Thomas Arp

Både-og. Det er jo reelt at staten bruker flere penger på konsulenter enn de gjør på fastansatte. Og det er verdt å diskutere om det er fornuftig bruk av våre felles penger. Men det er vesentlig at man innser at valget står mellom en større stat (VESENTLIG flere ansatte) eller oppgaver som ikke blir gjort, dersom man skroter konsulentene. Det virker det ikke som om SP-lederen har innsett.

Så... personer med ansvar for kontrakter må reforhandle? Jeg må innrømme at jeg sliter litt med å se daglig-konsekvensene her.

Dette er alt sammen riktig og viktig! Takk for at du skriver det (jeg mener det samme men mangler dine evner til å formulere meg uten å tale ned til mottakerne).

Jeg håper du når frem til noen av dem som tar beslutningene, Christin. Jeg deler denne på de plattformer jeg har tilgjengelig og oppfordrer andre til å gjøre det samme, slik at sjansen øker.

Jeg synes det er en spennende idé å tenke at man kan bruke en annen form for hyllevare (Content management systems) i stedet for å gå etter noe som er mye større og vesentlgi vanskeligere å forholde seg til. Bra tenkt!

Færre e-poster ... Ja, og hva så? Det blir mer av noe annet ... Ikke sant? Pling og varsler på mobilen? Akkurat som om det er noe å trakte etter???

 

Det blir mer samlet informasjon ett sted. En gruppe som kommuniserer om dokumenter som ligger i skyen, som alle kan se endringer i "live". Et sted der bar de relevanted linjer blir skrevet - mail er i virkeligheten et utrolig verbost medium - du må sikre at alle er med at det er nok historikk til at alle kan følge hva som har skjedd og høflighetsfraser som "hei X," og "Vennlig hilsen Y".

 

Hvis du tror at det blir mer støy når man bare skriver det viktigste i en gruppechat, har du aldri vært med på en slik mailingliste - to tredjedeler av mailene kommer fort til å handle om hvilken versjon av et gitt dokument som er den gjeldende og hvem som fortsatt ikke er informert. Jeg har eksempler på mailtråder med hundrevis av mail, der opp under halvparten har vedheftede filer og det er umulig å si ut fra teksten i mailen om den vedheftede filen er en kladd eller et ferdig dokument. Også der flere jobber parallelt og har dokumenter som så må merges.

 

Alt dette forsvinner når man i stedet bruker en enkel chat-løsning. Jeg har prøvd en rekke ulike, og selv om Teams ikke er en av dem jeg har best erfaringer med, er den fortsatt mye bedre enn mail.

Sjeldent jeg så naturlig stiller meg bak et åpent brev fra gigantene.

Hvor mange slike artikler må dere kjøre i året? 

 

Mange, håper jeg. Jeg synes det er en interessant problemstilling. Hvordan sikre at man får alle de nødvendige innspill for å lage gode løsninger for alle, hvis man mangler halvparten av jordens befolkning i bransjen?

 

Med andre ord så blir kundene flådd og betaler grov overpris. Og verre skal det bli. Microsoft er Microsoft. Det er tilgangen til dine egne data Microsoft alltid har hatt som mål (og har i store trekk klart) å kontrollere. Sånn at du aldri er i reelle forhandlinger med Microsoft. Du betaler bare beskyttelsespenger. For det ville jo vært dumt om det skjedde noe med denne fine lille tilgangen til dataene dine, ikke sant?

 

Det er naivt av deg å tro Apple, Google, Facebook og andre selskap ikke tjener penger på data om deg.

Så vidt jeg forstår missi, er poenget at du betaler Microsoft for å ha tilgang til dine data. Google (med deres mail/docs/sheets/drive/photos/slides) tjener tilsynelatende nok penger på å selge reklamer til deg til at du ikke trenger å betale dem i tillegg. Jeg antar at også Microsoft selger reklamer, så de har dobbelt pengestrøm; både direkte fra deg og fra reklamene.

Det er litt sprøtt at de må betale nesten en million for å få tettet noen få hull. Framfor å sjekke koden selv. Tenk på alle de andre hull som ikke ble tatt tak i denne gang? Det er sikkert noen igjen som kineserne ikke oppdaget, men kanskje NSA eller Russland vet om.

 

Egentlig ikke dyrt med en million. Den ekspertise som sitter i et slikt hackerteam ville kostet dem mye mer hvis de skulle ha hatt dem på lønningslisten permanent. Og i praksis er det ikke sannsynlig at de selv ville kunne finne feilene likevel - her var det mange teams som alle jobbet for å få det til, og det lyktes bare for noen av dem.

Det eneste som egentlig manglet var at det offentlige skulle hive seg på Agile/Scrum bølgen å bli religiøse, for dette er mer religion enn det er noe annet.

 

