e-helseløsninger forenkler hverdagen

Postet den av
Svar

Digitalisering betyr forenkling. Fordi dagens teknologi muliggjør forenkling gjennom redesign av tjenester med underliggende verdikjeder og prosesser som har eksistert i lang tid. Derfor er det lurt å ta utgangspunkt i behovet og ikke prosessen for å dekke behovet når du skal digitalisere og forenkle noe. Det krever en kundesentrisk tilnærming.

Et godt eksempel finner vi i helse- og omsorgssektoren, som bruker begrepet e-helse om digitalisering i egen sektor.

Illustrasjonsfoto fra National Cancer Institute på Unsplash

Helsetjenester under press

Helsetjenestene i Norge har høy kvalitet og er blant verdens beste. Likevel er det et stort behov for forenkling, fordi helsetjenestene er satt under press. Det er minst tre årsaker til at dette skjer:

  • Vi blir flere og lever lengre, som medfører økt etterspørsel av helsetjenester.
  • Det kommer stadig nye behandlingsmuligheter, som krever mer ressurser.
  • Helsetjenestene er kostbare og skalerer dårlig på grunn av menneskelig involvering.

Dersom vi ikke gjør noe med måten vi forebygger og behandler sykdom på, vil ikke helsetjenestene være bærekraftig i framtiden. Derfor er det helt nødvendig å anvende IT riktig og tenke nytt rundt forebygging og behandling.

Heldigvis er dette noe ansvarlige ledere i sektoren allerede vet. Men å omsette denne kunnskapen til praktisk handling er som kjent utfordrende, og da kan det være godt å få inn litt ekstern hjelp. Slik kom jeg inn som rådgiver for å videreutvikle produktstrategi for de nasjonale e-helseløsningene, som inkluderer helsenorge, e-respt og kjernejournal.

Problemet som søkes løst

Dagens IT systemer støtter i for liten grad opp under målsettingen om at nødvendige helseopplysninger skal følge pasienten gjennom hele pasientforløpet. Denne erkjennelsen ble beskrevet i Stortingsmelding 9 (2012-2013) Én innbygger – én journal. Der står også tre overordnede mål for IT-utviklingen i helse- og omsorgssektoren:

  • Helsepersonell skal ha enkel og sikker tilgang til pasient- og brukeropplysninger
  • Innbyggerne skal ha tilgang på enkle og sikre digitale tjenester
  • Data skal være tilgjengelig for kvalitetsforbedring, helseovervåkning, styring og forskning.

Disse målene er utgangspunktet for Nasjonal strategi for e-helse, hvor det blant annet står: «For å nå helsepolitiske mål om bedre kvalitet, økt pasientsikkerhet og bedre bruk av kompetanse og ressurser er det nødvendig å utnytte mulighetene som ligger i digital teknologi på en bedre måte. E-helseløsninger utfordrer eksisterende arbeidsmåter, tankesett og kultur i helse- og omsorgstjenesten. Det er derfor avgjørende med fokus på endringsledelse for å lykkes med digitaliseringen.»

Etter min oppfatning er det en god beskrivelse av hva som må gjøres på et overordnet nivå. Men som alltid er det gjennomføringen av strategien som blir avgjørende for om den er god eller ikke.

Veikart for e-helse

Strategien for e-helse er brutt ned i konkrete krav, som skal oppfylles gjennom tiltak som strekker seg fra 2019 til 2025. Veikartet beskriver krav om at:

  • Innbyggere skal ha mulighet for å administrere behandlingsforløp, digital dialog og innsynstjenester gjennom Helsenorge
  • Helsepersonell skal ha tilgang til pasientens legemiddelliste
  • Helsepersonell skal ha tilgang til en oppdatert og autorativ beskrivelse av kritisk informasjon
  • Helsepersonell skal ha tilgang til journaldokumenter uavhengig av hvor pasienten har mottatt helsehjelp
  • Helsepersonell skal ha tilgang til laboratorie- og radiologisvar uavhengig av hvor undersøkelsen er foretatt
  • Helsepersonell skal ha tilgang til dialogmeldinger og forbedrede henvisninger
  • Innbygger skal ha muligheter for digital hjemmeoppfølging
Veikart for nasjonale e-helseløsninger 2021 – 2025

Mange av tiltakene i veikartet for nasjonale e-helseløsninger realiseres blant annet gjennom kjernejournal. Ett av tiltakene er tidligere nevnte pasientens legemiddelliste, PLL.

Helsepersonell dokumenterer behandling som gis i en elektronisk pasientjournal (EPJ). I dag fins det mange ulike leverandører av EPJ, og helseforetakene har anskaffet ulike løsninger. Derfor er det et behov for et sentralt register – hvor helsepersonell kan slå opp og få tilgang til kritisk informasjon om pasienten. Det er her kjernejournal kommer inn.

Helsenorge

Helsenorge er innbyggerportalen, hvor alle innbyggerne kan få innsyn i opplysninger om seg selv, legge inn nye opplysninger og bestille tjenester.

Innbyggerportalen helsenorge.no

Helsenorge tar utgangspunkt i innbyggernes behov for innsyn og medvirkning til opplysninger knyttet til egen helse, og ikke eksisterende prosess. Kanskje er det derfor det har blitt en suksess målt i antall oppslag. En annen forklarring kan være at selvbetjening gjennom Internett er et relativt nytt fenomen, som det ikke eksisterte en innarbeidet prosess for.

E-resept

Resepter inneholder opplysninger om legemidler, og praksisen med å sende papirbaserte resepter mellom leger og apoteker har eksistert så lenge at den digitale utgaven – e-resept – startet ved å erstatte resepter på papir med elektroniske utgaver av de samme skjemaene. Prosessen med å behandle reseptene ble også kopiert. Dermed ble de elektroniske utgavene av skjemaet sendt mellom aktørene i verdikjeden gjennom en tjeneste kalt «reseptformidleren» – som om de fremdeles var papirdokumenter.

Men etter å ha gått gjennom dette nødvendige første steget (strøm på papir), arbeides det nå heldigvis med å utvikle Pasientens Legemiddelliste, forkortet til PLL.

Hvorfor det? Jo, fordi PLL er en mye bedre måte å utveksle informasjon om hvilke medikamenter den enkelte pasient bruker mellom alle aktører som trenger denne informasjonen. Det gjøres blant annet gjennom kjernejournal, som jeg vil komme tilbake til.

Både fastleger, legevakter, sykehus, apotek og bandasjister bruker e-resept, og i dag er omtrent 93% av alle resepter utskrevet elektronisk. Det sendes rundt 27 millioner e-resepter til reseptformidleren årlig.

Kjernejournal

Kjernejournal er et virksomhetsovergripende, behandlingsrettet helseregister som skal øke pasientsikkerheten ved å bidra til rask og sikker tilgang til strukturert informasjon om pasienten til helsepersonell på tvers av:

  • Omsorgsnivåer (primær- og spesialisthelsetjenesten)
  • Virksomheter (offentlige og private aktører)
  • Regioner (nord, midt, vest og sør-øst)

I kjernejournal finner du følgende informasjon:

  • Om pasienten (kilde: offentlige registre)
  • Pasientens egne registreringer
  • Legemidler (kilde: offentlig register)
  • Kritisk informasjon (kilde: helsepersonell)
  • Besøk i spesialisthelsetjenesten (kilde: offentlig register)
  • Journaldokumenter (kilde: helseforetak)
  • Prøvesvar luftveispatogen (kilde: offentlig register)
  • Vaksinasjoner (kilde: offentlig register)
  • Pasientens personverninnstillinger (kilde: pasienten)

I tillegg arbeides det med å gjøre flere informasjonstjenester tilgjengelig:

  • Lab- og radiologisvar (offentlig register)
  • Digitale behandlingsplaner og egenbehandlingsplaner (helsepersonell)

Søkbare data

Utfordringen er å gå fra ustrukturerte data til strukturerte data som er lettere å søke i. Dagens situasjon er at helsepersonell skriver ustrukturerte data i form av fritekst i kliniske fagsystemer. Det er «strøm på papir», og skyldes rett og slett at vi gjør det samme som tidligere, bare digitalt.

Ønsket tilstand er strukturerte, søkbare data. Men det krever enighet om kliniske informasjonsmodeller. Et problem er at det ikke er ensartet bruk av kodeverk i sektoren. Ulike applikasjoner og løsninger har implementert ulike informasjonsmodeller. Det medfører et behov for oversettelse uten at den medisinske betydningen endres. Gamle kliniske applikasjoner ble ikke laget for å utveksle data med andre systemer. Derfor trengs det standarder som sikrer lik definisjon av medisinske data.

Standardisering

Heldigvis er dette arbeidet kommet godt i gang, og det arbeides med en rekke standarder. For eksempel er SNOMED CT den mest omfattende standarden for klinisk terminologi på det internasjonale markedet i dag, og representerer et system av rundt 350.000 begreper.

Det kommer til å ta tid før alle leverandørene av kliniske fagsystemer har oppdatert produktene sine til å kunne utveksle data i henhold til den aktuelle standarden. Det er en utfordring vi sannsynligvis må leve med en god stund fremover.

Teknisk gjeld

Leverandører av kliniske fagsystemer, herunder Elektroniske Pasient Journaler (EPJ), må adressere teknisk gjeld i sine respektive løsninger. Teknisk gjeld kan defineres som alt det uferdige, unødvendig kompliserte og utdaterte i IT-løsningen som hindrer oss i å drifte, forvalte og videreutvikle så effektivt som vi ellers kunne gjort.

Teknisk gjeld er også noe ledere og innkjøpere i helseforetak bør være oppmerksomme på. De bør stille følgende spørsmål til sine leverandører av kliniske fagsystemer:

  • Hvor mye teknisk gjeld har den aktuelle løsningen?
  • Hva gjør leverandøren for å nedbetale den?

Svarene du får, vil gi deg en indikasjon på hvilke leverandører som er robuste nok til å bli med videre i den digitale transformasjonen.

Refleksjon

Dersom morgendagens helsetjenester skal bli bærekraftig må vi redesigne prosesser slik at de tar utgangspunkt i pasientens og helsepersonellets behov – ikke prosessen vi har benyttet fram til i dag. Det er enklest på helt nye områder, hvor det ikke eksisterer en etablert prosess, som innbyggerportalen helsenorge. Så er det litt vanskeligere på områder det allerede eksisterer en prosess, som e-resept, hvor en har gått fra reseptformidleren til pasientens legemiddelliste.

