What level do you demand plan at? Or rather, where should you interact with Demand Planning data in the forecasting process? There are many steps in a demand planning process, including data collection, post game analysis, statistical forecast, creation, reporting, consensus and final approval of the plan. The hierarchy levels for each of these steps can be different and can range from low to mid to high.

The level selection has a crucial effect upon the efficiency and quality of the forecast and final results. It is important to pick the right levels for each of these activities, let us first describe the meaning of levels. Levels are simply groupings of data. And these groupings are used to create hierarchies where each level aggregates or summarizes the information from the level below.

You can visualize the levels as a pyramid where each block in the pyramid is a separate level. The bottom block is the lowest level and has large amounts of data, including customers, locations, SKU's. The data is usually noisy and sparse here. The metal block is the middle level, which summarizes the lowest level data for more effective reporting and decision making.

The top block is the highest level for executive summary and corporate level reporting. Let's look at a business example to understand how the right level helps to create a balance between receiving an input and taking an action on it. For example, if we plan to sell one million tires for a given time period, knowing the mix of size, type and performance rating is important, so we can build the correct tyres upfront based upon the supply chain activity lead time. We need to know how many economy and racing tires are needed because they are not interchangeable.

A good demand planning system can reconcile the data between high and low levels. Using sophisticated aggregation and disaggregation logic, let's look in more detail at the hierarchy level choices in the various stages of the demand planning process. Firstly, Data Collection. Information will be gathered from internal sources such as ERP systems and external sources such as customers and third parties.

The intent is to gather all this data without any loss of information. An example is shown here with data collected by Item, Customer Ship to, and Day. All the data is being collected at the lowest level of the hierarchy, aggregation which is adding all the data values up the hierarchy from the lowest to the highest occurs. In this scenario, postgame analysis, including KPI tracking, is another area where level selection is important.

Post-Game, including exception generation, is usually done at lower levels. To highlight the problem, areas that need specific planner attention, KPI or key performance indicators are generally performed at middle levels. This is to summarize data for easier decision making. And management KPI's that reveal how well a plan is performing for strategic analysis might be calculated at higher levels such as category, channel and quarter.

Now, let's look at levels used in building the statistical forecast. Lower level data can be more noisy and sparse, while aggregate levels become very smooth and uniform. We need to pick the right level that identifies seasonality and trends, but still maintains the product and regional distinctions. In many planning systems Stack generation is done at multiple levels, with an aggregate level driving the overall volume and a lower level driving the mix.

As an illustration here we see forecast data created at the levels of item type, customer group and month. These results are then broken down to the lower levels and then aggregated back up the hierarchies. Now let's look at the impact of changing or overriding the forecast with business insight. When adjusting the forecast, the lower in the hierarchy of change can be made, the better.

This is because disaggregation to lower levels will use certain assumptions, and these assumptions can ever only be approximate. Demand planning tools will typically disagregate according to a predefined calculation, such as proportional splits or according to a related measure like history or budget. In this example, changes are made at Planning Item Customer Group by quarter. Now let us consider the demand planning review step.

The levels used to align on the consensus forecast are heavily influenced by the horizons that are being predicted and the decisions being driven from the consensus number. As you can see in this picture, there is a funnel or telescope where we focus on more aggregate levels as we go further out in the horizon. The short horizon needs excellent accuracy for resource planning decisions and is performed at low levels such as Planning Item, Customer and Week. The middle or medium horizon needs accuracy at more aggregated levels.

And often uses a mid hierarchy point, such as Item, Customer, Group and Month. This will be for supply planning decision making, strategic or long term forecasts only require accuracy at higher aggregated levels such as category, channel and quarter. This will be for long range capacity decisions. One of the final steps in the demand planning process is to publish the forecast, and here too it is important to use the correct levels.

There are many downstream uses of forecast data, and the output level can vary depending on their process needs. As an example, consider deployment. Who would need information by Item, Ship to and Day. Manufacturing, however, might need data at the levels of Item and Week and for revenue calculation purposes.

The Item, Customer and Month might be the most important levels for finance. In summary, then the various tasks in demand planning need to utilize different hierarchy levels. Data collection is done at the lowest level to capture data as is and avoid any data loss. Post-Game KPI are calculated at aggregate and intermediate levels.

While exceptions are defined at lower levels to locate and resolve problems quickly, stack generation is performed at intermediate and lower levels to get a mix of trends and seasonality. Business insight overrides are performed at multiple levels depending on where the inputs are coming from. Consensus validation and demand reviews are performed at telescoping levels that match business decisions according to the Horizon and finally, publishing is performed at multiple levels, depending on downstream needs.