Dette med "smidig" utvikling er ikke nødvendigvis bare positivt, stadig flere selskaper opplever at det er problematisk å jobbe på denne måten, og at det fører til dårlige produkter og misfornøyde ansatte.

 

Dette blir vel som å banne i kirken, da de som har lest Bibelen ("Manifestet") som oftest er totalt hjernevasket og vil forsvare sin "religion" med nebb og klør.

 

Som det kommer frem i en av kommentarene på en av de sidene du lenket til, er "smidig" egentlig bare det motsatte av "fossefall" eller BDUF.

Jeg synes det høres ut som en god idé å ha mulighet for å justere målene underveis, etter hvert som vi vet mer om hva man kan oppnå. Det er hva jeg mener begrepet "smidig" dekker.

 

Mener du at man bør låse seg til den første visjon man har, den plan man lager når man vet aller minst om hvilke utfordringer man vil komme bort i i forbindelse med implementasjonen? I så fall er jeg redd du selv høres litt religiøs ut.

JA! Takk for denne her, Beth og Erik. Vi trenger flere som dere, som forteller om suksess opplevd med smidig utvikling, også i offentlig sektor.

Til dere som mener epost "burde være nok" - en ting som ikke kommer automatisk med en slik løsning er en sikkerhet for at du er deg. Altså, innholdet blir kryptert og kan bare åpnes med en riktige nøkkel, og publicnøkkelen er lastet opp på en key server.

Så vi kan være ganske sikre på at du som har privatenøkkelen er den eneste som kan lese innholdet i eposten. Men kan vi være sikre på at det er deg som har lastet opp den nøkkelen til key serveren?

For å bli med på digipost (eller e-boks, antar jeg) må du ha en form for elektronisk id fra før. Den du bruker til altinn. Og nettbanken. I tillegg mener jeg at jeg mottok et fysisk brev med en kode, før jeg kunne bruke tjenesten. Det siste er jeg litt usikker på, det kan ha vært en sms. Altså, to- eller tre-faktor autentisering for å starte en konto.

Med andre ord, det er en høy grad av sikkerhet for at den som faktisk har kontoen hos digipost er den personen de utgir seg for å være.

Egentlig burde handlingsreglene skjerpes enda mer ved å kreve at realkostnadene i offentlig sektor SKAL reduseres med minst 5 % årlig.

 

Jeg synes nu at Arild Haraldsens forslag om å holde en stabil netto-utgift er strengt nok. I praksis vil det medføre at utgiftene høyst stiger i takt med utviklingen i økonomien.

I Norge er offentlig sektor i seg selv en vesentlig bakgrunn for fordelingspolitikken, i tillegg til at det løses mange nødvendige oppgaver. Det sier noe at selv partier som har gått til valg på å stramme inn sliter med å finne steder å kutte når de kommer i posisjon.

Det er et konstant ønske fra befolkningen om bedre tjenestetilbud fra det offentlige, i takt med den teknologiske utvikling. Dette må løses på en eller annen måte - jeg tror ingen politikere med ambisjoner om å sitte i mer enn en periode vil kunne motstå det presset, uansett parti. Alternativene er kort sagt enten å ansette flere eller å få de som er der til å gjøre mer med de samme folk. Det ene får utgiftene til å eskalere.

Altså må målet være å få inn løsninger som forhøyer produktiviteten til de ansatte, som Arild foreslår.

 

Jeg synes det er noen fornuftige forslag, han kommer med.

Det arbeides godt for å fjerne kontanter som betalingsmiddel. Skjønt dette er det rimeligste  betalingsmiddelet for butikken, og dermed for kunden.

 

Banker tar seg veldig godt betalt for å ta imot kontanter etter hvert. Og har du noen som helst volum i transaksjonene, er det i tillegg jobb med å transportere pengene. Det billigste alternativet for en typisk norsk forretning er debit-kort (bankaxept).

 

Dessuten når/hvis noen gærninger stopper kortbruk av forskjellige (politiske) årsaker, og/eller  nettet er nede, så er vi låst.

(Visa stoppet betalingsmulighet til Weakeleak)

Dessuten kan vi, gjennom kortbruk, spores både i handlingsmønster og geografisk. 

 

Betal regninger i nettbank, men betal med kontanter når du handler. Dette hjelper til å stoppe de som arbeider for  et kontantløst, ufritt samfunn.

 

Dette er til gjengjeld reelle innvendinger. Anonyme betalingsløsninger (som kontanter og bitcoins) er noe vi må ta vare på.

Jeg tror dere tenker litt for vanskelig om hva som er suksessfaktor for en levende IT tjeneste. Det er egentlig veldig enkelt. "you build it, you run it" Werner Vogels, Amazon.

 

Jeg forstår hva du mener, men det er ikke _nok_ å delegere til utviklerne. Man må endre noen av de rammene som fins omkring. Herunder prosjektoppsett, finansiering mv.

