Hvordan kan vi oppnå det vi vil med digitalisering i helsesektoren?

Nok IT-skandaler nå?

Digitaliseringsprosjekter i offentlig sektor har vist seg å være krevende. Navs moderniseringsprogram var planlagt med et budsjett på over tre milliarder mellom 2012 og 2018, men ble stoppet i 2013. Politiets merverdiprogram ble planlagt med et budsjett på 2,4 milliarder kroner, men stoppet i 2015 før det kom ordentlig i gang. Det finnes selvfølgelig eksempler på vellykkede satsinger i offentlig sektor og på IT-skandaler i privat sektor, men disse hører vi som regel ikke like mye om.

Forskere har lenge kritisert hvordan store IT-prosjekter organiseres (Sørgaard, 1996; Dæhlen & Hanseth, 2011). Da Regjeringen lanserte IKT-strategien Digital agenda (Kommunal- og moderniseringsdepartementet, 2016), ble bedre styring av offentlige IKT-prosjekter vektlagt, og forskere ble invitert inn for å bidra til kunnskapsgrunnlaget (Jørgensen, 2015). Som en del av strategien ble fem prinsipper for digitaliseringsprosjekter i offentlig sektor lansert: 1) Start med behov. 2) Tenk stort – start smått. 3) Velg riktig samarbeidspartner. 4) Sørg for riktig kompetanse og god lederforståelse. 5) Lever hyppig – skap nytte hele veien. Disse prinsippene ble gjentatt i Regjeringen og KS sin handlingsplan og i digitaliseringsrundskrivet. Dette er fornuftige råd som samsvarer godt med anbefalinger fra forskningen på store og komplekse IKT-prosjekter. Imidlertid legges det på samme tid opp til at man i offentlige IT-prosjekter skal benytte statens prosjektmodell og prosjektveiviseren, noe som hindrer at disse rådene kan følges fullt ut. Vi har dermed også etter 2016 sett store IT-prosjekter som kommer feil ut, og hvor skattepenger, tid og ressurser i form av menneskers arbeidsinnsats sløses bort.

I helsesektoren gikk for eksempel Akson-prosessen ganske langt før man tok til seg innspill og kritikk og endret kurs for arbeidet med å fornye pasientjournalsystemene i kommunal sektor (Riksrevisjonen, 2020). I region Midt-Norge er man havnet i en problematisk situasjon etter innføringen av Helseplattformen; en prosess som startet tilbake i 2012. Den planlagte kostnadsrammen på 3,7 milliarder kroner er overskredet, og det er foreløpig uklart hva sluttresultatet og -regningen vil bli. Ansatte rapporterer bekymring og stress, mens prosjektledelsen vektlegger at det arbeides med forbedringer, og at det ikke er noen vei tilbake.

Fremover kan vi ikke sløse hverken med skattepenger eller helsepersonell. Vi må simpelthen bli bedre på å gjennomføre digitaliseringsprosjekter. Fra mitt ståsted i en forskningstradisjon som studerer samspill mellom teknologi og organisasjoner, er diagnosen at man ikke har erkjent og håndtert det vi kaller sosioteknisk kompleksitet godt nok. I det følgende vil jeg beskrive hva som ligger i denne kompleksiteten, og hvorfor tradisjonelle prosjektmodeller ikke egner seg til å håndtere den.

«Det var overraskende komplekst»

I et IT-prosjekt som strever, vil det typisk komme noen signaler eller drypp til mediene, men det går gjerne noe tid før det kommer en offentlig erkjennelse fra prosjektledelsen om at man har problemer. I første omgang følges slike innrømmelser gjerne av en betryggende melding om at det «håndteres», eller at man «tar grep». Men i fasen etter at det er blitt offentlig kjent at prosjektet stoppes, og når prosjektleder intervjues av media, hører vi vanligvis en eller annen variant av at «vi undervurderte kompleksiteten», «det var mer komplekst enn vi trodde», eller «det var overraskende komplekst».¹

