The subject of forecast consumption is often overlooked.
What is forecast consumption?
The principle is quite simple. You make forecasts, for example monthly or weekly forecasts.
You have a forecast of 10,000. To date, you have received orders for 4,000 of this 10,000 forecast. The remaining forecast is therefore 6000. Actual orders consume the forecast. It's common sense. Or it isn't.
A consumption tactic buried somewhere
Do you know what the consumption rule is in your company?
When the ERP was set up, someone probably defined a rule for forecast consumption. This was more or less documented, or forgotten. That someone may no longer be in the company. Every day, however, we receive new orders, and they continue to consume the forecasts according to the tactics that have been defined.
Let's look at an example.
This month you have a forecast of 2,500 per week, next month that drops to 2,000 per week.
You didn't receive any orders in the first week, but last week and this week you had a total of 11,000 on order.
What is the forecast remaining to be consumed?
Your system can be configured to apply different consumption conventions.
For example:
In other words, with the same forecast, depending on the forecast consumption convention, my MRP system will see a residual requirement of 5000 or 10500, which is not quite the same...
All based on the same forecast, which we know is not perfectly accurate.
In real life, the consumption tactics in your MRP system will probably be a little more sophisticated, like consuming two weeks in the past and 4 weeks in the future - which may not be much better, but that's how it's defined.
The reality of what should be consumed may require more human intelligence.
Maybe the 4,000 order for week 2 comes from our recurring customers, the ones for whom we set up 2,500 a week.
However, perhaps the 7000 requirement for week 3 was a one-off order from a customer who usually buys from another supplier, and in reality shouldn't consume any forecast at all. It was a completely unforeseen, supernumerary order.
It is likely that our regular customers will order the volumes forecast and catch up with the forecast accumulated in weeks 4 and 5.
In this case, by week 8, my requirement would not be 5,000, nor 8,000, nor 10,500, but rather 14,000!
Sometimes the truth lies elsewhere...
This is just one item. You probably have thousands of items silently consuming forecasts according to some obscure and arbitrary rule. This tactic has a huge impact on the requirements propagated in the system.
It's one of the MRP's dirty secrets.
Trigger replenishments based on actual demand
The only thing you can be sure of is that you have orders for 4000 and 7000.
Your forecasts, and the consumption of those forecasts - you're not sure, you're not sure at all, are you?
As this is a recurring product, you have set up a DDMRP buffer, i.e. a replenishment loop, a structural flow based on an average requirement of around 2,500 per week, with a fluctuation margin formalized in a red zone that you have assessed on the basis of historical demand and your anticipated risk.
You've also defined what is normal demand or exceptional demand, through a spike threshold. Perhaps the 7000 quantity was detected as a spike as soon as it appeared in the order book.
You can trigger a replenishment based on your buffer's net flow equation, without any impact from the forecast's consumption tactics.
Project scenarios by range of operation
To project your future risks, your forecast requirements, your loads/capacities - as part of S&OP - a forecast consumption logic is necessary. However, knowing that your forecasts are not accurate, and neither is your forecast consumption, you absolutely must test your operating model against several scenarios.
For example, a scenario that takes into account your high forecast assumption (3000 per week?) as well as 14,000 of unconsumed forecast up to week 8 - and another with your low assumption (1800 per week?) and only 5000 up to week 8. Faced with these two scenarios, how does the buffer of this article looks? What are the risks? What decisions need to be made?
Stop believing in precision
Your MRP system gives precise results, which are an illusion. The simple example of forecast consumption logic shows this.
As much as possible, you should base your ordering decisions on actual demand, and your projections on scenarios based on ranges.