Derfor gik det galt for EFI-systemet

Designet af EFI-systemet var på galt spor fra begyndelsen, og Skat endte med et system, som ville være verdens mest komplekse system til gældsinddrivelse – hvis det havde virket.

Skats system til inddrivelse af danskernes gæld til det offentlige blev sat i drift i december 2013. I september 2015 blev systemet taget ud af drift, da det kom frem, at sagsbehandlingen i systemet i flere tilfælde overtrådte loven.

Hvordan kunne det gå så galt for et system, det havde kostet mere end én milliard kroner at udvikle?

Den korte forklaring er, at der ikke kan peges på én enkelt årsag til, at EFI-systemet ikke virker og nu sandsynligvis skal udskiftes. Men hvis man alligevel skal sætte fingeren ét sted i det otte år lange projektforløb, så opstod problemerne allerede inden, der var skrevet så meget som én linje kode i programmet.

En del af de mange problemer i EFI-systemet er afdækket i en omfattende rapport, 'Teknisk rapport fra Accenture', som konsulentfirmaet Accenture har udarbejdet for Skatteministeriet.

Rapporten skal danne grundlag for EFI-systemets videre skæbne og var medvirkende til, at flere chefer hos Skat med tilknytning til EFI-projektet blev suspenderet i september.

Den tekniske rapport peger flere steder på selve systemets overordnede arkitektur og den kravspecifikation, som leverandørerne fik at arbejde med. Om kompleksiteten af systemet og arkitekturen skriver Accenture blandt andet:

‘Omfanget af systemet, som det oprindeligt blev præsenteret, ville uden simplificering formentlig have krævet, at man udviklede ét af verdens mest komplekse systemer til offentlig gældsinddrivelse. […]

Fleksibilitet regnes normalt ikke for et systemarkitektonisk princip og er i strid med flere gængse principper som KISS og YAGNI (You Aren’t Going to Need It).«

Med andre ord bad Skat om et it-system, som skulle være komplekst og samtidig fleksibelt. Det var to hovedingredienser i den cocktail, der fik EFI-systemet til at løbe af sporet.

Ingen kravspecifikation

Rent teknisk er det imidlertid også gået galt i implementeringen af systemet. Det kan spores tilbage til kravspecifikationen, som ifølge Accentures vurdering er formuleret i alt for generelle vendinger.

Kravspecifikationen bestod af cirka 400 krav samt 700 siders beskrivelser af brugsscenarier. For et projekt af denne størrelse vil der normalt være cirka 5.000 krav, vurderer Accenture ud fra den behovsanalyse, der blev lavet.

Da der ikke var formuleret konkrete krav, var det ikke muligt at fastslå, om systemet gjorde det, det skulle.

»Der var ikke nogen kravspecifikation, så der var ikke noget at teste ud fra,« siger professor Søren Lauesen fra IT-Universitetet.

Det betød også, at det reelt ikke er muligt på noget tidspunkt at sige, om EFI er færdigt. Da systemet blev sat i drift, havde det desuden kun bestået cirka 80 procent af de test, der var defineret.

De ansvarlige for EFI-systemet blev ifølge Accenture-rapporten advaret om, at EFI ikke var gennemtestet i 2012 og 2013 forud for idriftsættelsen.

Der var ellers afsat mellem 30 og 40 millioner kroner til et testmiljø for systemet.

KMD var hovedleverandør på udviklingen af EFI-systemet, men Accenture-rapporten slår fast, at EFI er så afhængigt af et andet system hos Skat, Debitormotor (DMI), at de to reelt bør betragtes som ét system.

Det ene kan ikke fungere uden det andet. Skat valgte imidlertid at udvikle de to systemer hver for sig og efter en forskudt tidsplan.

Unormal arbejdsdeling

»Det er unormalt, at man fordeler et system mellem to leverandører. Skat troede, de kunne undgå at slås med ét monopol, men det er værre at være i kløerne på to monopoler end på ét,« siger Søren Lauesen.

