How to Understand Redeployment Decision Matrix for SAP APO

ByShaun Snapp

Executive Summary

  • Different Redeployment Designs in Conjunction with APO
  • Redeployment Decision Matrix
  • Integrating with the SAP Deployment Solution
  • The Approach for Transportation Lane Management
  • The Downsides

ReDeployment

Introduction

Redeployment is a much less discussed supply planning thread. Some redeployment is necessary at most companies.

Different Redeployment Designs in Conjunction with APO

Companies do not meet their redeployment (not be confused with deployment needs, which are met with the SNP deployment heuristic) needs with APO. I have been through this topic with several companies, with a desire by either the consulting company or SAP, that we “get creative” in coming up with a way around the fact that there is no solution in APO.

  • This request to get creative is usually issued from the person responsible for checking if SNP could meet all of their supply planning needs or the SAP account manager who needs political cover for why both deployment and redeployment were not sufficiently explained during the discovery phase of software selection.
  • However, while many calories have been burned on this topic on several clients (after testing the cost optimizer and CTM with various custom configurations), the result has been the same. We end up not doing redeployment in APO. Redeployment does not exist in SAP SNP and never did.

Companies that want redeployment functionality do not use APO for deployment, and they have three basic alternatives available to them:

  1. Create a custom report that allows the redeployment to be performed manually.
  2. Use an application that has redeployment functionality, and integrate this application with APO.
  3. Create a custom application that performs redeployment.

Redeployment Decision Matrix

redeployment-decision-matrix

Integrating with the SAP Deployment Solution

Regardless of which alternative above is chosen, it is still necessary that the redeployment transportation lanes be turned on when STOs are brought over from SAP ERP and turned off before the SNP heuristic running.

  1. If a custom report is used, then the redeployments are created manually.
  2. If an application is used (either custom written on a third party application), then stock transfer requisitions are created automatically (outside of APO, of course), and they are then evaluated before being approved and sent to SAP ERP to be converted to STOs.

Redeployment stock transport orders are scrutinized much more heavily than normal deployment stock transport orders. A massive value judgment often goes along with how redeployment stock transport orders are viewed because they are considered rectifying a mistake. Considering that I mostly work with companies that do things like manipulating/flush safety stock to make their quarterly inventory targets or can’t justify why different supply planning methods were selected, the value judgments are routinely applied to redeployment STOs is peculiar.

Some companies cap redeployment transportation budgets, which is again weird. When a program is used, redeployments must already pass a test, one of which is the transportation cost of the redeployment movement.

Sometimes the “if our forecast was only better” argument may be brought up. However, a certain percentage of deployments will always be wrong, and as time passes, the stock can be repositioned to locations where it has a higher probability of being consumed.

That reduces duplicate production, reduces inventory and inventory carrying costs as well as obsolete stock. However, when a redeployment solution is rolled out, it will tend to have more manual oversight over the STRs generated than normal deployment STRs.

The Approach for Transportation Lane Management

There are several steps to managing the SNP model setup so that a multi-method approach (that is, one which also uses an SNP heuristic, as that is the main point of contention) is consistent with redeployment STOs. The steps are the following:

  1. Setup redeployment transportation lanes (RTLs) between all locations for which a redeployment stock transport order could conceivably be created.
  2. Use a process chain to activate and deactivate the RTLs.
  3. Set up a specific time when redeployment STOs will be sent over to APO. Redeployments tend to be infrequent. Weekly will tend to be the highest frequency (and quite rare actually), with bi-quarterly or quarterly being a far more common frequency.
  4. Use a Process Chain to activate the RTLs, bring over the STOs to APO, and de-activate the RTLs with another Process Chain.

The Downsides

This is undoubtedly work and long-term maintenance. This work is necessary because the RTLs create strong location-to-location relationships, which we are not part of the normal deployment flow. SAP Development did not think to provide the ability to have transportation lanes assigned for different purposes (for instance, allows for the creation of RTLs which are coded so that they are ignored by the initial supply planning run and the deployment planning run).

Essentially SAP development not only did not build in redeployment functionality into APO but also developed its heuristic solution without consideration to whether a company would ever want to perform redeployment. This issue applies to the SNP heuristic, but not with CTM. That is, CTM can plan “loops” while the SNP heuristic does not.