Derfor fejlede tre store offentlige it-projekter

Der er meget at lære af it-projekter som EFI (SKAT’s inddrivelsessystem), PolSag (Politiets sagssystem) og Rejsekortet. Søren Lauesen er professor på IT-Universitetet, og han har i 20 år undersøgt offentlige it-projekter. Her får du hans bedste råd til at undgå flere it-skandaler.

ForskningSøren Lauesenoffentlig it

Skrevet 5. juli 2016 11:36 af Ninna Gandrup

- Det er svært at se på it-projekterne og sige, at der er en eller to faktorer, som gør, at projekterne går galt. Der er oftest flere konkurrerende dødsårsøger, siger Søren Lauesen, som er professor på IT-Universitetet og underviser på kurset Anskaffelse og Kravspecifikation.

- Et gennemgående problem for alle projekterne er, at man ikke kan finde ud af at skrive kravspecifikationen, så brugernes og forretningens behov dækkes. Det har været gældende både i EFI-sagen, PolSag og Rejsekortet. Men der er også mange andre årsager til, at it-projekterne sejler, siger Søren Lauesen.

Derfor gik EFI galt
Den største udfordring for EFI-projektet var, at man havde undervurderet, hvor mange gældstyper, der fandtes. Derudover introducerede it-systemet en række nye arbejdsgange hos kommuner og andre myndigheder, som brugerne slet ikke var klædt på til. Endelig forsøgte it-systemet at erstatte en ekspertise i form af pantefogeden, som ikke kunne erstattes.

- Projektet var dødsdømt fra start, fordi man ikke havde styr på kravspecifikationen og fejlvurderede kompleksiteten. Man var simpelthen ikke klar over, hvad systemet skulle gøre. Det viste sig, at man skulle programmere 400 gældstyper, der hver havde 600 regler, og så skulle man teste, om systemet håndterede sagerne korrekt. Det var umuligt, og derfor nåede man ikke at teste færdig, før man under politisk pres satte systemet i drift, fortæller Søren Lauesen.

Projektet var dødsdømt fra start, fordi man ikke havde styr på kravspecifikationen og fejlvurderede kompleksiteten. Man var simpelthen ikke klar over, hvad systemet skulle gøre.

Søren Lauesen, professor og underviser på kurset, Anskaffelse og kravspecifikation

EFI-systemet var også baseret på en række nye arbejdsgange. Fx skulle kommunerne nu indberette deres gældskrav og indsende dokumentation direkte i systemet. Det resulterede i, at mange gældsposter blev registreret i systemet uden dokumentation, fordi EFI ikke testede, om den nødvendige dokumentation blev sendt med. Hvis ikke dokumentationen var med, kunne gælden slet ikke inddrives. Tidligere opkrævede kommunerne deres egen gæld med deres egen pantefoged og havde styr på den opgave helt nede i de praktiske detaljer.

- Tidligere kunne pantefogeden fx gå ned på stamcafeen og foran venner bede skyldneren betale sit udestående. Det var effektivt, men det kan et it-system ikke. Pantefogeden kunne også banke på hos den gældsramte familie med en pludselig forhøjet el-regning og snakke med dem om el-forbrug. Det kan et it-system ikke. Socialforvaltningen kunne tage hensyn til alkoholikeren, der netop var kommet på benene og skåne ham for at blive stævnet for manglende børnepenge. Det kan et it-system heller ikke. Dermed havde man lavet et system, der ikke kunne inddrive gæld, mens man havde fyret de pantefogeder, som faktisk havde gjort et fint arbejde, fortæller Søren Lauesen.

Det kan vi lære af EFI:

• Skriv en problemorienteret kravspecifikation, så behovene dækkes. Skitsér en løsning, men lad den være til inspiration og ikke et krav. En problemorienteret kravspecifikation beskriver hvilke kommende arbejdsopgaver systemet skal støtte, og hvilke problemer man har i dag. Den beskriver også de forretningsmæssige mål, og hvilke krav der sikrer, at de nås.
• Høst ikke gevinsten (fyring af pantefogederne), før den er nået. Dette kunne være undgået ved korrekt risikostyring.
• Lav et tidligt bevis på, at det er muligt. Man kunne fx have startet med et par gældstyper, fx dem hvor det økonomiske potentiale var størst.

Derfor gik PolSag galt

Projektet med Politiets nye sagsbehandlingssystem havde også en række sygdomme, som tilsammen gjorde, at systemet fik dødsstødet, før det overhovedet blev taget i brug.

- Politiet havde oprindelig lavet nogle forretningsmæssige mål og en cost-benefit-analyse. Anbefalingen var, at man købte et ESDH-system og lavede enkelte tilpasninger i det, så det kunne støtte Politiets arbejde. Men den løsning ville kræve, at man tilpassede arbejdsopgaverne til systemet. Fx kunne man ikke forvente, at de nye skærmbilleder ville være magen til de gamle, man havde. Men Politiet glemte de forretningsmæssige mål undervejs og omformulerede målet til, at man skulle have et system magen til det gamle - blot ”mere moderne”, fortæller Søren Lauesen.

