Klassiske IT-fejl koster nationen milliarder

Hen over de sidste tyve år har den ene IT-skandale efter den anden kostet samfundet milliarder af kroner. Ifølge ITU-professor Søren Lauesen er det ofte de samme fejl, der går igen.

Det er hele Danmarks infrastruktur og alle kerneinstitutionerne, der er blevet rokket i deres grundvold gennem de seneste 20 års IT-skandaler.

De basale institutioner, som udgør kernen i en velfungerende nation, har alle haft enorme problemer, når de skulle opgradere deres grundlæggende IT-systemer. Ofte har det truet kernen i deres samfundsopgave.

Forsvaret, politiet, sundhedsvæsenet, den offentlige transport. Den har været gal hele vejen rundt. Selv den brede befolkning har hørt om Amanda, Polsag, Digital tinglysning, Proask eller EPJ og Rejsekortet, som alle har trukket ud, kostet for mange penge og i nogle tilfælde bare er blevet skrottet, inden de kom i brug.

Senest har det været selveste skattevæsenet, der er blevet rystet så kraftigt i grundvolden, at SKAT har haft problemer med at udføre kerneopgaven: At inddrive de skatterestancer, som er med til at finansiere alt det essentielle, som et samfund er bygget op omkring.

SKAT’s inddrivelsessystem EFI blev ikke blot forsinket i fem år, og kom til at koste en hel milliard mere end beregnet. Undervejs mistede man så meget grebet om kerneopgaverne, at man i dag regner med, at SKAT vil gå glip af et sted mellem syv og 14 milliarder kroner, som det nu er for sent at inddrive. At de samtidigt har udbetalt 12 milliarder kroner for meget i udenlandsk udbytteskat er en helt anden bonus-historie.

33 fejltyper går igen

En af dem, der har de største indsigt i årsagerne til de katastrofale IT-brølere er professor Søren Lauesen, fra IT-Universitet i København (ITU), der har undersøgt adskillige af de store sager, blandt andet som ekspert for Rigsrevisorerne. Og der er ikke én bestemt årsag til, at tingene går galt. Han har gennem årene lavet en liste på 33 klassiske årsager.

Og IT-brølerne er ikke små. Det kan nemt have seriøse konsekvenser, når tingene går galt, forklarer han.

”Hvis man tager Den Digitale Tinglysning, så betød systemskiftet, at det forsinkede mange folks hushandler i et halvt år, og dermed bragte man mange danskeres privatøkonomi i fare.”

Søren Lauesen har analyseret årsagerne til, at det gik galt med netop Den Digitale Tinglysning, og han kalder sagen for et fremragende lærestykke i, hvad der kan gå galt – og dermed en perfekt advarselsliste for andre.

Man havde sat en tinglysningsdommer til at designe skærmbillederne sammen med en grafisk designer. Det betød, at man fik et system, som kun en tinglysningsdommer kunne finde ud at af bruge.
Søren Lauesen, Professor, ITU

Forkerte specifikationer

Problemerne med IT-systemerne starter ofte før, man overhovedet er gået i gang med at kode.

”Man fokuserer ikke på, hvad brugernes behov egentlig er. Man tror, at man skal beskrive, hvad systemet skal gøre, men det skal man ikke,” understreger Søren Lauesen.

”Man skal i stedet beskrive, hvad det er for arbejdssituationer, systemet skal bruges i. Det har den store fordel, at kravsspecifikationen kommer til at fylde en femtedel eller en tiendedel.”

Søren Lauesen vurderer, at opgavebestillerne ofte overser konsekvenserne, når de opremser alle de ting, som de gerne vil have med i systemet.

”Man kræver bare ind og tror, at det er gratis. Tag sådan noget som tilgængelighed (oppetiden). Det koster 10 millioner kroner mere at have en tilgængelighed på 99,9 procent i forhold til, hvis man kan nøjes med 99,5 procent. Hvis man som bestiller i stedet tillader leverandøren at tilbyde flere muligheder, så kan man selv vælge om man vil have den dyre eller den billige.

ITU-professoren langer i samme runde ud efter en af tidens andre mode-fænomener, som også står på listen over årsager til IT-katastrofer: Service Orienteret Arkitektur (SOA), hvor IT-systemer trækker data fra andre systemer for at undgå at ligge inde med kopier af andres datasæt.

”Det er en urealistisk drøm. Tinglysningssystemet skulle trække på hele 10 andre systemer, fx på CPR-oplysninger, og det er selvfølgelig umuligt at holde en høj oppetid, når man er afhængig af så mange andre systemer.”

”I Tinglysningsaffæren gav det også forsinkelser, at man ikke var opmærksom på, at leverandøren ikke arbejdede på systemet de første måneder, fordi man havde mistet nogle topfolk. Alene det kostede et halvt års forsinkelse,” fortæller Søren Lauesen, der understreger, at en af de svære ting i et IT-projekt faktisk er at overvåge, at der er fremskridt i projektet i den første planlægningsfase.

Dommer som usability-ekspert