CSC var leverandør på DMI, og KMD og CSC skulle således samarbejde om at få de to systemer til at arbejde sammen. Den proces viste sig at tage længere tid og kræve flere tilrettelser, end den første tidsplan tog hensyn til.

Læs også: CSC misinformerede Skatteministeriet om forsinkelse af skandaleramt it-system

I stedet for at definere en grænseflade for kommunikation fra ét system til et andet blev de to systemer bundet sammen via en Serviceorienteret Arkitektur (SOA), men det er ifølge Søren Lauesen en anvendelse, som SOA er uegnet til.

Et af problemerne ved den uspecificerede grænseflade mellem de to dele af systemet var, at det var svært for henholdsvis CSC og KMD at teste, om deres implementering ville virke med den anden halvdel af systemet.

Derfor fik Skat kort sagt kun ulemperne og ingen af fordelene ved SOA ud af projektet.

Accenture-rapporten udpeger designfasen som dér, hvor problemerne begyndte for EFI. Ser man på selve de applikationer, der er kommet ud af det, så er kodekvaliteten generelt god.

Der er dog også steder i koden, som afspejler, at der var visse ting, udviklerne havde problemer med at få til at virke efter hensigten, hvilket kan ses i talrige ændringer og udkommenteringer.

Ingen test af data

Programkoden har også en lav kompleksitet, når man måler på den med gængse metoder til automatisk kodeanalyse. Men det kan ifølge Accenture skyldes, at der ikke var konkrete krav i kravspecifikationen, som kunne implementeres til eksempelvis validering af data i systemet.

Det viser sig også i praksis, hvor der efter import og senere input af data i systemet ikke har været validering af data. Derfor findes der nu data, som ikke stemmer overens, efter at EFI blev taget i brug i 2013. Systemet kan således også give problemer, når det får data ind.

Det skal kunne håndtere cirka 450 forskellige fordringstyper, som kan variere fra restskat til en regning for rude på en skole, der er baldret med en fodbold.

Derfor får EFI data fra mange forskellige myndigheder, og hvis data ikke er formateret korrekt, er det ikke sikkert, at systemet opdager fejlene.

Rapporten anviser ingen mirakelkur for Skat, der kan få EFI-systemet til at virke. Skat har måttet indstille brugen af systemet og overlade visse prioriterede inddrivelsesopgaver til manuel behandling, og det kan Skat blive nødt til at fortsætte med.

Læs også: 11 år og 1,5 mia. kr. spildt på it-problemer i Skat

Accenture anbefaler nemlig, at Skat undlader at bruge de dele af EFI, hvor der er konstateret problemer. Som en kortsigtet løsning vil det være muligt at reparere dele af EFI, men på længere sigt bør EFI og DMI udskiftes med et helt nyt system.

Samtidig bør der ifølge Accenture ske en forenkling af reglerne på området for at reducere kompleksiteten af et nyt system, ligesom Skat bør gennemgå hele organisationens it-arkitektur

Dokumentation: Pressemeddelelse med links til Accenture-rapporter

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (17)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#4 Malthe Borch

Har man virkelig kigget på samtlige af verdens nuværende IT-systemer for indrivelse af gæld? Hvordan måler man hvilket system er mest komplekst? Er det ikke bare endnu et pinligt og navlebeskuende forsøg på at gøre Danmark til centrum af verden?

Hvad gør man i vores nabolande? Hvorfor ikke give en sammenligning, e.g. tal for "kompleksitet", samlet pris etc.

  • 2
  • 0
#5 Bent Jensen

"Kravspecifikationen bestod af cirka 400 krav samt 700 siders beskrivelser af brugsscenarier. For et projekt af denne størrelse vil der normalt være cirka 5.000 krav, vurderer Accenture ud fra den behovsanalyse, der blev lavet."

Ja, det havde nok hjulpet rigtig meget, hvis der havde været en kravspecifikation med 5000 krav istedet for 400?

