What Is Redeployment?

What This Article Covers 

  • What is Redeployment?
  • Redeployment as it differs by product type.
  • How redeployment compares across supply planning methods.

Some 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 as he put it:

“what if 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.


Using MEIO to Connect Sales and Supply Chain Planning

What This Article Covers

  • How Inventory Optimization and Multi Echelon Planning software (MEIO) enabled contract development.
  • The issues with sales versus operations at most companies.


Part of this article is a movement of previous text from a separate article here. However, I reviewed an older article are realized this section should be moved and given its own article.

Working with Contract Development or Sales

Contract development will most often have service levels that are set at the customer. Supply chain planning organizations tend to set their service levels at the location or the product location. However, one reason for the conflict between sales and operations is that they often speak in different languages. In order for supply chain planning and sales to interoperate, they need to be using some of the same language.

Sales vs. Operations

This is a problem at every company that I have worked for, however, the examples I have seen have been in consulting and software. In either case sales routinely promises things that operations can not implement. In fact, in software, things are promised that don’t even exist. I was once told by a software saleswoman that I needed to “get onboard” with the vision that the “optimistic” president of sales of was creating for the company. However, as a software implementor, all I had was the software to implement. This basic and continual problem in level setting between sales and operations is not very well explained and leads to over-optimism regarding software such as Sales and Operations Planning (S&OP) which is supposed to help reduce this conflict. However, the concept of S&OP is not a coherent process at most companies, even thought it is a perennial “hot topic” with executives that sells many books.  In fact I have developed a “real” S&OP process graphic below:

This is to a great degree because sales and finance and operations do not have anywhere close to the same amount of power, at least in the US. Consulting firms and book on S&OP like to sidestep this issue, because they would rather focus on less political issues such as software or “getting everyone in the same room.” For more details on the flaws in S&OP see this article.

Contract Development

MEIO can’t do anything about the discrepancy in power between sales, finance and operations, however it can help with the common language aspect of the disconnect. A design that describes how a MEIO application can be shared between different departments is shown below:

Contract Development as Customer of Supply Chain Planning and Vice Versa

When MEIO applications are used in this way, the contract development department is a customer of supply chain planning. Supply chain planning provides them with up-to-date parameters and costs, while planning is a customer of contract development in that contract development provides them with service levels per contract.

  • Planning uses a system which is active or production
  • Contract development uses essentially a copy of the system which is off-line, and run in simulation mode.

Following this approach, contract development does not interfere with the active production instance and they can run and re-run their simulation as often as they like. However, it is important that periodically the production system data overwrite the contract development instance so that contract development is working with a recent copy of “reality.” Any capable inventory optimization software has the ability to easily perform this copy, and it is a normal part of system’s maintenance. Simulation is what allows multiple instances of a database to be created, and to inter-operate flexibly with the application logic. It is one of the great advantages of planning systems, although the full capabilities of simulation are very rarely tapped into by companies.

Does the Present Solution Include this Capability?

Very few software vendors have this capability, so what many businesses are doing is using terminology such as inventory optimization and multi echelon planning, but selecting software which cannot support this terminology. Secondly, many executives have no idea that software exists that can do this, so they miss out completely on being able to enable their businesses to operate in this way.


A lot of companies can benefit from this much more advanced and accurate approach of pricing new business. For companies  that are serious about managing their supply planning by differentiated service level, MEIO is the key enabling technology.


Was this article clear? Do you have any questions about how this would work. If so comment below.


Inventory Optimization Versus Allocation Software

What This Article Covers

  • What is allocation software?
  • What is the output of allocation software and how does it relate to MEIO?
  • How does allocation software process the supply network?


The topic of how different supply planning methods relate to one another is always of interest to decision makers, and to my knowledge how allocation and inventory optimization and multi echelon (MEIO) related to another is not generally written upon.

What is Allocation Software?

Prioritization in Capable to Match (CTM) works on the principle of running some customers through the planning process, and allowing them to have inventory pegged to their requirements before others. A CTM run uses the combination of the supply, demand and master data selection to perform sequential planning. The actual process it uses is simple. It runs some demand segments (i.e. customers) before others. Thus, these earlier runs consume inventory through pegging, and then later runs and demand segments have less inventory available to them because the previous runs have taken it. At some point inventory is no longer available for the lowest priority demand segments.

How Allocation Software Processes the Supply Network

Allocation based methods are order based methods of creating the supply plan. Unlike MEIO which looks at the entire supply network and computes a probability for every location product combination at every iterative stocking level, allocation is only processing a portion of the supply network every time it pegs a demand element to a supply element. The way MEIO software works with respect to overall supply network analysis is described below:

Inventory optimization has one set of mathematics behind it, and multi-echelon planning has another. However, MEIO vendors combine them and have them perform their calculations iteratively. What is really quite amazing is that MEIO software does this for every product-location combination in the supply network and for every intermediate state between the starting inventory position until it hits either a service level or inventory cap. This stops the model from continuing to add inventory. A simplified version of the formula for the inventory optimization piece is shown below. Not all vendors use the same approach, but this is a general approximation of what most of these applications do. – Inventory Optimization and Multi Echelon Planning Software

Prioritization/allocation software can not position stock as well as MEIO and are much less sophisticated mathematically than MEIO. (For details on how CTM works, see this post.)

Also the challenges faced by allocation projects. This is because Capable To Match (CTM) creates the supply plan by responding to individual planned requests. CTM for customer allocation works from a list of customers of different priority.

How Allocation Deals with Service Level