At kompleksitet er så sentralt, stemmer bra med vår forskning, men det er allikevel en ganske generell og overordnet formulering. Kompleksiteten i store prosjekter har med mange aspekter å gjøre, og det er behov for å pakke dem ut.

Sosioteknisk kompleksitet

Prosjektledernes overraskelse kan skyldes at man ikke har sett eller anerkjent den allerede eksisterende sosiotekniske kompleksiteten i det feltet man jobber i. Begrepet sosioteknisk er ment å indikere at det vi ofte skiller ad og kaller henholdsvis teknologi og det sosiale (mennesker, arbeidsgrupper, organisasjoner), bør ses på i sammenheng (Emery & Trist, 1960; Mumford, 2006; Baxter & Sommerville 2011). Teknologi, arbeidsoppgaver, rutiner og organisasjonsstrukturer spiller sammen. De tilgjengelige verktøyene påvirker hvordan man utfører oppgaven, hvilke kunnskaper og ferdigheter som kreves, og hvilket personellbehov man har. For eksempel, dersom et sykehus ikke har selvinnsjekk-automater, må det i stedet finnes personale som kan gjennomføre pasientregistreringen og -veiledningen.

De ulike elementene i et velfungerende sosioteknisk nettverk har tilpasset seg hverandre gjennom mange år og føles naturlige og velkjente. Det å skulle endre noen deler i en slik vev, for eksempel ved å bytte en papirbasert løsning med en digital, kan fort føre til utfordringer (Bardram & Houben, 2018). Noe forandring er jo ønsket (i og med at man har valgt å gjennomføre endringen), men man bør unngå altfor drastiske brudd eller forstyrrelser. Skal man for eksempel innføre ny teknologi i et sykehus som er i løpende drift, må man passe på at man ikke introduserer brudd i ressurstilgangen eller kommunikasjonskjedene rundt pasientene (Grisot et al., 2023).

Dette sosiotekniske nettverket representerer det vi kan kalle en naturlig forekommende kompleksitet – denne typen kompleksitet slipper man ikke unna; den er en uunngåelig del av den verdenen man jobber i, og man må håndtere dette på en eller annen måte.

Nødvendig og unødvendig kompleksitet

Utover denne naturlig forekommende eller uunngåelige kompleksiteten kan det oppstå en tilleggskompleksitet som stammer fra valg man tar i prosjektet. Det kan være fordi man setter seg altfor ambisiøse mål knyttet til raske og omfattende endringer. Å gjennomføre en radikal endring av måten oppgaver løses på, er mer krevende enn å endre oppgavene skrittvis og gradvis. Å bygge løsninger som leverer alt til alle, er mer krevende enn å lage en delløsning som løser ett problem for én gruppe brukere. Å gjøre store endringer på kort tid medfører dermed en mye større risiko for problemer. Den kompleksiteten som oppstår fra slike valg, er ikke naturgitt eller naturlig forekommende – den er introdusert, og man kunne (i hvert fall i teorien) valgt å unngå den.

Størrelse er i seg selv en risikofaktor. Et stort prosjekt krever arbeidsdeling i flere separate delprosjekter eller team. Ofte er det avhengigheter mellom det de ulike gruppene jobber med, slik at beslutninger som tas i ett prosjektløp, vil få konsekvenser for andre. Det kan være svært krevende å planlegge og koordinere dette. Når store IKT-prosjekter hyppig omorganiseres, er en del av grunnen at man prøver å finne en god struktur for arbeidsdelingen hvor disse avhengighetene lar seg håndtere.

