DIGITALISERING OG OFFENTLIG IT

– Mye å lære av Navs IT-suksess

Skandaler har det ikke manglet på i IT-bransjen. Da det lugget for Nav midt i et storprosjekt, kastet de om på metodene – og kom ut med en suksessløsning.

Det tok flere måneder å få behandlet søknader om foreldrepenger. NAV startet en prosess med å få på plass et datasystem, men underveis endret de metode. Nå tar det sekunder å behandle søknaden, og de fleste gjøres ved selvbetjening.
Det tok flere måneder å få behandlet søknader om foreldrepenger. NAV startet en prosess med å få på plass et datasystem, men underveis endret de metode. Nå tar det sekunder å behandle søknaden, og de fleste gjøres ved selvbetjening. Illustrasjonsfoto: Nina Tveter
Svein Inge Meland, Gemini.no
9. des. 2022 - 12:20

Store forsinkelser, kostbare overskridelser og voldsom misnøye blant brukerne. Sånn har det gått når en del nye datasystemer skulle innføres.

Bransjen har lært, men ennå er det rom for store forbedringer, mener professor Torgeir Dingsøyr ved NTNU.

Han har studert hva som skjedde da Nav kastet om på arbeidsmetoden midt oppi arbeidet med å lage et nytt datasystem for utbetaling av foreldrepenger.

Fra fossefall til evolusjon

Den gamle fossefallmetoden i programvareutvikling var en trinnvis prosess:

Først en omfattende definering av hva man ville ha, så store valg av design og arkitektur, omfattende tester og til slutt – langt der fremme – leveranse til kunden. Hvert ledd var avhengig av de foregående.

– Fossefallmetoden innebærer unødig venting og stor risiko. Når prosjektet er en stafett, må den som avleverer forklare neste ledd hva det handler om. Gjerne gjennom en omfattende dokumentasjon. Ikke enkelt. Erfaringen er at prosjektmedarbeidere på ulike trinn ikke engang sitter sammen i lunsjen.

– Selv med omfattende dokumentasjon kan det i praksis bli en hviskelek. Det opprinnelige budskapet kan spore helt av, sier Dingsøyr, som arbeider ved NTNUs institutt for datateknologi og informatikk.

Små grupper

– At IT-miljøet sitter og venter på beslutninger i andre deler av organisasjonen, er også et kjent problem. I dag har programvarebransjen i stor grad beveget seg bort fra fossefallsmetoden mot smidig (agil) metode, sier professoren.

Smidige metoder kom som et svar på det bransjen opplevde som krise for IT-prosjekter. De fleste mente disse metodene bare fungerte for små, samlokaliserte grupper som lager et lite programvareprodukt, men i dag brukes de også i store IT-prosjekter.

Nav-suksess

Professoren mener de fleste i dag jobber med det han kaller førstegenerasjon storskala smidig metode.

Da Nav i 2016 startet med å lage et datasystem for å forenkle saksbehandlingen med foreldrepenger, valgte de en variant av førstegenerasjon smidig.

Midt inne i prosessen, og til tross for at tidsfristen var absolutt, hoppet Nav over til det Dingsøyr karakteriserer som andre generasjons smidig metode. Og lyktes svært godt.

Prosjektet ble gjennomført innenfor både tidsfrist og budsjett.

Behandlingstiden for søknaden om foreldrepenger ble kortet ned fra måneder til sekunder, og 99,8 prosent av søknadene ble behandlet med selvbetjening.

Nav kunne i 2019 smykke seg med prisen for digitale prosjekter.   

Kronikkforfatteren: Yngve Milde er konsulent i Bekk Consulting.
Les også

Ja, smidighet i større offentlige IT-initiativ er liv laga

Ledelsen – en støttefunksjon

– Hva er forskjellen på første og andre generasjon smidig metode?

– I andre generasjon står produktet i sentrum helt fra starten. Det jobbes i tverrfaglige grupper med stor frihet, sier Dingsøyr.

 Overlappende kompetanse innad i gruppen gjør at avklaringer skjer kontinuerlig, i stedet for i møter med mange andre som legger beslag på unødig tid og ressurser.

