Outsourcing på dårlig grunnlag

Denne ytringen er skrevet sammen med min kollega Karl Egil Stubsjøen i A-2 Norge AS og publisert i Computerworld 28.10.2016.

Det er dyrt og krevende å hente IT-tjenester tilbake igjen til egen virksomhet. Stadig flere virksomheter tar nå konsekvensen av at kvaliteten på IT-tjenester som er satt ut til eksterne leverandører, ikke samsvarer med forventningene som lå til grunn for beslutningen om outsourcing. En viktig årsak er ofte at det forutsetter langt større innsikt og forståelse i virksomheten enn det leverandøren har mulighet for å bygge opp.

En balansert tilnærming

Ved å finne den gode balansen mellom oppgaver som skal utføres internt eller eksternt, kan man sikre både lavere kost og økt kvalitet på tjenestene. Men hva gjør man når kostnadsbesparelsene uteblir, de kulturelle forskjellene skaper uoverkommelige barrierer, kommunikasjonen er elendig, kvalitetene på tjenestene er for dårlig, innovasjonen stanser opp og den interne kompetansen på kritiske IT-løsninger har forvitret? Jo, da begynner man å hente tjenester tilbake igjen. Og det koster.

Flere sterke drivere trekker i retning av outsourcing: Tilgang på spesialkompetanse, reduksjon av produksjonsrisiko, økt økonomisk fleksibilitet, og skalering av produksjonskapasitet. Når outsourcing skal reverseres, gjelder det å sikre at de nevnte driverne i så liten grad som mulig slår negativt ut.

Både norsk og internasjonal forskning viser at det er minst like kostbart og krevende å hente tjenester tilbake som å sette dem ut. I bunn og grunn dreier problemene seg i begge tilfeller om kompetanse. Enten mangler den hos leverandøren, eller så må den bygges opp igjen internt i virksomheten.

Å gjøre mer selv

Vår erfaring tilsier at det er viktig å beholde kompetanse internt på områder hvor det skjer hyppige endringer og hvor det er vesentlig å være tett på markedet. I slike tilfeller vil man fort havne i bakevja om man ikke evner å tilpasse seg endringene rask nok.

Vi er eksempelvis skeptiske til planer om å sette ut forvaltning av faglig smale IT-systemer som er kritiske for virksomhetens leveranse av produkter og tjenester. Vi tror heller ikke alltid det er riktig å sette ut systemutvikling til f.eks. India eller Kina. Flere virksomheter har oppnådd gode resultater ved å ha utviklere «i samme rom» som egne ansatte, i motsetning til å jobbe med team som sitter på den andre siden av jordkloden, i en annen tidssone, og som sliter med å forstå både funksjonelle krav og kultur.

Dersom tjenester skal hentes tilbake anbefaler vi å vurdere alternative sourcingmodeller. Det kan lønne seg å flytte noen tjenester til naboland eller til Norge, hvor forskjellene i språk og kultur er små. Enkelte velger å flytte leverandørens medarbeidere til sine egne lokaler (riktignok med varierende hell).

Det er ikke alltid enkelt i praksis å presist definere hvilke kjerneaktiviteter og kompetanse man selv må ha kontroll på. Eksempelvis kan toppledelsen mene at IT-prosjektledelse er en kjerneaktivitet som skal beholdes internt, mens programvareutvikling kan outsources. I slike tilfeller kan det vise seg vanskelig å få utviklet gode prosjektledere med tilstrekkelig utviklingskompetanse. Virkningene og konsekvensene av å skille fagområder må derfor vurderes grundig.

Uansett må virksomheten ha den tekniske og administrative interne kompetansen som må til for å styre det området som outsources. Dette undervurderes ofte.

Ny strategi. Nye motiver

Å ensidig fokusere på kostnadsbesparelser i forbindelse med outsourcing er ikke tilstrekkelig. Mange ser at det fremdeles er mulig å redusere kostnadene, men ikke i den skala som man tidligere ofte trodde var mulig. Kostnadsfokuset må suppleres med fordeler knyttet til økt fleksibilitet og tjenestekvalitet, og beslutningen basert på inngående risikovurderinger.

