ITU-professor: Amatøragtigt forarbejde gjorde EFI og Polsag til IT-skandaler
Der er rigtig meget at lære af it-projekter som EFI (SKAT’s inddrivelsessystem), PolSag (Politiets sagssystem) og Rejsekortet, mener professor på IT-Universitetet Søren Lauesen. Han har i 20 år har undersøgt offentlige it-projekter.
I denne artikel, som ITU har udarbejdet og som Version2 har fået lov til at udgive, giver Søren Lauesen sine bedste råd til at undgå flere it-skandaler.
Men lige som ved mange alvorlige flyulykker, er det ikke én ting, der går galt - men flere:
»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, der på ITU 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 ifølge ITU-artiklen.
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.
Søren Lauesen har arbejdet 20 år i it-industrien som programmør, opfinder, kvalitetssikringschef og meget mere. Han har været professor i over 30 år og har været med til at grundlægge adskillige uddannelser blandt andet IT-universitetet. Han er ofte konsulent i store og små projekter og har de seneste år hjulpet Rigsrevisionen med at undersøge, hvorfor nogle store it-projekter fejlede helt eller delvis fx den Elektroniske Tinglysning, Rejsekortet, Politiets Sagsstyringssystem og Skats inddrivelsessystem (EFI). Erfaringer fra disse projekter bringer han ind i undervisningen. Kilde: IT-UniversitetetSø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. 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.
EFI-systemet var også baseret på en række nye arbejdsgange. F.eks. 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 f.eks. 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 f.eks. have startet med et par gældstyper, f.eks. 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. F.eks. 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.
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. F.eks. 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 f.eks. slet ikke godkende det regnskabsmæssige, og revisionssporet var tabt,« fortæller Søren Lauesen.
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.
De ti mest almindelige konkurrerende dødsårsager
Nedenfor er Søren Lauesens liste over ti mest udbredte konkurrerende dødsårsager i større it-projekter.
Listen er baseret på Søren Lauesens undersøgelser af projekter som SKAT’s inddrivelsessystem (EFI), Politiets sagssystem (PolSag), Rejsekortet, elektronisk tinglysning (eTL), Hovedstadens Sygehusfællesskab (H:S) med flere.
Sætter sig ikke ind i brugernes behov (skaber ikke win-win).
Ved ikke, hvordan man skal skrive kravene, så de dækker behovene.
Høster gevinsten, inden den er opnået.
Ingen forretningsmæssige mål – eller glemmer dem undervejs.
Kræver ind og tror, at det er gratis.
Tør ikke sige til leverandøren, at de ikke forstår hans løsningsforslag.
Skridt for skridt i grøften uden at det opdages.
Teknologier oversælges f.eks. SOA eller ”alt skal være webbaseret”.
Leverandør for optimistisk – den der vinder lyver.
Pengene slipper op og parterne skændes i stedet for at samarbejde.
...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.
Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.
Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.
Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.
