Nyt sygesikringssystem: Tyndbenet kravspec eller tyndbenet leverandør?

Illustration: Region Hovedstaden
Man bør gøre op med forståelsen af, at digitale projekter har et fast bagkant - de bør udvikles løbende, som apps på en mobiltelefon, lyder det i en kommentar fra redaktionschef Henning Mølsted.

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.

Henning Mølsted er redaktionschef i Teknologiens Mediehus, som Version2 hører under. Han har i mange år beskæftiget sig journalistisk med området for sundheds-it. Illustration: Das Büro

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.

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

Jeg kan da undre mig over at du skriver at GDPR er undskyldning for forsinkelser i det offentlige, jeg troede nemlig at det offentlige var undtaget?
Og gælder det for det offentlige var det vel bare at kikke i sin dokumentation over hvordan man beskytter data og så lave en procedure for at slette det når man ikke skal bruge det mere.
For i et nyt system har man vel styr på de grundlæggende ting, som at data kun kan tilgås af dem som skal bruge det.

Rene Madsen

Man har en tendens til at gerne ville lave big bang løsninger i stedet for at løse delopgaver og så få dem til at være gode og så siden optimere på det.

Jeg siger bare microservices kombineret med CI/CD, men det vil jo være alt for nemt, så hellere holde sig til den eksisterende tilgang som ikke virker...

Henrik Sørensen

Henning, du rammer skiven rigtig godt i din artikel og peger korrekt på nogle helt centrale problemstillinger.

At DXC’s historik på store offentlige projekter er udfordret er tydeligt, men lige så interessant er det, at det også gælder for de fleste af de andre ‘store’ udviklingshuse, herunder KMD, hvor jeg selv har har arbejdet i en periode med netop offentlige udbud.

Nu plejer kommentarsporet på denne slags artikler lynhurtigt at blive fyldt op med nedsættende kommentarer om alt fra grådighed til inkompetence hos de store systemhuse og selvom der sikkert kan findes belæg for nogle af påstandene, så er det næppe sådan, at alle inkompetente og griske it-folk i Danmark har evnet at få ansættelse samme sted.

Det samme gør sig gældende for ‘kundens’ side ... de kan ikke være idioter alle sammen, dertil er de simpelthen for mange.

Der er derfor, som du også er inde på, tale om nogle mere systemiske problemstillinger.

Der er ingen tvivl i mit sind om, at selve udbuds-setuppet er alvorligt sygt ... det fremmer på ingen måde gode løsninger, men skaber derimod en usund kultur, med fokus på alt mulig andet end det centrale, nemlig produktet.

Et andet aspekt er os selv ... IT branchen. Er vi dygtige nok og har vi den rigtige kultur? Noget tyder i hvert tilfælde på, at der er plads til forbedringer!

De utallige ‘frameworks’: ITIL, PRINCE2, SAFe, SCRUM med mange flere, er alle sammen opstået ud af et behov for at forbedre, styrke og styre noget.

Det er bare som om de ikke rigtig giver det udbytte de stiller os i udsigt ... måske fordi vi ikke evner at bruge dem rigtigt eller måske fordi de hurtigt ændrer karakter til noget man kan bruge til at slå andre oveni hovedet med uden at forholde sig til formål og indhold?

Du har også fat på tids-aspektet ... 40 dage til at forstå opgaven, samle de rigtige folk og skrive en løsning og besvare 800 andre krav er absurd teater, men det står jo ikke i lovgivningen at man som kunde kun må give leverandørerne 40 dage. Det er tilsyneladende bare en mærkelig kutyme, der er opstået og som vi (branchen) så blindt accepterer, for ellers får vi jo ingen ordrer...!

Men tid er måske i det hele taget en større synder end vi er opmærksomme på. Det går nemlig stærkt i vores branche og måske for stærkt?

Teknologierne vælter frem i et sindssygt tempo og hvor man for 20-30 år siden lærte at programmere i et enkelt sprog og blev rigtig god til det, så mixer vi i dag utallige teknologier, som få så når at fordybe sig i og ingen bliver rigtig gode til og det smitter af på vores løsninger.

