«Vi har ikke kommunisert godt nok om Akson» sier Stine Camilla Bjerkestrand, kommunikasjonsdirektør i direktoratet for e-helse. Jeg er helt enig med henne, og synes det er fint å se at hun tar innover seg at kommunikasjon – hennes område – har stått for en del av problemet.
Gode ledere tør å innrømme feil og mangler ved det de har gjort, og tenke gjennom hvordan det kan forbedres. Bedre kommunikasjon rundt hva Akson-arbeidet egentlig handlet om og hva de holdt på med kunne helt klart gjort debatten mer konstruktiv. Mange har for eksempel fortsatt ikke fått med seg at det handler om å levere verktøy til helsearbeidere ansatt i kommunal sektor – og har ikke noe med pasient-tjenester i det hele tatt.
Men akkurat lærdommene hun trekker frem i innlegget sitt, treffer dessverre ikke – for mitt vedkommende i alle fall. Bedre forklaringer av hvordan statens prosjektmodell legger føringer for konseptvalgutredninger og styringsdokumenter hjelper lite, når kritikken er rettet mot nettopp disse prosessene. Det er det å bruke statens prosjektmodell for store IT-prosjekter som er problematisk. Statens prosjektmodell er utarbeidet for prosjekter som handler om å bygge fysiske ting som infrastruktur og store bygg. IT er noe helt annet, og bør ikke styres på samme måte.
Skal du legge en motorvei fra en side av en elv/fjord/innsjø til en annen, så må dette planlegges nøye i forkant. Skal det være en bro? Skal det være en tunnel? Hva blir konsekvensene? Hvor mye vil det koste? Du kan ikke bare sette i gang og bygge en bro og «se hvordan det går» også finne ut halvveis at broa burde vært et annet sted, eller at man egentlig burde lagt en tunnel istedenfor.
Her bidrar statens prosjektmodell med prosesser som skal sikre en mot dårlige beslutninger. I et slikt prosjekt er det også naturlig å ha en separat planleggingsfase, gjennomføringsfase og en vedlikeholdsfase. De som planlegger er ikke de som konstruerer broa, eller de som vedlikeholder den i etterkant. Statens prosjektmodell passer kjempegodt inn i denne typen arbeid.
IT er helt annerledes. På den ene siden har vi det mye enklere – vi har ikke noe fysisk å konstruere. Vi kan begynne med å lage «en gangbro», se hvordan det funker, også utvide den til litt og litt, til det er en «4-felts motorveibro». Vi kan både lage en liten bro og en liten tunnel samtidig, se hvordan de funker i praksis før vi bestemmer oss.
Det er ingen grunn til å vegre seg for å sette i gang med IT – det tar ikke lang tid å lage enkle løsninger som kan validere business-case imens man planlegger. Så det at direktoratet for e-helse har brukt mange år og mer enn 100 millioner kroner uten å levere noe som helst som kan brukes eller evalueres av brukere er kritikkverdig i seg selv.
På den andre siden, er IT mye mer komplekst enn typiske vei og bygg-prosjekter. En bro er statisk. Den endrer ikke karakter etter hvilken bil som kjører over den, eller hvilken dag det er i uka, politiske vedtak, eller hvorvidt sjåførene foretrekker bokmål eller nynorsk. IT-systemer har en intern kompleksitet som langt overgår de aller fleste fysiske konstruksjoner.
Fysiske konstruksjoner endrer seg heller ikke stort etter de er bygget. Vedlikehold handler om å bevare dem slik de er. Dette er også langt ifra virkeligheten for IT-systemer. IT-systemer er i konstant endring. «Vedlikehold» av IT-løsninger handler i stor grad om videreutvikling – altså de samme oppgavene man jobber med under utvikling. Det er de samme type folkene, som gjør de samme oppgavene både i «planlegging», «gjennomføring» og «vedlikehold» av IT-systemer. Det å dele arbeidet inn i disse fasene er dermed ganske meningsløst.
Den iboende kompleksiteten i IT-systemer gjør også at det er tilnærmet umulig å jobbe på «store prosjekter» effektivt. Selv i små prosjekter blir kompleksiteten fort overveldende. Jo flere brukere som skal tilrettelegges for i et IT-system, jo mer komplekst blir det. Jo flere systemer som må samkjøres for å levere verdi, jo mer komplekst blir det. Derfor er det helt nødvendig å dele inn IT-satsinger opp på måter som gjør at man kan levere funksjonalitet som gir verdi med minimal koordinering med andre systemer.
Som Bjerkestrand sier, så er det helt korrekt at Akson-arbeidet også var ment å deles opp i flere anskaffelser. Deres forslag er som følger:
- Journalplattform
- Forvaltning av identiteter og rettigheter
- Utvikling av grensesnitt og integrasjoner
- Applikasjonsdrift og forvaltning
- Driftsplattform
- Kompetanse- og kapasitetsforsterkning
- Tilleggsfunksjonalitet
Men med denne inndelingen så må alle anskaffelser samkjøres med alle de andre anskaffelsene for å levere verdi til brukerne. Man kan ikke ha en journalplattform uten forvaltning av roller og identiteter, eller driftsplattform eller grensesnitt og integrasjoner. I tillegg må alle anskaffelsene forholde seg til alle de forskjellige brukerne samtidig. Dette gjør gjennomføringen veldig mye mer kompleks enn den bør være.
Arbeidet bør heller deles opp per brukergruppe. Det er veldig mange helt forskjellige brukergrupper innen kommunal primærhelsetjeneste, som har helt forskjellige arbeidshverdager. Deler vi per brukergruppe, vil hvert prosjekt måtte levere journal-funksjonalitet, grensesnitt og integrasjoner, driftsplattform og rollestyring, men det er en mye mer effektiv inndeling av arbeidet. Det gjør også at det er mye lettere å holde fokus på hva de forskjellige brukerne faktisk trenger av funksjonalitet.
(Når det gjelder helsedata de alle skal samhandle om – så har dette nå blitt trukket ut av Akson-arbeidet, ettersom det ikke har noe med «kommunal sektor» å gjøre, helsedata er et nasjonalt anliggende. Heder og ære til direktoratet for e-helse som har gjort denne endringen.)
For å oppsummere, så handler ikke kritikken min om misforståelser rundt hvilken fase Akson var i i henhold til statens prosjektmodell. Det handler om deres tilsynelatende mangel på forståelse for hvordan vi i bransjen har lært oss å jobbe effektivt med IT-løsninger.
(For dem som er interessert i å lære mer om moderne IT-utviklingspraksis, så anbefaler jeg å lese boka «Accelerate».)
