It på armlängds avstånd – ingen bra idé

I mer än tio år har jag arbetat med det som ibland kallas för legacy-problem. Ordet legacy kan leda tankarna fel, eftersom det betyder arv och ett arv är ju något som de flesta skulle bli glada av att ha – men i detta sammanhang är det istället synonymt med problem och svårigheter. Det arv som företagen har att förvalta tynger ner, förhalar och ibland helt förhindrar innovation och utveckling.

På ytan råder en märklig paradox. Om man läser i tidningar eller ser sig om i världen kan man se att all it-utveckling går snabbt och dessutom tycks gå allt snabbare. Inte nog med det, teknik blir billigare och billigare. Det du köpt för 18 månader sedan finns nu tillgängligt för halva priset. Men hur många känner igen denna situation när de tittar på sitt eget företag? Har ni en it-verksamhet som levererar allt snabbare och billigare, så snabbt och billigt att verksamheten ibland måste be dem sakta ner, så att ni kan hänga med?

Om jag ser på de större företag, organisation och myndigheter som jag arbetar för, så går utvecklingen förtvivlat långsamt. Allt mer pengar måste stoppas in i budgeten bara för att kunna behålla det du redan betalt för och använder. Förvaltning, drift och underhåll tar en absurt stor del av budgeten, så att det nästan inte finns något alls kvar för att göra mer än små stegvis tillägg.

Det går dessutom så långsamt, att i stort sett alla organisationer jag arbetat med har it-lösningar som it-avdelningen inte varit med om att ta fram och kanske inte ens är informerade om att de finns. Verksamheten har gett upp och rundar it-avdelningen genom att själv hoppa rakt in i denna nya sköna värld med mobila molntjänster, sociala medier och datakonst.
Hur blev det så?

Flera orsaker
Jag anser att orsaken kan sökas i ett par olika områden. För det första så var det ingen som tänkte på sociala medier när företagens centrala system skapades för 30 år sedan, vilket givetvis inte är speciellt konstigt, men det var heller ingen som tänkte på att systemen skulle komma att utsättas för ett väldigt stort förändringstryck. Systemen designades inte för stor förändring och inte var det heller någon som tänkte på att dessa system en dag skulle behöva ersättas.

Om någon gjort det, hade vi i dag garanterat sett helt andra systemlandskap sammansatta på ett helt annat sätt. Det är ju som att bygga en stad bara med betong, där alla byggnader sitter fast förankrade i varandra med armeringsjärn som binder samman det ena huset med nästa. Hur ska du i en sådan stad kunna byta ut några hus i mitten, utan att ha sönder resten?

Den andra orsaken har med ledning och styrning att göra. Om vi ser på större organisationers sätt att styra sin it-verksamhet är det fortfarande så att många hanterar it på armlängds avstånd. Ledningen känner att detta är ett område som de helt enkelt inte förstår och kombinerat med att it väldigt ofta ses som en kostnadspost blir styrningen inte sällan en uppgift CFO skall hantera, dessutom lite vid sidan av.

Teknisk skuld
Ett intressant exempel kan vara ett riktigt stort företag med verksamhet i stora delar av världen. För några år sedan ledde jag ett arbete som, om man skall förenkla det, gick ut på att byta operativsystem. Man hade kommit till ett läge att man absolut inte kunde fortsätta med det man hade då det helt enkelt blockerade för vidare affärsexpansion. It-avdelningen hade flaggat för ett byte under mer än tio år, men varje gång man ville öppna upp för det i it-budgeten hamnade man i en prioriteringsövning som skulle väga ett projekt som var dyrt, riskfyllt och med väldigt lite kortsiktig verksamhetsnytta mot projekt som direkt skapade synligt resultat på sista raden.

Varje år fick man frågan ”Ok, jag förstår att vi förr eller senare måste byta, men vad händer om vi väntar ett år?” Det enda svar man kunde komma på var ”Inget”. Detta svar var faktiskt helt fel, då det kom att kosta flera tiotals miljoner mer än om man hade gjort bytet i tid. Förvisso hände det inget synligt det kommande året eller åren, men det man i praktiken gjorde var att addera ytterligare till sin tekniska skuld.