As with cost optimization, CTM also does not have a concept of service levels. Instead, it is providing stock to customers based upon the sequence customers are processed by the application. Higher priority customers receive essentially 100% fill on their orders, and lower priority customers receive whatever percentage of fill is available after the top priority customers have taken all of the inventory that they have requested. This is the weakness with all priority based systems. For instance, in SNP it is possible to perform fair share deployment based upon priorities. The priorities are assigned to the transportation lanes in SNP.

This field sets, which is assigned per product per transportation lane in SAP SNP, controls the priority of the location. For more on transportation lanes in APO, see this article.  


Priorities are very binary, and work as the following graphical example demonstrates with regards to fair share distribution.

As one can see, priority systems are a “winner” take all method of fair sharing a limited amount of stock among different competing demands. This is a less flexible way of allocating than using a service level. This is why I prefer using MEIO for customer allocation and fair share distribution in allocation based upon quota arrangements rather than priorities.

CTM creates both the initial stocking position and the pegging between the customer demand and the receipt element. MEIO on the other hand creates the initial stocking position but not the pegging. However, after the pegging has been created, a mechanism is required to enforce the allocation that has been created by CTM. This occurs in the order management process. SAP typically recommends using GATP, to enforce the allocation, however, GATP which is rarely successfully implemented, although it has been broadly attempted. Allocation protection software can be used to protect allocations created by an allocation planning system or a MEIO system.


With MEIO, there is much less reason to use allocation software. However, CTM continues to have a very appealing aspect for clients that MEIO does not have, and that is the ability to perform constraints based planning.




Do you have any questions about the article. If you do, add a comment below and we will respond to it. 

MEIO for Consumer Packaged Goods and High Tech

What This Article Covers

  • How do two major industries relate to inventory optimization and multi echelon planning (MEIO)?
  • What are the different types of high-tech firms?
  • What are some of the demands of meeting the requirements of the retailers in consumer packaged goods?
  • How have problems with cost optimization impacted the acceptance of a second optimization method?

How Inventory Optimization and Multi Echelon Planning Applies to CPG and High Tech

A frequent question within companies is how inventory optimization and multi-echelon planning (MEIO) relate to their particular industry. At a high level and regardless of industry, MEIO applications are appropriate for any company that wants to manage their supply chain on the basis of service levels. However, there are important distinctions with respect to the opportunities presented by MEIO applications that differ per industry. Not being an industry specialist myself I turned to SmartOps that was nice enough to put me in touch with their industry experts.

In this article we will discuss how MEIO helps manage the supply planning challenges in two industries; consumer product goods (CPG) and High Tech.

Consumer Product Goods

CPG covers a broad spectrum of products and is one of the largest industry segments globally. Historically CPG companies have tended to have high margins. Their marketing focus has led to product proliferation for the supply chain organizations of these companies. Through extensive work with CPG companies, SmartOps has observed that there are key features that are especially relevant for their CPG customers. These are the following:

  1. A tendency for these companies to vacillate in their emphasis between inventory costs vs service level, but with a general tendency to favor service levels over inventory costs.
  2. The desire to set a service level for overall product mix
  3. The ability to deliver products to different channels based upon different service levels
  4. The desire to change service levels depending upon the time of year
  5. A need for more sophistication in product prioritization beyond ABC classification

Current Challenges in CPG

The CPG industry is current facing a change in its circumstances that creates a requirement for enhanced supply planning techniques over what is currently the general practice in CPG. CPG companies are seeing increases in some of their most important costs, fuel and raw material. Unfortunately, many CPG companies have designed their supply chains for the higher profit environment that they historically enjoyed. Generally, through interaction with clients, SmartOps has observed that many CPG companies are struggling to meet their fill rate objectives.


Inventory optimization and multi echelon planning (MEIO) holds benefits for a number of which match the key drivers of CPG and can help mitigate their current challenges. In the area of addressing key drivers, MEIO software has the ability to provide a transparent understanding of the relationship between inventory costs and service level. While all supply chain professionals can relatively quickly grasp the standard inventory cost of service level curve, to be able to interact with this curve, to change service level or inventory cost caps interactively and perform sensitivity analysis, with the company’s actual data is a different matter. It is the difference between understanding a general principle and having actionable intelligence. SmartOps has performed this type of analysis for a number of CPG clients and has found that promotes a more logical policy regarding service levels that are selected by the company. On a personal note, I can say that it is surprising to me how many companies think they are hitting a higher service level they actually are. This is because non-MEIO systems do not have the ability to model the service level-inventory trade-off. Furthermore, I have discovered from working on a number of cost optimization projects that the costs which are input into the model would never result in minimizing costs in any real sense, because the costs are set too high in one area, usually the cost of missed demand. This discovery is described in this post. Off-line analytical tools can get a close to this value, but no other application can model the service level-inventory trade-off as accurately as a MEIO application. This is one reason MEIO applications can be used either in production, or as simulation environments so successfully.

Without the feedback of the cost of maintaining the different service levels, there is a tendency for executive decision makers to set the service levels unrealistically high and to either incur extremely high costs, or to promote gaming behavior in the organization in order to attain these unrealistic service levels. This tendency exists because the company simply does not know, and does not have transparent control over its service levels. Analysis that can be performed by using SmartOps, lays bare the reality of what can be afforded.

Meeting the Demands of Retailer

CPG companies sell to retailers and just a few retailers like Wal-Mart and Target can represent large percentages of overall sales of many CPG companies. These retailers dictate specific service levels. This means that CPG companies must be able to provide their family of products at an overall service level, much like a service level contract. SmartOps allows CPG companies to meet the overall objectives of these retailers by working backwards from the aggregate service level requirement to define each of the individual product location service levels. How this is done is not discussed sufficiently with regards to MEIO application in general. Most often MEIO is discussed in terms of setting service level targets at a product location. However this capability happens to be one of its most powerful area functionality of this class of software.

