Archive for July, 2009

Forecast Interval – Weekly

Wednesday, July 29th, 2009

Last week I built a case for monthly forecasting, so why do some people prefer weekly forecasts?  Obviously, there must be some good reason, as many large consumer packaged goods (CPG) companies rely on them.

There are a couple advantages to weekly forecasts:

1)  Compatibility:  If your customer is communicating with you in terms of weekly forecasts or weekly Point-of-Sale (POS) information (i.e. CPG), generating your own forecasts in kind provides an invaluable direct linkage with them.  Getting that direct linkage with data closer to the retail customer will outweigh any potential internal forecast accuracy improvements.

 2)  Medium Volume Items:  If you are dealing with medium volume items, a weekly approach allows more rapid stabilization of the trend line and more rapid signaling when demand has shifted.  In the absence of Demand Sensing functionality, you get an update to your forecast once every week, rather than once every month.  Thus increasing the accuracy of forecasts by reacting more quickly, both as an algorithm and as a business function.

As you can see, there are advantages of utilizing both monthly and weekly forecasting models.  Next week, I’ll discuss how you might be able to get the best of both worlds…

Forecasting Interval – Monthly

Wednesday, July 22nd, 2009

In the world of distribution, the question is often asked, “What is the best interval at which to create a forecast—monthly or weekly?”  Over the next few weeks, I’d like to weigh in on the debate.  I’ll start with monthly.  Creating a forecast for twelve periods throughout the year often produces a ‘lower forecast error’ than generating one 52 times.  There are several reasons for this:

1)  Monthly forecasting normalizes to a larger bucket size so that timing issues are not as disruptive.  For instance, if an end-customer states they are going to order a SKU at a given time, but instead, the order comes in during another week.  This modifies the monthly time series in a nontrivial way.  The jitter is nearly four times as likely to be absorbed into the same monthly bucket, causing no net change to the time series.

2)  Monthly bucketing reduces the number of zero entries in the time series and allows the law of averages to work for us.   For example, if a customer places an order for 100 units every 2 weeks, we see an average of 50 per week.  However, the forecast error relative to that average is always wrong.  The order quantity is either 100 or 0, but never 50.   Looking at this series in a monthly view gives a near constant usage of 200 units per month, which is easy to forecast.

3)  Seasonality is easier to detect and forecast using a monthly timeframe.  There are a lot of natural cycles that fall into monthly boundaries, i.e. paychecks, quotas, budgets, holidays, and average weather conditions.  As well, by definition, months are in the same position every year.  Weeks, on the other hand, can move around +/- 4 days in either direction.  This generally muddies the seasonality analysis given a limited number of years to evaluate.  Putting these seasonal factors into monthly lumps more reliably allows general tendencies to develop and be projected into the time series.

As you might imagine, we at RockySoft are generally proponents of monthly forecasting for the vast majority of cases.  This is based largely on the fact that we have forecasted millions of time series, and realize there is a limit to improving forecast accuracy.  Why not allow more of the noise to be filtered out by using the larger monthly buckets (instead of weekly buckets)?  This approach generates fewer exceptions, and allows forecasts to be reviewed less frequently.  

Next week, I’ll discuss the reasons why one might choose weekly forecasting.