Vi har god erfaring med bruk av selektive og balanserte sourcingmodeller, der man har et realistisk syn på potensielle gevinster og en meget bevisst tilnærming til valget om hva som skal settes ut og hva som skal beholdes internt. Det er etter vårt syn slik virksomheten oppnår de beste resultatene.

Når reviderte du leverandørene dine sist?

Revisjon høres kanskje litt tørt og kjedelig ut, men det trenger det absolutt ikke være. I min verden handler det om å sjekke at leverandørene faktisk gjør det de har forpliktet seg til å gjøre. I Statens standardkontrakter (SSA) ligger det inne flere muligheter til å følge opp kontraktforpliktelsene. Men dette er noe som en kunde bør legge inn i kontrakten med leverandøren uansett. I den nylig oppdaterte SSA-D (driftsavtalen) formuleres det på følgende måte:

«Kunden har rett til å foreta revisjon og verifikasjon av at Leverandøren overholder avtalte forpliktelser for driftstjenesten … Leverandøren skal yte bistand hvis Kunden har behov for å involvere Leverandøren i gjennomføring av kvalitetsrevisjoner … Med mindre annet er avtalt … kan revisjon maksimalt gjennomføres én gang per år … Kunden kan oppnevne tredjepart til å utføre revisjon og verifikasjon etter denne bestemmelse … Hvis de påviste avvikene er av vesentlig karakter, eller kan bebreides Leverandøren som uaktsomt, plikter Leverandøren å refundere Kundens nødvendige kostnader til gjennomføring av revisjonen … Dersom Kunden ønsker å gjennomføre en revisjon hos Leverandørens underleverandør, plikter Leverandøren å samarbeide med Kunden for å få gjennomført en slik revisjon.»

auditingDette innebærer at kunden har en sterk rett til å gå dypere inn i leverandørens arbeidsmetodikk enn det den tradisjonelle SLA-rapporteringen innebærer. Mange kunder burde være mye mer aktive og benytte den muligheten som en kontrakt kan gi. Slike gjennomganger kan normalt gjennomføres i løpet av et par dager, riktignok avhengig av kontraktens omfang og problemstillingene som skal adresseres.

Jeg pleier å bruke samme tilnærming som ved en ISO 9001-revisjon og kategorisere funnene i tre grupper: A: Avvik, M: Merknad og F: Forbedringspunkt. Alle funn skal begrunnes og knyttes til et punkt i kontrakten. Basert på funnene skal aktiviteter beskrives, med en tidsfrist for når det skal være korrigert.

For en kunde som skal gjennomføre en anskaffelse gir det en ekstra trygghet å vite at leverandøren skal revideres. Mange har en gjennomgang hos leverandørene før en kontrakt inngås, men færre gjør det i ettertid. Erfaringsmessig er det mye vanskeligere å finne «feil» hos en leverandør før kontrakten inngås enn etterpå. Når man har erfaring med både løsning og samarbeid er det lettere å utføre en målrettet gjennomgang.

Som ISO 9001-sertifisert kvalitetsrevisor har jeg gjort dette mange ganger, og uten unntak kommer det opp forhold som må utbedres. Og som regel setter faktisk også leverandøren pris på denne muligheten til å forbedre sine tjenester.

Det er ofte kravene som er feil, ikke løsningen

To av mine gode kolleger i A-2 Norge har skrevet en artikkel i Ukeavisen ledelse om tre grep for å få mer vellykkede IT-prosjekter i offentlig sektor. Dette gjenspeiler dyp erfaring fra en rekke IT-prosjekter vi har fulgt over mange år. Jeg vil her ta tak i ett av momentene de tar opp og spinne videre på det, nemlig selve utgangspunktet:

  • Hvilke behov det er som skal dekkes?
  • Hvilke krav er beskrevet?
  • Er det en fare for at en ny løsning bygges ut i fra noe som er svakt fundert?

