Skat håber ny arkitektur vil forhindre EFI-gentagelse

Ny it-arkitektur i Skat skal forhindre fremtidige skandaler. Men fastholder delvist den problematiske vandfaldsmodel.

Nu skal det være slut med bøvl og skandaler i Skats it. Dårlige historier, såsom EFI-systemet, skal forhindres af ny strategisk it-arkitektur.

EFI var Skats inddrivelsessystem, som blev sat i drift i 2013, seks år efter køreplanen, og skrottet delvist i september 2015 med en ny afløser ventende i kulissen til en pris på 1,1 mia. kroner.

Sådan en begmand skal ny arkitektur i det genfødte Skat være med til at sætte stopper for.

Det var budskabet, da Skats underdirektør med ansvar for teknologi, data og sikkerhed, Søren Ilsøe Overgaard, talte om sagen på den fællesoffentlige arkitektur-dag på Crowne Plaza-hotellet i ørestadskvarteret ved København.

Læs også: Nyt system til 1,1 milliarder er ikke meget bedre end EFI

Grundlaget for den nye arkitektur er et opgør med silo-tænkningen. Det skal være slut med data, som ikke kan snakke sammen. I stedet skal en fælles databank være det fundament, som Skats enkelte tjenester kan stikke snablen ned i.

Ja: Arkitektur kan forhindre nye skandaler

På Version2’s spørgsmål om, hvorvidt det fælles datagrundlag er det, der skal til for at undgå fremtidige EFI’er, svarer Søren Ilsøe Overgaard:

»Jeg blev spurgt af Skats direktion, om jeg kunne stå i spidsen for EFI-analyserne, så jeg synes, jeg har indsigt i det. EFI har også været en ordentlig mundfuld. Det var et udtryk for en strategi, man så i mange virksomheder i 00’erne, hvor man ville opbygge en konsolideret funktionalitet i store system-organismer. Vi vil en anden tilgang, så ja, det mener jeg er svaret.«

Han peger på, at det nye såkaldte ICI-inddrivelsessystem allerede er i gang. Det er et af de første projekter under den nye arkitektur.

Strategisk it-arkitektur skal forhindre nye skandaler, håber underdirektør i Skat Søren Ilsøe Overgaard. Illustration: Tania Andersen

»De første 1.000 kroner er i kassen, og så står folk og kigger lidt – for var det ikke 100 mia., der var i restancer? Vi er nødt til at få hul igennem til systemet og arbejde agilt mod et mål og så skalere op.«

For én af tilhørerne i salen, som Version2 senere har været i forbindelse med, er budskabet ikke ligefrem noget chok:

»Han fremlagde nogle slides, som nogle konsulenter har forsynet ham med, og sagde, at ‘sådan vil vi gøre.’ Der er for mig at se ikke noget forkert i at ville have styr på organisationens fælles datagrundlag. Powerpoints er taknemmelige ... Noget andet er, om Skat kan gennemføre det i praksis. Det finder vi ud af,« lyder dommen.

Fastholder delvis vandfald

Et af problemerne med EFI var blandt andet brugen af den såkaldte vandfaldsmodel, hvor et it-projekt planlægges med faser langs en tidslinje – en metodik, som er stærkt kritiseret for ikke at være hensigtsmæssig i forbindelse med it-udvikling.

Skats tidligere direktør Jesper Rønnow Simonsen pegede da også sidste år på, at modellen er problematisk:

»Vi har for længst taget til os, at vandfaldsmodellen ikke er måden at lave it-systemer på. Men Skat har i visse tilfælde desværre været tynget af sin arv og fanget af en forældet tankegang,« udtalte Jesper Rønnow Simonsen til Version2 i juli sidste år.

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

Men Skat holder stadig fast i modellen, i hvert fald delvist, forklarer Søren Ilsøe Overgaard, da Version2 rejser spørgsmålet:

»Vi arbejder stadig med ‘mixed sourcing’ og kigger på, hvilken model vi skal bruge til hvert enkelt projekt. Vi arbejder aktivt sammen med Digitaliseringsstyrelsen og bruger de råd, der er i forhold til forskellige udviklingsmetoder.«

I øjeblikket kigger Skat på at definere et sæt af udviklingsmetoder.

»Hvis folk siger agil udvikling – er det så bare at løbe ud over stepperne og sige ‘nul dokumentation’? Det tror jeg ikke, vi mener i Skat. Der mener vi, at man har en fælles retning og et fælles mål, man gerne vil opnå. Så det er ikke sådan, at vandfaldsmodellen udgår, men vi må se i tilgangen til hvert projekt, hvad det egentlig er, vi vil opnå.«

Professor: Forebyg dødsårsagerne

It-professor Søren Lauesen fra IT-Universitetet i København bifalder de nye visioner og kommer med et godt råd til Skat i en mail til Version2:

