The Problem with SNP Optimizer Flow Control

Executive Summary

• The SNP optimizer has two types of methods of deployment. The deployment optimizer has major problems with the second method, which is called cost optimization.
• The deployment optimizer cannot fair sharing stock to locations.
• This topic is hidden by SAP and SAP consulting companies from customers.

Introduction to Optimization in APO

In its early years, SAP APO was sold on its ability to perform optimization. This is primarily because it was an industry-wide practice to market advanced planning software in this way. SAP APO, or SAP Advanced Planning & Optimization, had the term directly in its name.

The General Versus Specific Meaning of Optimization

Optimization has two general meanings. One is more of a business nature, which means to produce the best outcomes. The other has to do with operations research, from where the supply chain optimization originates. For this article, we’ll define optimization as the use of software tools and processes to ensure a supply chain’s optimal operation, including the optimal location of inventory within the supply chain and the minimizing of operating costs (including manufacturing costs, transportation costs, and distribution costs).

The Two Different Methods of Performing Deployment in SNP

There are two ways to run the deployment in SNP:

1. The Deployment Heuristic
2. The Deployment Optimizer

These two methods provide two very different sets of functionality. This article will focus on the optimizer. Details on the deployment heuristic can be found in this article.

Deployment Complexity

Deployment can be considered somewhat of an afterthought to the actual planning run. However, that is not the correct way of thinking about it. Deployment is the planning that mainly takes action to correct either an overage or underage between two locations. There are two ways to run Deployment in SNP; Heuristics and Optimization. In this post, we will only be concerned with optimization. SNP has a very significant number of settings for the deployment, and just this fact means that deployment is far more an afterthought.

Methods of Running the Optimizer

The deployment optimizer is quite flexible. This includes how safety stock deviations are treated (absolutely or relatively). Whether discreet or linear optimization is used, whether cost-based or strict prioritization should be used, whether existing orders should be deleted, global push, pull, and SNP checks horizons.

However, regarding costs, the optimizer can have relative costs setup for:

• Costs of transporting stock
• Costs for storage stock
• Costs for handling stock
• Costs for violating safety stock
• Costs for not delivering

Duplication of Optimizer Profile

The following profile will seem extremely familiar because the deployment optimizer uses the same screens as the optimizer configuration. You can see this here.

This is accessible from Profiles. This allows us to apply different Profiles to different Product Location combinations.

We name the profile as well.

General Constraints Tab

Back to the configuration of the Deployment Optimizer Profile. In this tab, constraints can be set up, that is, which constraints the optimizer should respect, in addition to whether it should respect lot sizes. One of the most critical setups is whether the optimization should perform linear or discrete optimization. Linear optimization is faster, but discrete optimization is more realistic. If we are not merely testing the system to get a general response, we will go with discrete optimization. Safety stock and shelf life can be incorporated or not incorporated in the optimization run.

Discrete Constraints Tab

This provides more constraints, which are respected if the “Discrete Optimization” radio button is selected. Below these costs can be incorporated as well for both transport and for the procurement quantity.

Shelf Life

An interesting feature here is that the SNP optimizer has the strongest recognition of the shelf life parameter. Simultaneously, CTM has only recently added consideration for shelf life, and its degree of respect for this constraint is something we have not had time to research. Thus projects that use CTM and heuristics (which is the vast majority of SNP implementations) can lose out on shelf life functionality. However, by running the deployment optimizer with the SNP heuristics or CTM, one can benefit from optimization.

Model Parameters Tab

This tells the model whether to consider the average stock on hand or look for the stock at the end of the period. I typically do not change these settings or the Bucket Offset During Shipment.

Integration Tab

This tab deals with the duration of the horizon. It also allows you to change how the system views Distribution Demand. If it is set as a hard constraint, it must meet the distribution demand. If it can’t be, then the solution is not optimal. I do not know this as a Hard Constraint, but instead, set it regards as a forecast.

These are the options available for the Fixed Order Handling. You can select the option below, which determines how the orders should be considered (either part of the demand forecast or the customer demand) and if the orders should be regarded as a hard or semi-hard constraint. The lowest two options determine if any orders should be allowed to be deleted.

Automatic Cost Generation Tab

This is a highly abstract number of settings, which we will skip.

Extend Settings Tab

This determines which consistency checks should be run.

Deployment Parameters Tab

This determines if the shortage of supply should be handled by which method. This is important because it changes whether the deployment optimizer is based upon costs or based upon the demands and performs a fair share.

It is surprising to many people that the optimizer performs as a fair share. However, it does.

