Procesautomatisering wordt begroot op het verkeerde document. Iemand tekent het proces, iedereen aan tafel vindt dat de tekening klopt, en daar wordt het project op geprijsd. Die tekening beschrijft hoe het werk hoort te gaan. De kosten, het risico en het grootste deel van de echte waarde zitten in de gevallen die erbuiten vallen. Daarom vraag ik nu niet meer om het proces. Ik vraag om de laatste twintig gevallen die misgingen.
Waarom is het processchema het verkeerde document?
Een vastgelegd proces is een consensusdocument. Het bestaat omdat een aantal mensen het over één beschrijving eens moest worden, en een beschrijving waar meerdere mensen het over eens zijn is bijna per definitie de versie waar de rommel uit is. De operationeel manager herkent haar deel. De financieel verantwoordelijke herkent het zijne. Niemand meldt spontaan het geval dat alleen goed gaat omdat één collega op de tweede verdieping het elke donderdagmiddag nakijkt, deels omdat het niet als onderdeel van het proces aanvoelt, en deels omdat niemand er ooit naar heeft gevraagd.
Dat is geen oneerlijkheid. Het is simpelweg wat er gebeurt als u een bedrijf vraagt zichzelf te beschrijven. In enkele honderden eerste gesprekken met Nederlandse en Vlaamse ondernemers heb ik nog nooit een procesbeschrijving gekregen waarin de uitzonderingen stonden. Niet één keer. Ze worden niet verzwegen. Ze zijn alleen niet waar zo'n document voor geschreven is.
Dat zou een onschuldige constatering zijn als het document niet dragend was. Een offerte is een voorspelling, en in de meeste automatiseringsprojecten is dit schema het enige bewijs waar die voorspelling op rust. U begroot dus de versie van het werk die geldt wanneer er niets bijzonders gebeurt, en de rest ontdekt u later, op kosten van iemand.
Wat weet het Nederlandse bouwrecht hier al over?
Er is een vak dat deze discussie lang voor de software beslecht heeft, en dat is het onze niet. In de bouw beschrijft het bestek het werk zoals het is afgesproken. Iedereen in de bouw weet ook dat de marge, en het meeste geruzie, in het meerwerk zit: het werk dat opduikt zodra de wanden open zijn en iemand ziet wat er werkelijk achter zat.
Het Nederlandse recht laat dat niet aan goede bedoelingen over. Op grond van artikel 7:755 van het Burgerlijk Wetboek kan een aannemer alleen een prijsverhoging vorderen voor toevoegingen of veranderingen die de opdrachtgever wenst, als hij de opdrachtgever tijdig heeft gewezen op de noodzaak van die prijsverhoging, tenzij de opdrachtgever die noodzaak zelf had moeten begrijpen. Van die bepaling kan in de praktijk niet ten nadele van de opdrachtgever worden afgeweken. De Hoge Raad verduidelijkte in juli 2022 dat de waarschuwing niet hoeft te vermelden hoe groot de verhoging wordt. Is er gewaarschuwd, dan is het aan de opdrachtgever om ernaar te vragen.
Lees dat als beroepsnorm in plaats van als wetsartikel en het zegt iets nuttigs over ons vak. De last om het voorzienbare extra werk te benoemen ligt bij de professional, vóór het werk begint, en niet bij de opdrachtgever achteraf. Een leverancier die een processchema beprijst en de uitzonderingen in maand drie ontdekt, doet precies datgene wat dat artikel moet voorkomen.
Over de grenzen van die vergelijking wil ik eerlijk zijn. Niemand gaat een AI-leverancier aanspreken op 7:755. Het is Nederlands aannemingsrecht, geschreven voor bouwwerk, en België kent zijn eigen regeling voor hetzelfde probleem. Het is een norm die ik mijzelf opleg, geen norm die mij wordt opgelegd. Toch heb ik geen betere beschrijving gevonden van waar een eerste gesprek voor dient.
Waar lopen automatiseringsprojecten werkelijk vast?
Niet op het model, in mijn ervaring. Op de gevallen die de demo nooit gezien heeft.
Er is één onderzoek dat het waard is om te kennen, vooral vanwege de herkomst van het idee. In juni 2024 publiceerde een team bij Sierra een benchmark genaamd tau-bench, voor agents die een gesprek met een gebruiker voeren en daarbij tools aanroepen onder een vastgelegd beleid. De blijvende bijdrage was niet zozeer de benchmark als wel een maatstaf: pass^k, de kans dat een agent alle k pogingen op dezelfde taak goed doet in plaats van één ervan. Het artikel meldde dat de sterke function-callingmodellen van dat moment minder dan 50 procent van de taken afrondden, en dat de consistentie nog slechter was, met pass^8 onder 25 procent in het retaildomein.
Modellen van vandaag scoren daar ruim boven, en wie die cijfers uit 2024 als actueel aanhaalt, gaat er slordig mee om. Wat goed heeft standgehouden, is de maatstaf. Een demo is pass^1 op een geval dat iemand heeft uitgekozen. Wat een bedrijf nodig heeft is dezelfde taak, acht keer, op gevallen die niemand heeft uitgekozen. Het verschil tussen die twee is de uitzonderingenlijst, en die staat nooit op een slide.
Daarom is het gat tussen demo en productie ook geen technische verrassing, maar een scopekwestie. Ik schreef eerder over wat er verandert tussen een demo en een productiesysteem; bijna alles op dat lijstje is een geval dat de demo nooit hoefde te behandelen.
De drie soorten uitzondering, en wat elk ervan kost
Zodra u een lijst heeft, is de nuttigste stap om het niet als één lijst te behandelen. Uitzonderingen zijn niet één categorie. De drie die tellen gedragen zich volstrekt verschillend, en de duurste fout is om ze alle drie hetzelfde te behandelen.
Zeldzaam en goedkoop in gevolgen
Iets gebeurt twee keer per jaar en kost dan een uur van iemands tijd. Bouw er niets voor. Laat het niet in de scope komen. Laat het misgaan op een plek waar een mens het ziet, en leg vast dat dit het bedoelde gedrag is. Het werk zit hier in het benoemen, niet in het oplossen. Een benoemde uitzondering met een afgesproken eigenaar is afgehandeld. Een onbenoemde komt in maand vier terug als bugmelding, en dan is het een discussie over de scope geworden.
Zeldzaam en duur
Iets gebeurt twee keer per jaar en gaat dan de deur uit naar een klant, een belastingaangifte in, of een patiëntdossier op. Frequentie is hier de verkeerde as, omdat de kosten niet meebewegen met hoe vaak het geval zich voordoet. Hier moet tijdens de bouw voor worden ontworpen: een regel die het geval herkent, een route naar een mens, en iemand voor wie het daadwerkelijk werk is om aan de andere kant van die route te zitten. Dit is ook de categorie die opdrachtgevers het liefst uitstellen, juist omdat het zeldzaam is. Uitstellen is precies hoe een goed gebouwd systeem uiteindelijk één zeer dure middag oplevert.
Frequent en onzichtbaar
En dan de categorie die meestal het echte project is. Iets gebeurt bijna elke week, en niemand noemt het een uitzondering, omdat iemand het altijd gewoon heeft opgelost. De leverancier die twee documenten stuurt voor één levering. De klant wiens referentienummer nooit klopt. De order die altijd telefonisch binnenkomt. Het veld dat technisch optioneel is en elke keer met de hand wordt gevuld. Deze gevallen zijn onzichtbaar juist omdat ze vaak genoeg voorkomen om in iemands routine te zijn opgenomen, en zij bepalen of de automatisering überhaupt iets waard is.
Als er een lijst komt, is het vooral die derde categorie waar ik op jaag. Het is de enige waarin de uitzondering helemaal geen randgeval is. Het is het proces, in een andere jas. Het factuurwerk dat we beschreven in factuurverwerking automatiseren met AI is het helderste voorbeeld dat ik ken: de businesscase daar is niet het model, maar het aantal facturen dat niet binnenkomt zoals het schema beweert.
Hoe bepaalt u de scope van een AI-project met de uitzonderingenlijst?
Dit is iets concreets dat u deze week kunt doen, zonder leverancier aan tafel. Het kost een ochtend en het is het minst kostbare onderdeel van het hele project.
- Vraag om de laatste twintig gevallen die misgingen, of die iemand met de hand heeft moeten aanraken. Geen lijst met soorten uitzonderingen. De werkelijke gevallen, met datum, van de mensen die ze hebben opgelost.
- Reken uit welk deel van de laatste honderd die twintig zijn. Kan niemand dat zeggen, dan is dat geen vertraging in het project. Dat is de eerste bevinding, en die is meer waard dan het processchema.
- Sorteer elk geval in zeldzaam en goedkoop in gevolgen, zeldzaam en duur, of frequent en onzichtbaar. Het meningsverschil over waar een geval thuishoort is het productiefste half uur dat u eraan besteedt.
- Schrijf per categorie één zin over wat het systeem doet: het handelt het af, het weigert het, of het routeert het naar een met naam genoemde persoon. Weigeren is een functie, geen gat in de bouw.
- Beprijs de routering, niet alleen de goede gang van zaken. De route naar een mens is een echt onderdeel van de bouw. Er hoort een scherm bij, een wachtrij, een melding en een verwachte reactietijd, en niets daarvan is gratis.
Komt die lijst er helemaal niet, dan is dat ook een antwoord. Het proces is niet klaar om geautomatiseerd te worden, en de offerte dus ook niet. Dat vaststellen kost een ochtend. Het in maand drie vaststellen kost een project, en meestal ook een samenwerking. Het verlegt het gesprek bovendien vaak naar welk proces u als eerste automatiseert, en dat is een betere vraag dan waarmee de meeste bedrijven binnenkomen.
Welk percentage van de gevallen moet het systeem aankunnen?
Tachtig procent is het getal waar bijna iedereen naar grijpt, en het is comfortabel omdat het zich tot niets verplicht. Het zegt precies niets over de andere twintig.
De betere vraag is wat het systeem doet wanneer het het niet weet. Een systeem dat zeventig procent van de gevallen afhandelt en de rest betrouwbaar weigert, is meer waard dan een systeem dat tweeënnegentig procent haalt en bij de rest gokt. De fouten van het eerste komen in een wachtrij terecht waar een naam aan hangt. Die van het tweede komen weken later in een klantmail, zonder dat iemand kan zeggen hoeveel andere gevallen dezelfde weg zijn gegaan. Weigeren is herstelbaar. Een onopgemerkt fout antwoord is de dure variant, en dat blijft het nog lang nadat het project is afgesloten.
Het percentage is dus het verkeerde getal om over te onderhandelen. Onderhandel in plaats daarvan over de weigerregel: waardoor geeft het systeem een geval terug, en aan wie. Hoeveel foutmarge een proces überhaupt kan dragen is een aparte vraag, die ik uitwerkte in hoe fout AI-automatisering mag zijn. Die twee antwoorden moeten met elkaar kloppen, en in de meeste offertes staat geen van beide op papier.
Waar ik dit zelf fout heb gedaan
Ik schrijf deze paragraaf liever niet, wat meestal het teken is dat hij in het stuk hoort.
Wij hebben op het processchema begroot. Meer dan eens. Het heeft altijd dezelfde vorm. Een systeem werkt goed in week één, en in week zes komt er een langzaam straaltje berichten dat begint met "kun je hier even naar kijken". Dat straaltje is de uitzonderingenlijst die te laat arriveert, geval voor geval. Op dat moment draait iemand op voor de kosten: wij, op eigen rekening, wat te overleven is en waar een vaste prijs voor bedoeld is, of de opdrachtgever, wat erger is, want die denkt nu dat het systeem onbetrouwbaar is terwijl de scope dat was.
De uitzonderingenlijst is daarom verhuisd. Het is niet langer iets dat we tijdens het project vinden. Het is iets waar we om vragen voordat er een prijs is, en een voorstel dat niet kan zeggen wat er met de rare gevallen gebeurt, is geen afgerond voorstel, wat er verder ook in staat.
Wat er nu in het voorstel staat
Drie dingen, op papier, voordat er een getal is:
- De uitzonderingscategorieën, met naam. Niet "randgevallen worden afgehandeld", wat niets betekent en niet afdwingbaar is. De werkelijke gevallen, gesorteerd in de drie categorieën.
- Wat het systeem met elk ervan doet: afhandelen, weigeren of routeren.
- Wie aan de andere kant van die routering zit, met rol, en hoe snel die persoon geacht wordt naar de wachtrij te kijken.
Dit maakt voorstellen langer en eerste gesprekken langzamer. Het heeft ons zeker werk gekost bij bedrijven die diezelfde week een getal wilden. Die ruil zou ik opnieuw maken, want het alternatief is een vaste prijs zetten op een beschrijving van het werk die is geschreven om instemming te krijgen en niet om waar te zijn. Wat een AI-project kost en hoe wij een implementatie aanpakken volgen hier allebei uit. De uitzonderingenlijst is wat die twee eerlijk maakt.
Staat u dus op het punt automatisering te kopen, stuur de leverancier dan niet uw procesbeschrijving. Stuur de twintig gevallen die misgingen, en kijk wat hij ermee doet. Wie om méér ervan vraagt, is degene met wie het gesprek de moeite waard is.