Som kvalitetsikrer av store IT-prosjekter undersøker vi alltid selve fundamentet for prosjektet. Det har å gjøre med behovsanalyse, kravformulering, organisatorisk forankring, ledelsens engasjement, teknologivalg, samt ikke minst om det er utarbeidet en dekkende business case. Gjentatte ganger har vi sett at dette fundamentet er ustabilt. Behov og krav kan være beskrevet med varierende presisjon og ikke minst på veldig ulikt detaljeringsnivå. Jeg opplever ikke at det er teorien det er noe galt med. Å utarbeide en behovsanalyse eller beskrive overordnede behov før kravene blir detaljert ut er fornuftig. Men praksisen derimot, den kan man innvende mye mot.

Must have 2Jeg har konkludert med at fem sentrale forhold må være på plass for å gi IT-prosjektet et solid fundament når det gjelder behov og krav, både før prosjektet starter og underveis i gjennomføringen. Det er lett å nikke til disse punktene, men det er ikke dermed sagt at de er enkle å realisere. Og overraskende mange kunder og ikke minst leverandører med mye erfaring viser manglende forståelse for hva som må til for å gjennomføre dette i praksis. De fem punktene er:

  1. Riktig kompetanse. De som beskriver behov og krav må kjenne virksomheten, primært arbeidsprosesser og regelverk, meget godt. Jeg har ofte sett at kompetente folk bare har vært med sporadisk og i en tidlig fase av arbeidet. Det holder ikke.
  2. Solid forankring gjennom både arbeidet med å lage en kravspesifikasjon og ikke minst under gjennomføringen av prosjektet. Dette er ikke et «one man show». Som er krevende når store løsninger med hundrevis av krav skal innføres. Det tar tid å forankre, ikke minst for de det skal forankres hos. Når disse ikke har den tiden, bytter jobb internt eller slutter kan man lett få et vakuum – som lett kan føre til at man skyver på vanskelige avklaringer til senere i prosjektet.
  3. Tenk nytt, ikke bare kopier funksjonaliteten i en gammel løsning. Overraskende mange går i denne fella. Man snakker om å optimalisere arbeidsprosesser og tenke smart i en ny løsning, men når alt kommer til alt ender man opp med at den nye løsningen blir for mye av det gamle, laget på en ny teknisk plattform. Og gjerne unødvendig komplisert.
  4. Visualiser løsningen så tidlig som mulig. Det er mye mer effektivt å kommunisere ved bruk av skjermbilder kontra beskrivelser. Når et krav er at løsningen skal ha «et moderne og effektivt brukergrensesnitt», må man så tidlig som mulig konkretisere hva det i praksis betyr. Da blir visualisering helt avgjørende. Både for at kunde og leverandør skal bli enige om en felles forståelse, men også fordi tidlige designvalg kan bli veldig arbeidskrevende å endre senere i prosjektet. Går det helt til akseptansetesten kan man også risikere store økonomiske krav i form av endringsordre.
  5. Dynamisk samarbeid i et konstruktivt klima. Begge parter bør være innstilt på at endringer i krav vil komme. Ingen kunde klarer å definere krav så presist at man bare kan designe og bygge uten videre. I tillegg kan (og bør) standard funksjonalitet i mange applikasjoner også påvirker realiseringen av krav. Dette skal normalt dekkes i kontrakten, men ofte ser man det ikke godt nok før prosjektet er i gang. Da blir det viktig med en åpen og fleksibel samarbeidsform. Dessverre ser jeg for ofte at kunden «står på krava», både fordi man er er usikre (kompetanse) og forankringen er vanskelig å få til, samt at viljen til å tenke nytt ikke er nok til stede (her kan man også være bundet av det offentlige reglementet for anskaffelser, men det gjelder jo ikke i privat sektor).

La meg snu på det: Hvis man bygger et IT-system hvor kravene er laget av noen som ikke kjenner virksomheten inngående, det har vært dårlig forankring i linjen eller forretningen underveis i prosjektet, man er mest opptatt av å kopiere det bestående (hvis det finnes), ingen ser demo av løsningen før langt ute i prosjektet, og det er rigide fronter mellom partene – da er det en sikker oppskrift for at det blir nok et mislykket prosjekt.

IT-skandalene i offentlig sektor