This tab supposedly provides the option to perform a fair share with the optimizer, which is very strange as it’s counter to how cost optimizers work. More on this topic can be read here:

A check at SDN.SAP.COM shows only a few entries on fair share for the cost optimizer. When I tested it, I did not find it to work, and SAP sells an add-in, which I have also tested and not found to work correctly. This is not something that companies should be using the SNP optimizer for.

Running the Optimizer

The optimizer can be run interactively in the planning book. However, it can also be run in the background.

These, of course, can be saved as variants so that they can repeatedly be rerun, and multiple variants can be created.

Problematic Outcomes for The SNP Deployment Optimizer

Interestingly, costs control the flow of products throughout the supply network when the cost optimizer is used. However, SNP does not have a “tie-breaking” logic, which can primarily share supply among different child locations.

There is no nuance here in this design. The problem with this is that costs are very binary. So there is parent location A, which deploys to child locations B and C. If all other costs are equal, and the cost of nonfulfillment is set as follows:

1. A = 50
2. B = 30
3. C = 25

The stock will be kept back at location A because this is the lowest-cost solution. However, the optimizer will keep all the demand and share none of it with B or C. If the optimizer nondelivery charge is changed so that C = 55, then C will simply get all of the stock. If all locations are set to the same cost, SNP seems to decide by random (although it always seems to send to the same site) which one of the locations will receive the stock and will again ship all of it to that location.

This lack of attention to detail and oversimplification of deployment functionality is frankly shocking.

Background of Fair Share in the SNP Optimizer

I always find it strange when I am asked about performing fair share distribution with the cost optimizer. This is because the optimizer is designed to move products through a supply network based upon costs. I always like to keep the other costs in the optimizer equal when analyzing any one particular cost. So in the scenario, I am discussing all costs are the same. This includes:

1. Production
2. Procurement
3. Prod Cap
4. Transport
5. Transport Cap
6. Storage
7. Storage Cap
8. Safety Stock
9. Handling Cap
10. Late Delivery
11. No Delivery (only this is changed in our discussion)
12. Rec. Bound
13. Quota Arrangement
14. Setup C.

Setting up Costs in the SNP Optimizer

While there are many costs listed here, not all of them necessarily need to be used to run the optimizer. The system will use those you populate and not attribute any costs to those you do not.

All of these costs can be found in SAP SNP: Profile of Cost Multipliers. These penalties are set in specific locations; for instance, the transportation cost is set at the transportation lane. However, the penalties can be increased in proportion to one another.

Therefore, the penalties can be kept the same, but these can be used to multiply the cost categories.

Here is the cost of the transportation lane. If the cost here was entered as five and the multiplier in the SNP Profile of Cost Multipliers were 2, then the cost incurred by moving a truck over this lane would be 10. It’s not very useful to think of this regarding dollars because it is not dollars. I find it more instructive to think of it as points.

The points are all relative. If a 5 or 10 increases all the costs/points, the same result comes out of the optimizer.

The most commonly populated optimizer costs that I have seen in the SAP optimizer are the following:

1. Production
2. Procurement
3. Transport
4. Storage
5. Safety Stock
6. No Delivery (only this is changed in our discussion)

Fair Share Distribution / Deployment

While SAP SNP has an in-built fair share distribution/deployment capability, supposedly, it does not work very well. The concept of fair share is the opposite of cost optimization. Because of these limiting factors, SNP offers a fair share patch, which clients can buy. I analyzed this patch and found a lot of wrong things. The patch seemed to make the optimizer ignore the case quantity or rounding values from what I could tell.

Therefore if an optimizer deployment run looked like the following when the patch was included:

1. Location A = 5
2. Location B = 15
3. Location C = 100
4. Location D = 10
5. Location E = 75

and the minimum case size or other rounding value was 40, the deployment run without the fair share patch would look like the following:

1. Location A = 40
2. Location B = 40
3. Location C = 100
4. Location D = 40
5. Location E = None

What happened was that when the rounding value was implemented, the deployment optimizer was able to deploy to fewer locations because it has to satisfy rounding values. However, the rounding values were, in fact, necessary. Any deployment optimizer run produced below case quantity results simply had to be rounded manually after the fact.

I noticed that there did not seem to be any logic to how the fair share was allocated. There was no proportionality. So if demand at location A was 20 and the demand at location B was 20, the deployment optimizer fair share patch might send 5 to A and 15 to B. In fact, all the fair share patch seemed to do was violate the case quantity. It was essentially no value add.

Fair Share Distribution / Deployment with Costs

