Je automatisering zal soms fout zitten. Ontwerp eerst het uitzonderingspad.

Een tijd geleden bekeek ik een automatisering voor factuurverwerking bij een bedrijf dat er op papier heel tevreden over was. Het model classificeerde 92 procent van de binnenkomende facturen correct. Dat cijfer stond in elke rapportage. Het klonk uitstekend.

Toen vroeg ik wat er met de overige 8 procent gebeurde. Het bleef even stil, en daarna zei iemand: “Die gaan naar de gedeelde mailbox.” Niemand in de ruimte kon me vertellen wie die mailbox nakeek, hoe vaak, of hoe lang een factuur daar bleef liggen. Het antwoord bleek ongeveer elf dagen te zijn, en twee mensen deden stilletjes werk over dat het systeem al half verwerkt had.

De automatisering was niet stuk. Het uitzonderingspad wel, want niemand had er een ontworpen.

In die 8 procent zit je businesscase

Dit is de rekensom die bijna niemand maakt voor een project wordt goedgekeurd.

Stel: je verwerkt 500 facturen per maand. Handmatig kost elke factuur 4 minuten, samen zo’n 33 uur per maand. De automatisering neemt 92 procent voor haar rekening, waardoor er 40 facturen bij een mens terechtkomen. Als die 40 elk ook 4 minuten kostten, bespaar je nog altijd ruim 30 uur. Prima project.

Maar uitzonderingen kosten nooit 4 minuten. Een uitzondering moet eerst opgemerkt worden, en dat kost op zich al tijd. Daarna moet iemand uitzoeken wat het systeem gedaan heeft, waarom het twijfelde, en wat het juiste antwoord is. In de praktijk zie ik dat de afhandeling van een uitzondering drie tot vier keer langer duurt dan de oorspronkelijke handmatige stap. Aan 15 minuten per stuk kosten die 40 facturen 10 uur per maand. Je besparing van 33 uur wordt er een van 23 uur, en dat is nog steeds goed.

Verander nu één cijfer. Zet de nauwkeurigheid op 85 procent in plaats van 92, wat volstrekt normaal is bij rommeliger documenttypes. Dan heb je 75 uitzonderingen van 15 minuten, bijna 19 uur. Tel daar de tijd bij die iemand kwijt is aan het bewaken van de wachtrij en het achternalopen van wat vastloopt, en je zit dicht bij break-even op een project waar je €18.000 voor betaald hebt.

Het slaagpercentage is het cijfer dat iedereen citeert. De kost per uitzondering is het cijfer dat bepaalt of het project zich terugverdient.

Twee soorten fout

Niet alle fouten zijn gelijk, en dat verschil weegt zwaarder dan het foutpercentage zelf.

De eerste soort is de zichtbare fout. Het systeem weet dat het twijfelt, stopt, en vraagt het na. Dat is de goede soort. Ze is vervelend en ze kost afhandeltijd, maar ze blijft beheersbaar en je ziet ze.

De tweede soort is de stille fout. Het systeem is zeker van zijn zaak en zit ernaast. Het boekt een factuur op de verkeerde kostenplaats, leest 1.450 als 1,45, koppelt een betaling aan de verkeerde klant. Er gaat geen signaal af. Er stopt niets. Het cijfer stroomt door in je rapportering en wordt drie maanden later ontdekt door je boekhouder, of nooit.

Een systeem met 5 procent zichtbare fouten is meestal veiliger dan een systeem met 1 procent stille. Vraag bij de beoordeling van een automatisering dus niet “hoe nauwkeurig is het”, maar “hoe gedraagt het zich als het fout zit”. Is het eerlijke antwoord “het geeft gewoon een antwoord”, dan koop je de tweede soort.

Vijf dingen die je beslist voor je bouwt

Dit zijn de vragen die ik intussen op tafel leg tijdens de ontwerpfase, voor er één regel code bestaat.

1. Welke nauwkeurigheid is goed genoeg voor dít proces?

