Sluta kalla allt som är gammalt ”teknisk skuld”

Sedan några år tillbaka har jag lagt märke till att många människor missbrukar begreppet ”teknisk skuld” och felaktigt tillämpar det på nästan allt som behöver uppdateras.

Trots att Shakespeare föraktade vikten av namngivning (”En cio skulle fortfarande ignoreras, oavsett vilket namn den hade”) är namngivning strategiskt avgörande inom företags-it.

Detta är inte bara klagomål från en gnällig journalist som skakar näven och skriker: ”Ord har betydelse, för tusan!” Det är verkligen ett problem. När leverantörer, it-chefer, konsulter eller någon annan slänger in allt från modernisering av äldre system, övergång till molnet, mobilteknik, virtualiserade miljöer, SaaS, agentbaserad integration och ombalansering av lokala system i samma korg som verklig teknisk skuld, skapar det förvirring kring frågan.

Ännu viktigare är att det antingen inte kommer att fungera alls, eller fungera betydligt mindre effektivt än det skulle kunna och borde, att stoppa in väldigt olika problem i en och samma kategori och sedan försöka lösa de skilda problemen med en enda metod.

Dessutom spelar denna tendens rakt i händerna på teknikleverantörerna, som älskar när kunderna felaktigt etiketterar saker, eftersom det gör det lättare för dem att öka försäljningen genom att utnyttja förvirringen. Tyvärr har inte IBM monopol på FUD som försäljningsstrategi. Det finns en mycket gammal kliché som innehåller en hel del sanning: När det enda verktyget i din verktygslåda är en hammare, ser alla dina problem ut som spikar.

Teknisk skuld är väldigt enkelt. Det är en legitim term för det som uppstår när utvecklare eller SOC-personal medvetet – och med ledningens fulla godkännande – tar en genväg på grund av budget- eller tidspress. De vet vad de gör, och det görs av legitima affärsskäl.

Det låter vanligtvis ungefär så här: ”Jag vet att det här inte är det rätta sättet att göra det på, men vi kan bara lägga X dollar på det här eller så måste vi få det klart inom två veckor, så låt oss ta genvägar och städa upp röran senare. Jag vet att det här sättet sannolikt kommer att kosta oss mer på lång sikt, men budgeten/tidsplanen går inte att ändra.”

Ett relativt nytt konsultföretag, Acceligence, använder olika termer för att korrekt beskriva två problem som ofta felaktigt betecknas som teknisk skuld.

1. Teknisk skuld är en medveten, godkänd genväg som tas av ett konkret affärsmässigt skäl, vanligtvis tid eller pengar.

2. Skuggteknisk skuld är en taktik för teknisk skuld, men det är en genväg som tas utan godkännande. Detta är ett allvarligare strategiskt problem än skugg-it, som vanligtvis är en liten, praktisk tillfällig lösning: en kreditkortsavgift för en snabb molninstans, eller att använda en router av konsumentklass eftersom den godkända företagsroutern dröjer en månad. Skugg-it medför sällan stora framtida kostnader för företaget. Skuggteknisk skuld gör det. Det handlar om att en person beslutar att företaget ska betala om ett år för en genväg som tas nu, utan att företaget vet att det har gått med på det.

3. Teknisk tyngdkraft. Det här handlar inte alls om genvägar. Det handlar om legitima – ofta dyra – inköpsbeslut som var helt lämpliga vid den tidpunkten, såsom stordatorer eller tidiga molnimplementeringar. Men tiden har hunnit ikapp dessa beslut. Tekniken förändras ständigt, och det är inget konstigt med att ändra, uppdatera eller modernisera inköp som gjordes år 2000 när det nu är 2026.

”Det går inte att betala tillbaka, eftersom det inte finns någon genväg att ta tillbaka det. Man kan bara undkomma det”, skrev Acceligence vd Justin Greis. ”Det beter sig mindre som en skuld än som tyngdkraften: en dragningskraft som skapas av massa, som verkar på allt, och som inte är någons fel.”

Greis, som myntat begreppet ”tech gravity”, säger att han har sett alla möjliga strategiska it-problem uppstå till följd av felaktig användning av begreppet ”teknisk skuld” för att beskriva denna situation.

– Teknisk skuld beskriver, enligt den ursprungliga avsikten, en medveten avvägning. Begreppet är användbart just därför att det är så specifikt, ,emar Greis.