Hvad med at prøve at bygge systemet i mindre bidder og sætte dem i drift en ad gangen?

Hvis man hurtigt fik et system, der kunne håndtere den type fordring der har størst økonomisk betydning f.eks restskat, ville man efter kort tid have en system, der rent faktisk tjente penge og kunne derfra udvide og forbedre systemet.

Men at nå frem til den konklusion kræver nok at man sætter nogle andre (og mere kompetente?) end Accenture til at vurdere forløbet.

  • 18
  • 0
#6 Thomas Hildebrandt

"ét af verdens mest komplekse systemer til offentlig gældsinddrivelse. […] Fleksibilitet regnes normalt ikke for et systemarkitektonisk princip og er i strid med flere gængse principper som KISS og YAGNI (You Aren’t Going to Need It).«

Siden hvornår er kompleksitet og fleksibilitet blevet lig med hinanden?

Keep It Simple Stupid er et fint princip - men det er ikke i modstrid med et fleksibelt system. YAGNI har også sin berettigelse til at udelade features der øger kompleksiteten, men ikke til at fravælge fleksibilitet og muligheden for at udbygge og tilpasse og validere systemer efter de er taget i brug.

Jeg er helt enig med Bent Jensen i, at 10 gange så mange krav ikke havde undgået nogle problemer (tværtimod) og at vejen frem er at stille krav til at få et system der kan implementeres og testes/valideres gradvist.

Det er muligt - men ikke ved at beskrive og implementere hundredevis af forretningsprocesser (som man forestiller sig de skal se ud) med den gængse teknologi, hvor det er så godt som umuligt at validere om processerne overholder regler eller er korrekte.

Det helt store mysterium er, hvorfor man ikke bruger eksperterne på landets universiteter INDEN det går galt, igen og igen.

  • 12
  • 0
#7 Anders Djursaa

Det virker som om der har været for mange teoretikere og for lidt praktisk erfaring i såvel planlægning som ledelse. Altså et simpelt underskud af håndværksmæssig dygtighed og erfaring. Herudover kan man gætte på at mange projektdeltagere også har begrænset deres ansvarsfølelse til egne revirer. Eks. er det jo en kardinalsynd at indlæse rådata uden at være sikre såvel format som integritet i processen. Gad vide hvordan en sådan beslutning er blevet truffet. For jeg har svært ved at tro at håndværkerne på gulvet ikke har udsendt advarsler til projektledelsen, i forbindelse med at de blev sat til at udføre noget så elementært klamphuggeri. At hele forretningsmodellen med udbud og vandfald under alle omstændigheder er meget betænkelig - er et helt overordnet problem - som blot gør fraværet af håndvæksmæssige dyder endnu værre

  • 9
  • 0
#9 Jørgen A Thomsen

En af grundene til dårlige IT-systemer er, at den unødvendigt komplekse forretningsgang, der over tiden er opbygget, forsøges implementeret ukritisk.

Vi skal lige have 117 rabatformer i stedet for 3, for firma XX plejer at få denne specielle rabat, som ingen andre ellers får. Vi forudsætter også i vores forretningsgang, at der er en person, der lige tager stilling og retter lidt til.

Man bør ALTID starte med at se på forretningen og forsimple og standardisere sine procedurer med åbent sind uden et 'sådan har vi altid gjort'.

Når det er gjort, kan man lave sig et billigere, simplere og vedligeholdelsesvenligt IT-system, som måske endda kan drage nytte af standardprodukter.

  • 5
  • 0
#10 Hanne Kristensen

Uden at negligere konkrete problemer forekommer det mig lidt mærkeligt at man ikke har lavet et system så delområder, f.eks. skyldig ejendomsskat, afleverer deres data med alle relevante beløb og tidsfrister til en database, og det nye i al væsentlighed er et collector system. Hvor alle delområder fungerer uafhængigt af hinanden og collector systemet ikke bliver det mest komplekse af alle systemer, men blot skal kunne håndtere et vist antal forskellige situationer.

  • 0
  • 0
