Testing Deployment

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 here:

http://www.scmfocus.com/sapplanning/2008/10/11/snp-deployment-and-fair-share/

Deployment Complexity

Deployment can be considered somewhat of an afterthought to the actual planning run. However, that is actually not a correct way of thinking about it. Deployment is the planning that essentially 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 an after thought.

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 check horizons.

However, in terms of 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, this is because the deployment optimizer uses the same screens as the optimizer configuration. You can see this here.

http://www.scmfocus.com/sapplanning/2009/07/25/snp-optimizer/

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

We name the profile

General Constraints Tab

Back to the configuration of the Deployment Optimizer Profile. In this tab, constraints can be setup, that is which constraints the optimizer should respect, in addition to whether it should respect lot sizes. One of the most important 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 simply 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 just provides more constraints, which are respected if the “Discrete Optimization” radio button is selected. Below this costs can be incorporated as well for both transport and for the procurementquantity.

Shelf Life

An interesting feature here is that the SNP optimizer as the strongest recognition of the shelf life parameter, while 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 end up losing out on shelf life functionality. However, by running the deployment optimizer with the SNP heuristics or CTM, one can get the benefit of 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 then the solution is not optimal. I do not generally this this as Regard as a Hard Constraint, but instead set it to regards as a forecast.

These are the options available for the Fixed Order Handling. You can select the option below, which determine how the orders should be considered (either part of the demand forecast, or the customer demand) and if the orders should be considered 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 fair share, however it does.

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

http://www.scmfocus.com/supplyplanning/2012/01/03/the-problem-with-cost-optimization/

In fact 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 properly. This is not something which 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 be repeatedly rerun, and multiple variants can be created.

Problematic Outcomes for The SNP Deployment Optimizer

Interestingly, costs control the flow of product throughout the supply network when the cost optimizer is used. However, SNP does not have a “tie breaking” logic which can essentially 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 there is parent location A, which deploys to child locations B and C. If all other costs are equal, and the cost of non fulfillment 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 non delivery 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 location) 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.

This article is continuing here…..

http://www.scmfocus.com/supplyplanning/2012/01/03/the-problem-with-cost-optimization/