– Ordet skuld innebär en antydan om fel, och det har snedvridit hur organisationer ser på sina egna system. Enligt min erfarenhet är teamen betydligt mer uppriktiga om vad de bär på när beskrivningen inte låter som en bekännelse.

Jag bad Greis att närmare förklara varför felanvändningen av detta begrepp skadar företagens strategier.

– Tänk på moderniseringsprogrammet som aldrig riktigt blir klart, säger han.

– En it-chef går till styrelsen med en flerårig plan för att fasa ut en kärnplattform, och eftersom det enda begreppet som finns tillgängligt är teknisk skuld presenteras planen som en skuld som ska arbetas bort över tid.

– Styrelsen godkänner den i princip, finansdirektören anslår medel för det första året på en nivå som känns försiktig, och arbetet inleds. Efter två år ligger programmet efter i tid, delvis därför att kärnsystemen alltid visar sig vara mer sammanflätade än inventeringen antydde och delvis därför att finansieringen aldrig räckte till för att flytta alla beroende system samtidigt.

– Ingen fattade ett felaktigt beslut. Problemet är att ett program som detta har en miniminivå för engagemang under vilken det inte kan slutföras, och skuldperspektivet gav it-chefen ingen möjlighet att påpeka detta. Varje begäran såg ut som en avbetalning på en skuld, så varje begäran förhandlades ned, och organisationen fick i slutändan betala för det dyraste möjliga utfallet, nämligen att fortsätta i all oändlighet utan att nå målet.

Ett annat problem som orsakas av felaktig användning av teknisk skuld är ett företag som moderniserar i ytterkanterna men stannar upp i mitten, säger han.

– Under fem eller sex år förnyar ett företag sina kundinriktade applikationer, flyttar sin analysverksamhet till molnet, byter ut sina samarbetsverktyg och rapporterar stadiga framsteg när det gäller sin tekniska skuld. Applikationsinventeringen visar att en majoritet av systemen har moderniserats.

– Vad inventeringen inte visar är att systemen under ytan – huvudboken, plattformen för försäkringsadministration, kärnbanksmotorn, orderhanteringssystemet – inte har flyttats, och att var och en av de nya applikationerna fortfarande är beroende av dem för sina data och transaktioner, säger Greis.

– När något i kärnsystemet förändras, bryter det moderna lagret samman. När verksamheten efterfrågar en ny funktion går svaret fortfarande via den gamla plattformen. Cio:n tvingas förklara för styrelsen varför moderniseringsgraden fortsätter att stiga samtidigt som riskprofilen, driftskostnaden och den tid det tar att leverera något nytt knappt har förändrats.

– Sett som en skuld ser det ut som ett program som inte lyckas betala av sin skuld. Sett som tyngdkraften är det precis vad man kan förvänta sig: dragkraften är starkast i mitten av systemlandskapet och svagast i kanterna, så kanterna rör sig först och mitten rör sig sist – om den överhuvudtaget rör sig. Perspektivet förändrar inte fakta, men det förändrar samtalet från “varför tar det så lång tid?” till “vad krävs egentligen för att få kärnan att röra sig”?

Det här argumentet stämmer, men det finns en annan anledning till varför denna terminologiförändring är till hjälp. Den kommer att tvinga cio:er och it-chefer att tänka igenom dessa frågor på ett mer effektivt sätt, vilket i sin tur kommer att hjälpa cfo:n, vd:n och styrelsen att förstå vad det verkliga problemet är.

Låt oss vara ärliga här. It-chefen vet exakt vad problemet är och har alltid vetat det. Det har aldrig handlat om att it-cheferna känner till problemen. Det handlar helt och hållet om att kommunicera dem till cheferna på ett sätt som inte leder till att den högsta ledningen får en felaktig uppfattning om problemet, vilket i sin tur leder till en rad negativa konsekvenser.

Vilka slags negativa konsekvenser? Otillräcklig budget, tidsplaner som är dömda att misslyckas och, kanske värst av allt, orealistiska förväntningar och mål. Felaktiga förväntningar, som direkt härrör från bristfälliga uppfattningar, är det som förstör avkastningen på investeringen (ROI).

Jag påstår inte att bristen på en jordnära beskrivning av problemen är anledningen till att begreppet ”tech gravity” fungerar så bra här, men det är inte heller det sämsta argumentet.