#11 Peter Houmark-Nielsen

I 1980'erne lærte vi KISS: Keep It Simple, Stupid! - eller: Keep It Stupid Simple" og OBD= Obsolete When Debugged" og " Når du har rettet alle fejlene er systemet overkompliceret og fungerer ikke". I Statens Skatte Administration gælder åbenbart: Ikke lære af andre, ikke høre på andre og ikke kunne læse indenad.

  • 1
  • 1
#12 Frithiof Andreas Jensen

Det helt store mysterium er, hvorfor man ikke bruger eksperterne på landets universiteter INDEN det går galt, igen og igen.

Faglighed er ikke længere ønsket på "direktørgangen", der er jo i forvejen alt for meget friktion imellem fantasierne og virkeligheden til at man ligefrem også skal "til at regne på det" før man handler!

I dag siger regeringen ligefrem til eksperterne: "Tak for dit bidrag til debatten. For at vise vores taknemmelighed vil vi give dig en særlig præmie: En stor pose jord og en fodtur til Thyborøn eller Bornholm."

  • 4
  • 0
#13 Michael Cederberg

Jeg har ikke arbejdet med EFI og ved ikke noget om dets struktur. Men dets tilblivelse nærmest sikrer at det er et elendigt system. Jeg har nu heller ikke den store tiltro til Accenture rapporten. Hvis man ser bort fra statisk kodeanalyse (som ikke siger særligt meget om den arkitektoniske kvalitet), så er det svært at se hvordan Accenture kan sige noget seriøst om systemet uden at have brugt meget lang tid på analyse. Min erfaring siger at det tager lang tid at forstå store systemer - både at se deres kvaliteter men også at forstå hvor det er gået helt galt.

Hvis Accenture foreslår at der laves ca. 5000 krav (for at håndtere alle behovskrav), så er de galt afmarcheret. Men jeg er ikke sikker på at det er det de skriver. Måske mener de blot at hvis man skulle have lavet en fuld kravspecifikation, så ville den skulle være så stor. Ikke at man skal lave sådan en. Anyway, konklusionen i Accenture rapporten virker som bestilt arbejde.

EFI skal løse en kompliceret opgave - derfor vil systemet også til en vis grad blive kompliceret.

Selvfølgeligt skal man simplificere reglerne. Men hvis man ønsker et system der håndterer alle det offentliges fordringer - og det giver umiddelbart masser af mening - så vil der være en del forskellige regler. At forestille sig at man hurtigt kan aligne typer af fordringer fra alverdens offentlige myndigheder viser blot at man aldrig har arbejdet med forretningskrav.

Så kompleksiteten må vi leve med. Fejlen er i mine øjne hvordan man har håndteret kompleksiteten. Man har, sikkert i et forfejlet forsøg på at reducere budget risikoen, udbudt en samlet løsning. Problemet er at ingen kan stille alle krav til den samlede løsning up-front. Og at få, hvis nogen, kan lave et perfekt komplet system design up-front. Ovenpå kommet så ændringer i kravene undervejs.

At bygge den slags systemer er ikke nemt. Selv med de bedste folk går det nogen gange galt. Min opskrift er:

  • Ansæt nogle arkitekter der skal være med i hele processen. Nogle der er med i laaaang tid.
  • Brug tid på at disse arkitekter forstår forretningsgangene. Ikke de enkelte krav - det overordnede.
  • Lav et overordnet løsningsdesign.
  • Diskuter nu krav med de forskellige forretningsområder. Sørg for at alle krav kan håndteres i det overordnede design. Peg ud steder hvor der er problemer - diskuter om der kan files på kravene eller om det overordnede design skal ændres.
  • Udvælg et minimum at funktionalitet til at der haves en brugbar løsning for en eller få brugere.
  • Lav detaljeret design for ovenstående. Estimer, lav budget, plan etc.
  • Byg det.
  • Revider det overordnede design.
  • Repeat. Når man først er i gang kan delopgaver uddelegeres til andre teams (helst inhouse, evt. udenfor).

