Att stora förändringsprojekt drar över tid och budget är snarare regel än undantag. Inte minst när de inbegriper förändringar av IT-miljön. Många företag lever i en verklighet där verksamhetsprocesserna måste anpassas i allt snabbare takt, samtidigt som de IT-system som stödjer processerna har svårt att ändras i samma takt. De sitter fast i en IT-arkitektur som är svår och dyr att förändra.

Problemet är välkänt. Ändå finns det förvånansvärt få metoder för att uppskatta kostnaderna för – och riskerna med – stora IT-förändringsprojekt. Men nu har forskare vid Institutionen för Industriella informations- och styrsystem på KTH tagit tag i saken, och skapat en modell (Kostnadsmodellen) – och ett verktyg (TEAMATe) för ändamålet.

Kostnadsmodellen, som har tagit tre år att arbeta fram, är baserad på tidigare forskning inom EA-området (enterprise architecture) samt på intervjuer med experter. Dessutom har den testats vid fyra nordiska företag.

TEAMATe (The Enterprise Architecture Modifiability Analysis Tool) bygger på den tidigare omskrivna KTH-metoden för Enterprise Architecture som visualiserar sambandet mellan verksamhetsarkitektur (EA) och beslutsfattande.

Det modellen har ”lärt sig” är att räkna ut ett estimat för projektkostnaden uttryckt i mantimmar. Dessa timmar kan sedan överättas till kronor baserat på tim­taxor hos respektive företag. I artikeln redogör vi för hur den har fungerat i 15 projekt i de fyra företagen – alla större än 2 000 mantimmar.

Fallstudie 1

Fallstudie nummer ett (1) genomfördes på ett nordiskt konsultbolag, startat 1993 och ledande inom product data management (PDM) med relaterade områden. Två förändringsprojekt studerades med hjälp av modellen (projekt A och B). Projekten ifråga leddes av konsultbolaget, men förändringsarbetet i sig implementerades på ett stort IT-företag av en underleverantör. Vi tittar lite närmare på projekt A.

Projekt A kostade i slutändan ca 20 000 mantimmar, varav 6 800 timmar användes till arkitekturförändringar medan 13 200 timmar spenderades på förändringar på komponentnivå.

De allra största kostnadsposterna för projekt A var utvecklings- och testkostnader för komponentförändringarna, medan den minsta kostnadsposten var inlärningskostnaden för arkitekturförändringarna.

Som vi kan se i tabellen estimerade modellen projekt
A till 19 860 mantimmar. Detta gav en differens på endast 1 procent. Vi kunde också se i modellen att de tekniska förändringarna av komponenter var både svåra och stora. Det var alltså inte överraskande att de största kostnadsposterna var just utvecklings- och testkostnader.

Fallstudie 2

Fallstudie nummer två (2) genomfördes på ett stort nordiskt tillverkningsföretag i transportbranschen. Företaget är aktivt i cirka 100 länder och har över 30 000 anställda. Sju förändringsprojekt studerades med hjälp av modellen (projekt C, D, E, F, G, H, I). Vi använder oss här av projekt F som exempel.

Projekt F initierades eftersom företaget prognostiserade en ökad försäljning av sina produkter. För att kunna hantera denna ökning behövde man tillföra ny funktionalitet i sin produktportal. Projektet omfattade dessutom implementering av en uppsättning icke-funktionella krav, som högre säkerhet och redundans.

Genom att studera modellen av projekt F kunde vi se att de största riskerna låg i följande tre faktorer: i bristande expertis hos utvecklarna, eftersom de bara hade upp till ett års erfarenhet; i resursplanering av arkitekterna, då de bara fick lägga upp till 20 procent av sin tid på projektet; samt i att de inblandade systemen var relativt tätt ihopkopplade. Till detta hörde även att förändringsprocessen endast nådde mognadsnivå 1 på en femgradig skala.

Projekt F estimerades av modellen till 15 230 mantimmar, och slutkostnaden landade på hela 20 000 mantimmar. I detta osäkra fall uppvisade modellen alltså en träffsäkerhet på 76 procent.

Fallstudie 3