One request made of me was to see if the deployment optimizer could be made to fair share between parent and child locations by using costs. So if A supplies to B and C and they all had demands of 40 (which would appear to A as distribution demands from B and C), could the deployment optimizer be made to allocate 120 units equally among the three.

Firstly, this is a request, but no documentation states that the deployment optimizer can do this. There is a setting under the Demand at Source Location that is supposed to control this. This is the “Demand at Source Location,” so it can be made to consider either forecasts or sales orders at the parent location. There was some confusion about where this should be set (at the parent or the child), but I tested it at both, and neither worked.

I communicated with SAP on this, and the comments that came back from development contracted this functionality. I have never seen this work in my consulting experience, but on the other hand, I have also no been asked to configure this requirement.

Getting back to obtaining a fair share of costs, one might think that setting the costs of non-delivery is the same at all locations in the supply network. However, when I tested it, it sent all material to one site and divided none of it. This brings up a general point about the binary nature of how the material is flow controlled in cost optimization that is a real concern. It surprises me that it is not brought up more frequently as a major design problem. It has given me some real concern about how well cost optimizers match actual term requirements and are explained more in this article.

Problematic Outcomes for The SNP Deployment Optimizer

The optimizer has several problems with fair sharing. SAP’s fair share components for the deployment optimizer do not work. Secondly, attempting to emulate a fair share by setting the non-delivery penalty costs the same at the locations where the fair share is desired did not work. This is because the SNP optimizer does not have any tie-breaking logic for when costs are identical, and how it selects which location to use is not apparent to me.

I am curious if anyone has any comments on this. I see the behavior in the deployment optimizer as I can’t see it matching business requirements. I recall hearing from an IBM consultant several years ago how wonderfully nuanced and capable the optimizer was once it is “tuned.” I do not see this. However, for years my viewpoint has been obscured because the optimizers I have been working with have been misconfigured. I describe the problem with cost setting in this article.

However, even the simplest location to location movement within one echelon seems to be a problem. It is simply not desirable to send all stock to one site when multiple locations have a demand. It is also not useful to source all stock from one place until the stock is depleted before shifting to a secondary location. Anyone who has worked in the supply chain for some amount of time should know this, so I am a bit perplexed about why there is no more conversation on this topic.

The Issue with Cost Flow Control

Costs control the flow of products throughout the supply network when the cost optimizer is used. Some consultants will bring up the Fair Share selection on the SNP cost optimizer profile. However, that does not appear to work. This is described in this article.

SAP sells a fair share patch, which is added to APO. The results that I have tested that come from this fair share patch do not make any sense. That is in either how the distribution compared to demand or in how it ignores the rounding value. For this reason, I reject the common consultant claim that the SNP optimizer has fair share capability. I have concluded that the only way to control the deployment of the cost optimizer is with costs.

Many companies do not realize what I will explain below before they go down using the deployment optimizer.

How the Deployment Optimizer Works

You can use several costs to control the deployment optimizer in this respect, but I have used the cost of non-delivery. SNP lacks a “tie-breaking” logic, which can share supply among different child locations. I will use an example to explain how this works. In the example, there is parent location A. A deploys to child locations B and C. If all other costs are equal, and I have set them to be equal in the testing, the cost of nonfulfillment is set as follows:

NonDelivery Penalties for One Product at Three Locations

Test Case 1

1. Location A = 50
2. Location B = 30
3. Location C = 25

In this case, as expected, the stock will be kept back at location A because this is the lowest-cost solution. That is, it reduces the cost of the objective function.

However, the binary nature of the cost optimizer’s decision-making is evident here when the results of this test are that the optimizer will keep all the demand and share none of it with B or C.

Test Case 2

• Suppose the optimizer nondelivery penalties are changed so that C = 55, C will simply get all of the stock. If all locations are set to the same cost, SNP seems to decide at random.
• But it always seems to send to the same location. This is one of the areas that will receive the stock and ship it to that location.

The problem is very few supply chains work like this, so what I have described will not meet the business requirement.

The only time it works properly is sufficient demand, and the deployment is set up as a pull. The inbound or network optimizer works in the same problematic way. If locations E and F are supplied by location D, and the costs are as follows:

Test Case 3

1. Location D = 50
2. Location E = 30
3. Location F = 25

The higher unfulfilled demand costs at D will create a pull strategy out to E and F.

Therefore stock will be kept at D until demand is required at E or F. However, if both E and F require stock simultaneously, the stock will always go to E. This is because it has the higher unfulfilled demand penalty. All of it will go to E until E’s demand is entirely satisfied before F is supplied. Who would want that setup?

