A poor and distrusted demand forecasting system.

The shipment history was distorted, the method labour intensive and flawed, and the results poor.

Sales forecasting, a case study

The shipment history was distorted by shortages, 'pipelining' (filling e.g. new depots) seasonality and new products. The mainframe rewrite to correct for pipelining (which is 40% of demand for this client!) was 12 months away, so they specifically wanted a "short term fix".

We took 14 month's shipments, tried about 20 or 30 different models to forecast the 15th. month, and then compared the output with the actual results for month 15. We chose a model which reduced the total error by 24%. More important, it halved the number of items which were under-forecasted. It's the under-forecasts (sales exceed expectation) which cause stock-outs. It also reduced the severity of the worst under-forecasts.

The final model compensates for back-orders, as well as adapting the forecast module automatically for new products (those with a short history).

We then put in two 'flags'. One shows if the last month's demand was greater than, say, 170% of the forecast. (i.e. Shipments 70% higher than forecast) The 170% is user settable, indeed both flags are. As the forecasts get better, you set the flag lower, so it generates a sensible number of exceptions, enough for the person to investigate and interpret. To give some idea, at 170%, 39 'high' flags showed on an 870 long list of products. By our calculations, they will set this flag as low as 120% in 18 months time. The second flag (it's actually two flags in one) catches products which are short of stock, or going to be short of stock.

The user looks at the flagged lines in the forecast. If they want to, one set of keystrokes puts a graph of monthly shipments for that product no. on the screen and prints a hard copy. The client found this so dramatic and attention grabbing that he may actually forget how much better the base forecast is.

Run time for the forecast is about 19 seconds.

What is so extraordinary is the development time. 21 hours.

From first defining the problem with the users, to them accepting both the software and the logic behind it. While this is obviously exceptional (The client already had clean data, a predisposition to change, and we developed the solution in the same application as the data) it does show the potential of modern computer languages. Fourth generation languages have cut development times so dramatically that 'prototyping' and 'throwaway programming' are now quite realistic. Three years ago, nobody could have offered this sort of 'quick fix'. (Nor would anyone have considered the offer seriously, had it been made!) A demand forecasting system we specified in May '85 could now be developed in a week, rather than the 6 months quoted at the time.

This rings very true. Please contact us