Å løse den store utfordringen – at dagens IT systemer støtter i for liten grad opp under målsettingen om at nødvendige helseopplysninger skal følge pasienten gjennom hele pasientforløpet – krever utskifting av systemer og at det blir gjort på riktig måte. En viktig del av dette handler om hvordan vi skal bevege oss bort fra ustrukturerte data i gammeldagse, monolittiske systemer til standardiserte og strukturerte data som er søkbare og gjort tilgjenglig i digitale plattformer som kjernejournal.

Hvordan bli mer datadrevet?

Postet den av
1

De aller fleste av oss ønsker å ta gode beslutninger som er basert på fakta. Med fakta menes riktige og sikre opplysninger om virkeligheten, som reduserer usikkerhet rundt hvilke konsekvenser beslutningen vil føre til. Det kan dreie seg om å redusere risiko, som er usikkerhet knyttet til nedside, eller å se muligheter for verdiskapning basert på innsikt – som er usikkerhet knyttet til oppside. Så det ene er å optimalisere noe man allerede gjør, mens det andre er å begynne å gjøre noe nytt.

Et faktum skal være mulig å teste og verifisere. Derfor opererer vi med antagelser eller hypoteser helt frem til hypotesen blir bekreftet eller avkreftet. Det er her data kommer inn som en måte å lagre, overføre og prosessere informasjon – som er grunnlaget for å ta gode beslutninger. Men hvorfor velger så mange å bruke egen magefølelse som beslutningsgrunnlag i stedet for data? Det er verdt å undersøke nærmere.

Illustrasjonsfoto av Franki Chamaki på Unsplash

Det kan være flere årsaker til at mange av oss velger egen magefølelse fremfor data. Min erfaring kan oppsummeres i tre punkter:

  • Mangler data
  • Dårlig kvalitet på data
  • Stoler ikke på de dataene en har

Som regel er det en sammenheng ved at de to første punktene resulterer i det siste punktet. Når du mangler data, og vet at det datasettet du har er ufullstendig, blir konsekvensen at du ikke kan stole på dataene. Derfor velger mange å lene seg til egen erfaring og magefølelse som beslutningsgrunnlag.

Så dersom du som leder ønsker at din virksomhet skal bli mer datadrevet – er det min erfaring at du må adressere de tre rot-årsakene først. Kall det gjerne «fix the basics», som en CFO jeg møtte nylig så treffende kalte det.

Mangler data

Dersom du ikke har data, er det lite å ta beslutninger på. Men ofte fins dataene, bare at de er utilgjengelig og vanskelig å finne når en trenger dem. Dataene som eksisterer, er nemlig «innesperret» i gammeldagse IT-systemer som ble utviklet til et bestemt formål. For eksempel HR, regnskap, kundehåndtering (CRM), produksjon (ERP) med flere.

Jeg opplever at problemet mange beslutningstakere har, er å få gode rapporter som gir beholdningsoversikter og prognoser de kan bruke for å ta gode beslutninger rundt anskaffelser, utvikling og drift. Det koster for mye i tid og penger å få ut rapportene, som helst skal vise data i sann tid, og ikke være en måned gammel. Aller helst ønsker vi oppdaterte data i form av et dashbord som viser tilstand og fart i forhold til de viktigste måleparameterne. KPIene.

Løsningen er å trekke ut data fra ulike kildesystemer og presentere dem i sann tid for beslutningstakere. For at dataene skal gi verdi, må de settes i en kontekst og være tilgjengelig for dem som trenger dem, når en trenger dem. Med andre ord må data kobles til forretningsmål og måleparametere som Key Performance Indicators (KPI) eller Objective and Key Results (OKR), og gjøres selvbetjent gjennom dashboard.

Dårlig kvalitet på data

God datakvalitet innebærer at dataene har evnen til å støtte informasjonsformålet de brukes til. Med andre ord er det et krav at dataene skal understøtte informasjonsbehovet den enkelte beslutningstaker har. Det innebærer at det stilles krav til at data er:

  • Korrekt
  • Fullstendig
  • Tidsrelevant
  • Konsistent

Når kvaliteten på data er dårlig, skyldes det som regel svikt i en eller flere av punktene over. Dersom du ikke registrerer data på riktig måte, oppstår det feil i datagrunnlaget, med konsekvens at data blir ukorrekt. Når man ikke registrerer alle forekomstene i en oversikt, blir datagrunnlaget ufullstendig. For eksempel ved at man ikke registrerer alle enhetene som går inn eller ut av et lager, eller ikke slår inn alle varene i kassen i et salg.

Det hjelper lite med korrekt og fullstendig informasjon dersom tidsvinduet for å handle ut fra beslutningsgrunnlaget er lukket og muligheten gått tapt. Videre er det også et krav at dataene ikke må inneholde innbyrdes motsigelser. Kravet om å være konsistent er et grunnleggende vilkår for oppbygging og godtagelse av logiske kunnskapsmengder, fordi det motsatte, den logiske motsigelse, synes å gjøre enhver form for orden og rasjonalitet umulig.

Stoler ikke på de dataene en har

Her tror jeg vi kommer til sakens kjerne, det vil si hvorfor så mange velger egen magefølelse fremfor data som beslutningsgrunnlag. Når du vet at egne data ikke gir et korrekt bilde av virkeligheten, enten fordi de er ufullstendige eller inkonsistente, og det tar for lang tid å få tak i dem – er det ikke så rart at man ikke bruker data som beslutningsgrunnlag. Det er slett ikke vanskelig å forstå.

Hva er løsningen?

Så hvis kjernen i problemet er at du ikke stoler på de dataene du har – må løsningen være å snu dette. Det er et langsiktig arbeid som innebærer en transformasjon for hele virksomheten mot å bli mer datadrevet i store og små beslutninger. Jeg tror det er viktig å komme riktig i gang, og det er her bruk av ekstern kompetanse kan være både nyttig og verdifullt. Det merker jeg blant annet gjennom økt etterspørsel av konsulenttjenester for å bli mer datadrevet.

Datadrevet virksomhet

Datadrevne virksomheter er organisasjoner som baserer beslutningene sine på data, og bruker innsikt til å forbedre prosesser og fornye forretningsmodeller. For å komme dit, må du jobbe aktivt med å øke datakvaliteten, slik at du kan stole på de dataene du har. Til dette vil du også trenge endringsledelse for å iverksette og forankre beslutningene i hele organisasjonen.

Når det grunnleggende fundamentet er på plass, og «fix the basics» er gjennomført, kan du begynne å utforske hvordan data kan brukes på nye måter for å skape kundeverdi og forretningsverdi. Gjennom systematisk læring og kontinuerlig forbedringsarbeid over tid, kan dere ta små og store skritt i retning å bli en datadrevet virksomhet.

Hva gjør en Chief Digital Officer (CDO)?

Postet den av
1

Chief Digital Officer betyr, som navnet antyder at du er sjef for digitalisering. Det var en slik rolle jeg som innleid konsulent fylte i et middels stort norsk selskap. Av hensyn til kunde-konfidensialitet omtaler jeg det heretter bare som Selskapet.

På 15 år hadde Selskapet vokst fra 0 til 600 millioner i omsetning, som resultat av systematisk godt arbeid og en svært dyktig ledelse. Kanskje var det nettopp derfor de nå ønsket ekstern bistand fra Sopra Steria inn i rollen som CDO – for å tilføre kompetanse de ikke hadde selv. Jeg tror det var et smart trekk, fordi effekten ble verdifull læring – for alle involverte. Denne posten vil besvare to spørsmål:

  • Hvorfor trenger du en CDO?
  • Hva er rollen og oppgavene?

Hvorfor trenger du en CDO?

En CDOs overordnede ansvar er å drive vekst og strategisk fornyelse gjennom å være CEOs rådgiver og utøvende leder i å transformere selskapet. Fra det som er – til en bedre utnyttelse av mulighetene informasjonsteknologi gir virksomheten. Det legges spesielt vekt på å skape ny verdi gjennom smart bruk av digitale verktøy, plattformer, teknologier, tjenester og prosesser.

Digitalisering sto sentralt i SeIskapets strategi, som var bygd på fem prioriterte mål:

  1. Digitalisere prosesser for å øke konkurransekraften
  2. Skape lønnsom vekst i Norge, Sverige og Danmark gjennom nye produkter og nye distribusjonskanaler
  3. Påvirke og tilpasse oss endringer i lovverket
  4. Effektivisere og forbedre administrative arbeidsprosesser for å takle vekst
  5. Få kunder til å foretrekke og velge Selskapets produkter og tjenester
Digitalisering er et middel for å skape vekst og lønnsomhet

Selv om en CDO har et spesielt ansvar for digitalisering, var CEO for Selskapet tydelig på at hele ledergruppen skulle føle dette ansvaret, ikke bare en person. Derfor valgte de å leie inn Sopra Steria, som i dette tilfellet var meg, i en avgrenset periode.

Rollen og oppgavene

For dette spesifikke oppdraget ble rollen til Sopra Steria formulert i en standard kontrakt for konsulentbistand, hvor det blant annet sto:

Sopra Steria skal være en sparringspartner og rådgiver for Selskapet i digitaliseringsspørsmål. Videre skal Sopra Steria være prosessdriver for å etablere en samordnet og integrert virksomhetsarkitektur som muliggjør innovasjon i Selskapet.

Det vil i hovedsak dreie seg om tre oppgaver:

  • Bistå med å vurdere Selskapets portefølje av IT-prosjekter, herunder prioritering av disse, mulighet for samordning/samkjøring av prosjektene, samt en vurdering av gevinstpotensial ved automatisering av egnede steg i selskapets kjerne- og støtteprosesser. Hvor kan Selskapet hente størst gevinst gjennom de muligheter dagens teknologi gir oss? (RPA, AI, Cloud, VR, med flere)
  • Etablere et overordnet kart over selskapets virksomhetsarkitektur og analysere utnyttelsesgraden til selskapets nåværende applikasjoner, samt ideell arkitektur og system-sammensetning.
  • Lede og koordinere Selskapets prosjektportefølje innenfor IT- og digitaliseringsprosjekter i en periode på 6 – 12 måneder.

Det er for øvrig viktig at den bistanden Selskapet får bidrar til å bygge intern kompetanse og robusthet, slik at rutiner, systemer og metodikk kan arves av interne ressurser og bygges videre på også etter at dagens avtale om bistand fra Sopra Steria opphører.

Gjennomføring

I løpet av de tre første ukene gjorde jeg meg kjent med Selskapet ved å snakke med ledere og medarbeidere. Det jeg så etter var hvordan Selskapet var satt sammen og produserte verdi. Gjennom samtaler med utvalgte representanter for ulike enheter i verdikjeden tegnet jeg meg et bilde av nå-situasjonen og områder med forbedringspotensial.

