Redegørelse om Proask: 283 mio. blev spildt på en forkert vision om automatisering

Illustration: REDPIXEL.PL/Bigstock
Proask var det forkerte it-projekt fra begyndelsen, men dårlig projektstyring betød, at fejltagelserne ikke blev opdaget i tide, konkluderer Beskæftigelsesministeriet.

Sagsbehandlingssystemet Proask var på katastrofekurs helt fra første anslag i kravspecifikationen. Visionen om at automatisere sagsbehandlingen var forkert, og der var ikke den rette styring med projektet til at opdage fejlen.

Det er hovedkonklusionen i en kortlægning af forløbet om det skrottede it-system Proask, som Beskæftigelsesministeriet har udfærdiget, og som Version2 har fået indsigt i.

Læs også: Kriseramt it-system var en prøveklud og et højrisikoprojekt fra begyndelsen

Første spadestik til Proask blev taget i 2006, og efter flere forsinkelser og store budgetoverskridelser blev systemet helt opgivet i foråret 2014. På daværende tidspunkt havde Arbejdsskadestyrelsen brugt 283 millioner kroner på projektet.

Nu er Beskæftigelsesministeriet kommet med en kortlægning af projektforløbet, som er udarbejdet med udgangspunkt i Rigsrevisionens gennemgang af Fælles Medicinkort og statens it-projektmodel. Det er i den forbindelse værd at bemærke, at Proask blev sat i gang, før statens it-projektmodel blev obligatorisk i 2010, og før oprettelsen af Statens It-projektråd i 2011.

Læs også: Rapport afslører: Kodefejl og rod i projektstyringen sendte tidligt stort it-projekt på katastrofekurs

Beskæftigelsesministeriet vurderer ifølge notatet om kortlægningen, at en projektmodel til at bistå projektstyringen måske havde givet en bedre mulighed for at opdage problemerne med Proask tidligere i forløbet. Ministeriet skriver dog samtidig, at det ikke er sikkert, at en bedre projektmodel havde reddet systemet.

Det forkerte projekt

Det altoverskyggende problem med Proask var imidlertid, at det helt fra første færd var det forkerte it-projekt. Arbejdsskadestyrelsen ønskede et nyt sagsbehandlingssystem, hvor en stor del af arbejdsgangene var automatiserede. Men styrelsen havde ikke inddraget forretningen og specifikt ikke de sagsbehandlere, som skulle bruge systemet. Derfor endte styrelsen med en 'utilstrækkelig kravspecifikation', som kom til at plage hele projektforløbet:

Arbejdsskadestyrelsens vision om et automatiseret system er den altovervejende grund til, at projektet ikke lykkedes. Den begrænsede inddragelse af forretningen gjorde, at der ikke blev stillet spørgsmålstegn ved visionen. Det gav sig udslag i en utilstrækkelig kravspecifikation og kontrakt. Det betød, at Arbejdsskadestyrelsen var nødsaget til at tage udgangspunkt i en utilstrækkelig kravspecifikation og kontrakt ved overtagelses- og driftsprøverne.

...

Det eneste, der kunne have ændret markant ved Proask-forløbet, var en anden vision, hvor forretningsbehovene var tydeligt afspejlet.

Ved at vægte automatisering så højt i projektet endte Arbejdsskadestyrelsen med en utilfredsstillende brugeroplevelse. Sagsbehandlerne oplevede lange svartider, når de brugte systemet, fordi de skulle vente på de automatiske processer.

Læs også: Nyt offentligt it-system vakler: Fem gange langsommere end system fra 1991

Da konsulentfirmaet Deloitte gennemgik Proask i slutningen af 2014 blev konklusionen, at arbejdsprocesserne i Arbejdsskadestyrelsen ikke var oplagte til automatisering, fordi sagsbehandlingen ikke følger en stringent standardproces. Når sagsbehandlerne gennemgår en sag, følger de altså ikke de samme trin i samme rækkefølge i hver sag.

Men fordi kravspecifikationen handlede om automatisering, så var det også sådan et system, hovedleverandøren Steria udviklede, men i de efterfølgende brugertest viste det sig, at systemet eksempelvis ikke understøttede, at en sagsbehandler kunne afbryde en sag og genoptage den senere.

