Kennet mener disse planene er oppskriften på en ny, stor IT-skandale

[Redaksjonen.]

Kennet mener disse planene er oppskriften på en ny, stor IT-skandale

[69ZT3Y16]

Hvis du tegner opp før-skissen per prosess så ser det gamle systemet riktig så bra ut:

 

Vi må ha løsninger som har nytte for skattebetalerene, ikke løsninger så ser vakre ut på oversikten til arkitektene som bestiller løsningen.

[Svært Undrende]

Er enig med Kennet Nilsen i at prosjekter som planlegges for så lang gjennomføringstid løper en stor risiko for ende opp som problemprosjekter. En av hovedutfordringene er at en gjerne sitter igjen med verken med det en spesifiserte seks-syv år tidligere eller det en faktisk trenger på tidspunktet prosjektet avsluttes.

 

En ender gjerne opp med noe midt imellom der 20-50 prosent av det en opprinnelig spesifiserte ikke lenger trengs i den form det var tenkt samtidig som en har brukt mye ferske penger på å tilpasse seg nye behov, lærdom og teknologi som dukker opp underveis.

 

På toppen av dette blir en nødt til å budsjettere med ytterligere investeringer for dekke gapet mellom det systemet leverer og det som er det faktiske behovet etter de seks årene.

 

Effekten av dette er at en ikke klarer å møte de opprinnelige stipuleringene for verken kostnader eller tidsbruk.

 

Bruk av smidige metoder kan motvirke deler av denne risikoen men det fordrer at smidigheten omfatter hele prosjektet, inkludert prosjektets eiere og sponsorer, og at det på høyeste hold eksisterer den nødvendige forståelse for hva dette innebærer av endringsvilje og -evne i hele prosjektperioden.

 

Nå kjenner jeg verken prosjekteringen som er gjort eller hvilke krav som er lagt til grunn for den. Det er derfor umulig å mene noe konkret om det som faktisk er gjort. Men, rent umiddelbart ville jeg mene at en burde satt seg et gjennomføringsmål på ca to år og så brukt noen nye øyne til å se på hva som skal til for å gjennomføre innenfor en slik komprimert tidsskala. Min erfaring er at det slettes ikke behøver å bety at prosjektet blir noe dyrere totalt sett.

[Kikert]

I overkant negativt synes jeg. At det er utdatert når man er ferdig om 6 år er irrelevant da det også vil være utdatert om 6 år hvis det sto ferdig i morgen.

 

Brreg er "komplisert" nå også, men hvis man har bittelitt vett i knollen så klarer man fint å finne ut hva man trenger. Man skal også ta vare på dokumentasjon av alle slag uansett så hvis noe ikke blir levert eller noe blir feil så er det bare å fikse det i ettertid, man får ikke millionbot for å ha glemt ting som småbedrift. Store bedrifter er en annen sak.

 

Man kan ikke lage noe så massivt og komplekst som Brreg simpelt, det vil bli en stor salat uansett. Men selvfølgelig så må man gjøre det oversiktlig og det er kanskje det han mener? Selv synes jeg det er mer enn greit å navigere seg rundt der og hvis man trenger hjelp så er det alltids noen på diskusjon.no som klarer å hjelpe

 

Jeg er dritt lei av at alt skal være så enkelt, har vi blitt veldig mye dummere brått? Jeg har tro på at det er fullt mulig at oppegående mennesker klarer å bruke en tjeneste selv om det ser litt overveldende ut.

[DiamantGrevling]

Lars Peder Brekk er nok i overkant diplomatisk når han sier at han tror Nilsen ikke forstår omfanget av aktiviten i Brreg sine systemer. Nilsen sier at at en må identifisere brukerne. Han raljerer også mot skjemajungel og for enkle systemer for mannen i gata.

 

Problemet for Nilsen er bare at han selv feiler med å identifisere brukerne. Dette prosjektet gjelder det interne saksbehandlingssystemet hos Brreg. Det er ikke et system som private skal forholde seg til. I hovedsak skal næringsdrivende og andre private forholde seg til Brreg gjennom å sende inn informasjon i Altinn (eller på papir). Det nye systemet skal behandle denne informasjonen på innsiden hos Brreg.

 

