Kan arkitektarbete motiveras i pengar?

Peter Tallungs & Håkan Edvinsson fredag 22 feb 13


EA Verksamhetsarkitekter vill ofta ha råd om hur man motiverar en arkitektursatsning för en ledning. Vanligen förväntas man i förväg visa hur man räknar hem arkitektarbetet i pengar.

Man vill ha en ”Return of Investment”, ROI, eller investeringskalkyl på svenska. Man vill veta hur en arkitektursatsning lönar sig om man ställer den mot andra saker man kan göra för pengarna. Men själva frågeställningen är knepig.

Varför det är svårt

Om man ska kunna räkna på en satsning på det sättet krävs det ett realistiskt nollalternativ att jämföra med. Investeringskalkyl lämpar sig väl vid rationalisering, det vill säga där man planerar göra samma sak som idag fast på ett nytt sätt. Ska vi köpa en ny pappersmaskin eller fortsätta med den gamla? Ska vi hyra in personal eller fortsätta med anställda?

Men en arkitektursatsning är inte ett annat sätt att göra samma sak som tidigare. Det är att ta steget till ett nytt synsätt på verksamhet, med det gemensamma lärandet i centrum. Det är en ny spelplan. Det låter kanske mer dramatiskt än det är. Det är i själva verket en mognadsprocess i små steg.

Arkitekturarbetet är ett löpande strategiskt fokus för alla i verksamheten. Det är att bygga en gemensam förståelsen av var vi är och vart vi vill komma, och hur vi kommer dit. Det är egentligen i grunden inget man kan välja in eller välja bort. Man kan bara välja att göra den aspekten av verksamheten – hanteringen av strukturkapitalet - mer synlig och hanterbar, eller lita till att det löser sig magiskt ändå. Där har vi visserligen två alternativ, men de är genomgripande och svåra att koka ner till särkostnad och särintäkt.

Man brukar inte kräva att man visar ROI för andra liknande aktiviteter som affärsplanering, uppföljning, portföljhantering etcetera. Anledningen är att det är saker som man egentligen inte kan välja om man ska göra utan sådant som man helt enkelt måste göra om man vill ha en verksamhet. Varifrån kommer då föreställningen att just arkitektarbete behöver kunna räknas hem, på samma enkla sätt som en rationalisering?

Varför efterfrågas ROI?

En anledning kan vara att hela arkitektdisciplinen har sitt ursprung inom it-området, och informationsteknik länge handlade om rationalisering, om automatisering av manuellt arbete. Och rationalisering är just investeringskalkylens hemmaplan. När man ska göra samma sak på ett nytt sätt är det mycket lämpligt, och ganska rättframt att räkna på om investeringen lönar sig eller inte.

Sedan är det en annan sak att arbetet med informationsteknik idag är så mycket mer än att göra samma sak som tidigare, fast automatiserat. Det handlar numera i hög grad om att göra saker som man alls inte kan göra utan tekniken.

Men vi kan ändå inte bortse från kravet att påvisa värdet av vårt arbete. Vi måste ändå tala kundens språk, berätta i konkreta termer vad vi bidrar med. Låt oss titta på det. Det värde arkitekturarbetet kan ge kan uttryckas på många olika sätt. Låt oss börja med den mest allmänna beskrivningen.

Användbar kunskap och ett gemensamt språk

EA-arbete bygger upp en tillgänglig och användbar kunskap om verksamheten och ett gemensamt språk för verksamheten.

Arkitektarbetet handlar i grunden om att utforska och dokumentera verksamhetens olika aspekter som arbetsflöden och processer, funktioner och it-system. Vi arbetar med att kartlägga strukturer, begrepp, information och data för de företeelser som verksamheten hanterar som kunder och andra intressenter, produkter och tjänster, ärenden med mera.

För allt detta utvecklar man ett gemensamt språk med begrepp, definitioner och benämningar. Man fångar verksamhetslogiken och gör den hanterbar och tillgänglig.

Det ger nytta i alla sammanhang och vid alla tillfällen då någon intressent behöver förstå och kommunicera om verksamheten; hur verksamheten fungerar idag, hur man vill att den ska fungera i framtiden. Ledningen vill kunna låta förändringar ske och vill kunna kommunicera vad det innebär både till dem som tar del av förändringen och till dem som ska få förändringen att ske.

Denna aspekt på arkitektarbetet handlar om dess möjlighet som ett kraftfullt tanke- och kommunikationsverktyg och som verktyg för kunskaps- och ändringshantering.

Verksamheter är mycket komplexa företeelser att förstå, så snart man lämnar det mest ytliga planet.

Det är möjligt att det vi kallar verksamheter är de mest komplicerade konstruktioner som skapats av människor. Orsaken till komplexiteten är att en verksamhet är sammansatt av många olika företeelser av helt olika natur som organisationsenheter, roller, ting, processer, mål, policys, regler, händelser, lokaliteter, anläggningar, produkter och tjänster, data, information, it-system med mera.

