In several cases, I have already been confronted with the question of why forecasts should be used when the order books are full for the next two years. With precise knowledge about the future, you can do without forecasts and safety stocks. The BOM explosion calculates exactly which components and assemblies are required in which quantities and on which dates. That’s what you’ve always wanted!
This way of thinking is fatal and leads to the following wrong actions:
- Safety stocks are scaled back or completely reduced
- Preliminary planning at product level, but also for components and assemblies, is deleted
- Consumption control is switched to demand-driven production
That will happen:
- Deadline commitments are made on the basis of the precisely calculated plan
- Reality strikes: disruptions occur, e.g. due to delivery delays from suppliers, machine malfunctions, staff shortages due to illness and redundancies
- Production orders cannot be manufactured due to lack of material
- Due to a lack of safety or buffer stocks, there is no flexibility to bring forward other production orders
- Machine downtimes occur, valuable production capacity is lost
- Residues are created at all levels
- Planners, schedulers and production controllers wear themselves down to somehow save the situation
- Promised deadlines are not met, customers become dissatisfied and express their displeasure
- We try to prioritize according to backlog and importance of customers
- Allocation processes are set up to distribute the goods in the best possible way
- Rising costs, falling margins burden the company result
- Etc.
I don’t wish anyone to fall into this trap. If you are considering changing your stockpiling strategies, check what flexibility is required. You need flexibility to cushion and bridge disruptions.
Size your buffer stocks according to the periods to be bridged in bottleneck situations, among other things.
We would be happy to discuss with you which other settings are required to achieve the necessary flexibility.
With best regardsBernd Reineke
