Søren Lauesen: Offentlige it-kunder overvurderer egne evner og forplumrer it-kravspecs

Ud af 33 identificerede årsager til IT-katastrofer, som it-professor Søren Lauesen, IT-Universitetet, opererer med, så er det kunden, der bestiller opgaverne, der står for hele 28 af årsagerne.

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.

Læs også: Finansministeriet: Hver tredje statslige it-system risikerer nedbrud og hackerangreb

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

Læs også: ITU-professor: Amatøragtigt forarbejde gjorde EFI og Polsag til IT-skandaler

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

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (14)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Brian Schmidt Pedersen

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

Nu er jeg relativ uvidende på området omkring kravspecifikationer, så håber lidt at jeg har misforstået noget i min opfattelse, når jeg læser det citerede.

Som jeg forstår det citerede, så lyder det da som om at det måske ganske vist giver mindre kravspecifikationer, men til gengæld giver kæmpe hovedpiner med kontraktstyring, brede fortolkninger og uendelige diskussioner med leverandøren om hvorvidt et behov dækkes på den ene eller anden måde, hvilket jo i sidste ende bunder ud i store efterudgifter fordi at kravspecifikationen netop var for "tynd".

Når man ser/læser om leverandører byde ind på opgaver/projekter, synes jeg gang på gang at man ser/læser at udbuddet bliver vundet på økonomi (billigst), og det efterfølgende viser sig at der kommer kæmpe udgifter, fordi kravspecifikationerne ikke var gode nok. Jeg mistænker at mange leverandører spekulerer i dette og bevidst underbyder, fordi de ved at de efterfølgende kan komme og påpege at en ønsket funktionalitet ikke er beskrevet i kravspecifikationen, og derfor er en ekstra feature som koster dyre udviklingstimer.

  • 4
  • 0
Lise Gerd Pedersen

... kunden skal beskrive, hvilken funktionalitet systemet skal stille til rådighed i forbindelse med kundens arbejdsproces, men så vidt muligt skal prøve at undgå at låse designet fast i kravspecifikationen (fx fastlægge skærmbillederne). Det kan være en fordel for alle parter, hvis leverandørens ekspertise og erfaring får lov at præge løsningen.

Så jo, man skal beskrive hvad, systemet skal gøre, men ikke nødvendigvis hvordan, det skal gøres.

Er der generelle krav til designet (fx en designmanual, der skal overholdes), skal det med som et krav.

  • 2
  • 0
Lise Gerd Pedersen

... at det offentlige ikke skal have en fler-leverandør-strategi! De skal netop tage ansvaret for IT på sig i en sådan grad, at de er i stand til at definere og udbyde udviklings- og driftsopgaverne til private firmaer. Gerne i mindre klumper.

Hvis en privat leverandør går neden om og hjem (eller bliver for dyr), skal det offentlige have så meget viden om systemerne, at man kan overdrage videreudviklingen og driften til en anden leverandør. Man skal ifølge loven i øvrigt også kunne udbyde disse opgaver med jævne mellemrum ... hvilket i nogle tilfælde ikke sker, fordi man ganske simpelt ikke er i stand til at beskrive det, der skal gives tilbud på.

Så når man nu alligevel skal have styr på sin enterprise arkitektur og sine systemer, hvorfor så ikke benytte markedskræfterne til at få bud fra flere leverandører, i stedet for at låse sig fast til én?

  • 5
  • 0
Denny Christensen

... er netop at beskrive behovet i dagligdagen, ikke skærmbilleder, database beskrivelser etc - men jeg er enig i at der kommer en afklaringsfase og at meget stadig kan gå galt der, eftersom køber næppe vil overlade det hele til leverandøren.

Et sådant projekt har jeg for nylig været med i og selv om det da også gav diskussioner af den mere bombastiske slags, også med hensyn til hvad der kunne forventes til den aftalte pris, så var det en bedre metodik end at kunden specificerede alt i detaljer.

  • 1
  • 0
Jesper Frimann

Så når man nu alligevel skal have styr på sin enterprise arkitektur og sine systemer, hvorfor så ikke benytte markedskræfterne til at få bud fra flere leverandører, i stedet for at låse sig fast til én?


Lige netop. Men det er jo her, at kultur problemerne starter. Igen vi kommer fra en situation, hvor offentlig IT i høj grad var isoleret i 'nogle' offentlige virksomheder, og da man 'skar' dem fra så var det med den bagtanke, at så skulle man ikke have alle de der dyre IT-folk, der blandede sig mere, så ville snitfladen være en rent 'offentlig forretning' mod private IT-leverandører.

Problemet er bare at offentlig service i høj grad i dag er så gennemsyret af IT, at det så at sige på sin vis er en 'IT-forretning'. Og det betyder, at man er nødt til at have en stærk og solid IT-viden i organisationen. Og da man skar de store offentlige IT selskaber fra.. så forsvandt langt det meste af den viden og ekspertise, der var essentiel for at tingen kunne fungere smertefrit. Man er da kommet efter det, men IMHO er man ikke engang nået tilbage på det niveau man var før 'cuttet'.

Og det har toppen af 'den offentlige administration' ikke fattet endnu, der sidder mange godt folk rund omkring i Kombit, Statens IT m.m. som har fattet det og som råber på EA, men man har bare ikke forstået det endnu i toppen.
Jeg er meget enig i det du siger, at det offentlige skal have en ordentlig rigtig IT-org gerne en der f.eks. er virtuelt forankret et sted, og så giver "mandatory IT-faglig direction" til naturlige mere decentrale organisatoriske IT enheder.
For så kan man, som du også skriver, reducerer problemerne til noget der kan løses af private underleverandører. Og hvor man kan flytte sin forretning rundt.