Difi-sjefen Ingelin Killengreen skriver i sitt innlegg 19/12-2014 i DN (Hvordan unngå IT-skandalene) om viktige, men samtidig ganske generelle og opplagte virkemidler for å gjøre ledelsen i det offentlige dyktigere til å forstå IT-strategi og gjennomføre prosjekter. Temaer det har blitt snakket om i årevis. Det er to forhold som ikke påpekes, som jeg mener har en meget stor betydning for pengebruk og suksessrate:

For det første: Regelverket i det offentlige er ofte meget komplisert med mange sære regler og unntak. Når man skal digitalisere dette i IT-løsninger, blir jobben kompleks og omfattende både å bygge og vedlikeholde. Da trenger man mange konsulenter, noe DN gjennom søkelyset på NAV sine IT-kostnader effektivt har påvist. Det som dessverre sjelden utføres er en kritisk gjennomgang med mål om forenkling av regelverket før et IT-prosjekt starter. Da mister man en unik mulighet til forenkling og effektivisering.

Videre kan regimet for offentlige anskaffelser være direkte kostnadsdrivende. Dette har også blitt påvist gjennom en rekke artikler i DN. La oss håpe at forslagene fra Forenklingsutvalget (levert i juli i år) blir iverksatt. Det vil i det minste hjelpe noe.

Men uten forenklede arbeidsprosesser og regelverk vil IT-prosjektene fortsette å være store og kompliserte og med høy risiko for både tids- og kostnadssprekk.

To prosjekter: Så like, men likevel tar det ene tre ganger mer tid …

Noen ganger kan prosjekter tilsynelatende se ganske like ut, men vise seg å bli veldig forskjellig å gjennomføre. Eksempelet jeg skriver om her handler om to virksomheter som begge skulle skifte ut sine økonomisystemer. Den ene er en dynamisk, mellomstor privat bedrift («BEDRIFTEN») og den andre en litt større statlig etat («ETATEN»). Begge hadde et ganske likt utgangspunkt med en eksisterende ERP-løsning som måtte skiftes ut.

BEDRIFTEN brukte under ett år på et forprosjekt, utarbeide en kravspesifikasjon, gjennomføre en tilbudskonkurranse og et prosjekt og ta i bruk løsningen. ETATEN er fortsatt ikke i mål etter tre år. Hvorfor blir det slik? Er det noen tydelige indikatorer som kan fortelle hvorfor noe som er ganske likt tar så mye lenger tid i ETATEN enn hos BEDRIFTEN? Ja, jeg tror det.

Jeg har satt opp noen viktige parametere og gjort en liten vurdering av de to prosjektene opp imot disse:

  • Kontrakttype: Statens standard for begge.
  • Ledelsen engasjement: Høy for begge.
  • Løsningens kompleksitet: Høyere for ETATEN.
  • Grad av tilpasning: Mye høyere for ETATEN.
  • Rammebetingelser: Mer krevende for ETATEN.
  • Tidspress: Mye høyere for BEDRIFTEN.

ETATEN er pålagt å følge og benytte statens regelverk for IT-anskaffelser, men også BEDRIFTEN valgte å benytte denne prosessen og kontrakt – riktignok med mulighet for en helt annen fleksibilitet enn ETATEN kan gjøre. Og uten den gjennomsyrende frykt i det offentlige for å gjøre noe feil i prosessen. Etter mitt syn viser det at både prosessen og kontrakten er god, men regelverket som staten må følge er meget rigid. Gjør man en liten feil kan hele prosessen bli underkjent. Rykk tilbake til start! Det risikerte man ikke i BEDRIFTEN og kunne derfor kjøre en rask og smidig prosess, men uten å gå på kompromiss med etiske normer. Flere av tilbyderne sa i ettertid at de hadde satt pris på den ryddige og profesjonelle prosessen som var gjennomført. ETATEN derimot, brukte mye tid på å sikre seg at alt gikk riktig for seg, og hadde gjennomgående mye lengre frister på alt enn BEDRIFTEN. Så der BEDRIFTEN brukte 6 måneder på å få en avtale på plass, brukte ETATEN halvannet år. Det samme gjaldt gjennomføringen.

