1.885 sider: Her er kravspecifikationen for Skats fejlslagne EFI-system

Illustration: REDPIXEL.PL/Bigstock
Version2 har fået aktindsigt i kravspecifikationen for EFI og inviterer nu læserne til at hjælpe med, om kravspecifikationen burde have tændt nogen advarselslamper.

Hvorfor gik det galt for Skats EFI-system til inddrivelse af gæld?

Det er ikke sikkert, vi nogensinde får en klar redegørelse, som gør os i stand til at undgå at gentage de samme fejl, men der var meget der tydede på, at projektet allerede var på vej mod en katastrofe, inden der blev skrevet under på kontrakten.

Version2 har efter et mere end ét år langt forløb fået aktindsigt i kravspecifikationen for Skats system til gældsinddrivelse, EFI, og søstersystemet DMI (Debitormotor Ind).

Kravspecifikationerne er ikke det første spor. Kravspecifikationerne blev nemlig udfærdiget på baggrund af en overordnet it-strategi om at bruge Service Orienteret Arkitektur, som også kom til at udmønte sig i Den Fællesoffentlige ESDH kravspecifikation i 2009.

Men kravspecifikationen, som den så ud ved udbuddet i 2007, giver os muligvis et indblik i, hvorfor et projekt af denne størrelse løb ind i enorme problemer.

Det fremgår eksempelvis af kravspecifikationen, at udviklingen skal ske i faser, og Skat skal godkende dét, der er afleveret efter hver fase. Med andre ord en klassisk vandfaldsmodel, som tidligere er blevet kritiseret af en af arkitekterne på systemet, og som Skats tidligere direktør også har erkendt problemerne ved.

Læs også: Skat-direktør: Vandfaldsmodellen er ikke måden at lave it-systemer på

Læs også: Arkitekt på Skats EFI-system: Vandfaldsmodel skabte falsk tryghed

Forkert håndtering af forældelsesfrister

EFI-systemet blev i modsætning til et par tidligere af de store offentlige it-skandaler ikke stoppet, fordi systemet havde lange svartider. Det blev stoppet, fordi det blandt andet håndterede forældelsesfrister forkert.

Læser man bilaget om Regler i kravspecifikationen, så er der måske en indikation af, hvor svær en opgave det har været at tolke forældelsesreglerne korrekt for et system, der skulle håndtere hundredvis af use cases:

»En fordring forældes som hovedregel efter 3 år, men kan afbrydes ved at der foretages forældelsesafbrydende skridt, som fx et udlæg.«

»Forældelsens starttidspunkt regnes fra fordringens sidste rettidige betalingstidspunkt. Dette gælder både den 3 årige og den 10 årige forældelse. På personskade og miljøskade er der dog 30 års forældelse.«

Derefter følger blandt andet 10 punkter med grunde til at afbryde forældelsesfristen og afsnit om særlige 1-årige frister. Og selvom der står, at forældelsesfristerne som regel er 3 eller 10 år, så følger der kort efter afsnit om både 1-årige og 5-årige frister.

Samme dokument indeholder eksempelvis også afsnit om regler for bodeling, og her er der tale om de juridiske beskrivelser. Der er altså ikke tale om en beskrivelse af, hvad systemet skal gøre.

Næsten umulig opgave

Målet med kravspecifikationen var at få udarbejdet en systembeskrivelse som afslutning på designfasen. Det var et krav, at systembeskrivelsen skulle følge samme logik som kravspecifikationen.

Når man som lægmand læser kravspecifikationen inklusive Skats bilag, så fremstår det som en stor opgave alene at udrede, hvad det i virkeligheden er for et system, Skat vil have bygget. Og det fremstår ligeledes som en næsten umulig opgave for Skat efterfølgende at finde ud af, om denne systembeskrivelse ville beskrive et fungerende, lovligt system.

Det er derfor, at Version2 nu inviterer læserne til at se nærmere på kravspecifikationen for EFI. Vi har muligheden for at være bagkloge og måske undgå en gentagelse.

Skiller den sig ud fra andre store it-projekter? Hvordan fungerer den som udgangspunkt for en analyse- og designfase?

Kravspecifikationen for EFI - marts 2007.

Skriv i debatten herunder eller på redaktion@version2.dk

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (25)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Anne-Marie Krogsbøll

