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

Reklamer

Arkitekturens forbannelse

Du finner ingen IT-folk som ikke mener at arkitektur, på ett eller annet nivå, er viktig. Fra det detaljerte nivået med tekniske arkitekturer for nettverk og servere, til høynivå arkitektur som viser sammenhengen mellom strategi, arbeidsprosesser, informasjon og systemer (enterprise architecture). Det ubehagelige og vanskelige er at arkitekturen på flere nivåer ofte henger sammen. Før jeg tar opp denne tråden igjen, en liten casehistorie.

Jeg kom over et interessant prosjekt forleden. En forholdsvis liten offentlig virksomhet hadde innført en ny løsning for online innrapportering av data om sine brukere. Informasjonen ble benyttet slik at de kunne tilpasse sine tjenester på en meget fleksibel måte, med full oversikt over dagens behov. Dette gjorde de raskt og billig, uten å involvere andre enn sine leverandører. Teknologien er avansert, men løsningen enkel. De valgte helt bevisst ikke å ta hensyn til noen sentrale føringer overhode, enten de kom fra Difi eller andre. Smarte var de også: Det hele ble definert som et prøveprosjekt, noe de fikk aksept for. Løsningen fungerer i dag som planlagt. Egentlig en liten suksesshistorie. Hva er da problemet?

Virksomheten jeg refererer til er en av mange «avdelinger» i en stor offentlig virksomhet som strever med akkurat de samme problemstillingene. De visste veldig godt at dersom de skulle ha ventet på et «konsernprosjekt» som hadde tatt hensyn til alle mulige problemstillinger med valg av teknologi, standarder, og ikke minst arkitekturer, ville de ikke ha gått live i 2013, men kanskje i 2016 –  hvis de hadde kommet i mål overhode. Da er det vel bedre bare å starte? Så får i det minste noen glede av dette. Problemet, sett fra toppen, er når «alle» i innfører ulike løsninger. Da blir det dyrere og selvsagt vanskeligere å trekke ut styringsdata på tvers. Her skyter jeg kanskje meg selv litt i foten (som gammel IT-direktør som alltid var opptatt av synergier på tvers … ), men jeg synes faktisk det er bedre at noen ildsjeler får mulighet til å innovere enn at man skaper store, tunge prosjekter som aldri tar av. Jeg kan tenke meg mange situasjoner, som f.eks. innføring av et ERP-system, hvor det vil være annerledes, men altså ikke her.

Enterprise architectureEtter å ha jobbet i denne bransjen to tiår har jeg fortsatt til gode å se noen som virkelig har lykkes med å både lage, følge og oppdatere en helhetlig arkitektur over tid. Det blir med et stunt, så settes det hele bort. Noen gode elementer brukes, resten har ingen verdi.

Så fornuftig i teorien, men så ubrukelig i praksis.

Finnes det egentlig IT-prosjekter?

Jevnt og trutt leser vi om store kostnadsoverskridelser i forbindelse med innføring av nye IT-løsninger. Prosjektene tar mye lenger tid enn planlagt, kundene og leverandørene skylder på hverandre, fagforeningene raser og brukerne fortviler.  Nå har vi holdt på med å innføre nye datasystemer i over 40 år. Hvorfor butter det slik?

Det innebærer ingen revolusjon å hevde at vellykket innføring av nye IT-løsninger forutsetter et nært samspill mellom teknologianskaffelse, utvikling av arbeidsprosesser og endringsarbeid. Hvor man har sikret at prosjektet støtter opp under eller er en integrert del av virksomhetens strategi. Og at man tar hensyn til organisasjonskulturen når endringsarbeidet planlegges og gjennomføres. Samt at det hele ledes og styres på en profesjonell måte fra starten av beslutningsprosessen til verdiskapningen er realisert. På tross av bevisstheten hos mange om disse sammenhengene, vil jeg hevde at svært få virkelig er gode til å gjennomføre dette i praksis, og dermed sikre at verdiskapningen eller nytteeffekten eller resultatet – kjært barn har mange navn – blir så stort som potensialet tilsier.

innovationAlt for mange kaller fortsatt dette arbeidet for et IT-prosjekt. Navnet gjør at man assosierer prosjektet hovedsakelig med teknologi. Men hvorfor innfører du egentlig et nytt IT-system? Jo, enten er det for å utvikle eller effektivisere organisasjonen, eller så er det for å utvikle tjenestene som leveres til et marked. Teknologien er et middel for å nå et mål. For å klare det må en fokusere på mye mer enn teknologi.

