17.05.2017
Nyhed

Professor: Samme fejl er skyld i offentlige it-skandaler

Det er ofte de samme fejl der går igen, når store it-projekter ender i skandaler. Det mener ITU-professor, som i nyt rapportudkast viser de typiske årsager til, at it-projekter kuldsejler.

Af Martin Ejlertsen
Skats digitale inddrivelsessystem EFI. Skrottet. Pris: Op mod 80 milliarder kroner som mangler at blive inddrevet. Arbejdsmarkedsstyrelsens Amanda. Skrottet. Pris: En milliard kroner. Politiets sagsbehandlingssystem Polsag. Skrottet. Pris: Ca. en halv milliard kroner. Arbejdsskadestyrelsens it-system PROASK. Skrottet. Pris: 164 millioner kroner.

Igennem de seneste år har en række store it-skandaler i den offentlige sektor fyldt godt op i både medielandskabet og i danskernes bevidsthed.

Men når store problemer med it-systemer i det offentlige ender med taber millioner eller milliarder kroner og ender i sådanne skandaler, så kunne de faktisk være undgået. Det er nemlig oftest de samme fejl, der går igen.

Det mener professor på IT-Universitetet Søren Lauesen, som i et udkast til en ny rapport gennemgår årsagerne til, at fem af de seneste års store offentlige it-projekter gik helt eller delvist galt. Det drejer sig om Den Digitale Tinglysning, Rejsekortet, Politiets nu henlagte sagsbehandlingssystem PolSag, SKAT’s gældsinddrivelsessystem EFI, og Sundhedsplatformen EPIC, som i øjeblikket er ved at blive rullet ud på københavnske og sjællandske hospitaler. 

"Det gælder for alle projekterne, jeg har undersøgt, at man ikke vidste, hvordan man skulle stille krav til systemet. Det man gør galt er, at kunden med en lang liste beskriver, hvad man synes, systemet skal gøre. Derved giver man ikke leverandøren nogen frihed. Den løsning man får, kan gøre alle de ting, kunden har bedt om, men giver ikke en smidig arbejdsgang", udtaler Søren Lauesen i en pressemeddelelse. 

Konference onsdag
IT-professoren diskuterer onsdag på en konference på IT-Universitetet netop de seneste års udfordringer for offentlige it-projekter med CBS-professor Kim Normann Andersen og direktør for Digitaliseringsstyrelsen Lars Frelle-Petersen.

Søren Lauesen mener, at man i stedet bør beskrive, hvad systemet skal bruges til, fx den situation en sagsbehandler sidder i.

"Man beskriver de opgaver, man skal udføre med hjælp fra systemet. Og så kan leverandøren byde ind med, hvordan han vil hjælpe dem med det", siger Søren Lauesen.

I sit rapportudkast opridser Søren Lauesen på baggrund af sin undersøgelse af de fem fejlfyldte it-projekter 36 årsager til, at offentlige it-projekter slår fejl. Han oplister desuden de fem mest typiske årsager og giver sit bud på en løsning.  

5 hyppigste årsager + forslag til en løsning:

1) Identificerer ikke brugernes behov og win-win.
Kur: Undersøg hvad virkelige brugere gør og kig på alle typer brugere. Drejer det sig fx om et sundhedssystem, skal man sætte sig ind i alle de forskellige grupper af lægers, sygeplejerskers, og patienters behov.

2) Beskriver ikke krav, der dækker kundens behov.
Kur: Undgå at stille for detaljerede kravsspecifikationer. Beskriv i stedet hvilke opgaver, systemet skal hjælpe brugerne med at løse. I sit tilbud skal leverandøren specificere, hvordan systemet hjælper brugeren med at løse opgaverne.

3) Vil opnå alt på én gang, fx dække hele landet (som med Den Digitale Tinglysning) eller alle typer gæld (som med EFI). Kur: To muligheder. 1) Start med at sætte systemet i gang for et begrænset antal brugere eller kør en pilottest. Det gør det nemmere at hjælpe brugerne og forbedre processerne. 2) Start med at sætte dele af systemet i drift, fx en del der giver en synlig og øjeblikkelig effekt. Når alt kører som det skal, kan andre dele af systemet gå i luften.

4) Designer brugergrænseflader for sent.
Kur: Lav prototyper/mockups af brugergrænsefladerne tidligt i forløbet, lav brugertests af dem, og forbedr dem indtil resultaterne er tilfredsstillende. Når meget af systemet er programmeret, er det svært og dyrt at ændre brugergrænsefladerne.

5) Oplever overraskelser, når forskellige systemer skal integreres.
Kur: Lav et proof-of-concept lige efter kontrakten er underskrevet. Dette indebærer udveksling af data til eksterne systemer. Sommetider kan det tage flere måneder at få tilladelse til at få de nødvendige tilladelser til at forbinde til det eksterne system. Senere i forløbet kan eventuelle fejl fanges ved at teste systemet.