Waarom inkoopplanning automatiseren in de groothandel zo vaak vastloopt
De logica van geautomatiseerde inkoopplanning is simpel: neem de verwachte vraag, trek de huidige voorraad eraf, houd rekening met de doorlooptijd van de leverancier, en bestel op het juiste moment de juiste hoeveelheid. Elke planningssoftware belooft dit. Het probleem is niet de logica zelf, maar de gegevens die erin gaan. In een typische groothandel met een paar duizend actieve artikelen zijn die gegevens zelden op orde. Leveranciersdata staat in verschillende formaten, minimale bestelhoeveelheden zijn verouderd of ontbreken, en doorlooptijden per SKU zijn nooit systematisch bijgehouden. Je kunt het beste algoritme inrichten, maar als de invoer niet klopt, krijg je bestelsuggesties die de planner direct terzijde legt. Na een paar weken vertrouwt niemand de output meer en draait de planning weer op buikgevoel.
Leermoment 1: ongestructureerde leveranciersdata saboteert elke bestelsuggestie
Groothandels werken doorgaans met tientallen leveranciers, elk met hun eigen prijslijsten, artikelcodes en bevestigingsformaten. Die data komt binnen als PDF, Excel, e-mail of via een portaal, en wordt handmatig of half-automatisch in het ERP gezet. Het gevolg: hetzelfde artikel staat onder drie verschillende leverancierscodes, de laatste inkoopprijs is zes maanden oud, en de bevestigde levertijd wijkt af van wat in het systeem staat. Zodra je een automatisch bestelvoorstel wil genereren op basis van die data, geeft het systeem conflicterende of onbetrouwbare adviezen. De oplossing begint niet bij de planningsmodule maar bij het structureren van de leveranciersinformatie: één actieve leverancierscode per artikel, een vastgelegd proces voor prijsupdate en een gevalideerd veld voor doorlooptijd. Pas als die basis er is, heeft een algoritme iets om mee te werken. Dottle, onze document-AI, kan helpen om inkomende leveranciersbevestigingen en prijslijsten gestructureerd uit te lezen en direct in het juiste veld te zetten, zodat de stamdata actueel blijft zonder handmatig overtypen.
Leermoment 2: inconsistente minimale bestelhoeveelheden maken het bestelplan onbruikbaar
Minimale bestelhoeveelheden, ook wel MOQ's, zijn in veel groothandels per artikel anders en wisselen per leverancier, per seizoen of na een contractwijziging. In de praktijk staat in het systeem vaak de historische waarde van jaren geleden, of een ronde schatting die nooit is gevalideerd. Een planningsmodule die een bestelvoorstel genereert van 47 stuks, terwijl de leverancier minimaal 100 levert per doos, produceert een voorstel dat de inkoper direct corrigeert. Dat klinkt klein, maar als dit voor een significant deel van het assortiment geldt, verliest de planner het vertrouwen in het systeem als geheel. Wat werkt: een eenmalige opschoonslag waarbij je voor elke actieve leveranciersrelatie de geldende MOQ, de verpakkingseenheid en de eventuele staffelkorting vastlegt in een gestructureerd formaat. Vervolgens koppel je dat veld hard aan de bestelsuggestie, zodat de output altijd een geldig veelvoud oplevert. Dat is geen algorithm-werk, dat is stamdata-beheer.
Leermoment 3: doorlooptijden per SKU ontbreken, en een gemiddelde werkt niet
Het derde breukpunt is het ontbreken van betrouwbare doorlooptijden op artikelniveau. Veel groothandels werken met een algemene doorlooptijd per leverancier, bijvoorbeeld tien werkdagen. Maar in werkelijkheid varieert de doorlooptijd per artikel, per seizoen en soms per order. Een artikel dat uit een Europees magazijn komt, heeft een andere doorlooptijd dan een artikel dat uit Azië verscheept wordt. Als je met een generieke waarde rekent, bestel je sommige artikelen structureel te laat en andere te vroeg. Het bestelmoment klopt dan nooit precies. De oplossing is niet een nog geavanceerder prognosemodel, maar het bijhouden van de werkelijke doorlooptijd per ontvangst. Elke keer dat een levering binnenkomt, registreer je de datum van bestelling en de datum van ontvangst. Na een aantal maanden heb je per SKU een historisch gemiddelde dat betrouwbaar genoeg is om het systeem op te laten sturen. Dat vereist een klein veld in je ontvangstscan en een beetje discipline, geen extra software.
Wat betekent dit voor het automatiseren van je inkoopplanning?
De rode draad in deze drie leermomenten is dezelfde: automatisering van inkoopplanning begint bij de kwaliteit van je artikelstamdata, niet bij de keuze van een planningsalgoritme of een nieuw systeem. Een AI Workers-laag of een nieuw planningsmodel bovenop slechte stamdata geeft slechte bestelsuggesties. Andersom: met opgeschoonde leveranciersdata, correcte MOQ's en bijgehouden doorlooptijden per SKU kun je al een flink stuk automatiseren met wat je vandaag al hebt. Wil je daarna verder, dan is het zinvol om te kijken naar een gestructureerde koppeling tussen je verkoopprognose, je voorraadmodule en je bestelproces, eventueel aangevuld met AI Workers die de inkoper een dagelijks voorstel presenteren dat hij alleen nog hoeft te accorderen. Maar die stap werkt alleen als de fundering op orde is. De volgorde is: eerst stamdata, dan logica, dan automatisering.