Published on December 5, 2019 – Lars Sondergaard, Managing Partner at Westernacher
When implementing an S&OP Planning Solution such as SAP IBP, you often think about what functionalities the system should provide, how the planning views and dashboard should look to support the process, etc. When we initiate such a project, we see the need not only to reengineer the business processes and organization, but also to access and often adjust the different planning and reporting hierarchies within the company.
Often, we have a situation where hierarchies for products, customers, resources and plants are defined and detailed completely different between the regions, departments (e.g. sales, production, purchasing, finance and controlling) and systems.
While sales might have a market-oriented view to the product hierarchy, production might have a more internal view, such as features of the product, for example. Controlling could have its own structure based on profitability. In the case where a company has grown quickly through acquisitions, you could have hierarchies that are defined differently in different systems.
This misalignment prevents an organization from speaking one common “language” that is, from our point of view, a prerequisite for implementing any integrated planning/reporting tool used across regions, departments and business units.
Let’s explore the product hierarchy.
When we start defining product hierarchy, we make sure the hierarchy is defined with a market- oriented view – how the products are positioned to the customer.
Effective product hierarchy
= What are we selling?
An effective product hierarchy allows everyone in the organization to advocate your products in a consistent way. You create the foundation for transparency and aligned KPIs across all lines of business and subsidiaries.
Example: Automotive OEM
Product type:
Cars, SUVs, Trucks & Vans, Hybrids & EVs, Commercial Vehicles, Performance Vehicles
Product characteristics:
High Performance, Deluxe, Standard, Economy
Brand:
Fiesta, Mustang, Edge, F-150, Transit, Ford GT, etc.
Product families — How many?
If we want to ensure the involvement of upper management in the planning process, we need to report as efficiently as possible. Top management is very busy, leading to a limited attention span. You can’t discuss 30 product families during an executive S&OP meeting.
Based on literature and our experience, the optimal number of product families is between 1 and 6 (maximum 12). So, how can you depict a complex environment with less than a dozen product families?
Well you can’t, that is why you need to define a hierarchy of sub-families.
What is the right planning level?
If you forecast only on product family for “the total company”, it will not be specific enough to make any decision regarding demand, supply and finance.
If you forecast on the most detailed level, you will lose the big picture and it will be next to impossible to create a long-term forecast that will not cause more forecast errors, not less.
For S&OP, the truth lies
somewhere in the middle.
The planning hierarchy looks different from industry to industry and an important part of an implementation is to analyze and define the right planning level for the organization.
Consumer packaged Goods Industry
Caption 1: In the consumer goods industry, the focus for S&OP is typically from product family down to the packaging size.
Consumer Goods Industry
Caption 1: Whereas the capital goods industry is doing their S&OP planning from the OE (finished goods) down to the main components by location.
Better take advantage of the law of large numbers in the time horizon for Sales & Operations Planning (S&OP), where the focus should be planning on volume, capabilities to balance demand and supply in general.
When we move closer within the planning time fence, defined as the maximum lead-time plus 25-50%, we will then work on a detailed level, where the focus is on determining the right mix of SKUs to produce.
How to structure.
How to structure sub-families, product groups, etc.
From a planning point of view, we’re checking if there is a 1:n relationship between the different levels in the hierarchy, making sure that we are not only able to aggregate the planning result but also able to disaggregate. This is especially important when you aim to be able to plan on a product sub-family level as an example.
Also make sure that the level of detail is approximately the same across the product families, sub- families and product groups, etc. Otherwise you will end up comparing apples and oranges.
Make sure that the number of planning combinations is steadily increasing from level to level within the hierarchies. Instead of going from 1 to 100 planning combinations, it is better to go from 1 to 10 to 100 – that way you can better plan and maintain the disaggregation rules.
Don’t forget classification.
In addition to creating a clear hierarchy structure, it is equally important to get a consistent classification of all products.
We mainly use the following criteria for segmentation and determination of planning approach:
Material type:
Finished goods, semi-finished goods and raw materials
PLM status:
L – Launch, R – Running, O – Obsolete, D – Dying, I – Inactive
ABC:
Classification by value streams (important parts)
XYZN:
Classification by predictability (value driver))
UOM:
Units, boxes, pallets
Hierarchy cube.
The hierarchies are the foundation for any planning process and solution. They are a prerequisite for any alignment between sales, supply, and finance and controlling.
In essence: the planning and reporting hierarchies are the foundation for a common language between the departments.
The hierarchies are the foundation for any planning process and solution. They are a prerequisite for any alignment between sales, supply, and finance and controlling. The goal is to create a consistent cube with all important hierarchies and a combination of choice. Make sure that it is understood that the hierarchies are multi-dimensional, i.e. sales is not only working on the product hierarchies but is mostly working with a product/customer combination. In comparison, production is also not only working within the product hierarchy but is mostly working with a product/location combination.
Where to start?
When implementing an integrated planning solution, the shift to a harmonized planning hierarchy is not an easy task but it is a fundamental part of the success of the implementation.
Step 1: Create a Business Case:
With a Business Case any implementation program will achieve a higher standard through better focus, coordinated organization and target-oriented executions.
In doing so, you see the clear formulation of why change is necessary and what would happen if you did not change. Furthermore, it is advisable to define exactly what you want to achieve with clear measurable goals and what added value this should bring to the company. These measurable goals are the benchmark for setting priorities and for measuring the success of a project.
Step 2: AS-IS analysis:
In preparing for the change, it is important to understand where the current planning hierarchies are used. Make sure to not only ask sales, production and controlling – also analyze the hierarchies within marketing, product management, finance, corporate reporting, web shop, etc.
Step 3 A: Define the TO-BE:
When defining a new planning hierarchy, it is important to have certain guidelines to follow, otherwise the risk is that the company basically re-invents the wheel again, not reaching a common structure.
Step 3 B: Do a proof of concept / prepare phase:
In the prepare phase, the goal should be to evaluate to what extent the TO-BE processes and hierarchies can be mapped to the IT system (e.g. using the SAP IBP solution). The aim should be to provide a well-grounded decision document for a change and IT implementation project and to prepare it in an optimal way.
Step 4: Implementation of the Process, IT and Change Management Project:
If the original business case could be proven in the prepare phase, the necessary organizational and IT prerequisites are available and the project has been approved by the management, we recommend starting with a pilot implementation of a subset of product groups, making sure that you prove the process, solution and organization before rolling out the solution to the entire organization/regions.
Share this article
