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

28. januar 2014 kl. 11:3611
Kriseramt it-system var en prøveklud og et højrisikoprojekt fra begyndelsen
Illustration: Lars Refn.
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.
Artiklen er ældre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

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.

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).«

Artiklen fortsætter efter annoncen

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.

11 kommentarer.  Hop til debatten
Denne artikel er gratis...

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.

Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.

Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.

Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
10
29. januar 2014 kl. 15:27

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-what-soa-do-you-have-with-extended-eda-and-cqrs-material/)

9
29. januar 2014 kl. 13:41

Tak til version2 for at dykke ned i de konkrete problemer der har været ved at udvikle systemet.

Skræmmende at endnu et offentligt it projekt er endt i skandale.

6
29. januar 2014 kl. 01:49

Alle offentlige it-systemer er prøveklude og højrisikoprojekter fra begyndelsen. Det vil tage flere timer blot at skrive en liste over fiaskoerne.

1
28. januar 2014 kl. 12:45

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...

3
28. januar 2014 kl. 13:12

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.

4
28. januar 2014 kl. 14:50

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 :)

5
28. januar 2014 kl. 17:27

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.

2
28. januar 2014 kl. 13:05

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 :)