Den danske forskeren Bent Flyvbjerg har i flere tiår forsket på store prosjekter og har samlet informasjon om mange tusen megaprosjekter i sitt forskningssenter ved universitetet i Oxford (se Flyvbjerg et al., 2003; Flyvbjerg, 2017; Flyvbjerg & Gardner, 2023). Han har formulert det som kalles de store prosjekters jernlov: Disse prosjektene går «over tid, over budsjett, under gevinst, igjen og igjen». Med andre ord, de lykkes dårlig. I en studie som omfattet over 11 000 prosjekter, fant forskerne at nesten halvparten (47,9 prosent) klarer å holde seg innenfor budsjettet. Adskillig færre, bare 8,5 prosent, klarer å holde både budsjett og tidsfrister. Kun 0,5 prosent klarte å holde budsjetter, tidsfrister og samtidig levere det de skulle (Flyvbjerg, 2017). Flyvbjergs forklaringer på dette retter seg inn mot psykologi- og maktaspekter (Flyvbjerg, 2021). Prosjektforkjempere har en tendens til å overvurdere gevinstene og undervurdere kostnader og risiko. Noen ganger gjøres dette bevisst og strategisk for å klare å komme i gang med prosjektet. Det er også et velkjent fenomen at dårlige nyheter og kritikk har vanskelig for å flyte oppover i en organisasjon, slik at ledelsen ikke har et realistisk bilde av situasjonen. Forskning på fenomenet prosjekteskalering viser at ledere legger mye vekt på allerede foretatte investeringer (sunk costs) både relatert til økonomi og prestisje, og at dette kan bidra til en videre satsing på prosjekter som rasjonelt sett burde vært avsluttet (Mähring & Keil, 2008).

Styringsverktøyene passer ikke til komplekse IKT-prosjekter

Problemene kan også skyldes at man velger en styringsmodell og styringsverktøy som ikke hjelper til med å håndtere kompleksitet på en god måte. De fleste rammeverkene og verktøyene retter seg ikke mot det som er spesifikke utfordringer for endringer av slike sosiotekniske nettverk. Dette kan lede til manglende oppmerksomhet om disse tingene, og verktøyene bidrar dermed til at risiko og mulige problemer ikke kommer på bordet. I stedet skaper styringsmekanismene og -verktøyene merarbeid og bruker dermed opp ressurser og oppmerksomhet som burde vært rettet mot å avdekke og håndtere risiko.

Det finnes flere eksempler på at IKT-prosjekter i helsesektoren tar en ugunstig retning på grunn av føringene og begrensningene som ligger i regimet for offentlige anskaffelser. Man blir bundet av hvordan kravene i anbudsdokumentene er utformet og vektet; krav som kanskje er formulert før man er klar over hva som finnes på markedet. I stedet for å velge en løsning som blir vurdert som best egnet av fremtidige brukere, må man velge den løsningen som best oppfyller kravene i de formelle dokumentene. Det som skulle være et hjelpemiddel til åpne og rettferdige anskaffelsesprosesser, kan også bli et hinder for å være fleksibel og løsningsorientert.

En annen styringsmekanisme er statens prosjektmodell (Finansdepartementet, 2023), som skal brukes ved store statlige investeringsprosjekter, herunder digitaliseringsprosjekter med et budsjett på over 300 millioner kroner. Her stilles det krav til metodikk i utredningen og ekstern kvalitetssikring av beslutningsunderlaget før prosjektet legges frem for Regjeringen og Stortinget. Prosjekter skal i en konseptfase beskrive problemet som skal løses, fremtidige samfunnsmessige behov, og angi hvilke mål som skal oppnås med å gjennomføre tiltak. I en konseptvalgutredning (KVU) skal ulike løsninger vurderes og sammenlignes gjennom en samfunnsøkonomisk analyse. Utredningen skal anbefale tiltak og beskrive viktige forutsetninger for videre arbeid. Denne skal så legges frem for en ekstern kvalitetssikring (kalt KS1) før Regjeringen kan fatte beslutning om konseptvalget. Deretter kan et forprosjekt startes opp, hvor man utarbeider styringsunderlag og kostnadsanslag for det valgte konseptet. Også dette skal kvalitetssikres gjennom KS2 før investeringsbeslutning og fastsettelse av prosjektets kostnadsramme kan fremmes for Stortinget. Først da kan et gjennomføringsprosjekt starte.

