Søren Lauesen: Offentlige it-kunder overvurderer egne evner og forplumrer it-kravspecs
Ublu tekniske krav, udpegning af brugere til systemudviklere, datatræk fra alt for mange eksterne it-systemer og helt forkert håndtering af kravspecifikationen.
Det er fire af hovedårsagerne til, at offentlige it-projekter går galt, lyder det fra professor Søren Lauesen, IT-Universitetet, i en artikel på Samdata.
»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.
»Man skal i stedet beskrive, hvad det er for arbejdssituationer, systemet skal bruges i. Det har den store fordel, at kravsspecifikationen kommer til at fylde en femtedel eller en tiendedel.«
Diskussionen er interessant, netop som Finansministeriet har udgivet en rapport om statens 4000 it-systemer, der viser, at flere af de 428 it-systemer, som er kritiske for vores samfund, er i dårlig stand.
Søren Lauesen har undersøgt adskillige af de store sager, blandt andet som ekspert for Rigsrevisorerne. Og der er ikke én bestemt årsag til, at tingene går galt. Han har gennem årene lavet en liste på 33 klassiske årsager.
Og IT-brølerne er ikke små. Det kan nemt have seriøse konsekvenser, når tingene går galt, forklarer han.
»Hvis man tager Den Digitale Tinglysning, så betød systemskiftet, at det forsinkede mange folks hushandler i et halvt år, og dermed bragte man mange danskeres privatøkonomi i fare.«
Søren Lauesen har analyseret årsagerne til, at det gik galt med netop Den Digitale Tinglysning, og han kalder sagen for et fremragende lærestykke i, hvad der kan gå galt – og dermed en perfekt advarselsliste for andre.
Dyrt at kræve ind
Søren Lauesen vurderer, at opgavebestillerne ofte overser konsekvenserne, når de opremser alle de ting, som de gerne vil have med i systemet.
»Man kræver bare ind og tror, at det er gratis. Tag sådan noget som tilgængelighed (oppetiden). Det koster 10 millioner kroner mere at have en tilgængelighed på 99,9 procent i forhold til, hvis man kan nøjes med 99,5 procent. Hvis man som bestiller i stedet tillader leverandøren at tilbyde flere muligheder, så kan man selv vælge om man vil have den dyre eller den billige.«
ITU-professoren langer i samme runde ud efter en af tidens andre mode-fænomener, som også står på listen over årsager til IT-katastrofer: Service Orienteret Arkitektur (SOA), hvor IT-systemer trækker data fra andre systemer for at undgå at ligge inde med kopier af andres datasæt.
»Det er en urealistisk drøm. Tinglysningssystemet skulle trække på hele 10 andre systemer, fx på CPR-oplysninger, og det er selvfølgelig umuligt at holde en høj oppetid, når man er afhængig af så mange andre systemer.«
»I Tinglysningsaffæren gav det også forsinkelser, at man ikke var opmærksom på, at leverandøren ikke arbejdede på systemet de første måneder, fordi man havde mistet nogle topfolk. Alene det kostede et halvt års forsinkelse,« fortæller Søren Lauesen til Samdata,
Han understreger, at en af de svære ting i et IT-projekt faktisk er at overvåge, at der er fremskridt i projektet i den første planlægningsfase.
Dommere gjort til usability-ekspert
En anden klassiker er, at man ikke henter de rette eksperter ind tidligt i forløbet. Da man skulle lave Den Digitale Tinglysning begyndte man først at designe skærmbilleder fem måneder før lanceringen.
»Man havde sat en tinglysningsdommer til at designe skærmbillederne i systemet sammen med en grafisk designer. Resultatet var, at man fik et system, hvor man skulle igennem 22 skærmbilleder for at registrere en hushandel og ikke mindst et system, som kun en dommer kunne finde ud af bruge,« fortæller Søren Lauesen.
»Det problem kunne have været undgået, hvis man havde gjort som UX’ere altid beder om: At man henter usability-eksperter ind tidligt i forløbet, så man kan lave simple produktions-dummies, der bliver testet tidligt i forløbet – før man begynder at kode.«
Da man skulle lancere Den Digitale Tinglysning skete det med udgangspunkt i en beregning, der sagde, at man kunne spare en masse penge. Problemet var blot, at man høstede rationaliseringsgevinsten – før systemet var i drift.
»200 tinglysningsmedarbejdere vidste, at de skulle fyres, når systemet var indført. Det betød selvfølgelig, at de begyndte at forlade skuden op til lanceringen. Når projektet pludseligt tog 1½ år længere, så havde man ikke længere kvalificerede medarbejdere men vikarer, som brugte længere tid om at ekspedere sagerne,« fortæller Søren Lauesen.
Kunderne årsag til flest fejl
Søren Lauesen har efterhånden undersøgt en stribe større IT-projekter, og hans erfaring er, at en stor del af fejlene går igen fra projekt til projekt. Han opdager dog et par nye fejl, hver gang han er ude på nye opgaver, eller når han bliver kontaktet af whistle-blowere. Derfor er han også tilhænger af en IT-havarikommission, som kan videreformidle erfaringerne og dermed mindske risikoen for, at man gentager allerede kendte fejl.
Det er alle parter i projekterne, der er medvirkende til fejlene. Kunden står dog for en overraskende stor del.
»Af de 33 forskellige årsager til IT-katastrofer, jeg opererer med, så er det kunden, der bestiller opgaverne, der står for hele 28 af årsagerne, mens leverandørerne er skyldige eller medskyldige i 12. Konsulenter, der trækkes ind, er medansvarlige i seks af årsagerne.«
»Endelig har regeringen skylden i tre tilfælde – fx når de 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.«
...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.
