En spissorganisering for å stå i front?

I bloggartikkelen «morgendagens IT-avdeling» reiser jeg spørsmålet om det er hensiktsmessig å organisere all IT-kompetanse i en og samme avdeling. Der tar jeg utgangspunkt i en firedelt modell for hva virksomheten måtte behøve av IT (både teknologi og kompetanse). Denne modellen har jeg hatt mye nytte av og vil i denne bloggartikkelen fortelle hvordan jeg bruker den. Kanskje kan den bli et nyttig verktøy for deg også?

Jeg underviste i IT-ledelse på BI ved årtusenskiftet, og formaliserte da modellen såpass at den fikk plass i et par av Petter Gottschalks bøker. Det er gått mange år siden, og det jeg presenterer her er en noe oppusset versjon, selv om hensikten og basisinnholdet er det samme. Modellen har overlevd fordi den er teknologiuavhengig ved å fokusere på utfallet av å utnytte teknologi som måtte finnes. I ytterste konsekvens uttrykker de fire ansvarsområdene følgende hensikter — litt uhøytidelig sagt:

1. besørge grunnforutsetninger for «å drive butikk» (altså virksomheten eller forretningen)
2. støtte daglig drift av «butikken»
3. fornye «butikken»
4. drive den digitale «butikken».

Tenk deg at IT dukket opp først i fjor høst som en ny mulighet for din virksomhet! Hvordan ville du tatt det i bruk og organisert ansvaret for dette nye? La oss si at du da ville etablert noe du kalte «IT-funksjonen» i virksomheten, på linje med andre funksjonsområder som eksempelvis økonomifunksjonen. Jeg antar du finner økonomikompetanse både på innkjøp, lønn, drift, virksomhetsstyring, og i flere fagavdelinger. På samme måte kan vi tenke at IT-funksjonen representerer IT-kompetanse og IT-ansvar i mange valører, plassert flere steder rundt om i organisasjonen, altså summen av de IT-faglige miljøene. Spørsmålet jeg reiser er:

I illustrasjonen nedenfor legger jeg de fire nivåene oppå et bilde av istapper. Jeg skal forklare hvorfor.

Figur 1. IT-innsatsområder i en virksomhet (Bildet av Ukjent forfatter er lisensiert under CC BY-NC-ND)

Figur 1. IT-innsatsområder i en virksomhet (Bildet av Ukjent forfatter er lisensiert under CC BY-NC-ND)

En modell representerer som kjent ikke sannheten, men gir kun en grov beskrivelse av virkeligheten. Ved å bruke istappmetaforen vil jeg komme bort fra fokuset på nivåer. Det er ikke en stige hvor målet er å komme seg opp fra ett nivå og til det neste, og altså hvor det nivået man forlot ikke er like viktig lenger. Det er glidende overganger, og ingen nivå er mindre viktig enn andre. Tar du bort nivå 1 i figuren ovenfor vil istappen ramle ned.

Men hvordan bruker jeg modellen? For meg er den et rammeverk når vi skal drøfte IT sin rolle og betydning i en virksomhet, enten jeg snakker med IT-ledere eller virksomhetsledere, og reiser spørsmål som:

• Hva trenger virksomheten av ansvar og innsats fra de ulike deler av IT-funksjonen?
• Hvordan evaluere at man lykkes, for hvert av innsatsområdene?
• Hvordan samspille mellom IT og andre fag i virksomheten, og sammen sette strategiske mål for IT sitt bidrag på hvert nivå?
• Hvordan kan vi samspille og nyttiggjøre erfaringer nivåene imellom?
• Hvordan bør vi organisere ledelse og styring for å lykkes med hvert innsatsområde?

Det at vi kan stille slike spørsmål og avgrense dem til ett innsatsområde om gangen, gjør det mye lettere å være konkret. For eksempel, hvordan evaluere at IT-løsningene faktisk støtter virksomhetens prosesser (nivå 2), eller at nye innovative IT-løsninger faktisk gir mer forretning (nivå 3)? Alle de fire IT-innsatsområdene er viktige, og de bygger på hverandre. Jeg har bevisst plassert det mest grunnleggende nivået øverst i modellen. Grunnleggende infrastruktur og funksjonalitet (nivå 1) må være på plass for at man kan være i stand til å støtte virksomhetens prosesser (nivå 2). For å kunne bidra i innovasjon (nivå 3) må IT-funksjonen først kjenne virksomhetens kjernevirksomhet i dag (nivå 2), og så videre. Tenker vi på det som istapper, så vil spissen vokse seg lengre og større etter hvert som virksomhetskunnskap og teknologierfaring flyter nedover i modellen fra nivåene over.

