Executive Summary

• Common Question: Why Does Our Product Database Look Like a Service Parts Database?
• Our reaction and the rising tide of unforecastability.

Introduction

Due to constant marketing pressure to grow the product database with new product introductions, demand histories are becoming increasingly intermittent.

Common Question: Why Does Our Product Database Look Like a Service Parts Database?

After analyzing many product databases from customers, it is apparent that companies are being saddled with “service parts” databases. This causes a fundamental mismatch between many forecasting and supply planning applications designed to work with non-intermittent demand histories.

These factors of product proliferation and increasing intermittency decrease the applicability of statistical forecasting methods and applications. All of this is, in part, hidden the fact that so few companies actually can calculate their forecast error at the product location combination.

Secondly, with intermittent demand histories, the standard forecast error benchmarks cannot be applied. There are several reasons for this. But for one, an intermittent demand history will result in a very high forecast error versus a more stable pattern. This seems “bad,” but it has no relevance because it is the nature of intermittent demand. The only relevant issue is how the error can be reduced. And this means effective forecast error measurement.

How to Deal with Zeros in the Demand History

Seeing this rising tide of unforecastability at our customers, we built our error measurement tool with error measurements that can accept many zeros in the demand history and or the forecast history. The most commonly used forecast error is MAPE.

The Issue With Intermittent Forecast Error and MAPE Calculation

However, MAPE does not work when there is a zero in the demand history. The existence of one zero period of demand nullifies the MAPE calculation and returns a #/Zero error. This is no joke that on multiple projects, customers, when faced with the #/Zero error in the forecasting applications, assume the application’s forecast error is broken.

The only way to account for this is to superimpose a MAPE override, which removes the #/Zero error but does so by superimposing a false value to keep aggregated forecast error measurements for returning the same #/Zero error.

Dynamic Safety Stock Adjustment

We do not use the standard dynamic safety stock calculation. It does not work to produce a usable safety stock, as we cover in the article Experiences with Dynamic or Extended Safety Stock.

Even though we have demonstrated this to more than seven customers, this information about the dynamic safety stock is not widely known, so companies continue to think that they only have to activate dynamic safety stock to get a usable safety stock calculation.

Our customized dynamic safety stock works with our custom forecast error, which never “quits” because of zeros in the demand history.

The Problem That Must Be Solved

Machine learning algorithms that are shown to add value in forecasting almost always work on the types of data sets that companies do not have. First, they work on multiple data streams, while companies tend only to have univariate sales data. Secondly, the algorithms are fed pristine – high-volume data, such as with the M4 forecasting competition, which we covered in the article How Real is the Data Science Gap?

What is missed?

The fact that sales history data is increasingly intermittent. We repeatedly perform analyses of companies that sell finished goods, but their data, for a large portion of the product location database, looks like service parts data.

Conclusion

With rising intermittency, we now see the largest discrepancy between service level expectations and inventory levels to have occurred. Marketing wants to keep increasing the intermittences of the database, while sales constantly want high service levels. Our application is designed to deal with these common issues. It is also used as an S&OP tool to show the relationships to sales and quantify their service levels onto the costs and loads placed on the supply chain environment.

Our application shows the direct tradeoff between service levels and inventory levels and the total inventory level, not merely the inventory level at a product location combination.