Een use case afbakenen

De vraag wat jullie met AI kunnen, levert zelden een eerste project op. De vraag die dat wel doet is kleiner: welke route legt bij ons zo vaak hetzelfde rondje af dat iedereen het voelt. Een use case is die route, met een begin, een eind en iemand die er last van heeft.

Daarom beginnen wij niet met een inventarisatie van de hele organisatie, maar met één route: hoe vaak hij langskomt, wat hij kost en wie hem elke keer loopt. Een lijst van veertig kansen levert die drie antwoorden niet op.

De eerste twee signalen zijn volume en herhaling. Iets dat dagelijks of wekelijks langskomt en niet per kwartaal, en dat elke keer dezelfde stappen in dezelfde volgorde aflegt: er komt iets binnen, iemand zoekt iets op, neemt iets over en boekt het. De winst van een automatisering is de winst per keer maal het aantal keren, en dat tweede getal doet het meeste werk.

Daarna komt de vraag of de regels hardop te zeggen zijn. Niet dat iemand er even naar kijkt, maar: als het factuurnummer overeenkomt en het bedrag binnen de marge valt, dan boeken. Uitzonderingen mogen er zijn, zolang je kunt benoemen wanneer je in een uitzondering zit. Kun je het aan een nieuwe collega uitleggen zonder erbij te gaan zitten, dan kun je het ook in code zetten.

Verder helpt het als iemand de uren kan noemen. Kan niemand in het bedrijf zeggen hoe lang dit werk kost, dan is dat op zichzelf al informatie: meestal ligt het over veel mensen verspreid, en dan is tellen de eerste stap en bouwen de tweede.

En er moet iemand zijn die het wil. Een route zonder eigenaar levert geen antwoorden op zodra er tijdens het bouwen een vraag opkomt, en die vragen komen. De beste eerste case is er een waarbij de persoon die het werk nu doet af en toe naast je komt zitten.

Tel hoe vaak de route per week loopt en hoeveel minuten hij kost bij de mensen die hem lopen. Twintig keer per week, twaalf minuten per keer, is vier uur. Dat is de bovengrens van wat er te winnen valt, want er blijft altijd nakijkwerk over.

Kies daarna een getal dat je achteraf kunt controleren. Uren zijn te tellen. Meer grip en minder ruis zijn dat niet, en een project dat daarop is verkocht eindigt in een discussie die niemand kan winnen. Noem dat getal in het diagnosegesprek, dan weet je zelf waar je twee weken later naar kijkt.

Het duidelijkste voorbeeld is de route die vijf afdelingen raakt en aan drie systemen hangt die niet van elkaar weten. Daar valt op termijn het meeste te halen, en precies daarom is hij als eerste project verkeerd: je bent maanden bezig voordat iemand iets ziet werken, en tegen die tijd klopt de helft van de aannames niet meer.

Lastiger te zien is de route waarvan de regels in het hoofd van één persoon zitten en per klant anders zijn. Die is te bouwen, maar dan begint het project met het opschrijven van die regels, en dat is een ander project met een andere doorlooptijd. Zeg dat vooraf, dan is het een keuze in plaats van een tegenvaller.

En dan is er de categorie zonder route: een AI-strategie, een innovatietraject, een pilot zonder eigenaar. Wat daar misgaat is bijna nooit het model, maar een vraag die nooit klein is gemaakt. Van de AI-pilots bij grote bedrijven levert 95 van de 100 niets op, en wie het door een gespecialiseerde bouwer laat doen slaagt twee keer zo vaak als wie het zelf probeert (MIT NANDA, The GenAI Divide, 2025).

Wij bakenen af tot één route en geven daar vooraf een prijs voor. Binnen twee weken draait er een werkende eerste versie op echte gegevens van jullie, in een omgeving waar niemand van schrikt als er iets misgaat. Geen presentatie en geen rapport.

Die eerste versie loopt eerst naast het bestaande proces. Jullie leggen ernaast wat de mensen die het nu doen eruit zouden hebben gehaald, en pas als dat hetzelfde antwoord is, gaat hij live. Daarna beslissen jullie welke route de volgende is. De tweede is meestal een stuk sneller, want de koppelingen liggen er dan al.

Twee weken is haalbaar door de afbakening, niet door harder te werken. Wat erin past is een route met een duidelijke trigger, een handvol stappen en een uitkomst die iemand kan nakijken.

De uitzondering hoort daarbij. Ziet het systeem iets dat niet past bij wat het verwacht, dan gaat de zaak met de reden erbij naar een mens. Dat is het ontwerp en geen gebrek: een systeem dat alles afhandelt, handelt ook de gevallen af die het niet begrijpt.

Verder blijven de eindcontrole en alles wat naar buiten gaat of geld verplaatst bij een mens liggen. En dan zijn er de stukken werk waarvan we in het gesprek samen vaststellen dat automatiseren er meer kost dan het oplevert. Dat zeggen we dan in dat gesprek, en niet bij de oplevering.