AI-roadmap maken: van experiment naar productie

Vraag tien MKB-bedrijven om hun AI-roadmap en acht ervan overhandigen een gerangschikte lijst: chatbot, dan CV-screening, dan een planningstool, dan iets met facturen. Dat is geen roadmap. Het is een verlanglijst met nummers erbij. Een roadmap is een reeks: wat begint nu, wat moet waar zijn voordat het volgende begint, en wat betekent productie eigenlijk voor het eerste item voordat je aan het tweede begint.

Waarom gerangschikte lijsten stilletjes falen

Een gerangschikte lijst gaat ervan uit dat elk item op zichzelf staat, en dat het afronden van nummer een niets te maken heeft met of nummer twee slaagt. In de praktijk is precies het omgekeerde bijna altijd waar. De CV-screeningtool op plek twee heeft schone, gestructureerde kandidaatdata nodig, en als de chatbot op plek een er nooit voor zorgde dat iemand daadwerkelijk vastlegde wat klanten vragen, heeft plek een niets opgeleverd van de spierkracht die plek twee nodig heeft. Gerangschikte lijsten zien er georganiseerd uit op een slide en vallen uiteen zodra iemand vraagt "wat verandert er maandag."

AI-roadmap, zoals wij die elders op de site definieren, legt vast welke toepassingen een organisatie gaat bouwen, in welke volgorde, en wat elke stap vraagt aan mensen, data en besluiten. De volgorde en de vereisten zijn geen versiering. Ze zijn de daadwerkelijke inhoud van het plan. Een roadmap zonder die twee is een lijst.

Het ritme: klein beginnen, waarde bewijzen, dan verder bouwen

Radicals eigen werkritme voor elke roadmap die wij helpen bouwen is hetzelfde drieledige patroon, toegepast per item, niet eenmalig voor het hele plan: klein beginnen, waarde bewijzen, verder bouwen. Niet omdat het een leuke leus is, maar omdat elke stap een vraag beantwoordt waar de volgende stap van afhangt.

Klein beginnen betekent een enkel smal, afgebakend gebruik binnen een team kiezen, niet "AI voor klantenservice" maar "AI stelt het eerste antwoord op een retourvraag op, een mens verstuurt het nog." Smal genoeg om binnen weken te draaien, niet kwartalen, en smal genoeg dat als het mislukt, het goedkoop en zichtbaar mislukt in plaats van stilletjes binnen een integratieproject van zes maanden.

Waarde bewijzen betekent iets concreets meten voordat je beslist over uitbreiden: hoeveel antwoorden stelde de tool op, hoeveel moesten zwaar bewerkt worden, hoeveel tijd bespaarde het team daadwerkelijk versus hoeveel tijd staken ze in correctie. Dit is de stap waar de meeste roadmaps stilletjes sterven, niet omdat de tool faalde, maar omdat niemand vooraf definieerde hoe "het werkte" eruit zou zien, dus kan niemand achteraf zeggen of het zo was.

Verder bouwen begint pas zodra de tweede stap een antwoord heeft. Dat kan betekenen dezelfde tool verbreden naar een tweede team, of het antwoord kan zijn geweest "het bespaarde vier minuten per ticket maar brak drie keer het vertrouwen van klanten," in welk geval verder bouwen betekent het specifieke falen repareren, niet het hele idee verdubbelen.

Twee mensen bij een whiteboard. Een bruikbare roadmap noemt per stap een eigenaar en een datum.

Wat "productie" eigenlijk betekent

Productie betekent niet indrukwekkend. Het betekent dat het gereedschap draait zonder dat iemand van Radical, of van je eigen AI-enthousiaste medewerker, ernaast zit om output met de hand te corrigeren. Een demo die prachtig werkt in een vergaderkamer met de bouwer erbij is niet in productie. Een tool die een nieuwe medewerker uit documentatie kan oppikken, die een bekend faalgedrag heeft met een bekend vangnet, en die blijft draaien als de bouwer op vakantie is, is in productie.

Dat onderscheid is specifiek belangrijk voor de roadmap omdat het bepaalt wat telt als "klaar" voor stap een voordat stap twee mag beginnen. Dit overslaan is de meest voorkomende reden waarom een roadmap na een jaar vijf items heeft staan en er nul daadwerkelijk draaien: alles is permanent "bijna in productie," dus er komt nooit aandacht vrij voor het volgende item.