Læs også: Skrottet it-system til 283 mio. duede slet ikke til formålet

Eksterne konsulenter skrev kravspecifikationen

Forud for kravspecifikationen var Proask stort set blevet planlagt udelukkende af it-afdelingen i Arbejdsskadestyrelsen med hjælp fra eksterne konsulenter. Ledelsen havde udpeget medarbejdere til at deltage, men 'de inddragne personer var som udgangspunkt ikke de personer, der havde størst viden og erfaringer fra sagsbehandlingen'.

Dermed var der kendte behov, som ikke kom med i kravspecifikation, som måske var kommet med, hvis projektgruppen tidligt i forløbet havde inddraget brugerne.

Kravspecifikationen fokuserede kraftigt på de tekniske krav til Proask, mens selve funktionaliteten kun var beskrevet i begrænset omfang. De tekniske krav omfattede selve it-arkitekturen og komponenterne, og det gav også problemer efterfølgende.

Problemerne med utilstrækkelige beskrivelser af funktionaliteten i kravspecifikationen og kontrakten betød i sidste ende, at Arbejdsskadestyrelsen var 'tvunget til at fuldt ud at overtage Proask, selv om systemet ikke understøttede styrelsens behov'.

Det var ligeledes besluttet, at implementeringen af it-regler og databaser skulle være på dansk, og dermed var det i praksis ikke muligt at hente eksperter ind fra udlandet til at løse problemer eller optimere systemet. Teknologivalget betød også, at Steria i praksis var den eneste danske leverandør, der havde kompetencer inden for de centrale komponenter.

I praksis blev en væsentlig del af kravspecifikationen og udbudsmaterialet udarbejdet af eksterne konsulenter. Det var konsulentfirmaerne Deloitte samt PA Consulting, hvor sidstnævnte både var involveret i denne del af projektet og senere bidrog med ekstern udvikling og projektrådgivning.

Læs også: Konsulentfirma tjente 35,4 millioner på fejlslagent it-system

Ved at overlade størstedelen af arbejdet med at beskrive projektet til eksterne konsulenter, endte Arbejdsskadestyrelsen dermed med et projekt, der ikke afspejlede behovet.

Som en del af systemet skulle Arbejdsskadestyrelsen også selv kunne ændre regler og konfigurere systemet, men denne del var også meget løst beskrevet. Derfor endte det med, at det ikke var hovedleverandøren Steria, som udviklede denne del af systemet, men derimod eksterne leverandører.

Som Version2 tidligere har beskrevet, brugte Arbejdsskadestyrelsen et tocifret millionbeløb alene til eksterne konsulenter, der udviklede på systemet sideløbende med Sterias arbejde.

Da Arbejdsskadestyrelsen i 2009 ansøgte Folketingets Finansudvalg om flere penge til Proask, så forretningsmodellen pludselig bedre ud end i det oprindelige forslag. Det var ganske vist to år inde i projektet, som allerede på daværende tidspunkt var forsinket og havde overskredet budgettet. Til gengæld vurderede styrelsen, at Proask ville medføre en effektiviseringsgevinst svarende til 50 årsværk.

Sådan en gevinst var ikke en del af den oprindelige forretningsmodel for Proask, og efterfølgende viste systemet sig altså ikke at give nogen gevinst.

Projektleder uden kendskab til sagsbehandlingen

Arbejdsskadestyrelsen brugte cirka 40 millioner kroner på eksterne konsulenter i forbindelse med Proask, og selvom brugen af konsulenter i et vist omfang var berettiget, så gav det også problemer.

Eksempelvis blev projektlederen hentet ind udefra i stedet for at bruge en medarbejder fra Arbejdsskadestyrelsen. Det betød, at projektet blev ledet af en person, der ikke havde kendskab til sagsbehandlingen i styrelsen.

Derudover måtte styrelsen læne sig op ad konsulenter i et sådant omfang, at det gav problemer med at adskille rollerne som projektleder, rådgiver og leverandør. Der har således siddet eksterne konsulenter i nøgleroller i projektet for at kompensere for, at styrelsen ikke selv havde kompetencerne.