Denne måten å organisere prosjektarbeid på er ikke spesielt godt egnet for IKT-prosjekter. Den binder opp prosjektet til et konsept (som ofte tilsvarer et teknologivalg) i en tidlig fase, og siden prosessen tar lang tid, gjerne flere år, mens teknologiutviklingen går raskt, kan man ende med å ha bundet seg til en teknologi som er utdatert før man starter gjennomføringen.

Enda mer problematisk er det at modellen ikke tar hensyn til at IKT-prosjekter er sosiotekniske endringsprosesser. En ny bro eller vei kan bygges relativt atskilt fra trafikken som går i det gamle løpet, helt til trafikken plutselig en dag (eller mer sannsynlig, en natt) blir rutet inn på det nye veistrekket. Det krever som oftest ikke noe spesielt av bilføreren å få til å kjøre på den nye veien eller broen. Et IKT-verktøy har mye større avhengigheter til arbeidsorganiseringen, oppgavene og samarbeidsformene. Disse vil endres – det er ofte hele formålet at de skal endres og blir sikrere, bedre og mer effektive. Men når og hvordan skal de nye arbeidsformene utformes og settes i drift? Skal dette detaljplanlegges før innføringen, eller skal man finne ut av det i etterkant? Uansett hvilken strategi man velger, vil innføring av et IKT-verktøy skape mange typer forstyrrelser i det eksisterende sosiotekniske nettverket. Arbeidet med dette tar en god del ressurser fra organisasjonen og krever kompetanse på å håndtere endringer. Slike aspekter, herunder kostnadene de medfører, er ikke i fokus i disse standardprosessene.

Søkelyset er heller ikke rettet mot avhengighetene av allerede eksisterende IKT-systemer. Større organisasjoner har typisk et sted mellom noen hundre til noen tusen ulike IKT-systemer. Mange av disse er sammenkoblet og henter data fra eller leverer data til hverandre. Endringer i ett system kan dermed få ringvirkninger for andre systemer. Slike avhengigheter har vært svært sentrale i mange av de store IT-skandalene vi har hatt både her til lands og internasjonalt. Man har ikke hatt oversikten over hvor mange andre systemer som er avhengige av det systemet man bytter ut, og må i etterkant slukke branner og bygge dyre punkt-til-punkt-integrasjoner. Ofte antar man at disse andre systemene vil være i stand til å kommunisere også med det nye systemet, uten å undersøke om dataformatene samsvarer. Den rent tekniske kompleksiteten er ofte en viktig årsak til forsinkelser og kostnadsoverskridelser i IKT-prosjekter. Når styringsverktøyene ikke legger opp til at denne typen risiko skal undersøkes og vurderes, dukker dette opp som ubehagelige og dyre overraskelser i etterkant. Prosjektveiviseren fra Digitaliseringsdirektoratet er rettet spesielt mot IKT-prosjekter, og her er det gjort noen justeringer. Den gir for eksempel en anbefaling om å holde handlingsrommet åpent slik at det konkrete valget av teknisk løsning kan gjøres så sent som mulig i prosessen. Det sosiotekniske perspektivet kan sies å være ivaretatt i noen grad av vekten på å arbeide med gevinster, men heller ikke dette verktøyet gir noen spesiell hjelp til å identifisere, minimere og håndtere sosioteknisk kompleksitet i mottakerorganisasjonen.

Behovet for felles infrastrukturer

Mange av de store IKT-prosjektene har som formål å bygge en felles digital infrastruktur som skal brukes av flere parter. De ulike aktørene i helsesektoren har ulike, men komplementære oppgaver, ansvarsområder, kunnskaper og tilnærminger. De har ulike behov knyttet til informasjonen de skaper, registrerer og bruker. Dette gjenspeiler seg i at aktørene bruker ulike IKT-løsninger. Vi har derfor i dag et heterogent systemlandskap som består av en mengde ulike systemer fra mange teknologiske generasjoner, noe som er utfordrende. Burde ikke alle bytte til det samme systemet?