For å systematisere det jeg observerte, brukte jeg tre metoder for min egen forståelse og måte å kommunisere med de forskjellige interessentene i Selskapet:

  • Strukturert problemløsning som betyr å identifisere og strukturere problemer.
  • Strukturert kommunikasjon som betyr å analysere og kommunisere tydelig.
  • Virksomhetsarkitektur som betyr å gruppere og prioritere informasjon lagvis i forretningsarkitektur, informasjonsarkitektur, applikasjonsarkitektur og teknologisk arkitektur.

Etter tre uker, presenterte jeg til ledergruppen hva jeg hadde observert. Jeg strukturerte det jeg hadde observert slik:

  • Situasjon
  • Komplikasjon
  • Spørsmål
  • Svar

Situasjon

«Selskapets vekst og digitalisering legger press på IT-løsninger og kjernesystemet.»

Denne observasjonen underbygget jeg med en arkitekturskisse for å forklare hvordan arkitekturen hang sammen og blitt endret i løpet av de siste årene. Kort fortalt var det et bilde med bokser og piler, inndelt i lag for forretning, applikasjon og teknologi.

Selskapets vekst innebar at behovene for IT-verktøy endret seg. Det som før kunne håndteres med manuelle rutiner, medførte etter hvert som selskapet ble større, en økende risiko for feil, dårligere kvalitet og misfornøyde kunder.

Digitaliseringen legger press på kjernesystemet blant annet fordi kundene skulle få selvbetjening gjennom en kundeportal på internett. For å hente ut data fra kjernesystemet, måtte det bygges nye databaser og integrasjoner. Dette økte kompleksiteten. I tillegg var ikke kjernesystemet designet for slik bruk, slik at det oppsto ytelsesproblemer som konsekvens.

Komplikasjon

Strategiske valg så langt har medført:

  • Teknologisk gjeld
  • Mange parallelle IT-initiativer og aktører
  • Økt kompleksitet i applikasjoner og prosesser

Spørsmål

Det var tre sentrale spørsmål som jeg ønsket å forankre i ledergruppen. Hensikten var å få dem til å forstå hva jeg hadde sett, slik at de kunne være med på å diskutere dem og ta informerte beslutninger. Å formulere riktige spørsmål – som betyr en prioritering av hva som er viktig – er en sentral del av analysen.

  1. Er kjernesystemet og leverandøren en god strategisk match for Selskapet?
  2. Hvilke strategiske valg har Selskapet for den videre digitaliseringen?
  3. Hvordan bør Selskapet gå frem i et eventuelt skifte av kjernesystem?

Så presenterte jeg min vurdering for ledergruppen, som de etter en kort stund også stilte seg bak.

Svar

Spørsmål 1

Er kjernesystemet og leverandøren en god strategisk match?

Leverandøren av kjernesystemet var et lite selskap som var en god match med Selskapet – da det i oppstartsfasen også var et lite selskap. Men på grunn av begrensede ressurser og det jeg oppfattet som manglende vilje og evne til å videreutvikle produktet, mente jeg at leverandøren ville hemme Selskapet i å oppnå deres ambisjon om videre vekst. Det ble meg også fortalt flere episoder hvor leverandøren ikke klarte å gjøre endringer raskt og godt nok, etter at en nøkkelperson hadde sluttet.

Slik jeg så det, ville konsekvensen av å beholde kjernesystemet bli at Selskapet hadde et svakt fundament for sin digitale satsing. Videre anslo jeg at utbedringer ville ha høy kost og lavt gevinstpotensial – på lang sikt. Men ikke på kort sikt. For det er alltid billigere å reparere det en har fremfor å kjøpe nytt. Men den operasjonelle risikoen vil gradvis øke, for hver lapping og utbedring som gjøres, uten å betale ned den tekniske gjelden.

Jeg konkluderte derfor med at kjernesystemet og leverandøren av det ikke ville være i stand til å støtte Selskapets videre vekst. Med andre ord var svaret på spørsmål en – nei.

Etter hvert som denne innsikten modnet – ble også de andre i ledergruppen enig.

Spørsmål 2

Hvilke strategiske valg har Selskapet for den videre digitaliseringen?

Jeg skisserte tre alternative strategier, med hensikt å få ledergruppen til å reflektere over dem og til slutt velge en.

  1. Behold og utbedre svakheter i kjernesystemet. Bygg ny kundefront og automatisering på gammel kjerne.
  2. Bygg ny standardisert integrasjonsplattform. Bytt kjerne og andre applikasjoner ved behov.
  3. Kjøp plattform og utnytt integrerte moduler. Koble applikasjoner ved behov. Saner gamle applikasjoner.

Alternativ 1 (Behold og utbedre svakheter) gir Selskapet lønnsomhet på kort sikt, men er ikke fremtidsrettet og bærekraftig på lengre sikt. Dette innebærer en videreføring av dagens praksis.

Fordeler: Løsningen gir stabil drift på kort sikt. Kan tilføres bedre ytelse og funksjonalitet med relativt lav endringskostnad og risiko – på kort sikt.

Ulemper: Løsningen bygger på utdatert teknologi og en svak leverandør. Den vil på et tidspunkt begrense videre vekst. Ved et eventuelt senere skifte, vil all utbedring i gammelt kjernesystem være bortkastet.

Alternativ 2 (Bygg integrasjonsplattform, bytt ved behov) gir Selskapet full handlefrihet til å utveksle data mellom applikasjoner internt og eksternt. Dette alternativet var allerede foreslått av IT-konsulenter som gjerne ville bidra til å bygge en integrasjonsplattform.

Fordeler: Gir frihet og leverandøruavhengighet. Det vil være enklere å bytte applikasjoner, og Selskapet får full kontroll over dataflyten mellom systemene.

Ulemper: En plattform som bygges av Selskapet, må også forvaltes og videreutvikles av Selskapet. Det krever kompetanse og en tydelig datamodell og arkitektur. Konsekvensen blir ofte at en bygger mer teknisk gjeld.

Alternativ 3: (Kjøp plattform og utnytt integrerte moduler. Saner gamle applikasjoner) gir Selskapet tilgang til innovasjon og standardisert funksjonalitet som oppdateres kontinuerlig av leverandøren.

Fordeler: Den kan kjøpes som en tjeneste, ferdig utviklet. En utnytter innovasjonskraften hos leverandøren, og det er rimelig å gå ut ifra at integrasjoner kan gjøres enkelt. Med en sky-basert tjeneste vil det også være enkelt å øke kapasiteten i takt med Selskapets videre vekst.

Ulemper: Data må migreres, som vil si at den overføres fra det gamle kjernesystemet til det nye. Det er ikke risikofritt, fordi dataformater og grunnleggende definisjoner ofte er ulike. Standardiserte prosesser vil kreve endringer i måten en jobber på, og dermed begrenses friheten.

Jeg anbefalte alternativ 3, som etter en grundig vurdering i ledergruppen – og styret – ble valgt.

Spørsmål 3

Hvordan bør Selskapet gå frem i et eventuelt skifte av kjernesystem?

Å skifte kjernesystem betyr både høy risiko og mulighet på samme tid. Det kan sammenlignes med en hjerte-transplantasjon, fordi konsekvensene ved en feil kan være katastrofale. Derfor er dette et strategisk spørsmål som må styrebehandles.

Jeg foreslo og fikk gjennomslag for følgende fremgangsmåte:

  1. Stans alle IT-prosjekter for å unngå bortkastet arbeid.
  2. Få oversikt og kontroll på virksomhetsarkitektur. Koble strategi, prosesser, aktiviteter, funksjoner og applikasjoner på en forståelig måte.
  3. Definer forretningsbehov for nytt kjernesystem
  4. Undersøk mulige kjernesystemer i markedet
  5. Gå i dialog med utvalgte leverandører
  6. Test ut to løsninger gjennom en demonstrasjon
  7. Vurder kost, nytte, og risiko
  8. Velg leverandør
  9. Planlegg transisjon før skiftet.
  10. Migrer data og saner gammelt system.

Refleksjon

I dag er selskapet kommet til punkt 9 på listen og er godt i gang med forberedelsene for å skifte kjernesystem. Det betyr at de kan bygge den videre digitaliseringen på et solid teknologisk fundament, når nytt kjernesystem er på plass. Dermed er de godt rustet til å utnytte teknologiske muligheter for å styrke kjernevirksomheten og bygge nye evner for verdiskapning i fremtiden.

Hva betyr IT Excellence?

Postet den av
Svar

Som leder for en avdeling som heter «IT Excellence» har jeg reflektert litt rundt dette spørsmålet, og ønsker å dele mine tanker i denne posten. Så må jeg presisere at det som deles i denne bloggen er kun på vegne av meg selv, og representerer ikke nødvendigvis Sopra Steria sitt offisielle syn.

Definisjon

«Excellence» handler om kvalitet, og betyr på norsk kvaliteten på å være enestående, fremragende eller ekstremt god. Det er også betingelsen for å være overlegen de en sammenligner seg med. Enten det er snakk om konkurrenter, eller andre aktører en gjennomfører benchmarking mot for å forbedre seg.

«IT» er – som de fleste vet – en forkortelse på informasjonsteknologi.

Dermed kan vi si at «IT Excellence» handler om ekstremt god kvalitet på informasjonsteknologi og utnyttelse av muligheter den gir for å skape forretningsverdi.

For meg betyr IT Excellence to ting:

  • En ambisjon som mine kollegaer og jeg jobber hardt for å oppnå – hver dag.
  • Et navn på en rådgivningsenhet som løser problemer og skaper forretningsverdi – for kundene våre og oss.

Verdibudskap

IT Excellence enheten tilbyr rådgivning til ledere for å utnytte det fulle potensialet i teknologi. Mottakerne hos kundene har fullmakt til å ta strategiske beslutninger, og er typisk enten CEO, CFO, CIO, CDO, COO eller en linjeleder i sin virksomhet. Rådgivningen inkluderer strategi, design, utvikling og drift av digitale plattformer som bidrar til å styrke kjernevirksomheten og bygge nye evner til verdiskapning i framtiden. 

Illustrasjonsfoto av Jamie Street på Unsplash

Kompetanse

Vår ekspertise inkluderer analytisk problemløsning, strategiske valg og vurderinger, teknologiledelse og -styring, virksomhetsarkitektur, og endringsledelse. Typiske oppdrag inkluderer rådgivning innen digitalisering og transformasjon.