PA Consulting, som var involveret i hele forløbet, udarbejdede i 2011 et review af Proask-projektet, hvor konsulenterne pegede på flere problemer i projektet. Ifølge Beskæftigelsesministeriet kan PA Consulting ikke klandres for, at det afleverede review ikke fik stoppet projektet. Her burde Arbejdsskadestyrelsen i stedet enten have givet PA Consulting konkret besked på at vurdere, om projektet skulle stoppes, eller have sat projektet på pause efter det første review.

Tilsvarende gav konsulenter fra Gartner også i første omgang Proask en sund helbredserklæring i 2013, men det skyldtes også, at Gartner ikke havde fået stillet den rigtige opgave. Et halvt år senere anbefalede Deloitte at skrotte Proask.

Det tegner derfor ifølge notatet fra Beskæftigelsesministeriet et generelt billede af, at Arbejdsskadestyrelsen ikke var god nok til at formulere opgavekravene til de eksterne rådgivere. Ministeriet konkluderer dog, at det overordnet set var en korrekt beslutning at få assistance fra eksterne konsulenter.

Arbejdsskadestyrelsen vil bruge konklusionerne fra kortlægningen af Proask-forløbet til at forberede et nyt udbud på et system, der skal afløse det mere end 20 år gamle system, der stadig danner grundlag for sagsbehandlingen i styrelsen.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (10)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Max Tobiasen

Det helt overordnede problem her er at man prøver at skrive en detaljeret kravsspecifikation der beskriver alle dele af systemet ned i mindste detalje, og derefter sætter en leverandør til at implementere den. Det er præcis det samme mange andre store IT projekter gør, og det fungerer ikke. Det kan simpelthen ikke lade sig gøre at lave en korrekt beskrivelse af et stort system som så bagefter "bare" skal implementeres.

Forestil dig at du skal skrive en kravsspecifikation til en af dine venner der skal ned til bageren efter brød. Hvis du skal give ham en komplet specifikation som han skal følge slavisk, uden at måtte agere på eksterne inputs bliver det en meget svær disciplin, han skal grundlæggende kunne gøre det med bind for øjnene;

Tag to skridt fremad, og ræk hånden ud. Der bør være et håndtag. Tag fat i håndtaget og før det nedad 5 cm. hvorefter du skubber på håndtaget. Tryk på døren så den glider op, og træd to skridt fremad. Tag med hånden på den anden side af døren hvor der også sidder et håndtag og før døren tilbage til dens originale position. Når du ikke kan føre døren længere tilbage skubber du håndtaget opad 5 cm. for at lukke døren. Vi er nu kun kommet ud af døren og har ikke engang beskrevet de utallige failure modes, såsom at døren binder, at der er nogen på vej ind ad døren, at døren er låst, etc. etc. En beskrivelse af hvordan du kommer ned til bageren og tilbage igen med brød kan hurtigt komme til at fylde et ringbind eller to, og man vil unægteligt glemme nogle skridt, eller failure modes. Har du husket at tage højde for at bageren kan være lukket på grund af sygdom? At der er vejarbejde? At brødet kan være udsolgt? Har du skrevet ind hvad der så skal ske?

Men det er sateme ikke nogen særligt smart måde at gøre det på...

Istedet kunne man sige til ens ven at målet er at få friskt brød, fortælle ham hvor bageren er, hvad brød bør koste og så sende ham afsted med instruktioner om at bruge de eksterne inputs der er tilgængelige og bruge hans sunde fornuft til at opnå det givne mål. Det er vist det man kalder agile....

Før vi får ændret udbudsprocessen og kommer væk fra den tåbelige waterfall model bliver det ikke bedre. Ikke fordi udviklerne og de involverede medarbejdere er dumme, men fordi processen er uladesiggørlig for alt andet end småprojekter.

Ulrik Suhr

Enig, men du tænker ikke på alle de mennesker/konsulenter du så ikke har i arbejde ved dit forslag.
Der er sikkert også en stor bestyrelse og konsulenter til at vejlede disse.
Der er simpelthen så mange jobs i ikke at gøre det ordentlig at det ikke kan lade sig gøre at ændre.

Den nemme vej er jo netop at sige hvis projektet er over 5 milioner så deles projekt op i mindre dele så de er under 5 milioner (EU grænse) hver.
De skal fx. tage max 4-6 måneder at implementere og teste.

