Nyt sygesikringssystem: Tyndbenet kravspec eller tyndbenet leverandør?
KOMMENTAR. Så er den gal igen med et af de offentlige it-projekter. Denne gang er det et nyt sygesikringssystem til kommuner og regioner, Praksys, som efter fem års udviklingsarbejde stadig er langtfra klar til brug.
Systemet skal bl.a. håndtere honorarbetaling fra det offentlige til privatpraktiserende læger og skulle oprindeligt være taget i brug i 2016. Men ifølge en ny statusrapport, som Version2's søstermedie DigiTech har fået aktindsigt i, har kommuner og regioner i dag hverken overblik over den fulde økonomi eller tidsplanen.
Foreløbig har projektet et budget på 276 millioner kroner. Men ingen ved altså, hvornår det bliver færdigt og til hvilken pris.
Det står fast, at Danske Regioner mener, der er centrale fejl på løsningen, og interesseorganisationen vil have fejlene løst, inden det nye system kan gå i luften, fordi fejlene betragtes som forretningskritiske.
Men trods aktindsigten til DigiTech er det sparsomt med oplysninger om, hvordan det er kommet så vidt.
Der er næppe tvivl om, at den nye databeskyttelsesforordning, som fik virkning i Danmark 25. maj sidste år, har haft en betydning for forsinkelsen af projektet, fordi de nye bestemmelser afføder en større omhyggelighed i håndteringen af persondata.
Men spørgsmålet er, om det at tillægge forordningen et hovedansvar for projektet miserable tilstand - sådan som Region Hovedstaden tidligere har gjort - i virkeligheden er et røgslør, som i offentligheden har til formål at dække over dybere problemer.
Dog blev det i samme åndedrag nævnt, at leverandøren har problemer med »at levere de lovede leverancer til tiden«.
For mange kokke og for svag styregruppe?
Interessant er det at lytte til vandrørene i projektmiljøet. Her tales der om, at der er rigtige mange interessenter i projektet - herunder regioner, kommuner, stat, apoteker, Datatilsynet og selvfølgelig leverandøren DXC - hvilket betyder, at der er uenighed om projektets mål.
Manglende enighed om scope kan være giftigt for et projekt.
Det er ikke brugerne eller alle mulige eksterne aktører, men en engageret styregruppe, der skal sikre, at projektet bliver godt. Herunder at det løser det rigtige problem, har et klart formål, har et veldefineret omfang, muliggør gevinster, har realistiske planer, styres fornuftigt og får de rette ressourcer i nødvendigt omfang. Det er centrale spørgsmål at forholde sig til i styregruppen.
Men ofte er disse elementer ikke beskrevet godt nok, og så kommer såkaldte ubeskrevne forhold ind og giver uenighed. Det kan være behov for opgaveløsning eller features, som erkendes eller bliver præcise undervejs i forløbet - og som optimalt set burde have været aftalt fra starten.
Det kunne i tilfældet med den nye sygesikringssystem Praksys fx være antallet af data, der skal registreres af lægen pr. besøg, eller kvaliteten af indbyggede planlægningsværktøjer. Eller omfang eller kvalitet af den afrapportering til Landspatientregistreret, sundhed.dk eller det politiske niveau, som systemet skal generere.
Det er desværre heller ikke et ukendt fænomen, at leverandører godt kender til de behov, som kunderne har brug for - eller i nær fremtid vil kunne få brug for - at få løst med et system, men som bare ikke er tilstrækkeligt beskrevet i kravspecifikationen.
Eller også er det umuligt at løse inden for projektrammen. Den viden - eller den problematik - forbliver bare usagt, for mange leverandører prioriterer at vinde udbuddet og komme i gang frem for at kritisere kundens udbud og forsinke processen.
Når det uopfyldte behov åbenbares i processen, så starter problemerne.
Research og brugerinvolvering inden udbud
Ovenstående peger i retning af, at man i de offentlige udbud skal blive bedre til forarbejdet med bl.a. at involvere brugerne i designet, at sikre genbrug af standardfunktionalitet og at researche på andre organisationer med samme type digitaliseringsprojekter for at sikre en større præcision omkring de behov og det problem, som et it-projekt skal opfylde hhv. løse.
Men samtidig er der brug for en erkendelse af, at nutidens organisation ikke altid har blik for fremtidens behov - eller muligheder. Her må man altså ty til professionel hjælp, fx i form af en markedsdialog, og i hvert fald erkende, at digital forretningsudvikling er en fortløbende proces.
Men udbudsgiverne skal også give leverandørerne en fair frist til at byde på et tilbud, så de har tid til at redgøre ordentligt for, hvordan forskellige behov og opgaver bliver løst med et nyt digitalt system.
En svarfrist på en måned eller 40 dage, som det fx var tilfælde med EFI-udbuddet, går simpelt hen ikke, hvis man vil have et professionelt og gennemarbejdet tilbud.
Leverandører skal gribe i egen barm
Leverandørerne skal dog også gribe i egen barm. DXC, som er en fusion af Enterprise Services Business i Hewlett Packard Enterprise og CSC, har ikke ligefrem en køn track record, når det gælder offentlige it-projekter.
Tilbage i 2012 blev det CSC-udviklede sagsbehandlingssystem til politiet, Polsag, skrottet efter mange års udvikling og flere pilotprojekter. Fire år tidligere blev systemet til arbejdsformidlingerne, Amanda, skrottet, fordi det var for dyrt. CSC stod også bag EFI's søstersystem, Debitormotor, der blev forsinket så længe, at den nye digitale inddrivelse i Skat blev udskudt fire år.
Og så sent som i januar kom det frem, at DSB havde opsagt aftale med DXC tre år før tid efter forsinkelser på at overtage driften af DSB's datacenter.
Systematics administrerende direktør, Michael Holm, har tidligere givet udtryk for, at hvis en leverandør har fået tre røde trafiklys i Statens It-råds statusrapporter for statens store it-projekter, så bør leverandøren sættes i karantæne.
I samme debat fremførte tidligere direktør i Digitaliseringsstyrelsen, Lars Frelle-Petersen, at leverandørerne for ofte hævder at kunne »levere alt - plus guld, kroner og alt muligt andet«, men når det kommer til stykket, så skønmales egen evne til at levere.
Mere grundlæggende er der formentlig også brug for at udvikle selve grundstrukturen omkring udbud, herunder nedbryde store projekter i 'proof-of-concept'-komponenter, som kan afprøves på mindre brugergruppe eller i en kortere periode for at høste erfaringer.
Desuden bør man gøre op med en forståelse af, at digitale projekter har et fast bagkant og bliver 'færdige'. Behov udvikles konstant, og nye muligheder opstår, hvilket kræver løbende vedligehold og udvikling, fuldstændig som apps, som vi har på vores mobiltelefon, der jævnligt skal opdateres med nye features og fejlrettelser.
...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.