Men det kræver at man implementerer ting som EA, SIAM m.m. centralt og decentralt.

Det er en stor opgave.. og ja.. det kræver at man giver slip på sådan noget som IT-strategi og sætter IT kyndige til at lave det, i stedet for folk med økonomi, og administrations uddannelser.

// Jesper

  • 1
  • 0
Rolf Kristensen

Måske kan problemet også være der før har været mange fusere. Kan i hvert nemt genkende problemet med en krav specifikation som er åben for mange løsninger tit ender med at blive løst på en ikke hensigtsmæssig måde (manglende performance, sikkerhed, fejlhåndtering, etc.). Hvorefter den efterfølgende process handler om at bøje den forkerte løsning om til det noget som kan bruges med hjælp af en hel masse elastikker og gaffatape. Resultatet er ikke smukt.

Så kan jeg godt forestå at man vælger at specificere en middelmådig men brugbar løsning fra start netop for at undgå dette problem. Hvis leverandøren er stærk nok, og ved hvad det går ud på, så er jeg sikker på at kunden vil acceptere en overlegn løsning frem for den middelmådige. Tror det det tit ender med at leverandøren med sine outsourcing partnere er lidt dovne og bruger alt tiden på at ramme den middelmådige løsning helt præcist, i stedet for at tage tænke hatten på.

  • 0
  • 0
Jesper Frimann

Så kan jeg godt forestå at man vælger at specificere en middelmådig men brugbar løsning fra start netop for at undgå dette problem. Hvis leverandøren er stærk nok, og ved hvad det går ud på, så er jeg sikker på at kunden vil acceptere en overlegn løsning frem for den middelmådige.


Ja det lyder jo logisk, smart og lidt af en nobrainer. Men det du jo skal huske på er, at tit så har den offentlige institution, der har lavet udbudet jo ikke den nødvendige viden til at kunne forstå/indse/vide, hvad der er en overlegen løsning. Og ofte vil du have med folk at gøre, der 'bare' eksekverer på den kontrakt eller den specifikation de nu har fået.

Lad mig give dig et eksempel fra den virkelige verden, et eksempel fra det simpleste og nederste lag i en løsning stak.
Et sted jeg arbejde engang driftede man en løsning for et ministerie. Det var dyrt software der kørte på noget gammelt *NIX hardware og på noget state of the art *NIX hardware.
Da det gamle *NIX hardware skulle refresh'es, gav vi et statement of work på kundens RFC på at flytte det system der kørte på en .. defacto EOL platform over på samme platform som resten af systemet, kørte på.
Ekstra kosten på at lave et platforms skift var 'betalt' via besparelsen på hardware, og man (ministeriet) ville også spare en mindre formue i licenser, da vi gik en klasse ned i fysisk server, og ville bruge færre licenser (hurtigere cores). Ud over at vi forventede hurtigere svartider og større kapacitet.
Men.. der løb vi hovedet mod en mur. Simpelt hen fordi ministeriet læste kontrakten således, at der stod at de skulle have en ny museumsgenstand sat op, for det var jo en platforms refresh.
Det var som at løbe hovedet mod beton, og som arkitekt var det frustrerende at sidde over for embedsmænd og jurister, hvis eneste respons var, vi vil ha hvad der står i kontrakten.....

// Jesper

  • 1
  • 0
Lars Christensen

Hvorfor benyttes der egentlig ikke en uafhængig projektkoordinator, der kan vejlede både kunde og leverandør og som betales i fællesskab af begge parter, f.eks. som et tillæg/krav ved indgåelse af offentlig/private udviklingskontrakter?
Projektkoordinatoren er ikke projektleder, men søger at finde den overordnede røde tråd, og via rådgivning at rette begge parter ind efter denne.
Dermed kunne både kunden og leverandøren benytte f.eks. en kapacitet som Søren Lauesen og sandsynligvis slippe for mange af de skøre it-problemer vi hører om i disse år.

  • 0
  • 0
Rolf Kristensen

Det er jo ikke brodne kar, det er jo folk der ikke forstår hvad RAM eller en CPU er

Tror vi kan skændes længe om hvor enige vi er. Men for mig så er uvidenhed/inkompetence/arrogance/ligegyldighed alle sammen egenskaber som modarbejdet målet. Hvis nogen påstår at de har en god løsning, så bør man som det mindste prøve at sætte sig ind i den løsning (eller finde nogen der kan) frem for at blive siddende i sit elfenbenstårn.

  • 0
  • 0
Rolf Kristensen

Hvorfor benyttes der egentlig ikke en uafhængig projektkoordinator?

Tror ikke at endnu et abstraktions lag vil løse problemet. Det vil mere være en skjold som inkompetente folk kan misbruge. Sjældent at projektkoordinator er personen tynget af uendelig forretningsviden, men mere den som får tingene til glide fremad i stedet for opgaver og ubesvarede spørgsmål sidder stille i en mail-boks.

Hvis noget, så kunne kunden ansætte en byggesagkyndig som kunne lave løbende design og kode-reviews, og lave anmærkninger hvis der er problemer med fugt i kælderen.

  • 0
  • 0
Tonni Pedersen

"Da det gamle *NIX hardware skulle refresh'es, gav vi et statement of work på kundens RFC på at flytte det system der kørte på en .. defacto EOL platform over på samme platform som resten af systemet, kørte på."
Nogle gange er man nødt til at målrette sit sprog til modtageren, det kunne jo også være at det er her at hunden lå begravet. Som fagfolk er vi nok engang imellem for dårlige til at forstå at det som er logik for os, kan være sort snak for dem udenfor kredsen.

  • 1
  • 0
Log ind eller Opret konto for at kommentere
IT Company Rank
maximize minimize