versie van dit artikel vertaald door Yesica Danderfer Wat als u geen idee had hoeveel schulden u had? Het zou een ongemakkelijke positie zijn om niet te weten hoeveel het kostte of in welke mate het uw bedrijf verhinderde om operationele verbeteringen aan te brengen, te reageren op marktveranderingen of zelfs het bedrijf volledig te transformeren.
Bovendien, wat als zowat iedereen in uw organisatie schulden zou kunnen maken zonder toestemming te vragen? Uw hoofd onroerend goed kan bijvoorbeeld snel een meerjarige huurovereenkomst aangaan met een lage huur voor het eerste jaar, maar met aanzienlijk stijgende huren in de loop van de jaren, zonder dat iemand dit anders onthult dan in een gesprek.
Dit klinkt allemaal als onvoorzichtig bestuur, maar het is eigenlijk heel gewoon in bedrijven. Het addertje onder het gras is dat dit soort 'schuld' niet de vorm heeft van de traditionele financiële instrumenten die we allemaal zo goed kennen.
Technische schulden hebben al deze kenmerken.
Schuld in zijn eenvoudigste vorm is vandaag lenen met de bedoeling en belofte om in de toekomst terug te betalen. Schulden zijn zinvol wanneer het lenen van vandaag leidt tot een betere toekomst, bijvoorbeeld lenen voor de universiteit of het kopen van een huis. Schulden zijn over het algemeen slecht als vandaag lenen leidt tot een slechtere morgen, bijvoorbeeld uit eten gaan en het op een creditcard zetten die je niet meteen terugbetaalt.
In bedrijfstermen kunnen schulden goed zijn als ze worden aangegaan om investeringen te financieren die een groter rendement opleveren dan de kosten van de schuld. Het kan ook zinvol zijn als u van plan bent het bedrijf te verkopen lang voordat de schuld opeisbaar is. Het nadeel van schulden is dat het een zeer reële uitgave heeft die geld en winsten meesleept, de flexibiliteit beperkt en zo belastend kan worden dat het uiteindelijk tot een faillissement kan leiden.
Tot nu toe gaat de metafoor waar we naar verwijzen over financiële schuld, nog een andere vorm van schuld - technische schuld (of "tech schuld") - heeft veel vergelijkbare kenmerken en moet op een doelbewuste manier worden gemeten, beheerd en aangegaan . Als het uw bedrijf in staat stelt om voor op de concurrentie op de markt te komen, is het zeer waarschijnlijk de moeite waard. Evenzo is het waarschijnlijk ook de moeite waard om technische schulden aan te gaan om een potentieel ernstige beveiligingskwetsbaarheid te verminderen.
Technische schulden hebben echter ook nadelen, wat leidt tot inefficiëntie en traagheid, bijvoorbeeld wanneer een afdeling de software van een andere afdeling niet wil gebruiken, of als u een upgrade meerdere keren uitstelt om financiële kortetermijndoelen te halen.
Technische schuld is een term die voornamelijk binnen de technische gemeenschap wordt gebruikt sinds Ward Cunningham, een computerprogrammeur, de term in 1992 bedacht. Het gebruik ervan is recentelijk van de grond gekomen en heeft een centrale plaats ingenomen met de verspreiding van agile programmeren. De technische schuld die in dit artikel wordt besproken, gaat niet over de programmeermethodologie, maar eerder over de strategische implicaties van het bestaan ervan.
In eenvoudige bewoordingen zijn technische schulden de incrementele kosten en het verlies aan flexibiliteit voor uw bedrijf als gevolg van eerdere beslissingen die zijn genomen om tijd of geld te besparen bij het implementeren van nieuwe systemen of het onderhouden van bestaande systemen. Het komt voor wanneer systemen niet correct zijn geïntegreerd of code te complex is. Dit is te wijten aan verschillende redenen, zoals inefficiëntie, time-to-market-overwegingen of het draaien van verouderde versies van software, naast vele andere.
Enkele duidelijke voorbeelden zijn:
Het onderstaande diagram is een handige afbeelding om in te schatten hoe tech-schuld verschilt van andere technologische implementaties die binnen de tech-stack van een bedrijf kunnen worden gemaakt. Vaak aangezien voor een bug, is technische schuld heel anders in die zin dat de aanwezigheid ervan misschien niet overduidelijk is. Daarin schuilt het gevaar, want hoe langer het onaangeroerd blijft, hoe groter het effect in de toekomst zal zijn.
Als CFO die zowel binnen IT heeft gewerkt als IT-rapportage aan mij had in ondernemingen met een hoge hefboomwerking, viel het me op hoe vergelijkbaar technische schuld is met traditionele schuld. Het viel me ook op hoe ondoorzichtig en riskant het is. Degenen met een financiële achtergrond zijn goed thuis in de mechanismen van financiële schulden - het is tastbaar en gemakkelijk te berekenen. Maar niet voor technische schulden, die vaak verkeerd worden begrepen of ten onrechte worden beschouwd als het probleem van iemand anders.
Het korte antwoord is dat de contante kosten zeer reëel zijn. Er zijn ook enkele belangrijke zachte kosten die moeten worden geïdentificeerd en afzonderlijk moeten worden gemeten en beheerd. Hieronder zal ik enkele voorbeelden van deze kosten toelichten:
Technische schulden zijn net zo reëel als rentebetalingen. Het manifesteert zich echter meestal op een meer indirecte manier in de winst-en-verliesrekening dan een eenvoudige "rente"-regeluitgave, zoals op de volgende manieren:
Headcount
Overhead
Verkoop
Werkkapitaal
Hoewel harde kosten daadwerkelijke bedragen in dollars hebben, zijn er ook zachte kosten die, ondanks dat ze moeilijker te kwantificeren en te realiseren zijn, een absoluut effect hebben op uw bedrijfsresultaten. Deze omvatten:
Marktinformatie
Productiviteit
Als we kijken naar een vergelijking van technische en financiële schulden, is een van de belangrijkste verschillen dat de eerste geen formele controle heeft. Bij financiële schulden zijn er meestal kredietcomités, teams voor activa- en passivabeheer en treasurymedewerkers die de niveaus als een havik bewaken. Met technische schulden bestaan er echter maar heel weinig van deze controles in traditionele bedrijven.
Bij traditionele schulden bepaalt het bestuur, samen met de CEO en CFO, doorgaans de kapitaalstructuur, d.w.z. hoeveel eigen vermogen, hoeveel schuld en welk type schuld (revolver, op activa gebaseerd of vanille ongedekt). De cap-tabel is zelfs expliciet over welke schuld zal worden afbetaald en wanneer. Zodra dit allemaal formeel is besloten, wordt een gestructureerd proces gestart om de schuld te verhogen.
Lenders kijken naar het vermogen van een entiteit om schulden terug te betalen via beoordelingen van de geschiedenis van het terugbetalen van schulden, kredietbeoordelingen en de kwaliteit van het onderpand dat dit ondersteunt. Toch vindt geen van deze formele processen, kwantificering en aftekening plaats wanneer technische schulden worden gemaakt. Laten we eens kijken naar hoe en waarom dit gebeurt via de processen waarin technische schulden ontstaan:
Time-to-market is alles in het bedrijfsleven. Het implementeren van nieuwe technologie gaat veel sneller als het op een stand-alone basis kan worden gedaan. Helaas zijn de implicaties hiervan dat andere systemen niet gesynchroniseerd zijn met de implementatie. Voor slanke organisaties met een eenvoudige tech-stack lijkt dit misschien niet zo slecht.
Het wordt echter problematisch naarmate systeemconfiguraties steeds complexer worden. Uiteindelijk automatiseert technologie processen en legt het gegevens vast die worden omgezet in informatie. Technologie die niet geïntegreerd is, resulteert in bedrijfsprocessen die niet samenwerken en meerdere versies van de waarheid.
Wanneer tijd wordt opgeofferd voor snelheid, kunnen gevestigde testprotocollen worden genegeerd of worden ontheffing verleend. Dit resulteert meestal in "bugs" op de weg die zich manifesteren in een vorm van systeemdegradatie en afleiding van de tijd van de ontwikkelaar om ze op te lossen.
Als we kijken naar het effect van tech-schuld in de loop van de tijd, hoe langer een probleem onaangeroerd blijft, hoe groter het effect. Wat begint als een kleine aanpassing van de code, kan in de loop van de tijd uitgroeien tot een volledige modernisering en vervanging.
Laten we eerlijk zijn:uitvoerende teams staan onder constante druk om de cijfers te halen. Vandaag uitstellen met uitgeven kan u helpen om het kwartaal te halen, maar net als bij lenen moet u het op een gegeven moment terugbetalen. Hier zijn enkele manieren waarop bedrijven op korte termijn geld besparen, maar uiteindelijk resulteren in technische schulden:
Soms kunnen de kosten en problemen van het implementeren van een periodieke software-update ertoe leiden dat deze vertraging oploopt. Soms gaat dit jaren door. We maken ons allemaal schuldig aan het gedwongen stoppen van Microsoft AutoUpdate wanneer dit op ongelegen momenten verschijnt.
Wanneer systemen ver achterlopen op hun huidige versie, kan nieuwere software die ermee moet integreren dat gewoon niet. Bovendien is het upgraden van meerdere versies tegelijk meestal duurder en kost het bijna altijd meer tijd dan bij te houden.
Naarmate organisaties steeds complexer worden, kan de pure inspanning van het synchroniseren van hardware-updatecycli overweldigend en kostbaar worden. Dit kan ertoe leiden dat de huidige hardware tot het uiterste wordt opgerekt en dat er grote verschillen bestaan tussen de kwaliteit van hardware tussen teams. Sommige teams raken gefrustreerd, kopen nieuwe hardware en kosten die gewoon via hun bureaubudget in plaats van te wachten tot IT de upgrades uitvoert.
Dit verschil heeft gevolgen voor de productiviteit en de compatibiliteit van hardware en bestanden voor gezamenlijke oefeningen.
In plaats van alleen maar over problemen te praten, laten we nu wat proactiviteit toepassen en enkele oplossingen voorschrijven voor het oplossen van technische schulden.
Daarvoor kunnen we een beroep doen op de technieken die gebruikt worden om financiële schulden te beheren. Om uw verplichtingen te beheren, moet u eerst weten wat ze zijn, hoeveel ze zijn en hun betalingsvoorwaarden. Laten we dit nu oplossen voor technische schulden.
Financiële schulden komen in tranches die worden bepaald door de anciënniteit van elk stuk (bijvoorbeeld senior, mezzanine of revolver), die op zijn beurt laat zien welke als eerste wordt terugbetaald. Technische schuld heeft een vergelijkbaar patroon van anciënniteit; om te beginnen moet u beginnen met uw bedrijfskritische systemen. Welke technische schuld hebben ze? Kijk dan naar het bredere ecosysteem - beter gezegd, welke technische schuld tussen veroorzaken uw systemen kosten?
Maak dit proces niet te ingewikkeld. Op een gegeven moment wil je een beoordeling van boven naar beneden krijgen, maar je hoeft daar niet te beginnen. Laat je hoofd IT je managementteam samenbrengen met dit huiswerk:
Als we al onze technische schulden een jaar geleden volledig hadden weggewerkt, hoe had dit jaar (of komend jaar) dan beter kunnen uitpakken?
Krijg je top tien ideeën en zet ze in een 2x2 matrix:makkelijk/moeilijk af te betalen op de ene as en mate van voordelen op de andere. Hopelijk helpt het beeld je om erachter te komen waar je moet beginnen.
Brainstormmatrix voor technische schuldaflossing| Voordelen van het oplossen ► | Sterk | ||
|---|---|---|---|
| Zwak | |||
| Moeilijk | Eenvoudig | ||
| ▲ Inspanning om te betalen | |||
Van daaruit kunt u dieper ingaan om uw aannames over de grootte van de prijs en inspanning te valideren. Neutraliteit is hier de sleutel, dus wees op uw hoede voor softwareleveranciers die aanbieden om een "gratis beoordeling" uit te voeren.
Als je eenmaal weet welke technische schuld je hebt, moet je nu beslissen hoe je ermee omgaat. Er zijn veel opties om te nemen.
Het kan uiteindelijk het beste zijn om niets te doen. Voor schulden die ofwel als "klein" of met een "lage rente" worden beoordeeld, kan het optimaal zijn om deze gewoon te laten staan - ook als er een aanzienlijke "vervroegde aflossing" is van vervroegde aflossing. Er kunnen ook strategische voordelen zijn. Een versie achterlopen en daar blijven is meestal prima en heeft soms het voordeel dat knikken worden opgelost op andermans dubbeltje.
Om technische schulden terug te betalen of te verminderen, moeten systemen worden vervangen en de kosten worden opgevangen. Dit kan ofwel onmiddellijk worden gedaan, ofwel in de loop van de tijd via een proces van geleidelijke verbeteringen. Net als bij financiële schulden zijn er creatieve manieren om technische schulden te 'herfinancieren', waarbij het uitbesteden van het onderhoud een van die manieren is. Dit kan uiteindelijk meer kosten om op te lossen, maar kan worden gespreid om de directe kosten te verlagen en, door de principes van de taakverdeling, de taak te delegeren aan een meer gespecialiseerde entiteit.
De komst van cloudgebaseerde software- en hardwareservices brengt ook een vergelijking met de populariteit van op lease gebaseerde financiering met zich mee. Het gebruik van cloudservices is ook een effectief hulpmiddel om technische schulden te verminderen, zowel bij het verwijderen van CAPEX-vereisten als bij het verleggen van de ontwikkelingsfocus naar de cloudprovider.
Laat u niet overweldigen door de kosten van het verminderen van uw technische schuld en probeer deze niet in één keer af te betalen. Dit zou een ambitieuze oefening zijn die een organisatie van elke omvang of balans zou kunnen overweldigen.
Nogmaals, teruggaand naar de financiële vergelijkingen, heb de mentaliteit om eerst de creditcard met de hoogste rente af te betalen. Dit betekent simpelweg dat je eerst waardevolle/lage inspanning moet aanvallen.
In de vorige paragraaf heb ik de verschillende manieren om technische schulden aan te pakken besproken. Bij het beoordelen van de kosten van elk, is het het beste om een vergelijkingsoefening uit te voeren. Door de cashflowkosten van elk potentieel resultaat te rangschikken, kunnen de belanghebbenden een duidelijk beeld krijgen van de afwegingen en voordelen van elk pad. Een voorbeeld van zo'n visual is hieronder opgenomen.
Deze vergelijking toont de afweging die bestaat tussen een theoretische oplossing en het schril contrast tussen het probleem oplossen en niets doen (“bestaande baseline”). In dit voorbeeld zou de overstap naar een cloud, SaaS-gebaseerde oplossing de meest economische optie zijn voor het bedrijf.
Als je eenmaal je basislijn en aanvalsplan hebt vastgesteld, wil je zowel die zichtbaarheid behouden als voorkomen dat nieuwe schulden binnensluipen. Zie de oefening als een nieuwe start en een kans om best practices te implementeren om te voorkomen dat problemen ooit in de toekomst weer escaleert.
De meeste technologieprojecten hebben een formeel goedkeuringsproces, compleet met een uitvoerende sponsor, een doelstelling op hoog niveau, verwachte voordelen, planning en natuurlijk kosten. Dit is een geweldige plek om nieuwe technische schulden weg te spoelen die zullen ontstaan en de rechtvaardiging ervan.
Ga niet te overijverig met het stellen van nieuwe normen. Net zoals u zakelijke creditcards met vooraf ingestelde limieten uitgeeft, wilt u niet te veel technische schulden beheren. Veel technische schulden zijn klein en gerelateerd aan het schrijven van code die snel zullen worden afbetaald. Dit geldt met name voor agile ontwikkeling. Vertrouw op uw IT-hoofd om deze drempel in te stellen en te bewaken.
In grotere bedrijven heeft IT een proces dat 'verandermanagement' wordt genoemd. Voordat nieuwe software live gaat, gaat deze meestal door change management. Simpel gezegd, de taak van verandermanagement is ervoor te zorgen dat nieuwe wijzigingen in het technologiesysteem van het bedrijf geen invloed hebben op andere systemen. Dit doen zij door ervoor te zorgen dat het nieuwe systeem voldoet aan gestandaardiseerde methoden en procedures. Overweeg om dit proces te gebruiken om te voorkomen of in ieder geval om nieuwe schulden te identificeren.
Technische schulden zijn een reële kostenpost voor het zakendoen en een echte oorzaak van systeemstoringen en belemmeren de algehele wendbaarheid van het bedrijf. Het hoeft echter geen voortdurende last te zijn, en slimme CFO's weten hoeveel technische schulden hun organisatie heeft en wat er nodig is om deze te optimaliseren.
De nadelen van schulden op afbetaling
De financiële implicaties van het COVID-vaccin, uitgelegd
De belastingimplicaties van ETH 2.0
Hoe u de beste financiële oplichting voor millennials kunt vermijden
Het probleem van financiële inertie
Microsoft Cloud for Financial Services:de implicaties voor FSI's
Financiële doelen stellen:de 4 fasen naar financiële onafhankelijkheid