Hoe 190.000 minuten besparen?

In deze rubriek nemen we één project onder de loep. Deze keer: een Belgische logistiek dienstverlener tussen de havens van Rotterdam en Antwerpen, die zijn klanten een verwerkingstermijn van twee uur belooft en die belofte niet meer kon waarmaken.

Aan dit project werkten de AI-engineers Pieter de Lange, Philip Gast, Mart Kempenaar, Noah van Potten en Hamza Lamrabet.

Laten we bij het begin beginnen. Wat was het probleem?

Pieter: Deze klant zit in opslag, overslag en transport van kunststofgranulaat. Kleine plastic korrels die later ergens tot product worden gesmolten. Ze zijn geen vervoerder zelf, ze zitten ertussen. Dagelijks kwamen er vijftig tot zeventig orders binnen, als PDF in de mail. Twee mensen op de orderadministratie typten die met de hand over in het ERP-systeem. Minimaal een kwartier per order, en de informatie zat verspreid over meerdere pagina's in vaak omvangrijke documenten.

Philip: Er zat bovendien een harde afspraak onder. Ze garanderen hun klanten dat een order binnen twee uur verwerkt is. Dat haalden ze een paar keer per week niet. Geen boete, wel gezichtsverlies. En het volume liep op.

Pieter: Wat het extra interessant maakte: ze hadden dit al eens geprobeerd. Met een andere partij, die er niet uit kwam. Toen wij binnenkwamen was er dus scepsis, en terecht.

Hoe merkten jullie dat?

Pieter: Niet doordat ze het hardop zeiden. Het zat in de omgang. Ze gaven ons een kleine testset in plaats van alles, de vragen waren scherper dan gebruikelijk, en elke planning die wij noemden kreeg een wedervraag. Dat is geen onwil, dat is iemand die één keer zijn vingers heeft gebrand en niet nog een keer intern wil uitleggen waarom het weer niets werd.

Philip: We hebben niet geprobeerd dat weg te praten. Tegen iemand die net is teleurgesteld begin je niet over wat er allemaal mogelijk is. Dat hadden ze al gehoord. Wij stelden voor om klein te beginnen: een betaald vooronderzoek van vier weken met een harde uitkomst. Haalbaar of niet haalbaar, per veld onderbouwd, op hun eigen documenten.

Pieter: Het punt daarvan is dat "het kan niet" een geldige uitkomst was. Dan hadden ze dat geweten voor een fractie van het bedrag, en hadden ze het dossier kunnen sluiten. Dat is wat de scepsis heeft weggenomen. Geen belofte, maar een afspraak waarin ook een negatieve uitslag iets opleverde.

Waar zijn jullie begonnen?

Pieter: Met meten, niet met bouwen. De vraag was simpel: kunnen we de velden die het ERP nodig heeft betrouwbaar uit deze documenten halen? Mart heeft de testset veld voor veld doorgemeten. Geen steekproef, maar de volledige set.

Philip: Dat meten is het belangrijkste deel van het hele project geweest. Je wilt weten of het kán voordat je er maanden in stopt. En je wilt weten wáár het misgaat, want dat bepaalt je architectuur. Als één specifiek veld structureel onzeker is, ontwerp je het systeem daaromheen.

Pieter: Het onderzoek liep iets uit. Dat melden we maar eerlijk. Maar de conclusie was helder: dit is te bouwen.

"De vraag die een organisatie stelt, is zelden de vraag die je moet oplossen. Hier was de vraag: automatiseer onze orderinvoer. De echte vraag was welke gegevens er per order nodig zijn, waar die vandaan komen, en hoe zeker je van elk afzonderlijk veld kunt zijn. Pas als dat scherp is, kun je een architectuur ontwerpen die standhoudt. Die vertaalslag is inhoudelijk werk, geen intake."

— Roel Rotteveel, COO AdamI

Hoe ziet de oplossing er in de praktijk uit?

Noah: Bewust saai. Je sleept de ordermail vanuit Outlook de applicatie in, je geeft aan of het inslag of uitslag betreft, en het systeem leest de mail én de bijlagen uit en zet alles klaar in de velden die het ERP verwacht. Geen nieuw systeem om te leren, geen extra stap in hun dag. De applicatie draait op hun eigen Azure-omgeving en mensen loggen in met hun eigen bedrijfsaccount. Dat klinkt als een detail, maar het is precies waarom het ding daadwerkelijk gebruikt wordt.