Een roadmap-regel, geschreven zoals het hoort

Een bruikbare roadmap noemt per stap een eigenaar en een datum, niet per project. Concreet ziet een regel in een echte roadmap er zo uit:

"Item: door AI opgesteld eerste antwoord voor retourvragen. Eigenaar: teamleider klantenservice. Start: week van 7 september. Bewijs vereist op 5 oktober: gemiddelde conceptduur onder de 90 seconden, menselijk bewerkingspercentage onder de 30 procent, nul klachten van klanten herleidbaar tot het concept. Beslismoment: 5 oktober, uitbreiden naar verzendvragen of eerst het bewerkingspercentage repareren."

Vergelijk dat met "chatbot voor klantenservice, Q3." De tweede versie kan niet worden gecontroleerd, kan niet worden geblokkeerd, en kan niemand in oktober vertellen of het is gelukt. De eerste versie kan door iedereen worden gecontroleerd, ook door iemand die er niet bij was toen hij werd geschreven.

Een monitor in een schemerig kantoor. Productie betekent dat het gereedschap draait zonder dat iemand van Radical erbij zit.

De meest voorkomende manier waarop roadmaps helemaal worden overgeslagen

Het faalgedrag dat wij het vaakst zien is niet een slecht geschreven roadmap, het is helemaal geen roadmap, vervangen door wat voor tool een adviseur het meest recent liet zien. Een bedrijf krijgt een indrukwekkende chatbot-pilot te zien, vindt hem leuk, en begint hem te bouwen zonder ooit te vragen of een chatbot het eerste ding was dat gebouwd had moeten worden, of gewoon het eerste ding dat toevallig werd gepitcht. Dit is dezelfde valkuil als in Waarom een adviesrapport geen capability is: een overtuigende eenmalige demo is geen bewijs dat een item bovenaan de lijst hoort, alleen dat het mogelijk is om te bouwen.

Een roadmap dwingt de omgekeerde vraag af voordat er iets wordt gebouwd: gegeven alles wat dit bedrijf plausibel zou kunnen automatiseren, wat is het ene item waar klein beginnen het minste kost en het meeste bewijst? Dat is een volgordebeslissing, en die moet plaatsvinden voordat een specifiek gereedschap wordt gekozen, niet erna.

Waarom dit verschilt van een projecttijdlijn

Een projecttijdlijn gaat ervan uit dat het werk bekend is en het risico de uitvoeringssnelheid is. Een AI-roadmap gaat uit van het omgekeerde: de grootste onzekerheid is of een bepaalde toepassing daadwerkelijk waarde levert zodra echte gebruikers ermee werken, niet hoe snel een team de code kan bouwen. Daarom eindigt elke stap in een beslismoment in plaats van een opleverdatum. Een projectplan zegt "lancering op 5 oktober." Een roadmap zegt "beslis op 5 oktober, op basis van wat we daadwerkelijk gemeten hebben, of dit uitbreidt of eerst gerepareerd wordt." De tweede formulering is minder comfortabel om in een slidedeck te presenteren en aanzienlijk waarschijnlijker om daadwerkelijk gevolgd te worden, omdat hij niet doet alsof hij in augustus al weet wat in oktober waar zal zijn.

Verlanglijst versus roadmap-regel, naast elkaar

Het onderzoek van RAND Corporation uit 2024 naar het falen van AI-projecten liet zien dat het merendeel van de AI-pilots nooit productie bereikt, en de grondoorzaken die het onderzoek benoemt zijn organisatorisch, niet technisch: onduidelijk eigenaarschap, geen afgesproken definitie van succes, en geen beslisproces voor wat er na een pilot gebeurt. Dat zijn precies de drie gaten die een verlanglijst openlaat en een roadmap-regel per constructie sluit. Een roadmap voorkomt niet elk falen, maar hij maakt falen zichtbaar en specifiek in plaats van stil en permanent.

Over deze pagina

De roadmap-definitie hierboven (eigenaar, datum, vereiste per stap) komt overeen met de bestaande AI-roadmap definitiepagina op deze site. Het ritme klein beginnen, waarde bewijzen, verder bouwen is Radicals eigen werkmethode, geen extern raamwerk. De verwijzing naar faaloorzaken komt uit het RAND Corporation-rapport hieronder geciteerd. Geschreven door Radicals eigen team; er is geen klantdata gebruikt.