Direktør: Nulfejls-kultur og manglende tillid er skyld i fejlramte digitaliseringsprojekter

Når digitaliseringsprojekterne sejler, så er det, fordi man i det offentlige ikke tør fejle, siger direktør i Formpipe.

Når store offentlige it-projekter som EFI og Polsag går i vasken, og andre projekter ikke kan indfri de lovede besparelser, som det sker ved Sundhedsplatformen, så skyldes det manglende tillid mellem leverandørerne og de offentlige indkøbere samt en virksomhedskultur, der ikke tolererer fejl.

Sådan ser administrerende direktør i Formpipe Thomas à Porta på det. Han har 10 års erfaring med udvikling af it til det offentlige på bagen, bl.a. som salgsdirektør og direktionsmedlem i KMD.

»Det offentlige har en nulfejlskultur. Det kommer til udtryk, når man for at undgå fejl prøver at beskrive yderst præcist, hvad man vil have, og så får en leverandør til at bygge præcist det. Realiteten er bare, at verden er fuldstændig anderledes, end man havde skrevet i udbuddet, når projektet så endelig er færdigt,« siger à Porta til Version2 i et interview.

Læs også: Sundhedsplatformen: Velkendt at business cases primært skal legitimere it-indkøb

Et fleksibelt system

Formpipe leverer elektroniske sags- og dokumenthåndterings (ESDH)-systemer til offentlige kunder og har udviklet et stort administrationssystem, der bruges til at søge om, sagsbehandle og udbetale EU’s landbrugsstøtte i Danmark for Landbrugsstyrelsen.

35.000 danske landmænd nyder godt af, at det er lykkedes Formpipe at automatisere 75 procent af ansøgningerne om landbrugsstøtte, og systemet håndterede en rekordstor belastning i februar på 1.300 ansøgninger på førstedagen for ansøgningsrunden. Brugerne kalder systemet ‘så godt som det kan blive.’

Succesen tilskriver à Porta, at det er lykkedes Formpipe og Landbrugsstyrelsen at bygge et fleksibelt system, der kan tilpasses lovændringer fra EU, at de er sluppet uden om nulfejlskulturen, samt at de har opnået gensidig tillid og godt samarbejde mellem sig.

»Jeg har prøvet det andre steder. Når en fejl opstår, så sidder kunden og leverandøren og venter på, at den anden blinker. Men når den anden blinker, er det altid for sent. Og så ender det med at blive meget dyrt at rette op på, eller at det forsinker projektet,« siger à Porta.

Læs også: Tidligere topembedsmand: Offentlig it sættes i værk hen over hovedet på brugerne

Vi må fejre dem, der tør fejle
For at undgå de rigide systemer, der opstår af de nøgterne produktkrav, mener à Porta, at vi i stedet skal finde nogle smartere udbudsformer, der lægger op til forhandlinger. Det fleksible system, der kan tilpasses reformer og nye krav, kommer, når leverandøren kan komme med forslag til ændringer.

»Der skal fra topledelsen hos kunden og hos leverandøren være jævnlige møder, hvor man deler ting, og hvor det ikke er et spil om, hvem der har fejlene. I stedet skal man skabe den her fælles forståelse af, at vi kun lykkes sammen, og det kræver modenhed og tillid,« siger han.

Der er også en tendens til dette for tiden, hvor bl.a. Region Syddanmark laver markedsdialog med potentielle leverandører, inden den formelle udbudsrunde starter. Thomas à Porta ser dog gerne, at denne samtale fortsætter inde i selve udbudsprocessen.

Hvordan man opnår den modenhed og tillid, en god dialog kræver, kan han dog ikke svare kortfattet på.

»Vi må jo erkende, at vi alle er mennesker og laver fejl. Men vi skal fejre de ledere, der tør gå forrest med det i det offentlige,« siger han.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (7)
Claus Juul

Jeg har set flere offentlige kontrakter Mv. Mit indtryk er ikke at de forsøger at beskrive alt til mindste detalje, jeg oplever at de på flere punkter er for generelle og ikke selv ved hvad det betyder.

Jeg mener at problemet er at man forsøger at slå et større brød op end man kan håndtere.

Det med nulfejls kulturen, tja det afhænger vel hvordan man anskuer det, hvis det er at skrive meget generelle vendinger og tror at man så har dække ryggen af, så har du nok ret.

Anne-Marie Krogsbøll

Hvis man tager f.eks. business casen til Sundhedsplatformen, så er den vel ikke ligefrem præget af nulfejlskultur som beskrevet ovenfor - det lyder mere genkendeligt, at man, som beskrevet for nogle dage siden i en artikel her, mest har brugt den som et figenblad for at få et projekt igennem - uanset om dette projekt var ordentligt gennemarbejdet eller ej.