De aller fleste såkalte IT-prosjekter er egentlig forretningsutvikling, mange med en solid grad av nytenkning og innovasjon knyttet til seg.

For: Alle prosjekter skal ha en forretningsmessig begrunnelse og en eier i forretningen. Uansett hvilket teknisk behov man har, vil det alltid kunne vises til en konsekvens for forretningen dersom man ikke gjør det. Enten i form av at noe går langsommere, blir utilgjengelig eller feil. Som igjen har en økonomisk konsekvens. Så alle prosjekter skal ha en forretningsmessig begrunnelse.

Dersom et prosjekt kan gjennomføres uten involvering fra forretningen, er det et teknisk prosjekt. Hvis ikke, er det er forretningsprosjekt med en teknisk del. Så kan man alltid diskutere hvor den grensen går. Det finnes noen rene IT-prosjekter. En oppgradering av nettverk (WAN, LAN, WLAN) er tekniske prosjekter med en forretningsmessig begrunnelse (får ikke gjort jobben skikkelig uten mer båndbredde). Grensen for når det er et rent IT-prosjekt kan variere, men bør etter mitt syn være meget høy. Det vil si at prosjekter der den tekniske delen utgjør over f.eks. 90 prosent blir definert som et teknisk prosjekt og styrt deretter. Men ellers er det forretningsutvikling!

Syv grunnregler for å få mer igjen fra IT-investeringene

Hvem kjenner seg ikke igjen her: Som beslutningstager blir du bedt om å godkjenne en IT-investering på et alt for tynt grunnlag – Forankringen hos nøkkelpersoner er svak, fokus er på teknologi istedenfor endring av arbeidsprosesser og atferd, og kostnadsoversiktene er mangelfulle. I tillegg er ofte de potensielle nytteeffektene diffuse, med svak kobling til forretningens mål og strategi. Analyse av risiko mangler ofte, og relevante alternativer til investeringen blir sjelden presentert. I det hele tatt ganske omfattende mangler! Er det da rart at bare rundt 30% (i følge Gartner Group) av IT-prosjekter blir betegnet som vellykket?

I rettferdighetens navn må det sies at stadig flere har blitt dyktige til å beslutte, gjennomføre og implementere IT-løsninger slik at den forventede gevinsten oppstår. Men fortsatt legges etter min mening for mye ansvar på IT-direktøren, mens andre ledere slipper lettere unna. Noe av grunnen til dette, tror jeg, er at mange ledere mangler kompetanse om og interesse for de totale utfordringene man møter, og fortsatt mener at dette har mest med teknologi å gjøre. Men: Jo større teknologifokuset blir, desto flere vil føle seg fremmedgjort.

success failureLedere trenger noen få, gode knagger å bruke når IT-investeringer besluttes, prosjekter gjennomføres og løsninger skal tas i bruk slik at gevinstene kan realiseres. Teknologibasert endring er jo mye mer enn en dyr teknologisk oppgave. Det dreier seg om å skape verdi gjennom organisatoriske og forretningsmessige endringer, muliggjort ved smart og riktig bruk av teknologi.

Utgangspunktet er at endring av teknologi, arbeidsprosesser og mennesker henger sammen og gir premisser for hverandre, og må forstås innenfor rammene av virksomhetens strategi, styringssystemer og organisasjonskultur. Disse elementene henger ubønnhørlig sammen. Jeg liker å oppsummeres dette i 7 grunnregler:

  1. Strategi: Sjekk det nye initiativet mot virksomhetens reelle og planlagte strategi.
  2. Portefølje: Sjekk det nye initiativet mot porteføljen av andre initiativer, prosjekter og applikasjoner.
  3. Ledelse: Sørg for at det foreligger riktig beslutningsgrunnlag (business case).
  4. Prosjektstyring: Sørg for rask og dynamisk prosjektgjennomføring.
  5. Arbeidsprosesser: Sørg for løpende vekselvirkning mellom prosessforbedringer og den tekniske realisering.
  6. Individ: Bruk aktivt endringsledelse for å sikre forståelse og engasjement.
  7. Verdi:   Bruk og tilpass beslutningsgrunnlaget helt til nytteverdien er realisert.

Er man bevisst på dette øker sannsynligheten for at IT-innføringen blir vellykket. Men enkelt er det ikke, for det er massevis av utfordringer og fallgruver under veis …