Ved behov går våre konsulenter inn som midlertidig linjeleder for teknologi hos kundene våre. Eksempler på slike lederfunksjoner inkluderer interim CIO, CDO, IT-direktør, virksomhetsarkitekt, utviklingssjef, seksjonsleder, avdelingsleder, med flere.

Produkter og typiske leveranser inkluderer ekspertvurderinger, nå-situasjonsanalyser, arkitekturmålbilder, gap-analyser, strategiske veikart og operasjonelle handlingsplaner.

Profiler

Våre rådgivere har bred og dyp kompetanse innen teknologi, ledelse og innovasjon. Det gjør at de evner å se nye muligheter og kan utfordre eksisterende antagelser på en konstruktiv og inkluderende måte, som er inspirerende og verdifull for våre kunder.

Synergi

I Sopra Steria er IT Excellence enheten en integrert del av Digital Platform Services (DPS), som er en divisjon med over 1000 dyktige medarbeidere i Norge. DPS tilbyr egenproduserte plattformtjenester (Platforms), implementering av tredjeparts plattform-løsninger (Solutions), prosjekt og programledelse (Delivery), sikring av data og plattformer (Cyber Security), samt drift av IT-infrastruktur og applikasjoner for kunder (Operations).

Strategi

Målet er å være ekstremt god på å skape forretningsverdi av IT – for Sopra Steria og kundene våre – gjennom en systematisk, organisatorisk læring og kontinuerlig forbedring. Vi skaper best verdi – sammen med kundene – når vi klarer å utnytte bredden og dybden i kompetansen som fins i hele selskapet med over 2000 medarbeidere i Norge. Vår store faglige bredde og dybde innen digitalisering og digital transformasjon mener vi differensierer oss fra våre konkurrenter.

Refleksjon

IT Excellence er en ambisiøs målsetting – som inspirerer meg – til å lære mer om hvordan IT skaper verdi for kunder og forretning. For selv om jeg har både bred og dyp erfaring på området, er jeg langt fra ferdig utlært.

For meg har det heller aldri vært noe alternativ å slutte med læring. De som eventuelt tror de ikke har mer å lære, blir lett høye på seg selv, og etter hvert akterutseilt. Derfor jobber mine kollegaer og jeg med kontinuerlig forbedring og læring – for å bli enda bedre på noe vi allerede er gode på. Vi jobber med å utvikle både bredden og dyben i kompetansen for å holde oss relevante som rådgivere.

Når jeg reflekterer litt, er IT Excellence et beskrivende og godt navn på en rådgivningsenhet i Sopra Steria. Blant annet fordi visjonen til Sopra Steria er «The world is how we shape it». For å oppfylle visjonen er det nødvendig å være ekstremt god på hvordan IT skaper verdi – for kunder, virksomheten, eiere og samfunnet.

Hva legger du i begrepet IT Excellence? Del gjerne her, eller i en direkte melding.

Hva er en digital plattform?

Postet den av
4

Det spørsmålet hører jeg stadig oftere, for både «digital» og «plattform» kan jo bety så mangt. Så det trenger en forklaring – som er hensikten med denne posten.

Illustrasjonsfoto av JJ Ying på Unsplash

Hva?

En digital plattform er teknologien og programvaren som benyttes i produksjon av forretningsverdi og kundeengasjement. Plattformen har en samordnet og integrert arkitektur, og brukes som et standardisert og transparent grunnlag for utvikling av applikasjoner, prosesser og tjenester for å skape verdi.

Hvorfor?

Brukt riktig, vil en digital plattform bidra til økt innovasjon og redusert teknisk gjeld.

  • Innovasjon – fra leverandøren som kan overføres og bygges videre på i egen virksomhet
  • Teknisk gjeld – reduseres gjennom bedre oversikt, struktur og lavere kompleksitet

Her trengs det litt mer forklaring.

Innovasjon

Innovasjon betyr nyskapning, og innebærer blant annet fornyelse av produksjonsprosesser. En god plattformleverandør tilfører ekstern innovasjon gjennom standardiserte prosesser, tjenester og applikasjoner. Produktet er utviklet på grunnlag av systematisk læring fra andre kunder – som kan overføres. Men det ser ut som at mange liker å tro at de er så spesielle at de ikke kan bruke standardiserte tjenester, prosesser og applikasjoner. Nesten på instinkt eller autopilot, uten refleksjon. Til dem vil jeg si: Neida, dere er faktisk ikke så spesielle som dere kanskje vil hevde.

Min erfaring tilsier at det er smart å bygge videre på innovasjon og læring fra eksterne. Vi bør rett og slett reflektere litt oftere over hvordan ekstern innovasjon kan overføres til egen organisasjon. Men det krever som regel endring i egne prosesser og strukturer som vil generere motstand i egen organisasjon. Dermed oppstår behov for endringsledelse for å oppnå ønsket effekt og høste gevinstene.

I stedet for å gripe denne muligheten, prøver mange heller å tilpasse løsningen til eksisterende strukturer og produksjonsprosesser, med den konsekvensen at de går glipp av innovasjonspotensialet. Denne tabben gjøres overraskende ofte, faktisk så ofte at den har fått et eget, ironisk navn: Conways lov for anskaffelse av nytt IT-system.

Teknisk gjeld

Teknisk gjeld kan defineres som alt det uferdige, unødvendig kompliserte og utdaterte i IT-løsningen som hindrer oss i å drifte, forvalte og videreutvikle så effektivt som vi ellers kunne gjort.

Når en skal integrere data mellom to forskjellige applikasjoner – med ulike datamodeller som ikke er standardisert – blir det fort blir unødvendig komplisert og komplekst. Med konsekvens at den tekniske gjelden øker, i stedet for å reduseres. Det skjer når en anskaffer ny applikasjon uten å vurdere hvordan den skal utveksle data med andre applikasjoner.

Derfor er det aldri lurt å bytte en applikasjon med en annen applikasjon – uten å samtidig redusere kompleksitet i den helhetlige arkitekturen. Les gjerne en tidligere post hva er teknisk gjeld? – om du vil vite mer.

Problemet den løser

Plattformen består av hardware og software som gjør det mulig å kjøre flere applikasjoner som oppretter, henter og sletter data på en enhetlig måte. Data lagres samordnet i plattformen, og ikke i den enkelte applikasjon. Det er en stor fordel, fordi det reduserer kompleksitet, plunder og heft med å dele data mellom applikasjonene.

Tradisjonelle applikasjoner blir ofte betegnet som teknologisk arv, fordi de ble utviklet til ett avgrenset, funksjonelt formål. Slike applikasjoner har sitt eget datalager og regler for å opprette, lese, oppdatere og slette data. Ulempen er at de i realiteten er data-siloer. Det betyr at deling av data er komplisert, kostbart og tidskrevende. Ofte lar det seg heller ikke gjøre, uten å bygge nye databaser og gjøre endringer i applikasjonen, som igjen øker kompleksiteten. Konsekvensen er at den tekniske gjelden øker, selv når vi ønsker å redusere den.

En digital plattform er designet for å løse nettopp dette problemet; deling av data på tvers av ulike applikasjoner. Det skjer gjennom felles protokoll og rammeverk for hvordan lagring og utveksling skal foregå. Tilgjengeliggjøring av eksisterende data – til nye formål – gjøres derfor mye enklere, sikrere, billigere og raskere.

Hvordan?

Applikasjonene som kjører på en plattform er standardisert, og kan som regel tilpasses uten at koden må enders gjennom programmering. Kundene kan i stedet konfigurere løsningen selv, når den er anskaffet og klargjort til bruk. Klargjøringen består i hovedsak av konfigurasjon, opprydding av data i den gamle løsningen, migrere data til ny løsning, ta i bruk ny løsning, og etter hvert terminere den gamle løsningen.

Det er også mulig å lage helt nye applikasjoner, men innen det samme rammeverket for datautveksling som gjelder for plattformen. Slik sikres en enhetlig og samordnet arkitektur som fremmer innovasjon. Men det innebærer strategiske valg av teknologi som skal understøtte verdiskapningen helhetlig. Til det trengs en portefølje av applikasjoner som deler data og har den samme definisjonen av hva dataene representerer.

Vi snakker egentlig om interoperabilitet, som innebærer at et produkts grensesnitt er fullstendig forstått, slik at det kan arbeide sammen med andre produkter eller systemer, nåværende eller fremtidige, i en hvilken som helst implementasjon eller tilgang, uten noen restriksjoner.

100% interoperabilitet krever åpne standarder, som desverre er noe vi har for lite av i dag. Men slike standarder er under utvikling, og støtte for disse standardene implementeres som regel i de plattformløsningene som er gode og fremtidsrettet.

Bistand

Businesscaset for å knytte til seg en rådgiver og implementeringspartner, som for eksempel Sopra Steria er godt. Fordi det reduserer risiko og øker innovasjonsevnen. Redusert risko for dårlige beslutninger, som mefører teknisk gjeld, manglende interoperabilitet og dårligere måloppnåelse. Økt innovasjonesevne gjennom adopsjon av eksterne standarder og læring.

Det er slike vurderinger jeg og mine rådgiverkollegaer har praktisk erfaring med, og kan bistå beslutningstakere med, slik at de kan ta gode strategiske valg knyttet til teknologi. For det er kostbart å velge feil produkt, siden en må leve med konsekvensene av manglende interoperabilitet og teknisk gjeld – i hele produktets levetid. Selv om en enkeltstående løsning, på kort sikt fremstår som det billigste alternativet.

Hva betyr kundesentrisk?

Postet den av
3

Kundeorientering er en måte å tenke på som setter kunden i sentrum for egen strategi og kultur. Målet er å skape verdi for kunden, og gjennom det lojalitet til egen merkevare. Men det er forskjell på uttalte og faktiske verdier hos dem som hevder de setter kunden i sentrum, men som ikke evner å gjøre det i praksis.

Illustrasjonsfoto av Grooveland Designs på Unsplash

Hvorfor?

Det er utfordrende å endre fokus – fra egen virksomhet, produkter og tjenester – til kundene og deres behov. En god start er å stille det grunnleggende spørsmålet: Hvem er vi til for? For svaret er – som de fleste vet – kundene (eller brukerne i offentlig sektor). Fordi sluttkunden er den ultimate mottakeren av produktene eller tjenestene som produseres i virksomheten.

Dette vet de som har kontakt med kunder eller brukere, og har derfor et bevisst kundefokus. Medarbeidere i andre og tredje linje bør også ha et like klart kundefokus, for de produserer interne tjenester som gjør dem som står i første linje – kundefronten – i stand til å levere gode tjenester til sluttkundene. Slik skapes verdier – for kundene – i en verdikjede.

