Det er ofte de samme fejl, der går igen, når et offentligt it-projekt går galt.
Sådan lyder det fra professor på IT-Universitetet Søren Lauesen i et indlæg i Samdata-magasinet.
Regeringen udgav mandag resultaterne af et såkaldt kasseeftersyn af de offentlige it-projekter. Her fremgår det, at 157 af statens it-systemer er sårbare og nedkørte.
Det kan du læse mere om her: Stort eftersyn: 157 af statens kritiske it-systemer er nedkørte og sårbare over for hackere
Gennem årene har de offentlige it-skandaler været et tilbagevendende fænomen. Igen og igen er de store projekter landet i store forsinkelser og fordyrelser - nogle gange i mange millioner kroners klassen.
I den lange række finder vi blandt andet Arbejdsmarkedsstyrelsens Amanda, forsvarets DeMars, EPJ-projekterne, SLS, Skats egen e-indkomst, den digitale tinglysning, SINE, Polsag, ProAsk og seneste Skats totalt fejlslagne EFI-projekt, som har fået Skat til at kræve næsten 700 millioner kroner i erstatning fra KMD.
Du kan læse mere om, hvorfor det bliver ved med at gå galt i det offentlige her: Hvordan kan det blive ved? Få nu stoppet de offentlige it-skandaler.
I stort set alle de store it-katastrofer er kæden hoppet af af samme årsager:
- Der har været problemer med dokumentationen.
- Der har været problemer med processer og projektledelse.
- Der har været alt for mange udviklere, chefer, projektledere og forskellige (skiftende) nøglemedarbejdere inde over, som i et miskmask af beslutningskompetencer og organisatoriske jungleveje gennem årene har truffet beslutninger på kryds og tværs af hinanden indtil overblikket er gået fløjten.
- Kompleksiteten er vokset i takt med ændret lovgivning og vilkår undervejs i det årelange forløb.
- På grund af manglende dokumentation har projektudviklingen været udfordret hver gang nøglemedarbejder er blevet skiftet ud.
Hvad er behovet?
Søren Lauesen peger da også på, at fejlen ofte er den samme:
"Man fokuserer ikke på, hvad brugernes behov egentlig er. Man tror, at man skal beskrive, hvad systemet skal gøre, men det skal man ikke," siger Søren Lauesen til Samdata.
Han peger her på, at man i stedet bør fokusere på at beskrive de arbejdssituationer, som systemet skal anvendes i.
"Det har den store fordel, at kravsspecifikationen kommer til at fylde en femtedel eller en fjerdedel," siger han til bladet.
Netop kravsspecifikationerne har i årevis været et kritiseret punkt i de store offentlige it-projekter, der ofte har det med ændre sig efter kravspecifikationen er blevet afleveret.
Det seneste eksempel herpå er kommunernes batalje med KMD om leveringen af de såkaldte støttesystemer. Det kan du læse mere om her: KMD-topchef efter voldsom kritik: "Jeg afviser fuldstændigt blankt, at KMD spekulerer i at forsinke systemer til kommunerne"
Det er næsten syv år siden, at en række ministerier sammen formulerede en række helt konkrete anbefalinger til at få de mange offentlige it-projekter til at køre.
Budskabet var det samme, som vi ofte har hørt: Professionalisering, projektledelse, risikohåndtering og dialog med leverandørerne - altså nøjagtigt det samme, som også Statens IT-Projektråd har været inde på.
Du kan læse mere om det i denne snart syv år gamle artikel: Overblik: Sådan skal staten lære at styre it-projekter.
Til gengæld har det offentlige jo efterhånden prøvet at udvikle avancerede it-systemer nogle gange gør, og der burde efterhånden være forankret en grundig viden om, hvordan disse store projekter skal håndteres.
Søren Lauesen mener, at kravene ofte er for urealistiske. Ifølge ham koster det eksempelvis 10 millioner kroner at hæve oppetiden fra 99,5 procent til 99,9 procent. Og oppetiden er ofte indskrevet som krav i selve kravspecifikationen fremfor at åbne for muligheden for, at leverandøren lægger flere forskellige muligheder på bordet.
Søren Lauesen siger til bladet, at den serviceorienterede arkitektur i mange tilfælde er en væsentlig årsag til katastroferne. I SOA trækker systemerne data fra andre systemer ind til et samlet hele.
Fordelen er, at man undgår, at de samme data ligger mange forskellige steder.
Søren Lauesen mener imidlertid, at det er en 'urealistisk drøm,' og at det 'selvfølgelig' er umuligt at holde en høj oppetid, når et system er afhængigt af at blive fodret med data fra mange andre systemer.
Kundernes skyld
I professorerens optællinger er det i et stort antal tilfælde kundens fejl, at et projekt løber af sporet.
Søren Lauesen siger til Samdata, at han opererer med 33 forskellige årsager til havarier af it-projekter.
Heraf står kunderne for de 28, mens leverandørerne kun er medskyldige i de 12. Eksterne konsulenter står for de sidste seks.
"Endelig har regeringen skylden i tre tilfælde - for eksempel når den oversælger Service Orienteret Arkitektur eller anbefaler en fler-leverandør-strategi, som er uhensigtsmæssig. Når en kommune har seks leverandører, som hver har monopol på deres område, så skal de holde styr på langt flere leverandører. Dermed er der mere, der kan gå galt," siger Søren Lauesen til bladet.
Han har fem gode råd til at undgå problemer:
- Test tidligt.
- Formuler specs som problemorienterede krav.
- Brug pilot-test i stedet for at rulle hele løsningen ud.
- Få kunden til at specificere hvilke regler og love, der skal overholdes.
- Formuler en reel og ærlig risikvurdering.
Se hele Søren Lauesens interview med Samdata her: Klassiske it-fejl koster nationen milliarder.