Brønnøysundregistrene er ikke et system som er enkelt og overskuelig nok til at ett (to-pizza) team kan håndtere en oppgradering.

Jeg kan se på det du har skrevet her (og i de sakene du ellers har lagt ut her) at vi er veldig enige, Arild. Investeringen er nødvendig. Det er ingen som har jobbet mot BR tidligere i tvil om. Det er en årsak til at mange offentlige instanser lager en lokal kopi av de registre de trenger. Flat-filer en gang i døgnet er en vanlig måte å integrere mot BR.

 

Innlegget "Gi oss oppskriften på IKT-skandaler" viser også at du er klar over hvor skoen trykker. Det er nødvendig å se på hva det er som har fått oss i den situasjonen vi er i i dag - med tunggrodde systemer som krever mye jobb (30% av driften) bare å holde fungerende.

Det er overveldende sannsynlig at det er en kombinasjon av teknologivalg, arkitekturvalg og organisering. Systemet har jo fungert i snart 25 år, så valgene var ikke helt dumme.

 

Den debatten jeg ønsker er nettopp den *systemtekniske debatten* du nevner i ditt innlegg. Den går på mange ting:

Om det alltid er korrekt å konsolidere - og om man kan ta den beslutningen så tidlig?

Om det kan betale seg å starte smått og så ta læring underveis?

Om arkitekturen enkelt kan tilpasses når man finner ut at det man trodde før ikke er riktig likevel?

