Terugkrabbelen bij AI: echte verhalen van leiders
Lessen uit AI: Veel leiders zien de waardevolle lessen uit mislukte of stilgelegde AI-projecten over het hoofd, terwijl die cruciale inzichten opleveren.
Pauzeren in plaats van doorduwen: Bedrijven hebben er vaak baat bij AI-initiatieven te pauzeren om de onderliggende processen en de kwaliteit van de gegevens op orde te brengen.
Eerst handmatig: Automatisering mag pas volgen nadat iets handmatig is uitgevoerd, zodat processen duidelijk zijn gedefinieerd en begrepen.
Impact meten: De sleutel tot succes is het beoordelen van bestaande processen en de mogelijke impact van AI voordat de implementatie begint.
Het belang van documentatie: Effectieve documentatie moet niet alleen processen vastleggen, maar ook de redenen achter beslissingen en uitzonderingen.
De meeste verhalen over AI-adoptie worden verteld vanaf het erepodium. Veel minder leiders praten over het moment waarop ze de stekker eruit trokken — de automatisering die werd geannuleerd, de uitrol die werd gepauzeerd, de pilot die vanaf nul moest worden herbouwd. Maar juist in die verhalen zitten vaak de echte lessen.
We vroegen het aan drie experts die dit hebben meegemaakt: wat werd ongedaan gemaakt, waarom, en wat zou je anders doen? Hun antwoorden komen samen in een verrassend consistent thema — het probleem ligt bijna nooit bij de AI zelf.
Wanneer het verstandig is om te pauzeren in plaats van door te zetten
Voor de meeste organisaties is het volledig terugdraaien van een AI-investering niet realistisch zodra het geld eenmaal is uitgegeven. Tejinder, senior manager bij Deloitte Consulting, zegt ronduit dat volledige verwijdering geen optie was gezien de al gedane investeringen — maar een weloverwogen pauze wel. Toen de resultaten niet aan de verwachtingen voldeden, deed zijn team een stap terug en “keek eerst naar de basis”, waarbij ze zich afvroegen of de onderliggende processen waren ingericht, of “de datakwaliteit” “goed” was en of planners de rol van agenten ten opzichte van hun eigen rol begrepen. “Ik denk dat reactivering eenmaal logisch was toen die vragen waren beantwoord”, zegt hij.
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
Priyanka Dave, PhD, leider voor bijscholing en eigenaar van het leerproces aan Oregon State University, heeft hetzelfde patroon herhaaldelijk zien terugkomen. “Ik heb gezien dat verschillende organisaties er bewust voor kozen om de uitbreiding van AI-initiatieven uit te stellen nadat ze hadden vastgesteld dat ze operationeel nog niet klaar waren.” In die gevallen was de terugtrekking geen mislukking — het was een koerswijziging. “In plaats van AI onmiddellijk uit te breiden, verlegde de leiding haar aandacht naar het versterken van de organisatorische basis”, legt Dave uit. Dit betekende dat “organisaties investeerden in het documenteren van bedrijfsprocessen, het standaardiseren van werkstromen, het verbeteren van datagovernance en het ontwikkelen van de vaardigheden van medewerkers door middel van gestructureerd leren en verandermanagement.”
In plaats van AI onmiddellijk uit te breiden, verlegde de leiding haar aandacht naar het versterken van de organisatorische basis.
Automatiseer niet wat je nog niet handmatig hebt gedaan
Soms betekent teruggaan dat je een project volledig annuleert — en ontdekt dat dit al die tijd de juiste beslissing was. Jaime Gil Martinez, oprichter en hoofdconsultant bij Swift Ops Solutions, leerde dit op de harde manier. “Ik heb ooit een automatisering gebouwd om marketingmateriaal te produceren voor een klant die het proces nooit handmatig had uitgevoerd”, vertelt hij. “Omdat het nieuw voor hen was, dachten we allebei dat het beter was om het vanaf nul geautomatiseerd op te bouwen. Op papier klopte dat. Achteraf gezien was het een beginnersfout.”
Het systeem functioneerde technisch gezien. “De automatisering werkte”, zegt Gil Martinez. “Het probleem was dat er telkens wanneer er een uitvoer nodig was iets opnieuw moest worden overwogen of aangepast (een ander doelpubliek, een ander formaat, een andere lay-out), dus bleef ik het systeem herbouwen. Na een paar van zulke rondes was het patroon duidelijk – ik automatiseerde een proces dat nog door niemand was gedefinieerd.”
Na een paar rondes [van aanpassingen] was het duidelijk dat ik een proces automatiseerde dat nog door niemand was gedefinieerd.
De oplossing was om terug te gaan. “Dus annuleerden we het project volledig en gingen we de materialen weer met de hand produceren”, zegt hij. “Dat bleek precies het punt te zijn: elke handmatige ronde leverde ons wat we hadden gemist, namelijk voorbeelden van de gouden standaard en een duidelijk beeld van wat varieerde en wat niet. Later hervatten we de automatisering, en die handmatige uitvoer werd de kennisbank die we aan de AI gaven.” Deze ervaring leverde een regel op die hij nu toepast binnen zijn eigen bedrijf en bij zijn klanten: “automatiseer niets voordat je het minstens drie keer handmatig hebt gedaan. Daarna kun je het gaan overwegen.”
De stap die iedereen overslaat: meten voordat je bouwt
Vraag Gil Martinez wat de meeste AI-adoptieplannen missen, en zijn antwoord komt onmiddellijk: “Meten voordat je bouwt. De meeste bedrijven missen twee cijfers op het moment dat ze beginnen: hoe goed of slecht hun huidige proces daadwerkelijk is, en welke impact AI er realistisch gezien op kan hebben. Zonder beide kun je niet bepalen hoe effectief je implementatie was of of de kosten gerechtvaardigd waren.”
Hij verwijst naar een zorgkliniek die het plannen van afspraken wilde automatiseren voor meer dan 100 patiënten. “Ze wisten niet hoe lang het hen kostte, alleen dat het tijdrovend en frustrerend was,” zegt hij. “En als je niet weet hoe lang iets duurt, weet je ook niet hoeveel het je kost.” Voordat hij iets bouwde, was zijn eerste stap daarom het berekenen van het aantal uren dat het plannen in beslag nam en de financiële waarde van die uren. “Dat gaf ons de nulmeting: twee weken volledig handmatig werk. De automatisering bracht dat terug tot één dag AI-ondersteund werk, tegen lagere kosten dan hun huidige vergelijkbare uitgaven.” Met die cijfers bij de hand “maakte de beslissing zichzelf.”
Dave ziet een andere, maar minstens zo cruciale omissie: gereedheid draait niet alleen om de technologie. “De stap die organisaties naar mijn ervaring het vaakst overslaan, is het beoordelen van de capaciteiten van hun personeel voordat ze AI implementeren,” zegt ze. En de tekortkomingen blijken zelden over training in het gebruik van tools te gaan. In verschillende capaciteitsbeoordelingen “brachten de beoordelingen consequent aan het licht dat de grootste capaciteitskloven lagen op het gebied van analytisch denken, kritisch denken, datageletterdheid, adviserende communicatie en probleemoplossing.” Haar conclusie: “Technologische gereedheid en de gereedheid van het personeel zijn verschillende uitdagingen. Duurzame AI-adoptie vereist beide.”
Wat er gebeurt wanneer AI terechtkomt in een proces dat er niet klaar voor is
Wat gaat er daadwerkelijk mis wanneer AI wordt toegevoegd aan een onvolwassen proces? Tejinder zag het uit eerste hand toen “AI werd ingebed in een bedrijfsproces (orderverwerking en toewijzingen) dat niet volwassen genoeg was” — het resultaat was een oplossing vol bugs. Maar hij maakt duidelijk waar de oorzaak lag: “Ik geloof niet dat AI hier het probleem was,” zegt hij, waarbij hij in plaats daarvan wijst op de volwassenheid van het proces, problemen met stamgegevens, niet-afgesloten hiaten in de vereisten en onvoldoende testen.
AI werd ingebed in een bedrijfsproces (orderverwerking en toewijzingen) dat niet volwassen genoeg was.
Dave beschrijft dezelfde dynamiek in haar beoordelingen: verschillende afdelingen die hetzelfde werk op verschillende manieren uitvoeren, onvolledige documentatie en uitzonderingen die alleen in het hoofd van medewerkers bestaan. “De zorg was dat AI simpelweg inconsistente werkwijzen binnen de organisatie zou reproduceren,” zegt ze. Het is een gevolg van een principe waar ze vaak op terugkomt: “AI lost organisatorische problemen niet op. Het versterkt bestaande systemen. Als processen inconsistent of slecht gedocumenteerd zijn, zal AI die inconsistenties vaak opschalen in plaats van ze te verbeteren.” De conclusie, in haar woorden: “De terugkerende les was dat organisaties processen moeten verbeteren voordat ze proberen ze te automatiseren.”
Als processen inconsistent of slecht gedocumenteerd zijn, zal AI die inconsistenties vaak opschalen in plaats van ze te verbeteren.
Gil Martinez heeft hier zijn eigen littekens aan overgehouden — een applicatie voor leadgeneratie die “de eerste keer dramatisch mislukte”. De bouw ging van semihandmatig naar volledig geautomatiseerd zonder vastgelegde vereisten of tests. “Mijn fout was dat ik ervan uitging dat AI een deel van de logica zelf zou uitzoeken, omdat de logica vanzelfsprekend en eenvoudig leek,” geeft hij toe. Vanaf dat moment liep het mis. “De code werd onbeheersbaar en was volledig eigendom van AI, tot het punt waarop ik niet meer kon terugkeren naar een veilige mijlpaal. Dat was het moment waarop ik wist dat het structureel kapot was, en niet alleen bugs bevatte.”
Het herstel vereiste een volledige reset. “De oplossing was even pijnlijk als voor de hand liggend: opnieuw beginnen,” zegt hij. “Deze keer beschreef ik elke vereiste en een test voor elke vereiste, bouwde ik stapsgewijs en gaf ik AI duidelijke instructies om fouten en successen te loggen, samen met goed versiebeheer.” De gedisciplineerde tweede poging “kostte ongeveer de helft van de tijd die ik aan de eerste poging had verspild om een werkbare oplossing van productiekwaliteit te bereiken.”
Hoe goede documentatie voor AI er daadwerkelijk uitziet
Onder al deze drie verhalen ligt dezelfde oplossing: documentatie die vastlegt hoe werk daadwerkelijk wordt uitgevoerd. Voor Dave betekent dat verder gaan dan takenlijsten. “Goede procesdocumentatie legt niet alleen uit wat mensen doen, maar ook waarom ze bepaalde beslissingen nemen,” zegt ze. En het meest waardevolle materiaal is meestal wat nooit wordt opgeschreven. “Een van de meest voorkomende fouten die organisaties maken, is dat ze alleen de standaardwerkstroom documenteren. De grootste organisatorische kennis bevindt zich vaak in de uitzonderingen, afwegingen en contextuele beslissingen die ervaren medewerkers nemen.”
Gil Martinez bekijkt het door een bril die PM's steeds vaker zullen herkennen: “Goede procesdocumentatie weerspiegelt promptengineering. Dezelfde elementen die we AI in een prompt leren meegeven (rol, context, taak, instructies, beperkingen), zouden ook op projectniveau zichtbaar moeten zijn.” Die verschuiving heeft gevolgen voor de manier waarop professionals hun tijd besteden. “De uitvoeringstijd voor mensen verdwijnt en wordt uitbesteed aan AI, dus onze focus moet verschuiven naar goed plannen en het valideren van resultaten. We moeten ons gedragen als AI-managers.”
Conclusie: de volgorde is de strategie
Geen van deze leiders betreurt de investering in AI. Waar ze wel spijt van hebben — of anderen spijt van zagen krijgen — is de volgorde van de stappen. Tejinder vat het samen: “De invoering van AI in ondernemingen mislukt wanneer het model wordt ingezet voordat de operationele basis op orde is. De juiste volgorde is eerst procesvolwassenheid, datakwaliteit en duidelijkheid over rollen. Daarna AI. Wanneer organisaties die volgorde omdraaien, geven ze de AI de schuld, terwijl het onderliggende probleem bijna altijd de omgeving is waarin de AI terechtkwam.” Terugkrabbelen blijkt dus niet de mislukking te zijn. Inzetten voordat je er klaar voor bent wel.
Wil je meer inzichten zoals deze? Meld je aan voor een gratis DPM-account om van meer experts zoals deze te horen.
