Helsedirektoratets Fagrapport om implementering av velferdsteknologi fra 2012 siterer Nis Peter Nissen som sier “velferdsteknologi handler ikke om teknologi… men om mennesker”. Å tolke sitatet bokstavelig kan bety titalls millioner feilinvesterte kroner i digitale velferdstjenester.
Den bitre sannheten er nemlig at velferdsteknologi handler nettopp om teknologi! For å oppnå resultater er det helt avgjørende for kommuner å kunne teknologien inn og ut. Tjenestetenking, tjenestemodeller, “blueprints” og “tjenestesafarier” alene—som nå for tiden brukes overalt –har en tendens til å abstrahere bort de små—og avgjørende—detaljene rundt hvordan ansatte og brukere jobber og lever med teknologi i sin hverdag. Man neglisjerer frustrasjonene, tidstyvene, og gledesmomentene som skapes av nettopp versjon 3.34 av appen. “Brukerreisen” til fru Hansen på 87 år går i uante retninger med en gang versjon 4.32 av selvrapporteringsappen blir lastet ned på smarttelefonen, eller den nye digitale medisindispenseren installeres hjemme. Det er dessverre først når rasjonaliserte tegninger treffer virkeligheten i hundre kilometer i timen at man blir oppmerksom på slike “detaljer”. Og da kan man allerede ha brukt titalls millioner kroner.
Mitt budskap er ikke at teknologene må få lov å sitte i førersete! Jeg vil heller skape forståelse for hvor sentrale detaljene og realitetene i teknologien er. Dette er viktig fordi mange som jobber med utvikling av nye digitale velferdstjenester—inklusive beslutningstakere og deres rådgivere—har en bakgrunn som gjør at de ser på teknologien som en svart boks. Ta falltjenesten—som noen kommuner nå jobber med å utvikle—som et eksempel. Denne tjenesten er ment å skape trygghet hos personer med fallrisiko og deres pårørende, slik at eldre kan bo lenger i sitt eget hjem. Hele verdigrunnlaget for denne tjenesten vil “falle sammen” dersom fallsensoren som brukeren skal ha på seg 24/7 har en utforming som gjør det ubehagelig å ha på, er vanskelig å lade, ser stygt ut, er laget av materialer som gir hudirritasjon, eller har upresis programvare som genererer masse falske alarmer. En tjenestemodell vil rett og slett anta at “brukeren går med fallsensor festet til kroppen” og ignorere alle “detaljene”.
Mange vil argumentere mot, og si at det jobbes på flere fronter, og at tjenestemodellering er kun en front. Det jobbes for eksempel med mange piloter der teknologi blir prøvd ut sammen med brukere. Jeg syns også at piloter bidrar med mye ekstremt nyttig kunnskap. Men, til syvende og sist, piloter er piloter og ikke virkelige tjenester. For å vite hvordan en falltjeneste vil fungere, vil jeg heller ha 4-5 brukere som har fått tildelt og brukt fallsensoren via den virkelige “tjenesteveien” enn femti brukere som har prøvd den ut via en tenkt “tjenestemodellvei” i en pilot. En pilot kan selvfølgelig bygges på samme infrastruktur som den virkelige tjenesten skal operere i, for å øke dens validitet. Men vi har ofte sett at dette er vanskelig. Det er f.eks. ikke mange som ser verdien av å integrere en fallsensor med kommunens infrastruktur allerede i en pilot. Det er jo tross alt snakk om bare en pilot! Og tunge anskaffelses- og konkurranseregler gjør dette heller ikke så enkelt for de som ønsker det. Vi vet fra litteraturen at opp til 90% av alle piloter innenfor helse-relatert teknologi forblir piloter.
Konsulenter og tjenestedesigneksperters innmarsj i nasjonalt program for velferdsteknologi er et tegn på at tjenestemodelltenking råder også hos Helsedirektoratet. Nå som vi får eget e-helsedirektorat kan det være på sin plass å reflektere rundt måten nye teknologi-baserte tjenester innenfor helse og velferd utvikles. Direktoratets mål har vært at velferdsteknologitjenester skal være en naturlig del av tjenestetilbudet i kommunene innen 2020. Datoen blir mest sannsynlig forskjøvet til 2025. Jeg er redd for at denne datoen kan bli enda mer forskjøvet.
Hva kan gjøres? Det er selvsagt utopisk å forvente eller ha klare svar på problemet. Men det er lov å lære av andre som har vært i lignende situasjoner. Det er spesielt to bransjer jeg vil nevne. Programvarebransjen gjorde en helomvending for mer enn ti år siden da de gikk fra vannfallsmodeller for prosjektstyring—hvor det ofte ble laget omfattende modeller og kravspesifikasjoner—til å bruke smidige metoder med fokus på iterativ og empirisk utprøving av produkter. Det samme har skjedd nylig innenfor entreprenørskap, der man igjen har gått vekk fra vannfallsmodeller med fokus på detaljerte forretningsplaner, til det som har fått navnet “lean startup“. Poenget med lean startup er å prøve å treffe virkeligheten i fem kilometer i timen i stedet for hundre, men gjerne treffe den flere ganger på rad. Det gjør mindre vondt, man lærer av det, og man kan garantert reise seg opp igjen.