Most organizations find it challenging to build realistic demand forecasts for the individual products that they carry.
For many businesses, broad trends such as year on year increases in the aggregate of all sales for the business, or even semi-accurate seasonal patterns for
groups of products (such as “Winter Sports Gear”) might be fairly easily discerned from sales history. For example, you might simply be able to use your trusty
old eye-ometer to realize that sales for the company below are generally increasing year on year or that this company usually sees a bit of a spike in sales
during August and September each year.
By contrast, it’s much more difficult to draw conclusions from the sales history for an individual product SKU. What might we say, for example,
about the sales patterns of the following product based on its sales history?
There’s not enough history for this product to be able to venture any ideas as to whether sales are generally trending up or down or whether there are any clear
seasonal patterns (the spikes in October and January might be completely unrelated to the time of the year – perhaps they corresponded to one off events).
And yet inventory planning decisions have to be made at the SKU level… you can’t send your suppliers an order for “some winter sports gear please”. One
way or another, decisions need to be made to purchase specific quantities of specific SKUs.
SkuBrain’s solution to this problem is to generate multiple forecasts in a forecast hierarchy and then combine these together. The idea is that although sales
data for specific SKUs can give us a good (or as good as any) idea of expected sales volumes for each SKU, aggregate demand forecasts will likely better predict
broader trends and seasonal patterns.
To see how this works in practice, let’s see what SkuBrain does with the above SKU level forecast.
SkuBrain begins by generating a baseline statistical forecast for the SKU. This forecast takes into account only sales for the specific SKU.
As we already mentioned, with so little sales data we can’t tell whether there are any broader trends or seasonal patterns, so the statistical forecast simply
produces a flat line. SkuBrain will try various different algorithms – in this case it settled on Exponential Smoothing.
Of course, if it is able to detect trend and seasonality for the SKU this won’t be ignored but, often as not, forecasts for specific SKUs just look like a flat line.
Once the SKU level baseline forecast has been produced, SkuBrain then reconciles this with the parent forecast (in this case the parent forecast is the root
level forecast for all of the products that the company sells). During the reconciliation process, the SKU forecast will essentially borrow some trend
and seasonality from its parent. The result is a forecast that reflects the sales volumes of the particular SKU but incorporates trends and seasonal patterns
from the parent (aggregate) forecasts.
Modifying forecasts in a hierarchy
If you’re not happy with any of the forecasts that SkuBrain produces automatically, you can always modify these before they get used in inventory planning decisions.
Furthermore, you can modify forecasts at any level of the hierarchy and SkuBrain will take care of reconciling your modifications throught the forecast hierarchy.
For example, if you increased the forecast for December of the root level forecast by 10%, this would result in a corresponding increase in December of 10% for all
of the SKU level forecasts.
Adjusting forecasts has already been covered in a previous post however, so I won’t rehash all of
Choosing an appropriate hierarchy
Once you understand how SkuBrain hierarchies work, you can probably appreciate that they can be used for both good and evil.
A good hierarchy will often be the simplest one…. don’t feel like you have to add attributes into your hierarchy just because you can. If you add a level into the
hierarchy, it should be because you feel that the SKU forecasts within the various branches of that level of the hierarchy are somehow temporally related (i.e. they
share similar trends and patterns). Moreover, they should not be temporally related to the SKUs in different branches – there’s no point in forecasting two groups of
SKUs separately if the SKUs in both groups share the same sales trends and patterns.
Here are a few things to consider when designing your hierarchies.
Obvious examples of products that will be temporally related are products that are typically sold within the same season. If you have a season attribute that you can
use, this is a great one to throw in the hierarchy (probably make it the very first level in your forecast hierarchy). Alternatively, various other attributes may imply
seasonality. At the online retailer that I worked for we had Categories for our products such as “Winter Boots” – so Category was an obvious attribute to be used for
forecasting in that company.
In addition to thinking about how products will relate to one another in terms of seasonal patterns, you might like to think about trend.
For example, new products might be more likely to be on the rise. Products that have been around for decades will probably have fairly stable demand and perhaps
clearance products will all share a downward trend. If you have an attribute in your sales data that could perhaps reflect the lifecycle of a product then, this
might also be a logical attribute to add into your forecast hierarchies.
Other attributes that could potentially be used for this purpose are things like Brand – since sales for products from the same brand may tend to rise or fall together.
As a rule of thumb, try to add levels to your hierarchy only if you think they will add information to your forecasts. For example, if your root level
forecast already incorporates pretty good seasonal patterns that you think are relevant to all of your SKUs, but you think individual product lines might have
trends that are often distinct from that of the root level forecast, then perhaps try to add an attribute to the hierarchy that is likely to highlight the trends that
different product groups share.
Most likely, you already have a pretty good feel for the factors that influence the sales of the products that you sell, so it’s just a matter of incorporating that
knowlege into your hierarchy designs. With a bit of playing around and visualizing various different hierarchy options, you’ll eventually find a formula that makes
sense for your organization and most likley stick to it.
I’ve no doubt glossed over certain details in my ramblings above (and there are plenty of details for maths geeks), but hopefully this gives you a better idea of what
SkuBrain hierarchies do so that you can use them as a force for good – not evil!