Tror det bliver en sådan løsning i fremtiden måske med en højre beløbsgrænse, men tror der går 1-2 generationer før gennemsnits intelligensen i folketinget er høj nok til at forstå dette.

Thomas Watts

Lidt godt gammelt TV OBS...

Over 500.000,- skal der annonceres på udbudsportalen så alle i DK gøres bekendt med det (hvis man abbonnerer på notifikationer inden for sit felt). Over 1.5mio skal det i EU udbud.

Beløbene er så små, at man nærmest ikke kan røre på sig, før man er over EU udbudsgrænsen med dertilhørende krav til proces og kontrakter, der gør hele setup'et meget, meget tungt. Danmark er kendt for at følge EU reglerne mere stramt end andre EU lande, men sådan er nu engang vore vilkår, indtil andet er bestemt.

Du kan ikke opdele store projekter i noget, der får dem under de grænser på nogen fornuftig måde rent juridisk. Det ville være i strid med reglerne om, at det er projektets samlede omkostninger over en 4-års periode (udvikling, implementering, test, drift, licenser, nødvendig slutbruger/admin undervisning) - regn selv på, hvor meget man får for om året, hvis man skal under 1.5mio ;)

Denne fokus på klart kalkuleret pris gør det yderligere meget svært at benytte agile metoder i så store anskaffelser. Byderne skal vurderes lige og ud fra klare kriterier. Hvis man benytter user stories, use cases eller andre beskrivelser der holder teknikken ude af billedet, men sætter fokus på forretningsbehovene, har man gjort det meget svært at sammenligne de bud, der komemr. Ooooog velkommen søgsmål fra hele EUs IT-sektor, som man så skal slås med i retten.

Det kan gøres, naturligvis, men det kræver fra start til slut en meget politisk stærk projektorganisation med høj faglig kompetence på jura, (user)design, forretningsprocesser, informationsmodellering, teknik, sikkerhed, projektledelse osv.

Jn Madsen

Her på Version2 har der været flere omtaler af udenlandske "metoder".

Bl.a. hvordan englænderne har kunne bruge små lokale leverandører, med det resultat at man sparer milliarder af kroner, får leveret til tiden og al funktionalitet er tilfredsstillende.

Svenskerne kunne levere et nyt system til deres politi,- af samme type som Polsag.
De gjorde det (i Danmark) helt utænkelige, at de satte et par kompetente brugere (rutinerede betjente) sammen med nogle interne garvede systemfolk. De måtte købe lidt hjælp udefra til nogle specielle ting.

Men det sagde bingbongdynamolygte .... så kørte det,- til en meget mindre pris end det kuldsejlede Polsag.

Vi er en flok amatører .... hvad er det vi ikke forstår?

Jn Madsen

I den forbindelse har jeg bl.a. hørt om kommuner der bruger mange resourcer på at skrive kravspec,- så de kun passer med en leverandør,- som de har en aftale med under bordet.

Something is rotten in Denmark.

Vi skal have et IT-ministerium ...

Lige nu har vi en situation, hvor det er bedre at bruge vildt mange penge på noget der ikke virker, men alle regler og procedurer er overholdt. Det er bedre end at lave noget der virker, billigt og til tiden,- men med "løse tøjler".

Rune Larsen

"Beskæftigelsesministeriet vurderer ifølge notatet om kortlægningen, at en projektmodel til at bistå projektstyringen måske havde givet en bedre mulighed for at opdage problemerne med Proask tidligere i forløbet. Ministeriet skriver dog samtidig, at det ikke er sikkert, at en bedre projektmodel havde reddet systemet."

Ikke sikkert?! Det er da det mest idiotiske - de har jo intet lært af forløbet.

"Det eneste, der kunne have ændret markant ved Proask-forløbet, var en anden vision, hvor forretningsbehovene var tydeligt afspejlet."

NEJ! Det eneste der kunne have ændret forløbet var en projektmodel, som med det samme sikrer at der der udvikles, kan bruges i virkeligheden. Dvs. agil udvikling.

NOGEN har bevidst valgt at køre projektet med en tung kravspev selvom det er veldokumenteret at dette er ekstremt risikabelt. Disse organisationer og personer bør drages til ansvar for farcen, så lignende undgås i fremtiden.

