We have devised a set of best practices from our experience implementing SAP Advanced Planning & Optimization (SAP APO) optimizers in numerous projects. In addition to sharing these tips, we also outline typical challenges and key success factors for optimizer implementations. Using ASAP methodology and the example of a Supply Network Planning (SNP) Optimizer we take you though a typical implementation life cycle. The process works for all SAP APO optimizers.

Phase 1: Project Preparation

Project preparation is the first phase of the implementation project in ASAP methodology. While in most projects, optimizer implementation is part of a bigger project such as an SAP APO implementation, you need to take special care in the following areas as part of project preparation: 

• Project planning
• Detailed project scoping
• Sizing for optimization server

Project Planning

A few special milestones that are not common in a standard SAP project should be part of an optimizer implementation project plan. One example is a full volume simulation phase, which is a must for any SAP APO optimizer project. While trial runs with small sample datasets can work well for other SAP APO processes (such as heuristic or deployment processes), the quality of results from an optimizer can only be tested when the run is taken with all master data (all materials and resources) and transaction data (such as stock and orders). Cost models or constraints may need tweaking after the simulation. Many companies use this simulation phase as a replacement for user acceptance testing (UAT) for processes for which the SAP APO optimizer is used.

While the need for simulation is evident, from a project planning perspective the next question is how much time should be kept for this phase. From a business user’s perspective the answer may be “until I get a satisfactory result,” but this does not make the project manager happy.

There is no single right answer for the duration for simulation; however, there are a few simple rules of thumb. For example, if the optimizer run is planned monthly, at least plan for two to three monthly simulation runs with real data before go-live and then compare the result with the actual. The simulation result should be compared against a set of key performance indicators (KPIs), such as whether the plan meets inventory target days, utilization benchmarks, or customer service measures. The best possible result needs to be defined in terms of a set of KPIs that is measurable and not subjective.

Another important step in project planning is to decide whether to take a big bang or a phased approach for optimizer implementation. While most companies take a phased approach for such an implementation, if a big bang approach is selected it’s important that such a large-scale rollout should only happen after a successful pilot. There can be different approaches for rollouts, such as location (do it first for a selected set of factories or distribution centers) or product category (choose a selected set of product categories under optimization scope). However, in such cases ensure that all related resources are kept in scope. For example, if three different product categories are produced in the same machine, all three categories need to be in scope for a complete capacity view of the resource.  

Detailed Project Scoping

The success of an SAP APO optimizer project also depends on how clearly the project’s scope is defined. While in most cases an SAP APO project has a high-level scope defined before the start, during the project preparation stage this scope is documented to the most minute detail. It’s desirable to get answers to the following questions during this stage:

• Between which legs of the supply chain it makes sense to run the optimizer (in the factory, between the factory and distribution center, between the factory and customer groups, between the factory and suppliers, or among the distribution center, factory, and suppliers)
• Which processes are in scope of the optimizer (distribution optimization, production schedule optimization, transportation optimization, or sourcing optimization)
• Whether there is a monthly weekly, or daily optimizer run

In some projects it’s difficult to answer these questions until the blueprinting ends, but it’s important that you answer them as early as possible and set the right expectations. Many optimization projects begin with unrealistic objectives such as end-to-end optimization. (A good example is a food company that started an optimization project with the objective of firm-to-fork optimization and eventually landed into problems.)

A single global optimization run that decides the optimal quota for suppliers, the best production schedule for factories, and the allocation for distributors can give the best overall result. However, it can also involve too many constraints and parameters, increasing the problem size to an unreasonable proportion and making it difficult for the planner to analyze the result.

Our experience is that a large supply chain involving hundreds of distributors and factories and a few million supply chain constraints can be an unmanageable size for an SAP APO optimizer. The run takes several hours and the results can be extremely difficult to analyze. A few companies that initially tried a global optimization solution for all their factories, distributors, and suppliers together for North America had problems and finally discovered that a local optimal solution involving a set of factories and distributors gives them the desired result.

If you decide on a locally optimal solution, keep in mind that it can take time to convince the business that it meets the requirements. This expectation setting needs to start early. Additionally note that it is possible to run the optimizer in such a way that it respects the results of the previous optimization runs. In the case of very large supply chain optimization problems, you can break the problem into small manageable pieces.

Breaking an optimization problem that involves suppliers, factory, and distributors into three different problems can give more understandable results. These three can be:

