Nyt offentligt it-system vakler: Fem gange langsommere end system fra 1991

Arbejdsskadestyrelsen står efter et overskredet budget, forsinkelser og tre konsulentrapporter med et it-system, som er op til fem gange langsommere end system fra 1991.

Arbejdsskadestyrelsen sidder lige nu på vippen, når det gælder fremtiden for et nyt sagsbehandlingssystem, Proask, som foreløbig har kostet styrelsen 164 millioner kroner. En ny rapport fra konsulentfirmaet Deloitte anbefaler styrelsen at skrotte systemet.

Det skyldes især lange svartider, som ikke ser ud til at kunne løses og i visse tilfælde får arbejdsgangene til at tage fem gange så lang tid som med det eksisterende system fra 1991. Systemets skæbne er dog endnu ikke afgjort.

»Det er en foreløbig rapport, så beslutningen er ikke truffet. Vi regner med, at der bliver truffet en beslutning i løbet af foråret,« siger direktør i Arbejdsskadestyrelsen Anne Marie Rasmussen til Version2. Hun understreger, at ingen af de tilskadekomne, hvis sager styrelsen behandler, bliver påvirket af situationen.

Anbefalingen om at lukke Proask-systemet ned og droppe projektet strider umiddelbart imod en rapport, som blev afleveret til styrelsen i juni 2013 fra Gartner Consulting. Her lød anbefalingen på at fortsætte projektet, fordi det stadig kunne komme til at give en positiv tilbagebetaling i 2020 mod oprindeligt allerede i 2013.

Det fremgår af en evalueringsrapport fra Arbejdsskadestyrelsen til ABT-fonden, som har været med til at betale en del af projektet.

Hvad har ændret sig, siden I fik Gartner-rapporten i juni 2013?

»Gartner-rapporten var afgrænset til at se på arkitekturen og en generel vurdering af projektet. De skulle ikke se på gevinsten ved endelig ibrugtagning. Gartner pegede også på nogle kritiske punkter, og da vi begyndte implementeringen, blev vi i tvivl og satte derfor en ny vurdering i gang,« forklarer Anne Marie Rasmussen.

Gartners vurdering af en mulig effektiviseringsgevinst, der svarede til det oprindeligt planlagte, var under forudsætning af, at problemerne med systemet kunne løses, samt at styrelsen kunne hente effektiviseringer ved omlægning af arbejdsprocesser.

»Deloitte har set på idriftsættelsen og effekterne. Svartiderne er for lange, og der peges klart på, at det ikke er muligt at løse det, så systemet bliver tilstrækkeligt effektivt« siger Anne Marie Rasmussen.

Leverandøren af Proask, Steria, har endnu ikke haft mulighed for at se den nye rapport fra Deloitte. Projektet er formelt overdraget i henhold til kontrakten til Arbejdsskadestyrelsen, men Steria har fortsat ansvaret for vedligeholdelse.

Proask-systemet skulle være taget i drift i 2011, men allerede i januar 2011 stod det klart, at systemet ville blive forsinket, fremgår det af et aktstykke fra Beskæftigelsesministeriet til Folketingets Finansudvalg. Derfor bestilte styrelsen en rapport fra konsulentfirmaet PA-Consulting, som konkluderede, at projektet ville blive forsinket med et halvt år. I en orientering fra Finansministeriet fra 2010 fremgik det desuden, at budgettet ville blive overskredet fra 108 millioner kroner til 137 millioner kroner. Den samlede pris er foreløbig endt på 164 millioner kroner.

Arbejdsskadestyrelsen og Steria indgik i begyndelsen af 2011 en ny aftale, hvor første fase af systemet skulle ligge klar i juli 2011, og anden fase skulle være afsluttet i april 2012.

Systemet blev imidlertid yderligere forsinket, og det blev først endelig afleveret til styrelsen i december 2012. Systemet havde på daværende tidspunkt bestået både en overtagelsesprøve og en driftsprøve i henhold til K02-kontrakten. 28. december 2012 overtog Arbejdsskadestyrelsen Proask fra Steria.

Ifølge Evalueringsrapporten fra Arbejdsskadestyrelsen var der imidlertid allerede problemer i forbindelse med den driftsprøve, som systemet skulle gennemgå, inden Steria kunne overdrage systemet til styrelsen.

Hvordan kunne systemet bestå prøverne, hvis det nu viser sig, at det må kasseres?

