Innlegget er et tilsvar til divisjonsdirektør i e-helsedirektoratet Karl Vestlis kommentar «Akson handler om digital transformasjon, ikke softwareutvikling»
La meg begynne med å rette en stor takk til divisjonsdirektør i direktoratet for e-helse Karl Vestli som har tatt seg tid til å svare på innlegget mitt om Akson.
Jeg setter stor pris på at direktoratet deltar i debatten på denne måten. Han og sine kollegaer jobber med dette prosjektet på fulltid, mens jeg kritiserer fra utsiden på på min egen fritid, så det er helt naturlig at det er aspekter av prosjektet jeg ikke har fått med meg.
Jeg har vært spent på hva svaret kom til å bli. Har jeg misforstått? Er det kanskje ikke så galt likevel?
Så det som var mest interessant med svaret, er at han heller enn å tilbakevise mine påstander, faktisk forsterker dem.
Verdiløs oppdeling
Først tar han for seg dette med oppdeling av prosjektet:
«Det vil bli to prosjekter; ett for å løse journalbehovet og ett for å løse samhandlingsbehovet», sier Vestli.
Når man skal lage (eller kjøpe) software, er det viktig å fokusere på brukerbehov. At man setter brukeren i sentrum. Hva en fastlege trenger av journalsystemer er noe annet enn det en pasient, eller sykepleier på et sykehjem, eller en lege på et sykehus, trenger.
Alle brukergrupper kommer til å trenge en eller annen form for journal-applikasjon, og alle brukergrupper kommer til å trenge visse former for samhandling. Men behovene er ikke de samme.
Samhandling uten journal har liten verdi, og motsatt: journal uten samhandling har heller ikke stor verdi. Vi bør alltid dele inn software-prosjekter slik at hver del faktisk leverer noe som kan brukes.
Stegvis tilnærming
Videre snakker han om dette med en stegvis tilnærming:
«Begge skal gjennomføres stegvis med flere kontroll- og stoppunkter underveis.»
Men uten at stegene faktisk leverer noe konkret verdi, hva er det da vi skal kontrollere? Hva blir stopp-kriteriene?
Det er veldig mye vanskeligere å evaluere og justere kurs underveis når det man har laget ikke kan brukes. Dessuten - hvis man da bestemmer seg for å stoppe etter et år, da har man kastet bort alt man har brukt av tid og penger frem til da.
Hvis vi istedenfor deler dette opp slik at faktisk bruksverdi blir levert fortløpende, da vil man kanskje ha oppnådd noe, selv om prosjektet skrapes etter noen år.
Ikke et utviklingsprosjekt?
«Felles kommunal journalløsning er ikke er et typisk utviklingsprosjekt, men skal primært gjennomføres ved kjøp i markedet», sier Vestli videre.
Jeg er en stor tilhenger av å kjøpe ferdig hyllevare der det er mulig. Men kun hvis det sparer tid og penger. Her snakker man om å bruke 11 milliarder kroner og 10 år.
Hvis det koster så mye å kjøpe noe på markedet, da er det faktisk bedre å lage noe selv. Dessuten er grunnen til at det koster så mye og tar så lang tid, at man er nødt til å tilpasse eventuell hyllevare man får kjøpt.
Tilpassing av hyllevare, det er softwareutvikling det.
Du får bare et mye dårligere resultat når du må tilpasse et eksisterende produkt som ble laget for helt andre forhold. Det blir som å kjøpe dress på Dressmann, for så å bruke 150 000 kr på å få skreddere til å tilpasse den til deg.
Risikabel organisering
«Anskaffelsen skal erstatte eksisterende journalløsninger som ikke er gode nok fremtidige arbeidsverktøy for kommuner og helsepersonell. Løsningen må derfor ha tilstrekkelig funksjonalitet fra første dag», sier Vestli.
Her er vi tilbake til det med inndeling av prosjektet. Det er essensielt at vi deler prosjektet opp slik at vi kan nettopp levere tilstrekkelig funksjonalitet fra dag én.
Men dag én må ikke være mange år frem i tid.
Og «tilstrekkelig funksjonalitet» kan gjelde for mindre oppgaver – vi trenger ikke løse alt samtidig. Det er kjemperisikabelt å organisere arbeidet slik at vi ikke får levert noe før om mange år.
Leveranser uten egenverdi
Så tar han opp dette med anskaffelser:
«For å tilrettelegge for konkurranse anbefales det flere anskaffelsesområder, blant annet den nevnte journalplattformen, men også løsning for identitetsstyring, tjenester og verktøy for utvikling av grensesnitt og integrasjoner, tilleggsfunksjonalitet og driftsplattform».
Igjen er dette en veldig lite hensiktsmessig inndeling. Ingen av leveransene har noen egenverdi. Vi kan ikke ha en journalplattform uten identitetsstyring og driftsplattform eller noe av det andre.
Når alle leveranser er avhengig av alle de andre leveransene, så blir det nødvendigvis mye vanskeligere å levere en gjennomført tjeneste. Alt må koordineres mellom alle parter.
De legger altså opp til et prosjektløp der man ikke kan finne ut om man har levert noe av verdi før alle sammen er ferdige og alt fungerer sammen. Det er både svært risikofylt og veldig ineffektivt.
Uhensiktsmessig prosjektmodell
Det at «arbeidet følger statens prosjektmodell» gjør ikke saken noe bedre. Statens prosjektmodell er laget for å styre bygging av store signalbygg, broer og veier. Den passer svært dårlig for utvikling av software. I software har vi ingenting fysisk å konstruere. Vårt produkt er virtuelt.
En bro kan ikke endres halvveis gjennom byggingen, men software endrer seg kontinuerlig. Det krever en helt annen tilnærming til prosjektstyring. En tilnærming de som driver med software-produktutvikling i privat sektor tar for gitt: Vi kvalitetssikrer ved å levere brukerverdi fortløpende, og så justere basert på feedback fra reell bruk.
Det å bruke årevis i planleggingsfaser uten å programmerere, uten å levere noe, det er det motsatte av kvalitetssikring. Man er nesten garantert å komme frem til en plan som er utdatert og vanskelig å jobbe med. Akkurat slik som vi ser her.
Basert på amerikansk løsning?
For meg og mange andre virker det som om direktoratet for e-helse har basert Akson-prosjektet på kunnskap om eksisterende helse-plattform-løsninger som Epic, heller enn å se på hva man faktisk kan få til ved å fokusere på konkrete brukerbehov og levere verdi fortløpende med mindre leveranser.
Det å la alle våre helsedata og all helse-IT-funksjonalitet være avhengig av et stort amerikansk konsern, det er en sak det er verdt å kjempe imot helt uavhengig av alt det andre jeg har tatt opp.
«Akson handler om digital transformasjon, ikke softwareutvikling», sier Vestli. Nettopp. Det er det den mangler. Med softwareutvikling vil vi få bedre tjenester, raskere og billigere.