Pieter: En dan komt het stuk waar we het langst over hebben nagedacht. Het systeem verstuurt niet zelf. De medewerker ziet wat eruit komt, corrigeert waar nodig, en drukt pas dan op verzenden.

Philip: Dat is geen technische beperking, dat is een ontwerpkeuze. Bij dit type document haal je geen honderd procent. Dus bouw je het zo dat de mens de laatste stap zet, op een scherm waar in één oogopslag te zien is wat er is ingevuld. Elke correctie die iemand maakt is bovendien signaal. Mart werkt nu aan de laag die daarop leert.

"Er zit een groot verschil tussen een model dat het in een notebook doet en een applicatie die elke ochtend om acht uur draait op de infrastructuur van de klant. Die laatste stap is geen detail, het is het grootste deel van het werk. Zolang je die stap niet zet, blijft AI een presentatie."

— Niels van der Wal, CEO AdamI

Hoe verliep de invoering?

Hamza: Met kinderziektes, zoals altijd. Er zaten stukjes informatie in bepaalde ordertypes die de applicatie in de eerste versie nog niet meepakte. Dat merk je niet in een testset, dat merk je pas als er echt werk doorheen gaat. De mensen op de administratie gaven het direct aan en wij konden het binnen dagen oplossen. Die korte lijn heeft meer opgeleverd dan welke extra testronde vooraf ook.

Pieter: Die correcties waren de eerste versie van de leercurve, aan beide kanten.

"Een organisatie wordt niet AI-ready van een tool. Dat gebeurt op het moment dat de mensen die het werk doen zélf gaan zien waar het beter kan, en dat ook durven zeggen. Hier corrigeerden medewerkers vanaf dag één wat het systeem eruit gooide. Dat is geen implementatiehobbel, dat is het begin van de verandering."

— Niels van der Wal, CEO AdamI

Wat heeft het opgeleverd?

Philip: Eerst het getal dat er voor hen het meest toe doet: die tweeurentermijn wordt nu structureel gehaald. Dat was de reden dat dit project er kwam, en dat is wat ze hun klanten beloven.

Pieter: En daaronder zit de tijd. De gemiddelde verwerkingstijd per order is gegaan van een kwartier naar ongeveer vijf minuten. Bij eenvoudige orders winnen ze acht tot tien minuten, bij complexe loopt het op tot een half uur. Gemiddeld houden ze zo'n twaalf minuten per order over. Zestig orders per dag, een normaal werkjaar, en je komt uit op ongeveer 190.000 minuten. Ruim drieduizend uur.

En de twee mensen die dit werk deden?

Pieter: Die zitten er allebei nog. Dat was vanaf de eerste week de afspraak, en het was ook de eerste vraag die op de werkvloer werd gesteld. Ze doen nu het werk waar ze structureel niet aan toekwamen: klanten bellen als een order ergens vastloopt, afstemmen met vervoerders, uitzoeken waarom bepaalde zendingen telkens misgaan.

Philip: En daar zit in deze arbeidsmarkt het echte argument. Ze waren al een tijd op zoek naar iemand erbij, zonder resultaat. Die vacature is van tafel. Niet omdat er iemand weg is, maar omdat er capaciteit vrijkwam bij mensen die het bedrijf al kennen. Dat is sneller en goedkoper dan werven, en het risico is nul.

Pieter: Ze denken inmiddels na over dezelfde oplossing bij hun partners in de keten. Dat is voor mij het echte signaal. Niet dat het werkt, maar dat het een vervolgvraag oproept.

Wat is jullie belangrijkste les uit dit project?

Philip: Dat de winst niet in het model zit. De extractie is goed, maar niet magisch. De winst zit in de vraag: welke stappen in dit proces bestaan er eigenlijk alleen omdat het vroeger niet anders kon?

Pieter: Ze typten informatie over van het ene systeem naar het andere. Dat is geen werk, dat is verplaatsing. Het interessantste moment in zo'n traject is niet de oplevering, het is het moment waarop iemand zegt: waarom doen we deze stap eigenlijk? Veel processen hebben hun huidige vorm omdat de techniek twintig jaar geleden niet meer toeliet. Die aanname opnieuw toetsen, dat is wat AI vooral oplevert. Wat je daarna bouwt is bijna een afgeleide.