Dessverre glemmer mange «hvem vi er til for», og fyller dagene med andre gjøremål som skyver kundefokuset lengre ned. Det medfører at interne gjøremål blir sidestilt, eller sågar prioritert høyere enn eksternt orienterte oppgaver. Dette skjer i overraskende mange virksomheter i dag.

Konsekvensen av manglende kundefokus over tid, er at kvaliteten på det som produseres gradvis forringes og mister relevans. Resultatet blir hyppigere feil som bidrar til redusert omdømme, og i ytterste konsekvens kroken på døren for dem som lever i et konkurranseutsatt marked.

Jeg tror kundesentriske virksomheter skaper større lønnsomhet for eierne, mer engasjerte ansatte og mer fornøyde kunder. Av samme grunn tror jeg brukersentrerte offentlige virksomheter løser samfunnsoppdraget sitt bedre, med mer engasjerte medarbeidere og fornøyde innbyggere som effekt.

Ett trekk som kjennetegner virksomheter som er virkelig kundesentrisk, er at de leverer produkter og tjenester som er designet med en dyp forståelse av kundens behov. De klarer også å fange opp hvordan behovene endres over tid – i takt med endringer i omgivelsene og konteksten kundene befinner seg i.

Hva?

Å sette kunden i sentrum – kundesentrisitet – er et tankesett, som betyr at uansett når en beslutning tas, så vurderes hvilken effekt den vil ha for sluttkundene. Det motiverer oss til å:

  • Fokusere på kunden – ved å segmentere og innrette tilbudet mot spesifikke, målrettede brukersegmenter.
  • Forstå kundenes behov – ved å investere tid i å identifisere ikke-uttalte behov og underliggende problemer.
  • Tenke og føle som kunden – ved å se verden fra kundens perspektiv.
  • Utvikle helhetlige produkter – ved å designe sammensatte løsninger for kundenes sammensatte behov.
  • Kjenne kundens verdi – ved å bevege oss forbi transaksjonsbasert mentalitet og heller fokusere på en tydelig forståelse av hvordan kunden får verdi fra løsningen.

Grunnlaget for å få til dette er data, som må identifiseres, samles inn og analyseres. Ikke som en innledende øvelse, utført kun én gang. Men gjennom en kontinuerlig prosess, som gjennom eksperimentering og læring, systematisk forbedres over tid. Det gjelder både prosessen, analysene og beslutningene. Da snakker vi om organisatorisk læring, hvor opparbeidet innsikt om kundene benyttes til kontinuerlig forbedring av egne produkter.

Vi kan skille mellom to typer analyser:

  • Markedsanalyse – for å forstå markedet og hvordan det utvikles (i sanntid og fremtid). Fokuserer på «hvem» og «hva». Vurderer hva store segmenter sier, og hva de ønsker å kjøpe. Brukes som beslutningsgrunnlag for produktstrategi.
  • Brukeranalyse – for å forstå brukerne og deres behov. Fokuserer på «hvordan» og «hvorfor». Vurderer hva mindre grupper gjør, hvordan de vil bruke produktet og hvilke krav som stilles. Brukes som beslutningsgrunnlag for produkt-design.

Analyse av oppdaterte data fra markedet og brukerne er viktig for alle som ønsker å bli mer kundesentriske. For her, som ellers gjelder de samme reglene: Jo mere data, og bedre datakvalitet (korrekt, fullstendig, aktuell, konsisent, anvendelig, presis, strukturert, relevant) – jo bedre og mer treffsikker blir analysen. Det er ofte her jeg, eller andre konsulenter kommer inn med spisskompetanse – for å bistå våre kunder med å få tak i relevante data, av god kvalitet, og sammenstille dem for analyse.

Digitale plattformer for deling av data mellom ulike kildesystemer, er en forutsetning for å få dette til. Videre må prosesser for innsamling og sammenstilling av data etableres. Det er også behov for strukturerte informasjonsmodeller som skal brukes til å tolke hva de ulike dataene betyr. Når dette er på plass, kan vi analysere kundebehov med en helt annen kvalitet og presisjon enn tidligere.

Målet er å utarbeide et godt beslutningsgrunnlag for å utvikle produktene slik at de skaper (mer) verdi for kundene. Når IT-infrastruktur, prosesser, modeller og metoder er på plass, starter den organisatoriske læringsprosessen med mål om kontinuerlig utforskning og forbedring av beslutningsgrunnlag og implementering av egen strategi.

Hvordan?

Design Thinking er en kundesentrisk utviklingsprosess med mål om å skape attraktive og bærekraftige produkter som kan videreutvikles og forbedres over tid, i takt med endringer i omgivelsene.

Metodikken vektlegger empati med kunden, for å forstå problemet og konteksten som søkes løst først. Deretter designes den beste løsningen på problemet. Den innarbeides så i et nytt eller eksisterende produkt, som videreutvikles kontinuerlig basert på ny innsikt og data.

Design Thinking (Scaled Agile, Inc)

Målsettingen med Design Thinking er å utvikle produkter og løsninger som er:

  • Attraktive (Desirable) – Vil kundene ha produktet?
  • Gjennomførbare (Feasible) – Kan vi levere?
  • Levedyktige (Viable) – Skaper produktet mer verdi enn kostnaden ved å lage det?
  • Bærekraftige (Sustainable) – Forvalter vi produktet godt gjennom hele livssyklusen?

Produkter utvikles og forbedres kontinuerlig basert på ny innsikt (data) fra markedet og brukerne. Les gjerne smidig produktutvikling i praksis, om du vil vite mer om Design Thinking og et praktisk eksempel på hvordan metodikken kan benyttes.

Refleksjon

Jeg har opplevd mange virksomheter som er kundeorienterte. Medarbeidere som er oppmerksomme, service-innstilt, vennlige, og oppriktig interessert i å imøtekomme kundenes preferanser og behov. Kanskje ikke så rart, siden alle med erfaring fra kundebehandling har lært at kunden kommer alltid først og må behandles godt.

Men det er forskjell på å være kundeorientert og det å bli kundesentrisk som organisasjon. Tankesettet – å sette kunden i sentrum for egen strategi og kultur- er det samme. Forskjellen ligger i evnen til å implementere strategien. Til det kreves kompetanse og ressurser for å kontinuerlig utforske hva kundene vil ha, og hvordan de får verdi av å bruke egne produkter og tjenester. Det må gjøres metodisk og være basert på fakta.

Datadrevet analyse for å ta gode beslutninger, og evne til å skape kundeverdi raskt gjennom kontinuerlig produktutvikling, er helt avgjørende for å lykkes. Jeg opplever at mange virksomheter ønsker å bli mer datadrevet i sin kundetilnærming, for å bedre forstå kundene sine og hvordan de får verdi av egne produkter eller tjenester. Men de trenger hjelp til å komme i gang, og bygge evne til å gjøre det i praksis. Det er en typisk oppgave for konsulenter, og slik kommer jeg eller andre inn i bildet.

Les gjerne mer om:

Hva er endringsledelse?

Fremhevet

Postet den av
6

Ordet endringsledelse er satt sammen av «endring» og «ledelse», og er faktisk et fag som har blitt forsket på og kan studeres ved universiteter og høyskoler. To spørsmål trer dermed frem, som denne posten vil besvare:

  1. Hva er endringsledelse?
  2. Er det forskjell på endringsledelse og ledelse generelt?

Aktuelt

Spørsmålene ble aktualisert i DNs portrettintervju sommeren 2021 av Nicolay Tangen, som er leder for oljefondet. I overskriften ble han sitert slik:

Endringsledelse? Et idiotisk begrep. Det er så kørka at det er helt ufattelig.

Nicolay Tangen

Et lurt journalistisk grep for å fange lesernes interesse, uten tvil! Så resulterte det også i en hel rekke reaksjoner og leserinnlegg fra fagfolk som var mer eller mindre fornærmet på vegne av faget sitt og ønsket å belære Tangen om endringsledelse og dens nødvendighet.

Men Tangens poeng var dette: For ham er det å lede endringer en selvfølge. Fordi en leder skal ta beslutninger og sørge for iverksetting og implementering av beslutningene. Noe han har helt rett i.

Problemet er bare at mange endringer IKKE blir ledet, slik en burde forvente. Derfor er det behov for endringsledelse. I tillegg er det alt for mange eksempler på dårlig ledelse som har medført at ønskede effekter av planlagte endringer har uteblitt. For noen blir løsningen å søke ekstern bistand, og slik kommer jeg eller andre inn for å bistå med kompetanse.

En viktig årsak til at endringsinitiativer feiler er motstand mot endringer, som kan forklares av høyst rasjonelle årsaker.

Illustrasjonsfoto av JESHOOTS.COM på Unsplash

Fundamentet

Kurt Lewin lanserte i 1951 en tre trinns modell for å lykkes med endringer:

  • Unfreeze (Tin opp)
  • Change (Endre)
  • Freeze (Frys)

Hans arbeid er regnet som fundamentet i endringsledelse. Lewins poeng var at det er viktig å skape oppfatningen om at en endring er nødvendig, for deretter å bevege seg mot det nye, ønskede atferdsnivået og til slutt befeste den nye atferden som normen. Psykologen og forskeren Lewins arbeid var en del av pensum da jeg studerte ledelse på Krigsskolen for snart 30 år siden, og står fremdeles i lærebøkene som grunnleggende teori.

Videreutviklingen

John P. Kotter, en professor ved Harvard Business School, skrev i Harvard Business Review 1995 artikkelen: «Leading Change: Why Transformation Efforts Fail». (Ledelse av endring: Hvorfor transformasjoner feiler). I 1996 ble arbeidet hans også publisert i boken «Leading Change», hvor han lanserte en «oppskrift» i 8 steg for å lykkes med endringer:

  • Create a sense of urgency (Skap en følelse at noe må gjøres nå)
  • Build a guiding coalition (Etabler nødvendig støtte)
  • Form a strategic vision and initiatives (Lag en strategisk visjon og initiativer)
  • Enlist a volunteer army (Mobiliser en frivillig hær)
  • Enable action by removing barriers (Muliggjør handling ved å fjerne hindringer)
  • Generate short term wins (Skap kortsiktige gevinster)
  • Sustain acceleration (Oppretthold akselerasjon)
  • Institute change (Gjør endringene til den nye normalen)

De fire første stegene er i realiteten en videreutvikling av det Lewin betegnet som «tin opp». I følge Kotter er feilen mange ledere gjør, å hoppe over disse trinnene og starte rett på trinn fem. Dermed oppstår motstand som en naturlig reaksjon, og medfører at endringen ikke får ønsket effekt og mislykkes.

