Du kan TCO. Men har du koll på TCI?
När vi pratar om kostnaden för integrationer hamnar fokus nästan alltid på själva projektet. Vad kostar det att koppla ihop systemen? Hur lång tid tar det? Hur många konsulttimmar behövs?
Det är naturliga frågor. Problemet är bara att de säger ganska lite om vad integrationen faktiskt kommer att kosta över tid.
Det här är något jag ofta kommer tillbaka till efter möten med företag som har många integrationer, men där ingen riktigt har hela bilden av vad de kostar att äga och förvalta.
För när integrationen väl är byggd börjar nästa del. System uppgraderas. API:er ändras. Certifikat löper ut. Incidenter behöver felsökas. Nya system ska in och gamla ska bort. Bolag köps upp, verksamheter slås ihop och nya kunder eller partners kommer med lösningar som ingen hade räknat med från början. Samtidigt behöver någon ha koll på helheten och avgöra hur integrationslandskapet ska utvecklas när verksamheten förändras.
Allt det där kostar också. Och ändå är det ofta bara kostnaden för själva bygget som är tydligt synlig.
Det är här jag tycker att det kan vara användbart att prata om TCI – True Cost of Integrations.
TCI är inget etablerat ekonomiskt nyckeltal på samma sätt som TCO, och det behöver det kanske inte heller vara. För mig är det framför allt ett sätt att påminna om att integrationskostnaden inte slutar när projektet går live.
Projektkostnaden är bara en del av bilden
När en integration upphandlas eller byggs internt går det oftast ganska lätt att se den initiala kostnaden. Det finns utvecklingstimmar, konsultkostnader, testning, projektledning och driftsättning. Det finns en budget, ett projekt och ofta en ganska tydlig slutsumma.
Det som händer därefter är svårare att få grepp om.
Integrationer ska övervakas och förvaltas. Fel ska hanteras. Förändringar i anslutna system ska analyseras, utvecklas och testas. Ibland krävs mindre justeringar, ibland betydligt större insatser.
Och kostnaderna hamnar inte alltid på samma ställe.
En del syns som konsultkostnader. En del ligger i interna team och försvinner in i lönekostnaden. En del märks först när en förändring tar längre tid än planerat eftersom någon först måste reda ut vad en gammal integration faktiskt gör.
Det är sällan någon enskild post som sticker ut, men när man summerar flera år och många integrationer börjar det bli pengar av det.
Tre kostnader du behöver ha koll på
Jag brukar tänka på integrationens verkliga kostnad i tre delar:
1. Build – kostnaden för att bygga
Det här är den del vi oftast har bäst koll på.
Analys, design, utveckling, test och driftsättning. Det är den synliga kostnaden och också den som brukar vara enklast att jämföra mellan olika alternativ.
2. Run – kostnaden för att hålla integrationen igång
När integrationen väl är i produktion börjar förvaltningen.
Övervakning, incidenthantering, felsökning, säkerhetsuppdateringar, certifikat, support och löpande underhåll kostar tid och pengar.
Det här arbetet är nödvändigt, men eftersom det ofta är utspritt över olika team och budgetar är det betydligt svårare att få en samlad bild av kostnaden.
3. Govern – kostnaden för att äga och utveckla
Det här är den del som jag tror att många underskattar.
Ett integrationslandskap behöver inte bara fungera här och nu. Någon behöver också äga helheten och se till att det fortsätter stödja verksamheten när förutsättningarna förändras.
Ett affärssystem byts ut. Ett API får en ny version. Företaget gör ett förvärv. En ny marknad ska öppnas. En kund eller partner använder ett system som inte passar in i det befintliga upplägget. Då behövs beslut om vad som ska ändras, vad som kan återanvändas och hur nya behov ska passa in i den befintliga arkitekturen. Det är den typen av löpande ägarskap jag menar med Govern.
Förändring är alltså inte något tillfälligt störningsmoment i ett integrationslandskap. Det är en del av vardagen. Och om ingen har ansvar för helheten är risken stor att varje förändring blir ännu en speciallösning.
Build + Run + Govern är tillsammans det jag menar med TCI: vad integrationerna faktiskt kostar att bygga, driva och äga över tid.
Den största kostnaden syns ibland inte alls
Det finns också en annan kostnad som sällan syns tydligt i någon kalkyl: vad organisationen hade kunnat göra med tiden i stället.
Om erfarna utvecklare lägger mycket tid på att felsöka gamla integrationer, anpassa punkt-till-punkt-lösningar eller hantera specialfall, då är det inte bara en lönekostnad.
Det är också kapacitet som inte läggs på annat.
Jag menar inte att integrationsarbete i sig är slöseri med tid. Integration är helt avgörande i de flesta moderna verksamheter.
Men det är skillnad på att lägga tid på att utveckla och styra en gemensam, återanvändbar integrationsförmåga och att gång på gång lägga tid på att hålla en mängd individuella lösningar vid liv.
Det är den skillnaden jag tycker är viktig att få syn på.
Billigast att bygga är inte alltid billigast att äga
Det här gör också att det blir ganska vanskligt att jämföra integrationsalternativ enbart utifrån vad de kostar att bygga.
- En lösning kan vara billig och snabb att få på plats, men kräva mycket handpåläggning varje gång något förändras.
- En annan kan kosta mer initialt men vara betydligt enklare att förvalta, återanvända och anpassa när verksamheten förändras.
På så sätt är resonemanget egentligen ganska likt TCO. Skillnaden är att integrationskostnader ofta är svårare att samla ihop. De ligger på olika ställen i organisationen och uppstår vid olika tidpunkter.
Vad händer när integrationslandskapet växer?
Har man fem eller tio integrationer kan en ganska projektorienterad modell fungera alldeles utmärkt.
Det går att hålla mycket i huvudet. Någon vet hur kopplingarna fungerar. När något behöver ändras går det ofta att lösa.
Men vid femtio, hundra eller flera hundra integrationer ser situationen annorlunda ut. Då börjar varje ny speciallösning lägga ytterligare lite förvaltning ovanpå det som redan finns. Samtidigt blir behovet av gemensamma principer, överblick och tydligt ägarskap större. Annars riskerar integrationslandskapet att utvecklas som summan av enskilda projekt snarare än som en sammanhängande förmåga.
Och någonstans där brukar frågan förändras.
Det handlar inte längre bara om:
Hur snabbt kan vi bygga nästa integration?
Utan snarare:
Hur bygger vi så att vi faktiskt kan leva med det vi skapar när verksamheten fortsätter att förändras?
Det är en betydligt viktigare fråga.
Få med hela kostnaden i diskussionen
Jag tror inte nödvändigtvis att TCI behöver bli ännu en förkortning på en KPI-dashboard. Men jag tror att fler organisationer skulle må bra av att ställa några ganska enkla frågor:
- Vad kostar våra integrationer att bygga?
- Vad kostar de att driva?
- Vad kostar det att äga och utveckla integrationslandskapet när verksamheten förändras?
- Hur mycket intern tid går åt till att förstå, felsöka och anpassa det som redan finns?
- Och vem har egentligen ansvar för helheten?
Den sista frågan tycker jag är minst lika viktig som de andra.
För i många organisationer finns det gott om människor som ansvarar för enskilda system, projekt eller integrationer. Det är betydligt mer ovanligt att någon faktiskt äger bilden av integrationslandskapet som helhet.
När man börjar titta på den bilden blir det också lättare att se vad som är dyrt på riktigt. Och då kan en lösning som såg billig ut i projektbudgeten visa sig vara ganska dyr att leva med.
Hur ser det ut hos er?
Om du känner igen resonemanget och vill diskutera hur integrationskostnaderna ser ut hos er – och hur ni kan få bättre kontroll på ägarskapet över tid – hör gärna av dig!