• The optimal quota between suppliers and factories considering a supplier’s capacity and cost
• The optimal allocation between distributors and factories to decide a gross monthly or weekly production plan for factories
• The optimal factory product schedule

A detailed analysis of the supply chain may also reveal that even if a company wants an end-to-end process, a lot of products or locations need not be in the scope of optimization simply because they can be manufactured only in one factory or because certain items can be sourced from only one supplier.

Beyond production restrictions, there can also be other restrictions such as tax advantages or global trade restrictions that necessitate that particular products be sourced from a particular region (or country or state). These all need to be factored in when deciding the scope of the optimizer.

In some make-to-order processes or discrete industry applications the optimizer is used at an aggregated level (i.e., an optimization run at a planning item between factory and customer groups). In these cases getting the starting situation right in terms of available stock and orders is essential for obtaining satisfactory results. Secondly, constraints such as prioritization of customer groups, campaigns, or work in progress may require additional master data design considerations.

Sizing for the Optimizer Server

A separate server is needed for optimization – the planning for that is one of the project preparation activities. Sizing depends largely on the complexity of the optimization problem. While theoretically, it is possible to plan for a larger server for an optimization problem of large complexity, often instead of using the server size it is better to break the problem into smaller sizes as discussed earlier. Product and time decomposition tools supported by SAP APO are also useful in handling large and complex optimization problems. You can maintain them in the Optimizer profile. The maximum time that the company can afford for an optimization run also dictates the sizing of the optimizer server.

About 25 percent of the optimization run requires the optimization server; the rest happens on the SAP APO box. After the first trials, you can quickly define what is needed. To estimate the sizing, the Basis or sizing team needs input from functional experts. Some of the following elements can be estimated (possibly with lot of assumptions):

• Number of planning buckets
• Number of location product combinations for which the optimization run is carried out

• Number of lane product combinations
• Number of Production Process Models (PPMs) for a linear optimizer, or number of PPMs with lot size requirements for a discrete optimizer
• Number of resources
• Number of setup groups    

Phase 2: Blueprinting

Blueprinting is the second phase of the project as per ASAP methodology where detailing is done on how the optimizer supports business processes and requirements. While at a high level the activities and deliverables for the blueprint phase for every SAP project remain almost the same (such as defining a business process hierarchy [BPH], finalizing the to-be process designs, and identifying gaps), an SAP APO project having an optimizer in scope may need additional activities. In the next section, we highlight some of these with a few examples from our projects.

You May Need Additional Subprocesses in BPH

Typically developing a BPH and master list of business processes is one of the first set of activities in a business blueprinting phase. This is typically developed when the project team is new and has a high-level understanding of the company’s business processes.  You can create a BPH in SAP Solution Manager to give a high-level view of processes and sub processes under the project scope. In all the SAP APO projects we worked on that had an optimizer in scope, we had to add several sub processes in BPH for processes that had used the SAP APO optimizer.

Here is an example: A food company planned to use an SNP Optimizer for production planning for its manufacturing units. The first BPH the project team developed had only one process for production planning. When the detailed process discussions started, the company understood that the modeling challenges and constraints were different for its manufacturing units that produced different product lines such as confectionary items, ready-to-eat items, pasta, staples, and spices. Even the objectives of optimization varied across units. Some were company owned, some were contract manufacturers, and a few were pure vendors. The production planning process planned as one process initially in BPH had several variants later on and a number of sub processes under each depending on the type of product.

Limited Scope for Custom Developments in Core Logic

There is limited scope for adding new constraints or building new algorithms within an SAP APO optimizer. Unlike most other SAP modules customer-specific algorithm development may not be easy or feasible. It is advisable to check with the SAP customer development program to see if it can support certain critical developments. You should also check beforehand whether an SAP APO optimizer can solve the type of problem for which you propose to use it. Our earlier article on this provides a host of problem types that an SAP APO optimizer can solve and a set of problems for which an external optimization engines may be required. While a lot can be achieved by intelligent modeling, in some cases companies need specific developments within the SAP APO optimizer.

Prototyping Is a Regular Activity During Blueprinting

When proposing a solution approach (modeling), it is common to do a small test prototype on the system just to ensure that the proposed solution works for the given requirement. Sometimes there may not be a direct approach to model for a specific requirement and this may need a workaround such as additional master data modeling.

Designing the Planning Cycle Is Important

The optimization run can be a daily, weekly, or monthly run depending on specific business requirements. Whatever the frequency, such a run needs a set of activities to be performed before and after the run. Such predecessor and successor activities (with inputs/outputs), dates, times, and responsibility need to be defined during the blueprinting phase. Sufficient time needs to be provided to the planner to analyze the results, take corrective action, and provide agreement.

Here is an example from a consumer goods company: A large consumer goods company implemented an SAP APO optimizer between its factory and warehouses to decide on a monthly distribution and production plan. For this company each distributor was attached to a particular warehouse from which it obtained its supply (i.e., fixed pegging between the distribution center and the warehouse). However, warehouses are allowed to source material from any factory depending on the lowest cost.

The company’s planning cycle starts with a demand planning process in which distributor demands are finalized. These demands at the distributor level are released to SNP. SNP safety stock planning calculates required the safety stock level at each distributor. A set of heuristic runs propagates this demand from the distributor to warehouses. The next optimizer run between the warehouse and factories decides which warehouse should source from which factory and how much. After the optimization run, a set of heuristic runs at factory level propagates the demand for components to suppliers based on the defined quota. All these activities are part of a monthly planning cycle that needs to be completed within the first three working days of the month.

Data Analysis Is Critical

Implementation of an SAP APO optimizer requires analysis of current planning data. Depending on the scope of the optimizer project, you may need to include current product categorization (for example, identifying make-to-order or make-to-stock categories or the most profitable products), customer categorization (such as key customers, spot customers, or most profitable customers), lot size restrictions, allocations (for example, allocation logic of a customer order to a particular factory), and forecasting levels.

Check out how a leading tire manufacturing company completed multiple levels of data analysis during implementation of the SNP optimizer. The company wanted to increase its forecast accuracy by using SAP APO demand and supply planning tools including SNP Optimizer. It completed a thorough data analysis to design the processes to support this objective.

• Analysis 1: Categorize the products on quantity and volume using ABC analysis. By analysis of data it was evident that the forecast accuracy (including Mean Absolute Percentage Error [MAPE] and Mean Absolute Deviation [MAD]) was higher for the A category and lower for other categories. Thus it was suggested the company forecast the A category of products by key account managers at each sales office and aggregate this forecast to a national level. Other categories were forecasted at a national level and disaggregated to the sales office level. More weight was provided to the A category products in the SNP optimizer run.

• Analysis 2: It was also understood by data analysis that there were skews in sales of tires during the summer months (i.e., higher sales in summer) that required pre-building stock. From the optimizer perspective it means you need to release a forecast for a longer horizon and reduce the storage penalty. This shows that you need to understand the business and market situation by doing a thorough data analysis.

Aim for a Practical and Sustainable Solution

Finally it’s important to remember a few simple design principles while doing business blueprinting for an SAP APO optimizer. 

• Do not overkill the optimizer with constraints. Try to model only the most important constraints to achieve the desired objectives. Most companies’ supply chains can have an enormous number of practical constraints. They have production capacity constraints at factories, storage constraints at factories and warehouses, handling constraints at warehouses and distribution centers, and lot size constraints in terms of receiving materials from suppliers, producing finished goods, and delivering it in truck loads. Even a simple supply chain involving a few distribution centers, warehouses, factories, and suppliers can result in a few thousand constraints if all of them are considered. While considering all constraints ideally gives the most optimal result, the fact is this often results in a huge problem size and a long run time for the optimizer. More importantly it makes it difficult to analyze the results. For example, an unfulfilled delivery can happen for a variety of reasons, such as no production capacity in that bucket, no storage space at warehouse, or a capacity constraint at the supplier’s end. For this reason it is important to model only the most important constraints, even if that gives a semi-optimal solution.

• Design for fast interpretation and understanding of results to build planner confidence. Moving to an optimizer is a big change for the business user who perhaps was traditionally comfortable in using Microsoft Excel for planning. If the planning results cannot be interpreted by the planner quickly, there is a high chance that he will dump the tool. Therefore, it’s important that a planner’s input be taken at every stage during business blueprinting while designing the process. Also take the planner through a lot of simulation runs to show how the system behaves and how to interpret the results.
• Design for easy maintenance and changing business market conditions for the future. Business constraints and objectives keep changing. These need to be modeled on an ongoing basis. In some projects an optimizer can start giving unsatisfactory results as the modeling was never reviewed from the time the implementation core team finished its work. During the blueprinting stage it is important to design the process in a way that you can easily maintain it. 