Ovenstående er agilt (selvom jeg ved nogen mener jeg laver for meget planlægning i starten). Det er svært at forudsige den samlede omkostning - men vis mig en metode der giver gode estimater for omkostninger for store projekter.

  • 1
  • 0
#15 Benjamin Balder

Man sætter konkurrenten til at skrive en rapport om, hvorfor KMD fejlede? Flot. Det ender meget forudsigeligt som en fin reklame for Accenture. Ikke overraskende, at rapporten leveres i en massiv Accenture branding forside -- "High Performance. Delivered". Bah.

Accenture har brugt en masse tid og dermed tjent en masse penge på ligegyldig kildekodeanalyse, som de fastslår ikke er i overensstemmelse med et eller andet SAP-princip. Forudsigeligt.

Projektet var for komplekst? Forudsigeligt.

Funktionaliteter, der ikke virkede? Det vidste SKAT allerede.

Det overraskende er så: De skriver konklusionen alt for blidt. Hvorfor? Fordi de skal forsvare deres egne praksisser, som er li'så stupide som KMDs.

Derfor foreslår de 5000 krav i specifikationen. Ikke fordi det ville give et bedre skatte-indrivelsessystem.

Det er ekstremt skuffende, at man ikke efter 1,5 mia. er spildt på EFI, kan finde ud af at konkludere, at man skal stoppe med de her giga-projekter.

Det ville en IT Havarikommission skulle være i stand til at konkludere. Det er derfor, vi mangler den.

  • 2
  • 0
#16 Tobias Tobiasen

Så alene det at splitte systemet op i mindre dele ville betyde, at man ikke skulle levere dækkende krav? Godaw ...

Det vil betyde at man ikke skulle levere dækkende krav til alle arbejdsgange inden man går i gang. Man kunne udvælge nogle få områder at starte med og så sikre sig de virker inden man tager næste område.

På sigt når man er kommet i gennem alle områder så har man lavet dækkende krav for alt. Fordelen er at man har haft et virkende system imens det stod på. Mindre risiko og bedre system. Om jeg fatter hvorfor det er så svært.

  • 1
  • 0
#17 Donald Axel

Jeg tror ikke at Accenture's konklusion er "bestilt", men nok at den er forudset og at man har fået et "slag på tasken" ved de første møder og gennemgang af historien, og ud fra Accentures fem rapporter (som jeg har læst en del af) skønner jeg at Accenture er blevet oprigtigt forbavsede over to ting: Leverandørernes håndtering af dokumentation og processen omkring data-migration alias data-integritet + "cleaning" eller normalisering. Jeg gætter ud fra hvad jeg har læst at den oprindelige specifikation var baseret på et "logik-system" eller data-drevet "motor" system, deraf navnet "debitormotor", hvilket omsat til normalt fagsprog betyder en logik-programmering, som ud fra regler i databaseform skulle være i stand til at danne det rette output til en automatisk inddrivelse - og selvfølgelig dokumentation til overvågning af ganske få sagsbehandlere. Det var "drømmen" at man skulle angive en gældstype, og dertil hørte så sags-trin, som "logikken" automatisk skulle kunne følge. Jeg tror at den misforståelse hænger sammen med myten om "computer-intelligens", betegnelser og forskningsområder som "kunstig intelligens". Og som andre kommentarer gør opmærksom på har "direktørerne" kun haft foragt for fagfolks advarsler (der var advarsler 2009, 2011 og igen senere.)

Jeg mener at der er nogle flere dokumenter, som er offentligt tilgængelige og håber at kunne få lidt mere indblik. Jeg har skrevet en artikel ud fra hvad jeg indtil nu havde (og den er udgivet i foreningsblad) men man bør gå videre, offentligheden skal have indsigt. Denne skandale har lighedspunkter med VW skandalens blålys-som-erstatning-for-faglig-kvalitet.

  • 1
  • 0
Log ind eller Opret konto for at kommentere