Tag Archives: Deployment Optimizer

Attempting Fair Share Distribution with the Cost Optimizer

Posted on by

Background

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 product 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.

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

All of these costs can be found in 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 the but these can be used to multiply the cost categories by.

Here is the cost in the transportation lane. If the cost here was entered as 5 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. Its not very useful to think of this in terms of dollars, because it is not actually dollars. I find it more instructive to think of it as points. The points are all relative. If all the costs / points are increased by a factor of 5 or 10, the same result comes out of the optimizer.

The most commonly populated costs that I have seen 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

While SNP has in-built fair share 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 illogical things. From what I could tell, the patch seemed to make the optimizer ignore the case quantity or rounding values. 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. So any deployment optimizer run that produced below case quantity results simply had to be rounded manually after the fact.

Something else I noticed was that there did not seem to be any logic to how the fair share was allocated. There was no proportionality. So if a 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 with Costs

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

Firstly, this is a request, but there is no documentation that states that the deployment optimizer can do this. There is a setting under the Demand at Source Location that is supposed to be able to control for 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 as to where this should actually 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. In my consulting experience, I have never seen this work, but on the other hand I have also no been asked to configure this requirement.

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

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

Conclusion

The optimizer has numbers 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. It seems 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 are not apparent to me.

I am curious if anyone has any comments on this. The behavior I am seeing in the deployment optimizer is concerning as I can’t see it matching business requirements. I recall hearing from an IBM consultant several years ago how wonderfly nuanced and capable the optimizer was once it is “tuned.” I am not seeing this. However for years my veiwpoint has been obscured by the fact that the optimziers I have been working with have been misconfigured. I describe the problem with cost setting in this post.

http://www.scmfocus.com/inventoryoptimizationmultiechelon/2011/05/how-costs-are-really-set-in-cost-optimization-implementations/

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

 

Difference Between the SNP Deployment Optimizer and Inventory Balancing

Posted on by


What Are the Differences?

We were recently asked what are the differences between the deployment optimizer in SNP and inventory balancing in SPP. Before going into to much detail its important to read up on each of these areas of SCM if you are not familiar with them.

Inventory Balancing

http://www.scmfocus.com/sapplanning/2009/04/23/inventory-balancing-in-spp/

Deployment Optimizer

http://www.scmfocus.com/sapplanning/2009/07/30/deployment-explained/

Transportation Lanes

Something which is critical to both is transportation lanes, and their maintenance, for which we have a post on this topic in terms of mass maintenance here.

http://www.scmfocus.com/sapplanning/2008/09/14/snp-transportation-lane-and-transportation-resource-setup/

This makes the deployment optimizer and inventory balancing usable, because they can setup a large number of transportation lanes quickly with mass maintenance. However, they must be changed and adjusted as locations are added or deleted.

Differences

  • SPP Inventory Balancing has more fields that control the redistribution of materials. For instance, the warranty start date and the recall start date as well as the production end date. These are critical for service parts, but much less so for finished goods.
  • SPP inventory balancing can be run from the Planning Service Manager. This is an easy way to schedule services in SPP (but also in other SCM modules).
  • Through the use of the inventory area, SPP can treat multiple locations as a single location.
  • SPP has more ability to set warehouse space savings per location.
  • The deployment optimizer takes into account (capacities such as handling, transportation, storage, capacity) as well a prioritization related to costs and prioritization.
  • Deployment works off of

Open Question

One open question we have is how powerful is inventory balancing compared to the deployment optimizer? Aside from more fields is it more powerful in terms of its ability to see many different locations?


SNP Deployment Optimizer Profile Configuration

Posted on by

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.


SNP ProfilesWe 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.

Deployment Optimizer 0Discrete 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.

Deployment Optimizer 2Model 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.

Deployment Optimizer 3Integration 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.

Deployment Optimizer 5These 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.

Deployment Optimizer InsertAutomatic Cost Generation Tab

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

Deployment Optimizer 6Extend Settings Tab

This determines which consistency checks should be run.

Deployment Optimizer 7Deployment 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.

Deployment Optimizer 8

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.

OptimizerThese 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/

SNP Deployment Explained

Posted on by

A Term Often Used, But Not Often Defined

I have been working in supply chain for some time, and I tended to hear rather indirect explanations for deployment. I finally found several and wanted to locate them in one place for future reference. One is the presentation listed below:

http://www.sap.com/spain/company/events/2008gestioncadenalogistica/pdf/6Killer%20Applications%20Day%20SCM%202008_SNP.pdf

Deployment determines the best short-term solution to allocate available supply to meet demand and to replenish stocking locations. Deployment confirms or changes the supply network plan depending and creates an optimized plan for stock transfers. The rules-based Deployment Heuristic distributes the products according to quotations and priorities. The Deployment Optimizer distributes the products according to cost while also considering specific rules.

Another is in the book Supply Chain Management with SAP APO:.

