Professor om it-skandaler: Digitaliseringsstyrelsen skal tilbage på skolebænken

En analyse af fem af de seneste års største statslige it-fiaskoer viser, at mange af problemerne kunne være undgået ved at gribe projekterne anderledes an.

I rapporten identificerer professor Søren Lauesen fra IT-Universitet i København 36 årsager, som alle har bidraget til, at projekterne er lagt i graven eller afstedkommet betydelige økonomiske tab.

“Fælles for projekterne gælder, at man ikke vidste, hvordan man skulle stille krav til it-systemet. Problemet er, at man møder kunden med en lang liste med krav, som systemet skal opfylde. Derved giver man ikke leverandøren nogen frihed, og det betyder, at man ikke får en smidig arbejdsgang,” forklarer Søren Lauesen.

Digitaliseringsstyrelsen magter ikke opgaven
Han har i over 20 år undersøgt problemfyldte offentlige it-projekter og blandt andet hjulpet Rigsrevisionen med at undersøge, hvorfor en række store it-projekter slog helt eller delvist fejl.

Rapporten tager afsæt i fem konkrete projekter: Den Digitale Tinglysning, Rejsekortet, PolSag, EFI og EPIC.

Og selv om projekterne favner bredt på tværs af offentlige sektorer, er det ifølge professoren muligt at udpege én fællesnævner for problemerne.

Hvis jeg skal være bramfri, så kan Digitaliseringsstyrelsen ikke betale de store lønninger. En it-specialist ansat i staten kan måske tjene halvdelen af, hvad en topprofessionel it-udvikler får i løn. Man kan ikke købe de bedste.

Søren Lauesen
Professor, IT-Universitetet

“Det største problem er, at vi mangler indsigtsfulde rådgivere til statens it-projekter. Tanken var, at opgave skulle løses af Digitaliseringsstyrelsen, men det kan de ikke løfte,” siger han.

Problemer og kur
Først skal vi dog dvæle lidt mere ved selve analysen. I tilgift til de 36 årsager udpeger Søren Lauesen også en lang række løsninger, som kan komme besværlighederne i forkøbet.

Her er opremset fem af de hyppigste årsager samt professorens forslag til en kur:

I bunden af artiklen findes en fuld oversigt over problemerne

• Identificerer ikke brugernes behov og win-win: 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.
• Beskriver ikke krav, der dækker kundens behov: 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.
• Gaber over for store opgaver: 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. Eller 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.
• Designer brugergrænseflader for sent: 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.
• Oplever overraskelser, når forskellige systemer skal integreres: 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å de nødvendige tilladelser til at forbinde til det eksterne system. Senere i forløbet kan eventuelle fejl fanges ved at teste systemet.

“Mit mål er, at mine forslag bliver skrevet ind i de projekthåndbøger, som man arbejder med rundt omkring i landet. Nogle af dem står der allerede, men mange gør ikke. Og så ser jeg det som en drøm, at Digitalseringsstyrelsen – som er rigtigt udtænkt – også bliver i stand til at bruge dem,” siger han.

Projektmagere stiller ikke de rigtige spørgsmål
Det skal ikke være nogen hemmelighed, at Søren Lauesen er stærkt kritisk over for netop Digitaliseringsstyrelsens arbejde.

Han anerkender, at styrelsen har forsøgt at arbejde med andre typer kravspecifikationer, men mener ikke, at arbejdet har båret frugt.

“For et par år siden så jeg kravene til et energimærkningssystem, hvor de havde prøvet at bruge problemorienterede krav. Men de gjorde det uden at forstå princippet, og derfor blev det mindst lige så slemt som sædvanligt,” siger han.

Andre eksempler på problemer, som ifølge professoren ikke får tilstrækkelig opmærksomhed, finder man i udviklingen af sundhedsplatformen EPIC og Den Digitale Tinglysning.

“Man havde glemt at måle, hvor effektivt en ekspertbruger af systemet arbejder. Hvor hurtigt kan en læge arbejde og lave en sædvanlig konsultation? Det har de ikke målt, og det viste sig at være et helt centralt problem, da de startede op.”

“Det var det samme problem, som var årsagen til, at den elektroniske tinglysning kom galt fra start. Nemlig at medarbejderne var meget langsomme til at håndtere sagerne manuelt. De var ikke fortrolige med systemet. Og derfor gik man i drift med for få mennesker i supporten.”

Dyre konsulenter er ingen mirakelkur
En typisk reaktion, når man identificerer et problem i den offentlige sektor, er at hyre konsulenter ind til at hyre opgaven. Det har man også gjort i stort omfang i forbindelse med de mange fordyrende it-projekter. Men det er langtfra en mirakelkur, pointerer it-professoren.

“De er ganske enkelt ikke dygtige nok. Eksempelvis kender jeg ingen konsulenthuse, som kan skrive en brugbar kravspecifikation, selv om de får millioner for at gøre det.”

Og nu han er ude med riven, er det nærliggende også at give uddannelsesinstitutionerne en tur, fordi de ikke sørger for at spytte tilstrækkelig talentmasse ud.

“Jeg har opgivet at få universiteterne til at gøre noget ved det. De forstår overhovedet ikke problemerne. Og de forsker ikke i dem, fordi de ikke synes, at de er vigtige, så vi får ikke uddannet nye kræfter.”

Gælder det også din egen arbejdsplads IT-Universitet?

“Jeg har prøvet i årevis at få dem til at gøre noget ved det. Vi har en masse dygtige folk på de andre områder - eksempelvis matematiske beviser for programmer - men de interesserer sig ikke for store it-anskaffelser. De interesserer sig for at løse de problemer, som de selv har defineret, og ikke de problemer, der faktisk findes i store it-projekter.”

Behersket optimist – trods alt
Det lyder, som om at du ikke er alt for optimistisk på de statslige it-projekters vegne?

“Jo, det er jeg. Jeg mener, at de kunne gøre noget, hvis de ville.”

Men hvorfor skulle de ikke ville det?

“Jeg tror godt, at de er klar over problemerne. Jeg tror godt, at Digitaliseringsstyrelsen kan se, at der mangler noget. Men hvis jeg skal være bramfri, så kan Digitaliseringsstyrelsen ikke betale de store lønninger. En it-specialist ansat i staten kan måske tjene halvdelen af, hvad en topprofessionel it-udvikler får i løn. Man kan ikke købe de bedste.”

Det kan altså se ud til, at der er en inerti, som betyder, at statslige it-projekter også fremover vil være omfattet af skandaler?

“Lad mig lige understrege, at i det private er det ikke bedre. Der hører vi bare ikke om det. Men i erhvervslivet er man i stand til at stoppe projekterne tidligt, hvis man ser, at man går i den forkerte retning. Og det har man sværere ved i det offentlige på grund af frygten for prestigetab og kuldsejlede investeringer.”

“En anden forskel er, at private aktører er bedre til at udskyde driften af nye systemer. Her satser det offentlige på at skynde sig lidt mere til sidst, og så ender det med, at systemet går i drift uden at være testet ordentligt. Og så kommer katastrofen derefter.”