The SOP process typically spans the next one to three months, depending on the type of industry and manufacturing processes. In a Consumer Packaged Goods (CPG) industry, the SOP starting point (after the frozen period) can be as short as one week, while in most other industries the starting point usually lasts about one month. Capital-intensive industries in which production changes are not easy to manage or are expensive also tend to have a longer frozen period.

While basically all companies have some type of SOP process, big differences arise in terms of clear process definition and system support. A well-performed and sustainable SOP process enables companies to detect supply problems early enough to avoid customer dissatisfaction. Its main idea is proactive planning rather than reactive firefighting.

This article concentrates on the activities performed during the SOP process and the tools Advanced Planning and Optimization (APO) offers to enable them. It is based on best-practice SOP processes and lines up these activities with APO functionality. Understanding and implementing the SOP process in an APO environment is not that difficult once the concepts are clear.

The SOP process is an iterative one, by which I mean that, frequently, you must repeat a loop of steps 1 to 3 (described below) before you can reach a consensus between demand and supply planners. The SOP steps are:

1. Demand planning. The first step defines the quantities you can sell to the market, regardless of the supply capability. This is the unconstrained forecast, since it doesn’t consider supply constraints. The task uses the APO Demand Planning (DP) module and might also include the planning of promotions. The most important aspect of demand planning is accurate future demand predictions. To achieve this, suppliers and customers occasionally work together based on processes called vendor-managed inventory (VMI) or collaborative planning, forecasting, and replenishment (CPFR). Both processes work toward developing a single shared forecast of consumer demand that serves as a joint driving plan for both collaboration partners. The idea in both cases is that the customer has a better, more reliable view of future demand and can thus provide the supplier with a better forecast than the supplier could himself. Both VMI and CPFR are collaborative planning concepts. A formal sign-off of the unconstrained demand marks the end of this planning step.

2. Release of unconstrained demand. Once you know the unconstrained demand, release it to supply planning using the appropriate system function via menu path Demand Planning> Planning>Release>Release Demand Planning to Supply Network Planning or transaction /SAPAPO/MC90. Within supply planning, this forecast is called the independent requirement. After this release, you can compare the unconstrained demand to the supply capability.

3. Supply and demand matching. This planning process is not the day-to-day planning, but a separate task that you must do without interfering with the normal operation. Do this by releasing the unconstrained demand to a planning version that is not the “active” planning version. In APO, the active planning version is the one entitled 000. This planning version is based on the active supply chain model with the same name 000. Master data being transferred from R/3 via the Core Interface (CIF) is attached to the active supply chain model (000) automatically and transactions are created in the active planning version (000). The active planning version is linked to the active supply chain model, as you can see in Figure 1 (menu path Master Data>Planning Version Management>Model and Version Management or transaction /SAPAPO/MVM). Use this transaction to create new supply chain models as well, or planning versions if you run simulations.

Figure 1

The model and version management view shows the relationship between the active planning version (000) and the Active Model

This means that the transactions in the APO planning version 000 change frequently whenever a transaction is created or changed in R/3. A typical SOP process spans one week or one month, during which the demand and supply situation should not change. It is very difficult to derive the best plan while the demand or supply situation changes continuously.

It is advisable for this reason to not use planning version 000 for the SOP process. To carry out the SOP process in a separate planning version or to do simulations, you must create such planning versions in the APO system first. I describe this process in the sidebar, “Supply Chain Models and Planning Versions.”

This recommendation becomes more obvious when you run simulations during the SOP. Simulations in planning versions where demand situations are tested against several supply scenarios are likely to interfere with the day-to-day planning the moment master data is changed during these simulations. It is worthwhile to note that APO allows some of the master data to be different for each planning version, allowing great flexibility during simulations without interfering with day-to-day business. Supply and demand matching occurs in the APO Supply Network Planning (SNP) module using time buckets of a day or week in a planning version not equal to 000. A weekly time bucket means that you aggregate and compare demand and supply within a week, not considering any sequence constraints that might exist in production.

At the end of this process step, the supply planner proposes one or several supply scenarios to the SOP meeting that should already be aligned with the demand planning team. Note that you might carry out steps 1 to 3 several times in an iterative approach before reaching a feasible plan.

4. SOP meeting. During the SOP meeting, the demand and supply stakeholders must agree on a feasible scenario that balances demand and supply. Possible actions in times of short supply are temporary outsourcing of manufacturing, buy instead of make, and delivery from suboptimal internal warehouses. You might also need to scale down on the unconstrained forecast if no possible sources of supply are available. In this case, steps 7 and 8 are very important. Unfortunately, many companies fail to follow through on these valuable steps.