»De afsluttende prøver blev vurderet i forhold til kontrakten. I samråd med Kammeradvokaten vurderede vi, at leverandøren havde levet op til kontrakten, men da vi satte det i pilotdrift, viste der sig at være alvorlige problemer med systemet,« siger Anne Marie Rasmussen.

De problemer, som kan koste systemet livet, er hovedsageligt lange svartider, hvor brugerne skal sidde og vente. Det er der ifølge Deloitte-rapporten ingen forventning om at kunne afhjælpe i tilstrækkeligt omfang til at kunne hente den ønskede gevinst.

Steria har efterfølgende leveret mindst fire efterleverancer i henhold til en vedligeholdelsesaftale. Ifølge Gartner-rapporten var der forventning om, at den fjerde efterleverance ville kunne afhjælpe problemerne, og det ville være muligt med en merinvestering på mellem 20 og 30 millioner kroner at få projektet på ret køl.

Det har også været holdningen i Arbejdsskadestyrelsen frem til den nye rapport fra Deloitte. I september 2012 oplyste styrelsen til Digitaliseringsstyrelsen og Statens It-projektråd, at Arbejdsmarkedsstyrelsen forventede at kunne realisere alle de væsentlige gevinster ved indførelsen af systemet.

Af rapporten fra Gartner Consulting, som blev bestilt i marts 2013, fremgår det, at blot 20 procent af styrelsens såkaldte P-sager blev behandlet i Proask-systemet. Blot én procent af A-sagerne blev behandlet i systemet.

Alligevel var forventningen, at systemet kunne stå for behandlingen af alle sager ved udgangen af 2015.

Det fremgik imidlertid også af Gartner-rapporten, at behandlingstiderne for visse arbejdsprocesser kunne være op mod fem gange længere, end det var tilfældet med det system fra 1991, som Proask skulle afløse.

Styrelsen kunne måle en fremgang på visse områder efter den tredje opdatering af systemet, men i flere tilfælde stadig længere arbejdsgange end det gamle system.

I juni 2013 vurderede styrelsen på baggrund af Gartner-rapporten, at Proask trods forsinkelsen stadig havde potentiale til at blive et effektivt og tidssvarende sagsbehandlingssystem.

Den vurdering ser Deloitte-rapporten nu ud til at have skudt i sænk, hvis styrelsen vælger at følge anbefalingen i den foreløbige udgave af rapporten.

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

Der en tendens til at vægte design over funktionalitet.

Google gjorde gmail, langsommere for design skulle være vigtig, og nroaml funktion blev skjult.

Bibliotek.dk fik nyt design, hvilket gør at der ligesom gmail skal klikkes 3 gange så mange for at samme funktionalitet, samtidig fjernde de funktionen som at sende bestilling bekræftelse (kun kun printes i starten) Funktionen at vælge et standard bibliotek, så bibliotek skal vælge være gang og meget mere.
Det tager længere tid at indlæse listen med resultater.

Youtube, lagde en masse ting ind i tandhjul, hvilket også her kræver flere klik, hvis man skal slå captions fra.

Der er mange flere eksempler, men fælles er at resultat at siden ofte bliver langsommere når design vægtes før funktionalitet, og nogle gange som meget at det er helt ubrugeligt.

Anonym

Der er en tendens til at elske big bang releases i det offentlige. Hele systemet skal være 100% færdig udviklet, og skal overholde regler og direktiver 100% før det søsættes, og det er i den grad her at kæden springer over.

For det første at det utopi, at tro at regler og direktiver er en fasttømret ting der ikke ændre sig over tid, det er en flydende masse der stritter i forskellige retninger hele tiden.
Bedst som et system er ved at være klart, så er der skiftende regeringer, ministre eller ekstrabladshistorier der er med til at ændre lovene (hvilket er ganske naturligt, men system design/udviklingsprocessen har det ikke godt med det).
Nu skulle man så tro at det var en smal sag at tilpasse systemer til de nye regler, men næh nej så går der "DJØF" i projekterne. Så har vi forskellige kommuner, regioner og statslige institutioner, der hver lige skal have deres fingeraftryk på, for de er jo "helt unikke", eller man skal igang med re-fortolke lovgivningen i forhold til projektplaner - alt sammen noget der koster tid og ikke mindst mange penge.

