Wat is technische schuld? Gids voor bedrijfsimpact
Nu omzetverantwoordelijken steeds meer onder druk staan om efficiënte groei en winstgevendheid te realiseren, is ook de afhankelijkheid van hun technologiestack aanzienlijk toegenomen. RevOps is daardoor steeds belangrijker geworden als de functie die mensen en processen met technologie verbindt.
Over het algemeen beheren de meeste technologiebedrijven tegenwoordig een grote hoeveelheid tools om marketing- en verkoopgroei te stimuleren. Volgens Scott Brinker waren er in 2022 bijna 10.000 technologieoplossingen voor marketing en verkoop. Van CRM- en marketingautomatiseringsplatforms tot oplossingen voor verkoopparticipatie en conversationele intelligentietoepassingen: een groot deel van deze technologie-investeringen leidt tot aanzienlijke technische schuld, die het rendement op investering (ROI) kan aantasten en de algehele bedrijfsprestaties kan belemmeren.
Mijn naam is Mohammed Abukar en momenteel leid ik de strategie voor verkooptechnologie bij een van Canada's grootste en toonaangevende technologie- en telecombedrijven. In het afgelopen decennium is de groei in het gebruik van bedrijfsapplicaties, met name in de technologiesector, een indrukwekkend fenomeen geweest. Hoewel dit verschijnsel voor sommigen tot versnelde groei heeft geleid, is technische schuld voor anderen een last geworden die hun vermogen om op te schalen belemmert.
Create a free account to continue reading this article.
Want more from the CRO Club? Sign up to get free access and join modern revenue leaders using proven playbooks, peer insights, and AI-driven strategies to build predictable pipeline and scalable growth.
Have an account? Log In
Ik heb dit artikel geschreven om het concept van technische schuld te onderzoeken—zowel de goede als de slechte kant ervan, in relatie tot omzetactiviteiten. Ik ga in op aspecten van schaalbaarheid, datakwaliteit en algehele bedrijfsefficiëntie. Tot slot deel ik praktische inzichten en strategieën voor zowel het beheren als het beperken van technische schuld.
Wat is technische schuld?
De term technische schuld werd in 1992 bedacht door een softwareontwikkelaar genaamd Ward Cunningham, als verwijzing naar codeschuld binnen software-engineering. Cunningham was een van de auteurs van het Agile Manifesto, dat tegenwoordig veelvuldig wordt geciteerd.
Cunningham schreef ooit: “Code voor de eerste keer opleveren is alsof je schulden aangaat. Een beetje schuld versnelt de ontwikkeling, zolang die snel wordt terugbetaald met een herschrijving. … Het gevaar ontstaat wanneer de schuld niet wordt terugbetaald. Elke minuut die wordt besteed aan code die niet helemaal juist is, telt als rente op die schuld.”
Als we deze uitspraak van Cunningham analyseren, wordt duidelijk dat technische schuld op zichzelf niet inherent goed of slecht is. Integendeel, net als elke andere financiële schuld kan technische schuld, als die verstandig en strategisch wordt gebruikt, als hefboom worden ingezet om je bedrijf vooruit te helpen.
Met andere woorden: technische schuld kan een hulpmiddel zijn dat je organisatie zowel ten goede als ten kwade kan benutten.
In de context van omzetactiviteiten is technische schuld de kostenpost die een bedrijf maakt door inefficiënties die verband houden met technologie. Een slecht geïmplementeerd CRM of een systeemintegratie die niet optimaal is opgezet, geldt bijvoorbeeld als technische schuld.
Deze kosten worden in de wereld van RevOps vaak aangeduid als omzetlekkage. Mijn favoriete uitleg van wat omzetlekkage betekent, staat goed beschreven in The Atlantic.
“Omzetlekkage is het vermijdbare verlies aan omzet als gevolg van systemische tekortkomingen in inzicht, processen en uitvoering. Het gaat om omzet waarvoor je het werk hebt gedaan om die te verdienen, waaraan je team tijd en moeite heeft besteed, maar die niet op de balans terechtkomt. …Deze verloren omzet is groei die is verdwenen.”
Waarom is het belangrijk om technische schuld te begrijpen?
Net als bij elke andere schuld zal technische schuld zich in de loop der tijd opstapelen als die niet wordt terugbetaald. Door deze opeenstapeling wordt het uiterst moeilijk om proceswijzigingen door te voeren of met nieuwe initiatieven te experimenteren. Naarmate je organisatie groeit en meer processen en mensen toevoegt, wordt dit probleem steeds groter.
Het is belangrijk om inzicht te houden in de mate waarin je organisatie met technische schuld te maken heeft, omdat je zo binnen een comfortabele grens kunt blijven opereren en actie kunt ondernemen als die grens wordt overschreden.
De cyclus van technische schuld begrijpen
“Met deze tool kan ik sneller een verkooppijplijn opbouwen” of “Deze applicatie kan helpen ons winstpercentage bij verkoop te verbeteren.” Als je in RevOps werkt, heb je waarschijnlijk al eens een variant van deze uitspraken gehoord. In hun pogingen om verkoop- of marketingprestaties te verbeteren, nemen bedrijfsleiders soms slechte aankoopbeslissingen met langetermijngevolgen in ruil voor kortetermijnwinst.
De waarheid is dat deze nieuwe systemen na verloop van tijd hun synergie met de algehele omzetmotor verliezen als er geen rekening wordt gehouden met schaalbaarheid op lange termijn, waardoor de efficiëntie na verloop van tijd afneemt.
Deze situatie vereist meer middelen om alle inefficiënties binnen de systemen te beheren, in plaats van die tijd en moeite te gebruiken voor de ontwikkeling van nieuwe functies en het ontsluiten van extra productiviteit. Dit leidt tot aanzienlijke omzetverliezen en helaas krijgen leveranciers hier vaak een groot deel van de schuld van.
Volgens Gartner kan dit uitmonden in een vicieuze cirkel van investeringen in omzettechnologie.
Uiteindelijk zullen de kosten voor het onderhouden van deze ondermaats presterende componenten hun verwachte ROI overstijgen. Hierdoor zal je organisatie moeite hebben om klanten effectief te bedienen en de concurrentie bij te houden.
Veelvoorkomende oorzaken van technische schuld
In de context van Revops zijn er verschillende oorzaken van technische schuld. Het is belangrijk om deze oorzaken te begrijpen, zodat je voorkomt dat je onbedoeld extra schuld aan je technologiestack toevoegt. Hier zijn drie oorzaken om rekening mee te houden, met voorbeelden van technische schuld.
Gebrek aan goede bedrijfsprocessen
De meest voorkomende bron van technische schuld die ik door de jaren heen heb gezien, houdt verband met slecht opgebouwde processen binnen organisaties. Dit is een groot probleem dat ik vooral bij kleinere organisaties heb zien toenemen, waar processen voor het eerst worden opgebouwd.
Neem bijvoorbeeld iets zo complex als verkoopprognoses. Als je verkoopmanagementteam geen SOP's (standaard operationele procedures) en een vastgestelde operationele routine heeft voor het maken van prognoses, is het kopen van een nieuw systeem om prognoses te verbeteren een zeer grote gok.
Wat er in zo'n scenario doorgaans gebeurt, is dat de tool zelf het proces voor verkoopmanagers vaststelt. Dit is problematisch, omdat er nooit één aanpak is die voor iedereen werkt voor iets dat zo complex is als het maken van verkoopprognoses. De meest waarschijnlijke uitkomst? De tool vervult zijn beoogde doel niet en vereist uiteindelijk verdere configuratie naarmate processen beter worden gedefinieerd.
Bij iets dat zo cruciaal is als verkoopprognoses kun je te maken krijgen met onbedoelde gevolgen en omzetverlies als gevolg van onnauwkeurige gegevens, beperkte acceptatie of zelfs onnauwkeurige omzetvoorspellingen.
Nieuwe systemen aanschaffen voordat je goed gevestigde bedrijfsprocessen hebt, is als een zaadje planten in onvoorbereide of onvruchtbare grond: het groeipotentieel is aanwezig, maar zonder goede grond (duidelijk gedefinieerde processen) zullen deze nieuwe systemen moeilijk tot bloei komen en positieve resultaten opleveren.
Duplicatie en redundantie in technologie
Technologische redundantie kan ook een belangrijke bron van technische schuld zijn en organisaties voor uiteenlopende uitdagingen stellen. Duplicatie of redundantie in technologie kan worden omschreven als het hebben van twee of meer systemen met vergelijkbare functionaliteit. Deze systemen kunnen onafhankelijk van elkaar worden gebruikt of zelfs met elkaar zijn geïntegreerd.
Dit probleem doet zich vaak voor wanneer organisaties afdelingssilo's hebben. Organisaties die niet investeren in omzetactiviteiten worden doorgaans het zwaarst getroffen door deze specifieke bron van technische schuld.
Het hebben van redundantie in je technologiestack brengt een extra laag complexiteit met zich mee. Deze complexiteit kan problemen veroorzaken, zoals inconsistenties in gegevens, omdat elk systeem zijn eigen uitvoer genereert.
Redundantie in je technologiestack hoeft niet altijd negatief te zijn. Soms maken bedrijven bewust de keuze om systemen met vergelijkbare functies aan te schaffen. Ze kunnen ervoor kiezen om op verantwoorde wijze technische schuld op zich te nemen als afweging om in een kritieke bedrijfsbehoefte te voorzien.
Bedrijven kunnen er bijvoorbeeld bewust voor kiezen om meerdere tools voor gegevensverrijking te gebruiken voor verschillende toepassingen. Je hebt misschien één oplossing voor gegevensverrijking nodig omdat deze een betere dekking biedt voor e-mailadressen en telefoonnummers van contactpersonen. Daarnaast gebruik je mogelijk een andere oplossing voor gegevensverrijking omdat deze een betere dekking biedt voor accountgegevens, zoals de sector waarin een bedrijf actief is of het aantal werknemers.
Als je organisatie strategisch omgaat met het bewust aangaan van deze technische schuld, kan dit de hefboom zijn die nodig is om nieuwe kansen te benutten.
Onsamenhangende technologiestack
Een andere veelvoorkomende bron van technische schuld kan worden toegeschreven aan de manier waarop systemen en oplossingen worden geïntegreerd, of in veel gevallen aan het gebrek aan integratie daartussen. Dit probleem ontstaat wanneer je technologiestack bestaat uit verschillende tools die geïsoleerd werken en niet effectief met elkaar communiceren.
Wanneer verschillende tools binnen je technologiestack niet effectief met elkaar communiceren, ontstaan er hiaten in gegevens en informatie. Je teams zullen steeds meer moeite hebben om toegang te krijgen tot cruciale gegevens en deze te delen, wat tot slechte besluitvorming leidt.
Onsamenhangende systemen zorgen ook vaak voor inefficiënte werkstromen. Denk bijvoorbeeld aan de werkstroom die nodig is om een pas verworven klant over te dragen van je verkooporganisatie naar je klantensuccesteam. Vindt er een naadloze informatieoverdracht plaats tussen deze twee groepen, of is er handmatig werk nodig om gegevens van het ene platform naar het andere over te zetten?
Vaker wel dan niet zoeken bedrijven naar systemen die standaardintegratie bieden met andere tools in hun technologiestack. Wanneer deze integraties niet bestaan, zijn aangepaste configuratie en code nodig om deze systemen met elkaar te verbinden. Deze aangepaste configuratie kan ook een bron van technische schuld zijn, omdat de code intern moet worden bijgehouden en onderhouden.
Samenvatting van de gevolgen van technische schuld
Slechte gegevenskwaliteit - Inconsistente of onnauwkeurige gegevens leiden tot slechte besluitvorming binnen je organisatie.
Slechte klantervaring - Technische schuld kan systemen en processen die op klanten zijn gericht beïnvloeden. Als deze schuld niet wordt afgelost, leidt dit tot zaken als serviceonderbrekingen, niet nagekomen beloften en negatieve ervaringen.
Operationele inefficiënties - Technische schuld die niet wordt gemonitord, zal inefficiënties tussen teams veroorzaken. Een RevOps-team dat toezicht houdt op en processen van begin tot eind implementeert, helpt een deel van de door de schuld veroorzaakte belasting weg te nemen.
Samenwerking en teammoraal - Technische schuld kan ertoe leiden dat teamleden overbelast raken, wat frustratie en een afname van de teammoraal veroorzaakt. Deze afname van de moraal zal de functieoverschrijdende samenwerking verstoren en kan zelfs leiden tot het afschuiven van de schuld tussen verkoop en marketing of verkoop en klantensucces.
Deze gevolgen kunnen, als ze onbehandeld blijven, een aanzienlijke impact hebben op het vermogen van je organisatie om op te schalen. Zorg ervoor dat je deze schuld zorgvuldig monitort en beheert, want de onbedoelde gevolgen ervan kunnen groot genoeg zijn om de groeikoers van een bedrijf jarenlang te veranderen.
5 manieren om technische schuld te beheren
Om technische schuld effectief te beheren, moeten organisaties eerst de omvang van het probleem kunnen herkennen en beoordelen. Hier zijn vijf manieren waarop je organisatie technische schuld voortaan kan identificeren en beheren:
- Voer systeemaudits uit - Begin met het evalueren van de huidige staat van je systemen. Hierbij identificeer je verouderde oplossingen, inefficiënte processen en gebieden waar slechte gegevens worden gegenereerd.
- Geef slechte technische schuld prioriteit - Begin, nadat je je systemen hebt geaudit en verbeterpunten hebt blootgelegd, prioriteit te geven aan de technische schuld die voor je organisatie het kostbaarst wordt. Onthoud dat niet alle schuld gelijk is. Richt je op het verminderen van technische schuld waar omzetverlies het meest problematisch is.
- Wijs middelen toe - Zorg ervoor dat je beschikt over de juiste middelen die nodig zijn om je schuld te beheren. Gebruik bedrijfscycli voor planning om te bepalen voor welke specifieke functies je mensen wilt aannemen en welk budget nodig kan zijn om de negatieve gevolgen van technische schuld te verminderen.
- Implementeer beste werkwijzen - Maak het onderdeel van het DNA van je organisatie om beste werkwijzen toe te passen bij het beheren van je technische schuld. Zorg ervoor dat je deze beste werkwijzen volgt en je team verantwoordelijk houdt voor het niet naleven ervan.
- Zorg voor regelmatig onderhoud - Regelmatig onderhoud is, als onderdeel van je beste werkwijzen, een belangrijke manier om je technische schuld te beheren. Reserveer naast specifieke momenten gedurende het jaar voor onderhoud ook een regelmatig ritme waarin systeemkwetsbaarheden worden beoordeeld en foutoplossingen prioriteit krijgen.
Tot slot…
Om ervoor te zorgen dat organisaties rendement op hun investering in hun technologiepakket behalen, is het belangrijk dat ze de gevolgen van technische schuld begrijpen en deze proactief beheren. Door technische schuld op een systematische manier aan te pakken, kunnen organisaties deze benutten om een concurrentievoordeel binnen hun markt te behalen.
Als je dit artikel interessant vond of het nuttig vond bij het uitleggen van technische schuld, laat het me dan weten in de reacties. Nu je hier toch bent, kun je je ook inschrijven voor de nieuwsbrief van The CRO Club voor de nieuwste inzichten rechtstreeks in je inbox.
