Hva jeg lærte som Chief Digital Officer (CDO)

Chief Digital Officer betyr, som navnet antyder at du er sjef for digitalisering. Jeg fylte en slik rolle i 9 måneder – som innleid konsulent – i et norsk selskap. Av hensyn til kunde-konfidensialitet omtaler jeg det bare som Selskapet i denne posten.

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 tenker det var et smart trekk, fordi effekten ble verdifull læring – for alle involverte. Denne posten vil besvare tre spørsmål:

  • Hvorfor trenger du en CDO?
  • Hva er rollen og oppgavene?
  • Hvordan ble oppdraget løst?

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

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.

Hvordan oppdraget ble løst

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 to metoder for min egen forståelse og måte å kommunisere med de forskjellige interessentene i Selskapet:

Analytisk problemløsning betyr å definere og løse problemer på en strukturert måte. Det gjøres ved å samle informasjon for å produsere ny innsikt i problemet i stedet for bare å gjenta informasjonen. Konkret betyr det for meg å definere hva som er situasjon, komplikasjon, spørsmål og svar. Det vil jeg demonstrere litt lengre ned i artikkelen.

Virksomhetsarkitektur betyr å gjøre en gruppering, prioritering og lagvis inndeling av informasjonen for å beskrive noe som er komplekst og sammensatt. Ofte fremstilles den lagvis i forretningsarkitektur, informasjonsarkitektur og teknologisk arkitektur.

Etter tre uker, presenterte jeg til ledergruppen hva jeg hadde observert så langt. Kall det gjerne min vurdering etter å ha løftet på panseret og sett hvordan motoren fungerer og om den er riktig justert. Denne metaforen fungerer faktisk overraskende godt til å forklare hva jeg gjør.

Situasjon

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

Min observasjon

Denne observasjonen underbygget jeg med et kart, som jeg brukte til å forklare hvordan arkitekturen hang sammen. 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?

Spørsmål 1

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?

Spørsmål 2

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?

Spørsmål 3

Å 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.

Publisert av Ola Holm

Jeg er konsulent i Sopra Steria innen digital transformasjon.

Legg igjen en kommentar

Fyll inn i feltene under, eller klikk på et ikon for å logge inn:

WordPress.com-logo

Du kommenterer med bruk av din WordPress.com konto. Logg ut /  Endre )

Google-bilde

Du kommenterer med bruk av din Google konto. Logg ut /  Endre )

Twitter-bilde

Du kommenterer med bruk av din Twitter konto. Logg ut /  Endre )

Facebookbilde

Du kommenterer med bruk av din Facebook konto. Logg ut /  Endre )

Kobler til %s

%d bloggere liker dette: