Voorraadoptimalisatie: de volledige gids

Bijna elk bedrijf met voorraad heeft een systeem dat bijhoudt wat er ligt. Veel minder bedrijven hebben iets dat zegt wat er moet liggen. Dat verschil is voorraadoptimalisatie: de stap van registreren naar beslissen.

Voorraadoptimalisatie beantwoordt twee vragen per artikel: wanneer bestel ik, en hoeveel.

De vragen klinken eenvoudig, maar het antwoord hangt af van de vraag naar het artikel, de levertijd van de leverancier, de spreiding in beide, en wat het kost om mis te grijpen tegenover wat het kost om te veel te hebben. Wie die vier kent, kan per artikel een bestelpunt en een bestelhoeveelheid berekenen. Wie ze niet kent, bestelt op gevoel, en dat gevoel is meestal te ruim voor de hardlopers en te krap voor de rest.

Wat het niet is: een nieuwe voorraadadministratie. Als de standen in het huidige systeem niet kloppen, lost optimalisatie dat niet op; hij maakt het erger, omdat hij op verkeerde cijfers gaat rekenen. Lees eerst de gids over voorraadbeheer als de telling nog niet betrouwbaar is. Het is ook geen inkoopsysteem: de bestelling zelf, de leverancier, de prijsafspraak blijven waar ze zijn. De app zegt alleen wat en wanneer.

De toepassingen lopen uiteen. Een groothandel met duizenden artikelen wil per artikel een bestelvoorstel dat de inkoper alleen nog hoeft goed te keuren. Een producent wil weten welke grondstoffen kritiek zijn en welke niet. Een webshop wil de seizoenspiek niet missen en na de piek niet op een berg blijven zitten. Een installateur wil de bus vol met wat vaak nodig is en leeg van de rest.

De kern van elke optimalisatie is per artikel dezelfde rekensom. Wie hem begrijpt, kan beoordelen of een pakket of een eigen app het goed doet.

Vraag

hoeveel er per dag of week van een artikel uitgaat, en hoe grillig dat is

Levertijd

hoe lang de leverancier erover doet, en hoe vaak hij dat niet haalt

Bestelpunt

de stand waarbij u bestelt: vraag tijdens de levertijd plus buffer

Buffer

de veiligheidsvoorraad die de grilligheid van vraag en levertijd opvangt

De vraag tijdens de levertijd is de eenvoudige helft: als er tien per week uitgaan en de leverancier drie weken nodig heeft, moet u bestellen zodra er dertig liggen. De buffer is de lastige helft. Hij hangt af van hoe grillig de vraag is, hoe onbetrouwbaar de levertijd, en welke servicegraad u wilt: hoe vaak mag u misgrijpen. Een hogere servicegraad vraagt een grotere buffer, en die relatie is niet lineair; de laatste procenten zekerheid kosten onevenredig veel voorraad.

De bestelhoeveelheid is een aparte som. Grote bestellingen betekenen minder bestelkosten en vaak een betere prijs, maar meer voorraad die stilstaat. Kleine bestellingen het omgekeerde. De klassieke formule daarvoor is oud en bekend, en hij werkt alleen als de bestelkosten en de voorraadkosten echt bekend zijn. In de praktijk bepalen minimale bestelhoeveelheden van de leverancier en de verpakkingseenheid de uitkomst vaker dan de formule.

De vraag van morgen is niet bekend, maar de vraag van gisteren wel. Vraagvoorspelling is het vak dat uit de historie een verwachting haalt, en eerlijk zegt hoe onzeker die is.

De verleiding is om hier ingewikkeld te worden: modellen die tientallen factoren meewegen, machine learning op de verkoophistorie. Voor de meeste bedrijven levert dat weinig op boven een goed seizoensgemiddelde, en het maakt de uitkomst onnavolgbaar voor de inkoper die hem moet vertrouwen. Begin simpel, meet hoe ver de voorspelling ernaast zat, en maak hem pas slimmer als die afwijking structureel is.

Belangrijker dan het model is de invoer. Verkoophistorie die niet weet dat een artikel drie weken uitverkocht was, onderschat de vraag: er is niets verkocht omdat er niets lag. Een goede app registreert de nee-verkopen of schat ze, en corrigeert de historie daarvoor. Zonder die correctie leert het systeem dat een artikel dat vaak op is, weinig gevraagd wordt, en bestelt het er steeds minder van.

Een bedrijf met vijfduizend artikelen kan niet vijfduizend keer per week nadenken. Optimalisatie schaalt alleen als de app zelf bepaalt welke artikelen aandacht verdienen en welke niet.