Er is geen universele drempel. Voor het routeren van interne supporttickets is 85 procent prima, want een verkeerd gerouteerd ticket kost iemand dertig seconden doorsturen. Voor alles wat aan betalingen, klantcontracten of regelgeving raakt, is 85 procent onaanvaardbaar, tegen welke prijs dan ook. Leg het cijfer per proces vast, op papier, voor je begint.

2. Hoe zegt het systeem “ik weet het niet zeker”?

De meeste modellen kunnen naast hun antwoord een zekerheidsscore geven. Gebruik die. Zet een drempel waaronder het systeem niet beslist maar escaleert. Dat is precies wat stille fouten omzet in zichtbare, en het is meestal een kleine inspanning bij de bouw die zich vele keren terugbetaalt.

3. Wie is eigenaar van de uitzonderingswachtrij, met naam?

Geen afdeling. Geen gedeelde mailbox. Een persoon, met een aangewezen back-up voor verlofperiodes. Kan je die vraag tijdens het ontwerp niet beantwoorden, dan komen de uitzonderingen per ongeluk ergens terecht, en dat “ergens” is bijna altijd de meest consciëntieuze persoon in het team, die het stil opvangt tot ze vertrekt.

4. Hoe lang mag een uitzondering blijven liggen?

Geef de wachtrij een afspraak, ook al is ze informeel. Twee werkdagen bijvoorbeeld. Maak veroudering vervolgens zichtbaar, zodat een item dat over de limiet gaat opvalt bij iemand anders dan degene die het behandelt. Uitzonderingswachtrijen falen in stilte, en net daarom hebben ze een zichtbare klok nodig.

5. Hoe maken uitzonderingen het systeem beter?

Dit is de stap die de meeste bedrijven helemaal overslaan. Elke opgeloste uitzondering is een gelabeld voorbeeld van iets dat het systeem fout deed. Kijkt niemand die als groep na, bijvoorbeeld maandelijks, dan hou je hetzelfde foutpercentage voor altijd. Doet iemand dat wel, dan blijkt meestal dat de helft van de uitzonderingen uit twee of drie terugkerende oorzaken komt, en die zijn vaak op een dag op te lossen. Zo wordt een automatisering van 85 procent in het tweede kwartaal er een van 94 procent, zonder nieuw project.

Hoe dat er in de praktijk uitziet

Bij een klant werd de uitzonderingswachtrij elke vrijdagochtend twintig minuten doorgenomen. Binnen twee maanden bleek dat de meeste uitzonderingen kwamen van één leverancier die zijn factuurlayout had veranderd, en van documenten die in één bepaald kantoor scheef werden ingescand. Beide zijn opgelost zonder aan het model te raken. De wachtrij zakte van ongeveer 60 items per week naar minder dan 15.

Die twintig minuten waren meer waard dan eender welke modeltuning, en ze bestonden alleen omdat het uitzonderingspad vanaf dag één een eigenaar, een klok en een vast evaluatiemoment had.

De echte test van een automatisering

Een goed ontworpen uitzonderingspad is het verschil tussen een automatisering die je team vertrouwt en een die het stilletjes omzeilt. Dat tweede komt vaker voor dan leveranciers toegeven. Mensen houden de oude Excel naast het nieuwe systeem draaiende, omdat ze zich al eens gebrand hebben en niet kunnen zien wanneer het systeem fout zit. Dan betaal je voor allebei.

Zie je dus een voorstel dat negentig-en-zoveel procent nauwkeurigheid belooft, besteed dan het grootste deel van het gesprek aan de rest. Vraag wat ermee gebeurt, wie het ziet, hoe snel, en hoe het terugkoppelt. Heeft het voorstel daar geen antwoord op, dan is het niet af.

In kaart brengen waar automatisering zich echt terugverdient, uitzonderingsafhandeling inbegrepen, is een groot deel van wat de AI-waardescan doet. Wil je een eerlijk beeld voor je budget vastlegt, dan is de AI-waardescan een goed startpunt.