Navigeren door de AI-goudkoorts: het blootleggen van de verborgen kosten van technische schuld in ondernemingsavonturen

Over het afgelopen jaar heeft artificial intelligence de aandacht van ondernemingsleiders getrokken, waardoor ze hun investeringen in AI-bedrijven hebben versneld of de introductie van hun eigen producten hebben versneld om bij te blijven. Echter, in de haast om deel te nemen aan deze nieuwe era van technologische vooruitgang, kunnen organisaties die nieuw zijn in AI één belangrijk aspect over het hoofd zien dat bovenaan de lijst moet staan bij het investeren of creëren van nieuwe AI-producten: technische schuld.

Hoewel het idee van technische schuld niet nieuw is, brengt AI-technologie een andere soort technische schuld met zich mee in vergelijking met reguliere software-diensten. En aangezien AI snel blijft verbeteren, zorgt dit voor een belangrijk probleem dat samen met het groeit.

Wat is technische schuld?

Technische schuld, in de eenvoudigste definitie, is de opeenstapeling van slechte kwaliteit code tijdens de creatie van een stuk software. Dit komt meestal voort uit een versnelde go-to-market-tijdlijn om bedrijfsbehoeften te vervullen, of om iets op de markt te brengen om sneller klantfeedback te krijgen. Wanneer men technische schuld overweegt, is het belangrijk om zich te concentreren op het bewuste aspect ervan, aangezien beslissers vaak op de hoogte zijn van de risico’s met software en de gevolgen van het nemen van shortcuts voor snelheid. De opkomst van AI heeft een andere en unieke uitdaging gebracht met betrekking tot technische schuld, en daarmee significante risico’s en gevolgen die zouden kunnen resulteren.

Naarmate AI-systemen ouder worden en hun trainingsdata onnauwkeurig en verouderd worden, wegen de kosten van investeren in AI nu zwaarder dan de tijd en investering die nodig zijn om hoge kwaliteit trainingsdata te onderhouden, ook wel bekend als data-hygiëne.

Laten we onderzoeken hoe technische schuld wordt opgebouwd, de impact die het heeft op de bodemlijn en hoe organisaties het kunnen verhelpen.

Hoe verkrijgen organisaties technische schuld?

 Er zijn twee manieren waarop software technische schuld kan opbouwen. De ene is door gewoon slechte code. Organisaties kunnen producten kopen of erven via M&A-activiteit, om later kwaliteitsproblemen te ontdekken bovenop trage tarieven van verandering en innovatie. De andere is wanneer leiders bewust kiezen om technische schuld aan te gaan.

Wanneer het gaat om AI, willen meer dan 72% van de leiders AI adopteren om de productiviteit van medewerkers te verbeteren, maar de belangrijkste zorg bij de implementatie van AI is gegevenskwaliteit en -controle. Het lijkt tegenstrijdig voor een organisatie om een product te gebruiken dat de productiviteit moet verbeteren, terwijl tegelijkertijd tijd wordt afgeleid van het vitale werk om voortdurend alle kwaliteitsproblemen die door technische schuld worden veroorzaakt te verhelpen, die de productiviteit in gevaar kunnen brengen. Maar de belofte van de uiteindelijke opbrengst voor verhoogde productiviteit weegt zwaarder dan deze obstakels in de nabije toekomst, die uiteindelijk terug zullen komen om de software in de loop van de tijd te achtervolgen.

Model Drift: een nieuwe soort technische schuld

Met de opkomst van toenemende investeringen in AI, hebben organisaties haast gemaakt met go-to-market-strategieën om in te cashen op de generatieve AI-goudmijn. Hoewel dit op korte termijn als een omzetdrijver kan werken, zien organisaties over het hoofd wat een grote hoeveelheid technische schuld kan zijn in de toekomst, bekend als model drift.

Model drift treedt op wanneer de prestaties van een AI-systeem beginnen af te nemen en de uitvoer minder nauwkeurig wordt naarmate de trainingsdata verouderen. Als we naar de AI-levenscyclus kijken, is het duidelijk dat de trainingsdata voortdurend moeten worden onderhouden en bijgewerkt om ervoor te zorgen dat de antwoorden die de machine biedt zo nauwkeurig mogelijk zijn – hier begint de breuk. Wanneer men haast heeft om oplossingen te leveren, geven beslissers vaak prioriteit aan zaken zoals het verkrijgen van extra trainingsdata, het onderhouden van de gegevenshygiëne van het systeem en het garanderen dat er een werkkracht is die deze taken kan ondersteunen.