Fallstudie nummer tre (3) genomfördes på ett stort företag som utvecklar både mjukvara och hårdvara. Företaget är världsledande inom sitt tilllämpningsområde. De har över100 000 anställda samt kunder eller lokala distributörer i fler än 100 länder. Två förändringsprojekt studerades med hjälp av modellen (projekt J och K). Båda utfördes av en utvecklingsavdelning på företaget eftersom syftet i båda fallen var att modifiera en standardprodukt för att kunna möta en ny kunds unika krav. Nu tittar vi närmare på projekt K.

Projekt K estimerades av projektledaren till cirka 800 mantimmar. I modellen estimerades istället projektkostnaden till 3 085 mantimmar. Med facit i hand visade det sig att modellen lyckades bäst – den verkliga kostnaden blev cirka 3 200 timmar. Modellen avvek alltså bara med 4 procent från slutkostnaden, medan projektledarens eget estimat avvek med hela 75 procent.

Fallstudie 4

Fallstudie nummer fyra (4) genomfördes slutligen på ett stort nordiskt transportbolag som erbjuder tjänster först och främst i ett av de nordiska länderna, men även i några angränsande länder. Företaget har över hundra miljoner passagerare varje år och flera tusen medarbetare. Fyra förändringsprojekt studerades med hjälp av modellen (projekt L, M, N, O). Nedan presenterar vi projekt L lite närmare.

Projekt L handlade om att bygga om företagets biljettportal så den blev mer användarvänlig samt förbättra funktioner som sökning av resor, val av biljettyp och utskrift av pdf-biljetter. Projektet omfattade även en hel del integrationsarbete mellan webbshoppen och sex mer eller mindre centrala system.

En sak vi kunde se med hjälp av modellen av projekt L var att de sju system som var inblandade i förändrings­arbetet var tätt sammankopplade inbördes. Risker relaterade till dessa kopplingar kunde lätt identifieras – som att ändringar skulle kunna sprida sig och kräva arbete i flera av systemen. Modellen synliggjorde värdena för de sju systemens kostnadsfaktorer (begriplighet, intern och extern kopplingsgrad, storlek och komplexitet). Här gick det att utläsa att flera system inte bara var tätt sammankopplade, utan också stora och komplexa. Baserat på dessa insikter kring potentiella risker i projektet kunde en noggrannare planering genomföras.

Projekt L i fallstudie nummer fyra estimerades till 5 510 mantimmar, vilket ska jämföras med den verkliga slutkostnaden som blev 5 810 timmar. Det estimerade värdet hade alltså en noggrannhet på 95 procent.

Resultat

Baserat på de 15 projekt som studerades hos de fyra företagen kan vi konstatera att modellen klarar av att estimera förändringskostnader med hög precision. Tabellen på föregående uppslag visar att samtliga 15 projekt estimerades inom 69 procents exakthet och att mer än hälften (9 av 15) hade en precision på över 90 procent. Användarna är också nöjda med modellens möjlighet att påvisa risker i projektplaneringsfasen. En tydlig fördel är att kunskap som tidigare varit gömd hos en person kunnat synliggöras för hela projektet i modellen.

Kostnadsmodellen är alltså ett smart verktyg för den som vill uppskatta IT-förändringens kostnader och risker på ett stukturerat sätt. Modellen består av ett antal entiteter/objekt som ska modelleras samt egenskaper knutna till dem, här uttryckta som kostnadsdrivande faktorer.

Ett projekt delas upp i olika beståndsdelar, eller aktiviteter – det kan vara kravhantering, design, utveckling, testning eller liknande – vilka i sin tur bryts ned i konkreta förändringar. För varje sådan aktivitet estimerar modellen så en kostnad i mantimmar. Aktiviteterna innehåller per definition ett antal kostnadsdrivande faktorer. En faktor är ”synkroniseringsbehov” som i modellen avser den andel av den totala tiden för en aktivitet som perso­nalen tillägnar synkronisering av sitt arbete med andra beroende aktiviteter. Även ”förändringskomplexitet” och ”förändringsstorlek” är två faktorer som anges.

Kopplat till IT kan man säga att förändringarna implementeras i IT-system bestående av mjukvarukomponenter, där varje komponent i sig innehåller en uppsättning kostnadsdrivande faktorer. De mest framträdande faktorerna är storlek, komplexitet, andel kopplingar (internt och externt) och begriplighet. Vissa av dessa kan mätas med olika verktyg, exempelvis ”komponentstorlek” eller ”antalet kopplingar en komponent har inom sig själv eller till andra komponenter”. Andra faktorer uppskattas bättre av projektdeltagarna, exempelvis de mer subjektiva faktorerna ”komplexitet” och ”begriplighet”.
 