Selvfølgelig kan du finne eksempler på at grenseoppgangen mellom innsatsområdene ikke er veldig tydelige, og at sannheten fra i går ikke stemmer i dag, men min erfaring er at det kan funke likevel. Innsatsområdene er i figur 1 formulert litt «tidløst» på den måten at det handler mer hva man skal oppnå enn hvilke teknologier som havner i hvilket nivå. Teknologien og konseptene utvikler seg hele tiden, og det som en gang var å betrakte som innovativt er etter noen år blitt grunnleggende for alle. Sånn sett flytter teknologier og virkemidler seg «oppover» i modellen etter hvert som tiden går, — eller mer korrekt, blir basis for en kraftigere istapp, eller for å danne nye istapper.

Nok prat; nå må vi ta i bruk modellen.

Hvor viktig er IT-funksjonen for virksomheten?

Illustrasjonen nedenfor gir (i venstre kolonne) stikkord på hvilke oppgaver som typisk kan ligge til hvert av de fire områdene, samt (i høyre kolonne) hvordan synliggjøre eller måle at man lykkes. Dette er mye informasjon på en gang. Jeg vil foreslå å ta utgangspunkt i denne modellen for en workshop på IT-avdelingen (eller de IT-faglige miljøene samlet hvis dere har flere), for en bevisstgjøring på hva de faktisk jobber med og hva de eventuelt ikke gir bidrag til. Eksempelvis kan du spørre: leverer vi først og fremst daglig drift (nivå 1), eller er vi også proaktive overfor kjernevirksomheten på ny utnyttelse av data (nivå 3)?

Etter at IT-avdelingen/IT-miljøene har gått noen runder med seg selv og sitt selvbilde, er det tid for en workshop sammen med ledere for de andre fagavdelingene og kanskje toppledelsen. Hva er forretningssidens syn på behovet for, og nytten av, IT-miljøene i virksomheten? Da vil selvbildet hos IT-miljøene kunne møte forventningsbildet hos virksomheten, og du får forhåpentligvis en god vekselvirkning der og en fruktbar utviklingssamtale. Poenget er å komme til selvransakende spørsmål for alle parter, som for eksempel «trenger virksomheten en innovasjonspartner, og til hva, og kan våre IT-miljø fylle den rollen for oss? (nivå 3)» eller «hva skal til hos både IT-avdeling og i fagavdelinger for at vi skal innta en helt ny posisjon i vår bransje med heldigitale tjenester? (nivå 4)»

Figur 2. Stikkord for oppgaver og suksessfaktorer for innsatsområdene

Figur 2. Stikkord for oppgaver og suksessfaktorer for innsatsområdene

Jeg snakker om IT-avdelingen her fordi det er en kjent organisatorisk konstruksjon i mange virksomheter, etablert for å holde styr på det som har med data, lagring og deling av informasjon å gjøre, og teknologier for å behandle data. Men det er fagenhetene som eier dataene og informasjonen og kunderelasjonene, og ikke IT-avdelingen spesifikt. Faktisk er dette virksomhetens gull i mange tilfeller, og som IT-avdelingen setter IT-kompetente folk til å ta vare på og til å hjelpe virksomheten med bearbeidelse av. Det er store verdier, og potensielt store sikkerhetsmessige aspekter involvert. Det kan være relevant å spørre (spesielt på nivå 3 og 4): Er IT-kompetanse tilstrekkelig for å ivareta oppgaven? Og motsatt; er forretningskompetanse tilstrekkelig for de som eier og nyttiggjør dataene og informasjonen? Jeg legger selvsagt opp til at begge deler trengs, og at vi må ta konsekvensene av det. Eksempelvis får IT-folk i dag større og større ansvar for utforming av produkter og tjenester, inkludert kundenes bruksopplevelse. Hvordan bør det påvirke organiseringen av disse oppgavene? Hvilke kompetanser må til for å håndtere produkteierskapet når produktet er «erfart nytte av en digital tjeneste»?

