Kriseramt it-system var en prøveklud og et højrisikoprojekt fra begyndelsen

Det nye system til behandling af sager om arbejdsskader var Beskæftigelsesministeriets første satsning på Service Orienteret Arkitektur. Allerede i 2008 blev det set som en væsentlig risiko.

Arbejdsskadestyrelsen står over for måske at skulle tage livet af et nyt it-system, som indtil videre har kostet 164 millioner kroner, men ikke har givet de effektiviseringer, som styrelsen havde forventet. Tværtimod tager visse arbejdsgange op til fem gange så lang tid i det nye system som i det gamle.

Proask-systemet skulle automatisere flere arbejdsgange i styrelsens behandling af sager om arbejdsskader, men allerede før projektet gik i gang, stod det klart, at det var et projekt med en høj risiko på den tekniske side.

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

I en orientering til Finansudvalget fra december 2008 lyder det således i vurderingen af den tekniske risiko for projektet:

»Projektet er det første større projekt inden for ministerområdet, hvori man realiserer Beskæftigelsesministeriets strategiske beslutning om Service Orienteret Arkitektur (SOA), herunder anvendelse af koncern-fælles komponenter (fx Captia og BizTalk).«

Proask skulle således være ministeriets første forsøg med at implementere en serviceorienteret arkitektur. I orienteringen fra december 2008 var risikovurderingen for den tekniske løsning overordnet vurderet til fire ud af fem.

Men i en detaljeret risikovurdering fra marts 2011 vurderes projektets kompleksitet til fem ud af fem:

»Projektet indebærer, at hele styrelsens nuværende produktionssystem udskiftes, og det i sig selv er en kompleks operation.«

Netop det, at Proask er det første SOA-projekt i Beskæftigelsesministeriet, fremhæves også som en væsentlig risikofaktor.

Samtidig fremhæves det i risikovurderingen, at Proask er styrelsens hidtil største it-projekt med ny teknologi, som omfatter hele styrelsen, og at det vel at mærke er med teknologi, styrelsen ikke tidligere har anvendt.

Grænseflader gav problemer

Den høje risiko skulle imødegås ved at basere løsningen på standardkomponenter. I praksis viste det sig imidlertid at være sværere end først antaget.

»Selvom løsningen baseres på standardkomponenter, kræver løsningen alligevel en betydelig videreudvikling for at leve op til Arbejdsskadestyrelsens meget høje krav til systemet og forudsætter en teknisk meget avanceret løsning,« lyder det i en orientering til Finansudvalget fra maj 2011.

I april 2010 stod det således klart, at projektet ville blive forsinket på grund af udviklingen af de grænseflader, som ville være nødvendige for at opbygge arkitekturen.

»Udviklingen af specielt to af projektets 22 grænseflader (Captia-grænsefladen og BuilDoc-grænsefladen) har imidlertid vist sig at være mere kompliceret end forventet, hvilket har betydet, at nogle leverancer er blevet forsinket. Betydningen heraf har været drøftet med leverandøren, som har indsat flere ressourcer med meromkostninger til følge.«

Afløste system med WordPerfect 5.1

Proask-systemet er leveret af Steria, men består af blandt andet Scanjours Captia ESDH-system, Global 360's sagsbehandlingssystem, Corticon fra Progress som motor for regelbaseret automatisering af arbejdsgange og Microsofts BizTalk.

Systemet skulle afløse Scanjour P fra 1991, hvor medarbejderne blandt andet skal arbejde med WordPerfect 5.1.

Proask skulle imidlertid ikke kun være en prøveklud for SOA i Beskæftigelsesministeriet. Det skulle også være et forsøg på at anvende regelbaseret it til automatisering af arbejdsgange. Det var en medvirkende faktor til, at Arbejdsskadestyrelsen fik støtte på 37,4 millioner ABT-fonden, den nuværende Fonden for Velfærdsteknologi, i 2010.

Arbejdsskadestyrelsen overtog formelt Proask i december 2012, men da systemet blev taget i brug, viste det sig ikke at levere de ønskede effektiviseringsgevinster. Derfor fik styrelsen udarbejdet en rapport fra Gartner Consulting, som skulle vurdere, om systemet havde en sund arkitektur.

»Arbejdsskadestyrelsen står med løsning med en unødigt kompleks arkitektur i forhold til opgaven, somvil betyde høje videreudviklings- og vedligeholdelsesomkostninger og fejlmuligheder,« skrev konsulenterne fra Gartner Consulting i deres rapport ifølge en evaluering fra Arbejdsskadestyrelsen til ABT-fonden.

Nedtur på Gartners hype-kurve

