A planning framework to create impact in uncertain and volatile markets.
7 viewpoints on S&OP implementation
In theory, S&OP is really simple to implement, but due to cross-functional processes, involvement of different parts of the organisation and the need for IT support, it often turns out to be a difficult task to implement S&OP.
S&OP is about doing what is best for the company as a whole, and therefore the overall purpose of the S&OP process is to establish one overall plan.
S&OP brings these different views into one balanced decision process.
The wave of new SAP Integrated Business Planning (SAP IBP) applications opens up numerous new and powerful opportunities in order to support the S&OP process. However, it is important not only to focus on the features of the system when choosing directions for a new S&OP solution. The business, people/mindset and S&OP process also need attention when applying the system. The new IBP opportunities should improve the S&OP process – not confuse it.
The 7 viewpoints presented in this article aim to concretise and address some of the functionalities provided by SAP IBP for S&OP to support a successful and impactful implementation.
One common language is key to one common S&OP process. The S&OP process needs input from and evaluation by different stakeholders. Sales is normally focusing on $ and units sold per market, segment or brand. Finance is focusing on $ per business group, division or region. Operations is focusing on units or volume per hour per production site, capacity groups or production lines.
The idea of a common language in the S&OP process is strongly supported in IBP for S&OP. The possibility of creating attributes “freely” on master data makes is possible for Sales, Finance and Operations to aggregate and disaggregate data on desired levels – based on one data model. The attributes and “one data model” give the “Google Translate” in our S&OP process. An example of a common S&OP demand review template for Sales, Finance and Operations is seen in the figure below, where Finance reviews revenue aggregated on division.
The HANA engine in SAP IBP makes is possible to do fast calculations at a detailed level on the full S&OP horizon. Evaluating S&OP at a detailed level on a long horizon will typically not improve accuracy, but it requires a lot of effort. Therefore, the S&OP evaluations should be done at an aggregated level defined by each of the stakeholders (Sales, Finance and Operations). In case of deep dives, the data is immediately available in the system, enabling planning on mix in special situations (illustrated the in figure below).
When detailed data are available in the system, there is a risk that it will be evaluated – also on long horizons. A robust and well-defined S&OP process will mitigate this risk and ensures that the powerful possibility to do detailed planning is utilised properly.
The S&OP process should be separated from operational planning without losing the link, though. The S&OP planning process should always be built on a realistic foundation, as the base line determines the trustworthiness of the S&OP plan. That is why the operational plan should integrate towards IBP for S&OP (preferably via HANA Cloud Integration, HCI). HCI allows you to integrate data from your legacy system to IBP for S&OP applying translation rules for both master data and transactional data. For example, create combinations of the existing master data in the legacy system into new master data in IBP for S&OP (e.g. sales quantity x sales price = revenue).
The integration from IBP for S&OP to the legacy system should be handled manually, though. The actions agreed upon at the S&OP meetings are typically much more than a technical integration, and here automation could lead to misunderstandings and misalignment. Let us say that at an S&OP meeting you decide to increase to three shifts at one of your production sites in five months from now. The least that needs to be done is to update the data in the system. The heavy workload is to get the agreement with production, hire people and talk to HR etc. Therefore, we want to separate S&OP from operational planning, as decisions from the S&OP meeting are typically more than just a data update.
Scalability and planning horizons must be clarified for timely decision-making. Production, warehousing, transportation, suppliers and sub-contractors have different levels on supply chain capacities on different horizons. The decision time needed in order to increase/decrease capacity should be clarified for each key supply chain constraint modelled in the system.
Build the scalability of your capacities into your Excel planning template in IBP for S&OP. This makes it clear when to react to certain changes in your supply chain, i.e. handling an increase in demand by 50% in the coming six months as illustrated in the figure below. The scalability will determine decisions to be made per horizon and forms the foundation of the S&OP process.
Improve decision-making in an uncertain environment through scenario planning and simulations. Scenario planning is an important part of S&OP and serves to evaluate risk and consequences when the supply chain planning is not in a steady state.
SAP IBP for S&OP provides a wide range of possibilities to do scenario planning. The flexible creation of master data attributes, master data types and planning levels allows scenarios to be conducted by different stakeholders in the S&OP process and at different aggregation levels. It is recommended that the flexibility in relation to scenario planning is handled in a structured way. An example of how to structure the flexibility and what to bring into a scenario is illustrated in the figure below.
When conducting simulations and scenarios, it is possible to compare results. An example of comparison between three scenarios/versions in IBP for S&OP is seen in figure 6. Here the capacity load of three different scenarios, best-case, base line and worst-case, is compared in the same Excel planning template.
The ability to make decisions is the most central element in the whole process! Even though the HANA engine allows running simulations directly at the S&OP meeting, it is still recommended that focus is on decision-making and information rather than data. Analysis, recommendations and decision materials should be prepared before the S&OP meeting. The materials should include recommendations and consequences in an executive overview – still having background analysis available if needed.
It is suggested that Excel planning templates are built and prepared to support the S&OP meeting. When data, scenarios, graphs etc. are already available in the Excel planning template, it is easy to snip it directly into the S&OP material (see example in the figure below).
Your company has probably already invested heavily in planning solutions and processes. It is therefore important that you leverage your current investments and decide accordingly when deploying SAP IBP applications to the existing system landscape.
When giving advice on road maps for planning solutions in SAP IBP applications, the answer is almost always: “Well that depends …”.
Put in another way, only move what makes sense into the SAP IBP applications. For example, if your demand planning process is performing well in e.g. SAP APO demand planning, there may be no reason to move into SAP IBP for demand. On the figure below there are a few examples of different system landscapes, including SAP ECC, SAP APO and SAP IBP for S&OP, demand, supply and operational planning.
Be aware that the full list of combinations is wide. The main features of the SAP IBP applications are listed in the figure below and serve to show how IBP can complement the existing planning solutions.
According to Tom Wallace, the importance of the system is very low when implementing S&OP. Focus should be on people/mindset and process. However, the focus is often the other way around (see the figure below).
Hence, the people/mindset and process should be in focus. Prototyping is a good way to ensure this, and via prototyping the implementation can be done within a year as illustrated in the figure below.
Don’t go for new – go for better!
The first step is to build the business case for an S&OP implementation. Here top management should be involved and take the decision to start. The next month’s focus is on analysis to establish the S&OP process, define decision horizons, agree on a common language (basically look into the viewpoints presented in this article) and reinforcement of top management involvement. The next 3-4 months are spent on the prototype/pilot. It is important to spend time on the data model, as it is the foundation of enabling the full benefit of IBP for S&OP. The pilot should be proven in small sprints where top management and stakeholders are heavily involved in reviewing. When the prototype is proven, the cutover is made, and the IBP for S&OP application and process is live. The solution is further developed as results are proven.
SAP IBP for S&OP provides a wide range of new and powerful functionalities to support the S&OP process in an efficient manner across different stakeholders in the organisation (Sales, Finance and Operations). When starting an S&OP implementation, the trick is to focus on people/mindset and process rather than system and at the same time take advantage of the new and strong features in SAP IBP for S&OP as presented in the 7 viewpoints.
Keep in mind the 7th viewpoint throughout the implementation project: Don’t go for new – go for better!
Good luck on your S&OP implementation – maybe supported by SAP Integrated Business Planning for S&OP.
This article was originally authored by Christian Guldager.