Executive Summary

• A heuristic or optimization can perform stock deployment in SNP and the with the heuristic.  Deployment can be set as either push or pull.
• SNP has issues with fair share distribution, and the overall deployment optimizer can’t be effectively used in production.
• There are essential specific areas that we will discuss setting up for deployment, including Means of Transport, Virtual Locations, and a customized deployment in SNP.

Introduction: A Term Often Used, But Not Often Defined

Considering how often the term deployment is used, it is odd how infrequently it is defined. You will learn the definition of deployment and its relation to other supply planning threads and how deployment is used in SNP.

Notice of Lack of Financial Bias: We have no financial ties to SAP or any other entity mentioned in this article.

• This is published by a research entity, not some lowbrow entity that is part of the SAP ecosystem. 
• Second, no one paid for this article to be written, and it is not pretending to inform you while being rigged to sell you software or consulting services. Unlike nearly every other article you will find from Google on this topic, it has had no input from any company's marketing or sales department. As you are reading this article, consider how rare this is. The vast majority of information on the Internet on SAP is provided by SAP, which is filled with false claims and sleazy consulting companies and SAP consultants who will tell any lie for personal benefit. Furthermore, SAP pays off all IT analysts -- who have the same concern for accuracy as SAP. Not one of these entities will disclose their pro-SAP financial bias to their readers. 

What is Deployment?

• Deployment is a supply planning run that moves the material from the plants and stock locations to the final customer.
• DRP performs deployment in some systems and other systems by a heuristic or by optimization.
• 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.

In SNP, 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 Definition