Selv en amatør virker det tydeligt ud fra de i artiklen refererede eksempler, at det må være et meget svært system at få skruet sammen på forsvarlig måde. Det rejser så det nye spørgsmål, hvem det er, der har bildt ledelsen og politikerne ind, at det kunne lade sig gøre?

  • 13
  • 1
Michael Fjeldsted

... indtil lovgivningen er klargjort hertil.

Så længe man har en kompleks lovgivning vil IT-systemer have det meget svært ved at håndtere alle tænkelige usecases og fejl vil helt sikkert opstå. At man udvikler på en ny og mere agil måde, vil ikke afhjælpe kompleksiteten, selvom det helt sikkert vil hjælpe en hel del.

  • 11
  • 1
Martin Kirk

Hvis alle processer i systemet er klarlagt og forståelige, så kan det ikke være svært at implementere ...

kan der være tale om et af følgende:

  • inkompetence hos leverandøren ?
  • for få midler eller tid til at færdiggøre projektet ?
  • at kunden (SKAT) ændre krav undervejs ?
  • at kunden (SKAT) ikke vidste præcis hvad de ville have ?
  • 0
  • 12
Martin Kirk

Mon ikke det er her, det kniber?

Jo måske, men med 1885 sider må det da være lykkedes at forklare hvordan pengene flyder rundt og reglerne omkring det.

jeg nægter at tro på at man ikke undervejs har kunnet spørge de relevante mennesker om ting som mangler i kravspec
(hvis det alligevel er tilfældet, så kan jeg godt se hvorfor det hele falder sammen)

  • 1
  • 11
Martin Rud

Hvis alle processer i systemet er klarlagt og forståelige, så kan det ikke være svært at implementere ...

Jeg vil sige, at det netop er med til at gøre det svært. Med 1885 sider "klarlægning" tror jeg ikke, at der er nogle enkeltpersoner, der kan overskue, hvad løsningen skal gøre.

Opgaven burde nok have været beskrevet på langt færre sider, og så kunne man i iterationer undervejs i projektet detailbeskrive del-opgaverne.

  • 13
  • 0
martin nielsen

Start med at lave en analyse af den eksisterende arbejdsbyrde.

Find de top 1% af opgaver der tager flest mandetimer at udføre.

Beskriv disse opgaver som processer i form af input og output - hvor kommer dataen fra, og hvordan skal dataen se ud når den forlader processen, præcis som det fungerer i dag. Sæt enginiørerne sammen med den eller de personer der tidligere har varetaget processen, og lad dem sammen komme frem til en forbedret process, i stedet for at levere en kravsspecifikation, der ikke kan omdannes til et computerprogram, fordi den er beskrevet på en unaturligt kompleks facon der forsøger at redegøre alle både gyldige og ikke gyldige scenarier. De folk der førhen har stået for opgaven er nu kun nødt til at håndtere de obskure scenarier som er unødvendigt svære at programmere sig ud af, samt er sjældne og ikke bør være en del af første iteration.

Automatiser opgaverne.

Gentag processen.

De offentlige institutioner bliver ved med gang på gang at automatisere alting på én gang. De prøver at erstatte alt for mange systemer og tiltag på en gang, og de benytter sig ikke af de ressourcer de allerede har, i form af folk der har arbejdet med de eksisterende processer de sidste 30+ år.

I stedet bør de fokusere på at automatisere og effiktivisere de processer der eksisterer allerede, og som gradvist vil forbedre det eksisterende system, i stedet for at prøve at erstatte det.

Med et system der opbygges modulært og i mindre bidder vil de i langt større grad opleve en mængde af små success historier, hver gang et nyt initiativ resulterer i en reducering af den eksisterende arbejdsbyrde, i stedet for store og katastrofale investeringer der vokser sig ud af proportioner og ender med at fylde kistebunden hos KMD, CSC, osv.

  • 25
  • 0
Flemming Kaa Madsen

Når man læser artiklen, får man næste lyst til at spørge, om det er den rigtige kravsspecifikation, I har fået udleveret. Men som systemet virker er det jo den rigtige.

