- Getting started
- Demand forecasting
- Inventory planning
When creating forecasts with skuBrain, the software lets you define a hierarchy to help organize your product forecasts into different groups and subgroups.
A hierarchy is a chain of product attributes such as:
Category → Subcategory → Sku
Such a hierarchy essentially tells skuBrain to group your product forecasts by Category, then by Subcategory and then by Sku. The result would be a hierarchical tree of forecasts consisting of 4 different levels:
The forecast at the root level (the All sales forecast) will be equal to the sum of all of the individual category level forecasts. Similarly, each category level forecast will be equal to the sum of all of the individual subcategory forecasts within that category and so on.
What’s so great about hierarchies?
“That’s just simple grouping,” you say! Well, not quite – hierarchies are actually a bit more sophisticated than that and, when used properly, these enable skuBrain to detect trend and seasonality for products where this otherwise wouldn’t be possible.
If you haven’t already read it, I’d highly recommend you check out the following blog post describing the benefits of forecast hierarchies and some things to keep in mind when designing these:
However that post doesn’t discuss the mechanics of forecast reconciliation, which some users may find advantageous when considering how to design their hierarchies… so we’ll cover that presently.
If you haven’t read the blog post linked to above, then you may have the impression that skuBrain prepares parent forecasts in a hierarchy simply by summing/aggregating all of the child forecasts. So using the same hierarchy as we described above as an example, you might think that each subcategory forecasts was simply the sum of all of the SKU forecasts in that subcategory, and that category forecasts are created merely by adding each of their composite subcategory forecasts and so on and so forth. Such a reconciliation process would be known as bottom up reconciliation.
However this is not typically the case. By default, skuBrain actually performs a top down reconciliation, which is a bit more involved.
Top down reconciliation
Using a top down reconciliation strategy, separate forecasts are prepared for each level of the hierarchy. So, for example, for the All sales forecast, skuBrain uses the aggregate sales history of all of your SKUs to produce a forecast of how many units it thinks you will make of all of the products that you carry. It then creates separate forecasts for the aggregate sales of each of the different categories and then forecasts for the individual subcategories within each category and finally separate forecasts for each of the individual SKUs within those subcategories.
However, the result is likely a bunch of forecasts that don’t add up.
For example, imagine the following 3 sales histories and their corresponding forecasts…
Now look at the forecast for the aggregate of all of these SKUs:
A cursory glance will reveal that things don’t add up here. The sum of the SKU level forecasts in Q3 ‘14 is
18.5569 units, however the forecast against their aggregate sales histories for the same period is
So once the different forecasts have been prepared, skuBrain then does something called a reconciliation. During reconciliation, skuBrain ensures that parent forecasts match the sum of their child forecasts… and in the case of a top down reconciliation this is achieved by dividing the parent forecast up proportionately amongst each of the child forecasts, for each period.
For example, during the Q3 ‘14 period above, the individual child forecasts were:
Baseline Forecast A = 0.0049 Baseline Forecast B = 7.999 Baseline Forecast C = 10.553 Baseline Total = 18.5569
The final forecasts are thus calculated as follows
Final Forecast A = 20.0000 * 0.0049 / 18.5569 = 0.00528 Final Forecast B = 20.0000 * 7.999 / 18.5569 = 8.62105 Final Forecast C = 20.0000 * 10.553 / 18.5569 = 11.3737 Final Total = 20.0000
And once this reconciliation process has been performed for each of the periods, we end up with the following final reconciled forecasts at the SKU level:
Something you’ll note about each of the final forecasts is that rather than simply being flat lines, Forecasts A and B now slope up slightly (just like the aggregate/parent forecast). So by performing a top down reconciliation we are able to have our SKU level forecasts inherit selling patterns, to some extent, from their parents further up in the hierarchy.
If you design your hierarchy effectively, this borrowing of trends and seasonality will be a good thing… If your hierarchies are designed such that products with similar sales trends/patterns are grouped together then you can automatically apply appropriate trend and seasonality, even to products that have quite sparse sales histories (where it would otherwise be mathematically impossible to discern trend or seasonality).