Organisering av IT-funksjonen er avhengig av ansvarsområde

Den neste illustrasjonen kan være en hjelp til å drøfte hvilket ansvar som ligger til hvert innsatsområde og hvordan man kan eller bør organisere dette i virksomheten. Illustrasjonen gir noen stikkord som kan være veiledende, men er ikke en fasit. Et aspekt å tenke over er at oppgavene i de øverste nivåene tilsier behov for tydelige ansvarsgrenser og klare avtaler, og altså gjerne veldefinert og stabil organisering. Jo lenger ned i modellen du kommer jo mer fleksible bør aktørene være. Når vi kommer til nivå 4 skal det kanskje ikke alltid være veldefinerte stillingsinstrukser, men heller mer bruk av dynamisk organisering i tverrfaglige team i takt med produktsatsing og markedsdialog, og med team som har stor grad av selvstendighet til å ta valg med betydelige forretningsmessige konsekvenser. Det kan være en grensesprengende tanke. For å spissformulere; det trengs ikke bare spisskompetanse, men kanskje også spissorganisering for jobbing ytterst på istappen!

Figur 3. Stikkord på mål for, og organisering av, innsatsområdene

Figur 3. Stikkord på mål for, og organisering av, innsatsområdene

Også her anbefaler jeg å kjøre en workshop, kanskje først med ledergruppen fordi her drøfter vi den strategiske betydningen av IT. For det første vil modellen gi lederne bevissthet på at IT i noen tilfeller er varer og tjenester du kjøper, men i andre tilfeller må IT være tett integrert i det faglige arbeidet og verdiskapningen. Dernest utfordres lederne til å drøfte hva det helt konkret vil kunne bety i egen virksomhet. I noen virksomheter vil det nok bety at «IT-avdelingen tas inn i varmen». Det kan bli tydelig at virksomhetsstrategien ikke kan legges uten medvirkning og medansvar fra IT-avdelingen; (jeg vet at det er et utrolig stort sprik på dette punktet mellom ulike virksomheter /bransjer).

Utfra en slik workshop med ledergruppen kan et tiltak være å tydeliggjøre strategier for hvert av nivåene sett fra virksomhetens/forretningens ståsted; en «strategi for utnyttelse av IT» vil kunne sette svært ulike mål for hvert av nivåene. Et annet tiltak kan være å prøve ut hvordan ansvaret best bør organiseres for å nå de strategiske målene man setter seg for hvert nivå. Kanskje vil noen konkludere at for å lykkes på nivå 3 og spesielt på nivå 4 er den tradisjonelle IT-avdelingen en for lite smidig organisering. Man må kanskje tenke mer dristige former for «spissorganisering». Dette vil for mange være upløyd mark, og i overkant spennende, men også her gjelder at «den som intet våger intet vinner».

Oppsummering

For at «enden av istappen» skal kunne vokse seg stor, må vi se oss om etter alternative måter å organisere IT-funksjonen på i virksomheten. Det er her, på enden av istappen, at det er mest påkrevd med dialog mellom forretningsutvikler og systemutvikler, mellom bruker og designer, for å utforme produktene og skape bruksopplevelse — og kontinuerlig kunne tilpasse produktene i et skiftende marked. De som sitter i denne «spissen» må beherske både IT og forretning, ikke nødvendigvis som enkeltpersoner, men som et team. I dette bildet blir det ikke naturlig å snakke om IT-funksjonen som en separat avdeling eller gruppe; det vil være et kompetanseområde integrert i det forretningsmessige ansvaret. Istapper er gjerne tynnest her på enden, og mest sårbare for å knekke. Det kan vi tenke på som et bilde på risiko ved å strekke seg langt i digitalisering av virksomheten. Men det er de som strekker seg lengst som først blir valgt, i alle fall av dem som har lyst til å plukke ned en istapp.

Ta gjerne kontakt hvis du er interessert i denne tematikken.