• Ofta är det första steget mot teknisk skuld en tidsbegränsning som leder till att en kompromiss tas. Detta kan ofta glömmas bort.
• Frestelsen att spara kostnader kan också resultera i en teknisk skuldsituation. Detta är ofta relaterat till att avstå från programvaruuppdateringar eller förlänga hårdvarubytescykler.

Tänk om du inte hade någon aning om hur mycket skuld du hade? Det skulle vara en obekväm situation att vara i, att inte veta hur mycket det kostade eller i vilken grad det hindrade ditt företag från att göra operativa förbättringar, reagera på marknadsförändringar eller till och med förändra verksamheten helt.

Dessutom, tänk om nästan vem som helst i din organisation kunde dra på sig skulder utan att söka tillstånd? Till exempel kan din fastighetschef snabbt ingå ett flerårigt hyresavtal med en låg hyra ett år men med kraftigt eskalerande hyror under de sista åren – utan att någon avslöjar det annat än genom samtal.

Allt detta låter som oförsiktig styrning, men det är faktiskt ganska vanligt i företag. Haken är att den här typen av "skulder" inte kommer i form av de traditionella finansiella instrument som vi alla känner så väl.

Teknisk skuld har alla dessa egenskaper.

Skuld i sin enklaste form är att låna idag med avsikt och löfte att betala tillbaka i framtiden. Skuld är vettigt när dagens upplåning kommer att leda till en bättre morgondag, t.ex. låna till college eller köpa ett hus. Skulder är generellt sett dåliga när ett lån idag leder till en sämre morgondag, till exempel att gå ut och äta en dyr middag och sätta den på ett kreditkort som du inte direkt kommer att betala av.

I företagstermer kan skulder vara bra när de uppstår för att finansiera investeringar som kommer att ge en större avkastning än kostnaden för skulden. Det kan också vara vettigt om du planerar att sälja företaget långt innan skulden förfaller. Nackdelen med skuld är att den har en mycket reell kostnad som drar pengar och vinster, begränsar flexibiliteten och kan bli så betungande att den i slutändan kan leda till konkurs.

Hittills handlar metaforen som vi anspelar på om finansiell skuld, ännu en form av skuld - teknisk skuld (eller "teknisk skuld") - har många liknande egenskaper och måste mätas, hanteras och ingås på ett medvetet sätt . Om det tillåter ditt företag att komma ut på marknaden före konkurrenterna är det mycket troligt värt det. På samma sätt är det förmodligen värt det också att ta på sig tekniska skulder för att mildra en potentiellt allvarlig säkerhetsrisk.

Tekniska skulder har dock sina baksidor, vilket leder till ineffektivitet och tröghet – som när en avdelning inte vill använda en annans programvara, eller om du försenar en uppgradering flera gånger för att nå kortsiktiga finansiella mål.

Så, vad är teknisk skuld?

Teknisk skuld är en term som har använts främst inom det tekniska samfundet sedan Ward Cunningham, en datorprogrammerare, myntade frasen 1992. Användningen av den har tagit fart nyligen och tagit en central plats med spridningen av smidig programmering. Den tekniska skulden som diskuteras i den här artikeln handlar inte om programmeringsmetodik utan snarare de strategiska konsekvenserna av dess existens.

Enkelt uttryckt är teknisk skuld den inkrementella kostnaden och förlusten av smidighet för ditt företag som ett resultat av tidigare beslut som togs för att spara tid eller pengar när du implementerar nya system eller underhåller befintliga. Det uppstår när systemen inte är korrekt integrerade eller koden är alltför komplex. Detta beror på en mängd olika orsaker, såsom ineffektivitet, överväganden om tid till marknaden eller att köra föråldrade versioner av programvara, bland många andra.

Några tydliga exempel skulle vara:

1. Använda gamla versioner av Windows som hindrar dig från att använda ny programvara eller tillämpa en säkerhetsuppgradering
2. ERP-system i en ond cirkel av att vara så gamla och anpassade att de inte kan uppgraderas, eftersom det skulle vara en "rippa och ersätta"-ansträngning
3. Liknande system som har överlappande funktioner i olika delar av din organisation

