Corydon siger nej til it-havarikommission

Flere it-ordførere på Christiansborg er positive over for forslaget om en it-havarikommission. Men finansminister Bjarne Corydon afviser idéen.

I kølvandet på fejlslagne offentlige it-projekter og millioner af spildte skattekroner har Version2-blogger Poul-Henning Kamp i længere tid efterspurgt en havarikommission, der blandt andet skal gå de kuldsejlede projekter efter i sømmene.

Tidligere på måneden rykkede spørgsmålet så ind på Christiansborg, da Dansk Folkepartis it-ordfører, Dennis Flydtkjær, stillede finansminister Bjarne Corydon et §20-spørgsmål om hans holdning til en it-havarikommission.

»Hvad er ministerens holdning til at oprette en it-havarikommission i Danmark?«, lød spørgsmålet.

Også Venstres it-ordfører meldte sig positiv over for idéen om en it-havarikommission, men i sit svar slår Bjarne Corydon fast, at det ikke er noget, han ser nogen grund til at indføre. Statens it-projektråd gør den nødvendige indsats i forvejen, og det er for tidligt at sige, om det er behov for yderligere tiltag på området, lyder argumentet.

Læs også: Dansk Folkeparti skyder kamp for it-havarikommission i gang

»Det er et langt, sejt træk at forbedre ministeriernes gennemførsel af større it-projekter, men det er min opfattelse, at etableringen af endnu en myndighed, en it-havarikommission, vil overlappe den indsats, der allerede er etableret i
Finansministeriet med Ministeriernes projektkontor og Statens It-projektråd«, hedder det i finansministerens svar.

På trods af flere eksempler på offentlige it-fiaskoer, blandt andet rigspolitiets skrinlagte skandale-projekt, POLSAG, der endte med at koste mere end 500 millioner kroner, mener heller ikke brancheorganisationen IT-branchen, at en havarikommission er nødvendig.

I lighed med finansministeren mener man, at de nødvendige analyser foretages i forvejen, og formand for organisationens udvalg for digital forvaltning, Michael Holk Wätjen, meldte i sidste uge ud, at en it-havarikommission vil være ”spild af tid og penge”.

Dennis Flydtkjær har ikke besvaret Version2s henvendelse inden publiceringen af denne artikel.

Læs også: It-Branchen: Havarikommission spild af tid og penge

Læs også: IT haverikommission, NU!

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (18)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Markus Hornum-Stenz

Nu vil jeg måske blive skudt i skoene at jeg bare vil holde hånden over egne og gode kollegaer, men jeg er enig med Corydons melding.
AT finde frem til hvad årsagen er til at et projekt slår fejl, er at lægge en politisk proces oven på en anden.
Offentlige IT-projekter (og sikkert også private) havarerer sikkert af mange årsager, men de mest fremtrædende at man overspecificerer på den ene side, oversælger på den anden og/eller simpelthen ikke hånterer aftalemæssigt at man ikke kender opgavens omfang i starten.
Forestillingen om at man kan ændre på dette gennem feedback fra en havarikommision er forståelig, men ærlig talt en anelse naiv. Der er ikke nogen "black box" i et IT-projekt

  • 8
  • 20
Henrik Korsgaard

Jeg er helt med på hvorfor man ønsker at holde kortene tættere på kroppen, bevare illusionen af kontrol og i det hele taget sikre mindre gennemsigtighed i den nær-politiske offentlige forvaltning. Corydon tænker som en embedsmand i en kontrol kultur og ønsker bestemt ikke åbenhed og dialog.

Men, at det skulle være spild af penge er vist at forregne sig. Uden at lave et detaljeret regnestykke, siger min finger-i-vejret-vurdering mig, at bare et vellykket offentligt IT projekt der holder budget og tid, vil kunne finansiere en sådan IT-havarikommission. En IT- havarikommission kan både belyse grundlæggende udfordringer omkring udbud, specifikationer, ansvar og samtidig have en afskrækkende effekt. Hvis nu en tænkt virksomhed, lad os kalde den DTD, havde været forbi kommissionen 5 gange, så kunne man måske forsvare at de skulle suspenderes fra offentlige IT-projekter i en periode. Måske man også fandt problemer i hvordan embedsværket tænker IT?