Phase 3: Realization

Realization is the third phase of the project when the system is configured following the design created in the earlier phase. The project focuses on modeling during this stage.

Modeling Cost for an SAP APO Optimizer

Modeling costs can be a sensitive topic. In most of the optimization projects I have worked on I have seen a lot of intellectual discussion among project teams on how to model costs. Typical discussion points are:

• Which cost to take: Actual or notional (representative) cost. For example, if you know that not delivering orders to a customer on time is unacceptable, you can put a very high notional cost for non-delivery (i.e., 999999) without actually trying to measure the actual non-delivery cost.
• How to get actual cost figures and how to keep them updated on a regular basis
• How to calculate notional cost
• Can the optimizer work with both these objective functions simultaneously – cost minimization and profit maximization as the business needs cost minimization in terms of sourcing and profit maximization in terms of product mix and customer order fulfillment decisions
• How to model costs if you need a layered optimization (i.e., blocking capacity first for priority customers and then optimal allocation of capacity among the most profitable customers)

• Can we model cost to influence the way we want the optimizer to behave

While there is no one-line answer to most of these issues, the fact is different companies develop cost models based on their own business priorities. There is no hard and fast rule.

Actual costs can be a starting point: Some companies start modeling costs with actual cost figures. A large consumer goods company having a business interest in tobacco and food was running an optimizer between its factories and distribution centers. The purpose was to decide on a monthly production plan for its factories (formerly called the factory program for the month) and an allocation plan for its distributors. In this case the optimizer was also used to decide which distributor should source from which factory. The decision used to be based on total cost (i.e., transportation cost from distribution center to the factory and production cost at the factory). The company developed an elaborate procedure to capture actual variable costs for production, transportation, loading, and unloading, and the different taxes related to transport. All transport-related costs are maintained in the SAP APO transportation lane and production-related costs are in SAP APO PPM. Optimizer runs with these actual costs and provides monthly plans. The company developed an elaborate process to update these costs on a regular basis as there are frequent changes in transportation costs such as for fuel rate hikes or a change in government tax rates.

Some cost categories are always notional: It is important to remember that it is not important to use actual costs for all types of cost categories. Typical examples of such cost categories are storage costs or costs of non-fulfillment of a customer order. One argument is it’s difficult to measure actual costs for such cost categories and more importantly, the actual costs may not give the desired result. For example, if a company does not want to store finished goods materials at its factories but wants to produce the materials closer to the customer’s delivery date, it can opt for a high storage cost at a factory for its finished goods. As an optimizer tries to minimize total cost, it ensures that materials are produced closest to the dispatch date from its factories.

Similarly, it’s not important to measure actual cost of non-fulfillment of a customer order – what is important is to have an idea of the relative cost impact of non-fulfillment for different customer types. For example the relative cost of non-fulfillment for one of the key account customers can be very high compared to the relative cost of non-fulfillment for a spot customer. In a degree of importance scale, if the first type of customer is 10 times more important than the second one, you can put a value of non-fulfillment as 10,000 for first type of customer and a value of 1,000 for the second type so there is no need to know the actual cost. The optimizer ensures that key account customers’ orders are fulfilled first and then spot customers are reviewed. The consumer goods company discussed earlier used notional costs for all these cost categories.

Actual costs may need modification to get the desired result: Sometimes actual costs can be modified to influence the decision taken by the optimizer. Once again I’ll go back to the consumer goods company example. One of the company’s old manufacturing units had very old machines with low productivity. The variable cost of manufacturing at this unit was very high. In the beginning the optimizer was not giving any production plan to this unit as items were being sourced from low cost units. Later on the company realized that this would result in virtual closure of the unit and potential industrial relations issues with the factory union.

The company management wanted a minimum of 15 days of production in the unit. For this the hourly costs of resources were modified and the values were adjusted downward from actual for the first 15 working days of a month. Thereafter, for the remaining days the hourly costs were kept at actual. This adjustment helped the optimizer to give at least 15 days of production plan at this unit. This is a classic example of how you can modify actual costs to influence the optimizer’s result. 

Some companies build a cost index for different product categories using queries in SAP NetWeaver Business Warehouse (SAP NetWeaver BW). There are companies that build sophisticated cost models by following the basic planning principles that the company’s planners used to follow while planning manually.