Å etablere en felles løsning betyr at man må organisere aktører som har ulike behov, og som hører til i ulike organisasjoner. En sentral visjon bak Én innbygger – én journal (Helse- og omsorgsdepartementet, 2012) og den påfølgende prosessen (senere kjent som Akson og deretter felles kommunal journal) var at helseinformasjon skulle gjøres tilgjengelig for helsepersonell som var involvert i pasientbehandlingen, selv om de tilhørte ulike organisasjoner i sektoren. Dette var (og er fortsatt) utfordrende, selv om helsesektoren i årenes løp har lykkes med å etablere en viss informasjonsflyt på tvers gjennom meldingsutveksling samt noe dokument- og datadeling gjennom ordningen med kjernejournal. Også Helseplattformen i region Midt-Norge var tenkt som en delt infrastruktur. Både sykehus, den kommunale pleie- og omsorgstjenesten og fastleger skulle bruke denne, som landets første helhetlige løsning på tvers av organisasjonsgrenser og forvaltningsnivåer.

Kompleksiteten ved å bygge infrastrukturer

Vår forskning har avdekket en rekke utfordringer knyttet til forsøk på å bygge felles infrastrukturer. En av de sentrale utfordringene er knyttet til beslutningsprosessene. Det er ingen enkeltperson på toppen som har mandat til å ta beslutninger på vegne av alle; nå må man klare å bli enige og samarbeide gjennom andre mekanismer. En måte er å basere samarbeid på ulike former for forpliktende avtaler. Akson-prosjektet ble vurdert som samfunnsøkonomisk lønnsomt dersom kommuner som representerer om lag halvparten av befolkningen utenfor Midt-Norge, valgte å ta løsningen i bruk. Kommunene ble bedt om å signere en intensjonserklæring innen 1. juli 2020, og 183 av 291 kommuner signerte, mens 40 tok et aktivt valg om å ikke signere. Også Helseplattformen valgte en strategi basert på avtaler med kommuner i regionen. Fastlegene er mer krevende å trekke inn, siden det er mange legekontorer, og de er organisert som selvstendige aktører. Helseplattformen startet opp uten at det var gjort avtaler med alle regionens fastleger, men noen legekontorer i Trondheim ble med i den første fasen. I september 2022 valgte man å utsette den videre innføringen hos fastlegene for å jobbe mer med forbedret funksjonalitet. I etterkant har flere fastleger sagt at de ikke ønsker å ta systemet i bruk,² hverken nå eller senere. Dette vil da underminere visjonen om den helhetlige dekningen. I situasjoner hvor ingen sitter på toppen og bare kan bestemme hva aktørene skal gjøre, blir slike kollektive prosjekter sårbare for at noen trekker seg ut eller ikke gjør sin del.

Derfor er det krevende å bygge delte infrastrukturer. Når man forsøker å bygge dem opp fra bunnen av og med slike styringsgrep, vil man ofte støte på dilemmaer knyttet til at deltakerne først får gevinstene av satsingen dersom alle blir med. Kostnadene eller investeringene kommer tidlig, mens gevinstene ligger lenger frem i tid og er mer usikre – de avhenger av at alle de andre blir med, og at man lykkes med prosjektet. Heldigvis er ikke dette den eneste måten å bygge delte infrastrukturer på.

Hvordan bør man håndtere infrastrukturprosjekter?

Forskningen på hvordan store, komplekse, digitale infrastrukturer har vokst frem i mange bransjer, gir noen svar. Ikke minst viser denne forskningen alternative måter å gripe slike store oppgaver an på.

En viktig lærdom er at man ikke trenger å organisere et stort prosjekt selv om oppgaven som skal løses, er stor. Mange av de store infrastrukturene som finnes i den digitale verden i dag, har vokst uten at det har vært en definert, toppstyrt satsing på å etablere dem. I stedet har små, lokale løsninger blitt spredd og tatt i bruk i stadig større grad, til de har blitt så store og sentrale at «alle» vil bruke dem. For å unngå kompleksitet kan det ofte være en fordel å bygge stein på stein over lengre tid, heller enn å ta alle oppgaver i ett jafs, samt å organisere arbeidet ved å bruke de vanlige strukturene og ressursene, heller enn å flytte det ut og definere et eget prosjekt.