Again, the location which is being sent product will 100% of the time chose the lowest cost source location until there is no more capacity and then switch to the next highest and the next highest, as long as it can meet the dates. How realistic is this? I would say not very.

Test Case 4

If the change the scenario, the following holds:

1. Location D =15
2. Location E = 30
3. Location F = 25

Because D is now lower, the optimizer will want to keep the supply there. This is so this is now a pull deployment strategy. Again if both E and F have demands simultaneously, E will get all of the supply.

When there is sufficient stock, the system works fine. But in that case, costs have nothing to do with the movement, and it is strictly based on the demand. A much simpler way to run by demand is to use MRP and DRP. A primary benefit of optimization is that it processes sub-networks, as this article describes.

What Most Companies Want From Deployment

Most would prefer to apportion stock about the demands, more of a fair share situation. The sophisticated optimization functionality in SNP is not particularly useful because of deployment. It is so binary.

People are usually wowed by cost optimization because it’s so complicated.

However, several of the assumptions taken by the SNP optimizer are problematic for implementation. The flow control is just too “twitchy.” It allocates everything to one location while leaving other locations barren. Sure, costs may have been minimized, but to what end? Costs are merely a control device. They are not set to match real costs.

This is so the company does not have to develop necessarily accurate costs, as described in this article.

What Cost Optimization Then Means

So costs in any real sense were not minimized. Fake costs that have no relationship to real costs were minimized. And so? This would be like saying you had lost 20 pounds, which you had earlier imagined around your waist. Again, not helpful or beneficial to anyone. A better system would have stock moving in the proportions of demand. And SNP has this as fair share functionality in the optimizer. It also as has it in the SNP heuristic. However, in testing, it did not at all seem to work. Companies that want to use fair share should instead use the deployment heuristic.

Going Down the Path of SNP Optimization

I find many companies that go down the path of fully implementing the SNP deployment optimizer. But they do this without actually having it meet any of the requirements for a fair share. The supposed fair share patch has been used in companies to think they have a way to get the deployment optimizer to do what they want.

The Problem and the Larger Context

The tactical flow of material as controlled by non-delivery penalty costs is a serious disadvantage to cost optimization. It is surprising that I had not read an article about this topic and had to come to this conclusion on my own.

In the past, I have heard people make excuses for the SNP cost optimizer not giving the desired output. But this is a serious design issue that is getting past companies. For years those on the practical side of the fence have questioned the reasons for the lack of successful cost optimization projects.  Not all optimizers are created equal. Cost optimization is complex. Without the necessary functionality, it is hard to count a problem implementation against cost optimization.

Linear Versus Discrete Optimization

Optimization works best in perfectly “linear” situations so that inputs can be increased or decreased continuously. An example of a linear input is an order quantity. In a perfectly linear optimization, any order quantity from zero to infinity can be placed and fulfilled. But in reality, supply chains are not perfectly linear problems.

For example, the lot size is a discrete value that limits the flexibility of the order quantity. One item may be ordered in units of 50, but if 135 units are desired, and the current inventory is less than 35, then 150 must be ordered to meet this demand. SAP SCM has some techniques, such as lot size, that alter the problem being solved from perfectly linear to discrete or known as a step function. This is very important for making the resulting recommendation realistic.

The Reduced Focus on Optimization

Although optimization drove development in SAP SCM at one time, it no longer does. The evidence for this is that optimization is an option in three of the older applications (Supply Network Planning [SNP], Production Planning and Detailed Scheduling [PP/DS], and SAP Transportation Management [SAP TM], formerly known as Transportation Planning and Vehicle Scheduling [TP/VS]). But isn’t an option in any of the newer applications (SAP Extended Warehouse Management [SAP EWM], SAP Supply Network Collaboration [SAP SNC], SAP Event Management, SAP Service Parts Planning [SAP SPP], and SAP Forecasting and Replenishment). Also, the core optimization functionality in SAP SCM has been stabilized for some time. This shift is partly because optimization didn’t meet its originally envisioned potential. So, the newer applications in SAP SCM have tended to downplay optimization in favor of other functionality.

Conclusion

While it may sound like an interesting concept, supply networks are not merely sequences of locations that have cost-associated activities. That is, storage costs, non-delivery costs, etc. that are modeled in an optimizer. These are not costs that must be minimized.

Optimization may be working well when there is sufficient stock, but then again, so will any deployment system based on dates using the SNP heuristic. I have not tested this on other vendor systems. I will be sending this article to several vendors to gain insights into how their cost optimizers work in this respect.