Om man kan la seg inspirere av andre lande som har løst slikt før ( https://www.gov.uk/service-manual/making-software/apis.html / https://github.com/WhiteHouse/api-standards )?

Om man kan organisere det annerledes enn et mega-prosjekt?

Om man kan få god oppetid og svartid og sikkerhet og smidighet (slik at registrene kan tilpasses regler og lover)?

Om saksbehandlingsløsning må lages på nytt (fins det ingen som selger slikt)?

Om det er mulig å bli finansiert av staten og så ikke gjøre presis som man har fått kvalitetssikret?

 

Det er bare noen av de spørsmålene som kommer frem når jeg tenker på om det er en bedre metode enn mega-prosjekt.

Min personlige mening er at det vil være bedre å starte smått, ta lærdom og så utvide. Bruk av teams med utviklings- og forvaltningsansvar for hvert register (eller for flere, dersom det gir mening) som ikke bare står for fornyelse av de registrene men også har ansvar for å følge opp utfordringer og feilsituasjoner i etterkant (pager duty). Her kunne pengene brukes til å forsterke disse teams.

 

Når det kommer til et forum for å avklare spørsmål om prosjektorganisering er jeg også enig - dette er langt innenfor Difi sitt mandat, hvis jeg har tolket det riktig.

"Langt på vei er det dessverre slik at innkjøps- og finansieringsreglene i det offentlige krever at man lager prosjekter for denne typen skippertak for at det kan bli betalt."

 

Dette er dessverre en framtredende og feilaktig antagelse både i offentlige institusjoner og i leverandørmenigheten.

[...]

Utfordringen er vel kanskje dette med pengene.

[...]

 

Ja...

Jeg henger meg på det Geir skriver her over - det fremgår ikke, hverken av denne artikkel eller noen andre kilder jeg har funnet om saken, om oppdelingen i 6 delprosjekter er låst (er det allerede planlagt hva det skal skje i 5. og 6. delprosjekt? Og hvordan det så skal implementeres?).

 

Ulempen med lange planleggingsperioder er at man ikke vet nok, når man tar beslutningene. En løsning kunne ha vært å starte med ett av registrene og så ta lærdom underveis.

 

Jeg har forståelse for at de mange kommentarer oppleves som en hindring for dere på Brønnøysundregisterne. Dere har jobbet med å navigere i det mildt sagt ulendte terreng som er offentlig IKT-finansiering, levert analyser, kvalitetsikring, designskisser og meget annet jeg ikke har peiling på. Og så, når dere er klar til å søke om midler, kommer en flokk med folk som ikke har den samme kunnskapen om eksisterende systemer og stiller spørsmål ved den jobben dere har gjort og de løsninger dere har valgt. I noen tilfeller også den prisen dere har kommet frem til.

Vit at vi (eller, jeg kan bare tale for meg selv) ikke gjør dette fordi vi ikke tror at systemene på BR trenger oppgradering. Det er tydelig at det er nødvendig, ut fra de beskrivelser det er kommet i de ulike artikler, at noe må gjøres. Uenigheten er altså ikke OM det bør brukes penger på å gjøre systemene tidssvarende. Den går på HVORDAN det bør gjøres.

Langt på vei er det dessverre slik at innkjøps- og finansieringsreglene i det offentlige krever at man lager prosjekter for denne typen skippertak for at det kan bli betalt. Det får den uheldige konsekvens at man ofte lager kjempeprosjekt, som - når de er ferdige - viser seg ikke å ha levert det man nå vet man trenger, eller som vokser underveis og blir dyrere fordi man legger det til etter hvert som man oppdager det. Dette er ikke noen kritikk av enkeltmennesker - en slik prosess krever at man er synsk, hvis man skal få alt planlagt på forhånd. Det er dette vi reagerer på. Hver gang. Uheldigvis får vi litt for ofte rett i at budsjettet sprenges eller at løsningen ikke blir optimal.

 

En alternativ løsning som fungerer godt i utlandet (Christin lenket til dem i artikkelen sin) er å i stedet "utvide linja" - enten gjennom ansettelse eller innleie - og så utvikle forbedringene som en del av forvaltningen. Forvalterne (de interne utviklere) kjenner kundene sine og trenger uansett å kjenne til det nye systemet.

Uavhengig av Nilsens kommentarer er det også viktig å påpeke at dette ikke er så enkelt som et system med en database for hvert register, hvor data bare skal puttes inn og ferdig med det. De aller fleste registrene er regulert i egen lov, og for mange av registrene er det flere lover å ta hensyn til. For eksempel må nok Foretaksregisteret forholde seg til nærmere 20 forskjellige lover, om ikke mer. Det betyr en mengde regelverk som må kontrolleres av systemet og opplysninger som må følges opp.

 

Jeg legger merke til det du skriver her - at hvert register er underlagt ulike lover. Akkurat det er grunn nok til å vedlikeholde de ulike registre som ulike systemer. Endringstakten på de ulike registerne vil være ulik - derfor bør man dele opp systemene slik at de kan endres uavhengig av hverandre. Dette er det motsatte av å dytte alt inn i en database med en felles regelmotor på toppen.

 

Dermed vil det for eksempel ikke være tilstrekkelig å lage en enkel løsning for å registrere hvem som er styre for et selskap, da det er forskjellige regler for styret i et AS, et ANS eller et ASA, for ikke å snakke om selskapsformer regulert av spesiallover slik som bank og forsikring. Derfor er det dessverre nødvendig med et stort system, men som samtidig forsøker å gjennbruke funksjonalitet der det er mulig.

 

Akkurat - enhetsregisteret har sitt domene. Folkeregisteret har et annet. Det er forståelig hvis enhetsregisteret har en avhengighet mot folkeregisteret. Det er noe annet å si at fordi de har en avhengighet må de være en del av samme system, med felles datastrukturer i bunn. For alt jeg vet er folkeregisteret en førsteklasses kandidat til mongodb mens enhetsregisteret er selvskreven til å bruke en grafdatabase? Og kanskje folkeregisteret er stabilt over tid mens enhetsregisteret endrer formater tre ganger årlig? Er det ok at folkeregisteret er utilgjengelig mens enhetsregisteret oppdateres? Eller et av de andre 16 systemer? Er det ok at vi over tid ender med et system som ikke kan endres fordi alle endringer medfører at alt må stoppes mens vi ruller ut? Eksempler fra lignende omskrivinger tilsier at selv små, kosmetiske rettelser må igjennom en lang, tidkrevende prosess, når alt er avhengig av alt.

 

Det er kjernen i en slik konsolidering - man får avhengigheter som gir utfordringer når man skal lage selv små endringer. Dette løser man gjennom å lage løst koblede tjenester som ikke deler mer kode enn aller høyest nødvendig. Gjerne microservices med simple rest-grensesnitt.

 

Men, la oss se litt bort fra arkitekturen her - den er jo tross alt kvalitetssikret over flere år, så vi må anta at den er som den skal være (her er det litt sarkasme - i tilfelle det ikke kom frem). Den vesentligste utfordring her, som jeg ser den, er at man ikke ønsker å lære underveis. Å dele opp prosjektet i 6 stykk 200 000 000 kroners biter, hver med sine allerede definerte mål, ferdig designet og med rigide leveranser er kun marginalt bedre enn ett 1 200 000 000 kroners prosjekt. En mer fornuftig løsning ville gått på å transformere en eller to registre først, evaluere hva som fungerer og ikke fungerer, og så gjøre mer av det som fungerer. Kanskje man finner ut at man vil bruke Altinn på en annen måte enn man hadde planlagt?

 

Det er usikkert om det vil bli noe særlig billigere, men fordi man tar lærdom underveis er det nesten garantert at man får et bedre produkt til slutt. Og man får muligheten for å si, etter tre år, at nå har man modernisert de mest trengende registre, og resten kan tas som en del av forvaltning og videreutvikling (i linja) etter samme mønster som man etter hvert har identifisert er best for registre i Brønnøysund. I tillegg får man verdi av de første omskrivinger allerede etter første produksjonssetting..