Hvis der virkeligt var en nulfejlkultur, så må vi vel forvente, at der ryger en frygtelig masse hoveder meget snart i det projekt?

Denny Christensen

Jeg hylder nu stadig en kravspecifikation, vel at mærke een der angiver hvad man ønsker og så beder leverandøren om at beskrive hvordan de vil indfri de krav.

Så kan selve processen være agil og kommunikativ og meget andet, men som udgangspunkt er man nødt til at have en ide om at leverandøren kan levere og som leverandør hvad man kan forvente.

Business casen på sundhedsplatformen virker mere som en hoax - stærkere ord må man vist ikke bruge.

Simon Mikkelsen

Jeg genkender nogle ting, selvom jeg kun har siddet på projekter der endte godt. Frustrationerne er forskellige fra projekt til projekt.

Man beskriver én virkelighed og når projektet skal implementeres (kodes) finder man ud af at der er brug for noget helt andet, i forskellige variationer.

Udbudsreglerne givet størst problemer for mig på punktet tid: Der er aftalt en deadline og kan leverandøren ikke holde den vil en konkurrent kunne klage og kræve at udbuddet går om. Forestil jer at man lægger overtid og knokler for at levere til tiden, man når det, og så ligger resultatet på hylden hos kunden i et halvt år, fordi de ikke har tid til at teste det. Tak.

Men det offentlige kan være meget rigide. Når de sætter en contract manager til at få mest muligt for borgerenes penge, kan det betyde at man ikke vil betale for helt essentielle ting i processen. Hvis man som leverandør faktisk prøver at samarbejde, levere hvad der er brug for og være fleksibel, er det meget frustrerende at man bare får smækket i hovedet at man skulle have sørget for en bedre kontrakt. Det er også med til, at dem der gerne vil have gode produkter måske overlader markedet til dem som laver gode kontrakter og dårlige produkter.

Der er ingen tvivl om, at kompetancen softwareudviling - altså finde ud af hvad kunden har brug for og implementere det - ligger langt nede på listen over hvad man skal kunne, når man levere til det offentlige.

Udbudsreglerne har en væsentlig del af skylden. De antager at man kan brug jura til at beskrive et projekt som går godt, låse det, og så kan man ellers lade de værste plattenslagere byde ind. Men hvis man står med software der ikke virker, er det hamrende lige gyldigt om man kan få en bod eller har en god kontrakt. Det virker ikke. Operationen lykkedes men patienten døde.

Niels Henrik Sodemann

Udbudsreglerne har en væsentlig del af skylden.

Nok nærmere ”Den særegne Danske fortolkning af Udbudsreglerne”. EU’s udbudsregler bliver fortolket og frem for alt benyttet på mere pragmatisk vis i andre EU lande.

Man er i flere lande kommet til den erkendelse som du beskriver. I de lande ligner software udbud mere noget der er relateret til software end et anlægsarbejde.

Joe Sørensen

Kender noget lignende.

Jeg har oplevet flere gange at arbejde i en virksomhed, som vinder et projekt, fordi man har besvaret udbuddet betrykkende nok og til bedste pris. Derefter så blive de 2 kasser med udbuddets tusinder af krav stillet på hylden og ikke rørt igen. De konsulenter som kommunen eller regionen har brugt under forhandlingen af kontrakt og udbud kommer man ikke til at se igen. Og de i projekt afdelingen på vores side trækker sig ud af projektet og overlader det til deres kollegaer med domæne kendskab.

Til gengæld er det nu at vores andre projekt folk sammen med andre ansatte hos kunden samt vores udvikling og QA finder ud af hvad der faktisk skal leveres. Helt uafhængig af udbuddet. Ofte endda med succes.

Det sker selvfølgelig at de pludselig kommer med et eller andet tilfældig formeldt krav, som lige skal opfyldes. Det kan fx være krav til ram i den server som vi skal leverer til projektet. Vi har selvfølgelig kun betalt en server, det er kundens IT der køber den. De vil for Gud skyld ikke havde andre til dette, når den skal stå i deres rack. Hvis der i udbuddet fx står 32GB og vi havde betalt en server med 16GB, så skal de lige have en pakke RAM med i tilgift. Krav skal jo overholdes. Kommunens IT vælger selvfølgelig at smide de ram ud og sætte 1T ram i serveren for derefter at tilføje den til deres VMWare setup. Og derefter har den virtuelle maskine stadig de 8 GB ram vores løsning har brug for. Så alle er glade. Der er sikkert en grund til at udbuddet forlanger at vi leverer serveren. Men det er nok fordi kommunens IT afdelingen ikke har nogen måde at få hardware på i deres budget. Nu slap de med kun at skulle betale for de ram der sættes i.

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 10:31

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