B2B / distributie
Een terugkerend contractproces met meerdere merken, contractvormen en talen werd omgezet in een interne tool. Niet door het bestaande document te digitaliseren, maar door eerst regels, uitzonderingen, nummering en historische data expliciet te maken — en daarna vooral te testen wat nooit fout mocht gaan.
De situatie
Het proces werkte. Overeenkomsten werden opgesteld vanuit bestaande templates, gegevens werden ingevuld, de juiste versie werd gekozen en documenten kregen hun plaats in het archief. Dat werkte omdat degene die het proces uitvoerde ook wist hoe het in elkaar zat. Alleen stond niet elke regel ergens beschreven.
Er waren meerdere merken, verschillende soorten overeenkomsten en meerdere talen. Volgnummers moesten correct aansluiten op de bestaande historiek, sommige combinaties waren expliciet niet toegestaan, en bestaande gegevens en reeds uitgegeven nummers mochten niet in gevaar komen. Zolang alles handmatig gebeurt, vangt ervaring die complexiteit op. Bij automatisering verdwijnt die veiligheidsmarge.
Het zakelijke vraagstuk
De eerste vraag lijkt eenvoudig: kunnen we uit een aantal inputs automatisch het juiste contract maken? Technisch is dat niet het moeilijkste. De moeilijkere vragen kwamen ervoor: welke gegevens bepalen welk document gebruikt wordt, welke velden zijn verplicht, welke combinaties moeten worden tegengehouden, hoe behandel je meerdere personen binnen één overeenkomst, en hoe voorkom je dat twee acties hetzelfde contractnummer krijgen?
Een fout in een social post herstel je. Een tool die contractnummers dubbel uitgeeft of bestaande registraties beschadigt, creëert een ander soort probleem. Daarom woog betrouwbaarheid vanaf het begin zwaarder dan extra functionaliteit.
De gemaakte keuzes
Het bestaande gedrag werd niet meteen vervangen. Eerst werd vastgelegd wat er vandaag correct gebeurde en welk gedrag absoluut behouden moest blijven. De bestaande gegevens bleven het uitgangspunt — niet iets dat tijdens de ontwikkeling opnieuw werd opgebouwd omdat dat makkelijker was.
Bedrijfsregels moesten vastliggen. Contracttype, merk, taal, nummering en toegestane combinaties mochten niet afhangen van een model dat "waarschijnlijk" de juiste interpretatie maakte. AI hielp bij analyse, ontwikkeling en review; de regels zelf bleven expliciet en controleerbaar.
Daaruit volgde een eenvoudige ontwerpregel: wat niet toegestaan is, wordt geblokkeerd vóór er een document bestaat — niet achteraf gemeld. En voor de nummering gold één harde eis: twee acties, ook gelijktijdig, mogen nooit hetzelfde contractnummer opleveren.
Mijn rol
Mijn rol begon niet bij code. Eerst werd de bestaande werking ontleed: documenttypes, keuzes, uitzonderingen, historische nummering en de manier waarop gegevens werden bijgehouden. Dat leverde een expliciete beschrijving van het proces op — de regels waaraan de tool zich hoe dan ook moest houden.
Daarna werd de tool iteratief gebouwd en getest. AI werd daarbij in verschillende rollen ingezet: code produceren, aannames in vraag stellen, uitzonderingen opsporen en de werking door een tweede model laten nakijken. Belangrijk gedrag werd niet alleen visueel gecontroleerd: er kwamen geautomatiseerde tests voor regels die niet mochten verschuiven wanneer er later iets aan de tool veranderde. Die testset werd gaandeweg meer dan een controle achteraf. Ze werd de beschrijving van het gedrag dat we wilden behouden.
De uitvoering
De eerste werkende versie draaide lokaal: een eenvoudige interface, de bestaande gegevens en documentgeneratie. De gebruiker kiest wat nodig is; de tool controleert de invoer, past de regels toe, maakt het document en registreert wat er gebeurd is.
Daarna kwamen de situaties die in een demo makkelijk vergeten worden: meerdere personen in één verwerking, bestaande nummerreeksen, documentconversie, een fout in een programma waarvan de tool afhankelijk was. Telkens was de vraag niet alleen of we het weer werkend kregen, maar ook of dezelfde fout later ongemerkt kon terugkomen. Correcties werden daarom waar mogelijk gevolgd door tests en een aparte review van het betrokken gedrag.
Toen een online versie op tafel kwam, werden de lokale technische keuzes niet blind gekopieerd. Opslag, toegang, bestanden en documentconversie werden voor de webomgeving opnieuw ontworpen, omdat wat lokaal goed werkt niet automatisch een goede serveroplossing is. De regel bleef dezelfde: eerst het gedrag vastleggen, daarna pas het platform veranderen.
Bewust niet gedaan
Geen chatbot gebouwd rond een proces dat vooral vaste regels nodig had. Geen AI laten beslissen welke contractregels “waarschijnlijk” van toepassing waren. Geen bestaande data opnieuw opgebouwd of nummering gereset omdat dat de ontwikkeling makkelijker maakte. Geen correctie als geslaagd beschouwd alleen omdat het document één keer opnieuw gegenereerd kon worden. Geen online versie ontworpen door de lokale keuzes gewoon over te nemen. En geen automatisering toegevoegd alleen omdat ze technisch mogelijk was.
De tool moest tijd besparen. Maar niet door de controle op het proces in te leveren.