Should demand and supply stakeholders determine that they need to reduce the demand forecast, you must copy back this reduced demand forecast from the APO SNP environment to DP. This copy back is a system task a user must trigger at the end of this SOP process step or schedule to happen automatically at a certain time. This activity, described in step 5, allows the demand planner to compare the unconstrained demand plan with the constrained supply network plan.

The outcome of the SOP meeting is a commitment from the demand side to sell the products the supply side has committed to supply. It is a company-internal contract and any deviation from it needs to be followed up in the next SOP meeting. If you can’t reach an agreement, you need to start a completely new planning loop beginning with the demand planning step.

5. Release to DP. Figure 2 shows a simplified data flow from customer forecast through to supply planning and then back to DP. The numbers provide an example in which the demand forecast of 500 in location A is not attainable and only 400 can be delivered. This would lead to a proportionate reduction of the individual customers’ forecasts. You can change this automatic distribution of the constrained supply in DP as part of the production execution support (see step 8).

Figure 2

Sample simulation scenario process flows

Once you know constrained demand, release it back to DP using menu path Supply Network Planning>Environment>Release to Demand Planning or transaction /SAPAPO/LCOUT. I’ll describe this release in detail in an upcoming article.

6. Release of constrained demand. Copy the final agreed-upon demand plan from DP to the active planning version 000. This is where SNP and Production Planning and Detailed Scheduling (PP/DS) use it to drive day-to-day planning for manufacturing, transportation, and purchasing. Also, the system carries out forecast consumption triggered by incoming sales orders in the active planning version 000, further refining the agreed-upon demand plan. This plan is valid until another SOP meeting agrees on a new plan.

The activity performed in the APO system is the same as described in step 2.

7. Customer collaboration. In a collaborative planning environment in which the customer provides a forecast to the supplier, the supplier must either confirm this forecast or notify the customer of any anticipated shortages. The supplier should also discuss such shortages with key customers even if no collaborative planning agreement exists.

8. Execution support. Most companies do not want to sell their products in such a way that they compare incoming sales orders only to the existing stock. They also want to compare them to the existing demand forecast per customer. In this way it is impossible for the first sales order to take all available stock specifically in a supply-constrained situation. The last step of the SOP process is to define which customer (or customer group) gets which quantity. APO supports this process using the Product Allocation Planning functionality that is part of DP and Global Available-to-Promise (ATP).

Product allocation planning is an execution support step, not a planning step. During the SOP process, you make decisions as to which customers may receive stock in short-supply situations. This information is stored in DP. Product allocation planning picks up this information and uses it to drive the availability check (ATP) during sales order entry in R/3. The way APO and R/3 work together is totally seamless for the user.

Figure 3 shows the typical flow of events throughout the SOP process. A defined end-point occurs when the customer collaboration and execution support tasks have been finished. The other end point is the hand-over (release) of the constrained demand plan to supply planning.

Figure 3

SOP process flow

Now that you understand the principles of the SOP process and the tools used in the system, I’m going to discuss two topics that are related to the SOP process. They are frequently the cause of misunderstandings or inefficient APO system usage.

1. Budget. You can see and handle the budget process as a yearly SOP process. Once you have set up a formal SOP process, it is easy to use the same planning steps and system setup to handle the non-monetary part of the budget process. Avoid including any monetary aspects in the APO DP environment, as DP was designed to forecast quantities and not financial values. The system offers possibilities to express a forecast in financial terms, but this is intended as a tool to express volumes in values. You should not use it to forecast values and then translate them into volumes. The monetary aspect of the budget, from a system point of view, is handled efficiently in either R/3 or BI-SEM.
   
   
2. Deployment. Deployment is not part of the SOP planning task. The purpose of deployment is to distribute supply in accordance with demand that either stems from the SOP process or from actual sales orders within one’s own distribution network (e.g., from factory to distribution warehouse). After you finalize the SOP process, the system restricts all incoming sales orders in accordance with this plan. This is why sales order demand does not exceed planned levels. Deployment serves as a final confirmation that products will ship according to plan. You can also set up deployment to distribute products in a “fair share” manner if unexpected (unplanned) supply problems arise in the short term. Unlike product allocation planning, which is a proactive planning tool, deployment using fair share rules is a reactive execution tool that kicks in automatically on exception.