Och inte minst - det som riktigt gör det intressant – människor i samverkan. För alla organisationer, utom de allra enklaste, är det omöjligt att arbeta med alla dessa variabler och få till meningsfull utveckling utan någon form av strukturerad ansats. Det är just det vi kallar arkitektarbete.

Om man går med på ovanstående, torde det vara lätt att inse, att arkitektarbete är en nödvändig del av strategi-, styrnings- och kunskapsarbetet i varje organisation som inte vill agera i blindo.

Men går det att uttrycka i pengar, hur mycket det är värt att adressera arkitekturfrågor på ett strukturerat sätt, i stället för att lita till att det löser sig magiskt? Nej, knappast. Inte om vi talar om nyttoeffekterna i dessa allmänna termer i varje fall. Låt oss därför titta på något mera specifika nyttor.

EA-arbete ger möjlighet att standardisera processer

Ofta gör man samma saker på flera olika ställen i en verksamhet och gör det på olika sätt. Man kan då behöva standardisera hur man gör, det vill säga arbeta på ett mer enhetligt sätt, för att lättare kunna styra och följa upp arbetssättet.

Även om man inte vill standardisera processerna kanske man i varje fall vill dra nytta av en gemensam infrastruktur. Hur man än gör kräver denna kartläggning och hantering av verksamhetens processer information, begrepp och språk.

Vi talar nu om en del av nyttan av arkitektarbetet och i mer konkreta termer. Om man snävar in på en specifik satsning, rationalisering av en viss process, eller etableringen av en gemensam infrastruktur är det möjligt att räkna på just den. Men då har vi svårigheten att arkitektarbetet i sig inte är hela kostnaden för rationaliseringen utan endast en mindre del. Och samtidigt är det troligt att det arkitekturarbete man gör i samband med just denna satsning är till nytta även i kommande satsningar.

EA-arbete ger möjlighet att integrera och dela information

Vanligen behöver man dela information mellan funktioner, processer och applikationer. Det kan vara inom en verksamhet eller mellan olika verksamheter. Detta gäller per definition för sådan information som är en gemensam referensram för annan information, så kallad masterdata. Men man behöver också dela händelsedata, att en process behöver veta vad som hänt i en annan process.

Och om man vill monitorera sina verksamhetsprocesser behöver man samla och konsolidera information från många källor.

Därmed behövs en gemensam hantering och ett strukturerat utbyte av information. Det förutsätter att man kan skapa gemensamma begrepp och språk tvärs över en verksamhet eller flera. Gemensamma begrepp och språk är också en förutsättning för att uttrycka och kommunicera verksamhetsregler och mätetal på ett klart och tydligt sätt.

Allt detta adresseras av ännu relativt omogna discipliner inom informationsområdet som Integrationsarkitektur, Master Data Management, Information Management och Business Intelligence. En springande punkt är just att skapa en gemensam förståelse och ett gemensamt språk bland alla intressenter för data, informationen och det den representerar i verkligheten. Det arbetet brukar vi kalla för Informationsarkitektur, och ser det som en underdisciplin till det stora verksamhetsarkitekturområdet.

Detta är en annan nytta av arkitektarbetet än den som handlar om standardisering av processer även om det finns kopplingar mellan de olika arbetena. Det är också en nytta som är uttryckt i lite mer konkreta termer. Även här är det möjligt att räkna på kostnad och nytta, så länge man håller sig till en specifik satsning. Men då har återigen svårigheten att arkitektarbetet i sig inte är hela kostnaden för att hantera datat och informationen utan bara en grund. Och även här är det troligt att det arkitektarbete man gör i samband med just denna satsning är till nytta även i kommande satsningar.

Nu har vi sett på två lite mer specifika uttryck för nyttan av EA. Ingendera ger oss någon enkel och direkt koppling mellan kostnad och intäkt och är därmed inte speciellt användbara för en investeringskalkyl. Låt oss prova en helt annan infallsvinkel.

EA-arbete kan minska ledtider, risk och kostnad för utveckling

EA-arbete kan minska ledtider, risk och kostnad för utveckling, genom att etablera verksamhetsmodeller (beskrivningar av verksamhetens element som är gemensamma).

Ett alternativt sätt att räkna på arkitektarbetet är att se på hur det underlättar utvecklingsarbetet. Traditionellt har varje it-system och verksamhetsförändring designats och utvecklats i ett eget projekt, helt utan att kunskap från tidigare utvecklingsprojekt har tagits till vara. Man har varje gång utgått från ett blankt papper.