Også hjælper ingen teknisk analyse, fordi det er en bevist handling (læs ”Mørkelygten” af Jesper Tynell) fra de ansvarlige (Anders Fogh, Lars Løkke, Claus Hjort, Kristian Jensen) at få skrevet et dokument, der sikrede at skattesystemet crashede på et eller andet tidspunkt. Når noget er crashet, er man jo nød til at lave det om.

Tag det lidt mere simple skatteproblem med boligskatten. Før Fogh/Løkke/Hjort/Jensen fremturede med deres ”skattestop på boliger”, havde man synsmænd til at gå rundt og vurdere, de klager der kom over værdisætningen af deres bolig. Disse synsmænd var lokale og kunne derfor tage alle de ting med i betragtning, der skulle tages med. Derfor var deres vurderingere præcise. De var ulønnede og dermed billige. Altså et billigt, præcist og effektivt system.

Disse synsmænd blev nedlagt i forbindelse med ”skattestoppet på boliger”, da der jo ikke var brug for dem, da skatten en gang for alle var blevet fastsat. Det selvom det ville være helt gratis at have dem til at stå stand by, til man på et eller andet tidspunkt igen ville få brug for at få vurderet boligpriser. Systemet kortsluttet og crashet.

I disse dage bruges det så til at sænke skatteprocenten på boliger til de facto 0,48%. (http://finans.dk/live/opinion/ECE9074509/faktorernes-orden-er-ligegyldig...). Dette begrundes i at men vil sikre sig mod usikre vurderinger. Lige præcist det resultat man fik ud af at nædlægge synsmandsordningen.

Denne skattesænkning giver den klart største besparelse i kroner og øre for dem i de største boliger/de rigeste. Det drejer sig om 100-vis af kroner for den fattige boligejer og 1000-vis af kroner for den enkelte rige og mia. for fælleskassen. (Hvis det nu var det politiske program man havde lagt frem var det en ærlig sag, men det er det som bekendt ikke.)

Derfor kommer man ike nogle vegne med/det giver ikke nogen mening at lave en teknisk analyse af kravspescifikationen til skattesystemet. Det er et politisk problem.

  • 13
  • 1
Martin Husted Hartvig

Dette er bare endnu et eksempel, hvor man tydelig kan se, at man ikke "bare" kan kalde på konsulenter. Mange steder kræves der simpelthen en domæne viden af udviklerne, og arkitekterne, som ikke bare kan opnås via en kravspec, men igennem et langt forløb i en branche. At man ansætter konsulenthuse til at løse opgavnerne istedet for at opbygge egen viden, er, for mig at se, en af de væsenlige årsager til de mange fejlslagende offentlige it projekter.

  • 19
  • 1
Jesper Frimann

Det her er vel bare det oprindelige udbud. Så det er jo ikke nødvendigvis, hvad der faktisk kom til at ske.

Men der er da sådan umiddelbart et par ting der springer i øjnene når man skimmer dokumenterne igennem.

1) Der er lagt op til at det er SKAT's projekt, og at 'leverandørene' er underleverandører.

2) Kvalitetsstyring er kun specificeret på leverandør niveau. Det vil sige at der er ikke beskrevet en kvalitetsstyrings model på tværs af 'projekter leveret af forskellige leverandører', altså 'SKAT's' egen kvalitets styring er ikke beskrevet, ud over den organisatoriske forankring. Det lugter lidt af at koordineringen mellem del projekter kommer så højt op i hierarkiet, at der er en fare for at den mere tekniske og praktiske koordinering ikke kommer til at ske. Og at der derfor er en fare for at delprojekter derfor ikke kommer til at 'passe sammen'.

3) Der er pænt strenge begrænsninger på i forhold til hvor meget leverandørerne kan trække på ekspertviden hos SKAT. Og set i lyset af hvordan vi har fået beskrevet at kompleksiteten viste sig at være væsentlig større end først antaget så ja er det da bekymrende.

Tja ja...

// Jesper

  • 9
  • 0
Martin Kirk

Enig !!!

Jeg så helst at SKAT ansatte en IT-udviklingsafdeling som fik opgaven at lave EFI ..

med alle de milliarder det koster at udvikle ku man snildt ansætte en hel masse som kunne få en grundig domæneviden..

  • 4
  • 0
Jesper Frimann

Opgaven burde nok have været beskrevet på langt færre sider, og så kunne man i iterationer undervejs i projektet detailbeskrive del-opgaverne.