Men hvordan kan man få med seg folk om man ikke definerer et stort prosjekt? Store prosjekter kan skape begeistring og har en legitimitet og tyngde som kan dra med seg folk. Men de er allikevel sårbare for det sosiologene kaller kollektive handlingsdilemmaer (Vassilakopoulou et al., 2017). Det som er kollektivt rasjonelt, er ikke nødvendigvis individuelt rasjonelt. For hver enkelt aktør er det mest attraktivt å sitte på gjerdet og la de andre ta seg av kostnadene og risikoen ved å bygge noe nytt, men hvis alle tenker slik, skjer det ingenting. Det er krevende å gå med på å investere tid og ressurser i noe man ikke er sikker på kommer til å gi noe tilbake.

Lever nytteverdi!

Løsningen ligger i at de fleste gjerne vil ta i bruk nye løsninger dersom de har en verdi. Dersom det foreligger en IKT-løsning som forenkler det daglige dokumentasjonsarbeidet, muliggjør enklere informasjonsflyt eller gir bedre beslutningsgrunnlag for dem selv, kan man være villig til å betale det det koster å ta den i bruk – både økonomisk og i form av arbeidsinnsats. Kunsten er å finne et startpunkt for prosjektet som gir verdi fra første stund, og ikke bare i slutten når alt er ferdig og på plass. Slik man i smidig programvareutvikling og entreprenørskap snakker om enkleste fungerende løsning³, må en også tenke på hva som er et lite, men verdifullt nok bidrag til at man kan få med noen aktører på satsingen.

Vi har et godt eksempel på dette i historien om hvordan Danmark lyktes i å etablere digital tilgang til journalinformasjon på tvers av aktører. Løsningen som i dag finnes i Sundhed.dk (informasjonsportalen for danske innbyggere), var opprinnelig en liten og rimelig løsning for å utveksle pasientinformasjon mellom tre sykehus på Jylland, slik at informasjonen kunne følge pasienten som ble overført. Disse sykehusene, deres EPJ-leverandører og en konsulent utviklet en løsning som møtte et konkret behov. Dette gikk raskt og var billig. Da andre sykehus fikk høre om dette, ville de også ha løsningen, og den spredte seg raskt. Etter hvert som brukerantallet ble større, måtte man også rigge seg annerledes og blant annet skalere opp forvaltningen av løsningen. Det ble etter hvert laget en løsning hvor pasientene selv kunne få innsyn i tillegg til fastlegene, og i løpet av få år hadde den blitt en landsdekkende løsning basert på en slik organisk vekstprosess. Et parallelt nasjonalt prosjekt med store budsjetter og mye politisk støtte feilet i det samme tidsrommet. Det var organisert på en tradisjonell måte og kunne ikke levere noen nytteverdi til noen av deltakerne før alt var ferdig utviklet (Aanestad & Jensen, 2011).

Å levere nytte i hvert skritt til deltakerne er en sentral verdi i alternative måter å bygge infrastrukturer på. Infrastrukturer karakteriseres av at de kan ha selvforsterkende vekst – dersom man oppnår kritisk masse, kan man få en snøballeffekt som fører til at bruken plutselig vokser raskt. Slike kvaliteter ved infrastrukturer bør bevisst utnyttes når man legger en strategi (Hanseth & Aanestad, 2003).

Dette er lettere å gjøre dersom man har modulære og ikke monolittiske IT-løsninger. Plattform-arkitekturer hvor man etablerer en felles kjerne som gir rom for utvidelser, er mer fleksible enn alt-i-ett-løsninger.⁴ Da kan delløsninger, for eksempel for spesifikke behov, utvikles uavhengig av hverandre. Dermed trenger ikke alle å vente til alt er ferdig, og man kan klare å levere nytteverdi som forsvarer investeringen (Aanestad & Jensen, 2011). Dette åpner også for at ulike grupper kan bruke ulike løsninger, og man trenger ikke bli enig om alt (Ulfsten, 2023).