Orsaken är att det inte funnits gemensam beskriven och tillgänglig kunskap om begrepp, data, information, verksamhetslogik, processer, teknik. Analytiker och designers i projekten har varje gång fått utgå från ett blankt papper och själva fått försöka fånga, förstå och skapa sina egna beskrivningar. Det gör att projekt äter mer tid och resurser, levererar sent, om de inte underlevererar eller misslyckas helt.

De som ändå slutförs, levererar stuprörslösningar som gör att olika delar av verksamheten inte kan samverka och som är dyra att underhålla, och svåra att vidareutveckla. Det är naturligtvis en misshushållning av stora mått. Det handlar inte bara om det direkta slöseriet, utan också om alla missade möjligheter.

Ett löpande arkitekturprogram kan ganska snabbt och enkelt bygga upp gemensamma beskrivningar och modeller, samt få projekt att samverka runt gemensam kunskap. Det är svårt att överskatta värdet av att organisationen på detta sätt kan förändras med större smidighet och precision, lättare anpassa sig till förändringar i omvärlden. Det är snarare ett villkor för organisationens existens i dagens turbulenta värld än något man kan eller behöver räkna på, kan man tycka.

En gemensam vision

EA-arbete kan skapa och förvalta en gemensam vision om framtiden som delas mellan verksamhets- och it-sida.

Allt vi tidigare har nämnt handlar om hur vi kan skapa ett gemensamt språk, en samsyn och en gemensam plattform för lärande och utveckling mellan alla intressenter. Det är något som hela tiden när det ständiga utvecklingsarbetet.

Men vi behöver också det långa perspektivet. Verksamhetsarkitekter omfamnar både it- och verksamhetsperspektiv. Verksamhetsarkitekter kan få it-folk och verksamhetsfolk att förstå varandra, och att arbeta mot samma långsiktiga mål.

Så här gör vi

Om vi är tvungna att räkna får vi göra så gott vi kan. Den ansats vi har använt ibland är att räkna på kostnad och värde av någon av de mer konkreta och närliggande nyttorna som känns viktiga för ledningen, och samtidigt göra klart att dessa endast är en del av det långsiktiga värdet och med all sannolikhet den minsta delen.

Exempel på hur du kan räkna

Hos en kund där vi arbetat var arkitektarbetet koncentrerat kring den stora uppgift som låg i fokus för verksamheten: att konsolidera stora mängder information i samband med ett Business Intelligence-program.

Läget var följande. Vi hade kommit långt med att bygga upp informationsarkitekturen och redan visat nytta i organisationen, fast ännu bara för en mindre del av företagets hela informationsresurs. Vi blev då ombedda att ta fram ett business case för det fortsatta arbetet, och där Return of Investment var den springande punkten. Ja, i praktiken var det det enda örat ledningen lyssnade på.

Vi insåg svårigheten men försökte ändå räkna på de aspekter som gick att räkna på.

Så här gick vi till väga

Vi beslöt att ta fasta på att vi som informationsarkitekter gav stöd till utvecklingsarbetet i organisationen, det vill säga den del av utvecklingsarbetet som krävde konsoliderad information.  Vårt antagande var att det var den delen av utvecklingsportföljen som vår satsning skulle ha den tydligaste effekten på.

Vi ville utgå från den utvecklingskostnaden. Först tog vi fram den samlade utvecklingskostnaden i organisationen. Det var lätt att få fram den kostnaden de senaste åren i form av ”Full Time Employees”, FTE, som arbetade med utveckling i någon form. Man fann troligt att man skulle ha ungefär samma utvecklingsbehov de närmaste åren. När man såg tillbaka på de senaste åren gjorde man uppskattningen att ungefär hälften av utvecklingsarbetet hade krävt konsoliderad information.

Samtidigt gjorde man bedömningen att den fördelningen skulle fortvara, i varje fall för de närmsta åren. I pipiline fanns Customer Resource Management, segmentering av kunder, riskhantering, lönsamhetsberäkning, integration, Business Intelligence, nya myndighetskrav med mera. Andelen utvecklingsarbete framöver som krävde konsoliderad information uppskattades således till 50 procent av det totala utvecklingsarbetet.

I nästa steg intervjuade vi nyckelpersoner som varit med i tidigare satsningar. Frågan var: Hur mycket tid och resurser skulle ni ha sparat om ni redan hade en gemensam konsoliderad information och gemensamma konsoliderade begrepp i verksamheten? Svaret blev att man skulle spara hela 60 procent av tid och kostnad, sammanvägt i hela satsningen. Man skulle spara tid och resurser i alla delar, i allt från krav, utveckling, test, och även i utbildning, dokumentation, förvaltning, användarstöd och applikationsdrift.

Svaret var pålitligt genom att vi redan hade hunnit en bra bit på väg med informationsarkitekturen i verksamheten. Respondenterna visste vad de talade om. De hade redan hunnit uppleva vad vi kunde bidra med, samtidigt som de hade tidigare mödor i färskt minne.

