Orderverwerking automatiseren: drie routes

Een verkooporder in het pakket bestaat uit weinig. In de API van Exact Online zijn bij het aanmaken twee dingen verplicht: de klant die bestelt en minstens één orderregel, en per regel is het artikel het enige verplichte veld. Een klantnummer, een artikelnummer, een aantal. Alles wat de binnendienst doet tussen de mail die binnenkomt en de order die in het systeem staat, is die drie dingen achterhalen uit wat de klant heeft gestuurd.

Orderverwerking automatiseren is dus geen vraag over techniek maar over die vertaling: hoe komt wat de klant bedoelt in de vorm die het pakket eist? Daar zijn drie routes voor, en ze verschillen vooral in wie het vertaalwerk doet. Bij de eerste doet de klant het. Bij de tweede doet software het achteraf, op basis van wat de klant toch al stuurde. Bij de derde leest een taalmodel de order voor en keurt een mens hem goed.

De klant levert gestructureerd aan

De schoonste route is dat de order al gestructureerd binnenkomt: via een bestelportaal waarin de klant zelf artikelen kiest, of via EDI, waarbij het inkoopsysteem van de klant rechtstreeks een orderbericht naar uw systeem stuurt. Er is dan niets uit te lezen, want de klant heeft het artikelnummer en het aantal al in velden gezet.

Wat het vraagt, staat in het stappenplan van GS1 Nederland treffend als derde stap: stem af met je handelspartners en bepaal of zij dit ook willen en kunnen. Dat is de kern. EDI werkt als beide kanten investeren, en een groothandel met tweehonderd klanten heeft tweehonderd keer dat gesprek. De grote klanten doen het al, meestal omdat ze het u opleggen en niet andersom. De middelgrote klant met een eigen inkoopsysteem kan het, maar zet uw leverancierskoppeling niet bovenaan zijn lijst. De installateur die vanaf de bouwplaats mailt, doet het zelden.

Een portaal is de lichte variant: de klant hoeft geen software aan te passen, alleen zijn gewoonte. Dat lijkt weinig, maar die gewoonte is precies waarom de order nu per mail komt. Wie zijn bestelling al jaren in een Excel bijhoudt, ervaart een portaal als werk dat hij voor u doet. Sommigen doen dat, de meesten alleen als het niet anders kan.

Waar deze route ophoudt: bij de klanten die niet meedoen. Kijk daarvoor naar uw eigen orderlijst, niet naar de omzetlijst. De kans is groot dat een handvol grote klanten het grootste deel van de omzet stuurt, en de lange staart van kleine klanten het grootste deel van het aantal orders. De binnendienst is druk met het aantal, niet met de omzet. Wie alleen EDI regelt, heeft dan de omzet geautomatiseerd en het werk niet.

Orders uit mail en PDF uitlezen

De tweede route laat de klant met rust en doet het vertaalwerk aan uw kant. De mail komt binnen, de bijlage wordt gelezen, de regels worden herkend, het artikelnummer van de klant wordt opgezocht in een vertaaltabel, en de order gaat via de API het pakket in. Bij Exact Online is dat de resource uit de eerste alinea; bij AFAS Profit loopt het via een UpdateConnector, waarmee een externe applicatie records kan toevoegen, wijzigen of verwijderen. AFAS zegt er zelf bij dat die connector bedoeld is voor terugkerende uitwisseling, en de importfunctie voor de bulk bij een implementatie. Hoe die koppelingen er in de praktijk uitzien staat op de pagina's over Exact Online en AFAS.

Wat deze route van het pakket vraagt, is niet alleen een API. Het vraagt een vertaaltabel: klant X noemt uw artikel 40012 "beugel 60 verzinkt" of gebruikt zijn eigen inkoopcode, en die koppeling moet ergens staan. Bij veel bedrijven staat hij in het hoofd van de binnendienst. De eerste weken van zo'n koppeling bestaan dan ook uit het opbouwen van die tabel, order voor order. Dat is hetzelfde werk dat nu bij elke order opnieuw wordt gedaan, één keer vastgelegd.