Jeg kan ikke se et IT-fagligt eller samfundsøkonomisk argument for, at man ikke skulle have en IT- havarikommission. Jeg kan sagtens finde argumenter i relation til at bevare kontrollen, definitionsretten på succes og embedsvældet, men den slags argumenter er til gengæld spild af penge og ikke særlig demokratiske.

  • 18
  • 1
Pauli Østerø

Offentlige IT-projekter (og sikkert også private) havarerer sikkert af mange årsager, men de mest fremtrædende at man overspecificerer på den ene side, oversælger på den anden og/eller simpelthen ikke hånterer aftalemæssigt at man ikke kender opgavens omfang i starten.

Hvis det virkelig er så alment kendt, hvorfor sker det så igen og igen og igen og igen!?

Definition på sindssyge er "at man bliver ved med at gøre de samme ting igen og igen, i forventning om et nyt resultat". Ergo har vi en flok sindssyge folk sidende på borgen hvis de ikke vil erkende at der måske bør tænkes i nye baner hvis vi skal kunne få et bedre resultat.

  • 16
  • 2
Thomas Vestergaard

Ergo har vi en flok sindssyge folk sidende på borgen hvis de ikke vil erkende at der måske bør tænkes i nye baner hvis vi skal kunne få et bedre resultat.


Nu er det jo ikke folkene på borgen, der driver projekterne. Målet skal være at opsamle viden i de organisationer, der ejer projekterne.

Når det er sagt, er jeg ikke overbevist om, at de ikke også er tossede nok til at forsøge det samme igen igen i håb om et nyt resultat.

  • 1
  • 2
Hans Schou

mener man, at de nødvendige analyser foretages i forvejen

Ja det er lige præcis det som kommissionen skal lave. Forskellen er bare at kommissionen skal kigge på alle fejlslagne projekter, ikke kun dem som ministeren mener er værd at kigge på. POLSAG fra 2007 (et forholdsvis nyt projekt), må bare ikke gentage sig, men hvilke tiltag gør man?

Rent faktisk burde man også evaluere dem der gik godt, for så at kunne drysse dette stjernestøv ned over fremtidige projekter.

  • 16
  • 0
David Rechnagel Udsen

Jeg er helt med på hvorfor man ønsker at holde kortene tættere på kroppen, bevare illusionen af kontrol og i det hele taget sikre mindre gennemsigtighed i den nær-politiske offentlige forvaltning. Corydon tænker som en embedsmand i en kontrol kultur og ønsker bestemt ikke åbenhed og dialog.

Det er der intet nyt i. Corydon har konsekvent opført sig sådan i stort set alle sager. Tag sagen om salget af DONG. Jeg tror sågar at den eneste grund til, at han ikke har sagt »der er intet at komme efter« endnu, er fordi det er et Anders Fogh citat. Corydon har en helt klar kurs, og den skal ingen rokke på.

  • 16
  • 0
Carsten Olsen

Der er ikke nogen "black box" i et IT-projekt


Nej men det kunne der komme. (mon ikke "black box" er indført fordi havarikommissionen syntes der skal være dataindsamling før havariet sker)

Men hvis man skal indfører en havarikommission så skal det være på samme vilkår som for luftfart. Her er havarikommissionens anbefalinger noget der følges af Statens Luftfartsvæsen UDEN indblanding fra politikkere og DJØFer. Dette netop fordi politikere og DJØFer ikke har den ringeste ide om luftfart. I det hele taget kunne "det offentlige" godt bruge nogen folk med kompetance på IT området, man kunne fyrer 100 DJØFer og ansætte 50 teknikere. (Besparelse)

Hvis man overfører ovenstående på IT.: Så har politikere og DJØFer ikke den ringeste ide om IT. Så de må overlade det til nogen der har (forstand). Her er virksomhederne inhabile. Dette er noget det offentlige ikke har kompetance til nu. Men de kunne jo ansætte nogen teknikere der har. (DJØFer er der IKKE brug for i denne forbindelse)

  • 10
  • 2
