Where to Forecast?

In previous articles I introduced the some basic approaches of planning with Why Forecast?, How to Forecast?, What to Forecast? and When to Forecast? and now it is the turn of considerations of where in your dataset you should consider for Forecasting. The location of your planning department and the skillsets of the resources within it will be discussed in the article 'Who Forecasts?'.

The Right Structure

Whatever it is that you forecast, you need structure to create the rows and columns in your Excel spreadsheet or Demand Planning system. More formally, you need Dimensions, Hierarchies, Levels & Data Streams as discussed here. The structure you build dictates how you can slice, dice and manage the data as displayed in the image below.

Where's it at?

There are a lot of places that you interact with the forecast. These places can vary as you progress through your forecasting cycle and although it is entirely normal to have multiple 'where's' it is important that they are appropriate for each activity. The more that you can synchronise them the easier it is to manage your forecast. Here is a list of typical forecasting activities where you interact with the forecast:

Collect into the Forecast Create a Statistical Forecast Distribute the Forecast Review & Compare the Forecast Exception the Forecast Simulate the Forecast Edit the Forecast Check the Forecast Lock the Forecast Approve the Forecast Report the Forecast KPI the Forecast Dashboard the Forecast Archive the Forecast Apply notes to the Forecast Export for Analysis Publish the Forecast And more!

The places that these actions are made has a crucial affect upon the quality of your Forecast. Too low and the data may be sparse, performance degraded, maintenance tough and cycle times long. Too high and the forecast becomes over smooth, allocation calculations flawed, and lower-level planner adjustments might be blown away.

Where do you currently perform these activities and, are they the correct places? Do the locations that you need to undertake these tasks properly even exist?

Hierarchies are where it's at!

Hierarchies are groupings that define how information is stored and displayed within your Dimensions. Dimensions can have multiple hierarchies and some standard examples of Location and Product Hierarchies are pictured below. Do not underestimate the amount of time it will take to evaluate, agree and clean your hierarchies and related data!

The overarching rule of the hierarchies (at least for Integrated Planning Solutions) is that they must be logical. Data collected into each level needs to have a unique parent - a one to one relationship - not one to many. Without this logic multidimensional solutions cannot operate the allocation and aggregation functions.

Where Allocation and Aggregation matter

Allocation is the term to describe how Forecast numbers will be applied down the hierarchy while Aggregation is the term to describe how Forecast numbers will be applied up the Hierarchy. Other terminology commonly used for this activity is proport and disaggregation. The functions of Allocation and Aggregation occur in two particular situations:

1. Forecast Creation
2. Forecast Change

There are sundry calculation methods for managing the allocation and aggregation of values and they include Add, Average, Minimum, Maximum, First, Last and Weighted. The methods you select for allocation and aggregation may need to vary per data stream. Some examples of how changes can be aggregated up a hierarchy are pictured below.

The reward of a hierarchy that enables changes at a higher level is speed, the cost is allocation accuracy. Below is an example of allocation down a hierarchy in a data stream using the weighting from another.

Consider carefully the allocation process using weighted data. Adjustments to History might be best weighted by "self" but what about Forecast? Do you want to weight adjustments according to forecast itself, the last time-bucket of history or the history of the same period last year or the Annual Budget or previous Approved Forecast? Each of these approaches will allocate changes differently. None will be "perfect" - evaluate the most suitable.

Where to create the Forecast.

Statistical forecasts might be generated at one set level (say, Business Unit, Item, Customer, Manufacturing Site and Day) for all combinations or could be generated by dynamically, traversing up and down a hierarchy in search of the 'best' set of data. This latter approach is called using an Engine Hierarchy or a Forecast Tree.

Both set and dynamic approaches need their levels to be optimal. Levels with uneven data step-changes (such as say, 20,000 items within 1 parent group or the opposite, 2 items within 1 parent group) are not good for statistical forecast generation.

If you are implementing a Statistical Forecast Solution you should identify the levels that will create the best forecast and collect them. The existing Sales, Marketing or Finance groupings may not be acceptable, just because levels have existed for years in your business does not mean that they will work statistically - analyse members per level for suitability. If those levels don't exist - create them. I appreciate that this is much easier to say than to do but if you don't, then that sophisticated, 'best in class' algorithm will be hampered from the start.

Where to review the Forecast

Forecast Review, KPI and Reporting is generally performed at an aggregated level with SKU's rolled to groups and families, Customers into Key Customers (and the rest) or Channels, Days into Weeks and Months and so on.

The higher you go, the more the dataset reduces and the numbers bigger so it's easier to evaluate. The biggest recommendation here is to make the levels match across the Organisation so that Sales, Marketing, Finance and Operations can all sing from the same songbook. If you are creating a planning solution from scratch, obtain all the key analysis reports and ensure that the new system can feed into them.

It's not all about levels though. Where is the forecast bad? Where should you focus your energies to improve the forecast? Define a matrix to determine the value on the return of your time. Don't focus where the impact will be low but on where the volume, value and strategy impact will be highest.

The diagram below provides an example of how the results of a volume assessment might look. Tune the forecast for significant, poor performing Smooth & Intermittent combinations and override the significant Lumpy and Erratic. Use an assessment like this to determine where planners should focus their efforts. See the article: too much data & not enough time

Where to change the Forecast.

When adjusting the forecast, the lower in the hierarchy a change can be made - the better, but sometimes time or information constraints prevent that approach. Work top down and then bottom up is a general guide but there are no hard and fast rules here as there are too many variables.

Forecast override best practice is to know your products, market history, allocation rules and to match that to your forecasting maturity and the KPI's that are the target. Use the most appropriate method of change by % or absolute at the right level and adapt easily between methods. Ensure that rules and methods are understood by all the planners. Measure the success of your overrides and remove them if and when the statistical forecast can be trusted.

Beware forecast changes at the end of the Forecast cycle during the final S&OP meeting. If a strategic volume change is required, you must be clear about how that will impact the numbers at the lowest levels (that were carefully refined by the planners). Preferably, have the S&OP changes entered at the lowest level possible. Even better, retain the pre and post S&OP forecasts so that the quality of 'strategic' adjustments can be tracked.

Where did all the time go?

I thought about this and put it here

Where to Publish the Forecast.

One final point to consider is related to the data that is being published or uploaded - where is the forecast going and who will use it? There are many downstream users of Forecast data so be sure to evaluate the Dimensions and Levels that they will need. Some examples might be:

• Supply Planning = Organisation, Item, Qty, Day
• Purchasing = Organisation, Item, Qty, Week
• Finance = Organisation, Item, Customer, Qty, Value, Month

Should the forecast be dictated by what the users of the forecast need or by the optimal levels to create and manage a great forecast? This is a very difficult question to answer without thorough analysis of the processes involved but if source and destination solutions need different levels, consider defining allocation and aggregation interface solutions.

Where did we get to?

Demand Planning processes are Create, Review, Adjust, Approve & Publish the Forecast and you must understand where they are likely to be performed to get the best out of the planning solution. Wherever possible make Dimensions, Hierarchies and Levels the same throughout your business processes.

Where are you with your Demand Planning? If you would like to take it to a new, and better place, please get in touch.

__________________________________________________________________________

Articles in this series are:

Why Forecast?

How to Forecast?

When to Forecast?

What to Forecast?

Where to Forecast?

Who Forecasts?

If you have any questions, thoughts, additions, queries or contentions about Demand Planning, Oracle Solutions or even grammar reflections please get in touch.