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

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

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.