Ser man på ETATEN er det tilsynelatende ikke noen spesielt skremmende faktorer som spiller inn. Likevel tar det altså så mye lenger tid. Jeg tror BEDRIFTEN kom bedre ut primært av tre grunner:

  1. Valg av standard løsning fremfor skreddersøm
  2. Større grad av fleksibilitet i gjennomføringen
  3. Stort tidspress

BEDRIFTEN bestemte seg tidlig for å velge en standard løsning og gjøre så få tilpasninger som mulig på denne. De var villige til å endre sin måte å jobbe på i tråd med systemets standard prosesser hvis det var nødvendig. De tok utgangspunkt i en løsning hvor man kunne jobbe interaktivt hele tiden og se systemet live og legge inn sine regler fortløpende, uke for uke. Prosjektteamet jobbet kontinuerlig med detaljdesign, dialog med utviklerne, testing og evaluering. ETATEN, derimot, jobbet på en tradisjonell måte med mye lenger avstand mellom sine prosjektdeltakere, utviklerne hos leverandøren og selve løsningen. De var veldig opptatt av å få ting på sin måte, og hadde enkelte krav som var meget kompliserte å realisere.

Dette, sammen med en dynamisk holdning til de kravene som var utarbeidet, gjorde at BEDRIFTEN gjennom prosjektgjennomføringen hele tiden tilpasset seg og tok mange små beslutninger som ga trygghet på at de var på riktig vei. Dette kunne ikke ETATEN gjøre, deres krav var «hellige», enten de var fornuftige eller ikke. Det sto jo i kontrakten og var en del av evalueringsgrunnlaget.

Og så kan man ikke komme unna tidspresset. Av forskjellige grunner måtte BEDRIFTEN bli ferdig på ett år, mens ETATEN ikke på langt nær hadde det samme presset fra ledelsen. Når presset reduseres akseptere man mye lettere at «ting tar tid». For BEDRIFTEN var det ingen nåde: Eierne var veldig tett på ballen, og alle visste akkurat hva som var forventet av dem.

Begge løsningene kommer sikkert til å bli bra for virksomhetene. Men det er skremmende at et prosjekt i det offentlige skal tvinges gjennom rammebetingelser og forutsetninger som gjør at det tar så mye lenger tid og dermed også blir betydelig dyrere (for oss skattebetalere). Hvor mye dyrere? Vet ikke sikkert, men tipper at vi snakker om en faktor på 10 til slutt. Da begynner vi å snakke om mye penger.

Mann mot maskin: Hvor mange har mistet jobben om 20 år?

Blant de fleste (samfunns)økonomer er det en vedtatt sannhet at IT-drevet innovasjon skaper flere arbeidsplasser enn automatiseringen fjerner. Ser man på statistikk for de siste 20 årene er det ingen tvil om at teknologiens muligheter har gitt betydelig verdiskapning, samtidig som arbeidsplasser – spesielt i den vestlige verden – har blitt lagt ned eller flyttet til land hvor arbeidskraften er billigere enn hos oss. Totalt sett har vi hittil gått i pluss, men er det gitt at denne utviklingen vil fortsett på samme måte hvis man ser 10, 20 eller 50 år frem i tid?

Dette er det store spørsmålet som blir stilt i boken The Lights in the Tunnel av Martin Ford. Det er interessant at han, som ingeniør, gründer og programvareutvikler, både stiller og besvarer spørsmål som bryter kraftig med den rådende holdning blant toneangivende økonomer. Nettopp derfor kan han tillate seg å tenke utradisjonelt. Han er i utgangspunktet meget kritisk til økonomenes analyser som han mener er bakoverskuende og ikke tar inn over seg den teknologiske utvikling vi kommer til å se i årene som kommer, og konsekvensene av dette. Og mener at de ikke forstår hva som er i ferd med å skje.