Ved hjelp av slike strategier kan man unngå å skape unødvendig kompleksitet. Det er midlertid ikke all kompleksitet som kan unngås, og da er det avgjørende å ha en læringsorientert tilnærming. Det betyr å være forberedt på kompleksitet, ha tiltak slik at man kan observere hvordan det går, og agere mens prosjektet fortsatt går. Man må ha læringssløyfer på plass for raskt å kunne håndtere utfordringer som oppstår underveis (men også overraskende muligheter). Kursen må justeres dersom man ser uforutsette konsekvenser eller forhold. Såkalte smidige tilnærminger til systemutvikling og prosjektledelse har mye å bidra med her.

Kultivering eller konstruksjon?

I forskningen bruker vi metaforen kultivering for å fange opp denne styringsmåten. Vi stiller dette opp som en kontrast til den tradisjonelle måten å styre prosjekter på, som vi kaller konstruksjon. Konstruksjon viser til hvordan vi vanligvis gjør ting: En ingeniør som skal bygge et hus, starter med å planlegge, beregne materialforbruk og kostnader, og legger en plan for forberedelse og fremdrift. Når planen er ferdig og budsjettet på plass, kan arbeidet starte. Da bør man holde seg til planen, ellers kan man få avvik i budsjett eller overskride tidsfristene. Dette ligner på de tradisjonelle tilnærmingene til prosjektstyring, i IKT-verdenen kjent som fossefallsmodeller – hver fase kommer etter at den forrige er avsluttet.

Svært få av verdens vellykkede digitale infrastrukturer er bygget på denne måten. De aller fleste har utviklet seg over tid på en mer organisk måte. Begrepet kultivering dreier tanken over på dyrking, gartnere og andre grønne temaer. En gartner har også mål og planer, men innser at hun ikke har full kontroll over ting – plantene vokser ut fra sin egen indre vekstkraft og betingelsene i jorda. Disse kan påvirkes, men ikke fullt ut kontrolleres. Det er allikevel en aktiv, ikke en passiv strategi. Gartneren følger med og observerer: Trenges det gjødsel og vann? Må jeg luke eller beskjære? Bør jeg støtte opp denne greina litt? Her er læringssløyfene og justeringen sentrale, og man lener seg ikke bare på en prosjektplan med milepæler, men er aktivt i inngrep med aktivitetene for å monitorere og evaluere. Figur 1 oppsummerer forskjellene mellom konstruksjon og kultivering.

Hvordan kan vi styre kultiveringsprosesser?

Denne tilnærmingen står i motsetning til etablert praksis som til en viss grad også er nedfelt i anbefalinger og regelverk. I tillegg vil aktører i helsesektoren også etterspørre dokumentasjon på både helseeffekten og helseøkonomiske vurderinger. Selv om slike vurderinger noen ganger tas lett på av dem som heier frem ny teknologi og fokuserer på mulighetene, så er de viktige. Det er avgjørende for ansvarlig ledelse av helsesektoren at vi velger løsninger som har faktisk nytte for aktørene, som ikke medfører for stor risiko, og hvor bruken er økonomisk forsvarlig.