Politiet havde ikke gjort sig klart, hvad systemet skulle kunne, hvilket kom frem under møder med leverandøren.

- 40 politimænd mødte op og fortalte enstemmigt, at de ikke kunne fortælle om deres arbejdsopgaver, fordi de var fortrolige. Leverandøren kunne derfor ikke se, hvordan politiet skulle bruge ESDH-systemet, og hvilke tilpasninger der var nødvendige. Senere viste det sig, at fortroligheden blot var en undskyldning. Den egentlige årsag var, at de ikke selv havde kortlagt deres opgaver. Her tre år efter har de dog fået kortlagt arbejdsopgaverne ved hjælp af problemorienterede krav, siger Søren Lauesen.

40 politimænd mødte op og fortalte enstemmigt, at de ikke kunne fortælle om deres arbejdsopgaver, fordi de var fortrolige. Leverandøren kunne derfor ikke se, hvordan politiet skulle bruge ESDH-systemet, og hvilke tilpasninger der var nødvendige. Senere viste det sig, at fortroligheden blot var en undskyldning.

Søren Lauesen, professor og underviser på kurset, Anskaffelse og kravspecifikation

Stik imod anbefalingen blev resultatet, at man udbyggede ESDH systemet med cirka 100 skærmbilleder, der lignede dem, politiet havde i forvejen, hvilket komplicerede leverandørens opgave, fordi de ikke passede ind i systemet. Det betød 97.000 linjer mere kode i projektet.

- Da det, der svarer til Digitaliseringsstyrelsen, kiggede på projektet, kunne ingen pege på de økonomiske gevinster, men man kunne derimod konstatere, at driftsudgifterne blev femdoblet, og det blev besluttet at lukke projektet, fortæller Søren Lauesen. På det tidspunkt havde projektet kostet Politiet henved en milliard kroner.

Det kan vi lære af PolSag:

• Undersøg behovene og beskriv dem som problemorienterede krav.
• Husk de forretningsmæssige mål gennem hele projektet. Ved hvert styregruppemøde skal man vurdere, om målene stadig stemmer overens omkostningerne.

Derfor fik Rejsekortet en svær start

Der har også været en række udfordringer i projektet med Rejsekortet, som andre kan lære af. En udfordring var, at leverandøren troede, at han blot skulle levere en standardløsning, som han havde gjort mange andre steder i verden.

- Leverandøren troede, at han blot skulle stille de nødvendige webservices til rådighed og lade lokale SW-huse sørge for kortsalg, regnskab, kundeservice osv. Fx stod der i kravspecifikationen, at der skulle være en ”funktion til at rapportere stjålne kort”, og her troede leverandøren, at det var en webservice. Men kunden forventede, at det var drift af et kontor med kundeservice, forklarer Søren Lauesen.

Tidligt i projektet skulle leverandøren fremlægge en løsningsbeskrivelse. Den var meget teknisk og viste stort set bare, hvilke servere der skulle være og et par skærmbilleder, der viste status af de forskellige servere.

- Kunden syntes ikke, det var nok, men vidste ikke, hvad man normalt forventer af en løsningsbeskrivelse. Han gjorde derfor ikke vrøvl, men tænkte, at leverandøren jo havde lovet at levere. Så man måtte jo vente og se, hvad han leverede. Da det endelig skete, var det helt ved siden af. Revisoren kunne fx slet ikke godkende det regnskabsmæssige, og revisionssporet var tabt, fortæller Søren Lauesen.

Han gjorde derfor ikke vrøvl, men tænkte, at leverandøren jo havde lovet at levere. Så man måtte jo vente og se, hvad han leverede. Da det endelig skete, var det helt ved siden af.

Søren Lauesen, professor og underviser på kurset, Anskaffelse og kravspecifikation

Ifølge kontrakten skulle der også udføres usabilitytest, hvilket man gjorde, men leverandøren nægtede at rette problemerne.

- Leverandøren mente ikke, at det stod kontrakten, at han skulle gøre det. Kunden mente derimod, at det var underforstået og normal dansk praksis. Leverandøren gav sig, ligesom han også havde gjort for de andre uoverensstemmelser, men tabte nok omkring 500 millioner kroner, mens kundens udgifter kun var lidt over budgettet, fortæller Søren Lausen.

Det kan vi lære af Rejsekortet:

• Beskriv de arbejdsopgaver, som systemet skal støtte. Bed leverandøren beskrive, hvordan hans system støtter opgaverne.
• Vær ikke bange for at sige, at du ikke forstår løsningsbeskrivelsen. Stil krav om, at den skal vise de skærmbilleder, som systemet vil have, og kontroller, at de er testet for usability.