Berit Norum, kommunikasjonsrådgiver i NAV, forteller med et indremedisinsk perspektiv om digitaliseringen av sykefraværsoppfølgingen.
Hvorfor står du på scenen på Endringskonferansen, Berit?
Jeg skal fortelle litt om digitaliseringen av sykefraværsoppfølgingen. Det er litt tidlig å si noe helt presist om hva digitaliseringen gjør med arbeidstakerne og arbeidsgiverne, for vi er bare i startgropa av selve innføringen. Derimot synes jeg det er vel så interessant å snakke om hva digitaliseringen gjør med dem som digitaliserer. Altså, hvordan påvirker dette måten NAV utvikler tjenester på.
For å digitalisere sykefraværsløsningen bruker vi smidig metodikk, og det skaper endringer internt i NAV. Ikke minst kommer det til å få en stor betydning for den fremtidige IT-utviklingen. Det har ikke vært en selvfølge at vi fikk lov til å utvikle etter denne metodikken, men nettopp fordi vi fikk lov, og vi har klart å vise til resultater, vil flere komme til å gjøre det samme i NAV.
Men det er klart at dette kan være utfordrende for organisasjonen NAV, og for de som bruker tjenestene våre. Dette er jo også en endring i seg selv, og det bør de som digitaliserer vite noe om. Det skal jeg snakke litt om. Og helt oppsummert? Jeg tror faktisk at lekenheten og det utprøvende i smidig metodikk gir håp for fremtidens digitalisering.
Vil du høre Berit, og mange andre spennende innlegg på Endringskonferansen den 19.oktober, med temaet «Mennesket i digital omstilling»? Da melder du deg på her.
—————————————————————————————————————————
Smidig metodikk forklart noe enkelt av artikkelredaktøren (og alle feil i forklaringen må tillegges henne).
Systemutvikling i sin natur kan være uforutsigbar. Å utvikle etter smidig metodikk har mange fordeler, men ikke alle er kjent med hva dette innebærer. Ved smidig systemutvikling utvikles definerte områder for seg, og område deles opp i mange små deler. Det som gir mest verdi for brukerne utvikles først, tilpasset deres behov. Deretter lanseres det, uten at hele løsningen er ferdig. Løsningen utvikles videre, og det lanseres litt etter litt, basert på kontinuerlig læring og tilbakemeldinger fra blant annet brukere – helt til løsningen er fullstendig utviklet og lansert.
Dette er en leken og utprøvende metode, som gir bedre resultater enn å lansere noe ferdig som er vanskelig å endre på. Man reduserer også risikoen for å utvikle noe som er feil eller ikke gir noen verdi.
Samtidig er ikke dette uten ulemper for omgivelsene. Det krever både tålmodighet og toleranse, både internt og eksternt. Å lansere noe som ikke er fullstendig ferdig er fortsatt ganske nytt for mange, og for brukerne kan det oppleves frustrerende.