Forslag om it-havarikommission får støtte på Christiansborg

Dansk Folkepartis it-ordfører støtter nu Poul-Henning Kamps mærkesag om en it-havarikommission. Han vil prøve at få et flertal i Folketinget med på idéen.

Hvis et tog ikke kan bremse, eller et fly har været involveret i en ulykke, rykker eksperter fra havarikommissioner for jernbane og luftfart ud og undersøger situationen nøje. Målet er at finde fejlene, så man fremover kan tage højde for dem og hæve sikkerheden generelt.

Samme konstruktion bør Danmark have på it-området, har det lydt fra Version2’s blogger og selvstændig systemudvikler Poul-Henning Kamp i årevis. Og nu er hans opråb nået igennem murene til Christiansborg.

Dansk Folkeparti støtter nemlig nu idéen om en it-havarikommission, fortæller partiets it-ordfører Dennis Flydtkjær, som i første omgang nævnte konceptet i en udsendelse på Radio 24syv.

»Jeg har først set Poul-Henning Kamps forslag i en debat på Version2 her for nyligt, og så det ikke dengang, han først foreslog det. Men det lyder som en rigtig fornuftig idé, for vi ser jo gang på gang, at it-systemer kuldsejler,« siger Dennis Flydtkjær til Version2.

Det er ikke så tit, at it-problemer bringer liv i fare, så fejlslagne projekter har mest været til skade for statens finanser. For eksempel da Rigspolitiet og justitsministeriet måtte opgive at få gjort Polsag-systemet brugbart og derfor skrottede hele systemet, efter at have brugt over en halv milliard kroner på projektet.

»Det skal ikke være for at pege fingre, men for at få mest muligt ud af skattekronerne,« understreger Dennis Flydtkjær.

Mindretal kan blive til flertal efter valg

I dag er det meget forskelligt, hvordan fejl i et it-system eller et helt projekt-kollaps bliver håndteret. Er der gået mange skattekroner til spilde, går Rigsrevisionen måske ind i sagen og hyrer it-eksperter ind. Andre gange er det op til ejerne af projektet selv at lave en evaluering af problemerne.

»Man ser jo til en hvis grad allerede i dag på, hvad der går galt. Når Polsag går ned, ser vi på det. Men det skal systematiseres, så det bliver eksterne folk, der kommer og objektivt kan se, hvad der gik galt. Der er mange erfaringer, vi kan få på den måde, for det sker jo løbende, at noget bliver forsinket eller alt for dyrt,« siger it-ordføreren.

Han har ikke fået promoveret idéen i Folketinget endnu, for lige nu har han travlt med valgkampen op til kommunal- og regionsvalget den 19. november. Men når det er overstået, vil han prøve at samle opbakning blandt regeringen og sine it-ordfører-kolleger på Christiansborg.

»Det nemmeste vil være, hvis regeringen synes, det er en god idé, så jeg vil foreslå det for finansministeren og prøve at overbevise ham. Jeg kan også stille det som forslag, og så kan det være, vi kan for flertal uden om regeringen,« siger Dennis Flydtkjær.

Selv hvis han kun kan få et mindretal i Folketinget til at støtte idéen, kan det være frugtbart på længere sigt.

»Hvis jeg kan få for eksempel hele den borgerlige blok med, vil det lægge et større pres på regeringen. Det kan også være, at det ikke bliver til noget i denne omgang, men at den borgerlige blok efter et valg har flertal og kan gennemføre idéen,« siger Dennis Flydtkjær.

Læs Poul-Hennings Kamps forslag til en it-havarikommission:

Læs også: IT haverikommission, NU!

Blogindlæg på Ing.dk fra februar 2012

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (17)
Jørgen Elgaard Larsen

Det er fint nok at finde ud af, hvorfor (IT)-projekter går galt. Men det hjælper ikke noget, hvis den viden ikke bruges bagefter.

I flyindustrien virker havarikommisioner kun fordi fundne fejl munder ud i regler, som alle skal overholde.

Hvis en IT-haverikommision skal gøre gavn, skal dens opdagelser på samme måde munde ud i nye regler.

Desværre er IT langt mindre uhåndgribeligt end fly. En flyhaverikommision kan finde ud af, at flyet styrtede fordi klimningsrefraktionsskruen(*) knækkede. Det kan føre til en regel om, at sådan en fremover skal være lavet af stål i stedet for zink.

I et IT-projekt vil man typisk finde ud af, at ting gik galt fordi hverken opdragsstiller eller leverandør forstod projektet fuldt ud inden de gik i gang. Og fordi kontrakten var uklar. Og fordi kommunikationen gik galt. Og fordi opgaven var for kompliceret. Og fordi 117 andre ting.

Men hvordan laver man det til konkrete regler? Og hvem skal håndhæve dem?

Poul-Henning Kamp Blogger

Det er fint nok at finde ud af, hvorfor (IT)-projekter går galt. Men det hjælper ikke noget, hvis den viden ikke bruges bagefter.

Det er en fin balancegang: Hvis havarikommisionen skal kunne gøre sig arbejde, skal den være neutral og faktabaseret.

Derfor kan den hverken være regulerende, foreskrivende eller straffende.

Resultaterne skal naturligvis bruges og jeg kan ikke forestille mig andet end at EU-udbud vil komme til at indeholde tekst om at følge ITHK's anvisninger. Ellers er køberne jo direkte dumme.

Markus Laursen