De tweede eis is dat de order een vaste opmaak heeft. Vaste regels lezen een inkooporder uit het systeem van dezelfde klant betrouwbaar uit, zolang de kolommen op dezelfde plek staan. Verandert de klant zijn sjabloon, dan geeft de regel niets terug, en dat hoort ook zo: een lege regel gaat naar een mens, een verkeerd gelezen aantal gaat naar het magazijn. Dat niet alles een taalmodel hoeft, staat ook zo op de pagina over de techniek.

Waar deze route ophoudt: bij de order zonder opmaak. "Doe mij er nog twaalf van die van vorige week" heeft geen kolom, geen artikelnummer en geen leverdatum die ergens achter een label staat. Een regel kan dat niet lezen. Voor een groothandel waar een derde van de orders zo binnenkomt, is dat een derde die blijft liggen.

Een taalmodel leest voor, een mens keurt goed

De derde route neemt die restgroep. Een taalmodel leest de mail in lopende tekst en maakt er een voorstel van: klant, regels, aantallen, gewenste leverdatum, met per veld of het letterlijk in de mail stond of is afgeleid. "Twaalf" staat er. "Die van vorige week" is een afleiding uit de vorige order van deze klant, en dat moet het voorstel ook zeggen. Daarna kijkt iemand van de binnendienst ernaar en keurt goed of past aan. Pas dan gaat de order het pakket in.

Dat lijkt op wat Exact zelf al doet: een nieuwe verkooporder krijgt daar een goedkeuringsstatus en wordt pas verwerkt als iemand met het juiste recht hem goedkeurt, tenzij de instellingen dat automatisch doen. Het verschil is waar de controle zit. Bij een order die met vaste regels is uitgelezen, kan de controle achteraf en steekproefsgewijs zodra de regel zich bij die klant heeft bewezen, omdat hij morgen hetzelfde doet als vandaag. Bij een taalmodel hoort de controle vooraf, per order, omdat het model bij dezelfde mail morgen een ander antwoord kan geven en dat veel lastiger te testen is.

Wat het van het pakket vraagt, is hetzelfde als de tweede route, plus een plek waar die goedkeuring gebeurt: een scherm, een mail met een knop, een rij in een sheet. Van de klant vraagt het niets, en het richt zich op de orders die per stuk de meeste tijd kosten: die zonder opmaak.

Waar deze route ophoudt: bij orders die niemand nakijkt. Zodra de goedkeuring een gewoonte wordt van "altijd ja", is de controle weg en is het model de binnendienst geworden. Dat merkt u niet op de dag dat het misgaat, maar aan de creditnota's daarna. De grens van deze route is geen technische; het is de discipline om een voorstel als een voorstel te blijven lezen.

Wat de drie gemeen hebben

Geen van de drie komt om de vertaaltabel heen. Bij EDI staat hij bij de klant, bij uitlezen in uw koppeling, bij het taalmodel in het voorstel dat de mens nakijkt. En geen van de drie komt om het pakket heen: de order moet aan het eind een klant en een artikel hebben die het pakket kent. Een artikelnummer dat niet bestaat, wordt door geen enkele route een order; de goede koppeling meldt dat, de slechte kiest het dichtstbijzijnde artikel.

Daarom is de eerste stap bij elk van de drie dezelfde, en die kunt u deze week zelf doen: tel een week lang de orders per kanaal. EDI, portaal, PDF met vaste opmaak, Excel, lopende tekst in een mail, telefoon. De binnendienst weet het antwoord meestal ongeveer, en de telling wijkt er meestal toch van af. Die verdeling bepaalt welke route het werk werkelijk weghaalt. Hoe de tweede en derde route er samen uitzien, met de controles tussen mailbox en pakket, staat bij orderverwerking die zichzelf invoert.