Øh, jeg tror ikke rigtig du forstår kompleksiteten af det her. Hvad systemet sådan skal kunne, altså hvordan ser 'forretnings processerne' og usecases ud, der skal understøttes og implementeres ud, står jo ikke beskrevet i de her dokumenter.

De krav der er specificeret og som skal besvares, er sådan noget mere generelt.

Hvad der faktisk skal implementeres er som jeg forstår det beskrevet i Skats Metadata Repository. (Se appendix 22).

// Jesper

  • 5
  • 1
Morten Hansen

Hvis alle processer i systemet er klarlagt og forståelige, så kan det ikke være svært at implementere ...


Problemet var også at man helt til det sidste opdagede nye grene af inddrivelse, man ikke havde taget højde for. 11 år!
Uanset om det er en kompleks lovgivning og administration, har man valgt at bide over et enormt æble, i stedet for at dele de i små både.... men det er altid godt at være bagklog.
(Haverikonmision nu!)

  • 8
  • 0
Frithiof Andreas Jensen

Denne skattesænkning giver den klart største besparelse i kroner og øre for dem i de største boliger/de rigeste.


Det er nok en pointe, men jeg tror at man tänker "större" her.

En af de store tanker omkring "konkurrenceevnen" og "globaliseringen" er at alle lönninger skal presses ned til Nul og alle offentlige sociale sikkerhedsnet fjernes så "vi", d.v.s. KUN lönmodtagere kan få lov til at konkurrere på lige fod med 3'die verdens lön- og arbejdsforhold.

Det er jo så lidt muggent, hvis man også samtidigt gerne vil tage 1'ste verdens gebyrer, skatter, afgifter og priser for alting. Pengene skal jo komme et sted fra. Derfor puster man bevidst en boligboble op.

Midlerne kommer dermed ikke fra forbedrede lönninger, de kommer fra lån, gäld, primärt i boliger. "Väksten" stopper når boligerne ikke kan belånes yderligere, for eksempel hvis prisen på boliger ikke stiger. Derfor skal renten ned, beskatningen skal ned, vi skal have slappere kreditvurderinger, der skal "liberaliseres" så hvem som helst kan låne til hvad som helst og vi skal have placeret statskassen som bagstopper for den private gäld så ingen nogensinde behöver at tvivle om der er en god ide at låne penge ud, "tillid" tror jeg man kalder det.

Det er meget påfaldende at hver gang boligmarkedet kölede af i nullerne, så kom der lige en lånemulighed til for at hjälpe "väksten" på vej. Vi ser med boligbeskatningen at man er fanget mellem to onder, skatten kan ikke stige fordi så falder prisen på boliger, men, man kan heller ikke tillade at lave en reform der afspejler markedet fordi det ville give faldende indtägter til staten. Ingen kan låne mere, fordi alle er maxet ud, "väksten" er stendöd og vil våre det indtil gälden er afskrevet, men hvis det sker dör bankerne.

Selvskabte problemer er altid nästen ulöselige fordi begyndelsen på lösningen kräver at man ändrer sin måde at opfatte verden på - og så lige nu, hvor man er helt perfekt og verdens bedste til alting og kan köbe hele verden (på kredit, men det täller jo også lidt).

Så i stedet for pröver man at få regeringstiden til at gå med lidt klyt og småfusk indtil det hele er "oppositionens" problem og alting gentager sig.

  • 3
  • 1
Frithiof Andreas Jensen

Husk på at skattelovgivningen er så kompleks, at selv folk hos SKAT ikke altid selv kan forstå den og anvende den korrekt.


Feature != Bug. Lobbyisterne, som skrev lovgivningen, forstår nemlig deres del af den helt perfekt. Jo mere uforståelig lovgivning, desto bedre timelön giver det näste job som juridisk konsulent for skatteundragelse.

  • 3
  • 2
Michael thomsen

Nu er det vigtig at huske på, at dette var et nyt område, som skulle it-understøttes. Det betyder, at ansatte i en intern udviklingsorganisation ville have samme problem med manglende domæne-viden.
Reelt er problemet, at viden om den konkrete forvaltning af lov-komplekset var delt ud på mange forskellige personer (og lur mig om, der ikke også var forskellige måder at forvalte den samme lov på). Så første skridt i en digitalisering bør være at lave en samlet beskrivelse af forvaltningen. Hvis loven er passende stor er dette reelt en uoverkommelig opgave, da man skal identificere alle mulige situationer.