Vad är då en ”teknisk skuld”, tror jag att de flesta undrar nu. Jo, teknisk skuld är ett fiktivt mått som visar hur eftersatt ett system är. På samma sätt som att ditt hus kommer att förfalla om du inte avsätter pengar på att underhålla det och ibland byta ut delar av det, kommer dina system att förfalla. Precis som en fördröjd renovering kostar mer ju längre du väntar, kommer den tekniska skulden att öka om du väntar, dessutom med ränta på ränta.
Den tekniska skulden gestaltar sig i form av ökade kostnader och allt sämre förändringsförmåga, vilka båda faller tillbaka på en ökande komplexitet och minskat navigeringsutrymme. Om man inte aktivt arbetar med att minska komplexiteten i system och systemlandskap, kommer den – alldeles av sig själv – att öka.

Hur många organisationer tar hänsyn till detta i sin styrning av verksamhetsutvecklingen?

Vad kan du då som CFO göra i praktiken, om du redan sitter med problemet? Jo:

  • Kräv att varje projekt som lägger till ett system, också tar bort minst ett. Projekt är inte klara innan de har städat efter sig.
  • Sätt ett ”bäst-före”-datum på dina system, redan den dagen ett system går i drift. Tio år kanske är en rimlig gräns. Planera på detta sätt för ersättning av systemen långt innan det blir akut.
  • Kräv att din förvaltningsorganisation visar att de varje år minskar den tekniska skulden för just de system de äger.

När det gäller den tekniska skulden kan man mäta på lite olika sätt. Ett kan vara att man mäter tiden från uppkommet verksamhetsbehov till fullt genomförd förändring. Om detta minskar är man på rätt väg.

Vid en outsourcing är det extra viktigt – ni vill ju inte komma i ett läge när ni efter fem år tar tillbaka systemet eller byter leverantör och upptäcker att det är risigare och sämre. På samma sätt som en fastighetsförvaltare inte förväntas lämna tillbaka ett hus som lappats och lagats på billigaste sätt och där allt bakom den fina fasaden hålls ihop med silvertejp.

Om ni aktivt arbetar med minskning av komplexitet, modernisering och teknisk skuld kommer ni inte bara att ha enklare att hänga med i – eller kanske leda – den digitala utvecklingen i er bransch. Ni kommer också att skapa kostnadsfördelar i form av minskade kostnader i verksamheten och minskad risk i projekt. Det är ju faktiskt så att en alltför stor del av alla projekt med it-inslag misslyckas, i form av att de blir dyrare, försenade eller levererar mindre värde än tänkt.

Enligt en studie från Standish Group från 2011 lyckas bara 34 procent av it-projekten, en siffra som i stort sett inte ändrats på mer än ett decennium. Ser man samtidigt på potentialen för verksamhetseffektivisering är den idag väldigt stor i alla större organisationer jag arbetar med.

När vissa laborerar med saker som avancerat maskinlärande som stöd till läkare hanterar andra fortfarande delar av sin administration på papper eller i bästa fall i Excel. Jag vet en CFO som kör en skuggfakturering varje månad i Excel. Och varje månad upptäcker hon fel i den riktiga faktureringen, vilket så klart är ett problem, men det är ett otroligt slöseri med högkvalificerad personals tid och kompetens.

Det är dessutom hög tid att sluta betrakta it som en kostnadspost som med alla medel ska minimeras. Billiga lösningar tenderar att bli just billiga i första hand, och då kan kvaliteten så klart bli lidande, liksom sådan som bara har en effekt på lång sikt. Den dagen ditt företag lyckas få in it ”i finrummet” har ni kommit närmre it som aktiv del i verksamhetsutvecklingen.

Sedan skall du nog försöka få de som designar it-lösningar att inte bara tänka funktion, kapacitet och svarstid, utan också tänka i termer av verksamhetseffekt, förändringshastighet, ombytlighet och förutsägbarhet.
Och så var det ju det där med teknisk skuld…

Om skribenten: Joakim Lindbom är expert inom it-arkitektur på Capgemini och gästkrönikör i CFOworld.