Respekt til Deloitte, der havde indsigt til at sammenligne virkeligheden med systemet og stoppe vanviddet. Og det modsatte til PA, Gartner og Steria, der alle gav kunden hvad kunden bad om og ikke hvad kunden havde brug for.

Niels Henrik Sodemann

Det er da det mest idiotiske - de har jo intet lært af forløbet.

Ja, der kommer næppe megen læring ud af en ”egen undersøgelser”, hvor man alene kigger på de projekt interne dele af haveriet.

Det er min klare opfattelse at læring alene kan ske hvis man har en uvildig / uafhængig instans til at undersøge det samlede havari. Uvildig / uafhængig udelukke at undersøgelsen drives af de parter som på en eller anden vis har deltaget undervejs, dvs. Kammeradvokaten, Rigsrevisionen, Ministeriet, Styrelsen, de involverede konsulenthuse og leverandøren.

Det må efterhånden være indlysende for enhver at vi har brug for en IT havarikommission i Danmark, f.eks.som beskrevet her: http://www.version2.dk/blog/it-haverikommission-nu-51199

Tine Andersen

"Magisk IT-sovs" equals bespraelser, og så glemmer man helt at tænke på hvad, de der rent faktisk behandler sagerne, mener?

Hvorfor analyserer man ikke sagsbehandlingen og fremgangsmåden, sammen med de folk, der rent faktisk udfører arbejdet, og hører om de har rationaliseringsforslag?

IT-afdelingen: TJØH! Ja undskyld! ;-)

Hvor meget af den pg sagsbehandling udfører de? Eller vedligeholder de bare servere og maskiner?

Det er nok de sidste, jeg ville spørge, de kommer da endelig ind til næstsidst når man skal arbejde med sagsbehandling, jeg tror ikke, de har den højeste kapacitet/viden om, hvordan systemet fungerer. De ved så meget mere om, hvordan IT, kan få systemet til at virke hurtigere/bedre med IT.

De skal vel ikke bare sidde og ønsketænke deres idéer om, hvordan de får Janne Sagsbehandler maskine til at makke ret, når den fåkker up?!

Mvh
Tine

Kristian Sørensen

Svenskerne kunne levere et nyt system til deres politi,- af samme type som Polsag.
De gjorde det (i Danmark) helt utænkelige, at de satte et par kompetente brugere (rutinerede betjente) sammen med nogle interne garvede systemfolk. De måtte købe lidt hjælp udefra til nogle specielle ting.

Ifølge "den danske fortolkning" af EU udbudsreglerne er lige netop den fremgangsmåde ulovlig.

Det anses for helt forbudt at tillade dem der skal skrive tilbud at tale med brugerne undervejs i tilbudsarbejdet og det anses for påbudt at outputtet fra tilbudsprocessen er en detaljeret og ufravigelig kravspecifikation.

Først når der er tegnet bindende kontrakt på at levere netop det kravspecifikationen lover og ikke afvige fra kravspecifikationen, må den valgte leverandørs folk tale med kundens folk

Hvorfor man kræver den fremgangsmåde i Danmark går over min forstand, for jeg har endnu til gode at se det virke.

De projekter jeg har været på der er lykkedes, har været små nok til at snige sig under EU udbudsgrænsen. Der har man så valgt andre fremgangsmåder, der typisk havde som et væsentligt element at nogle programmører og nogle af kundens erfarne folk talte meget grundigt sammen.

Kristian Jensen
Log ind eller Opret konto for at kommentere
Pressemeddelelser

Welcome to the Cloud Integration Enablement Day (Bring your own laptop)

On this track, we will give you the chance to become a "Cloud First" data integration specialist.
15. nov 2017

Silicom i Søborg har fået stærk vind i sejlene…

Silicom Denmark arbejder med cutting-edge teknologier og er helt fremme hvad angår FPGA teknologien, som har eksisteret i over 20 år.
22. sep 2017

Conference: How AI and Machine Learning can accelerate your business growth

Can Artificial Intelligence (AI) and Machine Learning bring actual value to your business? Will it supercharge growth? How do other businesses leverage AI and Machine Learning?
13. sep 2017
Jobfinder Logo
Job fra Jobfinder