Here is an example: This company is one of the largest food companies in the world producing biscuits and chocolates. The company had used SNP Optimizer for planning production for its packers and makers. Scheduling makers and packers is a common optimization problem in the food industry. For biscuit units, a maker is the oven and the packers are the packaging units. For chocolate units, makers are the machines that make large chocolate slabs and packers are the packaging units. Sometimes makers are also defined as the primary manufacturing division (PMD) and packers as secondary manufacturing divisions (SMD).

Planning becomes a challenge as one of these (either packer or maker) can be a bottleneck. For example, oven capacity is a bottleneck for this food company in certain manufacturing units. In some units, a particular product might need a special attachment to the machine. As this attachment could be used on only one machine, the other machine used to become idle. Therefore, the product could be produced in only one machine, making capacity a bottleneck.

The company first identified all such bottleneck resources and the scenarios. Next it started building a cost model following the logic used by its planners while planning manually. For example the planners in its chocolate manufacturing units used to plan first for its promotional chocolates as those were the products with the highest priority. Next they used to plan for white chocolates for which they had a few large institutional customers. Other chocolates were planned for last.

The company used similar logic while building its cost model with cost factors having weight in line with the planners’ priority sequence. It took time to build this model because the company had to write SAP NetWeaver BW queries to bring data from the SAP ERP Central Component (SAP ECC) system and do the required calculations. However, the result from the optimizer was acceptable to the planners as it was in line with their expectations.

Note that costs are highly interrelated. Changing one cost element on its own can lead to completely different planning results. This big danger is often not understood if you change only one of the cost figures. For example, if you reduce the storage cost and keep all the other costs the same, you may end up with an inventory pile-up much before the demand bucket requirement.

Tips and Tricks in Modeling

Next we discuss a set of tips and tricks that can be useful in modeling certain types of problems in an optimizer. Some of these modeling tips and workarounds may save costly development efforts through data model design changes. Below are three such examples:

1. Modeling the optimal sequence: Sometimes production costs require orders to be produced in a particular sequence. You can model that process using SAP APO optimizers by specialized modeling techniques.

Here is a case study from a steel manufacturing unit that used APO SNP Optimizer for modeling a step-down matrix (combination of rolling thickness and tons produced) for its thin slab caster unit.  

It used the optimizer for generating a weekly production plan (balance-to-produce plan defined by the total order quantity minus the produced stock for that order). For example, in a make-to-order scenario a customer may order 1,000 tons of steel coils. Rolling is the mechanism of producing a coil from a slab of steel, converting a thick piece of steel to a thin piece. The company may have already produced 100 tons for the customer. The remaining order quantity is the balance to roll (i.e., 1000-100 = 900).

The plan was based on the demand (forecast + orders) and the production limitation of the thin slab caster. Thin slab caster equipment in a steel manufacturing unit is able to cast thin slabs from molten steel that can then be immediately rolled in a tandem mill to form a coil.

The first challenge was to read the make-to-order (MTO) orders in the planning book, which was easily solved by customizing the planning book with new key figures and macros. This can be done by adding a time series key figure in the SNP planning book, reading the MTO orders into the times series key figure, and then copying the demand date into the corrected demand key figure that the optimizer considers as input.