MooreI korte trekk er hans teori som følger: Teknologien kommer til å fortsette å utvikle seg i stadig økende tempo (ref. Moore’s lov). Alle som kan regne skjønner da at i løpet av ikke veldig lang tid vil det innebære et kvantesprang, ikke bare i ytelse (regnekraft), men også funksjonalitet i form av kunstig intelligens. Dette vil føre til en revolusjon når det gjelder automatisering av arbeidsoppgaver. Denne automatiseringen vil kunne benyttes for opp mot 50 % av alle arbeidsoppgaver innen forskjellige yrkesgrupper i USA. Dette vil i så fall føre til en massiv arbeidsledighet som kommer til å redusere kjøpekraften for svært mange mennesker. Nedgangen i etterspørselen i markedet vil føre til en nedadgående spiral, hvor det er omfattende tilbud av produkter og tjenester, men ikke nok kjøpere i markedet – noe som vil føre til negativ vekst. Noe få eiere vil riktignok bli rikere, men majoriteten av arbeidstakerne vil få mindre å rutte med, og markedet er avhengig av dette volumet for å fungere.

Ford argumenterer og viser på en god og troverdig måte hvordan disse faktorene henger sammen. Nå er ikke jeg samfunnsøkonom, men synes likevel at resonnementene virker overbevisende. At teknologien gjør automatisering stadig mer mulig og utbredt, blir løpende bekreftet i nyhetsbildet. For eksempel når en fabrikk i Kina lager ferdighuselementer som blir «printet» ut fra en gigantisk 3D-skriver, nesten uten bruk av arbeidskraft. Eller når Google gjør nye fremskritt med sin førerløse bil. Eller når radiologer får stadig færre oppgaver på grunn av automatisert tolkning av røntgenbilder. Sånn kan man fortsette lenge. Så at automatiseringen fortsetter er det ingen tvil om.

Det store spørsmålet er hvor mange nye arbeidsplasser som vil bli skapt. Bedrifter som er ledende innen teknologibruk omsetter betydelig mer per ansatt enn lav-teknologi bedrifter. Wal-Mart har 2,2 millioner ansatte, eller 44 ganger mer enn Google, mens forholdet mellom deres omsetning er 8:1. At Wal-Mart, la oss si innen 20 år, har automatisert bort betydelige mengder av sine ansatte er meget sannsynlig. Og hvor mange av disse (lavt utdannede) arbeidstakerne vil da klare å skaffe seg ny jobb? Ford argumentere kraftig for at det kommer til å være ganske få. Etableringen av arbeidsplasser i nye virksomheter og i eksisterende bedrifter, vil ikke demme opp for den totale nedgangen, spesielt i privat sektor hvor det er konkurranse. Det vil føre til erosjon av statens inntektsgrunnlag med påfølgende konsekvenser for offentlige tjenester.

Totalt sett tegner han et ganske pessimistisk bilde. Men kommer med noen forslag til løsninger, selvsagt. Han er jo dog en ingeniør! Og det er mulig å legge om skatte- og trygdepolitikken slik at man kan sikre staten inntekter og borgerne sosial trygghet. Men det innebærer at politikerne skjønner hva som skjer og er villige til å endre politikken i tråd med dette. Men hvor lett er det, spesielt i USA, å legge om en skattepolitikk slik at bedriftene garantert skatter mer enn de gjør i dag? Eller legge mer skatt på forbruk? Eller innføre en borgerlønn?

man machine1

MartinFord har en meget informativ blogg hvor han skriver mer om dette og har mange linker til mye materiale som utdyper de problemstillingene han tar opp. Boken kom i 2009 og er preget av finanskrisen, men er like aktuell i dag. Det skal bli veldig spennende å følge denne utviklingen fremover. Selv har jeg alltid vært teknologioptimist med tro på at det hele tiden vil dukke opp nye muligheter som vi ikke ser i dag. Og slik vil det fortsette. Men igjen: Vil veksten også for fremtiden virkelig klare å demme opp for avskallingen i antall arbeidsplasser? Denne boken har faktisk gjort meg litt i tvil om det vil kunne skje.

IT-ledelsens fire ansikter

JanusI følge romersk mytologi hadde guden Janus et blikk både mot fortid og fremtid, og ble derfor ofte avbildet med sine to ansikter. For mange stod han som symbol for endring og overgang til en ny tilstand, og var et bilde på bevegelse. Jeg tenkte på dette da jeg leste en artikkel om IT-lederens eller CIOens ikke to, men fire ansikter. Å ha to må da være krevende nok? Da jeg leste videre innså jeg at det nok er riktig at en moderne IT-leder må beherske en rekke store roller som går ut over Janus’ to ansikter. At endring og bevegelse står sentralt er det liten tvil om, men er det tilstrekkelig? Nei, det er ikke det.