Michael Kjeldsen

På trods af flere eksempler på offentlige it-fiaskoer, blandt andet rigspolitiets skrinlagte skandale-projekt, POLSAG, der endte med at koste mere end 500 millioner kroner, mener heller ikke brancheorganisationen IT-branchen, at en havarikommission er nødvendig.

Quelle surprise...

  • 9
  • 0
Joe Sørensen

AT finde frem til hvad årsagen er til at et projekt slår fejl, er at lægge en politisk proces oven på en anden.


Nej. Det er at efterfølge en politisk proces med en teknisk. En havarikommission er jo nettop afskåret fra politisk indflydelse.
Og når vi nu er i den terminologi, så er der vidst også mange der har brug for at vide hvem "kaptajnen" er på et it projekt. Det er der ikke nogen tvivl om til søs og i luften, men i it projekter er der ingen der ansvarlige.

Hvis det virkelig er så alment kendt, hvorfor sker det så igen og igen og igen og igen!?


Ja, det er præcist fordi det ikke er almen viden.
Der er nogen der har den holdning, at grunden til at det går galt, er fordi it leverandøren er dumme, dovne og nærige. For at undgå at bliver ramt af deres dovenskab er det vigtig at specificere alle detaljer. Og selvfølgelig ikke fortælle noget om hvorfor det skal være sådan. Leverandøren er jo for dum til at forstå dette alligevel.
Samme mennesker ser også sådan på andre brancher og er ubehøvlede overfor personalet når de er på indkøb. Jeg ved ikke hvorfor de havner på ledende poster i det offentlige, men det er nok fordi de slet ikke kan sammen med det private erhvervsliv.

  • 13
  • 0
Markus Hornum-Stenz

Ang. black box:
En blackbox henter bare tekniske data ind via automatik. Tanken er så, at man med udgangspunkt i disse data, kan sige noget om hvorfor fx. et fly styrtede ned. Dette suppleres så med vidneudsagn og undersøgelser af vraget. Altsammen fint nok fordi spørgmålet er simpelt: Hvorfor styrtede flyet ned?
Analogien i IT-projekter er jo ikke server logs, men mødereferater, mails etc. som er lavet (eller ikke lavet) af mennesker.
Datagrundlaget er med andre ord af en nogen anden og knap så entydig karakter.
Derfor vil den efterfølgende undersøgelse heller ikke være teknisk. Det vil være en menneskelig(politisk) styrkeprøve i CMA og mere minde om en juridisk undersøgelseskommision - og dem kommer der sjældent noget substantielt ud af.
Et nedbrud af et IT-system i drift kunne være velegnet til IT-havarikommisioner - som fx. da Rejsekortet gik ned forleden.
Udviklingen af et IT-system....jeg tror det ikke....der spiller alt for mange forskellige faktorer ind

  • 2
  • 4
Henrik Winther Jensen

De mennesker der skal indføre havarikommisionen, er også de mennesker som har travlt med at manøvrere i de politiske storme der opstår efter "havariet".
Disse mennesker er selvfølgeligt ikke interesseret i, at a-politiske teknikere skaber rav i den med udtalelser der ikke passer ind i deres dagsorden.

Derfor siger Corydon det han siger, og de politikere der går ind for ideen går kun ind for den, indtil de selv sidder med aben.

  • 6
  • 0
Pauli Østerø

Analogien i IT-projekter er jo ikke server logs, men mødereferater, mails etc. som er lavet (eller ikke lavet) af mennesker.

Er ikke helt enig med dig her. Ja, det er ofte simpelt at aflæse af en black box hvorfor et fly rent fysisk styrtede, det kan være der blev tanket for lidt brændstof eller et hjul eksploderede under landing.

Men nu skal vi også huske på de 5 Whys og kommer de i spil, så vil man selv i en Fly Havarikommission komme frem til at nogen på et eller andet har taget en beslutning som senere hen var fatal.

