One forecast to rule them all. One forecast to find them. One forecast to bring them all and in the darkness bind them.
In an attempt to keep my entry on this short, let’s just look at one specific example. Let’s say a retailer has an existing Item/Store/Week forecasting system that feeds their Store Replenishment and Allocation system. The forecast is reviewed and managed primarily two and three weeks out on account that those weeks are those that replenishment can most impact when determining need for the stores. When looking at the planning process, let’s say a Product Class forecast is needed for next year to help in financial planning. The first inclination would be to use the existing forecasting process at the Item/Store level, forecast out 1 ½ years, and then aggregate the forecast up to the Product Class; however, is not quite that easy.
First off, we have to take into consideration that we would now be expecting the forecasting team to review and manage a forecast for a much longer period of time at the Item/Store level.
Secondly, accuracy becomes a challenge because we’re dealing with both decreasing accuracy as we move further out in time and decreasing accuracy as we forecast the lowest, finite data we have (Item/Store). For example, you have a greater confidence in accuracy if you’re forecasting total company sales (all stores and all items summed up) then if you try to forecast one item at one store across the same period of time.
Finally, the impact of store closings, store openings, item introductions, and item discontinues may not be known nor correctly represented that far out into the future. It may be known that next year the company plans on opening 30 more stores and that it’s expected to increase total company sales by 2%; however, it may be months before the store’s product assortment mix, introduction dates, store type, etc are known. Without having a good understanding of these type of details, it makes it very difficult to accurately forecast out at the Item/Store level that far into the future.
Since all of our heads are spinning and since I still haven’t answered the question, I’ll leave on these last couple thoughts. The need to have one version of the truth may be as much of an exercise in setting up the correct processes so that the right reconciliations can be done at the right time on the different forecasts. It definitely makes sense to try and use the same forecast when possible, but you need to make sure the juice is worth the squeeze. If ever you’re at the crossroad in which you’re questioning the squeeze, here’s a couple questions I ask myself when determining if it makes sense to use an Item/Store level forecast as an input into another process/application where a forecast is needed at the aggregate level:
- What level do you need the forecast at?
- How timely can the Item/Store forecast be generated, reviewed, and approved vs. that of the aggregate?
- How far into the future do you need the forecast and how accurate is the Item/Store forecast when aggregated for that time period?
- Do New Item, New Store, Discontinues, Closings get handled more accurately at the Item/Store level or do year over year changes accurately enough represent trends and patterns at the aggregate level?
- Will this forecast be immediately executed against or will someone be adjusting it later down the line?

