Many forecasting software packages support hierarchical forecasting. You define the hierarchical relationship of your products and locations, create forecasts at one or more levels, and then reconcile the forecasts across the full hierarchy.

In a top-down approach, you generate forecasts at the highest level and apportion it down to lower levels. In bottoms-up forecasting, you generate forecasts at the bottom (most granular) level, then aggregate to get the forecasts at higher levels. In the commonly used middle-out approach, you generate forecasts at some intermediate level, sum them up to higher levels, and apportion them down to more granular levels. Here is an example of a forecasting hierarchy:

A worst practice in forecasting hierarchy design is to confuse forecasting requirements with reporting requirements and create overly complex hierarchies in your forecasting system. The hierarchy should only include levels needed for forecasting.

Quite clearly, there are a lot of costs associated with overly rich hierarchies. There is much more data to store and process, slowing down system performance. And there is, overall, more work for the forecast analyst with more levels of forecasts to monitor and maintain.

The usual mistake, made when the forecasting software package is implemented and the hierarchy is defined, is to include levels needed for reporting.

For example, it will be of interest to know how many units of red, green, and blue colored apparel items are forecast so that the appropriate amount of fabric or dye can be procured. Should color, therefore, be a level in the forecasting hierarchy? Probably not, unless there is someone assigned to generate forecasts by color.

The proper approach would be to export item level forecasts to a reporting system, then aggregate the item forecasts according to their color attribute. (This requires, of course, that you maintain master product files that know the color attributes of each item. If you don't have such files already, your issues are much deeper than forecasting, and you shouldn't be wasting time reading this blog.)

Another common mistake is to include levels at the bottom of the hierarchy that are more granular than necessary for forecasting.

Levels at the bottom of a hierarchy can dramatically increase the amount of data and processing required. Demand at these lowest levels is often very erratic or intermittent, and you probably can’t generate a good forecasting model at that level anyway.

For example, one large retailer has over 30 million store/item combinations, and over half of these sell less than one unit per week. Similarly, in apparel or footwear you may have workable numbers of sales at a style or even style/color level, but demand becomes very sparse when you go down to style/color/size.

Recommendations

In situations where data is very sparse at the most granular levels, it is usually best to focus your forecast modeling at some intermediate level, such as warehouse/item for the retailer, or style/color for the footwear manufacturer. Instead of incorporating the most granular level (store/item or style/color/size) in the forecasting hierarchy, you handle this level separately through inventory management policies, or through size profiling capabilities.

The forecasting hierarchy should only have the levels at which you are producing forecasts (that is, either generating statistical forecasts or making manual overrides). If additional levels are required for reporting, this should be handled outside the forecasting hierarchy. There is no need to encumber your forecasting system with extraneous levels.