Offentlig digitalisering: Læringen fra EFI

Der er mange gode grunde til at IT-løsningen EFI ikke viste sig at blive en succes for det digitale Danmark. Dette blogindlæg vil omhandle, hvordan de forskellige problemstillinger ved udviklingen og implementeringen af EFI har påvirket at SKAT i sidste ende måtte nødt til at droppe IT-løsningen bag EFI helt.

Problemstillingerne

Nedenfor findes oversigten over problemstillinger der har påvirket udviklingen og sidenhen dokumentationen af EFI:

  1. Manglende indsigt i forretningsprocessen for inddrivelse af gæld til det offentlige. Herunder manglende viden om forretningsprocessens kompleksitet.
  2. Hyppige udskiftninger i projektets styregruppe.
  3. Ændringer i tidsplanen for implementeringen af projektet.
  4. Anvendelse af mange forskelligartede leverandører, og manglende evne til at håndterer dem.
  5. “The Magic Dust of SOA” syndrom.
  6. Den forkerte styregruppe til at styre projektet p.g.a manglende om processen.
  7. Manglende evne (læs som mod) i organisationen til at stoppe projektet.
  8. Anvendelse af grønthøster metoden.
  9. Manglende kendskab til forretningsmodellen og et krav om standard systemer til en organisation der vitterlig er unik.
  10. Fanget mellem monopoler.

De ovenstående problemstillinger påvirkede udviklingen af EFI og ikke mindst implementeringen, det vil  sig det der skulle understøtte at SKAT ville kunne få de gevinster ved projektet der egentlig blev efterspurgt, da projektets business case blev udarbejdet.

Forretningskendskabet

Danmark er på mange måder et dejligt sted at bo, men på trods af den demokratiske styreform og en række ønsker blandt de demokratisk valgte beslutningstagere og ministre, så har man som nation desværre ikke oplevet at den dertilhørende skattelovgivning på noget tidspunkt tog udgangspunkt i at honorere behovet for finansiering og samtidigt gøre det nemt for skatteborgerne, organisationer og virksomheder at betale den korrekte skat. Dette er blandt andet kommet til udtryk ved at SKAT notorisk henviser til at deres rådgivning af skatteborgere, organisationer og virksomheder kun er vejledende, og for at opnå klarhed så skal revisorer med flere engageres. Dermed sagt så findes der en kultur og en lovgivningsgrundlag der har gjort rådgivning om skat til en profitabel industri af den grund at skattelovgivningen og lovgivningen om inddrivelse af gæld til den offentlige sektor også er kompliceret.

Komplicerede processer er ikke nødvendigvis gode processer at digitalisere med henblik på automatisering og straksafgørelser. Det viste sig i forhold til EFI, at forretningsprocessen var for kompliceret og specifikationen af det dertilhørende system ikke tog højde for dette, hvilket ledte til en række ressourcer blev anvendt til afklaringer uden egentlige resultater og systemudviklingen blev påbegyndt uden afklaringen til at styre udviklingen ud fra.

Det magiske SOA-støv

Der findes en række udfordringer ved at organisationer går i gang med implementering af et SOA-program (en række projekter). Ifølge redegørelsen fra Skatteministeriet så anvendte SKAT en strategi kaldet “SKAT – Connect” som essentielt set omhandlende at en lang række af “monolitterne” i SKATs omfangsrige systemlandskab skulle forbindes via en enterprise service bus (ESB) som ud fra det valgte designmønster skulle fungerer som et centralt komponent i SKAT. SKAT valgte dertil en model der var bygget op om Java som standard programmeringssprog og løbet af forskelligartede IT-udviklingsforløb har SKAT stillet krav om integration op imod den Java baserede platform.

Beslutningstagerne i SKAT har antageligvis også haft en tilgang til implementering af IT-løsningen (som siden viste sig at være udviklet på SAP, som i øvrigt har sin egen integrationsplatform), at når bare den var bygget op om det nye integrationsparadigme, så ville verdenen være meget lysere, grønnere og bedre fordi integrationerne ville være nemmere og mere effektive at styre ud fra en central ESB.

I tilfældet med EFI, så virker det næsten som om, at  SKAT har flyttet et problemdomæne fra den “fysiske” verden og direkte ind i den “digitale” verden. Dermed sagt så har processen været for kompliceret allerede i den “fysiske” verden, hvortil man måske ukritisk har tænkt at alene SOAs magiske støv ramte IT-løsningen så ville alt blive bedre.

SKAT definerede selv snitfladerne mellem EFI og de omkringliggende systemer, men lod to store leverandører designe IT-løsningerne og bygge dem, men snitfladerne disse skulle kommunikere igennem var designet til andre formål dette viste sig at være en udfordring for SKAT og implementeringsprojektet, hvilket i sidste ende var med til at gøre EFI til et uoverskueligt projekt og en uoverskuelig IT-løsning.

Hyppige udskiftninger i styregruppen

