Teknisk skuld – vad det kostar och hur ni hanterar det
Projekten tar allt längre tid. En enkel förändring som borde ta en vecka tar tre. Konsulterna pratar om "beroenden", "legacy" och att saker "hänger ihop på konstiga sätt". För den som inte är tekniker känns det abstrakt – men notan är väldigt konkret.
Det handlar med stor sannolikhet om teknisk skuld. Den här guiden förklarar vad det är, hur du känner igen den, vad den faktiskt kostar och hur du driver frågan internt.
Vad är teknisk skuld?
Begreppet myntades av programmeraren Ward Cunningham på 1990-talet. Metaforen är lånad från ekonomin: precis som finansiell skuld ackumulerar ränta, ackumulerar dåliga tekniska beslut framtida kostnader.
Teknisk skuld uppstår när ett system byggs – eller byggs om – på ett sätt som är snabbt och billigt just nu, men som kräver mer arbete längre fram. Det kan vara ett medvetet val ("vi gör det enkelt nu och fixar det ordentligt efter lanseringen") eller ett omedvetet resultat av tidsbrist, bristande kompetens eller otydliga krav.
Skulden i sig är inte alltid fel. Att ta ett kortfristigt tekniskt genväg för att möta ett marknadsfönster kan vara ett rationellt beslut – precis som att ta ett banklån. Problemet uppstår när skulden aldrig betalas av, eller när man inte ens vet att den finns.
Vanliga orsaker
- Tidsbrist och "vi fixar det sen"
Funktionalitet levereras snabbt utan att strukturen håller på sikt.
- Inget underhållsmandat
Organisationen investerar bara i nya features, aldrig i att städa upp det befintliga.
- Personalomsättning
Den som byggde systemet har slutat, och ingen annan förstår hur det fungerar.
- Gammal teknologi
Ramverk, programspråk eller databaser som inte längre underhålls aktivt och saknar modern dokumentation.
- Brist på tester
Ingen automatiserad testning gör att varje ändring riskerar att bryta något annat.
- Dålig dokumentation
Ny kod skrivs utan att någon förstår helheten.
Så känner du igen teknisk skuld – utan att vara tekniker
Som verksamhets- eller inköpsansvarig behöver du inte läsa källkod. Det finns tydliga beteendesignaler:
Tidssignaler
- Enkla ändringar tar oproportionerligt lång tid.
- Konsulter och interna utvecklare estimerar alltid med stor osäkerhet ("det beror på hur det är byggt").
- Leveranser förskjuts trots att kraven inte förändrats.
Kostnadssignaler
- Konsulttimmarna per ny funktion ökar successivt, inte minskar.
- Ni betalar för buggrättningar av saker som borde vara stabila.
- Det dyker regelbundet upp "oväntade" integrationsproblem.
Organisatoriska signaler
- Utvecklarna är ovilliga att ta i vissa delar av koden ("the legacy module").
- Det finns en eller ett par nyckelpersoner som "är de enda som vet hur det fungerar".
- Onboarding av nya konsulter tar ovanligt lång tid.
Vad kostar teknisk skuld i praktiken?
Det saknas exakta branschsiffror för svenska SMF, men mönstret är välkänt i branschen: ju äldre och mer obehandlad skulden är, desto större andel av varje projekts budget går till att navigera kring den snarare än att bygga nytt värde.
En tumregel som används av många IT-arkitekter är att teknisk skuld kan uppgå till 20–40 procent av ett systems totala underhålls- och utvecklingskostnad när den fått växa okontrollerat.
Effekterna syns framför allt som:
- Längre ledtider – det tar längre tid att leverera samma mängd funktionalitet.
- Högre konsultkostnader – fler timmar per ändring, mer felsökning, mer riskhantering.
- Ökad störningsfrekvens – system som inte underhålls korrekt är mer känsliga för driftsavbrott.
- Svårare att byta leverantör – ju mer skuld, desto mer leverantörslåsning.
Tre typer av teknisk skuld – och vad de kräver
Det underlättar att skilja på vilken typ av skuld ni har, eftersom åtgärderna ser olika ut.
1. Designskuld
Systemets grundstruktur håller inte för dagens krav. Lösningen är vanligtvis en refaktorering eller i mer extrema fall en ny arkitektur. Kostsamt men nödvändigt om systemet ska leva vidare.
2. Kodskuld
Enskilda delar av koden är röriga, odokumenterade eller beroende av föråldrade bibliotek. Kan ofta åtgärdas successivt av ett kompetent team utan att hela systemet behöver ritas om.
3. Testsskuld
Avsaknad av automatiserade tester gör varje förändring riskfylld. Att bygga upp ett testtäckning är arbetsintensivt men möjliggör i gengäld snabbare och tryggare leveranser framöver.
Hur ni argumenterar internt för att prioritera åtgärder
Teknisk skuld prioriteras ofta bort i budgetprocessen eftersom den är osynlig för alla utom de tekniska teamen. Att göra skulden synlig i verksamhetstermer är nyckeln.
Koppla till faktiska kostnader
Samla data på hur lång tid liknande ändringar tog för ett år sedan jämfört med nu. Om en standardmässig anpassning tar tre gånger längre idag än för två år sedan – vad innebär det i konsulttimmar per år?
Räkna på risken
Vad händer om det system som bara en person förstår slutar fungera, och den personen är sjuk? Vad kostar ett driftstopp per timme? Teknisk skuld är också en operationell risk.
Sätt det i relation till ny funktionalitet
Visa att varje ny funktion delvis finansierar konsekvenserna av skulden, inte bara det nya värdet. En tydlig modell: om 40 procent av konsultbudgeten går till att hålla det befintliga flytande, hur mycket ny kapacitet köper ni egentligen?
Föreslå ett gradvist upplägg
Ledningen vill sällan höra "vi behöver skriva om allt". Föreslå i stället att en definierad procent av varje sprint eller projektbudget går till teknisk återbetalning. Många erfarna IT-konsulter rekommenderar 15–20 procent av löpande kapacitet som riktmärke för teknisk underhållsbudget.
Checklista: Identifiera teknisk skuld i er verksamhet
Gå igenom följande punkter med er interna IT-ansvarig eller en extern konsult:
- Har ni en uppdaterad systemkarta över vilka system som kommunicerar med varandra?
- Vet ni vilka ramverk och bibliotek era system bygger på, och om de fortfarande är i aktivt underhåll?
- Finns det dokumentation som en ny konsult kan använda för att komma in i koden på rimlig tid?
- Finns det automatiserade tester för de mest kritiska delarna av systemet?
- Kan ni göra en ändring i ett delsystem utan att behöva testa hela systemet manuellt?
- Har ni en process för att regelbundet uppdatera beroenden och säkerhetspatchar?
- Är konsultkostnaden per ny funktion stabil eller stigande?
Mer än tre nej-svar är ett tydligt tecken på att teknisk skuld behöver hanteras aktivt.
Vanliga misstag när ni hanterar teknisk skuld
- Att ignorera skulden tills ett akut haveri tvingar fram en panikrefaktorering – ofta det dyraste alternativet.
- Att skriva om allt på en gång utan att stabilisera befintliga delar – skapar ny skuld medan den gamla hanteras.
- Att inte mäta – utan nyckeltal är det omöjligt att visa att åtgärderna faktiskt hjälper, och budgeten försvinner nästa kvartal.
Att anlita en extern konsult för att inventera skulden
En teknisk revision – ibland kallad kodbas-audit eller arkitekturgranskning – är ofta ett bra första steg. En erfaren IT-arkitekt eller senior utvecklare kan på relativt kort tid (vanligtvis 2–5 dagars arbete) ge er en strukturerad bild av:
- Var de största riskerna finns.
- Vad som kräver omedelbar åtgärd och vad som kan hanteras successivt.
- En grov kostnadsbild för olika åtgärdsalternativ.
Viktigt: revisionen ska resultera i ett dokument riktat till beslutsfattare, inte bara till tekniker. Be om en prioriterad åtgärdslista med affärsmässig motivering.
Läs mer om hur ni förbereder er inför ett sådant uppdrag i vår guide om att anlita IT-konsult.
Sammanfattning
Teknisk skuld är inte ett teknikproblem – det är ett affärsproblem. Den syns på fakturan, i leveranstiderna och i risknivån. Att hantera den kräver att den görs synlig i verksamhetstermer och att det avsätts ett löpande utrymme för underhåll, inte bara nya funktioner.
Det bästa sättet att börja är att kartlägga läget, koppla det till faktiska kostnader och presentera ett gradvist åtgärdsförslag – snarare än att kräva en stor omskrivning på en gång. Med rätt konsultstöd och ett tydligt mandat är teknisk skuld fullt hanterbar.
Redo att ta tag i den tekniska skulden?
Lär dig hur ni hittar rätt IT-konsult för att inventera och hantera er tekniska skuld på ett strukturerat sätt.
Läs vår guide om att anlita IT-konsult