Det kanske är en förvånande stor siffra för en del, men alla som deltagit i informationstunga projekt vet hur mycket tid som går åt till att den del av arbetet som handlar om att få fram och löpande hantera, kommunicera och utveckla den gemensamma kunskapen och språket för verksamheten. Och hur liten del som egentligen handlar om teknik i sig.

På så sätt kom vi fram till att vi med ganska stor säkerhet kunde reducera kostnader och tid med 60 procent i hälften av allt utvecklingsarbete i organisationen. Det ger en besparing i utvecklingskostnad på 30 procent (det vill säga 60 % x 50 % = 30 %) av allt utvecklingsarbete i organisationen. Sedan var det inte uttalat hur man skulle ta hem den resursbesparingen, om man ville göra andra saker eller om man ville minska kostnad.

Det gav ett så starkt business case att det såg ut som en glädjekalkyl. Man fick nästan lust att frisera siffrorna nedåt. Men samtidigt hade vi redan visat vad vi kunde åstadkomma och hade starka röster, nyckelpersoner på både it- och verksamhetssidan, som intygade riktigheten i bedömningen.

Det understryker under att det viktigaste är att visa nytta först, innan man kommer och ber om pengar. Inget slår evidensbaserad utveckling, att först göra nytta, och sedan - utifrån resultatet - motivera mer av samma slag, eller liknande.  Vem tror på något de aldrig har sett och inte förstår? Och som jag inte själv kan garantera, för vem är jag att säga vad som fungerar i just denna organisation?

Samtidigt försökte vi betona att kalkylen egentligen var i grunden naiv. Den byggde på antagandet att vi bara skulle göra samma sak fast effektivare. Köra precis samma utvecklingsprojekt som man ändå skulle göra. Men arkitektarbetet kan i själva verket ge helt nya möjligheter. När man får tydliga gemensamma begrepp och synsätt öppnar sig nya möjligheter med det data man har. Det finns nya spelplaner man kan agera på. De stora vinsterna handlar inte om att göra samma som idag fast billigare, utan ligger i vad man kan göra som ligger utom räckvidd idag.

Det var till en början svårt att motivera ledningen, trots de fina siffrorna. Man ville hellre satsa på projekt som gav en direkt nytta som de förstod. Man ville göra sådant som direkt utvecklade affärsmöjligheterna, som till exempel Customer Resource Management. Men nyckelpersonerna som var direkt involverade i den typen av affärssatsningar försvarade arkitektarbetet med att det skulle ses som en nödvändig plattform, en infrastruktur, för dessa mer affärsinriktade satsningar. De sade att utan oss informationsarkitekter hade de varit tvungna att själva göra allt det vi gjorde, och de hade gjort det sämre.

Vi hade alltså inte lyckats sälja in arkitektarbetet direkt till ledningen, trots ett fantastiskt business case, som dessutom hade en hög trovärdighet genom att vi redan visat resultat.

I stället hade vi sålt in arkitektarbetet genom ombud, via de som kunde förstå, de som var mer direkt berörda av de nyttor vi kunde skapa, och som ledningen lyssnade på.

Den lärdom vi kan dra av detta kan kanske vara följande:

  1. Se till att göra nytta tidigt, påvisbar nytta, och att det finns nyckelpersoner i utvecklingsorganisationen som ser det.
  2. Motivera arkitektarbetet utifrån att det möjliggör affärsutvecklingen.
    Arkitektarbete handlar om infrastruktur, det vill säga inte teknisk infrastruktur, men dock infrastruktur. Det är inget man direkt kan tjäna pengar på. Det är som med järnväg. Att bygga spåren är dyrt och ger ingen vinst i sig. Det är först när man kör tåg man kan tjäna pengar. Se därför till att hänga på de mer affärsinriktade satsningarna.
  3. Om man kräver business case för arkitektarbetet, visa hur arkitektarbetet möjliggör affärsutvecklingen i mycket konkreta termer. Men visa samtidigt att det egentligen är endast en mindre del av nyttan som kan kvantifieras på detta sätt.

Vi tar gärna del av din erfarenhet. Hur har du gjort för att visa värdet av arkitektarbetet?

Den som skriver en kommentar i anslutning till artiklar på trendspaning.se är själv ansvarig för innehållet. Kommentarerna omfattas inte av yttrandefrihetsgrundlagen inom utgivningsbeviset för trendspaning.se.

Redaktionen förbehåller sig rätten att ta bort kommentarer som är olämpliga i enlighet med lagen om ansvar för elektroniska anslagstavlor.

Annons från dfkompetens.se
Visualisera verksamhetens förmågor
Synliggör värdeflödet
Läs mer på dfkompetens.se
Läs mer
Annons från dfkompetens.se
IT-arkitektur – en introduktion
Läs mer på dfkompetens.se
Läs mer