Background
I have recently been analyzing using Inventory Balancing functionality in SPP, and the Deployment Optimizer in SNP in order to redeploy inventory. SPP Inventory Balancing is explicitly designed for this, while the SNP Deployment Optimizer is not (rather it is designed to move material out from parent locations to child locations in conditions where there is an overage or underage of material). However, I have been attempting to see if the Deployment Optimizer can be adjusted for this task. What I have found is the redeployment capability is significantly below third party application. And one area that we have analyzed is the ability to redeploy different types of stock differently. In fact, I have not found any evidence that the Deployment Optimizer has been used at any client for redeployment. Some consultants who are not familiar with redeployment like to pretend that deployment and redeployment are the same thing. This is convenient for them if they are SNP consultants as deployment is really all that SAP SNP has to offer.
Here is roughly how deployment is different from redeployment.
Click the image to enlarge.
Soon to Expire Stock
For the category of stock that is coded as “soon to expire” the solution selected must be able to reduce the threshold for redeployment so that the material can be repositioned to a location where it can be consumed rather than written off.
The Burnout Threshold
Other software calls this the Burnout threshold and is easily adjustable. We are not surprised that the SNP Deployment Optimizer does not have this, because it is not designed for redeployment. However, we were surprised to find no such functionality in SPP. The closest that we could find were fields related to the warranty end date, recall start date and the goodwill start date. These fields are related to providing a signal to the system to treat the inventory differently during redeployment. They are not the same as burnout threshold which is a very useful concept that exists in third party applications.