En anden klassiker er, at man ikke henter de rette eksperter ind tidligt i forløbet. Da man skulle lave Den Digitale Tinglysning begyndte man først at designe skærmbilleder fem måneder før lanceringen.

”Man havde sat en tinglysningsdommer til at designe skærmbillederne i systemet sammen med en grafisk designer. Resultatet var, at man fik et system, hvor man skulle igennem 22 skærmbilleder for at registrere en hushandel og ikke mindst et system, som kun en dommer kunne finde ud af bruge,” fortæller Søren Lauesen.”

”Det problem kunne have været undgået, hvis man havde gjort som UX’ere altid beder om: At man henter usability-eksperter ind tidligt i forløbet, så man kan lave simple produktions-dummies, der bliver testet tidligt i forløbet – før man begynder at kode.”

Da man skulle lancere Den Digitale Tinglysning skete det med udgangspunkt i en beregning, der sagde, at man kunne spare en masse penge. Problemet var blot, at man høstede rationaliseringsgevinsten – før systemet var i drift.

”200 tinglysningsmedarbejdere vidste, at de skulle fyres, når systemet var indført. Det betød selvfølgelig, at de begyndte at forlade skuden op til lanceringen. Når projektet pludseligt tog 1½ år længere, så havde man ikke længere kvalificerede medarbejdere men vikarer, som brugte længere tid om at ekspedere sagerne,” fortæller Søren Lauesen.

Kunderne skyld i flest fejl

Søren Lauesen har efterhånden undersøgt en stribe større IT-projekter, og hans erfaring er, at en stor del af fejlene går igen fra projekt til projekt. Han opdager dog et par nye fejl, hver gang han er ude på nye opgaver, eller når han bliver kontaktet af whistle-blowere. Derfor er han også tilhænger af en IT-havarikommission, som kan videreformidle erfaringerne og dermed mindske risikoen for, at man gentager allerede kendte fejl.

Det er alle parter i projekterne, der er medvirkende til fejlene. Kunden står dog for en overraskende stor del.

”Af de 33 forskellige årsager til IT-katastrofer, jeg opererer med, så er det kunden, der bestiller opgaverne, der står for hele 28 af årsagerne, mens leverandørerne er skyldige eller medskyldige i 12. Konsulenter, der trækkes ind, er medansvarlige i seks af årsagerne.”

”Endelig har regeringen skylden i tre tilfælde – fx når de oversælger Service Orienteret Arkitektur eller anbefaler en fler-leverandør-strategi, som er uhensigtsmæssig. Når en kommune har seks leverandører, som hver har monopol på deres område, så skal de holde styr på langt flere leverandører. Dermed er der mere, der kan gå galt.”

Ingen tør sige toppen imod

En af de 33 årsager på Søren Lauesens liste er et klassisk ledelsesproblem: Ingen tør gå tilbage til cheferne, særligt hvis der er tale om, at man skal krydse grænsen mellem embedsmænd og politikere.

”Der er en stor angst for forbindelse mellem politikere og embedsmænd. Det betyder, at man ikke tør gå tilbage til opdragsgiverne og fortælle om uhensigtsmæssige elementer. Tager vi Polsag-katastrofen, så havde regeringen specificeret, at man skulle bruge et standard ESDH-system. Men politiets behov ligger langt fra de almindelige behov. Det fik man aldrig afklaret,” siger Søren Lauesen.

Polsag-systemet endte med at blive forsinket tre år, koste 500 millioner kroner, og efter en kort pilottest blev hele systemet skrottet.

Fem måder at undgå IT-skandaler

Hvad kan man gøre for at undgå IT-brølere? Professor Søren Lauesen har fem konkrete bud:

1: TEST TIDLIGT

Lav brugergrænse-tests tidligt i forløbet. Man kan ret billigt lave en mock-up med en ikke-funktionel prototype, som man kan teste på repræsentative brugere.

2: PROBLEMORIENTEREDE KRAVSSPECIFIKATIONER

Formuler specifikationerne som problemorienterede krav. Det gør det muligt for leverandøren at være fleksibel og byde ind med billigere løsninger.

3: BRUG PILOTTESTS

Gør brug af pilottests i stedet for at rulle løsningen ud over alle brugere eller ud over hele landet. Der er intet i lovgivningen, der forhindrer, at man i starten behandler brugerne forskelligt, hvis man dermed kan undgå en stor IT-katastrofe.

4: KUNDEN KENDER REGLERNE

Man skriver ofte, at leverandøren har ansvaret for at overholde gældende regler. Men det er kundens ansvar at specificere, hvilke regler og love der konkret skal overholdes. DSB holdt fx fast i en intern regel om, at der ikke må være noget grønt, gult eller rødt lys på perroner. Det betød så, at brugerne ikke kunne se forskel på Rejsekortets ind- og udtjekningsstandere, fordi de alle skulle være blå.

5: REEL RISIKOVURDERING

Lav en reel risikovurdering, hvor man ser faren i øjnene. I Den Digitale Tinglysning havde man formuleret faren ved ”dårlig usability” som: ”dårlig usability.” Reelt betød de dårlige brugerflader, at almindelige brugere ikke kunne anvende systemet, og at de måtte vente på support i flere uger.