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

Illustration: REDPIXEL.PL/Bigstock
Skats direktør erkender, at vandfaldsmodellen er problematisk, men påpeger samtidig, at Skat har været fanget i en forældet tankegang.

Vandfaldsmodellen får en del af skylden for de store offentlige it-skandaler, fordi den ikke giver mulighed for at gå tilbage og prøve en ny tilgang, hvis en del af projektet viser sig at volde problemer. Modellen har været brugt i store projekter som eksempelvis Skats EFI-system, der endte med aldrig at komme til at virke.

Derfor erkender Skats direktør Jesper Rønnow Simonsen da også, 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,« udtaler Jesper Rønnow Simonsen i et skriftligt svar til Version2.

Udtalelsen er et svar på en del af den kritik, som tidligere it-arkitekt på EFI-systemet, Kristian Mandrup, har fremsat på Version2.

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

EFI-systemet var en del af en omfattende systemmodernisering, der blev planlagt i årevis og iværksat i 2006. EFI skulle således spille sammen med flere andre planlagte systemer, herunder det såkaldte Debitormotorsystem, DMI. Systemerne blev udviklet af forskellige leverandører, og det viste sig sent i forløbet, at det var sværere end ventet at få de to systemer til at arbejde sammen.

Læs også: Derfor gik det galt for EFI-systemet

Systemmoderniseringen var imidlertid planlagt efter vandfaldsmodellen med forskellige fastlagte etaper, budgetter og mål. Projekterne blev forsinkede, og eksterne konsulenter advarede om, at der var høj risiko forbundet med projekterne.

Læs også: Skats øverste chef blev advaret om mangler i EFI-systemet

Alligevel vurderede Skat, at det ville være muligt at nå i mål, selvom tidsplanen og budgetterne var overskredet. Det var først, da systemet blev taget i brug, at det for alvor viste sig, at der var alvorlige fejl i de beregninger, systemet foretog, som blandt andet indebar, at det ikke håndterede forældelsesfrister korrekt.

Derfor blev systemet taget ud af drift igen, og efterfølgende konkluderede nye konsulentrapporter, at det ikke ville være hensigtsmæssigt at prøve at få det leverede system til at virke efter hensigten på grund af den grundlæggende arkitektur, der var blevet fastlagt helt tilbage i udarbejdelsen af udbud og kravspecifikation.

Læs også: Accenture om EFI: Kildekode under niveau og i strid med SAP-anbefalinger

Nu skal der udvikles et helt nyt system, der skal varetage de opgaver, EFI skulle have klaret, som i dag er overtaget af manuelle processer hos Skat.

Kritikere som Kristian Mandrup mener, at hvis man havde benyttet sig af agil udvikling, ville det have været muligt tidligere i forløbet at opdage problemerne med arkitekturen og lave den om.

I dette tilfælde var leverandørerne og Skat bundet af kravspecifikationen og kontrakten. Problemerne fortsatte også, selvom der undervejs blev udskiftet leverandører på projektet.

Det offentlige er siden kontrakterne om EFI blev indgået blevet mere åbne over for kontrakter, der giver mulighed for agile udviklingsprocesser. Samtidig har blandt andet Skat benyttet sig af muligheden for at lukke projekter, før de var afsluttet, hvis de så ud til ikke at kunne nå i mål.

Læs også: Flere offentlige it-projekter overholder budgettet - ved at stoppe i tide

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

Vandfaldsmodellen er da glimrende til visse IT projekter....

Har man skidt som input så vil man også altid få skidt som output - uanset model.

Man kan måske få wakeup kaldet lidt tidligere med AGIL - men om det gør at man reagerer/ændre inputtet i SKAT det tvivler jeg på....

  • 9
  • 2
Henrik Hansen

Året var 1970. I August måned publiceres det oprindelige dokument, hvor Dr. Royce beskriver "vandfaldsmodellen" for første gang i verdenshistorien. Allerede på 2. side beskriver Dr. Royce modellen sådan her:

"I believe in this concept, but the implementation described above is risky and invites failure."

-- Winston W. Royce

Check selv efter:
https://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf

  • 0
  • 0
Lars Pedersen

Øhh...gad du bare ikke læse resten af dokumentet eller passede det ikke så godt med den pointe du vil nå frem til?

Dr. Royce starter med at gøre opmærksom med visse problemer med fremgangsmåden og DEREFTER kommer han med forslag/løsninger til hvordan man kan minimere de problemer.

Jeg vil faktisk mene at den sidste model (figur 10) vil passe meget godt til (gen)udvikling af et stort offentligt IT-system.

Og jeg er 100% sikker på at der også er offentlige IT-projekter der er kørt agilt og med scrum der kommer til at fejle big-time. Når hverken chefer eller arkitekter har lyst til at indrømme at det er dem, der har ansvaret for fejl og mangler - og ikke nødvendigvis den udviklingsmodel der anvendes - så kommer vi ikke videre.

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