Gartner-konsulenterne placerede også Business Process Management for den offentlige sektor på den nedadgående del af Gartners hype-kurve, og vurderede, at styrelsen lige nu befandt sig i den dybe dal, hvor en teknologi havde skuffet.

Ifølge rapporten kan styrelsen have knækket halsen på at give sig i kast med et meget kompliceret projekt:

»I forhold til Arbejdsskadestyrelsens investering i Proask er det således væsentligt at være opmærksom på, at en række af de vanskeligheder, man er stødt på i udviklingen af løsningen ikke alene, og heller ikke primært, stammer fra problematiske beslutninger i udviklingsprojektet, men derimod har vist sig at være generelle problemer forbundet med at oversætte komplekse sagsgange til en it-understøttet form.«

Arbejdsskadestyrelsen har efterfølgende fået udarbejdet en ny rapport fra Deloitte, som anbefaler helt at lukke projektet ned, fordi det ikke vil kunne lade sig gøre at få systemet til at fungere tilfredsstillende inden for et rimeligt budget.

Den endelige beslutning om skæbnen for Proask vil ifølge styrelsen blive truffet i løbet af foråret.

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

Jeg er varm fortaler for at man laver projekter hvor man prøver "nyt" af: ny teknologi, metoder, infrastruktur osv.

Men start dog for pokker med en Proof-of-Concept, en pilot eller lignende. Lav løbende evalueringer og vær klar til at smide barnet ud med badevandet for der er stor risiko for at det ikke er levedygtigt første gang...

Alt andet er temmelig hovedløst. Eller noget...

  • 9
  • 0
Claus Jacobsen

Og ikke bare en POC - men en bedre forudgående analyse. Hvordan kan man dog undgå at se at integration til andre proprietære systemer ikke vil give problemer? (jeg tror snart ikke jeg har hørt om et eneste sted hvor den slags ikke har givet problemer)

Til gengæld - hatten af for endelig at tage hul på bylden for at få afløst det gamle system - at det så blev på den forkerte måde er jo så en anden sag :)

  • 5
  • 0
Jesper Stein Sandal

Det var meningen, at der skulle gennemføres et PoC ifølge aktstykket fra 2008. Hvorvidt det faktisk skete, og hvad resultatet var, tilføjer jeg til listen over information, vi gerne vil have indsigt i.

  • 11
  • 0
Claus Jacobsen

Jeg kunne godt forestille mig at lige netop interaktionen med de andre systemer kan have været en lille hurdle for PoC'en. Dengang var der ikke noget der hed åbne standarder i de offentlige systemer. (oioxml var først så småt ved at blive vedtaget så vidt jeg husker) Så hvis der har været problemer med overhovedet at kunne få adgang til de andre systemer, som jo er temmelig vitalt for projektet så har det nok været lidt af en "showstopper" i første omgang. Det ville jo have krævet man rent faktisk fik lavet interfacet inden man gik i gang. Og det har man nok ikke været villig til at betale for, så man bare er gået direkte videre for så ville den omkostning komme under selve projektet. - men det er selvfølgelig REN spekulation :)

  • 1
  • 0
Filip Lindboe

Jeg var ikke på projektet, men jeg arbejde for Steria dengang det stod på. Jeg ved at der blev kørt POC på flere dele af løsningen. En ting er at man kan afprøve dele af løsningen og se at de virker. Noget helt andet er på forhånd at gennemskue konsekvensen af så kompleks en løsning.

  • 6
  • 0
Jeppe Cramon

Hvis projektet er initieret i 2008 kunne det godt lugte af en SOA (arkitektur) hovedsageligt bestående af synkrone integrationer og sikkert med en ESB/Koordinator i midten.
Jeg husker et andet stort SOA prestige projekt fra samme periode som også led af ekstremt lange svar tider. Årsagen var det høje antal service kald der skulle til for at håndtere selv de meste almindelige opgaver. Selv efter ESB'en blev fjernet var svartiderne meget lange.
Selvfølgelig var det SOA der var skyld i det. Eller rettere, problemet var ikke SOA, men det at man benyttede de samme design principper som man ville bruge i en monolit (der kunne tage fordel af lokale kald) i et distribueret setup. Kombineret med et dårligt service design er det en opskrift på fiasko.
Den form for integration bør efter min mening navngives Enterprise Application Integration (EAI) via WebServices og har meget lidt med SOA tankerne at gøre. Specifikt bliver 2 (boundaries og autonomi) af SOA 4's grundregler brudt (se evt. dette foredrag for mere argumentation http://www.tigerteam.dk/2013/slides-and-video-from-our-iddd-tour-dk-talk...)

  • 6
  • 0
Michael Christensen
  • 2
  • 0
Log ind eller Opret konto for at kommentere