Naarmate de trainingsdata ouder worden en de kloof tussen realiteit en uitvoer groter wordt, zullen organisaties worden geconfronteerd met verhoogde kosten en tijd die worden besteed aan het verhelpen van deze lacunes die hadden kunnen worden voorkomen met een goede planning en procedures.

Impact van technische schuld op de bodemlijn

Technische schuld kan ook diep ingrijpen op de efficiëntie van organisaties – bijvoorbeeld bij verkoopteams. Wanneer technische schuld begint op te bouwen en de veranderingssnelheid vertraagt, wordt het steeds moeilijker voor verkopers om klanten te overtuigen, wat de sluitingspercentages en uiteindelijk de omzetstroom vertraagt.

Verder heeft technische schuld ook een grote invloed op ontwikkelaarsteams. Niet alleen zal het meer tijd kosten om code bij te werken, maar de aandacht die wordt afgeleid, zet innovatie effectief op de achtergrond. Door de aandacht en tijd te verschuiven naar onderhoud, wordt de productroadmap vertraagd of opgegeven, waardoor een ripple-effect ontstaat dat uiteindelijk kan leiden tot wantrouwen tussen de technische en commerciële kant van het bedrijf. Zonder productroadmap om te volgen, worden verkoopteams geconfronteerd met gebroken beloften of niets om aan prospects te laten zien, wat opnieuw de omzet aantast.

Hoe technische schuld aan te pakken

Naarmate de voorspelbaarheid van levering afneemt, zullen organisaties beginnen te zien dat de organisatorische efficiëntie afbreekt, waardoor gesprekken ontstaan over hoe de uitdagingen aan te pakken. Er zijn twee manieren waarop beslissers technische schuld kunnen bestrijden. De eerste is door het platform en de code volledig weg te gooien en opnieuw te platformen, of door kleine incrementele veranderingen aan te brengen, vergelijkbaar met het langzaam schoonmaken van een slaapkamer, om uiteindelijk de systemen up-to-date te krijgen.

De eerste methode, re-platformisatie, vereist een complete revisie van de systemen en is een groot en kostbaar risico om te nemen. Vergelijkbaar met een groot bouwproject, kunnen vertragingen in de planning de productietijden in de war sturen en kunnen ze de hele inspanning laten mislukken. Deze methode kan soms werken. Neem LinkedIn als voorbeeld – na hun IPO in 2011, heeft het bedrijf het platform opnieuw ingericht en is het nu een grote speler op de markt.

De veiligere optie, het maken van kleine veranderingen die uiteindelijk tot grote verbeteringen zullen leiden, is een ander gebruiksscenario om voor te pleiten. Aangezien ontwikkelaars al dagelijks met gegevens werken, kunnen ze kleine aanpassingen maken om de systemen te verbeteren en technische schuld te verminderen. Het biedt ook voordelen voor de vaardigheden van ontwikkelaars, aangezien het hen dwingt om up-to-date te blijven met de nieuwste code- en technologiestandaarden, waardoor een organisatie minder vaardigheidslacunes heeft. Het implementeren van een door ingenieurs geleide initiatief, waarbij ze 20% van hun tijd toewijden aan het plannen van productupdates, is een goede manier om te beginnen. Hoewel dit proces veel langzamer is dan re-platformisatie, is het minder riskant en levert het nog steeds waarde voor het bedrijfsmodel.

Laat uw technische schuld achter in de tijdperk van AI

Naarmate de AI-ruimte blijft snel ontwikkelen, zullen we meer oplossingen zien ontstaan die productiviteitswinsten en organisatorische efficiëntie beloven. Hoewel dit waar is, moeten beslissers prioriteit geven aan het integreren van technieken zoals voortdurend onderhoud van gegevens en nadenken over het grote plaatje wanneer het gaat om de levenscyclus van uw oplossing. Investeren in AI hoeft niet duur en overweldigend te zijn, en met een paar kleine veranderingen in planning en go-to-market-strategie, kunt u de volgende berg technische schuld vermijden.