Endelig er der det fundamentale problem, at vi ikke ved, hvad det er vi egentlig skal lave. Jeg har endnu til gode at se en kravspecifikation, der detaljeret beskriver de forretningsmæssige og juridiske processer og data, som systemet er tænkt til at skulle håndtere.

Og selvom vi kan ‘prøve os frem’ i fail-fast-forward og scrum, så er det et grundlæggende sygdomstegn når vi er nødt til at gætte frem for at vide.

Henning, endnu en gang tak for en god artikel. Der vil formentlig være meget af samme slags at skrive om i fremtiden.

Malthe Høj-Sunesen

Man kommer til at tænke på hvordan Hovedstadens Beredskab udvikler nye løsninger, som beskrevet andetsted på siden: https://www.version2.dk/artikel/udvikling-hovedstadens-beredskab-specifi.... Det ville lettere skabe en kultur med små i stedet for store løsninger. Det er også værd at påpege at PSRM blev udviklet i releases og leveret "stort set ... til tiden" (og nu kan alle fordringshavere så få lov til at prøve at få deres integration og datakrav til at fungere).

Bjarne Nielsen
Lars Christensen

Det vil ALTID være opdragsgiver som har det overordnede ansvar for udformningen af en kravspecifikation.

Jeg beklager, men følgende statement fra artiklen
"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."
Er langt ude i hampen, fordi så kræves en krystalkugle!

Det er også langt ude i hampen, at inddrage konkurrenter og andre eksterne parter i en bedømmelse af den virksomhed som blev valgt som opgaveløser.

Der er KUN en ansvarlig og det er opdragsgiver.

Kan der bevises svindel, skal udviklingskontrakten opsiges

At det offentlige så ser stort på fornuftige fremgangsmåder mht til projektstyring etc. (de er der jo disse fornuftige fremgangsmåder) er jo noget svært at håndtere, medmindre der indføres retsansvar for forsætlig dumhed.

Btw. GDPR så jo dagens lys 24 måneder FØR den fik retsvirkning

Knud Larsen

Forsætlig dumhed !
Det bør fremhæves, at der i sundhedsektoren (som den eneste) er et kvalitetssystem og de ansatte har ansvar for opgavens udførelse dvs. der bliver rejst tiltale for grove fejl.

Sådan er det ikke i resten af de offentlige sektorerer. Her går man bestandig helt fri for forsætlig dumhed (eks, overtrædelse af egne love) og fejl, der medfører store gener og tab for borgerne, ja man må påregne at nogle af 'overmagt og afmagts'-grebene kan før til selvmord.
Men nej der sker absolut intet.
Flere af de grove eks. er ejendomsvurderinger, EFI, udbytte sagen osv.

Bjarne Nielsen

Jeg beklager, men følgende statement fra artiklen
"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."
Er langt ude i hampen, fordi så kræves en krystalkugle!

Jeg overhørte på et tidspunkt en samtale imellem en projektleder og en sælger og den gik nogenlunde (1) sådan her:

  • "Hvorfor har vi kun to servere med i vores tilbud? Er det ikke alt for lidt?"
  • "Jo, men det opdager de ikke før end de er gået i drift!"

Kan der bevises svindel, skal udviklingskontrakten opsiges

  • Er det svindel?
  • Kan det bevises?
  • Er der foretaget så få og små aftalte ændringer og tilkøb i mellemtiden, at de ikke kan få skylden?
  • Er der en udviklingskontrakt at opsige, når systemet er i drift?

Ureelt? Ja for pokker! Men sandsynligvis en gratis omgang.

Ad (1): Det er efterhånden nogle år siden, og jeg tog ikke noter :-).

Anders Hybertz

Var det ikke sådan at der i realiteten ikke blev ændret noget i GDPR forordringen, men at man fra EU side strammede op omkring brud på GDPR reglerne - ihvertfald set fra dansk side.

Det er virkelig skræmmende at man kan få lov til at lave personfølsomme offentlige IT systemer og så ikke tænke data management og sikkerhed ind i løsningen. - øv øv øv

Log ind eller Opret konto for at kommentere