Det fremgår at redegørelsen fra SKAT, at der også har været udskiftninger i styregruppen, og det kan også tolkes som at der har været for mange udskiftninger i styregruppen i den tid, hvor projektet er blevet udviklet. Dermed sagt så kan de personer der har haft en faglig relevant mening om implementeringen af EFI blevet udskiftet undervejs, hvor nye kræfter der blev introduceret til projektets sammenhæng ikke har forstået IT-løsningens kompleksitet eller forretningsprocessens kompleksitet. Dermed sagt så kan udskiftningerne i styregruppen ført til at projektet ikke blev realiseret.

Den forkerte styregruppe

Styregruppen havde ikke de nødvendige kompetencer set i forhold til at kunne håndterer udfordringerne med at de teknologier der blev anvendt i IT-løsningerne, og styregruppen havde heller ikke den fornødne indsigt i processernes kompleksitet, og dermed heller ikke en indsigt i, hvordan IT-løsningen reelt skulle understøtte de aktiviteter der skal til for at sagsbehandle inddrivelse af gæld.

Styregruppen havde ej heller indsigt om IT-løsningens design og om den egentlig ville understøtte dansk lovgivning.

Ændringer i tidsplanen

I løbet af projektet blev der foretaget store ændringer i tidsplanen, hvor flere leverancer skulle leveres på trods af ændringer i forretningsbehov og i ønsker til løsningen. Ændringerne medførte essentielt set at IT-løsningen ikke overholdte lovgivningen og ikke indeholdte den fornødne funktionalitet. Dermed sagt så findes der en række uhensigtsmæssigheder ved at de projekter der blev implementeret som en klynge og som havde klare afhængigheder til EFI ikke blev implementeret.

Standard systemer

Organisationer der ikke kender deres reelle forretningsbehov der skal honoreres ved implementering af IT-løsningerne kan bruge standard systemer og standard løsninger til at fungere som en dybere klarlægning af de egentlige behov, når standard systemerne bliver sat i drift. Disse løsninger virker som regel godt, når der er tale om behov for at kunne håndtere nogle opgavetyper der ofte finder sted i mange forskelligartede organisationer.

Unik forretningsmodel

Der findes ikke andre typer organisationer i Danmark som har samme forretningsmodel som SKAT. Forretningsmodellen er ligeledes lovbestemt, organisationen politisk styret og denne varierer i det store hele fra mange andre typer skattevæsner. I en rationel verden, hvor forretningsbehov skal diktere IT-løsninger, så vil det ikke give nogen form for strategisk fordel at arbejde med en model der understøtter standard systemer, da standard systemer i sin natur er udarbejdet til IT-løsninger der understøtter forretningsbehov som man oplever i mange forskelligartede typer virksomheder.

Manglende evne til at stoppe projektet

Trods der på papiret var gjort meget for at styre en klynge af forretningsbaserede IT-projekter og et stort IT-projekt, så manglende projektorganisationen en basal evne, som de fleste offentlige organisationer desværre mangler, når det kommer til store IT-projekter og styring af disse; nemlig modet til at stoppe projektet efter, at man har indset at projektets gevinster vil udeblive på grund af urealistisk forventninger eller for ambitiøse ideer om digitalisering og IT.

Fanget mellem monopoler

SKATs valg af leverandører gjorde ej heller fremdriften på udviklingen og implementeringen af EFI nemmere. Professor Søren Lauge har vurderet (2015), at SKAT blev fanget mellem to leverandører der på hver sin måde arbejder i retning af at skabe monopoler, hvilket gjorde arbejdet med udvikling og sidenhen at sætte IT-løsningen i drift til at køre af sporet.

Det at styre mange forskellige leverandører i samme projekter skaber ofte mere kompleksitet og især når det gælder IT-systemer der er designet og bygget til at data der skal udveksles med hinanden.

Grønthøster

EFI projektet var et projekt i en størrer portefølje. Porteføljen tog sit udgangspunkt i at man høstede før projektet var implementeret, hvilket betød en del af de medarbejdere der blev insourcet til SKAT blev fyret. Dermed sagt så forsvandt en hel del kompetencer. Dette har også ført en hel del negative konsekvenser med sig i forhold til EFI.

Perspektivering

EFI foregik i en statslig kontekst men har haft konsekvenser for mange andre dele af den offentlige sektor herunder kommunerne. Det er ikke alene uheldigt eller en fejl, men en katastrofe. Det stiller til gengæld også en mulighed til rådighed for perspektivering af, hvordan et digitaliseringsprojekt eller et IT-projekt skal gennemføres i den offentlige sektor, og samtidigt så giver forløbet et indtryk af, selvom organisationer anvender “best practice”, så er det ikke en garant for at digitaliseringsprojekter og IT-projekter bliver en succes. Derfor bør kommunerne tage ved lære af de fejl der blev begået i EFI.

Kilder

  1. http://www.version2.dk/artikel/podcast-om-efi-413982
  2. http://www.skm.dk/media/1263563/Redegoerelsen-om-Et-Faelles-Inddrivelsessystem.pdf

 

Bookmark permalink.

Skriv et svar

Din e-mailadresse vil ikke blive publiceret. Krævede felter er markeret med *