Kultur

En årsak til motstand mot endringer er organisasjonskulturen, som i sin enkleste form handler om «hvordan vi gjør ting hos oss». Kultur kan både fremme og hemme endringer. Organisasjonskulturen består blant annet av felles verdier og grunnleggende antagelser, og hjelper medlemmene med å løse to typer problemer:

  • Ekstern tilpasning
  • Intern tilpasning

Med ekstern tilpasning menes håndtering av eksterne utfordringer. En organisasjon må tilpasse seg omgivelsene, og organisasjonskulturens rolle er å utvikle en felles forståelse for hvilken misjon, mål og midler organisasjonen har, og en enighet om hvilke kriterier som skal gjelde for prioriteringer og vurderinger av eksterne forhold.

Med intern tilpasning menes den interne samhandlingen mellom medarbeidere. For eksempel gjennom felles språk og begrepsapparat, vennskap, ideologi, belønning og straff. Organisasjonskulturen skaper et felleskap hvor man jobber sammen, for hverandre.

Denne innsikten ble først beskrevet av Edgar Schein i 1987, en forsker og forfatter som har vært en sentral bidragsyter i faget organisasjonspsykologi. Han beskrev også organisasjonskulturen som flere lag utenpå hverandre, omtrent som i en løk.

  • Observerbare ting
  • Grunnleggende verdier
  • Underliggende antagelser

Det ytterste laget består av ting vi kan observere, og inkluderer symboler, arkitektur, språk, teknologi, produkter, kleskode, prosesser, organisasjonskart, myter og historier,

Det mellomste laget består av grunnleggende verdier og overbevisninger. Her kan vi skille mellom uttalte og faktiske verdier, som betyr at de offisielle verdiene ikke nødvendigvis etterleves i det daglige.

Det innerste laget består av grunnleggende, underliggende antagelser. Disse har blitt formet gjennom organisatorisk læring, og representerer det sterkest kulturelementet. Med organisatorisk læring menes «Slik gjør vi det hos oss, fordi vi har lært gjennom erfaring at denne tilnærmingen gir det beste resultatet.»

Organisasjonskulturen vil påvirke atferden til organisasjonens medlemmer. Som leder er det derfor nyttig å forstå hvordan kultur skapes, opprettholdes og påvirker atferd. Forhåpentligvis kan en dermed påvirke kulturen, slik at strategier blir implementert og gjennomført, fremfor å bli møtt med motstand.

Dette var også poenget bak det berømte sitatet «Kultur spiser strategi til frokost», som ble tilskrevet «ledelse-guru» Peter Drucker av Mark Fields i 2006. Strategien er bare så god som kulturen tillater den å være. Det hjelper ikke med en god strategi, når den ikke lar seg implementere på grunn av kulturen.

Culture eats strategy for breakfast.

Peter Drucker

Les gjerne mer om strategi i en tidligere post: Strategiprosess til besvær

Hva er forskjellen?

Endringsledelse og ledelse er slik jeg ser det, to sider av samme sak, hvor ledelse er overordnet og endringsledelse underordnet. Endringsledelse handler om en metodisk tilnærming til å implementere beslutninger om endringer. For meg koker derfor endringsledelse ned til nettopp dette; en metodikk og tilnærming for å implementere strategi. Som Levins tre steg og Kotters åtte steg er eksempler på. I senere tid er det også vokst fram rammeverk og sertifiseringer innen endringsledelse som handler om det samme.

Ledelse favner bredere, og betyr for meg å vise vei, gå først og påvirke andre til å oppnå felles mål. Å lede gjennom eksempel, være en rollemodell og bry seg om mennesker er viktige personlige egenskaper hos en god leder.

I likhet med alle andre, er også jeg formet av det jeg har lært gjennom min lederutdanning og praktiske erfaring fra å lede andre mennesker mot felles mål. For meg handler ledelse om to grunnleggende ting; å løse oppdraget og ta vare på folkene sine. Så mener jeg at endringsledelse handler om en metodisk tilnærming for å implementere en strategi som skal sikre at intensjonen bak strategien oppnås, slik at en når målene og får ønsket effekt.

Hva er en digital transformasjon?

Postet den av
3

Et stort spørsmål med flere svar, som er avhengig av perspektivet til den du spør. Mitt utgangspunkt er dette: Digitalisering er transformasjonen fra at IT er et støtteverktøy i virksomheten til at det blir en del av dens DNA. Det betyr at forretningsmodell og -praksis samt organisasjon og prosesser er designet for å utnytte dagens og morgendagens teknologi. Denne definisjonen er utdypet i posten IT-lederens nye rolle.

Illustrasjonsfoto av Javier Allegue Barros på Unsplash

Tverrfaglige team

Det er lurt å bruke flere perspektiver, for da kan vi belyse problemstillingen fra ulike sider. Spesielt når omgivelsene er omskiftelige og behovet for smidighet og korte beslutningsveier er stort. En faktabasert diskusjon mellom kompetente personer med ulike perspektiver er verdifullt, og hovedbegrunnelsen for å sette sammen tverrfaglige team. De benevnes også som kryssfunksjonelle team – fordi teamene løser komplekse oppgaver med sammensatt kompetanse. Det er som regel slik vi finner de beste løsningene – sammen.

Kanskje er bruk av kryssfunksjonelle team det viktigste enkeltgrepet som kan gjøres for å fremme innovasjon og håndtere kompleksitet i egen virksomhet.

Bruk av kryssfunksjonelle team åpner også for å ta inn konsulenter som kan tilføre ekstern kompetanse. Slik kommer jeg inn som rådgiver og sparringspartner for ledere hos kundene våre.

Jeg tror ikke det fins noen «silver bullet» for hvordan en transformasjon bør utføres, for det kommer helt an på virksomheten og konteksten den befinner seg i. Derfor er mitt råd å styre unna alle dem som tilbyr lettvinte løsninger og «quick fix» på komplekse problemstillinger. Jeg tror mer på analytisk problemløsning, sunn fornuft og prinsippene for smidig utvikling – som du kan lese mer om i posten smidig tilnærming til utfordrende prosjekter.

Lederskap

Transformasjon er en omfattende endring som medfører stor usikkerhet, for både eiere, ledere og medarbeidere. Derfor trengs det godt lederskap og styring. Lederskap er personorientert og styring er systemorientert.

Lederskap bidrar til å angi retning, skape endring og sette mål. For meg betyr ledelse å gå først, og handler om å ivareta medarbeidere, det sosiale og mellommenneskelige forhold.

Styring er påvirkning som utøves indirekte blant annet gjennom formelle strukturer, formaliserte prosedyrer, rutiner og kontrollfunksjoner.

Begge deler er nødvendig for å få ønsket effekt. Det er ofte her jeg kommer inn som rådgiver, når en leder trenger en sparringspartner.

I Forsvaret lærte jeg at ledelse handler om to grunnleggende ting; å løse oppdraget og ta vare på folkene sine. I en digital transformasjon er oppdraget som regel gitt av eierne, representert ved styret, til daglig leder: Gjennomfør forretningsstrategien og digitaliser det som er mulig for en bedre måloppnåelse. Ofte er det mål for produksjon, vekst, lønnsomhet, bærekraft, kundetilfredshet, medarbeidertilfredshet, omdømme, og/eller samfunnsoppdrag. Les gjerne mer om daglig leders rolle i en transformasjon fra en tidligere post.

Strategi

Digitalisering er ikke et mål, men et middel for å styrke kjernevirksomheten og bygge evne til å skape verdi i framtiden. Det krever en forståelse av hvordan verdier skapes i dag og hvordan teknologi kan utnyttes for å skape verdi på en bedre, raskere, billigere eller sikrere måte. For å få det til, må vi utfordre måten vi tenker på. Det kan du lese mer om i posten strategiprosess til besvær.

Det jeg ser, er at de fleste virksomhetene har startet digitalisering, men mangler en god tilnærming og plan for hvordan digitaliseringen skal forbedre måloppnåelsen av kjernevirksomheten. Det kan du lese mer om i posten hva er en digital strategi?

Jeg har lært at strategiutvikling og -gjennomføring er like viktig som selve strategien. Fordi omgivelsene og forutsetningene endres stadig raskere, må de som gjennomfører strategien forstå intensjonen, og ha nødvendig handlefrihet til å løse oppdraget. Gjennom frihet til å nå målene, vil medarbeiderne søke etter nye og bedre måter å løse oppdrag på. Derfor er delegering av myndighet viktig.

Men frihet betyr ikke uten styring og at alle kan gjøre hva de vil. Det må være en struktur som sikrer felles forståelse av målet, hva som skal oppnås og hvorfor.

I en transformasjon kalles denne strukturen virksomhetsarkitektur, og gir daglig leder mulighet til å manøvrere endringer i organisasjon, prosesser og IT-løsninger på en helhetlig måte som understøtter strategien. Målet er å skape en integrert og samordnet virksomhetsarkitektur som muliggjør innovasjon. Det betyr at forretningsmodell og -praksis samt organisasjon og prosesser er designet for å utnytte dagens og morgendagens teknologi.

Arkitektur

Problemet oppstår når strategien skal omsettes til praktisk handling, og kompleksiteten i prosesser, teknologi og organisasjon trer fram. Virksomhetsarkitektur er en strukturert metodikk for å identifisere hvilke endringer som må gjennomføres for å nå forretningsmålene. Det handler om å forstå hvordan virksomheten er satt sammen, og deretter dele oppgaven med å endre den i håndterbare deler. Nesten som legoklosser.

Enkelhet er et viktig prinsipp: Å ikke dokumentere mer arkitektur enn nødvendig – men nok til å ta informerte beslutninger – er essensielt. Til det kreves evne til å prioritere hva som skal dokumenteres og holde dokumentasjonen oppdatert. Det er utfordrende for mange.

Arkitekturen kan deles inn i flere lag (forretning, informasjon, applikasjon, og teknologi). Sikkerhetsarkitektur og arkitekturstyring er gjennomgående for alle lagene, og sørger for at de henger sammen.

Sammenheng mellom strategi, virksomhetsarkitektur og løsningsarkitektur

Virksomhetsarkitektur beskriver hvordan en virksomhet er organisert, hvordan arbeidsprosesser er satt sammen og hvordan IT-løsninger utnyttes for å produsere verdi. Virksomhetsarkitektur er tett koblet til strategi gjennom mål og målbilder.

Løsningsarkitektur beskriver hvordan applikasjoner sikrer effektiv informasjonsdeling mellom mennesker og maskiner. IT-løsningene er som regel laget av forskjellige leverandører. Som konsekvens oppstår to utfordringer: Teknisk gjeld og deling av data mellom applikasjoner.