The second major challenge was to model the production limitation of the thin slab caster and tandem mill. This limitation can be best visualized as a step-down matrix (i.e., the machine can roll 1,000-ton lots of slab to form coil. However, it can only roll for specific combinations of product mix. For example, it can roll 4 mm thin coil right away but cannot roll 0.8 mm thin coil. It first needs to roll 2 mm for 60 tons, then 1 mm for 60 tons, and so on. Thus this machine needs to be fed with a mix of orders that meets these criteria (i.e., the criteria of step down – first 2 mm, then 1 mm, then 0.8 mm). At the same time the waste is minimal (i.e., it does not roll coils without an order). This problem was modeled in an SNP Optimizer with multiple output PPM and modeling costs in a way that it uses the source of supply that satisfies the maximum demand.

The logic of this modeling is shown in Figure 1. The tandem mill has a lot size of 1,000 tons. It produces 1,000 tons no matter what the product mix is. P1, P2, P3, and P4 are the different products that can be produced by this mill (for example, coils of 2 mm, 1.5 mm, 1 mm, and 0.8 mm thickness). In this case PPMs were modeled as multiple output PPMs. That means it can produce only P1 as an output, or P1+P2 as an output, or P1+P2+P3 as an output, or all four as an output.

SNP Optimizer had an option of selecting among these four options. In this case, the storage costs maintained in the product master for this individual material were kept very high. Because SNP Optimizer always tries to reduce total cost, it was choosing the PPM (i.e., the product mix) that satisfied the maximum forecast mix requirements (producing P1+P2+P3+P4 instead of P1+P2+P3 reduces the overall cost).

Figure 1

Modeling the step-down matrix in SNP Optimizer

2. Modeling fixed pegging relationships: Some companies have the requirement to have a fixed pegging relationship between demand and supply elements in case there are multiple alternate uses for the same finished product. This is a common requirement across the mill product industry. For example, in the paper industry the same pulp (semi-finished product) can be converted to different types of papers (finished product) depending on the finishing line operations. For the metal industry, the same billet (semi-finished) can be converted to different finished products such as sheet or coil of different dimensions (finished product). Companies are interested in knowing how much of the production for a semi-finished product is planned for which finishing machine.

Let’s check out how a large metal company solved this problem by intelligent modeling in SNP Optimizer. The company was interested in knowing how much of its slab production (semi-finished goods) would be assigned to its different finishing lines (e.g., lines producing coils or sheets). It wanted to know in advance the quantity of slabs the coil manufacturing unit and the sheet manufacturing unit were getting to convert.

The approach shown in Figure 2 was taken to model the problem using SNP Optimizer. Here M0 is the upstream machine producing the semi-finished product (i.e., slabs) and M1 and M2 are two downstream machines producing finished products (i.e., one producing coil and another producing coil and then sheet). A1 is the semi-finished product (i.e., slab) and P1 is the finished products (i.e., coil or coil that is converted to sheet). The modeling was done in such a way that multiple intermediate products were defined for the same product A1 by the number of downstream alternate resources or routes.

For the same semi-finished product A1, there were two different intermediate products M1A1 and M2A1 depending on alternate finishing line M1 and M2 and two corresponding PPMs – PPM1 and PPM2. Thus in the supply plan the company was able to identify the downstream machine (M1 or M2) for each order on machine M0.

Figure 2

Modeling fixed pegging relationships in SNP

3. Modeling outbound quota relationships: SNP Optimizer does not consider the outbound quota relationship as this is a heuristics tool and using it would violate the optimization approach. However, you can model this in a way that splits the demand as per outbound quota and designs the supply sources as per the split demand.

Here is an example of how a company achieved this by modeling: It wanted to consider the outbound quota within the plant for the same operation by loading one machine with 70 percent of the incoming load and keeping the remaining 30 percent variable. In this case the company used the approach of splitting demand as per outbound quota and designing in the supply sources in accordance with the split demand.

This approach can be explained with a simple example as depicted in Figure 3. Total demand is 1,000. This is split on two finished products with P1 as 700 and P23 as 300. Now the supply sources PPM1, PPM2, and PPM3 are designed to fulfill this demand from the same semi-finished product A1. The optimizer would thus consider satisfying 70 percent of the total demand from machine M1 and the remaining 30 percent of the demand from machine M2 or M3.

If there is a delay across buckets in terms of demand satisfaction from a previous or future bucket, then there is a chance that within a particular bucket the quota may not be respected. However, for the complete time horizon this quota would be respected.

Figure 3

Modeling for outbound quota

Phase 4: Final Preparation

This is the phase before final go-live. In this phase a project having an SAP APO optimizer in scope would need simulation with full data volume. That is how it differs from other SAP projects. Multiple optimizer runs with a full data load are done until the business user confirms that the result from the optimizer is satisfactory. In this section we mainly discuss three things that help the planner get feasible results from the optimizer:

1. Checking settings before running the optimizer

2. Understanding the optimizer results

3. Tweaking parameters (needed at times) to get the desired results

Checking Settings Before Running the Optimizer

Table 1 shows key settings for the SNP Optimizer and the elements needed to make that setting. These settings govern optimizer results. It’s important during the final preparation stage to have a quick check on these settings.

Table 1

Key setting for the SNP Optimizer

Understanding the Optimizer Results

Optimizer logs and explanation results offer tools by which you can understand the optimizer results. There are logs available that provide explanations for demand fulfillment or non-fulfillment, resource utilization, and service levels.

The goal of the planner should be to analyze exceptions and conduct what-if analysis by changing only some parameters as per the business scenario. In the optimizer explanation log you can check the messages to find out which constraint is leading to dropping of demand (defined by 0 percent missing quantity) and read the recommendations for elevating this constraint if required. You can also check order proposals to understand what steps to take to fulfill missing demand quantities.

In the case of linear optimization, the optimizer does not consider any lot size (for example, production or transport lot size). In the case of discrete optimization, the optimizer considers lot sizes so the result is always in multiple lots. An example of a production lot size is a steel coil that weighs 20 tons. This means that for a customer requirement of 100 tons you need planned orders of 20 tons each at the resource. Note that discrete optimization leads to an increase in optimization run time. Thus generally you consider lot size constraints only for few initial buckets.

Here are some guidelines for interpreting optimizer results

1. Period-wise demand supply analysis. Highlight any bucket that does not seem to be fulfilled and analyze any reason for the same. An example is shown in Table 2.

Table 2

Period-wise demand supply analysis

2. Product group demand supply analysis. Similar to what you see in Table 2 for buckets, you can also highlight any product group that is not being fulfilled.
3. Analysis of key products and key locations or customer group demand and fulfillment to understand if prioritization is as per plan
4. Resource capacity and consumption bucket-wise analysis. Understand under- or over-utilization or resources (Table 3).

Table 3

Resource capacity and consumption analysis

5. Understand unfulfilled demands for each bucket. Check for unfulfilled demand and correlate it with the resource capacity consumption.
6. Stock transfers and lead times for products can be analyzed
7. Procurement plan can be analyzed
8. Safety stock fulfillment can be analyzed

Tweaking Parameters to Get the Desired Results

Table 4 shows examples of a set of requirements that the planners may look for in the optimizer results and a list of optimizer settings that you can tweak or modify.

Table 4

Possible modifications to the APO optimizer

You can encounter hurdles during this stage, as shown by these two examples. 

At one client when we started loading the data into the SNP Optimizer we realized that some stock elements were not being read. After analysis we found that certain finished goods were account assigned to a customer stock segment. Thus we had to remove the account assignment during the core interface (CIF) transfer to enable stock to be read into the SNP Optimizer planning book.

At another client we realized that global Available-to-Promise (global ATP) was planned for an availability check and it was not possible to stop the CIF for four hours to complete the optimization run. Thus we had to include additional steps in our planning to copy the data from the active version to a simulation version and then run the optimizer in simulation version. Later we copied the results back to the active version.

Phase 5: Go-Live

Finally the project is ready for go-live. There are a few things you can add in the final go-live checklist if the project has SAP APO in scope:

• Ensure that CIF is stopped during optimizer run. Include this as a step in the final background job schedule.
• Ensure there is a process for measuring the total SAP APO planning cycle time to see how much time an individual job actually takes. In some cases the project team discovers during go-live that the actual run time with full volume data for the entire planning cycle is quite different from what was planned. This is more common when the project team runs the complete end-to-end SAP APO background job schedule (with manual interventions in between as required by the planner) for the first time during the actual go-live. Before that the team had run only part of the cycle, even during integration testing. As a best practice this is never recommended.
• Ensure you have a process for measuring KPIs for the optimizer run
• Ensure that there is a single owner for all cost data for the optimizer

The period just after the project goes live is critical. There can be number of common issues:

• Optimizer is not giving desired result for certain products (the results were acceptable earlier during simulation)
• Optimizer is taking more time for the run compared to what was planned before
• The results the optimizer is giving in certain cases are not understandable. For example, why there is an unfulfilled demand in a certain week even though there is available production capacity in that week.

The role of the core team becomes critical at this stage in terms of helping business users interpret the result and sort out issues. The core team should provide periodic refresher training for modeling concepts that were adopted during the project.

Rajesh Ray

Rajesh Ray currently leads the SAP SCM product area at IBM Global Business Services. He has worked with SAP SE and SAP India prior to joining IBM. He is the author of two books on ERP and retail supply chain published by McGraw-Hill, and has contributed more than 52 articles in 16 international journals. Rajesh is a frequent speaker at different SCM forums and is an honorary member of the CII Logistics Council, APICS India chapter and the SCOR Society. 

You may contact the author at rajesray@in.ibm.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.

Abhishek Kaul

Abhishek Kaul is part of the global center of competence at IBM Global Business Services. He has led major process and technology innovation projects in leading companies. He has extensive experience in designing and implementing planning solutions for the manufacturing industry.

You may contact the author at abhishek.kaul@in.ibm.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.