For det andet, er der alt for ofte alt for langt mellem beslutningstagere og udviklere, og beslutningstagerne har det ofte med at have en berøringsangst overfor udviklere, for det har man jo ikke lært noget om på jura, økonomi eller statskundskab studierne. Man taler simpelthen ikke samme sprog, og når udviklerne så får fat i en specialist på, lad os bare sige sundhedsområdet, så er der en labyrint af bureaukrati fra mening medarbejder til leder, tilbage til medarbejder som (måske) snakker sammen med udvikler(-hus).

Næste problem er hele udbudsprocessen, som er en underlig proces. De store IT systemer i DK ender stort set altid ved de samme firmaer, da de er de eneste med juridiske ressourcer nok til at tage kampen op mod DJØF vældet. Dette er en dyr proces, som i sidste ende kan være med til at projekter havner ved en udbyder man måske ikke ville have valgt hvis man stod med valgfrihed. Den mindre lokale IT udbyder bliver (igen) forbigået, og udviklingskroner havner (igen) i udenlandske firmaer (for ikke at glemme data). Det er både halve og hele mio. af kroner der bliver brugt på projekterne inden der er skrevet så meget som en linje kode, eller underskrevet en aftale.

Det kan måske virke som en rant mod DJØF (og ja det er det måske også), men det er pga. bureaukrati at mange projekter i det offentlige ender med at være baseret på oldnordiske backend systemer, som er komplekse at vedligeholde, og som koster en formue med jævne mellemrum når de idiotiske udbudsrunder skal køre igen og igen.

For mig at se er det nødvendigt at gøre op med big bang release tankegangen og indse at det er helt ok at udpege "nice to have" og "need to have" frem for "must have everything", og så release sjatvis, for som det ofte viser sig så er det alligevel kun 10% af systemet der ender med at blive brugt.

Dernæst kunne det måske være en ganske fornuftig idé at man begynder at overveje om hele udbudstanken ikke er mere hæmmende i forhold til value for money, og ikke mindst at udbudsrunderne er med til at udelukke en lang række af mindre virksomheder fra at tilbyde deres ekspertise.

Og til sidst så skal DJØF uddannelserne i den grad begynde at klæde deres kandidater langt bedre på til at forholde sig til IT systemer, som ikke "bare lige" kan dække fagområder 100% med snørklede regler, regulativer og direktiver og hvad ved jeg.

Peter Øe Svendsen

Desværre endnu en kedelig historie om offentlige it-systemer der ikke virker. Efter at have skimmet evalueringsrapporten fra Arbejdsskadestyrelsen virker det som om det fra starten har været en svær opgave at udvikle systemet grundet en indviklet og uforudsigelig proces.

Som udvikler kunne jeg godt tænke mig at journalisten prøvede at fremskaffe oplysninger om systemets arkitektur. Det er svært at danne sig et indtryk af hvad problemet egentlig er. Er det den valgte arkitektur og selve projektudførelsen eller er det opgaven/processen der er for kompleks til at digitalisere?

Lars Persson

Jeg kan ikke lade være med at tænke på, hvor mange sager, man kunne færdigbehandle i samme periode med 164 millioner + papir/blyant...