Teknisk gjeld

Teknisk gjeld er en metafor som fungerer godt til å forklare strategiske konsekvenser av ulike valg i anskaffelse og utvikling av IT-løsninger. Over tid vil manglende forståelse av slike konsekvenser resultere i operasjonelle utfordringer som hindrer effektiv måloppnåelse av strategiske mål.

Problemet med teknisk gjeld er at det påløper renter – som må betales før eller siden. Problemet vokser med tiden som effekt av renters rente. Teknisk gjeld kan defineres som alt det uferdige, unødvendig kompliserte og utdaterte i IT-løsningen som hindrer oss i å drifte, forvalte og videreutvikle så effektivt som vi ellers kunne gjort.

Derfor kan det lønne seg å se nærmere på hva teknisk gjeld er, og forstå hvordan den kan håndteres. Det er utdypet i posten hva er teknisk gjeld?

Deling av data

I dag har vi egne IT-løsninger for HR, lønn, regnskap, fakturering, kundeoppfølging (CRM) og produksjon (ERP). Som ikke snakker med hverandre. Derfor registreres samme data, flere ganger, i forskjellige systemer. Enten gjennom manuell inntasting, eller overføring av filer på diskett eller minnepinne. Så nytteverdien av å koble sammen applikasjoner som brukes internt i en virksomhet synes åpenbar.

Men det virkelig store potensialet ligger i å gå ett skritt videre; å koble data fra applikasjoner som befinner seg utenfor egen virksomhet. Dette gjøres gjennom standardiserte grensesnitt; Application Programming Interface (API).

Forutsetningen er god informasjonssikkerhet og tilgangskontroll. For når du åpner en inngangsport (API Gateway) til dine data, trenger du å ha stålkontroll på hvem som får tilgang til hva, og hvilke rettigheter de skal ha for å opprette, lese, oppdatere eller slette data. Dette er utdypet og forklart i posten hva er et API?

Oppsummering

Mitt perspektiv, og svar på spørsmålet i overskriften, kan oppsummeres slik:

Digital transformasjon – er en aktiv respons og endringsprosess – for å gripe muligheter og unngå trusler – som oppstår som konsekvens av endringer i rammebetingelser – som følge av at digitalisering forskyver/forstyrrer/ødelegger maktballansen i markedet og samfunnet.

For meg er en digital transformasjon:

  • Teknologidrevet – ved at IT går fra støttehjul til drivhjul for virksomheten
  • Datadrevet – gjennom kontinuerlig læring og forbedring basert på målbare data
  • Strukturering – ved å samordne og integrere prosesser, systemer og infrastruktur som muliggjør innovasjon
  • Nytenkning – ved å kontinuerlig søke etter nye måter å skape verdi på for kundene, seg selv og samfunnet
  • Endringsevne – ved å tilrettelegge for kompetente, kryssfunksjonelle team som kan snu seg raskt i en smidig organisasjon
  • Lederskap – gjennom å gå først, vise vei og bemyndige medarbeidere slik at de kan bidra til å opprettholde en stadig økende endringstakt

Neste post vil komme etter sommerferien, en gang i august.

Ha en riktig god sommer!

Innovasjon i praksis

Postet den av
2

Begrep som «Design Thinking», «Lean Start-up» og «Agile» benyttes ofte i forbindelse med innovasjonsprosesser. Det er lett å bli forvirret av begrepsbruken, og spørsmålet mange stiller er: Hva betyr det i praksis, og hvordan henger de sammen? For å svare på det, utførte jeg et eksperiment – for å gjøre det praktisk og enkelt å forklare.

Utfordringen som søkes løst, er å kunne hvile samtidig som man fører en seilbåt. Problemet er at benken bak rattet er for lav i forhold til overbygget lengre frem, som medfører at sikten forsvinner når man setter seg ned.

Innovasjonsprosessen

Hensikten med en innovasjonsprosess er å komme raskt i gang med datadrevet produktutvikling for å bygge løsninger som kan testes og gi verdi etter kort tid. Jeg benytter Sopra Sterias innovasjonsprosess, som er basert på tankegodset fra Design Thinking, Lean Start-up og Agile (Smidig på norsk), i den rekkefølgen. Det kommer jeg tilbake til.

Sopra Sterias innovasjonsprosess Lean Next – Del 1

Definer mål

Vi starter med å definere mål, som i henhold til Design Thinking skal være:

  • Attraktivt (Desirable) (D)
  • Gjennomførbart (Feasable) (F)
  • Levedyktig (Viable) (V)

Det er skjæringspunktet mellom disse egenskapene vi er på jakt etter. Å kjøpe ny båt er ikke levedyktig (for dyrt), så vi går for å utvikle et sete som ikke sklir når vi seiler. Målet blir derfor at setet skal se bra ut, være enkelt å feste til rekken, og lar seg bygge av materialer som tåler fuktighet. Kostnadene skal holdes lave.

Generell utfordring

Innsikt/empati fasen handler om at vi «bredder ut» vår forståelse av problemet som søkes løst. Det symboliseres med (<) i modellen. Vi søker alle gode innspill som kan belyse den generelle problemstillingen. Dette er «ja-fasen» hvor alle ideer ønskes velkommen. Vi lager en brutto-liste over mulige problemstillinger som kan være relevant innen rammene av de definerte målene. Er beskyttelse mot regnvær kanskje en mer aktuell problemstilling? Hva med sikkerhet, navigasjon, og god stemning om bord? Vi oppdaterer om nødvendig målene dersom vi kommer på noe nytt.

I defineringsfasen «snevrer vi inn» brutto-listen over problemstillinger, som er symbolisert med (>) i figuren. Til sammen blir symbolene <>, en diamant. Det vi egentlig søker svar på er dette sentrale spørsmålet: «Er problemet stort/viktig nok til at det er verdt å løse?» For eksempel kan bruk av autopilot medføre at båtføreren kan sette seg et annet sted med sikt forover. Men autopilot krever strøm og kan ikke brukes over lange strekk, for da blir batteriet tomt. I tillegg er det mange båter som ikke har autopilot.

Vi oppsummerer med å utvikle hypotese 1: Dette er et problem som er verdt å løse.

Så vi går videre i prosessen.

Spesifikk utfordring

«Hvordan kan båtfører holde i rattet og samtidig sitte avslappet med god sikt forover?»

Igjen «bredder vi ut» gjennom en idéstorming, symbolisert med (<). Vi er på jakt etter å løse dette spesifikke problemet. Dette er «ja-fasen» hvor alle ideer er velkomne. Er det en stol? Hva er den laget av? Hvor stor skal den være? Hvor skal den plasseres? Hvordan skal den festes? Kan den flyttes?

Vi oppsummerer med å utvikle hypotese 2: En båtførerstol er den beste løsningen på vår problemstilling.

Prototypen lages for å skaffe oss data som gir svar på de nevnte spørsmålene. For å komme hit, har vi brukt en «dobbel diamant», fordi prosessen med å åpne og lukke har form som en diamant. Dobbel siden vi har gjort det to ganger- <> <> – Den første diamanten handler om problemet er viktig nok, og den andre diamanten om hvilket løsningskonsept (av flere mulige) som anses å være best egnet.

På bildet ser dere prototypen jeg laget til vårt formål i forgrunnen. Legg merke til festeanordning for å kunne hekte stolen fast på rekka. (I bakgrunnen kan dere også se to andre prototyper til blomsterkasse på hjul, som jeg også sysler med. Det er ellers helt vanlig å jobbe med flere prototyper samtidig)

Prototype til båtførerstol

Løsningskonsept

Nå bruker vi «Bygge – Måle – Lære» metodikken fra Lean Start-up. Vi skal teste prototypen i det miljøet den skal være i, på en ekte båt, som i dette tilfellet er vår egen.

Vi regner med å gjøre tilpasninger, så vi trenger å ta med oss nødvendig verktøy til båten.

Prototypen tilpasses miljøet den skal brukes i

Det første jeg ser når stolen kommer ombord, er at den er rett og slett for stor. Selv om den får plass, hindrer stolen bevegelse til og fra førerplassen. Jeg hadde tatt mål av tilgjengelig plass, men tenkte ikke på at vi skal bevege oss rundt i båten uten hindring av stolen. Derfor må sagen frem, og lengden kuttes med et helt bord. Siden jeg har bygget prototypen selv, vet jeg at det enkleste er å løsne skruene i bakkant på setet og kapper bærebjelkene i ønsket lengde. Så skrus setet fast i ryggen igjen.

Lengden er redusert for bedre fremkommelighet

Det neste jeg observerer er at stolen er for høy i forhold til rekken på båten. Dermed må beina kuttes. Fram med meterstokk, ta mål, tegne rett line og sage etter den.

Høyden må justeres

Så observerer jeg at stolen kan skli sideveis langs rekken. For hindre at stolen sklir under seiling, velger jeg å flytte et tverrgående bord under setet, og sage en åpning som passer til den vertikale delen av rekka. Bordet jeg bruker må også kappes i bredden, siden stolryggen blir smalere, jo lengre opp en kommer.

Flytter et bord slik at det hindrer glidning under seiling

Nå er det på tide med en brukertest, som jeg utfører selv. Testresultatene er lovende. Stolen sitter fast og er ikke til hinder for bevegelse rundt om i båten. Sikten forover er god, og rattet nås fint med den ene hånden.

Akseptansetest av løsning. Resultat: Godkjent.

Vi har nå en fungerende prototype av en båtførerstol som kan videreutvikles og eventuelt produseres i et større antall. Dermed er vi klare for neste fase, som handler om å stabilisere løsningen og skalere opp ved behov. Til dette benytter vi «Agile» eller Smidig på norsk.

Sopra Sterias innovasjonsprosess Lean Next – Del 2

En viktig del av smidig produktutvikling er produktkøen, som er en totalliste over behov for ny funksjonalitet, skalering og stabilisering. (Symbolisert med en stabel av behov, til venstre i figuren). Produktet utvikles i sprinter med varighet 1-4 uker. En sprint planlegges av et produkt-team som prioriterer hvilke oppgaver som skal utvikles. Hver sprint avsluttes med en demonstrasjon av hva som er laget, og det gjennomføres en læringssløyfe kalt retrospektiv ved jevne mellomrom. Vi benytter «Bygge – Måle – Lære» i kombinasjon med «Idé – Produkt – Data» for videreutvikling i gjentagende øvelser.