SNP deployment is inherently designed to distribute from one echelon level 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.

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 deployment optimizer setup is exceptionally similar to the setup of the regular initial planning SNP optimizer. Of the two deployment methods (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 Deployment Heuristic

The deployment heuristic in SNP is one of the two ways that deployment is performed in SNP. Another method is the deployment optimizer, which is much less frequently used.

“Push rules are used to calculate deployment in SNP if the ATD (Available to Deploy) quantity covers the demand.” – SAP Help

This is where the distribution of deployment is determined in the SNP2 tab in the Product Location Master in APO. All settings can be saved as a Deployment Profile and then applied to any product location combination.

Setting Push or Pull for Deployment

The controls are described by SAP as follows.

• Pull: Materials are distributed on the due dates specified at each demand location. Nothing is distributed to the demand location in advance of the demand date.
• Pull/Push: Supply is distributed immediately to the demand locations to cover all demand within the pull deployment horizon.
• The push by Demands: The supply chain is distributed immediately to the demand locations. – SAP Help

Pull deploys per demand, but not above demand (aside from what is necessary to meet the lot sizes). Push, attempt to move out material immediately from the sourcing facility. “Push by demands” is confusing because it is so similar to Pull. However, here the Pull deployment horizon is ignored. “Push taking the safety stock horizon into account” is push but with consideration for safety stock, which the other Push Distribution parameters do not take into account. “Push by quota arrangement” essentially allows quota arrangements to control the deployment.

However, the specific difference between Push and Push/Pull is a bit misleading. In essence, Pull/Push is Push functionality but is performed for the pull horizon. The Push Distribution field is highly confusing, and the documentation needs to be rewritten by SAP.

How Deployment Works in SNP

This is used to either allocate stock to customers or to allocate inventory to distribution centers. There are two ways of running Deployment:

1. Deployment Heuristic
2. Deployment Optimizer

The Deployment Heuristic

When you use the Deployment Heuristic, you can use both Fair Share and Push methods. Fair share is used when the supply is less than demand, and Push is used when supply exceeds demand. All that deployment can do is create stock transfers. For this reason, it is run after production planning. When running the Deployment Heuristic Fair share deployment and works on the following configuration controls:

Fair Share

1. Proportional distribution (based upon previous demand allocation)
2. Proportional fulfillment of target stock
3. Quota arrangements

Fair share also has some different ways it can be run:

1. Rule A: Allocates stock based upon previous demand allocation
2. Rule B: Allocates stock based upon target stock level
3. Rule C: Allocates stock according to Quota Arrangements
4. Rule D: Allocates stock based upon the priorities of the outbound transportation lane.
5. Rule X: User-defined with the DEPLOY_USER_DEFINED BADI

The push also has some options.

1. Push rule P: Demand within the pull horizon – only the demand within the pull horizon is met. No supply is distributed to the demand source in advance.
2. Push rule X: Demand in the system – all supply is distributed immediately with no concern for the pull horizon
3. Push rule Q: Push by Quota Arrangement – uses quota arrangements. Thus they must be configured.
4. Push rule S: Push with Safety Stock – only uses safety stock to fulfill demands
5. Push rule U: User-defined with the BADI DISTRIBUTE_USER_DEFINED

The Deployment Functionality in Action

The best way to test Deployment is by going into the Product View and setting up many orders in at least two locations. We want the Deployment  Heuristic, or the Optimization, to create Stock Transports between the sites. This will prove that the Deployment is in effect. Below you can see we have some orders placed on a location for the product SNA-GA. We also have a surplus at this location.

Next, we will show the second location for the same product, creating a shortage.

This takes you to the setup screen.

Problem with Fair Share

The fair share rule sounds simple enough. However, there can be problems with even this basic functionality.

The fair share logic can run into problems when there is something as simple as a shortage. For instance, under the following scenario, I ran into a problem.

1. Parent Location A (Demand = 1000, Stock = 1800)
2. Child Location B (Demand = 600, Stock = 0)
3. Child Location C (Demand= 1800, Stock = 0)

I have configured the following deployment optimizer profile. A “profile” is created and saved within the product location master. After created, it can be assigned to any product location. Blank in the Push Distribution means no push, and the A in the Fair Share Rule is by demands.

I would expect the following:

600 + 1800 = 2400

So

600 / 2400 * 1800 = 450 to Location B

Then the rest 450 – 1800 = 1350 to Location C

The results were not encouraging. Instead, it sent more than what it had in stock and stated that it could meet all the demand even though it lacked the stock.

Strangely, I found nothing online describing this as a problem. This is fundamental functionality, and it is quite surprising to find this result.

Interestingly, in testing with a different system, the results did provide a fair share. However, the question is, what was the difference between one system or the other? Nothing that I could tell.

The fair share distribution functionality should be bulletproof with a deployment heuristic, yet with SNP, it is not. This is only in the testing mind. I have a greater concern during production or after the system is live, where more problems can surface. I will post more details when I figure out why the fair share is working in one system but not in another.

The Deployment Optimizer

Now we will cover the fields that are available within the Optimizer Profile. All of these fields are associated with a tab in the Deployment Optimizer Profile.

General Constraints Tab

• Transportation Capacity: Takes into account transportation resources defined in the resource master data.
• Handling Capacity: Takes into account the capacity of the handling resources defined in the resource master data.
• Storage Capacity: Takes into account the capacity of the storage resources defined in the resource master data.
• Maximum Product Specific Quantity Stored: Takes into account the maximum product-specific quantity stored in the individual locations.
• Maximum Transportation Lot Size: Takes into account the product-dependent maximum transportation lot size defined in the transportation lanes.

There are several fields related to taking into account safety stock, and the same for shelf life, for supersession. (It also will take into account quota arrangement, which will not apply to most clients for redeployment, although possibly for deployment)

Discrete Constraints Tab

This tab is only of value if the discrete optimization option is selected.

• Min Transportation Lot Size: You can specify in this field that you want the optimizer to consider the min lot size profile for transportation lanes.
• Integral Transportation Lot Size: Can use integer transportation lots
• Integral Means of Transport: Can use integer transportation fleet values.
• Cost Function (Means of Transport): Can take into account the piecewise linear cost function defined in the transportation lane
• Procurement Quantity: Can take into account the piecewise linear cost function for the procurement quantity.

Model Params Tab

• Average Stock on Hand: Calculates the storage costs during planning (stock on hand, storage)
• Stock On Hand at the end of Period: Changes this calculation to the end of the period.
• Bucket Offset During Shipment: Used by the optimizer to calculate the availability date of a receipt element within a period (bucket)

Solution Methods Tab

• Max Runtime: Self-evident
• Number of Improvement: How many times will the optimizer look to try to find a better solution.

There are more fields below this related to essentially how many resources or how much time to provide to the optimization.

• Cost-Based Prioritization: Includes demand prioritization on penalty costs that you define in the product master.
• Strict Prioritization: Makes the optimizer adhere to demand prioritization.

Here we show the product master tab (SNP1) and the time-dependent costs entered per product location at either the customer or the location.

If you select the penalty cost box, you can then open the following and enter the information.

Back to the Solution Methods Tab, there are several solution procedures to choose from Primal Simplex or Dual Simplex. Also, the Aggregate planning field specifies that the optimizer carries our aggregate planning at the location product group level.

Integration Tab

This has fields that control the stock transfer and forecast horizon. The fixed or substitution order demand for fixed orders allows the system to treat the fixed orders’ distribution demand like independent requirements.

Automatic Cost Generation Tab

The first four fields deal with how things like customer requirements, corrected demand forecast, demand forecast, and safety stocks are treated regarding priority.

The other three fields on this tab have to do with how the optimizer considers the priority of location products in combination with priority classes of demand.

Extended Settings Tab

This tab contains fields that control the details of how the optimization technically runs.

Deployment Parameters Tab

This is the most important tab in the deployment optimizer profile. It controls what the optimizer looks at.

• Distribution Based on Lowest Cost: If shortage, fulfill the demand at the demand locations. This distributes the available to deploy quantity to the demand locations based on the lowest costs only.
• Fair Share Distribution of Demands: If supply shortage, this indicator sets the optimizer to distribute the available quantities to demanding locations evenly.
• Distribution Based on Lowest Costs: If surplus distributes available to deploy quantity based on the lowest costs only. Is not necessarily a location with a need.
• Push Distribution By Demands: If surplus available to deploy, evenly distribute the quantities based on demand.

Other fields on this tab have to do with the deployment horizon for push, pull, and SNP checking.

The Difference of the Deployment Definition Concerning STOs

The deployment optimizer does not require SNP planned stock transfers to highlight how different the deployment optimizer is from the deployment heuristic approach. 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, the 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

How to Understand a Custom Deployment SAP SNP Solution

Now that we have described the standard SNP deployment functionality, we will go through a custom solution for deployment. This is because deployment in SNP is often considered a gap versus customer requirements.

Setting Up Virtual Locations as Means of Transport

In the situation where a company has a virtual location that is used for ownership transfer for an intercompany transfer. A natural inclination is a consultant configuring SNP to add the same virtual location in ERP (the location must be in ERP to perform the ownership transfer) to SAP APO. In general, the consistency between ERP and APO is more important than the consistency between reality and APO. When a different supply network exists in ERP than exists in APO, this is a custom solution. There will be maintenance overhead involved as the systems are designed to work from an identical supply network. I won’t get into this here as I cover setting up the supply network in great detail in my book Setting Up the Supply Network in SAP APO.

However, if a company wishes to deploy to the “real” location next in line from the initial location, then modeling the virtual location in SNP will not work. This is because SNP cannot deploy “around” a location regardless of whether this location exists in real life or not. Instead, the company would have to deploy twice, once from the initial location and again from the virtual location. However, if the intermediate location is not a real location, it is unlikely the company will want to do this.

This is the standard design. However, the problem is that in SNP, a location cannot deploy “around” a child’s location. However, in this example, the virtual location sits on the water – and is simply a virtual location. It serves to transfer ownership between companies and is an intercompany transfer.

If a company does not want to deploy from the intermediate location, they can set up a plant in ERP and transport (MOT) in APO. A MOT is one of five varieties or dimensions of transportation lanes that can be created and configured to control the flow between locations. The MOT is designed to represent both the mode of transportation (airplane, railcar, truck) and the actual equipment. However, in this customized solution, it is used to represent a location.

The virtual location is still set up in APO. However, the transportation lanes to the virtual location and from the virtual location are blocked. Transportation lanes can be easily blocked or unblocked by selecting a single checkbox on the MOT (check this). However, the deployment is from the initial location, directly to the third location (and around the virtual location), and running the transportation load builder works the same way. (Understand that APO will not work this way without customization. For instance, the built loads are not sent through the CIF (unless the CIF is also enhanced) but must be extracted and sent to SAP ERP through some middleware.

Customizing a Solution for Deployment

The previous solution that I just described was partially customized. It still used SNP functionality but changed the workflow and the recommendations created by APO and how they were communicated between APO and ERP. This next solution is fully custom and external to APO. I was asked by the client and by SAP to try to get the solution to use as much native SAP functionality.

After quite a bit of analysis that included other APO and ERP consultants, my main client counterpart and I concluded that attempting to leverage any SAP functionality would be more difficult than worth. The company did not have an interest in purchasing a non-SAP application. I am unsure if we had performed a functionality search at other vendors if we found one that could have met the requirements.

That meant that the company needed to develop a custom external application, which eventually came to be known as the deployment prioritization application or DPA. This company had the following deployment requirements:

1. Deployment is based upon a custom prioritization sequence, which includes such factors as how many days past due the order is.
2. Deployment based on the requirements and stock position at the final distribution center, with a logic which is “if-then” nature, with the following rules:
   1. A stock that is not required at any of the final DCs (as well as in some cases, customers) is shipped to the regional DC (RDC) until a need appears at a final DC.
   2. The ability to deploy to multiple DCs, even though the stock is initially sent to the RDC, for cross-docking.

Prioritization Beyond Product Prioritization

So the problem is that standard SNP deployment cannot perform prioritization beyond product prioritization (that is, prioritizing a product’s prioritization number in the product priority field on the product location master.[1]

SNP does have the capability to perform what is called priority tier processing. This is used in conditions of shortage. Net requirements segmented. This is set up in the transaction /SAPAPO/TIERDEF. The segments or tiers are the following.

1. Backorders
2. Prioritized Fixed Demand
3. Demand For Replenishment Lead Time
4. Location’s Safety Stock
5. Non-Prioritized Fixed Demand
6. The proportion of Parent Safety Stock
7. Parent Location’s Safety Stock
8. Fixed Demands by Anticipated Demand
9. Additional Demand by Rounding (EOQ, POD, PS)

The following graphics describe the logic for the location deployment requirement.

The problem is that this intermediate location interferes with the deployment between factory and DC, which is actually how the deployment logic should be controlled.

For the actual deployment decision, the requirement is to use the DCs and customer locations’ status. The RDC receives the stock if no other suitable place can be found.

The selection criteria easily attain the deployment logic modeled above in the user interface, which I will show below:

How the DPA Would Work

The DPA concept would be a sortation-based application, which allowed the user to manually override any sortation, moving orders up or down in the queue, and fixing those laws whose rank in the sortation they were comfortable within the user interface. The user interface would have a screen with selection criteria along the top, including the following:

1. The Deployment Horizon
2. Products to be Included in the Deployment Sortation
3. Source Locations to be Included in the Deployment Sortation
4. Destination Locations to be Included in the Deployment Sortation

It would then have a screen below the selection criteria with the following fields:

• DC
• Order Type
• Pegging Relationship (from SNP and to be discussed in the next section)
• Calculated Deployment Date
• Order Quantity
• Customer Priority
• Location Priority
• Allocation
• Coverage
• Percent of Coverage
• Demand
• Is the production Order Complete?
• Part Number
• Target Coverage per Product for DC 1
• Target Coverage per Product for DC 2
• Target Coverage per Product for DC 3
• Target Coverage per Product for Customer 1
• Actual Coverage per Product for DC 1
• Actual Coverage per Product for DC 2
• Actual Coverage per Product for DC 3
• Actual Coverage per Product for Customer 1

This application would provide lots of flexibility regarding how the orders were sorted for deployment. The last fields would allow sortation based upon how far away the location is from its target. This application would be tough to build and provide the ability to sort on a wide variety of criteria – repeatedly sorting – and fixing some of the orders until the deployment’s capacity had been reached.

I do not doubt that many other companies would be interested in such an application.

Using the Pegging Relationships for Deployment for Prioritization

One of the main issues with the DPA was that it needed the connection between the demand and supply element to apply the desired prioritization. This is the pegging relationship. Because we were using CTM, which has the best pegging functionality of all the APO methods, we knew that the company could rely on the complete pegging information from APO when implemented.[2] [3]

The trick was getting these peggings extracted from the APO system to be then sent to the DPA. One account manager from SAP repeatedly recommended we pull the sales book from ERP. However, just looking at one side of the equation – demand does not explain the pegging or relationship between demand and supply.

The Problem: A Problematic Deployment Solution

Many years of using SAP APO deployment have me questioning why APO should be used for deployment. The reason is that it is far more straightforward to simply build a custom deployment solution from scratch that has to deal with SAP’s deployment functionality continually. The deployment solution is better and more effectively run from a cloud service provider and simply connected to APO, rather than adding the application logic to SAP. We follow the same approach when customizing MRP, as is covered in the article Real-Time MRP.

Deployment in SAP has considerable overhead and does not work the way most companies want to deploy. This is because companies want to fair share stock to downstream locations. The optimizer states that it does this, but after years, most companies have either given up on the optimizer in SAP or are still struggling to get it to work and have spent enormous sums and still have poor quality output. SAP’s deployment optimizer does not make any sense and will never work correctly, as we covered in the article The Problem with SNP Optimizer Flow Control.

The master data maintenance in the transportation lanes, the failings of the deployment optimizer, the overall overhead merely is unacceptable for the output that SAP APO produces. APO’s deployment heuristic works but is so basic that it can be easily replicated by a far easier-to-use externally developed solution that allows the solution to be customized for the requirements. Deployment functionality offers no reason to use it, other than it is “SAP.”

Being Part of the Solution: Running Deployment Externally

This article has been written for people that have to get deployment to work in APO — but it is not a very good solution. The best solution is to simply run the deployment externally and then import the data back into APO — or even APO and just import the data into ECC. The application runs on AWS, and so we can bring large amounts of server resources to the problem and run it far more quickly than any SAP server that currently runs APO can.

References

[1] Of course, the problem with saying you “can’t do something” is a risky statement. Some SAP resource is sure to say that it can be done. Interestingly, if one says something can be done in SAP, little evidence is required to make people believe it, but if one says something cannot be done in SAP, an enormous amount of proof is required. No matter how expensive or poorly functioning, there always seems to an SAP consultant willing to say it can be done – often by customizing SAP – without considering the cost/benefit. Those how to know SNP well may know that there is a custom option to the fair share logic (the Fair Share Rule field on the SNP 2 tab of the product location master) – so that the fair share of deployment can be based upon custom logic built by the client. However, one issue with this hook is that it only works when fair share deployment is used, while we needed the custom logic to work for all deployments, not just when there is fair share deployment required. We did not go in this direction because it would not solve the second requirement, which was to deploy “around” an intermediate location.

[2] Something interesting to note is that neither the deployment optimizer nor the deployment heuristic can use the peggings that are developed from the initial supply plan. This means that when deployment is run in SNP, the peggings, which focus on the initial supply plan, are eliminated. We discussed this topic quite a bit on the project and another SAP APO resource, and I concluded that this was simply a bug – an incomplete design between the two fundamental planning runs in SNP.

[3] However, one does not have to run CTM as the planning method to benefit from CTM’s pegging. Part of the research on this project proved that CTM could be used exclusively for pegging no matter what methods were run previous to a CTM pegging run. This research is extensively explained in the book “Combining Supply Planning Methods in SAP APO.”

SAP Release Notes

Deployment Capability

I was recently asked what the deployment capability in SCM was.

One confusing thing in this area is that SPP, which has picked up a large amount of functionality in redeployment, is listed as deployment in the SAP release notes, which is incorrect. Deployment and redeployment are two separate planning threads. However, here is a list of deployment functionality enhancements as of SAP APO 4.1: 4.1 SNP Deployment

• The 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 transportation lane’s validity dates and means of transport.
• The 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 consider 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 carries out a fair share distribution of the ATD quantity to cover the demand at the source location and 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.
• The 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 regarding 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 considers.
• 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.