Jeg ser allerede de politiske argumenterne for mig, om at de seneste tilføjelser til statens it-projektmodel skulle gøre det overflødigt med en IT-havarikommission. Som en it-projektleder sagde til mig: det ikke er modeller og regler men mennesker, der i sidste ende står får udførslen, og jeg vil tilføje- god som dårlig og for piloter som for it-folk.

En strøtanke er desuden, at det er vigtigt også at fokusere på succeserne, da læring fra disse også kan give meget værdifuldt input, givet et formål om at gøre det bedre i fremtiden. Ikke at det skal være en havarikommissions arbejde.

Det bliver spændende at se, hvor grænsen mellem fiasko og succes vil blive trukket, og hvordan budget, timing og kvalitet bliver vægtet samt om fokus bliver på leverancer eller formål og gevinster.

Martin Juhl Jørgensen

Desværre er IT langt mindre uhåndgribeligt end fly. En flyhaverikommision kan finde ud af, at flyet styrtede fordi klimningsrefraktionsskruen(*) knækkede.

Rent spekulativt vil jeg tro at der findes en frygtelig masse flyhavarier man aldrig rigtig er blevet klogere på, fordi man manglede tilgængelig information. Deraf kom kravet vel om at al data og kommunikation skulle gemmes, bare sådan lige i tilfælde det skulle gå galt. Man kan jo være heldig at det kan være noget simpelt, men hvad hvis det var et frossent pitotrør der gav fejlagtige målinger til en navigationskomputer + inkompetente piloter etc.

I et IT-projekt vil man typisk finde ud af, at ting gik galt fordi hverken opdragsstiller eller leverandør forstod projektet fuldt ud inden de gik i gang. Og fordi kontrakten var uklar. Og fordi kommunikationen gik galt. Og fordi opgaven var for kompliceret. Og fordi 117 andre ting.

Der findes allerede Statens IT projektråd der burde afhjælpe med den slags i opløbet.

Derudover vil jeg gerne endnu engang gerne lige slå et slag for nærulykker, "hov, vi var lige ved at ligge alle cpr-nr ud i klartekst på forsiden" -- "hov, elektronkanonens intensitet var sat til byte16 (navn) or ikke byte61 (cancer_gun) i Den Fælles Patientjournal". Nærulykker ser luftfartsmyndighederne i hvert fald ikke stort på.

Ole Laursen

I flyindustrien virker havarikommisioner kun fordi fundne fejl munder ud i regler, som alle skal overholde.

Jeg er absolut ikke ekspert på området, men ud fra de små ting jeg ved så lyder det meget firkantet stillet op, og jeg tror ikke du har ret. Tror mere på at den største del af bidraget kommer fra mere viden. Det er en ting at have en regel om at man skal gøre et eller andet, det er noget andet at vide at dengang i 1985 hvor man ikke gjorde det, der døde 102 mennesker.

Det er enormt gavnligt at fremelske en kultur hvor man observerer og bliver klogere. Kan kun sige tak til PHK for at have sat skuden i søen, lad os håbe det bliver til noget. :)

Ole Laursen

I et IT-projekt vil man typisk finde ud af, at ting gik galt fordi hverken opdragsstiller eller leverandør forstod projektet fuldt ud inden de gik i gang. Og fordi kontrakten var uklar. Og fordi kommunikationen gik galt. Og fordi opgaven var for kompliceret. Og fordi 117 andre ting.

Angående dette: som min salig underviser i softwareledelse på universitetet bemærkede, så skyldes mange fejlslagne projekter en dårlig strategi der ikke er tilpasset til situationen. F.eks. at man har ringe forståelse for problemet og alligevel kaster sig ud en kompliceret upfront-designet løsning der ikke er klar til test før 2 år senere.

Jeg forventer mig af en it-havarikommission at vi kunne få sat spot på dårlige strategivalg. Nogle gange kommer disse af usunde organisatoriske strukturer, hvad der jo nok skal en ekstern uvildig part til at påpege.

Lars Severin Klausen

Mangler vi teoretisk viden om at gennemføre projekter og forandringer? Nej! Udfordringen er bl.a. at anvende det vi allerede ved meget mere effektivt samt ikke mindst, at de forretningsansvarlige projektejere og styregruppemedlemmer opprioriterer denne rolle i forhold til deres driftsopgaver. Så kære projektejere, tag lederskab, foretag de nødvendige prioriteringer ud fra en forretningsmæssig tilgang, sørg for de nødvendige ressourcer og glem ikke det vigtigste, den menneskelige faktor og motivation på alle niveauer. Flere kommissioner og udvalg risikerer blot at udvande det konkrete forretningsmæssige ansvar.

Log ind eller Opret konto for at kommentere
Pressemeddelelser

Welcome to the Cloud Integration Enablement Day (Bring your own laptop)

On this track, we will give you the chance to become a "Cloud First" data integration specialist.
15. nov 2017

Silicom i Søborg har fået stærk vind i sejlene…

Silicom Denmark arbejder med cutting-edge teknologier og er helt fremme hvad angår FPGA teknologien, som har eksisteret i over 20 år.
22. sep 2017

Conference: How AI and Machine Learning can accelerate your business growth

Can Artificial Intelligence (AI) and Machine Learning bring actual value to your business? Will it supercharge growth? How do other businesses leverage AI and Machine Learning?
13. sep 2017
Jobfinder Logo
Job fra Jobfinder