»Der er mange gode tanker om den tekniske arkitektur. Specielt er det godt at høre, at man vil tage ansvar for data og centralisere det mere. Det har STAR (Styrelsen for Arbejdsmarked og Rekruttering) gjort med succes i flere år. Det er også fint at ville sætte systemerne i drift lidt ad gangen.«

Han peger dog på behovet for indsamling af erfaringer.

»Det er godt at ville undersøge, hvad der gik galt i tidligere systemer, men hvorfor bruger man ikke eksisterende, forskningsbaseret viden? Jeg har selv undersøgt, hvad der gik galt i fem store offentlige IT-systemer, og fandt 36 årsager. Inddrivelsessystemet EFI led af 16 af dem. Kun halvdelen af disse årsager er velkendte.«

Endelig har Søren Lauesen ikke fuldstændig tillid til Digitaliseringsstyrelsens viden på området.

»Jeg har også fundet 20 behandlinger, der kan forebygge problemerne, men kun halvdelen er velkendte. Hvis man spørger Digitaliseringsstyrelsen til råds, tror jeg ikke, man får den anden halvdel med, og så får man ikke forebygget mange af de andre dødsårsager.«

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (7)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Anders Frandsen

»Hvis folk siger agil udvikling – er det så bare at løbe ud over stepperne og sige ‘nul dokumentation’?

Det virker som om man slet ikke har forstået hvad det drejer sig om. Agilitet handler ikke om mangel på dokumentation, snarere tværtimod - jo mere der dokumenteres, jo nemmere er det ofte at være agil.

Men hvis hele den her plan bygger ovenpå det whitepaper jeg så tidligere på året om offentlig IT-arkitektur, så forstår jeg godt hvorfor man ikke har noget konkret endnu. Det handlede udelukkende om at forsøge at give organisatorisk plads til at bryde nogen silovægge ned, ikke det mindste om IT arkitektur.

  • 8
  • 0
Flemming Riis

http://www.business.dk/oekonomi/ny-rapport-system-fra-skat-var-spaekket-...

Det fremgår af rapporten fra IT-Universitetet, at udviklerne af EFI-systemet nåede frem til, at der er omkring 500 forskellige former for gæld. Dette tal blev skåret ned til 400 ved at »bøje regler og praksis en smule«. Men kompleksiteten bliver kun tungere herfra. Det blev analyseret, at der for hver type af gæld kunne gælde 700 forskellige regler.

Det må kunne laves mere simpelt , og derved nemmere it systemer

  • 6
  • 0
Morten Toudahl

Hvis man ikke helt forstår the agile manifesto, så er det nærliggende at komme til den konklusion at man ikke længere skal dokumentere.

Men man kunne jo også bruge en af de mere dokumentations tunge processer, f.eks unified process.
Der svømmer man i artifacts.

  • 0
  • 0
Martin Neiiendam

For mig lyder det som om det i første omgang er indstillingen til IT der er ændret. - Og det er første skridt.

Det nytter ikke noget at indføre agile metoder, hvis ledelsen ikke står på mål for dem. Det lyder som om ledelsen har fået en mere moderne holdning til IT.

Jeg er meget spændt på hvad vi kommer til at høre om Skat de næste par år.

Og helt sikkert, - Skat ligger under for at skulle implementere et så kompliceret regelsæt, at der næsten er garanti for at opstå fejl. Sammenholdt med hvor ofte politikerne tilføjer/ændrer regler for fradrag/skatter/afgifter, giver det rigtig god mening at vandfalds-modellen er "problematisk".

  • 1
  • 0
Peter Rosenberg

lade agiliteten ligge de mange opkrævningsformer (500+) ?
Jeg mener lad systemet starte med antagelsen om: Der vil komme mange og de vil være komplekse, men start med de simple og især dem der giver hurtigst afkast i Statskassen.
Så kan et fleksibelt (læg mærke til jeg ikke kalder det agilt) system, udvikle sig over tid til e forskellige Scrum leverancer.

  • 2
  • 0
Knud Larsen

Men når det er sagt, fører det naturligt til, at det er Folketinget, der skal ændre adfærd.
- Hver ny lov skal checkes op mod det eksisterende lovsæt og den skal kun indføres dersom, der kan fjernes mindst dobbelt så mange elementer som der indføres. helst skal det kun være parameteren [typisk skatteprocenten] der ændres.
- Loven skal formuleres logisk i beslutningsdiagram - kan det ikke lade sig gøre, skal det slet ikke lovgives.
- Hvis det kræver nye cirkulærer og bekendtgørelse skal der sættes midler og tid af til at gennemføre implementeringen. Vi ser jo at administrationen slet ikke kan/vil følge med. Eks. en særlig pris/præmie blev ikke beskattet som særlig indkomst trods det at bestemmelsen havde været gældende i mere end 20 år og såmænd var omtalt i den lille gode håndbog 'Skatten'. Det siger noget om hvor laaaang tid et tager at implementere ændringer og forstå dem.

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