The SAB Medium Term Sales Forecasting System : From Data to Planning Information. Kenneth Carden SAB : Beer Division Planning

Transcription

1 The SAB Medium Term Sales Forecasting System : From Data to Planning Information Kenneth Carden SAB : Beer Division Planning

2 Planning in Beer Division F Operational planning = what, when, where & how F 7 Breweries, 45 Products, 50 Depots F Centralised planning for cost optimality F Horizon : 1 day to 10 years F Sales Forecasting, Production Planning, Interdepot Planning South African Breweries : Beer Division operates a centralised planning department which is responsible for all operational planning. Planning is made complex due to the fact that the company operates 7 breweries which do not all produce each of the 45 products (brandpack combinations), and has 50 depots which all require each product. This setup leads to some interesting optimisation problems. Plans produced range over a time horizon from 10 years to the next day. The specific planning processes of the department are Sales Forecasting - in which the demand for each product at each depot is forecasted. Production Planning - determining production at each brewery to meet this demand. Interdepot Planning - planning of distribution of product from brewery to depot.

3 Sales Forecasting F Medium Term Sales Forecasting F Drives financial budgeting, and production and distribution planning F Replace APL system on mainframe F Forecasts on around 800 time series F Statistical forecast and rich editing at any aggregation level Sales Forecasts are produced across the whole time horizon. The system described here is used for determining the medium term forecast, which is essentially a forecast which spans a period of up to 15 months ahead. These forecasts are then used to drive financial budgeting and production and interdepot planning. The forecast is updated at least quarterly. This medium term sales forecasting process has been supported by a system developed 10 years ago in APL which has runs on an IBM mainframe. This system needs to produce forecasts on around 800 time series (district or depot and brand pack combinations). It combines statistical forecasting with rich editing functionality, which is used to adjust the statistical forecast to take account of expected trends and events not derivable through history. Although forecasting is done on each of the 800 time series, editing is possible at any level of aggregation thereof (districts or depots, brands, packs or groupings thereof).

4 System requirements F Windows and connect to SQL Server F Have numerous forecasting algorithms F Editing => rich programming capability F Good graphics F Cost effective F SAS Base,ETS,Graph,Access,Assist,AF, FSP By analysing the strengths and weaknesses of the current system, the following major requirements for the new system were compiled. The system had to Be PC-based and operate in the MS Windows environment while connecting to a SQL Server database. Provide a better statistical fit than the current system by having access to numerous forecasting algorithms. Have a similar rich editing capability to the current system. Augment editing with good use of graphics for time series viewing and allow for editing off a graph of a time series. The lack of graphics was a major weakness of the mainframe system. Be cost effective, both in initial and development cost. The search for relevant tools was extensive, and after months of investigations, we decided that the best software that could be used to meet our requirements was the SAS system and the following SAS modules were acquired; SAS Base, SAS AF, SAS FSP, SAS Assist, SAS Access, SAS ETS, and SAS Graph. Development commenced using the IDS Quality Partners.

5 Normalisation F Read in series then normalise prior to forecasting Re-allocate sales of discontinued products Pad new series with quasi-history Adjust series to edit out certain effects The system is now described in some detail. The first step is to read 48 months of history for all 800 series from the SQL Server database. Amongst the time series read in are certain with inadequate history, and certain which have been discontinued. The normalisation function has been developed to Re-allocate the sales of discontinued products to other products to create a hypothetical historical situation assuming the current product mix. Pad new series with quasi-history in order to obtain feasible statistical forecasts. Otherwise adjust historical series to edit out things like one off events that are unlikely to re-occur. All normalisation is done prior to any forecasting. One of the normalisation tools will be demonstrated in the presentation.

6 Forecasting F Winters exponential smoothing F Introduce tournament with X11 and Stepar, and Winters F Run in batch environment with options F Fit results justify decision Once normalisation is complete, we can proceed to produce the statistical forecast. The mainframe system used Winters exponential smoothing to derive statistical forecasts on all 800 time series. The system did, however, have no way of determining smoothing constants and made use of the same set of hard coded constants for each time series. It was deemed necessary for the new system to try out different algorithms per time series, and for the system to choose the algorithm that fits best. This is referred to as the tournament. At this stage X11 with STEPAR and Winters exponential smoothing have been implemented. Furthermore the implementation of Winters optimises the smoothing constants for each time series. More algorithms can be added at a later stage if this is deemed to be necessary. As the tournament takes some time to execute, the system has been set up to run the forecast in a batchtype environment. The user does however have a number of options for controlling this tournament, including specifying which of a number of diagnostic reports should be produced. Results to date indicate that the decision to use the tournament were justified, as different algorithms are selected for different series, although the algorithm selected most often is X11 with STEPAR. Statistical fits produced are deemed to be very good with quite a number of series producing Mean Absolute Percent Error s (MAPE) of less than 5%.

7 Editing model parameters F Edit model parameters of Base, Trend and 12 Seasonal factors F Powerful means of modifying trends modifying seasonal profiles creating a forecast for new series F Recompute forecasts to derive statistical forecast Once a statistical forecast has been produced, we have always found it necessary be able to edit the model parameters of Base, Trend and the 12 Seasonal factors. This is a particularly powerful way of Modifying trends in brands or packs that are expected to start exhibiting a different trend. Modifying the seasonal profile for a brand or pack that is going to marketed differently. Creating forecasts for new products by copying in the parameters of an existing product. Parameter editing will be demonstrated in the presentation. After any parameter editing, the statistical forecast is recomputed to derive the so-called system forecast. This forecast serves as a base for going out into the business and agreeing what the most likely sales are expected to be. The following set of tools are used to modify the system forecast with the input received from the business.

8 Edit planning forecast F Monthly statistical forecast for 800 time series F Agree the planning forecast and use editors to modify The first tool is a multi-dimensional tabular editor which allows the users to edit within any selected 2 of the 4 dimensions of geographic region (district or depot), brand, pack and time. There is also a graphical editor, which allows for editing a time series or the consolidation of a group of time series on a line graph. The final editor allows for editing geographic region, brand or pack percent shares. To enable this a heuristic algorithm has been developed. This algorithm allows for editing the shares of one dimension, while not affecting the shares of the other dimensions. These editors will be demonstrated in the presentation.

9 Restructure and split F Restructure the forecast from one geographic dimension to a lower one F Split the monthly forecast to a daily forecast The final 2 processes of the system are used to Restructure the forecast from one geographic dimension (eg district) to smaller geographic dimensions (eg depot and distributor). This is accomplished by using historical district to depot and distributor shares. Split the forecast from calendar months to days. From the daily forecast, weekly forecasts are then also derived. The splitting process also uses historical month to day splits to split forecast months.

10 Conclusion F Confidence in system and satisfied that requirements have been achieved F No forecasting package F Programming languages - longer and more risky project The system was implemented in one of the four regions of Beer Division in October Implementation is proceeding in the other three regions. The project team have confidence in the system and are very satisfied with what has been achieved. Furthermore, looking back at the decision made to use the SAS system, we remain convinced that we would not have achieved what we have done in any of the forecasting packages that we reviewed, and that our other options to use programming languages like C, or Visual Basic would have led to a longer and more risky project.