– Af Peter Nørregaard, Expert Director
“Ingen plan overlever kontakten med fjenden.” Dette klassiske militærcitat kan nemt omskrives til situationen for it-initiativer i dag: “Ingen it-initiativer overlever kontakten med organisationen.”
Som konsulenter oplever vi alt for ofte, at godt tænkte initiativer fejler i mødet med organisationen. Det kan være svært på forhånd at vurdere, hvilke der vil lykkes, og hvilke der vil fejle. En god analyse kan hjælpe til at forstå it-initiativerne i forhold til den udviklingsretning, organisationen ønsker.
Derfor præsenterer vi her en analysemodel, som kan hjælpe med på forhånd at identificere og forhindre de initiativer som i praksis vil være dømt til at fejle. Initiativer, som i to af vores cases endda har fået it-direktøren fyret.
Modellen er oprindeligt udviklet af Jeanne W. Ross (MIT), Peter Weill (MIT) og David C. Robertson (Wharton). Modellen opstiller fire forskellige forretningsmæssige operating models med hver sine krav til it-understøttelsen.
Forfatterne er på empirisk solidt grundlag kommet frem til, at organisationer med en it-understøttelse (foundation for execution) som er afpasset til organisationens måde at operere på (organisationens operating model), performer bedre end sine ligesindede. Forfatterne skriver:
”Companies with a foundation for execution supporting an operating model reported 17 percent greater strategic effectiveness than other companies – a metric positively correlated with profitability. These companies also reported higher operational proficiency (31%), customer intimacy (33%), product leadership (34%), and strategic agility (29%) than companies that had not developed a foundation for execution.”
Vi vil her vise, hvordan modellen kan bruges operationelt til analyser i it-afdelingerne.
Hvordan er modellen relevant til evaluering af it-initiativer? Modellen kan vise, hvor organisationen ønsker at ligge i forhold til standardisering af processer som den ene dimension og som den anden, integration af processer, hvilket i praksis sker ved at dele data. Modellen kan også vise, hvor hvert it-initiativ søger at trække organisationen hen. På den måde synliggøres, om et it-initiativ modarbejder eller hjælper organisationen i at opnå – eller fastholde – sin ønskede placering i modellen. It-initiativer, som ikke understøtter eller direkte modarbejder organisationens ønskede placering, vil ofte fejle, som de tre cases herunder viser.
For at finde frem til præcis, hvor en organisation befinder sig i modellen, bør man ifølge Ross, Weill og Robertson stille sig følgende to spørgsmål.
- I hvilket omfang er transaktioner i en forretningsenhed i organisationen afhængige af data fra en anden forretningsenhed? For eksempel med hensyn til tilgængelighed, nøjagtighed og timing.
- I hvilket omfang gavner det organisationen, at forretningsenhedernes processer er standardiserede på tværs af organisationen?
Afhængig af svaret på de to spørgsmål kan organisationen indplaceres i en af fire kvadranter. Vi gennemgår i det følgende kort de enkelte kvadranter.
Diversification (D)
Her taler vi om en organisation, der er kendetegnet ved behov for ”independence with shared services.” De forskellige forretningsenheder har ikke særlig meget til fælles med hensyn til kunder, leverandører eller forretningsmodel, og organisationens øverste ledelse har begrænset operationel kontrol. Det kan for eksempel være et konglomerat som Mærsk eller Ørsted.
Coordination (C)
Organisationer i denne kvadrant er kendetegnet ved behov for ”seamless access to shared data.” Data samles centralt, men der er ingen eller kun lidt standardisering af processer. De fleste virksomheder har brug for fælles data om eksempelvis kunder.
Replication (R)
Her finder vi organisationer med ”standardized independence.” De enkelte forretningsenheder kører autonomt, men med en høj grad af standardisering. Et typisk eksempel er kæder som 7-11 og Starbucks.
Unification (U)
I denne kvadrant mødes delte data med standardisering af processer og bliver til Unification. Organisationerne i denne kvadrant er kendetegnet ved behov for ”standardized, integrated processes.” Typiske eksempler er luftfartsselskaber og UPS.
Med modellen følger en række anbefalinger til, hvordan organisationer i de respektive kvadranter kan understøttes med it. Eksempelvis får organisationer i Diversification-kvadranten anbefaling om at etablere shared services.
For at kunne bruge modellen korrekt, er det vigtigt at forstå, at operating model for ens egen organisation kan variere, afhængig af hvilket organisatorisk niveau, man analyserer. Eksempelvis ligger et konglomerat typisk i kvadranten Diversification, mens det enkelte forretningsområde i konglomeratet kan have en anden operating model, for eksempel Unification, som vores sidste case viser.
3 cases
I det følgende gennemgår vi tre autentiske forløb, vurderet ud fra analysemodellen.
Case 1. Forkert scope for it-initiativ i Alpha-gruppen
Organisationen bestod af 5 divisioner med et behov for standardiserede, delte data om udvalgte kunder, men med meget forskellige processer i hver division. I analyse-modellen kunne det beskrives som en virksomhed placeret i Diversification på vej mod lidt mere Coordination. Denne situation befinder mange virksomheder sig i.
En visionær arkitektur-chef fra den ene division startede et initiativ med begrebsmodellering på tværs af hele gruppen.
Initiativet blev gennemført over 10-12 måneder og resultatet var en overordnet begrebsmodel for hele Alpha-gruppen på et højt fagligt niveau. I dag, 10 år senere, er modellen stadig ikke i brug nogen steder i Alpha-gruppen og den bliver da heller ikke opdateret.
Interessenterne i it-afdelingen og forretningsenhederne ignorerede begrebsmodellen, fordi de havde svært ved at se relevansen af den for deres arbejde. Arbejdet blev anset som fagligt solidt, men afkoblet fra virkeligheden.
Initiativer om fælles begrebsmodeller er typisk både relevante og velkomne i organisationer, som arbejder mod at befinde sig i Unification kvadranten. I Alpha-gruppen var der ikke overensstemmelse mellem it-initiativet og organisationens operating model.
Hvis initiativet derimod havde været scopet til at koncentrere sig om den division, som den visionære arkitektur-chef kom fra, ville situationen formentlig have været en anden.
Læren er her, at succeskriteriet for et it-initiativ bør være, at det passer til det sæt problemer, som organisationen skal have løst. Uanset, hvor godt initiativet i øvrigt er eksekveret.
Case 2. For ambitiøst scope i Beta Pharma
En ny og ambitiøs it-direktør havde som udfordring, at der decentralt i forretningsenhederne var anskaffet en mængde systemer med overlappende funktionalitet. Omkostningerne var alt for høje, og derfor skulle systemerne inden for hvert forretningsområde konsolideres og standardiseres i, hvad der blev kaldt en domæne-drevet it-strategi.
Der var en vis mængde data, der skulle deles mellem forretningsområderne, men der var ikke behov for ensretning af tværgående processer. Virksomheden befandt sig altså i Coordination-kvadranten.
Den nytilkomne it-direktør havde tidligere arbejdet i en organisation med ét fælles ERP-system og en placering i Unification-kvadranten. Han havde oplevet fordelene ved at befinde sig i der, og hans agenda var – via it-initiativer om ensartede it-anskaffelser inden for samme ERP-produktsuite – at trække organisationen fra Coordination hen imod Unification.
Hvis Betas erklærede strategi havde været en bevægelse mod Unification, ville it-direktørens tilgang have været den rette. Men det var ikke tilfældet, blandt andet fordi en placering i den kvadrant ikke kun bringer fordele, men også udfordringer. I dette tilfælde var det specielt den decentrale frihed der var truet, og it-direktørens it-initiativer resulterede i stigende modstand i forretningsenhederne.
It-direktøren fik stadig sværere ved at retfærdiggøre it-initiativerne over for forretningen og endte med at blive fyret.
Her er læren, at hvis it-initiativerne sigter mod at samle forretningsenhederne på én fælles platform, vil forretningsenhederne typisk yde modstand. Det er derfor afgørende, at strategien har opbakning fra den øverste ledelse, og at man accepterer modstand og konflikter som en omkostning, en godkendt bivirkning om man vil, ved dette strategiske valg.
Case 3. Oversete muligheder i konglomeratet Delta
Delta er et globalt brand med fire selvstændige forretningsområder. Hvert forretningsområde foretog regelmæssigt opkøb af lokale aktører med lokale kunder. It-direktøren var ansvarlig for hele Deltas it, inklusiv i de fire forretningsområder.
Delta havde fokus på bundlinjen, og driftsresultatet var utilfredsstillende.
It-chefen var af den opfattelse, at Delta i analysemodellen lå solidt placeret i Diversification, og han havde etableret de få shared services, en sådan placering giver mulighed for. Disse shared services gav nogle, dog ikke store, besparelser.
Men under overfladen, i de enkelte forretningsområder, var situationen en anden. Et område lå i kvadranten Coordination, en anden i Unification og de sidste to i Replication. Det betød, at der var væsentlige besparelser (og potentialer) at hente ved at fokusere på de anbefalinger, som følger med placeringer i de respektive kvadranter.
It-chefen indså imidlertid ikke behovet på forretningsområde-niveau og pressede derfor ikke nok på med de rigtige it-initiativer. Derfor udeblev gevinsterne, og han blev fyret.
Læren er her, at det er afgørende at være opmærksom på hele organisationen og dens behov, også nede i de enkelte forretningsenheder.
Husk realitetstjekket mod organisationens behov
I samtlige disse tre cases burde man have realitetstjekket initiativerne, eller i sidste case manglen på initiativer, op imod en god analysemodel. De tre cases er nedenfor sat ind i analysemodellen. Her ses tydeligt, hvilken kvadrant organisationen reelt befandt, eller ønskede at befinde sig i, i forhold til den kvadrant, initiativerne understøttede.
Nu kan der være mange årsager til at it-initiativer fejler, men som disse cases viser, kan nogle fejlende it-initiativer identificeres og forhindres i tide blot ved at få dem belyst med en simpel analyse.
Den kendte ledelsesguru Peter Drucker er citeret for, at ”culture eats strategy for breakfast.” Tilsvarende vil vi påstå, at organisationens operating model spiser it-initiativer til frokost.
Derfor skal du realitetstjekke dine it-initiativer op imod forretningens operating model. Du undgår dyre fejltagelser, og sikrer at it-initiativerne matcher organisationen.
Vil du vide mere?
Så er du velkommen til at kontakte Peter.
Vi stiller gerne op til faglige indlæg og individuelle møder om emnet.