Hvorfor styrtede flyet ned? Fordi det løb tør for brændstof.
Hvorfor løb det tør for brændstof? Fordi der ikke blev tanket nok på.
Hvorfor blev der ikke tanket nok på? Fordi der blev regnet forkert mellem Liter og Gallons.
Hvorfor skulle der omregnes mellem Liter og Gallons? Fordi det var en amerikansk pilot i en europæisk lufthavn.
Hvorfor er vi ikke alle enige om at bruge de samme måleenheder?

Ud af disse 5 spørgsmål kan kun det første besvares af den sorte boks. Resten kan sagtens stilles i en ITHK og er ikke noget flyindustrien har patent på.

  • 11
  • 3
Morten Hattesen

Der er ikke nogen "black box" i et IT-projekt

Det er ikke nødvendigt at have en black-box i IT projekter, da det er yderst sjældent at dokumentation for projektforløb og økonomi går op i røg, når et IT projekt havarerer. Så opsamling af dokumentation er nok ikke det største problem i den sammenhæng.

  • 1
  • 3
peter larsen

Spørgsmålet er måske snarere om dem der indkøber projekterne er kvalificeret nok og har den nødvendige erfaring.

Hvorfor ikke samle alt offentligt indkøb i en enhed som tager sig af kravspecifikation, udbud, overvågning af udviklingen, test og implementering? Her vil man kunne samle den nødvendige ekspertise til at tage sig af hele processen. Samtidig vil man kunne holde begge partner lidt i ørerne.

Når jeg har læst om sagerne har jeg nogle gange tænkt på om der ikke har siddet nogle DJØF'er, der har sagt vi vil gerne have data om dit og dat. Alt sammen ting som lyder meget rationelt og fornuftigt, men når det helle lægges sammen ender det med at den stakkels medarbejder hos politiet eller jobcentret skal udfylde 20 skærmsider for at oprette en simpel bøde eller ny ledig. En central enhed burde kunne sige til DJØF'erne "Nu stopper I, er I klar over hvad dette betyder?".

Omvendt har jeg også tænkt på at hele udbudsrunden også betyder at leverandørerne presses til at gå på kompromis. Jeg tænkte på det i forbindelse med et eksamenssystem, hvor det gik ned fordi 10.000 elever koblede sig på samtidig. 10.000 er i virkeligheden ikke mange når man tænker på hvad Google, Microsoft, Amazon mv. har kørende. Er det fordi at leverandøren har følt sig presset til nøjes med en server selv om to var ideelt mv. for at få ordren. En central enhed vil letter kunne gennemskue om leverandørens tilbud er realistisk.

  • 3
  • 0
Markus Hornum-Stenz

det er yderst sjældent at dokumentation for projektforløb og økonomi går op i røg, når et IT projekt havarerer

Jeg er helt med på at den ikke går op i røg, den vil bare være mangelfuld. Man vil bare nemt stå i den situation at beslutninger, som senere viser sig at være kritiske, ikke er tilstrækkeligt dokumenteret.
Ofte er de dygtigste og hurtigste ressourcer stærkt efterspurgt, og når det går stærkt, så smutter dokumentationen ofte. Det er ikke nødvendigvis udtryk for dårlig projektstyring, kunsten er jo at balancere processen (effektivitet/prioritering/projektøkonomi) med målet (sikker, stabil og veldokumenteret idriftsættelse af et system som lever op til forventningerne)

Denne her kommer ikke ud af den blå luft:
http://biconsultancy.blogspot.dk/2012/11/different-views-to-it-project.html

  • 1
  • 2
Peter Møller

Problemet, som jeg ser det, ville så være en central enhed uden nødvendigt kendskab til domænet og de relevante processer.

Jeg tror problemet, til dels, skyldes at DJØF'ere har for meget at skulle have sagt ift. at få udarbejdet en kravsspec. der skal kunne redde køberens røv hvis ikke systemet fungerer.

Det er ikke nemt at vinde et udbud hvis man ikke opfylder udbudsmaterialet og hvis så materialet er en hæmsko for et ordentligt system.. ja så.

Flere, mindre og mere kompatible systemer er løsningen i min optik. Og hvis det så kan minimere DJØF'ernes behov for at lege Software-arkitekter så tror jeg vi kan nå langt:-)

  • 5
  • 1
Log ind eller Opret konto for at kommentere