De combinatie is wat telt. Een A-artikel met een stabiele vraag (AX) is de droom van elke inkoper: veel omzet, goed te voorspellen, kleine buffer. Een A-artikel met een grillige vraag (AZ) is het gevaarlijkst: veel omzet, en toch vaak mis of te veel. Daar hoort het gesprek met de leverancier over kortere levertijden, of met de klant over vaste afroepen. Een C-artikel met een grillige vraag (CZ) hoort meestal niet op voorraad; bestel het pas als iemand erom vraagt.

De indeling is niet statisch. Een artikel dat dit jaar C is, kan volgend jaar A zijn. Een app die de klassen elk kwartaal opnieuw berekent en de inkoper laat zien wat er is verschoven, doet meer voor de voorraad dan een app met een ingewikkelder model op een verouderde indeling.

Een optimalisatie-app heeft zelf weinig gegevens. Hij leest uit het voorraadsysteem, het verkoopsysteem en het inkoopsysteem, en schrijft zijn bestelvoorstel terug naar de inkoop.

Standen

de actuele voorraad per artikel en per locatie, uit het voorraad- of ERP-systeem

Historie

verkopen of verbruik per artikel per dag of week, minstens een jaar terug

Levertijd

per leverancier en liefst per artikel, uit de inkooporders: besteld en ontvangen

Open orders

wat al is besteld maar nog niet binnen is; anders bestelt de app dubbel

De levertijd is de gegevensbron die het vaakst ontbreekt. Veel bedrijven hebben per leverancier een afgesproken levertijd, maar niet de werkelijke: hoe lang het de laatste twintig keer echt duurde. Het verschil tussen die twee is precies de buffer die u nodig heeft. Een app die de besteldatum en de ontvangstdatum uit de inkooporders leest, berekent de werkelijke levertijd en de spreiding vanzelf. Dat is vaak de eerste keer dat een bedrijf ziet welke leverancier onbetrouwbaar is.

Terugschrijven is de tweede stap. Een bestelvoorstel dat de inkoper in een scherm ziet en overtikt in het inkoopsysteem, werkt, maar niet lang. Bouw de eerste versie zo dat het voorstel als conceptorder in het inkoopsysteem landt, en de inkoper alleen goedkeurt of aanpast. Wat hij aanpast, is informatie: als hij structureel een artikel hoger zet, klopt de rekensom niet of weet hij iets dat de app niet weet.

Duizend of vijftigduizend artikelen maakt voor de bouw weinig uit. Wat de prijs drijft, is hoeveel systemen de app moet lezen en hoeveel opruimwerk er vooraf ligt.

Bronnen

voorraad, verkoop en inkoop in één ERP is eenvoudig; drie losse systemen is drie koppelingen

Historie

een schone verkoophistorie per artikel is goud; een historie zonder nee-verkopen vraagt schatten

Locaties

één magazijn is een som; meerdere magazijnen met onderlinge verplaatsing is een netwerk

Automaat

een voorstel dat de inkoper goedkeurt is een scherm; een order die vanzelf weggaat is een proces

Wat meestal meevalt: de rekensom zelf. Bestelpunt, buffer en bestelhoeveelheid zijn bekende formules; die zijn in een dag gebouwd. Wat tegenvalt: de gegevens. Artikelen die dubbel in het systeem staan, levertijden die nergens zijn vastgelegd, historie die begint bij de laatste systeemwissel. Dat opruimen is werk voor u, en het moet vóór de eerste berekening.

Vraag ook wat uw huidige pakket al kan. Veel ERP- en voorraadsystemen hebben een bestelvoorstel op basis van een vast bestelpunt. Als dat bestelpunt handmatig is ingevoerd en nooit wordt bijgesteld, is dat het probleem, niet het pakket. Een eigen app wordt interessant als hij de bestelpunten berekent en bijstelt, en dat in het pakket terugzet.

De volgorde hieronder begint niet bij een model maar bij tien artikelen die uw inkoper uit zijn hoofd kent. Als de app daar niet beter is dan hij, is hij nergens beter.

1. Controleer de tellingKlopt de voorraadstand van de tien artikelen met wat er ligt? Zo niet, eerst dat.
2. Haal de historie opVerkoop per week, een jaar terug, per artikel. Markeer de weken waarin het artikel uitverkocht was.
3. Meet de levertijdUit de inkooporders: besteld, ontvangen. Gemiddelde en spreiding per leverancier.
4. Reken met de handBestelpunt en buffer voor de tien. Leg het naast wat de inkoper nu doet, en bespreek het verschil.
5. Bouw en vergelijkDe app rekent hetzelfde, elke week, en laat zien waar hij afwijkt van de inkoper. Drie maanden meekijken.
6. Breid uit per klasseEerst alle A-artikelen, dan B. C-artikelen krijgen een vuistregel, geen model.