07 Sep 2011

Why moving averages in APO DP rarely move?

Why moving averages in APO DP rarely move?

When I was a beginning student of Statistics in High School, I was fascinated by moving averages.  This is pretty cool stuff to get an average that moves over time rather than the plain vanilla “sum it up and divide by the count” routines.

The question that we hear often from SAP APO users is about the “mysterious” behavior of the moving average model.  Many pronounce the SAP APO Demand Planning module as weak the moment they see a constant straight line as the forecast after “trying very hard” with countless hours of model iterations!!

To some, APO DP often declares the constant as the “best” forecast.  And of course, the planners are frustrated.  Management is frustrated to see a constant forecast coming from a million-dollar package most of the time.

There are many factors that may be driving this frustrating challenge-

1.  The user settings may unnecessarily eliminate the information in the historical series leaving with not much but a random variation.

2.  The configuration settings may have imposed constraints on the modeling options available to the users.  Although this was not deliberate on the part of the consultant who configured the system, the users are left with very basic models.

In a strange way, some consultants do not want to allow advanced modeling options, since they do not understand how these models behave themselves.  They do not want to be answering tough user questions on issues they are still researching!

If all the planner is left with are basic options like the Constant Model or the Moving Average Model, then they really have to settle for a straight line into the far horizon.

So let me answer the question of why even moving averages become “dead” constant in the forecast horizon.

One of the important qualities of a forecast is robustness.  Robustness means the forecast does not change like a yo-yo just based on a new historical data points.  So if you select a three-period moving average, each new historical data point will change the forecast by one-third.

So the objective is not to mimic the history but to produce a forecast that minimizes the error. Theoretically, Moving averages should produce a constant forecast into the future at least after the first two periods.  The idea of the moving average is that it will change by at least one-third of the impact of the new observation that is different from the

Let us assume there is a series that looks like this:

917, 908, 902, 907, 908, 916, 903, 912, 916, 909………..

APO DP moving average model suggests a forecast of 910, 910, 910, 910……….. etc.

I would say that is a darn good forecast.  And this is not much different from another forecast that fancily varies between 905 and 915 every month.

Let us understand the difference in error in what is being proposed here.  A forecast that is 910 each month is off by less than 1% from another forecast that varies between 902 and 915 over the entire forecast horizon.

A contrived model that looks fancier with oscillations in results between 902 and 915 perhaps can be 1% better on average than another model that proposes to use a constant 910 every month. I don’t think the trade-off to improve forecast quality by 1% is worth the model search to come up with a more complex model that mimics
the history better.

The fact that you are choosing moving average means that the data series is relatively more stable. We as planners should let moving average do its job and move on to more complex items that need your attention – items that
have a persistent trend or seasonality or both.

Trying to fit a holt-winters model when the series begs you for a constant model is NOT a good use of time. Note that SAP APO classifies moving averages under constant models.  In fact, specifying that you want Holt-Winters models in such a scenario will give you a First Order smoothing model which again gives you constant forecasts into the horizon.

Assuming you don’t have major misconfiguration issues, the demand planner is better off doing a product segmentation based on model ability and being discriminative about when to apply advanced models.

Leave a Reply