Diagrammet nedan är en användbar grafik för att rama in hur teknisk skuld skiljer sig från andra tekniska implementeringar som kan göras inom ett företags tekniska stack. Ofta misstas den för att vara en bugg, teknisk skuld är mycket annorlunda genom att dess närvaro kanske inte är uppenbart uppenbar. Däri ligger faran, eftersom ju längre den lämnas orörd, desto större kommer effekten att bli i framtiden.

Som CFO som både har arbetat inom IT och haft IT-rapportering till mig i företag med hög belåning, slog det mig hur lik teknisk skuld är den traditionella skulden. Det slog mig också av hur ogenomskinlig och riskabel den är. De med finansiell bakgrund är väl insatta i mekanismerna för finansiell skuld - det är påtagligt och lätt att beräkna. Men inte så för tekniska skulder, som ofta missförstås eller felaktigt antas vara någon annans problem.

Vad exakt är kostnaderna för tekniska skulder och är de verkliga?

Det korta svaret är att kontantkostnaderna är mycket reella. Det finns också några viktiga mjuka kostnader som bör identifieras samt separat mätas och hanteras. Jag kommer nedan att utveckla några exempel på dessa kostnader:

Kontantkostnader

Tekniska skulder är lika verkliga som räntebetalningar. Det visar sig dock vanligtvis på P&L på ett mer indirekt sätt än en enkel "räntekostnad", som på följande sätt:

Antal anställda

• Mer personal behövs helt enkelt för att underhålla befintliga system
• Ytterligare tid för utvecklare att skapa nya funktioner

Overhead

• Försenat realisering av synergieffekter från förvärvsintegration
• Åtgärd och böter som härrör från säkerhetsöverträdelser

Försäljning

• Förlorad försäljning på grund av systemavbrott
• Mindre effektiv marknadsföring

Arbetskapital

• Ökade krav, särskilt för företag med höga lagersaldon

Mjuka kostnader

Även om hårda kostnader har faktiska dollarbelopp förknippade med dem, finns det också mjuka kostnader som, trots att de är svårare att kvantifiera och realisera besparingar på, drar ner dina affärsresultat absolut. Dessa inkluderar:

Marknadsinformation

• Oförmåga att snabbt anpassa sig till möjligheter eller förändringar på marknaden
• Minskad förmåga att omvandla data till information för att fatta bättre beslut
• Flera versioner av sanningen

Produktivitet

• Lägre personalproduktivitet på grund av systemavbrott
• Mindre produktiv personal som lägger mer tid på att extrahera och massera data än att analysera den
• Att spåra ur ledningens tid och uppmärksamhet om ett större säkerhetsintrång inträffar

Om man tittar på en jämförelse av tekniska och finansiella skulder, är en av de viktigaste skillnaderna att den förra inte har någon formell kontroll. Med finansiell skuld finns det vanligtvis kreditkommittéer, förvaltningsteam för tillgångar och skulder och finanspersonal som övervakar nivåerna som en hök. Med tekniska skulder finns dock väldigt få av dessa kontroller i traditionella företag.

Hur och varför tekniska skulder uppstår

Med traditionella skulder bestämmer styrelsen, tillsammans med VD och CFO, vanligtvis kapitalstrukturen, det vill säga hur mycket eget kapital, hur mycket skulder och vilken typ av skuld (revolver, tillgångsbaserad eller vanilj utan säkerhet). Cap-tabellen är till och med tydlig om vilken skuld som kommer att betalas av och när. När allt detta formellt bestämts inleds en strukturerad process för att ta upp skulden.

Långivare tittar på en enhets förmåga att betala tillbaka skulder genom bedömningar av historien om att betala tillbaka skulder, kreditbetyg och kvaliteten på säkerheter som backar upp dem. Ändå händer inget av denna formella process, kvantifiering och sign-off när tekniska skulder uppstår. Låt oss ta en titt på hur och varför detta sker genom processerna där tekniska skulder uppstår:

Tidsbegränsningar leder till kompromiss

Time to market är allt i affärer. Att implementera ny teknik är mycket snabbare att göra när det kan göras på en fristående basis. Tyvärr är konsekvenserna av detta att andra system inte är synkroniserade med implementeringen. För smala organisationer med en enkel teknisk stack kanske det inte verkar så illa.

