Thought leaders
De AI-goudkoorts navigeren: de verborgen kosten van technische schuld in ondernemingsavonturen

In het afgelopen jaar heeft artificial intelligence de aandacht van ondernemingsleiders getrokken, waardoor ze hun investeringen in AI-bedrijven hebben versneld of hun eigen producten hebben geïntroduceerd om bij te blijven. Echter, in de haast om deel te nemen aan deze nieuwe era van technologische vooruitgang, kunnen ondernemingen 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 concept 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, veroorzaakt dit een belangrijk probleem dat samen met AI groeit.
Wat is technische schuld?
Technische schuld, in de eenvoudigste definitie, is de opeenstapeling van slechte code tijdens de creatie van een software-product. Dit komt meestal voort uit een versnelde go-to-market-tijdlijn om bedrijfsbehoeften te vervullen, of om sneller klantfeedback te verkrijgen. Wanneer men technische schuld overweegt, is het belangrijk om de bewuste aspecten ervan te benadrukken, 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 met zich meegebracht met betrekking tot technische schuld, en daarmee aanzienlijke risico’s en gevolgen die 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 data-hygiëne genoemd.
Laten we onderzoeken hoe technische schuld wordt opgebouwd, de impact ervan op de onderste regel en hoe ondernemingen dit kunnen verhelpen.
Hoe verkrijgen ondernemingen technische schuld?
Er zijn twee manieren waarop software technische schuld kan opbouwen. De ene is door gewoon slechte code. Ondernemingen kunnen producten kopen of erven via M&A-activiteiten, om later te ontdekken dat er kwaliteitsproblemen zijn, bovenop trage veranderingen en innovatie. De andere is wanneer leiders bewust kiezen om technische schuld op zich te nemen.
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 datakwaliteit en -controle. Het lijkt tegenstrijdig voor een onderneming om een product te gebruiken dat productiviteit moet verbeteren, terwijl ze tegelijkertijd tijd wegnemen van het vitale werk om continue kwaliteitsproblemen aan te pakken die door technische schuld worden veroorzaakt en die productiviteit in gevaar kunnen brengen. Maar de belofte van de uiteindelijke opbrengst voor verbeterde productiviteit weegt deze hindernissen in de nabije toekomst tegen, die uiteindelijk terug zullen komen om de software op de lange termijn te achtervolgen.
Model Drift: een nieuwe soort technische schuld
Met de opkomst van grotere investeringen in AI, hebben ondernemingen haastig go-to-market-strategieën om in te spelen op de generatieve AI-goudmijn. Hoewel dit als korte-termijn-omzetstuurder kan werken, kijken ondernemingen over het hoofd wat een grote hoeveelheid technische schuld kan zijn in de toekomst, bekend als modeldrift.
Modeldrift 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 continu moeten worden onderhouden en bijgewerkt om ervoor te zorgen dat de antwoorden die de machine geeft zo nauwkeurig mogelijk zijn – hier begint de breuk. Wanneer men haast heeft om oplossingen te introduceren, geven beslissers vaak prioriteit aan problemen zoals het verkrijgen van extra trainingsdata, het onderhouden van de data-hygiëne van het systeem en het garanderen van een workforce die voldoende mensen heeft om deze taken te ondersteunen.
Naarmate de trainingsdata ouder worden en de kloof tussen realiteit en uitvoer groter wordt, zullen ondernemingen worden geconfronteerd met hogere kosten en meer tijd die wordt besteed aan het aanpakken van deze lacunes die hadden kunnen worden voorkomen met behulp van een goede planning en protocollen. Kortom: het overslaan van de volgende stap bij het plannen van een go-to-market-strategie kan snellere levering mogelijk maken, maar het is niet waard de onvermijdelijke terugval die op verschillende manieren op lange termijn zal kosten.
De impact van technische schuld op de onderste regel
Technische schuld kan ook diep ingrijpen op de efficiëntie van ondernemingen – bijvoorbeeld bij verkoopteams. Wanneer technische schuld begint op te bouwen en de veranderingssnelheid vertraagt, wordt het steeds moeilijker voor verkoopafdelingen om klanten aan te trekken, waardoor de sluitingspercentages en uiteindelijk de omzetstromen vertragen als gevolg.
Verder dan verkoop heeft technische schuld ook een grote invloed op ontwikkelaarsteams. Het zal niet alleen 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 kettingreactie kan ontstaan die uiteindelijk kan leiden tot wantrouwen tussen de technische en commerciële kant van het bedrijf. Zonder een productroadmap om te volgen, worden verkoopafdelingen geconfronteerd met gebroken beloften of niets om aan prospects te laten zien, waardoor de omzet opnieuw wordt beïnvloed.
Hoe technische schuld aanpakken
Naarmate de voorspelbaarheid van levering afneemt, zullen ondernemingen beginnen te zien dat de efficiëntie van de organisatie afneemt, wat leidt tot gesprekken over hoe de uitdagingen aan te pakken. Er zijn twee manieren waarop beslissers technische schuld kunnen aanpakken. De eerste is het weggooien van het platform en de code helemaal en het opnieuw platformen, of het invoeren van kleine incrementele veranderingen, soortgelijk aan het langzaam schoonmaken van een slaapkamer, om uiteindelijk de systemen up-to-date te krijgen.
De eerste methode, re-platformisatie, vereist een complete overhauling van uw systemen en is een enorm en kostbaar risico om te nemen. Vergelijkbaar met een groot bouwproject, kunnen vertragingen in de planning de productietijdlijnen 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 nu een grote speler op de markt.
De veiligste weddenschap, het maken van kleine veranderingen die uiteindelijk grote verbeteringen zullen opleveren, is een ander gebruiksscenario om voor te pleiten. Aangezien ontwikkelaars al dagelijks met data omgaan, kan het maken van kleine aanpassingen hier en daar de systemen helpen om hun technische schuld kwijt te raken. Het heeft ook voordelen voor de vaardigheden van ontwikkelaars, aangezien het van hen vereist om up-to-date te blijven met de laatste code- en technologiestandaarden, wat op zijn beurt een onderneming in staat stelt om technisch succes te behalen, omdat ze minder vaardigheidslacunes hebben. Het invoeren van een door ingenieurs geleide initiatief, waarbij ze 20% van hun tijd toewijzen aan het plannen van productupdates, is een goede manier om te beginnen. Hoewel dit proces veel langzamer is dan re-platformen, is het minder riskant en levert het nog steeds waarde op voor het bedrijfsmodel.
Laat uw technische schuld achter in de AI-tijdperk
Naarmate de AI-ruimte blijft snel evolueren, zullen we steeds meer oplossingen zien ontstaan die productiviteitswinsten en organisatorische efficiëntie beloven. Hoewel dit waar is, moeten beslissers technieken prioriteren zoals continue datamaintenance 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.