Ofte vil man se til tradisjonelle evalueringsmetodikker som basis for beslutninger, men heller ikke disse er godt egnet. Selv en tverrfaglig basert metode som Health Technology Assessment (metodevurdering)⁵ har begrensninger, i og med at den baserer seg på at man skal ha oppnådd en form for stabilitet som lar en måle effekter. Utfordringen er at den sosiotekniske dynamikken i virkeligheten er stor – mange ting endrer seg samtidig. Ny teknologi kan endre selve arbeidsoppgavene, men også hvordan oppgaver koordineres og føyes sammen inn i oppgavekjeder – og etter hvert hele tjenestesystemet og organiseringen. Det er ikke lett å definere en før- og etter-situasjon som skal sammenlignes. Det gjelder både omfanget og tidsaspektet: Det er ikke lett å forutse hva som vil endres, og hvor langt utover i det sosiotekniske nettverket ringvirkningen vil forplante seg. Det at slike endringsprosesser forløper over lang tid, gjerne flere år, før det nye nettverket stabiliserer seg, gjør der vanskelig å velge tidspunkt for etter-vurderingen. Situasjonen på ett tidspunkt kan se annerledes ut enn på et annet tidspunkt. Det er i liten grad opplagt hvordan og når man skal måle effekter, og hva disse effektene er.

Rammeverk som tar utgangspunkt i kompleksitet

Trish Greenhalgh har stått i spissen for arbeidet med å utvikle NASSS-rammeverket, som er rettet mot utfordringene man ofte møter med å få ønskede effekter av teknologi (Greenhalgh et al., 2017). Akronymet NASSS kommer fra problemområdene rammeverket dekker: Non-adoption or Abandonment of technology by individuals and difficulties achieving Scale-up, Spread and Sustainability. Rammeverket skiller mellom på den ene siden enkle systemer (med få aktører og komponenter) og kompliserte systemer (med mange agenter og komponenter) hvor relasjonene er veldefinerte og stabile slik at systemet er forutsigbart, og på den andre siden komplekse og adaptive systemer hvor agentene ikke har veldefinerte mål, hvor det er udefinerte grenseflater mellom dem, hvor de kan agere på uventede måter, og hvor én agents handlinger kan påvirke en annen agents handlingsrom. Slike komplekse systemer responderer annerledes på intervensjoner og karakteriseres av uforutsigbarhet og ikke-lineære forløp. NASSS-rammeverket hjelper til med å kartlegge de ulike aspektene og er nyttig i en forberedelsesfase. Det har imidlertid i mindre grad utviklet verktøy for å støtte evaluering.

En annen kandidat er rammeverket utviklet av det britiske Medical Research Council for å håndtere og evaluere det de kaller komplekse intervensjoner (Skivington et al., 2021). Retningslinjene er rettet spesifikt mot å kunne håndtere kompleksitet og bygger på en systemteoretisk forståelse. Utgangspunktet er en anbefaling om å være oppmerksom på kompleksitet og ta den alvorlig, heller enn å søke å kontrollere for den. Anbefalingen bygger på kompleksitetsteori og bruker den som basis, ikke bare for å forstå og modellere helsesystemer (som har vært gjort før), men også for å utvikle evalueringsmetoder. Rammeverket dekker både fasen hvor man utvikler (designer) intervensjonen, utforskningsfasen (engelsk feasibility) rettet mot å utforske kjente så vel som nye usikkerheter, evalueringsfasen (hvor målet er å maksimere kunnskap om de identifiserte usikkerhetene for å støtte beslutninger), og innføringsfasen (hvor arbeidet er rettet mot å maksimere den ønskede effekten). Ulike forskningsmetoder og -perspektiver har sin plass i dette rammeverket. Dette kan være nyttige ressurser når man etablerer en struktur for løpende evaluering og læring.

Vi må bygge nødvendig læringskapasitet for en ansvarlig digitalisering

Kultivering er en strategi for teknologiutvikling som innebærer utprøving fulgt av en læringsorientert og løpende evaluering. Vi står overfor en videre digitaliseringsfase med kraftfulle digitale teknologier som bør utnyttes til beste for samfunnet. Da er det viktig at vi utvikler kompetanse, tilnærminger og verktøy for å kunne møte ny digital teknologi. Vi må unngå å skape unødvendig kompleksitet gjennom våre valg, og vi må klare å håndtere den uunngåelige kompleksiteten som ligger i sosiotekniske endringsprosesser. Da trenger vi evnen til å løpende prøve ut og lære om dens effekter.