Det blir dock problematiskt eftersom systemkonfigurationer multipliceras i sin komplexitet. I slutändan automatiserar teknologin processer och fångar data som omvandlas till information. Teknik som inte är integrerad resulterar i affärsprocesser som inte fungerar tillsammans och flera versioner av sanningen.

När tid offras för hastighet kan etablerade testprotokoll ignoreras eller ges undantag. Detta resulterar vanligtvis i "buggar" på vägen som visar sig i någon form av systemförsämring och distraktion av utvecklarens tid att fixa dem.

Om vi ​​tittar på effekten av teknisk skuld över tid, ju längre en fråga lämnas orörd, desto större är effekten. Det som börjar som en liten kodrefaktoreringsövning kan snöa in i en hel moderniserings- och ersättningsansträngning längre fram.

Frestelsen av kortsiktiga kostnadsbesparingar

Låt oss inse det - verkställande team är under konstant press att nå siffrorna. Att hålla av med utgifterna idag kan hjälpa dig att klara kvartalet, men precis som att låna måste du betala tillbaka det någon gång. Här är några sätt som företag sparar pengar på på kort sikt men som leder till tekniska skulder:

Programuppdateringar

Ibland kan kostnaden och besväret med att implementera en periodisk programuppdatering leda till att den försenas. Ibland pågår detta i flera år. Vi är alla skyldiga till att tvångsavbryta Microsoft AutoUpdate när det dyker upp vid obekväm tid.

När system hamnar långt efter sin nuvarande version, kan nyare programvara som måste integreras med den helt enkelt inte. Att uppgradera flera versioner samtidigt är dessutom vanligtvis dyrare och nästan alltid mer tidskrävande än att hänga med.

Ersättning av maskinvara

I takt med att organisationer växer i komplexitet kan ansträngningen att synkronisera hårdvaruuppdateringscykler bli överväldigande och kostsam. Detta kan resultera i att nuvarande hårdvara tänjs ut till de extrema och stora skillnader som finns mellan kvaliteten på hårdvaran mellan team. Vissa team blir frustrerade, köper ny hårdvara och tar bara ut den via sin skrivbordsbudget istället för att vänta på att IT ska starta uppgraderingarna.

Denna skillnad har konsekvenser för produktivitet och hårdvara/filkompatibilitet för samarbetsövningar.

Taktik för att hantera en teknisk skuldsituation

Istället för att bara prata om problem, låt oss nu tillämpa lite proaktivitet och föreskriva några lösningar för att lösa tekniska skulder.

För det kan vi använda de tekniker som används för att hantera finansiella skulder. För att hantera dina skulder måste du först veta vad de är, hur mycket de är och deras betalningsvillkor. Låt oss nu arbeta igenom detta för tekniska skulder.

1. Ta reda på vad och hur mycket teknisk skuld du har

Finansiella skulder kommer i omgångar som definieras av åldern för varje del (t.ex. senior, mezzanine eller revolver), vilket i sin tur visar vilken som betalas tillbaka först. Tekniska skulder har ett liknande mönster av anciennitet; till att börja med måste du börja med dina verksamhetskritiska system. Vilken teknisk skuld har de? Titta sedan på det bredare ekosystemet – bättre uttryckt, vilken teknisk skuld mellan orsakar dina system kostnader?

Överkomplicera inte denna process. Vid någon tidpunkt kommer du att vilja komma till en topp-till-botten-bedömning, men du behöver inte börja där. Låt din IT-chef dra ihop din ledningsgrupp med denna hemläxa:

Om vi ​​hade rensat upp all vår tekniska skuld för ett år sedan, hur skulle detta år (eller det kommande året) kunnat fungera bättre?

Få dina tio bästa idéer och placera dem i en 2x2-matris:lätt/svårt att betala ner på en axel och graden av fördelar på den andra. Förhoppningsvis hjälper den visuella bilden dig att ta reda på var du ska börja.

Därifrån, borra in för att validera dina antaganden om storleken på priset och ansträngningen. Neutralitet är nyckeln här, så var försiktig med programvaruleverantörer som erbjuder sig att göra en "gratis bedömning".

2. Bestäm vad du ska göra

När du väl vet vilken teknisk skuld du har måste du nu bestämma dig för hur du ska hantera den. Det finns många alternativ att ta.

