Je belooft betrouwbare leverdatums door te beloven op basis van available-to-promise in plaats van de fysieke voorraad, met echte levertijden in het systeem en één berekening over verkoop, inkoop en productie heen. De datum komt dan uit getallen, niet uit het onderbuikgevoel van een verkoper.
Een klant stelt de voor de hand liggende vraag: "wanneer heb ik het?" Je verkoper kijkt naar een voorraadscherm dat 40 op voorraad zegt, zegt "vrijdag", en stuurt de orderbevestiging. Op donderdag blijkt dat 30 van die 40 al beloofd waren aan andere orders, de rest is de verkeerde variant, en de aanvulling van je leverancier komt volgende week binnen, niet deze. Dus je belt de klant terug en verschuift de datum. De eerste keer zijn ze er beleefd over. De derde keer beginnen ze dezelfde vraag aan je concurrent te stellen.
Dit is het order-promising-probleem, en het is een zakelijk probleem voordat het een softwareprobleem is. De datum die je op de bevestiging zet is een belofte. Als die komt uit een getal dat niemand vertrouwt, het onderbuikgevoel van een verkoper, of een voorraadcijfer dat negeert wat al toegezegd is en wat onderweg is, ga je hem missen. De oplossing is niet later beloven of elke datum met twee weken oprekken. Het is de belofte maken vanuit echte getallen: wat er echt beschikbaar is om te beloven, en hoe lang het werkelijk duurt om meer te krijgen. Hier is waarom de datums verschuiven, wat het je kost, en hoe je datums belooft die je kunt waarmaken. Daaronder zit een keuze die we elke klant aandringen om expliciet te maken: draai het systeem als een enabler, niet als een administratief pakket. Wanneer het systeem het ding is dat de verkoop vertelt wat te beloven, word je gedwongen voorraad, levertijden en toezeggingen actueel te houden, en de beloning is een datum die je kunt verdedigen. Een systeem dat alleen vastlegt wat al gebeurd is, kan nooit iets beloven.
Waarom leverbeloftes verschuiven
De datum breekt omdat de persoon die de belofte doet werkt met het verkeerde getal, of helemaal zonder gedeeld getal. Een paar oorzaken komen keer op keer terug.
Voorraad die je niet kunt vertrouwen. Het cijfer op het scherm zegt 40 op voorraad, maar het zegt niet hoeveel daarvan al gereserveerd zijn voor bevestigde orders, hoeveel er in een kwaliteitsblokkade liggen, of hoeveel de verkeerde maat of kleur hebben. "Op voorraad" is niet "beschikbaar om te verkopen". Beloven op basis van de fysieke voorraad is voorraad beloven die je al aan iemand anders hebt verkocht.
Geen koppeling tussen verkoop, inkoop en productie. Verkoop belooft een datum. Inkoop bestelt de materialen volgens een aparte planning waar verkoop niets van weet. Productie plant de klus in een schema dat verkoop nooit ziet. Drie teams, drie agenda's, en de datum van de klant hangt ervan af of ze alle drie per toeval samenvallen. Als dat niet gebeurt, komt niemand erachter tot het te laat is om de klant te waarschuwen.
Leverancierslevertijden die in iemands hoofd zitten. De echte tijd om een onderdeel aan te vullen is "ongeveer twee weken, maar drie rond de feestdagen, en die ene leverancier is altijd te laat". Als die kennis in het geheugen van één inkoper zit in plaats van in het systeem, is de datum op de orderbevestiging een gok, en die klopt alleen wanneer die ene persoon toevallig aanwezig is.
De hele order beloven op de datum van de traagste regel. Een order met tien regels waarvan negen vandaag verzonden worden en één in backorder staat, krijgt één datum: de backorderdatum. Of erger, hij krijgt de datum van vandaag en negen regels gaan eruit terwijl de tiende stilletjes uitloopt, en de klant merkt het gat eerder op dan jij.
Een statische datum die nooit bijwerkt. De belofte wordt eenmalig gedaan op het moment van bestellen en daarna bevroren. Een leveranciersvertraging, een herplanning van de productie of een grotere order die voordringt in de wachtrij verandert de werkelijkheid, maar de bevestiging zegt nog steeds vrijdag. De datum klopte toen hij gemaakt werd en was fout tegen de tijd dat het ertoe deed, en niets signaleerde de verandering.
Wat het je kost
Een gemiste leverdatum is geen klein operationeel hobbeltje. Het is de meest zichtbare belofte die je aan een klant doet, en die breken is duur op manieren die niet op één factuur zichtbaar worden.
Je verliest de herbestelling, niet alleen de order. Een klant die een datum kreeg en de goederen op die datum kreeg, komt terug zonder rond te shoppen. Een klant die je twee keer belde om de datum te verschuiven, begint elke toekomstige order met de vraag wat je echte levertijd is, en stelt twee van je concurrenten dezelfde vraag. De kosten zijn niet die ene te late order, het is de marge op elke order daarna die nu in een tender gaat.
Je team verbrandt tijd met brandjes blussen in plaats van verkopen. Elke verschoven datum verandert in telefoontjes, excuses, spoedzendingen waarvan jij de kosten slikt, en een verkoper die inkoop achternazit voor een status die niemand kan geven. Die tijd is niet gratis, en het is tijd die niet besteed wordt aan het binnenhalen van de volgende deal.
Je belooft te veel of je beschermt te veel, en beide kosten je. Beloof datums die je niet kunt waarmaken en je verliest vertrouwen. Rek elke datum met twee weken op om veilig te zijn en je verliest de deals waar de klant het eerder nodig had en je eerlijke-maar-opgerekte datum ze elders heen stuurde. Zonder echte getallen zit je vast tussen onbetrouwbaar lijken en traag lijken.
De oplossing, in genummerde stappen
Je lost order promising op door de datum te laten komen uit data die het hele bedrijf deelt, niet uit het scherm van één persoon. De stappen bouwen op elkaar voort.
Beloof op basis van available-to-promise, niet op de fysieke voorraad.
Stop met het gebruik van het ruwe fysieke voorraadcijfer. Het getal dat ertoe doet is wat vrij is om toe te zeggen nadat je alles aftrekt wat al gereserveerd is voor andere orders en optelt wat echt inkomend is met een bevestigde aankomst. In Odoo is dit de voorspelde hoeveelheid: het verrekent reserveringen en inkomende ontvangsten met de fysieke voorraad zodat het cijfer op de orderregel het echte is. Beloof daarop, en je stopt met dezelfde eenheid twee keer verkopen.
Zet echte levertijden in het systeem, per product en per leverancier.
De twee weken die in het hoofd van een inkoper leeft, moet leven op het product en het leveranciersrecord: de inkooplevertijd per leverancier, de productielevertijd per product, de verkooplevertijd die je nodig hebt om te picken en te verzenden. Zodra die erin staan, kan het systeem ze optellen tot een echte leverdatum in plaats van een verkoper die gokt. Werk ze bij wanneer de werkelijkheid verandert, want een levertijd die vorig jaar klopte verrot stilletjes.
Verbind verkoop, inkoop en productie zodat de datum één berekening is.
De belofte zou automatisch door de hele stroom moeten ketenen. Als de voorraad er is, is de datum pick-and-ship-tijd. Zo niet, dan is de datum leverancierslevertijd plus ontvangst plus verzending, of productielevertijd plus verzending. Odoo kan aanvulling op aanvraag draaien zodat een bevestigde verkooporder de inkoop- of productieorder triggert, en de datums verbinden van begin tot eind in plaats van op drie aparte agenda's te leven.
Beloof elke regel op zijn eigen datum, en wees duidelijk over deelleveringen.
Een order met tien regels is niet één belofte, het zijn er tien. Toon de regels die nu verzonden worden en de regels die volgen, geef elke regel zijn echte datum, en beslis met de klant of ze nu een deellevering willen of de hele order later samen. Één eerlijke splitsing is beter dan één optimistische datum voor het geheel.
Laat de datum opnieuw berekenen wanneer de werkelijkheid verandert.
Een belofte die bij het bestellen wordt gedaan, moet bestand zijn tegen een leveranciersvertraging of een herplanning van de productie. Gebruik forecasting en planning die de verwachte datums bijwerken wanneer de input verandert, zodat een vertraging als een vlag op de order verschijnt terwijl er nog tijd is om de klant te bellen, niet als een verrassing op de verzenddatum.
Het stuk waar mensen over struikelen
Een paar dingen overkomen vrijwel iedereen
Fysieke voorraad is het getal waar iedereen naar grijpt, en het is het verkeerde. De verkoper ziet "40 op voorraad" en belooft daarop omdat het het cijfer op het eerste scherm is. Het beschikbare cijfer (fysieke voorraad min gereserveerd plus bevestigd inkomend) is het enige waarop je veilig kunt beloven, en dat zit meestal een klik verderop in plaats van vooraan. Train het team om de voorspelde of beschikbare kolom te lezen, niet de fysieke-voorraadkolom.
Levertijden zijn niet "eenmalig instellen". Het hele systeem is maar zo eerlijk als de levertijddata erachter, en levertijden verschuiven. Een leverancier die betrouwbaar was wordt traag, een nieuw product heeft nog geen historie, een feestdag rekt alles op. Als niemand verantwoordelijk is om levertijden actueel te houden, verslechteren de datums stilletjes en gok je weer zonder het te merken.
Aanvulling automatiseren betekent niet dat de datum nu veilig genegeerd kan worden. Make-to-order en aanvulling op aanvraag verbinden de agenda's, maar ze gaan ervan uit dat de levertijden die je hebt ingevoerd kloppen. Slechte levertijden erin, zelfverzekerd foute datums eruit. De automatisering maakt goede data krachtig en slechte data gevaarlijk.
Een betrouwbare datum is soms een langere datum, en dat is prima. Het doel is niet de vroegste datum, het is de datum die je haalt. Een klant die te horen krijgt "de 18e" en het op de 18e krijgt, vertrouwt je meer dan een klant die drie keer "de 11e" te horen krijgt. Weersta de druk om de optimistische datum te quoteren om de order binnen te halen, want de order die je wint op een datum die je mist, is de klant die je verliest.
Editie en inrichting doen ertoe. De forecasting, de levertijdvelden, de make-to-order-routes en de aanvulling zijn standaard Odoo, maar ze werken alleen samen als ze aangezet en geconfigureerd zijn om aan te sluiten op hoe je daadwerkelijk inkoopt, maakt en verzendt. Een half geconfigureerde inrichting geeft je datums die er geautomatiseerd uitzien en nog steeds fout zijn.
Snelle checklist
- De verkoop quoteert datums op basis van het beschikbare/voorspelde cijfer, nooit op basis van de ruwe fysieke voorraad.
- Inkooplevertijden stel je per leverancier in, en productielevertijden per product, en iemand is verantwoordelijk om ze actueel te houden.
- Een bevestigde order die voorraad nodig heeft, triggert automatisch de inkoop- of productieorder, zodat de datums van begin tot eind aan elkaar gekoppeld zijn.
- Orders met meerdere regels tonen een datum per regel en een duidelijke keuze voor deellevering, niet één datum voor de traagste regel.
- Verwachte datums worden opnieuw berekend wanneer een leverancier- of productiedatum verschuift, en een vertraging zet op tijd een vlag om de klant te waarschuwen.
- Het team is getraind om de datum te beloven die je kunt waarmaken, niet de vroegste datum die de order binnenhaalt.
FAQ
Waarom kan ik het voorraadgetal niet vertrouwen wanneer ik een leverdatum beloof?
Omdat het fysieke voorraadcijfer niet is wat beschikbaar is om te verkopen. De fysieke voorraad telt alles wat fysiek in je magazijn ligt, inclusief eenheden die al gereserveerd zijn voor andere bevestigde orders, voorraad in een kwaliteitsblokkade, en de verkeerde varianten. Het getal waarop je veilig kunt beloven is de beschikbare of voorspelde hoeveelheid: fysieke voorraad min wat al gereserveerd is, plus wat echt inkomend is met een bevestigde aankomstdatum. Beloven op basis van de fysieke voorraad betekent voorraad beloven die je misschien al verkocht hebt.
Hoe berekent Odoo een betrouwbare leverdatum?
Odoo bouwt de datum op uit echte data in plaats van een gok. Het verrekent je reserveringen en bevestigde inkomende ontvangsten met de fysieke voorraad om een voorspeld beschikbaar cijfer te geven, en het telt de levertijden op die je per product en per leverancier instelt (inkooplevertijd, productielevertijd, verkooplevertijd). Als voorraad beschikbaar is, is de datum je pick-and-ship-tijd. Zo niet, dan kan een bevestigde order automatisch de inkoop- of productieorder triggeren en wordt de datum leveranciers- of productielevertijd plus verzending. De datum is maar zo goed als de levertijddata erachter.
Moet ik de hele order op één datum beloven of per regel?
Per regel, in vrijwel elk geval. Een order met meerdere regels waarbij de meeste regels op voorraad zijn en één in backorder staat, zou niet één datum moeten krijgen op basis van de traagste regel, en het zou geen optimistische enkele datum moeten krijgen die negen regels halen en één stilletjes mist. Laat de klant zien welke regels nu verzonden worden en welke volgen, geef elke regel zijn echte datum, en spreek af of ze nu een deellevering willen of de complete order later samen.
Waarom blijven mijn leverdatums verschuiven terwijl we ze zorgvuldig vaststellen?
Meestal omdat de datum bevroren is op het moment van bestellen en nooit bijwerkt, of omdat de levertijddata erachter verschoven is. Een leveranciersvertraging of een herplanning van de productie verandert de werkelijkheid, maar een statische bevestiging toont nog steeds de oude datum en niets signaleert de verandering. Gebruik planning die verwachte datums opnieuw berekent wanneer de input verschuift, zodat een vertraging als een vlag verschijnt terwijl er nog tijd is om de klant te waarschuwen, en wijs iemand aan om levertijden actueel te houden zodat ze niet verrotten.
Kan ik beter een latere datum quoteren die ik kan waarmaken of een vroegere datum om de order binnen te halen?
Quoteer de datum die je kunt waarmaken. De vroegste datum die de order binnenhaalt is waardeloos als je hem mist, want een klant die je twee keer belt om de datum te verschuiven vertrouwt je minder dan een concurrent en zet je volgende order in een tender. Een betrouwbare datum, zelfs een iets langere, is wat een klant laat herbestellen zonder rond te shoppen. Betrouwbaarheid stapelt zich op; één gemiste belofte kost je de marge op elke order daarna.