Poenget er å ta vare på all læring for å kontinuerlig forbedre og videreutvikle produktet. Det er her DevOps kommer inn, et ord som er sammensatt av «Development» (utvikling) og «Operations» (drift). Konseptet går ut på å ta vare på opparbeidet innsikt i en kontinuerlig læringssløyfe mellom utvikling og drift. I motsetning til prosjekter som overleveres fra utvikling til drift hvor innsikten går tapt i overleveringen.

Vårt produkt er ikke en digital løsning, men det kan likevel videreutvikles på flere måter. For eksempel pusset jeg over med sandpapir for å jevne harde kanter. Så bør den males i en farge som passer båten den skal stå på. Videre bør det vurderes om materialbruken kan reduseres for å spare kostnader. For eksempel ved å bruke mindre dimensjon på reisverket. Dette er elementer som går inn i produktkøen. Produktstyringen utføres av produkteier eller produktansvarlig, som avgjør hva som skal produseres i neste sprint.

Innovasjonsprosessen er kundeorientert og datadrevet for å gjøre oss i stand til å skape verdi raskt. For det er markedet som avgjør etterspørselen, og gjennom den behovet for å skalere opp og stabilisere produksjonen. Ikke ledelsen. Deres ansvar er å legge til rette for smidig produktutvikling, med alt det innebærer av transformasjon i egen organisasjon.

Les gjerne min tidligere post Smidig tilnærming til utfordrende prosjekter om du vil vite mer om hvor tankegodset til smidig kommer fra.

Smidig tilnærming til utfordrende prosjekter

Postet den av
4

Feil antagelser, tapt innsikt i overleveringer og lang utviklingstid resulterer i mislykkede digitaliseringsprosjekter. Mens forventede gevinster uteblir, løper kostnadene fort – med tapte muligheter og bortkastet arbeid som resultat.

Men hva om vi lærer av feilene, og endrer tilnærming?

Det er nettopp det «Agile» eller smidig på norsk, har gjort. Smidig-bevegelsen, i mangel på et bedre navn, tilbyr en bedre og ja, mer smidig tilnærming; fra prosjekter med flere overleveringer til kontinuerlig produktutvikling og forvaltning, utført av samme team. Opparbeidet læring forsvinner ikke, og utviklingstiden reduseres radikalt fra år til uker.

Illustrasjonsfoto av jana müller på Unsplash

Antagelser

Vi trenger å korte ned tiden fra idé til funksjonelt produkt, for å bekrefte eller avkrefte de antagelsene som er lagt til grunn for behovet ute hos brukerne eller kundene. Antagelsen om problemet/behovet er viktig nok til at kundene vil bruke tid og ressurser på tjenesten/produktet er helt sentralt, siden hele business-caset for prosjektet bygges på denne hypotesen og antagelsen – alene.

Videre er det lurt å teste vår andre antagelse; om at løsningen vi har valgt er riktig. Hele gevinstkorthuset bygger på at denne helt sentrale antagelsen holder. Dessverre ser vi litt for ofte at det ikke er tilfelle.

Hvis vi tidlig i utviklingsprosessen tester de grunnleggende hypotesene våre i liten skala, kan vi lære hvordan en enkel prototype av en tjeneste eller produkt blir mottatt av kundene. Det er kanskje den beste muligheten vi har for å unngå å kaste bort penger på produkter og tjenester som aldri burde vært laget.

En slik tilnærming er helt i tråd med innovasjonsprosessen Bygge – Måle – Lære, som er kjernen i hvordan kundeorienterte og datadrevne virksomheter opererer. Dette har jeg blant annet skrevet om i et tidligere innlegg strategiprosess til besvær.

Overleveringer

Et prosjekt er per definisjon tidsavgrenset, som betyr at den læringen som har skjedd underveis i utviklingsprosessen, forsvinner i det resultatet/leveransen overleveres fra utvikling til drift. Utvikling er typisk organisert i prosjekter, mens drift og forvaltning som regel utføres av linje-organisasjonen.

For å komme i mål til rett tid, har det kanskje i utviklingsprosjektet blitt gjort noen grep som har resultert i teknisk gjeld. Som regel blir ikke teknisk gjeld oppdaget før etter en tid, av den enkle årsaken at linjeorganisasjonen ikke har nødvendig forutsetninger eller tilgang på erfaringen som er opparbeidet i utviklingsprosjektet. Erfaring som går tapt når prosjektet er ferdigstilt og utviklingsteamet oppløses.

En smidig tilnærming har ingen slik overlevering fra utvikling til drift. Blant annet begrunnet med at det er lurt å betale ned teknisk gjeld fortløpende, før effekten av renters rente gjør løsningen ustabil med de konsekvensene det kan medføre for tapt produksjon.

Om du vil vite mer om teknisk gjeld, kan du lese et tidligere innlegg: hva er teknisk gjeld?

Tid

Den siste store utfordringen med klassisk prosjektgjennomføring i digitalisering er tiden det tar fra behovet oppstår til en løsning er utviklet, testet og satt i produksjon. Hvis problemstillingen er kompleks, og prosjektet stort, kan det ta opptil flere år. I løpet av så lang tid kan behovene være endret, med konsekvens at løsningen ikke lenger er relevant. Nettopp dette var kjernen i kritikken som ble reist mot Akson, et gigantprosjekt til 11 milliarder for å utvikle elektroniske pasientjournaler til kommunene, som skulle løse for mange behov – samtidig.

Siden endringstakten i samfunnet øker, blir det nærliggende å møte denne utviklingen med å jobbe i kortere sykluser og sørge for at gevinstrealiserings­tidspunktet – når produktet vårt møter sluttbrukeren – kommer så tett opp til startpunktet som mulig. Helst ikke mer enn uker, og maks noen måneder.

For å få det til må sammensatte behov deles opp i mindre deler, og at vi må lære oss hvordan vi kan teste hypoteser for å redusere usikkerhet om hvordan produktet/tjenesten vil bli mottatt hos kundene. Dette er eksperimentering og læring satt i system, slik at vi kan ta gode beslutninger, understøttet av gode og oppdaterte data fra ekte kunder/brukere.

Det er her smidig kommer inn med en radikalt ny tilnærming til utvikling av programvare. Fra prosjektorganisering til produktorganisering med tverrfaglige, selvstyrte team som både utvikler og drifter tjenestene. Fordelen er åpenbar, siden smidig utviklingsmetodikk skaper verdi raskt i små steg ved å korte ned veien fra behov til fungerende kode i en digital løsning.

Smidig manifestet

Det sentrale tankegodset rundt «smidig» har rukket å bli 20 år i 2021, og kommer opprinnelig fra en gruppe utviklere som skrev Manifestet for smidig programvareutvikling. Manifestet går i korte trekk ut på å verdsette:

  • Personer og samspill fremfor prosesser og verktøy
  • Programvare som virker fremfor omfattende dokumentasjon
  • Samarbeid med kunden fremfor kontraktsforhandlinger
  • Å reagere på endringer fremfor å følge en plan.

Dette vil si: Selv om punktene som står til høyre har verdi, så verdsetter vi punktene til venstre enda høyere.

Smidig prinsippene

Manifestet følges av noen sentrale prinsipper:

  • Vår høyeste prioritet er å tilfredsstille kunden gjennom tidlige og kontinuerlige leveranser av programvare som har verdi.
  • Ønsk endringer i krav velkommen, selv sent i utviklingen. Smidige prosesser bruker endringer til å skape konkurransefortrinn for kunden.
  • Lever fungerende programvare hyppig, med et par ukers til et par måneders mellomrom. Jo oftere, desto bedre.
  • Forretningssiden og utviklerne må arbeide sammen daglig gjennom hele prosjektet.
  • Bygg prosjektet rundt motiverte personer. Gi dem miljøet og støtten de trenger, og stol på at de får jobben gjort.
  • Den mest effektive måten å formidle informasjon inn til og innad i et utviklingsteam, er å snakke ansikt til ansikt.
  • Fungerende programvare er det primære målet på fremdrift.
  • Smidige metoder fremmer bærekraftig programvareutvikling. Sponsorene, utviklerne og brukerne bør kunne opprettholde et jevnt tempo hele tiden.
  • Kontinuerlig fokus på fremragende teknisk kvalitet og godt design fremmer smidighet.
  • Enkelhet – kunsten å maksimere mengden arbeid som ikke blir gjort – er essensielt.
  • De beste arkitekturer, krav og design vokser frem fra selvstyrte team.
  • Med jevne mellomrom reflekterer teamet over hvordan det kan bli mer effektivt og så justerer det adferden sin deretter.

Hva dette betyr

Jeg opplever at tankegodset fra smidig manifestet sprer om seg i norske virksomheter i dag. Blant annet har jeg sett at det blir stadig vanligere å kjøre korte «stand-up» møter på 15 – 30 minutter for å koordinere oppgaver i teamet – ansikt til ansikt.

Så registrerer jeg med glede at enkelte kunder allerede har organisert seg i produkt-team etter modell fra smidig. Teamene er satt sammen tverrfaglig, slik at teamet har nødvendig forretningsmessig, juridisk og teknisk kompetanse til å utvikle ny funksjonalitet og gjøre løsningen mer robust.

Jeg er så heldig at jeg får lov til å være rådgiver for produktstyring og -strategi hos en stor norsk virksomhet som leverer samfunnskritiske tjenester. Figuren under viser hvordan produktstyring og smidig organisering skaper økt nytteverdi for kundene/brukerne.

Smidig utviklingsmetodikk

At teamene er selvstyrte, innebærer at de gjør egne prioriteringer innen rammene av en overordnet produkt-kø. Den inneholder en liste over krav og behov, som er sentral i den strategiske produktstyringen. Oppgavene organiseres i en sprint-kø, som produktteamet står fritt til å fordele og løse i løpet av sprint-perioden. Normal varighet på en sprint er 1-4 uker.

Fra produktkøen velges det ut oppgaver etter en helhetlig prioritering av hva som vil gi størst mulig nytteverdi i forhold til kostnader/innsats. Det er produktteamet som gjør dette. De planlegger sprinten slik at oppgavene er spesifisert og klare til at leveranseteamet kan utvikle kode for endringer som skaper nytteverdi. Endringene blir gjort tilgjengelig umiddelbart etter sprinten er ferdig demonstrert, testet og godkjent.

For å få til dette, kreves blant annet en god løsningsarkitektur som er modulisert, standardisert og automatisert for testing. Det er typisk her jeg kommer inn som rådgiver innen smidig utviklingsmetodikk og -prinsipper. Selv lærte jeg om smidig for 10 år siden, da jeg tok en sertifisering som produkt-eier (Certified Scrum Product Owner), en innsikt jeg har hatt stor glede og nytte av siden.