Deloitte Consulting har gjort en undersøkelse blant flere ti-talls nåværende og tidligere CIOer og konkludert med at IT-lederen må finne en balanse mellom fire roller: Operator, Technologist, Catalyst og Strategist. Dette er ikke veldig ulikt andre rammeverk, f.eks. lanserte jo Gartner for 10 år siden sin tilsvarende modell som skilte mellom Grinder, Butler, Team Player og Entrepreneur. I min bok «Omstilling» valgte jeg å benytte rollene teknologileverandør, serviceleverandør og samarbeidspartner. På mange måter snakker vi om det samme, men jeg synes likevel CIOens fire ansikter i modellen til Deloitte har mye for seg.

The Operator – drifteren – er dag-til-dag lederen som skal sikre leveranse av stabile og kostnadseffektive tjenester til organisasjonen. Dersom man sliter i denne rollen, blir det nesten umulig å fylle rollen som katalysator og strateg, både av tidsmessige grunner, men ikke minst på grunn av manglende troverdighet.
The Technologist – teknologen – er ansvarlig for å sikre en teknisk arkitektur som gjør virksomheten fleksibel og i stand til å møte nye utfordringer på en kostnadseffektiv måte. Teknologen har alltid et blikk mot nye teknologier som blir analysert og testet.
The Catalyst – endringsagenten – søker hele tiden etter nye og innovative måter å bruke IT som en del av virksomhetens produkter og tjenester. CIOens unike posisjon på tvers av funksjoner og gjennom hele verdikjeden gir en oversikt og kompetanse som, parret med de andre tre ansiktene, kan føre til nye markedsmuligheter.
The Strategist – strategen – har som sitt primære mål å sikre at alle IT-investeringer støtter opp under eller er integrert med virksomhetens strategi. Dette er den klassiske IT-strategen som har betydelig innsikt i måten virksomheten fungerer på.

Etter å ha vært CIO i 11 år kan jeg underskrive på følgende: 1) Det er en stor utfordring å finne en riktig balanse mellom de fire rollene, 2) Rollene henger sammen (du kan ikke lykkes som strateg uten å ha kontroll på drift og teknologi, 3) Ingen virksomheter er like og vil kreve ulikt fokus, og 4) Man ønsker som CIO ofte at balansen skal være annerledes enn den faktisk er.

innovasjonCIOene i undersøkelsen sier at deres primære ansikt er knyttet til dag-til-dag drift (36 %), det å holde hjulene i gang, mens det de primært ønsker å være er strateg og endringsagent. Jeg har i mange år argumentert for sammenhengen mellom IT-innføring, strategi og endringsledelse, og det mener jeg fortsatt. Men når enkelte hevder at CIO egentlig burde stå for Chief Innovation Officer, stusser jeg. En CIO bør etter mitt syn ikke være den som får ansvaret for innovasjon. Være konstruktiv bidragsyter og teknologisk premissgiver – ja. Være del av team som jobber med tjenesteutvikling – ja. Være ansvarlig for å bygge nye IT-baserte, innovative produkter og tjenester – ofte. Det er i samspill med andre at de store innovative sprangene kan skje. Men ansvaret må ligge i forretningen.

Hva så med denne drømmen om å bli noe mer enn det man er? Høyst forståelig, men er det realistisk? Det er ingen tvil om at reisen fra å være The Operator til The Catalyst er meget krevende. Før man kommer dit vil mange være brukt opp, både fordi man rett og slett går tom for krefter, men også fordi man har blitt plassert i en bås som det er veldig vanskelig å komme ut av. Kan man starte med blanke ark er alt mulig, men hvor mange får den muligheten? Min konklusjon er dessverre litt pessimistisk: Dette er en ambisjon som det er svært få forunt å fylle. Har jeg tanker om hvordan dette kan løses? Ja, og det skal jeg ta for meg i et annet innlegg. 🙂