If the supply chain behaves exactly as planned – i.e. neither changes in the demand nor unpredicted deviations of the supply happen – deployment is not necessary. Since we are living in an imperfect world, both demand and supply will usually differ from the planned quantities when it comes to execution. If the demand exceeds the supply, it has to it has to be decided which demands – in case of the supply chain network: which locations – will be covered and to what extent. This is exactly the scope of deployment. – Supply Chain Management with SAP APO

SNP Deployment

SNP deployment is inherently designed to distribute from one level of the echelon to the next, either with a push or pull method. SNP creates a quantity called “Available to Deploy,” which is much like “Available to Promise.” That is the first step to running the deployment. The deployment also has three horizons that it works with. These are:

  1. The deployment horizon: The number of days over today over which you want to take process stock transfers.
  2. The push horizon: The number of days over today over which you want to take into account receipts
  3. The pull horizon: The number of days over today you want to take into account demands.

The information that the deployment heuristic uses is shown in the graphic below:

These are set in the SNP2 tab, notice below.

Deployment Product Location 2

For those attempting to compare SNP deployment to the inventory rebalancing in SPP, the question is can SNP deployment be configured to act as a redeployment engine. Some more detail can be found by evaluating more from SNP’s training material.

Deployment determines which DC or VMI customer distribution demands can be covered by the present supply. If the available quantities are not sufficient to meet the demand, or if they exceed the demand, deployment makes adjustments to the stock transfers created by the SNP run.

______________________________________

Heuristic versus Optimization Deployment in SNP

The heuristic uses rules to deploy inventory. The optimizer uses costs. The setup of the deployment optimizer is extremely similar to the setup of the normal initial planning SNP optimizer. Of the two methods of deployment (optimization vs. heuristics), the heuristic is far more commonly used than the optimizer.

  • Heuristic = from one plant product by product
  • Optimization = focus on network product by product (cost based optimization)

The Difference With Respect to STOs

To highlight now different the deployment optimizer is from the deployment heuristic approach, the deployment optimizer does not require SNP planned stock transfers. The deployment optimizer calculates the replenishment plan for a product in all locations in the network. In contrast to the SNP optimizer, the production and procurement quantities remain unchanged; only the stock transfers change. Also, as opposed to a normal SNP run, real time deployment will not take transportation lanes or quota arrangements between target locations and locations other than the given source location into account. Stock transfers are thus only created between deployment source locations and target locations. The constraints for the optimizer include:

  1. Product Priority
  2. Storage Capacity
  3. Transportation Capacity
  4. Lot Sizes
  5. Safety Stock

(This requires more analysis).

Release Notes

Deployment Capability

I was recently asked what the deployment capability in SCM actually was. One confusing thing in this area is that SPP, which as picked up a large amount of functionality in redeployment, is actually listed as deployment in the SAP release notes, which is incorrect. However, here is a list of deployment functionality enhancements as of SAP APO 4.1: 4.1 SNP Deployment

  • System ensures that the category group has been specified in the location product.
  • Alert enhancement
  • More flexibility with profile management
  • Enhanced procedures for speeding up the processing
  • Forecast horizon improvements.
  • Improvement in the resulting stock transfers checking with the validity dates of the transportation lane and means of transport.
  • Use of transportation lot size has been improved

5.0 SPP Deployment SNP Deployment

  • Parallel Processing Profiles (enhanced performance)
  • Automatic cost generation for SNP and deployment optimizer – As of 5.0 the cost model has been enhanced and can take into account the maximization of service level, demand and product priorities, procurement priorities.
  • Consideration of demand at the source location – as of 5.0 the deployment heuristic can specify that the system carry out a fair share distribution of the ATD quantity to cover not only the demand at the source location, but also the distribution demand at the destination location. Two new fields in the master data of the source location product (SNP2 tab page) specifies whether the system should consider customer demand or planned independent demand.
  • New planning book 9ADRP_FSS contains the key figure Deployment Reservation Quantity, which saves the quantity it reserves for the demand at the source location.
  • As of 5.0 several source locations can be selected on the screen for executing the deployment heuristic. Supply Network Planning -> Deployment -> Deployment Heuristic -> Consideration of Demands in the Source Location.

5.1 SPP Deployment SNC Deployment SNP enhancement in deployment, but only in regards to considering product interchangeability in the deployment. 7.0 SPP Deployment – Inventory Rebalancing PP/DS Deployment – Similar to SNP deployment

  • The PP/DS deployment horizon allows you to define the number of days the system consider.
  • Heuristic can be called from the Product View
  • Can fit within the process chain
  • However, the PP/DS heuristics only allows pull distribution
  • Uses the planning book 9APPDS_DEP
  • /SAPAPO/HEU_PPDS_DEPLOYMENT algorithm and SAP_PP_024
  • Advanced Planning and Optimization -> Supply Chain Planning -> Production Planning and Detailed Scheduling (PP/DS) -> Deployment -> Maintain PP/DS Deployment Characteristics Profile.

Details on deployment can be found at these links.

SPP deployment — which should really be called redeployment, is covered here: