What This Article Covers
- What is Redeployment?
- Redeployment as it differs by product type.
- How redeployment compares across supply planning methods.
Background on The Redeployment Planning Run
Redeployment is the redistribution of stock that is already in a forward location in the supply network to another forward location, or back up to the parent location. Deployment follows a rigid flow of parent to children locations which is essentially designed to minimize logistics costs. However, redeployment is quite different because it means that the normal parent child valid location-to-location relationships are in essence turned off, allowing any location to be shipped stock from any other location. Redeployment can be considered the correction of an error in the deployment supply plan in that product was moved to a location that it was not consumed, and has a lower probability of being consumed in the future at its present location than if moved to a new location.
Different Redeployment for Different Products
Redeployment is in general an overlooked supply planning functionality on the part of non-MEIO vendors. Other supply planning methods focus on the initial deployment, but often not at all on redeployment. A case can be made that this is an oversight, as imperfect forecasts will require some percentage of the initial deployment to be redeployed at a later date. This is not only a matter of simply waiting and taking more inventory costs, product can and does expire because it was never redeployed, and this means writing off both the cost of the item in addition to the carrying cost of the item until it expires.
How a product can be adjusted post deployment greatly depends upon the product’s characteristics. Some items only have the opportunity to be sold in the same state but in a different location. However, some items like paint can be re-manufactured and can be sold as entirely different colors (possibly a better selling color), and this can mean moving the product twice. One to move it back to a manufacturing facility, and again to move it to forward locations in the supply network (which may or may not be where the product originated). In this way, re-manufacture is very similar to the repair redeployment faced by service parts networks.
A Philosophical Opposition to Redeployment with Finished Goods Companies?
It sometimes appears that redeployment contradicts some supply chain decision makers at a philosophical level. I was once told by an executive that they did not want redeploy inventory, because “what we they had to redeploy it yet again?” However, there is nothing to say that the initial deployment is correct. All anyone can do under conditions of uncertainty is apply probabilities. A certain percentage of all supply chain planning decisions will be “wrong,” but that should not prevent us from making due with imperfect information.
How Does Redeployment Compare Across the Various Supply Planning Methods?
Redeployment is one of the strongest areas of functionality for MEIO vendors, and correspondingly one of the weakest areas of functionality in all other supply planning methods. In fact, I am unaware of any redeployment specific functionality in DRP, Heuristics, Allocation of Cost Optimization (as a workaround, Cost Optimization can be possibly adjusted to perform a redeployment, but they are not designed for this, and it is not a recommended solution). This is in fact a greatly underemphasized area of supply planning software development, as every client I have consulted with has a need for redeployment. The lack of enterprise software solutions is why this is a common area for custom development.
The History of Redeployment
The original work on MEIO was actually developed for service parts network which have a strong need for redeployment. Many of the RAND Corporation papers that set the basis for modern MEIO had a strong emphasis on redeployment as this was a requirement of the US Air Force (the party actually paying for the research), and their airplane service network. In addition to having the functionality built-in, MEIO vendors have an advantage conceptually over non-MEIO vendors in redeployment because the traditional logic of deployment, which non-MEIO vendors attempt to use for re-deployment such as fair share logic, does not translate appropriately for redeployment. The logic for cost optimizers which essentially compares the transportation costs to the costs of unfulfilled demand at the sending and receiving location as well as the storage costs at the sending and storage locations are also not really designed for redeployment.
Of the many reasons listed for why MEIO is a good choice, redeployment is very far down on the list of most companies. That is unfortunate, because it should not be. Redeployment is an important functionality, which MEIO is naturally good at performing. It should be considered a major benefit of moving to a MEIO system. Service parts planning MEIO vendors have the strongest redeployment functionality, with their redeployment actually being a separate run which creates stock transport requisitions. However, most the non-service parts MEIO vendors also have redeployment functionality, which is simply part of the normal network supply planning run and focuses more on redeployment at the lower echelons of the supply network.
Do you have a question about the post? If so please comment below.