Når Nilsen ikke får med seg denne grunnleggende forutsetning, tror jeg ikke øvrige kommentarer skal tillegges vekt i denne saken.

 

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.

 

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.

[DiamantGrevling]

Hvis du tegner opp før-skissen per prosess så ser det gamle systemet riktig så bra ut: https://twitter.com/ChristinGorman/status/757938395729518592

 

Vi må ha løsninger som har nytte for skattebetalerene, ikke løsninger så ser vakre ut på oversikten til arkitektene som bestiller løsningen.

Her er det viktig å være klar over at den skissen som Gorman viser til ikke gjelder enkeltprosesser, men heller de forskjellige systemene. Hver og en av systemene har en mengde prosesser, så det er en alt for grov forenkling han har gjort ved å illustrere dette prosjektet til å være et fåtall prosesser.

 

Nå er ikke jeg noen systemutvikler, så jeg er åpen for at den nyansen ikke undergraver hovedpoenget hennes, men for min del får jeg et inntrykk av at hun ikke forstår kompleksiteten i de systemene som er i dag og systemet Brreg nå ønsker seg.

Endret 28. juli 2016 av DiamantGrevling

[*F*]

Microsoft Access eller Excel....

[Thomas Arp]

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..

[E32IF3SH]

Det blir garantert ikke en framtidsrettet meldingsorientert modulbasert løsning, hvor hver enkelt del av løsningen kan oppdateres når ny teknologi blir tilgjengelig.

[ibnbattuta]

det vekker assosiasjoner til moderniseringsprogrammet i nav, jfr http://www.digi.no/artikler/ikt-i-nav-hva-gikk-galt/347598. det er edruelig (gjen)lesning.

[0slo]

framtidsrettet meldingsorientert modulbasert løsning

 

Jøss.. nettopp vært på kurs?

[Anders Jensen]

BRreg virker å være midt i blinken for FaaS/serverless (iron.io + OSE?). Burde gi den endringsdyktigheten de har behov for samtidig som en får standardisert "undifferentiated heavy lifiting" mest mulig. Det er vel mye asynkron backend jobb ho BRreg, så FaaS bør være en god match. Regner med BRreg bruker mye ressurser på å drifte forskjellige komponenter som kunne vært like i dag. Det gjør vel de fleste av oss som ikke jobber hos en start-up.

 

Uansett burde dette kun vært forvaltnings aktivitet. Det er meningsløst å levere IT systemer som prosjekter, med mindre du definerer prosjektet til å vare like lenge som systemet. Det er derfor så mange IT hoder blir helt forstyrret av disse mega prosjektene innen IT. De er dømt til å mislykkes fordi et IT system leveres ikke, det lever.

Endret 29. juli 2016 av Anders Jensen

[angeland89]

Slutt å leie inn utviklere. ansett utviklere slik som man ansetter folk i skranken. la de lage produkter som skal leveres. Mye slik som bedrifter normalt lager varer

[Fangs78]

Disse problemene har med anbudsreglene å gjøre tenker jeg. Før man kritiserer det offentlige for dette, må man se på reglene de har og forholde seg til.

 

De må bytte ut 6 store systemer som henger sammen. De kan ikke bare bytte ut ett, se hvordan det gikk og prosjektere på nytt etter første prosjektet, som noen her har foreslått. Da må de ha ett anbud per system/prosjekt. Med påfølgende ventetid mellom hvert prosjekt. Med de problemene det fører med seg.

 

Man står da også i fare for å måtte bruke forskjellige leverandører/konsulenter per system, noe som de fleste forstår ville vært svært fordyrende, avhengig av hvor tett systemene skal fungere sammen.

 

Jeg leser at etaten *ønsker* å bruke smidig prosjektstyring i dette prosjektet, med åpning for endringer av hvert system selv etter leveransen, som en del av prosjektet. Det er vel det de fleste her mener er riktig å gjøre, så kritikken faller litt urimelig syns jeg.

 

Vi hadde hatt godt av et mye mer smidig anbudsreglement for IT prosjekter i Norge. Etatene burde stått langt friere til å velge leverandører og prosjektoppbygging enn det er i dag. Den siste endringen som kom (for noen år siden) er et steg i riktig retning, men det langt fra nok, i mine øyne.