– Det brukes mindre tid til administrasjon og koordinering og mer til produktutvikling. Ledelsen må sørge for å sette retning for hva gruppene skal gjøre – og at produktiviteten er høy. Ut over det blir ledelsen mer en støttefunksjon til det faglige arbeidet. Man frir seg fra tvangstrøya med faser, forklarer Dingsøyr.

Prøve straks – lære underveis

I stedet for en detaljert og omfattende kravprosess med medvirkning av brukerne i starten på et prosjekt, er det bedre å gå i gang med det viktigste straks – og la brukerne gi tilbakemeldinger umiddelbart.

– Man har ikke tatt nok hensyn til brukervennlighet og at det tar tid å lære seg nye systemer. Med et tidlig samspill skjønner utviklerne fort hva som er viktig med systemet, hva kunden egentlig vil ha. Dermed kan de prioritere hardere hva som skal være med av funksjonalitet.

– Man prøver først en enkel løsning – og utvider hvis det trengs. Andregenerasjonsmetoder legger til rette for fleksibilitet og læring underveis, sier Dingsøyr.

Koordineringen må virke

Koordinering er en utfordring i store prosjekter når mange grupper jobber med å lage et datasystem og det er mange avhengigheter mellom oppgavene.

Man risikerer at endringer som én gjør, skaper uventede problemer for noen i andre grupper. Studier internasjonalt viser prosjekter hvor arbeidet har stoppet opp på grunn av manglende koordinering.

– Studien av foreldrepengeprosjektet er viktig fordi den viser hvordan prosjektet klarte å koordinere arbeidet på en mer effektiv måte med andregenerasjons metode, mener professor Torgeir Dingsøyr.

Unngå Big Bang!

Professoren tror det er skivebom å vente på én stor lansering:

– En Big Bang-lansering er svært risikofylt. Tekniske problemer kan være vanskelige å oppdage før systemet tas i bruk.

Og for brukerne er det vrient å vite hvordan nye systemer vil bli – før de ser hvordan de virker sammen med andre systemer de må bruke.

Man bør heller lage noe, teste det med en gang, vise det frem – og kanskje helst sette det i drift, før det gradvis lanseres til flere brukere.

Professoren forteller at strømmetjenesten Spotify har flere grupper som jobber med funksjoner for appen. Nye versjoner testes først internt og etterpå blant en del testbrukere før de slippes i stor skala.

– Takket være skyløsninger har det blitt mye lettere å sende ut nye versjoner, og ulike brukere kan få ulike versjoner. Med ny teknologi og nye metoder har vi fått helt andre muligheter.

Andre vil lære

En videreutviklet smidig metode brukes ikke bare hos en del store IT-selskaper. Stadig flere bransjer blir digitalisert. Hele bilbransjen ble utfordret av Tesla, som tenker som et programvareselskap. En moderne bil har kanskje 100 millioner linjer med datakode.

– Jeg ser for eksempel at Volvo Cars beveger seg i retning mer smidig utvikling av programvare. I prosjektledelse er det stor interesse for det som har skjedd i IT-bransjen, også innen økonomi og ledelse, sier Dingsøyr.

Han mener Norge og de andre nordiske landene ligger langt fremme i metoder for programvareutvikling. Mange år med diskusjoner har gjort flere miljø modne for andregenerasjonsmetoder, tror han.

– Studien av foreldrepengeprosjektet er det første som beskriver en overgang til andregenerasjon under gjennomføring av et stort IT-prosjekt og som viser hvordan overgangen førte til mer effektiv koordinering, sier Dingsøyr.

Artikkelen ble først publisert på Gemini.no

− Man blir ikke ferdig med programvareutvikling. Om man erklærer seg ferdig, har man bare startet på et nytt legacy-prosjekt, sier Navs IT-direktør Vegard Storstad.
Les også

Slik jobber Nav smidig i stivbeint regelverk

Del
Kommentarer:
Du kan kommentere under fullt navn eller med kallenavn. Bruk BankID for automatisk oppretting av brukerkonto.