Meeting the service level requirements of retailers not only means deriving different service levels for the product mix the same way in all time periods, but making changes depending upon the time periods, for instance depending upon the seasonality of the products. CPG companies can use the SmartOps solution to set a service level that varies depending upon the time of year. This means that the company can more intelligently deploy its inventory, and move these inventory dollars not only between products locations, but also by the time of year.

High Tech and MEIO

Another industry to showcase is one that is quite different from GPG. High Tech. High Tech is identified with the following supply chain features.

  1. Deep bills of material (i.e. complex products)
  2. Long lead times for materials
  3. High demand volatility
  4. Short product life cycles

A product that is purchased by a consumer in a Best Buy has a lengthy supply chain in which a wide variety of component specialists participate. Anyone who purchases consumer electronics is familiar with how quickly products turnover and how often new products are introduced. However, what is less well-known is how this issue of short product life cycles extends to electrical components. A good example of how quickly things change can be taken from a current event. There is now a heated competition in computer tablets. This is an emerging technology market that did not exist in any volume prior to one year ago. No doubt some of these tablets will become popular, but many of them will not. It is very difficult to forecast those that will become popular, and those do not will result in few components being demanded to support the finished good. Another example of how fast things change is the new iPod Nano. This device shrunk my more than 1/2 meaning that a new internal design was required and new, smaller components, and even a consolidation of several components into one component was effected in the product’s bill of material.

Types of High Tech Firms

It can also be said that there are at least two different categories of High Tech firms. There are firms like Intel and Samsung that are very capital-intensive and which have higher profit margins, and then firms like Flextronics and Celestica that are less capital-intensive and have lower profit margins. Each category faces different challenges. Flextronics and Celestica must be able to respond quickly to the demands of the major electronics brands, which include effectively managing their inventory of components and their procurement.

In the capital-intensive semiconductor firms (Intel and Samsung), there are thousands of die are on one wafer, and a huge array of different products into which these product serve as subcomponents. However, their typical raw material lead-times of 10 to 16 weeks. These firms also have long development times the requirements of with large capital investment.

The Hangover of Cost Optimization in High Tech

Many companies in High Tech were among the leading edge of companies that attempted cost based optimization back in the 1990’s. (cost optimization differs from inventory optimization in that costs are what the system attempts to minimize, rather than inventory optimization which minimizes inventory per specific service level.) The problem is that few High Tech companies saw very much value from cost optimization. Many issues surfaced during cost optimization projects, from the difficulty in interpreting the results to the difficulty that companies encountered in developing their costs to be used by the optimizers. I am occasionally asked what the difference between cost optimization and inventory optimization is, and whether the same implementation problems can be expected that arose with inventory optimization. My answer is that they are quite different. Inventory optimization is a far better defined form of optimization and much has been learned since the first attempt at optimization, which was cost optimization. However, this fact is not well understood, and therefore the stigma of cost optimization remains. It negatively impacts the acceptance of inventory optimization generally, but particularly within the High Tech industry. This has caused many companies that could benefit from cost optimization to hold off on implementing this type of software, and this is supported by the fact there are few inventory optimization vendors that have made much headway in the High Tech industry.


At a high level, the answer to the question of “why inventory optimization and multi echelon planning” can be answered by the statement that this method of supply planning is beneficial for any company interested in planning their supply chain based upon service level. However, as one becomes more immersed in different industries, it is clear how MEIO solutions address different industries differently. However, one of the most powerful trends that becomes more apparent the different industries are analyzed. That is that supply networks are becoming more complex, with more partners and more echelons being added. This has been the case for some time in High Tech, but is growing in CPG as well. While this complexity is added, it can be an afterthought as to whether the present supply planning software the company is presently using, is designed to manage this complexity. It is important to align changes in the supply network with the solutions used to plan them.






Was this article clear? Do you have any experiences you would like to share regarding inventory optimization and how it may apply to your industry? If so comment below.

Key Success Factors for Optimization Projects

What This Article Covers

  • What key success factors are necessary for optimization projects?
  • Do the key success factors change by optimization type?

Key Success Factors