En viktig del av förändringsarbetet
är den process som stöttar projektet. Denna stödprocess för förändringshantering ska vara mogen, vilket betyder att den ska ha väl etablerade och inarbetade rutiner. Till exempel ska tydliga roller vara fördelade, mätetal för uppföljning definierade och rätt uppsättning dokument tillgängliga.
I varje projekt finns också en organisation som utför förändringsarbetet. Modellen fokuserar på de arkitekter och utvecklare som ingår i detta arbete. Det finns två kostnadsdrivande faktorer för dessa personer: dels deras expertis, dels hur stor del av sin tid de spenderar i det specifika projektet. Expertis mäts i modellen av (i) det antal år som en person har erfarenhet av förändrings­arbete generellt, (ii) kunskap om de språk som används för utveckling och design, samt (iii) kunskap om de system i vilka ändringarna ska utföras.

Eftersom mycket design- och utvecklingsarbete görs av konsulter och det är hög omsättning på IT-personal, är dokumentationen ofta det enda sättet att sätta sig in i hur ett system fungerar. I modellen ligger fokus därför på att mäta kvaliteten på dokumentationen.
Både arkitekter och utvecklare använder verktyg för att underlätta det dagliga arbetet. Det kan vara verktyg för design av mjukvaruarkitektur eller programmeringsstöd. De plattformar som de inblandade systemen kör på utgör också en viktig del av förändringsmiljön. Det kan vara operativsystem som Windows och Linux eller mjukvaruplattformar som Java JDK eller .Net. Modellen tar hänsyn till aspekter relaterade till dessa och verktyg där kvaliteten är en betydelsefull faktor att ta hänsyn till.

Kostnadsmodellen bygger som nämnts på KTH-metoden. Vilka objekt och faktorer som är väsentliga för modellering vad avser kostnadsestimering och riskanalys har hämtats från en mix av forskning och praktiska erfarenheter. Först var modellen helt baserad på ett 50-tal forskningsartiklar, men efter att ha testats i verkligheten skedde vissa justeringar. Sedan har fortsatta iterationer resulterat i den version som föreligger här. ]

Fakta

TEAMATe bygger på ”KTH-metoden för Enterprise Architecture” som kopplar ihop EA med beslutsfattande. Som de flesta EA-modeller visualiserar KTH-metoden en organisations övergripande arkitektur, exempelvis system, nätverk, servrar, processer samt organisatoriska enheter och hur de hänger ihop. Men utöver detta visar den hur egenskaper i de olika arkitekturelementen påverkar varandra. Så om du är intresserad av att se hur kostnaden för ett förändringsprojekt är beroende av tillkomsten av nya krav, passar KTH-metoden bra! Modellen innehåller följande steg.

1. Bestäm vad som ska utvärderas. Detta beror på vad som är intressant i en beslutssituationen. Det kan vara IT-egenskaper, IT-organisationsmognad, eller den affärsnytta som IT ger. I fallet för förändringskostnader kan man resonera i termer av kategorierna som presenteras ovan, IT-egenskaper kan uttryckas i termer av funktioner och icke-funktionella egenskaper som till säkerhet eller användarvänlighet, och IT-organisationens mognad kan mätas med ramverket COBIT.

2. Skapa ett ramverk. Bryt ner det som ska utvärderas via kausalrelationer; faktorer som påverkar det som ska utvärderas. Gör detta tills du har kvantitativa och mätbara faktorer. Till exempel påverkas begripligheten hos ett IT-system av hur komplext och stort det är.

3. Skapa ett modelleringsspråk. Tag faktorerna i analysramverket från punkt 2 och gör om dem till entiteter/objekt i ett modelleringsspråk, till exempel organisationsenheter, processer och IT-stöd.

4. Modellera. Använd modelleringsspråket för att modellera
relevanta saker för att kunna fatta ett beslut. Modellera till exempel
system och dokumentation för att utvärdera modifierbarhet.

5. Analysera. Applicera utvärderingsramverk på modellen och gör kvantitativ utvärdering. Till exempel att en viss förändring av ett system ger en hög kostnad med 90 procents sannolikhet.

6. Fatta beslut!