Lavkodeløsninger har for lengst gjort sitt inntog i norske offentlige og private virksomheter, og de har bidratt til økt digitalisering innen blant annet helse. Fagpersoner i ulike sektorer kan utvikle løsninger på ulike lavkodeplattformer der de ved hjelp av et grafisk brukergrensesnitt kan lage applikasjoner – skjermbilder, skjemaløsninger, arbeidsflyt med videre – uten programmeringskompetanse. Det eneste de trenger, er opplæring i plattformen, og så er de i gang. Dette er vel og bra, men det er noen fallgruver man må være oppmerksom på.
For det første forsvinner ikke behovet for god utredning og planlegging selv om det er enkelt å lage en løsning. Hvem er den til for? Hva skal den brukes til? Hvordan skal den fungere? Hvilke gevinster skal den gi? Dette er spørsmål som det er vel verdt å bruke tid på innledningsvis, slik at man sikrer at det man lager, faktisk løser et problem for noen, kan brukes effektivt i en arbeidsprosess og gir en gevinst.
For det andre må man bruke tid på å analysere hvilke data man trenger, hvor de kommer fra, hvordan de henger sammen og hva de skal brukes til. Et utbredt problem innen digitalisering er fortsatt dobbeltregistrering fordi systemer ikke snakker godt nok sammen.
Gammel løsning på nye problemer
Isolerte løsninger
Lavkodeløsninger kan lett bli utviklet som isolerte løsninger dersom man mangler kompetanse på hvordan man skal få dem til å kommunisere med andre løsninger. En løsning kan dekke en avgrenset arbeidsprosess eller en del av en brukerreise, men når dataene skal flyte videre på brukerreisen eller inn i neste arbeidsprosess, må de registreres på nytt. Jeg har fått presentert en lavkodeløsning av begeistrede fagfolk som uttalte at ingeniørene var overflødige, men som avsluttet med et fromt ønske om at løsningen deres i fremtiden skulle kunne kommunisere med de andre fagsystemene deres, så de slapp dobbeltregistrering.
Man må også være oppmerksom på at ulike profesjoner som samarbeider, kan omtale samme fenomen på ulike måter. Det er fort gjort å lage et skjema med noen datafelter, men når innholdet skal brukes i flere sammenhenger, må man både bli enige om hvilke begreper man skal bruke og sikre at dataene har et format som kan gjenbrukes.
I en pasienttavleløsning mitt prosjekt skulle forholde seg til, var pasientens norskkunnskaper, språkfunksjon, hørsel og syn samlet i én kommunikasjonsvariabel, på en måte som gjorde det umulig å dokumentere for eksempel at pasienten snakket godt norsk, men hørte dårlig. Det var heller ikke kompatibelt med hvordan samhandlende aktører dokumenterte disse forholdene.
Forventninger
Mange ikke-teknologer forventer at en person med IT-utdannelse er ekspert på datamaskiner, nettverk og programmering. Som IT-utdannet har jeg ofte måttet forklare at en datautdanning ikke nødvendigvis innebærer dype kunnskaper om maskinvare og at en masterutdanning i data, i tillegg til programmering, ofte inneholder blant annet prosessanalyse, informasjonsmodellering og systemdesign. Og det er denne kunnskapen som alltid må brukes når man skal digitalisere, uansett om løsningen skal bygges i lavkode eller utvikles i et programmeringsspråk.
Jeg har selv vært prosjektleder og senere produkteier for en lavkodeløsning for pasientoverganger innenfor kommunal helse- og omsorgstjeneste. Dyktig operativt helsepersonell var tungt inne i utviklingen fra brukersiden, og vi brukte mye tid på å få en felles forståelse for pasientreisen og arbeidsprosessene på hvert tjenestested, bli enige om standardiserte informasjonselementer på tvers av de ulike tjenestene og etablere integrasjoner mot nasjonale og kommunale løsninger i nært samarbeid med IT-arkitekter, utviklere og helsepersonell som jobbet på IT-siden i kommunen.
Oppfordrer til å fortsette å kjøpe tjenester fra selvstendige konsulenter
Menneskesentrert
Visjonen er at teknologien skal være «usynlig» – man skal kunne få hjelp til å gjøre jobben sin uten å måtte tenke spesielt over at man bruker en IT-løsning. For spesielt interesserte anbefales The Design of Everyday Things av den amerikanske forskeren Donald Norman. Han har blant annet sagt noe som tilsynelatende er opplagt, men som veldig ofte ikke er oppfylt: Brukerens behov, ferdigheter, egenskaper og atferd må settes først, og så må designet ivareta disse hensynene. Vi må utvikle teknologi som matcher vår måte å tenke på, heller enn at vårt tankesett må tilpasses teknologien. Teknologien må være menneskesentrert, ikke bare brukersentrert.
I den videre digitaliseringen er det svært viktig at domeneeksperter og IT-folk finner sammen i et fruktbart samarbeid der hver part bidrar med det de er gode på. Da kan vi unngå å skape en rekke lavkodeøyer uten forbindelse, og vi kan heller skape løsninger som underbygger gode brukerreiser med god informasjonsflyt og effektive arbeidsprosesser.
Frp er positive – men med ett forbehold