Det kan i slutändan vara bäst att inte göra någonting. För skulder som antingen bedöms vara "liten" eller med en "låg ränta" kan det vara optimalt att bara lämna den – likaså om det finns en betydande "förskottsbetalningsstraff" att betala av i förtid. Det kan också finnas strategiska fördelar. Att vara en version bakom och stanna där är vanligtvis bra och ibland har fördelen att det låter knäcken lösa sig på någon annans krona.

Att betala tillbaka eller minska den tekniska skulden kommer att innebära att man byter ut system och tar kostnaden. Detta kan antingen göras omedelbart eller över tid genom en process av gradvisa förbättringar. Precis som med finansiell skuld finns det kreativa sätt på vilka du kan "refinansiera" teknisk skuld, där outsourcing av underhållet är ett sådant sätt. Detta kan i slutändan kosta mer att lösa, men kan ändå spridas ut för att sänka den omedelbara kostnaden och, genom principerna för arbetsfördelning, delegera uppgiften till en mer specialiserad enhet.

Tillkomsten av molnbaserad mjukvara och hårdvarutjänster ger också en jämförelse med populariteten för leasing-baserad finansiering. Att använda molntjänster är också ett effektivt verktyg för att minska tekniska skulder, både för att ta bort CAPEX-krav och flytta utvecklingsfokus till molnleverantören.

3. Skapa en betalningsplan

Bli inte överväldigad av kostnaden för att minska din tekniska skuld och försök inte betala av allt på en gång. Detta skulle vara en ambitiös övning som skulle kunna överväldiga en organisation av vilken storlek som helst eller balansräkning.

Återigen, gå tillbaka till de finansiella jämförelserna, ha en mentalitet att betala av kreditkortet med den högsta räntan först. Detta innebär helt enkelt att först attackera aktiviteter med högt värde/låg ansträngning.

I föregående avsnitt diskuterade jag de olika sätten att hantera tekniska skulder. När du bedömer kostnaden för var och en är det bäst att göra en jämförelseövning. Att rangordna kassaflödeskostnaden för varje potentiellt resultat kan göra det möjligt för intressenterna att få en tydlig bild av avvägningarna och fördelarna med varje väg. Ett exempel på en sådan bild finns nedan.

Denna jämförelse visar den avvägning som finns mellan en teoretisk lösning och den skarpa kontrasten mellan att lösa problemet och att inte göra någonting ("existing baseline"). I det här exemplet, att flytta till ett moln, skulle SaaS-baserad lösning vara det mest ekonomiska alternativet för företaget att ta.

Hantera tekniska skulder framöver

När du väl har etablerat din baslinje och attackplan kommer du att vilja både bevara den synligheten och förhindra att nya skulder smyger sig in. Se övningen som en nystart och en chans att implementera bästa praxis för att förhindra problem från någonsin eskalerar igen i framtiden.

Implementera en låneupplysning

De flesta teknikprojekt har en formell godkännandeprocess komplett med en verkställande sponsor, mål på hög nivå, förväntade fördelar, schema och naturligtvis kostnader. Det här är ett bra ställe att spola ut nya tekniska skulder som kommer att uppstå och motiveringen till den.

Ange utlåningsgränser

Var inte för överivrig med att sätta nya standarder. Precis som du utfärdar företagskreditkort med förinställda gränser vill du inte överstyra tekniska skulder. Mycket teknisk skuld är liten och relaterad till kodskrivning som snabbt kommer att betalas av. Detta gäller särskilt med agil utveckling. Lita på att din IT-chef ställer in och övervakar denna tröskel.

Träna om dina försäkringsgivare

I större företag har IT en process som kallas "förändringshantering". Innan ny programvara går live går den vanligtvis igenom förändringshantering. Enkelt uttryckt är förändringsledningens uppgift att se till att nya förändringar i företagets teknologisystem inte påverkar andra system. Det gör de genom att se till att det nya systemet följer standardiserade metoder och rutiner. Överväg att använda den här processen för att förhindra eller åtminstone identifiera nya skulder från att införas.

Tekniska skulder är en verklig kostnad för att göra affärer och en verklig orsak till systemavbrott och drar på företagets övergripande smidighet. Det behöver dock inte vara en pågående börda, och smarta finanschefer kommer att veta hur mycket teknisk skuld deras organisation har och vad som krävs för att optimera den.