Så vi ender nok i den sædvanlige situation - gennemfør det i små overkommelige bidder - find de overskuelige tilfælde, digitaliser, få erfaring, brug erfaringen til at forstå mere komplicerede tilfælde - og gentag

  • 0
  • 1
René Nielsen

Jeg har ikke læst på EFI udbuddet, men de andre udbud fra Skat som jeg har været med i, fylder med bilag mere end 1.900 sider. Jeg ville nærmere sige omkring 10.000 -> 20.000 sider, men jeg ved det ikke for udbuddet var i 3 store flyttekasser med fyldte ringbind og ingen læste alt.

Og det som funktionelt skulle laves i ”det nye udbud” skulle matche det som ”man havde i dag”.

Sidste gang fik jeg løn (af en byder) for at læse de mange sider indenfor mit område og denne gang er det så uden løn – så det springer jeg over :-)

I mine øjne var ”det helt sort” at man gik efter en samlet løsning – med samtlige gældsformer/inddrivelse i et hug! Man burde havde lavet et skalerbart system hvori man udtog højest 10 gældsformer/inddrivelse ud af de ca. 400 gældsformer som der er i dag.

Derpå kunne man løbende tilslutte nye/ændrede gældsformer som ”bølger”.

Det er jo helt hen i skoven – at forstille sig et lovgivningsstop i den periode et EFI-system implementeres, men hvordan skal det ellers ske? Hvis politikkerne via deres ændrede skattelovgivning hele tiden ”flytter målstregen” på den funktionalitet som er aftestet og klar til produktion?

Problemet er bare, at det lyder udbuddet ikke på. Det lyder på et samlet system – med alle gældformer.

Herefter ”klapper man hælene sammen” og siger javel for du vinder ingen udbud på, at tilbyde noget andet end det udbuddet lyder på.

Og det var måske her man skulle starte – med IT kompetencer ansat i Skats udbudsafdeling?

  • 10
  • 0
Lars Pedersen

Skattelovgivningen er jo udformet af vores Folketing, det er et pragtfuldt værk som vore ledere har udbygget igennem generationer, og der er tænkt over hver eneste lille detalje. F.eks. er millimeterretfærdighed indbygget som en af grundpillerne under alle de tusinder af paragraffer. Det bør omtales med respekt.
Det er Danmarks stolthed, og faktisk alt for smukt til at det kan implementeres af almindelige programmører - der skal genier til! Glem bare alt om at ændre et komma i dette pragtværk - det er perfekt og evigt.

  • 2
  • 0
Peter Valdemar Mørch

Jeg synes at huske at have læst i en anden tråd herinde, at der var ca. 200 nye tilføjelser til disse regler om året. Og aldrig nogen gamle regler som helt bliver fjernet, for i fortiden gælder de gamle regler stadig.

Kombinationsmulighederne er derfor astronomiske.

En ny regel pr. arbejdsdag i snit i al fremtid gør sådan et system umuligt at implementere.

Kald det juridisk denial-of-service.

Velsagtens også umuligt for mennesker at administrere 100% korrekt i alle tilfælde. Og når fejl opdages i en manuel proces, laves afgørelserne bare om pr. sag manuelt fordi nogen brokker sig i enkeltsager. Det er ikke muligt for et program. Her skal alle tests virke efter hver ændring.

Jeg er ikke sikker på sådan et system overhovedet kan lade sig gøre at implementere og vedligeholde - ikke engang i udviklingstiden.

  • 4
  • 0
Lars Christensen

Jeg er helt enig - 1.900 sider er i bedste fald kun til overskrifterne for hvert enkelt udviklingstrin indenfor hvert enkelt emne.
Som eksempel kan jeg oplyse at kravspec'en til vores landmine detektor projekt fylder ca det dobbelte - og dette projekt koster 1/100 del af EFI og er langt mindre kompliceret.
Vi snakker sørme så meget om hvor gode vi er til at forstå og bruge it - men det kniber sandelig med at oversætte ønskerne til faktuel data som kan benyttes til andet end øregas

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