Hvis én sag tager en uge bliver det 40 sager på et år for én sagsbehandler.
Hvis sagsbehandleren får 400.000,- om året er det 10.000,- pr. sag eller 16.700 sager.
Arbejdsskadestyrelsen bearbejder ca. 40.000 sager om året (http://www.ask.dk/da/Statistik/Statistik-omkring-sagsbehandlingen/Sagsti...)

Jarle Knudsen

Der er en tendens til at elske big bang releases i det offentlige. Hele systemet skal være 100% færdig udviklet, og skal overholde regler og direktiver 100% før det søsættes, og det er i den grad her at kæden springer over.


Sidst år var jeg til jobsamtale i Naturstyrelsen (IT-arkitekt) hvor jeg kom til at kritisere nettop den vandfaldsmodel med krav specs på 100-200 sider (som tilsyneladende igen gider at læse) samt big bang release som det offentlige sværger til. Abefalede i stedet agile model med 100-200 projekter hvor kravene er beskrevet på 1-2 sider hvert.

Gæt om jeg har fået jobbet :o/

Jesper Stein Sandal
Charlotte Grønvold

<<<<For mig at se er det nødvendigt at gøre op med big bang release tankegangen og indse at det er helt ok at udpege "nice to have" og "need to have" frem for "must have everything", og så release sjatvis, for som det ofte viser sig så er det alligevel kun 10% af systemet der ender med at blive brugt.<<<<
Jeg er helt enig og måske skulle man overveje at udvikle skræddersyede løsninger istedet for at tro et standard system kan løse eller funktioner. Der er alt for mange store virksomheder der poster millioner i standardsystemer for derefter at tilpasse dem. Med dyre konsulent-regninger til følje. Ofte ender det med en alt for dyr og tung løsning, hvis den overhovedet bliver sat i drift.

John Vedsegaard

Der er tale om en skide multibruger database . . hvor svært kan det være.
Om så systemet skulle programmeres helt fra bunden, altså uden en sql del, kan det aldrig koste over 100 millioner, det er et 2-mands projekt, som kan laves af studerende i fritiden, på mindre end 1 år.

Ditlev Petersen

»De afsluttende prøver blev vurderet i forhold til kontrakten. I samråd med Kammeradvokaten vurderede vi, at leverandøren havde levet op til kontrakten, men da vi satte det i pilotdrift, viste der sig at være alvorlige problemer med systemet,« siger Anne Marie Rasmussen.

Det er muligt, jeg er uvidende, men hvordan kan kammeradvokaten skulle afgøre, om en afprøvning gav et godt eller et dårligt resultat? Det er da et antal prøvebrugere, der skal afgøre det. Når vi laver tests, så har vi da ikke sat en advokat til det.

Jesper Udby

kan det aldrig koste over 100 millioner, det er et 2-mands projekt, som kan laves af studerende i fritiden, på mindre end 1 år


Meget enig. Det er helt vildt hvad et lille team af dedikerede udviklere kan afstedkomme på få måneder!

Udfordringerne opstår imidlertid når systemet som er designet til udskrive badebilletter også skal interface til leverandøren af klaphatte, producere farvestrålende rapporter til direktionen og sende fakturaer til det offentlige.

Derfor kan det være fristende at købe et standardsystem - som har "connectors" til hvadsomhelst og kan tilpasses i det uendelige - og så bruge tid og penge på at tilpasse det, fremfor at forsøge at ny- eller videreudvikle det oprindelige på baggrund af de nye krav. Desværre.

For ofte viser tilpasningerne sig at være sværere og dyrere end antaget, de der "connectors" koster dyre ekstralicenser, producenten har lovet for meget og tilpasningerne giver problemer når der skal opgraderes til nyere versioner, hvilket er påkrævet hvis man ikke ønsker fortsat support skal være urimelig omkostningstung. Og så videre.

Ved sgu snart ikke...

Anonym

Alt efter hvilke lovkrav der skal opfyldes for at lave systemet, så kan det meget hurtigt komme til at koste rigtig mange penge, for selv simple systemer.

Der skal heller ikke mange krav til driftsikkerhed før man kommer over EU udbudsgrænserne, og så begynder man allerede der at udelukke to mands teamet.

Så systemer at denne art er ikke "bare lige" projekter (det kunne være rart hvis det var)

Jesper Udby

Alt efter hvilke lovkrav der skal opfyldes for at lave systemet, så kan det meget hurtigt komme til at koste rigtig mange penge, for selv simple systemer.


Hmmmthahh, der kommer an på. Og det gælder vel også tilpasningerne til "standardsystemerne"?

Der skal heller ikke mange krav til driftsikkerhed ...

Der er ikke meget der slår små simple systemer på driftssikkerhed, så den køber jeg heller ikke umiddelbart.

Anonym

Jamen så byd ind, og bliv overrasket når der stilles krav til hosting, driftsikkerhed, løn til dig og din makker, og ikke mindst jeres jurister.

Men kan I levere et system der over 4 år koster mindre end 500.000 at udvikle, hoste og vedligeholde, så sæt igang. Er prisen over 1.5 mio over de 4 år så skal der et EU udbud, og så begynder det først at blive dyrt bare at komme i betragtning til opgaven.
Og når løn, hardware, jurister, kørsel, møder, kravsspec osv. skal betales så er der pludselig meget lavt til loftet på de 1.5 mio over 4 år.

Dermed ikke sagt at det retfærdiggøre de offentlige IT projekter hvor det er løbet løbsk, men den proces har jeg forsøgt at beskrive ovenfor.

Ulrik Suhr

Jeg er i den stik modsatte grøft.
Hvis man ikke kan opdele et projekt i små bidder (læs: del det op i så små bidder som man ønsker).
Så er man simpelthen ikke egnet til at lede projektet PUNKTUM.

p.s. jeg har hørt at grunden til ledere ønsker standard systemer er deres manglende firma indsigt. De har simpelthen brug for standard rapporter til at give dem firma nøgletal. Det er skrammende men det er hvad jeg har hørt fra flere steder.

Jesper Udby

Jamen så byd ind...


Jeg er kun mig og kunne ikke drømme om at byde ind med andet end Time & Material.

Når det er sagt tror jeg ikke vi er så uenige. Den grundlæggende udfordring er "De Offentlige Kontrakter" som giver anledning til big-bang udbud i 2-3 cifrede mio kontrakter.
Som kun de største magter at byde ind på. De har ganget med et sted mellem kvadratrod 2 og pi for at være på den sikre side, ellers er fastpris ganske enkelt no-go.
I det konkrete tilfælde er det Steria. De har nok snarere håbet på nogle lukrative servicekontrakter efterfølgende...

Og det ender galt HVER gang. Derfor må der gøres op med hele konceptet, for big-bang projekter er dømt til at gå galt.

Anonym

Og det ender galt HVER gang. Derfor må der gøres op med hele konceptet, for big-bang projekter er dømt til at gå galt

Helt enig.

Jeg er i den heldige situation at det meste af det jeg sidder med er open source, og som inhouse Plone/Python udvikler er det ikke så tit at jeg bliver ramt af at skulle sende noget i udbud på mit område (jeg har det "til gode"). Skulle der endelig sendes noget i udbud, så ville det være mig der fører den tekniske del af snakken og så lader jeg juristerne om deres, og cheferne om deres.

Jesper Udby

De har simpelthen brug for standard rapporter til at give dem firma nøgletal. Det er skrammende men det er hvad jeg har hørt fra flere steder.


Det er meget skræmmende, for rygter vil vide at krav til levering af KPI's og tilsvarende fra systemet til beslutningstagerne ofte overskygger ønsker og forventninger til UI/UX og derfor kan være direkte ødelæggende for selv de mest velmenene systemer...

Men det er også nogen gange det systemer bliver solgt på. Altså: "Hvis vi implementerer dette geniale standardsystem fra leverandør XXX, så kan vi få direkte indblik i den aktuelle økonomiske situation og vi kan til enhver tid udpege nøgleprodukter hvor vi bør kunne optimere indtjening/omkostninger. Den tænkte effektivisering i kroner og ører forventes at kunne tjene investeringen hjem på Y år".

Og så er den sådan set ikke længere.

Michael Christensen

Der er tale om en skide multibruger database . . hvor svært kan det være.
Om så systemet skulle programmeres helt fra bunden, altså uden en sql del, kan det aldrig koste over 100 millioner, det er et 2-mands projekt, som kan laves af studerende i fritiden, på mindre end 1 år.

Mon ikke du lige skulle læse udbudsmaterialet og kravspec'en inden du lukker sådan noget ud?

Hvis du læser arkitekturbeskrivelsen: http://www.version2.dk/artikel/kriseramt-it-system-var-en-proeveklud-og-...
så bærer det rimeligt tydeligt præg af, at det ikke "bare" er en database.

Bare mængden af grænseflader (22) er nok til, at jeg i hvert fald godt kan følge hvorfor det koster kassen. Hvis jeg kender det offentlige, så er der så godt som ingen af dem der er standardiserede grænseflader, men sikkert en god blanding af alle muligt mærkelige API'er til 3. parts software, webservices, ftp og andet snask.

Steria kan næppe sige sig fri for en del af skylden, men jeg vil æde min gamle hat på, at størstedelen af skylden ligger hos Arbejdsskadestyrelsen.

Frithiof Andreas Jensen

Udbudsreglerne kan hackes - man kan, for eksempel, dele systemet op i pakker som er mindre end udbudsreglerne kræver. Det kræver en rigtig god arkitekt fra starten og en tam, kompetent, DJØF'er lige fra starten - men - dem kan man også få til mindre end udbudsgrænsen.

Problemet er at folk tænker for meget i "alt eller intet" når de skriver projekteringen.

Log ind eller Opret konto for at kommentere