I was recently asked what I thought they key success factors were for optimization projects. This seems like somewhat of an obvious topic to write on, but the nice thing about my work is I get a lot of questions that then cause me to think through various topics, and then promote me to then document my answers. Also, I now have come to experience different forms of optimization, and have developed a list of things that I think are really necessary to both implement and maintain optimization. So while I am placing this on this inventory optimization site, it really applies to every form of optimization I have worked with.

  1. Dedication to explaining and socializing the solution to all people who the optimizer effects. (this topic is discussed in detail in this post http://www.scmfocus.com/inventoryoptimizationmultiechelon/2011/05/socializing-supply-chain-optimization/)
  2. Master data emphasis
  3. Senior executives who actually understand optimization conceptually at the very least
  4. A comprehensive approach to the development of the main control metrics (costs for cost optimization, service level for inventory optimization, durations for duration optimization, etc..)
  5. For optimization that included constraint based planning, having the correct orientation, resource allocation, and master data update tools necessary to keep the constraints in the system consistent with the reality of of the supply chain domain being modeled.
  6. Understanding that the results from optimization are different than the results from other methods of planning (MRP, DRP, Heuristic, etc..)
  7. Engaging in a thorough analysis of how metrics should change in the new state using the new technology
  8. Create a training and continual education database
  9. Purchasing the necessary hardware and app servers in order to provide both simulation environments and enough breathing room for multiple uses of the application
  10. Related to the previous point, setting up the overall installation to meet the needs of multiple groups. However, each individual group that requires information from the system (S&OP and contract development, mid-term planning etc..), must be willing to provide funding to the installation. Companies where different groups simply plan to extract information from the optimizer, without providing resources back to the installation end up with unsustainable and underfunded optimizers.
  11. Dedication to support, which means enough staffing in this area. New people will be continually coming into the organization, and will typically only have a hazy understanding of optimization. The support staff that is put into place must not only troubleshoot the application and support employees who may have gone through the implementation and have already been educated (but require reinforcement), but must educate new employees as well.


The Key Success Factors on optimization projects don’t change much regardless of the particular optimization method used. However, the effort and resources required to follow these steps is high, and is not for many companies that are primarily focused on extracting from their supply chain planning function rather than creating sustainable systems for their operations. I see many companies that lack the desire to fund effective optimization capabilities. I say desire or interest to invest, because every company I have consulted with has the resources to support fully functional optimization in at least production and supply planning, however, they choose not to, and to allocate money to marketing, executive compensation, etc.. When I find multi-billion dollar revenues in sales, that try to maintain optimization solutions with just a few people who know the solution, it becomes fairly obvious that this is not an issue of funding availability as allocation of this funding. Optimization projects that don’t have at least most of the success factors listed above tend to stall out. If the desire is to keep operational costs minimal, then skip optimization. However, for those companies that are dedicated to optimization and really want to improve their supply chain operations, then make sure the list of items above is met.

Questions or Comments? 

Was this article clear? Do you have any experiences you would like to share regarding inventory optimization success factors? If so comment below.

How Costs Are Really Set in Cost Optimization Implementations

What This Article Covers

  • What are implicit versus explicit costs?
  • What are actual costs versus what is normally used?
  • What are the implications to how costs are set?
  • How does this compare to inventory optimization and multi echelon systems?


In working on a number of cost optimization accounts over the years and in conferring with other individuals who have worked in the area for some time, I have come to a conclusion regarding how costs are set in both supply planning and production planning implementations.

The graphic above describes major elements of cost optimization that applies to supply planning.

Implicit Versus Explicit Costs

Cost optimizers use both explicit and implicit costs to generate the plan. During the software selection stage, this tends to be covered from a surface level, but it is probably the most important element to investigate thoroughly before engaging in cost optimization implementations. Before we go into the cost development methods its important to review the distinction between explicit costs versus implicit costs.

Explicit Costs

Explicit costs are the costs that the company actually incurs, these would include things like transportation costs and storage costs. They are paid out by the company, but must be aggregated because it’s not feasible to enter the costs for every single shipment into the model. Estimating these costs is tricky, and surprisingly, there is generally not a group inside a company that can help with this cost estimation.

Implicit Costs

These are costs that the company does not actually pay out but are implicit in the activities of the business. Penalty costs are an example of an implicit cost. When a company fails to meet a demand, there is no accounting entry for this. The customer  goes away, and no sale is made on that item. That customer may purchase another item from the company’s offering, or may move on to a different company’s item, and in the latter case the first company has lost the profit and goodwill of that potential sales had they been in stock. For a cost optimizer to appreciate that not stocking out is important to the company, and for an appreciation of how important it is to meet this demand, a cost optimizer requires a cost associated with an unmet demand, which is then traded off against the costs of ordering, keeping items in stock, transporting items, etc.. Implicit costs like this are more difficult to estimate than explicit costs because they can’t be found in any invoice or real cost the company pays, but comes down to the goals and objectives of the company.

Actual Versus Relative Actual Costs

There are several ways to set cost, both explicit and implicit costs, in a cost optimizer. The major ways I have seen are listed below:

  1. Actual Cost Development: Use actual costs for the explicit costs, and then perform detailed cost based accounting to develop the implicit costs.
  2. Relative Actual Cost Development: Start off with close to actual costs for the explicit costs (transportation and storage, etc..) and then derive the implicit costs, such as penalty costs in relation to these explicit costs.
  3. “Crazy Costs” or Interactive Cost Development: Here, costs are simply determined based upon repetitive testing and the desired model output. The costs do not relate to any real costs but are simply determined through trial and error which provide what the planners want to see.

What Academics Would Say on Cost Development

The underlying assumption of cost development that underpin cost optimization is that the costs are some reflection of the actual costs the company incurs. If one were to think about the objective function of cost optimization, that is to minimize costs, the concept is that the optimizer is in effect reducing the real costs that the company is incurring through its various operational behaviors. This was the original intent of the of the software, and is the assumption under which the optimizer is sold to company and to explained to executives. However, the way that the costs that are placed into the cost optimizer are developed, this is not at all what the cost optimizer is in fact accomplishing.

The Reality

What would come as a surprise to academics, and what has surprised me, is that the only way I have ever seen costs developed on cost optimization projects is the third method, the Crazy Cost, or Interactive Cost Development Method.  Interestingly,  in different conversations with different implementers of cost optimization systems, the responses I get back is that “actual costs were not know,” “we tried actual costs and they did not work, so we went to this.” This is not one observation, but many observations, and not just my observation, but has been verified with a number of other consultants who have also seen multiple cost optimization projects. What this tells me is that the Crazy Cost Method is the dominant method of developing costs on cost optimization projects, and that using actual costs, or even relative actual costs is the exception, not the rule.

The Implications

What this means that the cost optimization that is occurring is not actually based upon the costs that various things cost the company. The costs are simply rigged to give the desired output. So if a very high penalty cost is required to get enough stock held by the system, then it is simply increased until the desired effect is obtained.

Secondly, if actual costs cannot be estimated and if estimated cannot be used, then it calls into question whether the objectives of companies that implement cost optimization projects actually consider cost minimization as the overriding objective of their supply chain organizations. Cost minimization is the objective function of the cost optimizer, and therefore should be the objective of the company implementing this technology. If this is not the actual objective, then cost optimization, or cost minimization is not the correct supply planning method for that company to use. This addresses the core of how various methods are selected for implementation. Many people think that cost optimization is advanced, and it is. However, it is also very specific and does only one thing, minimize costs. The match between the biases of the technology and the goals of the business is the most important factor in method selection, not whether one method is more advanced than another.

Implications When Comparing Cost Optimization to Inventory Optimization and Multi Echelon Planning (MIEO)

The implications for inventory optimization bear discussion. Inventory optimization and multi echelon planning uses goals that are more easily quantifiable by supply planning organizations. These goals are services levels and inventory quantities. This means that inventory optimization should not face the same issues that have faced cost optimization with respect to variable estimation. Companies have specific service level and inventory goals that they can place into the system. However, while MEIO can certainly be thought to have an advantage over cost optimization in the determination of their input controls, once service levels are broken down into different product grouping it turns out companies run into complications developing these service levels as well.


The way costs are developed during implementation is not the way that cost optimizers were originally developed to be used. This is not to say that this method is wrong. However, when costs are developed in this way, in fact when any input is developed differently from how the software has assumed it would be developed, it should be understood and recognized in terms of the implications for the plan and for cost optimization generally. Currently, I don’t think these implications are widely understood.

Questions or Comments? 

Was this article clear? Do you have any experiences you would like to share regarding how you have seen costs set on cost optimization projects? If so comment below.

Socializing Supply Chain Optimization

What This Article Covers

  • What is the present general level of optimization socialization?
  • What are some of the main problems?
  • What is a good way to choose and optimization solver?
  • A sample optimization problem.

Background on Supply Chain Optimization

Inventory optimization is really the second major type of optimization to be implemented for supply planning. I work in inventory optimization; however, I also do a fair amount of work in SAP SNP’s optimizer, which is a cost optimizer. That is it attempts to minimize costs while meeting demand and respecting capacity constraints. Something that I find commonly between all the optimization projects I work on is that the optimizer is not sufficiently socialized within the company. This results in optimization that is considered a black box by the business and by executives. After having worked on another account where optimization was once again not understood by the business and where the results are continually overwritten by the planners, I thought I would write on the need to provide better education to clients, and how to better socialize optimization overall. My point to the optimization vendors and to consulting companies is this; the main limiting factor is no longer the technology. I run across various applications and am usually impressed with the technology and its ability to meet the business requirements of my clients. The factor limiting the uptake of optimization is the transparency of parameters and in the education on the part of vendors and consultants that work in optimization. I often come into projects after they are live and I am in a good position to evaluate the effectiveness of the education and knowledge transfer that took place prior to my visit. I interview the business, see how the system is being used in reality, and review the project and the training documentation. I can say confidently, that the job of education of clients on optimization is being done poorly.

Main Problems

One of the main issues that I see is that both vendors and consultants are not getting the business users at their clients a hands–on feel for what optimization is. I think this is greatly related to the limited number of tools that are used to explain optimization to clients. It seems there are really just two educational tools.

  1. One is PowerPoint, which explains optimization with boxes and arrows. Most the optimization PowerPoint decks just are not that effective. If I were managing an optimization vendor, I would contract with a company that specializes in technical education to get people who really know how to do this right. A few educational decks could be used repeatedly with different clients.
  2. The second education tool is the application itself. However, few optimization tools are themselves good education tools. Secondly, this is starting of a person new to optimization too quickly. Unless they are quantitative analysts people need to be eased into a new topic by starting from the basics. Production ready optimization tools are not the basics

Luckily, there are tons of tools to select from to begin to acclimate planners and even executives to how optimization works. As with anything else, we want to start at a basic level, listen gauge the group to make sure that everyone understands. If people begin leaving, the room or start checking email the moderator needs to take a few breaks and or give some one-on-one tutoring to make sure the group can go through as a block.

Using Excel to Teach Optimization

I have had good success explaining optimization using a few optimization scenarios in Excel. Excel is a great learning tool because while the number of people who can read scientific notation is very rare in groups of planners, everyone can read formulas in a spreadsheet. This makes me question the point of scientific notation, but I will save that tangent for a different post. Suffice it to say, people are generally comfortable with Excel, Excel has solvers that can be installed as add-ins (some of them free), and so it is a great learning tool. Secondly, since all users have Excel themselves, by simply walking the class through an installation of a solver on their machines, they can use the optimization scenario themselves in the class and outside the classroom as well. Real learning takes place when the user changes constraints and goals and sees the output. This is why I highly recommend that each user have a working solver on their computer and be able to work along with the moderator.

For details on format standardization in optimizer spreadsheets in order improve understanding, see this post.

Choosing a Solver

For this example, I am using the Frontline Solver for Excel. There are many solver plug-ins for Excel and I happen to like this one because it works with Mac as well as for PC. When using it I found this particular plug-in very easy to use, so I would recommend it, plus the basic version is free. Frontline offers a basic solver at no charge, and then sells a more advanced solver or pro version that they do charge around $900 for. This pro version can handle up to 2000 variables and a production type solver. I tip my hat to Frontline for offering a free basic version, which allows a person to cut their teeth on optimization without having to commit to buying a product. It also allows an unlimited number of users to download a basic solver for teaching without having to place an optimizer in the budget for short-term use.

A Sample Optimization Problem

Below I have setup a simple optimization scenario. This scenario asks the solver to resolve the following problem.

  1. Minimize the transportation dollars spent for 375 pounds of material.
  2. Respect the constraints for the minimum number of pounds to be shipped by truck, and the maximum number of pounds to be shipped by rail.
  3. Allocate material to the different modes (which move at different speeds) such that the average pound of material is moving at greater than or equal to 75 miles per hour.

Below is the initial view of the optimizer scenario. We start with the values that the optimizer will change, the pounds shipped, as set to “1,” next I will go through each of the values and describes how the optimizer will see each of them and use them to come to an optimal solution.

Next, we need to bring up the solver by selecting it from the Tools menu.


When the solver window comes up, we will setup the objective, the variables to be changed and the constraints. I find it useful to first name the cells so that the cell names show up in the Solver Parameters window. Having “TotalTransCost” in the window is far clearer than “C13.” I want the all of the screens to be as clear as possible so that the user can intuitively understand what is happening based upon their business experience. Later, when we get into adjusting parameters in the real model, I need complete clarity because ultimately, the business user must provide the right values for the parameters.

Here is our result below.

After the users are comfortable with this first example, I will make a change to the scenario. I will change the average speed to 85 miles per hour and rerun the optimizer.

The users will quickly notice that the optimizer moved roughly 10 pounds from the truck mode to the plane mode in order to meet the constraint of a higher average speed per pound. The users will also note that this decision cost an extra 78 dollars (roughly).


There are big opportunities to improve the education of clients on optimization projects. This education is in my estimation the number one reason many optimization projects either fail to meet their potential or simply fail. In addition to implementing the software, a big push must be made to educate everyone involved with the optimizer output. Since supply chain directors and vice presidents often issue policies on inventory management, this includes educating the executive decision makers. I have yet to find an account where the users or executive decision makers were educated up to their potential, and have been to a number of accounts where the business does not understand the solution at all. However, I have found good success in using simple tools to socialize optimization concepts. The example I have provided is just one of these. However, starting at the basics, and showing users and executives multiple optimization scenarios can rapidly increase their understanding of a topic that is unfamiliar to most. Vendors and consulting firms that follow a similar approach will greatly improve the success ratio of their projects, and improve the utilization of projects that are already considered successful.

Questions or Comments? 

Was this article clear? Do you have any experiences have you had with how supply chain optimization projects are performed? Have you seen it done well or done poorly? If you have information you think others might learn from please comment below.


SAP is About to Change Its Inventory Optimization Story

What This Article Covers

  • What has SAP’s story on inventory optimization been? 
  • What is SAP’s pattern with respect to partnering with vendors? 
  • Does SAP have a good chance at being good at inventory optimization and multi echelon? 


I was recently doing research on SAP’s APO Add-In related to inventory optimization. I was surprised to read what appeared to be the beginnings of an inventory optimization product in one of the add-ins. (I discuss the add-in in detail in this post.)

SAP’s Old Story on Inventory Optimization

I sat in a combined SmartOps and SAP presentation to a client over a year ago where SAP declared that it was not at the time and had no interest in developing an inventory optimization product in the future. However, its unmistakable from this documentation that SAP now has a “product” that can be added to APO to enable some type of inventory optimization functionality. What this means is that SAP is about to change its story on inventory optimization and is going to be a vendor in the MEIO space. This follows an algorithm that I have observed by SAP with respect to their software partnerships which I have traced back to the 1990s.

The steps are as follows:

  1. Initiate a partnership with companies that will accept their onerous terms
  2. Declare whoever they select as the best of breed (this is important, because their presentation of the quality of the selected vendor changes in later stages of this algorithm).
  3. Market a rudimentary adapter to the application, but make the partnering vendor do most the work and provide most the funding for this initiative.
  4. Declare no intent to develop a competitive product to the partner vendor and to prospects.
  5. Immediately begin developing a competitive product using inside information gleaned from the partner vendor. This is enabled by making the vendor sign a legal document declaring that the prospective partner must declare all IP to SAP, and anything undeclared to SAP is essentially free game to SAP to borrow.
  6. After a few years, sever the relationship and declare that the intent was always to have an “open” system that could connect to any best of breed application. Change the story regarding how good the one partner’s product is, now that an SAP competitive product exists. (I witnessed this 180 degree turn firsthand with MCA Solutions. At the beginning of the MCA Solutions-SAP relationship, SAP spoke of MCA in glowing terms as the best service parts planning applications on the market. However, after the relationship with MCA ended, SAP was extremely coy when discussing MCA, and declared that they always had built their adapter to any service parts planning application. They clearly wanted to change the topic of the conversation, and they wanted to minimize their previous partnership with MCA.)

Will SAP be a Force in Inventory Optimization?

This question has two components. The first is “Will SAP convince some clients to buy its MEIO product?” The answer here is undoubtedly yes. It will be part of the APO product, so after the product passes through its add-in stage (where it is charged for separately), it will eventually just become part of the APO suite and available to anyone who upgrades to the version of APO which has MEIO. SAP will have no problem getting consultants to invest time in learning it. As an APO consultant, I will readily invest in learning their MEIO as I frequently work in SNP, which is where SAP MEIO will be located.

The second component of the question is “Will SAP will ever build an effective and competitive MEIO product.” I would bet quite a lot of money against it. My reasoning falls into two categories, one being my exposure to the best of breed MEIO vendors, and the second being my direct experience with SAP in cost optimization. The best of breed MEIO vendors tend to be very knowledgeable and extremely passionate about both the technology and the desire to continually improve that technology. Secondly, the lesson from the history of SAP in cost optimization is indicative of where SAP will be in the future with MEIO.

The feedback I consistently receive from clients who use the SNP or PP/DS cost optimizer is that SAP provides no thought leadership on how to use their product. SAP, with all their resources, has really added very little value to cost optimization either in technology or in explaining how to use it since they added the cost optimizer to their product over ten years ago. The recent realization of this fact has given me the idea of creating a cost optimizer simulator to be used to simply provide some transparency into what the optimizer is doing, and to simulate changes in an external system rather than using SAP’s opaque and technologically flawed simulation versions in APO.


The fact that I any SAP optimization account I visit I find a poorly explained product speaks to the SAP’s capabilities with deep applications. However, MEIO is a deep application as well.

SAP’s Sweet Spot?

Cost optimization was never a good fit for SAP because it is requires deep subject matter expertise in a technical area of supply chain planning, and this is not their sweet spot. SAP’s sweet spot is proving basic technology in a way that is perceived as low risk by corporate IT buyers. SAP seems to hide their weakness of their understanding of cost optimization by either discussing the proprietary nature of their optimization (and thus details cannot be shared), or by saying that anything related to methodology is “client specific.” However, those arguments are ridiculous. SAP has a large number of cost optimization clients, especially if you include the cost optimization clients that quit the cost optimizer, however they do nothing to mine that database to explain what works and what does not work to their new clients. This experience with SAP in cost optimization applies to three different APO modules. These are SNP (supply planning), PP/DS (product planning), and TP/VP (transportation planning), all of which have cost optimizers. Because of this experience with the same approach shown in multiple APO modules with cost optimizers, I expect them to take the same approach to inventory optimization, with lots of talk about how all MEIO best practices are in the product, but then with very little explanation of how it works to their clients.

The Lack of Passion That Comes with Stenography

When a company copies a concept simply for market reasons to steer people away from best of breed solutions, it’s simply a defensive move for that company. I predict this same result for SAP in inventory optimization that occurred to SAP in cost optimization. They will get APO customers to adopt SAP MEIO, but will only in special cases, where the client requirements are very basic, will they be able to pull off the implementation. From the product management perspective, it will also divert development resources from the rest of SCM-APO, a set of ten modules that had such enormous scope creep that it requires years of concentrated development to bring the vast storehouse of functionality up to par. Some modules such as SPP and EWM require large development efforts to simply be made functional and capable of supporting an account in production. The SAP marketing machine has taken these unfinished products as far as they can go, now the code has to be completed. There is much more to say about this issue, but the long and short of it is that SAP already has its hands full with its planning products without venturing off again into virgin territory.


SAP’s story on MEIO is going to change in the future. The add-in discussed above is a start, but they will eventually have a MEIO “product.” My best guess is that it will be in the next version of SCM-APO. However, I am not sure on this, because I can’t determine SAP’s directions on add-ins as they are so new. Either way, it will be a significant event for the industry because with APO’s large installed base, and with so many companies with such a high preference for SAP products regardless of their objective rating in functionality, technology or usability comparisons, it will mean that many companies will now have access to MEIO technology in some form without going out to a best of breed solution. All of the major consulting companies will get solidly behind the product. This is because instead of with a best of breed application, they will be able to staff and control the project, which was one of their major concerns with MEIO and why they would recommend heuristics, allocation or cost optimization on many supply planning accounts that would be been more appropriate for MEIO. Gartner will begin to rate SAP MEIO higher than it should be, because of SAP pays more to Gartner every year than any of the best of breed vendors. For best of breed vendors, this will mean a smaller piece of the SAP market. It also means that the best of breed vendors will need to spend some time differentiating their product from SAP’s product. This should combine tightening up some of the messaging around specific benefits of their product in relationship to APO MEIO, which will mean understanding the SAP MEIO and gaining exposure to the product.

Questions or Comments? 

Was this article clear? If you have any questions please comment below.

Why Safety Stock Is Not The Focus of Inventory Optimization

What This Article Covers

  • How is safety stock set in practice?
  • What is the Target Stocking Level?
  • What is the relationship between safety stock and inventory optimization and multi echelon planning software?

Background on Safety Stock 

I have always found the many supply chain professionals and executives have been far too focused on safety stock. Safety stock is just that, the stock that is carried to deal with unforeseen events. However, it could just as easily be called variability stock, or the stock that is held in order to account for variability in the supply chain. The exact formula is listed in this article. However, for the purposes of this article, it’s simply important to consider that safety stock is the component of the total stocking level which is designed to account for variability in supply and demand.

The best way to think of safety stock is that at a high level it has three inputs:

Safety Stock = Initial Stocking Level + Supply Variability + Demand Variability

How Safety Stock is Set In Practice

Safety stock can be calculated with a safety stock formula, which adjusts with changes in the variability in supply and demand, which is called dynamic safety stock. It can also be set manually, also safety stock can be calculated inside of the ERP or planning system, or externally and imported (hard-coded) into the system. Most companies do not have dynamic safety stock enabled and safety stock is normally updated manually  with a variety of calculation techniques. The end result of this is that most companies are not taking advantage of their system’s ability (regardless of the supply planning method employed or the particular vendor) to auto-adjust safety stock. This places an extra load on the supply planning organization because it is another parameter which must be actively managed.

Accounting for Variability in Non MEIO Applications

Unknown to a large contingent of companies that are running the older supply planning methods (MRP/DRP, Heuristic, Cost Optimization and Allocation), safety stock is the only factor which accounts for variability in the supply chain.  It is also the only place where service level is accounted for, for three of the four methods of supply planning listed above. (MRP/DRP, Heuristic and Allocation). Cost optimization can account for service goals, but only in an indirect manner. A cost optimizer by comparison has only the ability to set the service component based upon penalty costs, which is described in this post. This is a much more blunt instrument for connecting the service level to the language that the optimizer understands. This is because the penalty cost only has meaning to the cost optimizer in relation to other costs that are included in the system. This is a major weakness of cost optimization systems. In fact, the best way for a company to proceed in determining if cost optimization is the best choice for them is to first internally agree on all the costs that will drive the optimizer. If they cannot internally drive to this agreement, then cost optimization is not a good choice for them, even if their main supply chain objective is to minimize costs. This addresses an issue which is often missed. A method selected must not only be the right fit for the business requirements, but must also fit with the company’s ability to implemented the selected method. (The TSL is described in the post.)

However, inventory optimization and multi echelon (MEIO) have a superior approach to setting the stocking level which is still not widely understood, at least from my personal consulting experience. MEIO applications can at a very fine level of detail set stocking levels based upon service levels that are applied at either the most disaggregated (product location) or at higher levels of aggregation, depending of course on the particular vendor selected.

Target Stock Level and Safety Stock in MEIO Applications

MEIO systems also have and calculate safety stock. However, they have the ability to set the target stock level or TSL at the most accurate and sophisticated way that is currently available in software. This class of application uses the service level to set both the safety stock and the TSL.  The way inventory optimization calculates safety stock is in most cases identical to the safety stock functionality with heuristic or cost based optimization supply planning application calculates safety stock. The main functionality in inventory optimization goes towards calculation of the initial stocking level or TSL.

Understanding the Distinction between Target Stocking Level and Safety Stock

When I have the conversation regarding MEIO and its relationship to safety stock, the person I am speaking with will sometimes propose that he or she agrees with me in principle, but then will add, “However, inventory optimization does improve safety stock.” To simply correlate the two is to miss the point of inventory optimization. Inventory optimization is bigger than safety stock. Dynamic safety stock is a simple calculation that is performed at a product-location combination, while inventory optimization is a set of mathematics that encompasses the entire supply network and meets service level targets by distributing inventory to every product location optimally. It’s the difference between a formula that can be calculated in a single cell of a spreadsheet (safety stock) and a set of mathematics so complex that few people understand what it does. That’s why it is incorrect to say that inventory optimization is focused on safety stock. While safety stock does not need be optimized, it should always be dynamic—that is, it should flex with the variability in supply and demand. Therefore, inventory optimization and safety stock are independent from one another. A company can implement dynamic safety stock without implementing inventory optimization, and vice versa.

The Right Focus

Safety stock is important, but it should never be the main focus within the supply planning organization. It should be auto-calculated and left to the system to control. If it isn’t, and if the supply planning organization is spending much time discussing its safety stock, then it is wasting time because the formula for dynamic safety stock is correct and extensively tested. What is to be questioned is the quality of the lead time variability or demand variability, which the dynamic safety stock formula uses to calculate safety stock. However, these are questions related to improving the inputs to the formula, which is a different topic. Instead target stocking levels should be the focus. MEIO applications allow a direct control over the TSL because the objective function of the optimizer is to minimize inventory vs. service level, or to maximize service level based upon inventory.

Questions or Comments? 

Was this article clear? Do you have a different viewpoint? If you have any questions please comment below.

Service Level Setting vs. Penalty Costs in a Cost Optimizer

What This Article Covers 

  • What is a penalty cost in a cost optimizer? 
  • Do costs optimizers generally speak the same language as the business? 
  • What advantage does inventory optimization and multi echelon planning have in this area? 


I am sometimes work with companies that have implemented cost optimization software. However, when you discuss the most important factor to executives, they tell you it is service level. This is interesting, because cost optimization is for companies who’s most important goal is minimizing the costs of the supply plan. Something else which surprises some clients I have worked with is that cost optimization only understands costs. This means that everything must be converted to costs so that the optimizer can work with it and make trade offs. For instance, if transportation costs are set high in relation to other costs such as storage costs, the model will tend to move items less than if the opposite were true. In terms of meeting a specific service level, cost optimization cannot do this because it inherently does not understand what a service level is. Instead it has the concept of a penalty cost for a lost sale. Since all costs in a cost optimizer only makes sense in relation to one another, the company must develop a penalty cost for a lost sale that relates appropriately, in terms of how that company values the lost sale to say the cost of violating safety stock. However, what is that cost? It is very difficult to know. It’s not simply the lost profit of the product, because there are other considerations such as the reputation of the company in the customer’s mind. There are competitive concerns, etc.. Getting to a solid penalty cost number is extremely challenging, and the company can never be sure of the relationship between this number and the service level. Secondly, lost sale cost penalty is simply a convenient way to get the optimizer to consider a concept of service and is not a term not often used by the business. Therefore, cost optimizers are essentially speaking a different language from the business, which is not a good thing.

Inventory Optimization Does Inherently Understand Service Levels

Service levels on the other hand are much more concrete, and easier to add into a model. Of course perhaps I should say, they can be. Often the company itself has only a loose understanding of the relationship between service levels and costs, which is why so many unattainable service level goals exist within companies. When a company adopts a MEIO application, it changes the method of managing service levels. This is because without MEIO, the company was previously setting its inventory levels and its service levels in an arbitrary way. This arbitrariness often takes the form of overly high stated service level levels, which are not actually met, and if met would cost the company too much to meet. A MEIO application can cut through the confusion between service levels and inventory costs by making the relationship clear and thus improving the way companies set this metric.


Cost optimization could benefit from being better explained by both cost optimization vendors and consulting firms to their clients. Currently the methodology seems to be to simply put all the responsibility of setting costs on the business, however without fully explaining the implications of these costs in the optimizer. Subsequent attempts to tune the optimizer can often result in costs being changed, but without understanding how the new costs relate to the other costs that have been entered. Therefore, a large percentage of the problems of previous cost optimization implementations can be laid at the door of the methodology that was used on these projects. I have concluded that an external cost optimizer simulation model should be used to provide better transparency to the cost optimization logic. This is explained in this post.


This can show the business, with a smaller and more manageable data set and model than a full production model, how the model changes its output as costs are changed, and it can do so in an interactive environment. Therefore, the business can see a simulator change its costs while having the screen projected for them, and by being able to interact with the application engineer in real-time.


Was this article clear? Do you have any experiences in cost setting in an optimizer? If so comment below.

1 2 3 6