How to Understand Redeployment for Slow Moving Inventory

Executive Summary

  • Redeployment is a planning thread that repositions inventory to locations where it has a higher likelihood of being consumed.
  • Redeployment applies to more to slow-moving inventor and can be considered a form of inventory analysis and a way of reducing obsolete inventory.
  • Redeployment differs by product type.

Introduction to Redeployment

Redeployement is the least used, but still quite important supply planning runs. You will learn the reason for redeployment and how rededployment can be activated.

What is Redeployment?

Redeployment is the redistribution of stock that is already in a forward location in the supply network at an inventory position to another forward location or back to the parent location. I can also be called inventory re-balancing and sometimes inventory repositioning, and is the least well known of the major supply planning threads.

To understand redeployment, it is helpful to contrast it to normal deployment. 

normal-deployment

The deployment follows a rigid flow of parent to children locations which is primarily designed to minimize logistics costs.

redployment

Redeployment is quite different because it means that the normal parent-child valid location-to-location relationships are in 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 transferred to a new 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 transferred to a new location.

Redeployment as a Type of Inventory Analysis

Redeployment can be considered a type of inventory analysis because it means analyzing the inventory position in the system and making a determination which inventory should be moved where. Almost all companies end up with an inventory position which they would like to alter. Companies have people and groups that perform inventory analysis to determining

The most common types of inventory that falls into the redeployment category are slow moving inventory and obsolete inventory.

Slow Moving Inventory

Slow moving inventory is difficult to forecast, and the average inventory position of slow moving inventory is normally high versus its demand. In some cases, slow moving inventory should not be held at a particular location. In other cases, such as with service parts there may be no alternative because the inventory must be carried at a location to meet service goals.

Slow moving inventory is managed best when it can be “pooled.” This can mean that the slow moving inventory is aggregated to the larger distribution centers. Another way of pooling is through redeployment. Redeployment allows all the inventory in the network to be shared, but at the price of movement.

Slow moving inventory is increasingly being carried due to product proliferation. That is slow moving inventory is in many cases driven by marketing’s desire to have high numbers of SKUs. As this trend sees no sign of abating, redeploying slow moving inventory should be of rising interest to companies.

Obsolete Inventory

Companies have people and groups that perform inventory analysis to determining obsolete stock or obsolete inventory. Inventory obsolescence has several causes.

  • One is product specific. That is the product only sellable (for its normal price or sometimes for any prices) for a period, and so the stock becomes obsolete when it does not sell at this time. But also a primary reason why an obsolete stock or obsolete inventory “goes bad” is because the inventory position is not transferred to a location where it can be consumed. In

Apparently, if the stock can eventually be sold without requiring its movement, then it may make sense to keep it at the present location. Inventory obsolescence is a primary driver for redeployment, as it can mean the company writing off the obsolete stock for nothing or some small fraction of its average sales price.

Slow Moving Inventory and Obsolete Stock

In some cases, the soon to be obsolete stock is not moved because the inventory analysis is not performed. In other cases the soon to be obsolete inventory is not transferred to a location where it has a higher probability of being consumed is because doing so would violate the company’s transportation budget cap. It is often the case that even though a mathematical inventory analysis can demonstrate an inventory position has a lower likelihood of becoming inventory obsolescence and would earn the company more money; the decision to reposition the stock is still not made. I have been surprised to see how politically complicated it becomes to move stock that has a high likelihood of inventory obsolescence. But also, most companies are still not familiar with software that could automate the inventory obsolescence analysis and stock redeployment inventory analysis.

Factors Applied for Redeployment Analysis

In this inventory analysis, one applies various factors such as:

  • The forecast for the item at different locations.
  • The current stock level and inventory position for an item at all the locations it is stocked (if the analysis is run open)
  • The service level target at the different locations for the item.
  • The cost of carrying the item.
  • The transportation cost to move the item.

Another factor reinforcing the fact that redeployment is an inventory analysis is that many companies perform this redeployment as a stock analysis. That is without using any specialized software at all to determine what stock should be repositioned. In fact, there are few useful applications on the market for performing redeployment.

Different Redeployment for Different Products

Redeployment is an overlooked supply planning functionality on the part of non-MEIO software companies. 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 rationale at a later date. This is not only a matter of simply waiting and taking more inventory costs. The material 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. Other items like paint can be re-manufactured and can be sold as entirely different colors (possibly a better selling color) This can mean moving the product from its inventory position twice.

  • One to move it back to a manufacturing facility.
  • Then moved a second time 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 to redeploy their current inventory position, because as he put it:

What if they had to redeploy it yet again?

However, there is nothing to say that the initial deployment and the current stock position is correct or as it should be.

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 Redeployment Compares Across the Various Supply Planning Methods

Redeployment is one of the strongest areas of functionality for MEIO vendors. It is correspondingly one of the weakest areas of functionality in all other supply planning methods which are.

  • MRP/DRP
  • Heuristics
  • Order Allocation
  • Cost Optimization

Sometimes those with little understanding of redeployment, but with a financial bias to utilize some specific cost optimizing supply planning application, will propose using a cost optimizer 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 designed for redeployment. Companies that attempt to use cost optimizers for redeployment will normally run into great limitations.

This a greatly underemphasized area of supply planning software development. Every client I have consulted with needs redeployment. The lack of enterprise software solutions is why this is a common area for custom development.

The History of Redeployment and Inventory Analysis

The original work on inventory optimization and multi echelon planning was developed for service parts network which needs 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 paying for the research), and their airplane service network.

Conclusion

Redeployment is very far down on the list of most companies. That is unfortunate because it should not be and the opportunity to reduce inventory obsolescence, to reduce inventory holding cost and increase revenues is certainly there.

Service parts planning inventory optimization and multi echelon software companies have the strongest redeployment functionality.

In addition to having the functionality built-in, vendors have an advantage conceptually over non-inventory optimization and multi echelon vendors in redistribution. This is because of the traditional logic of deployment, which non-inventory optimization and multi echelon vendors attempt to use for redeployment 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.

Search Our Other Supply Chain Optimization Content

References

MEIO Book

What is MEIO?

This book explains the emerging technology of inventory optimization and multi-echelon (MEIO) supply planning. The book takes a complex subject and effectively communicates what MEIO is about in plain English terms. This is the only book currently available that describes MEIO for practitioners, rather for mathematicians or academics.

The Interaction with Service Levels

The this book explains how inventory optimization allows the entire supply plan to be controlled with service levels, and how multi-echelon technology answers the question of where to locate inventory in the supply network.
This is the only book on inventory optimization and multi echelon planning which compares how different best of breed vendors apply MEIO technology to their products. It also explains why this technology is so important for supply planning and why companies should be actively investigating this method.
The book moves smoothly between concepts to screen shots and descriptions of how the screens are configured and used. This provides the reader with some of the most intriguing areas of functionality within a variety of applications.
Chapters
  • Chapter 1: Introduction
  • Chapter 2: Where Inventory Optimization and Multi-Echelon Planning
  • Fit within the Supply Chain Planning Footprint
  • Chapter 3: Inventory Optimization Explained
  • Chapter 4: Multi-Echelon Planning Explained
  • Chapter 5: How Inventory Optimization and Multi-Echelon Work
  • Together to Optimize the Supply Plan
  • Chapter 6: MEIO Versus Cost Optimization
  • Chapter 7: MEIO and Simulation
  • Chapter 8: MEIO and Service Level Agreements
  • Chapter 9: How MEIO is Different from APS and MRP/DRP
  • Chapter 10: Conclusion
  • References
  • Vendor Acknowledgements and Profiles
  • Author Profile
  • Abbreviations
  • Links in the Book
  • Appendix A: MEIO Visibility and Analytics
  • Appendix B: The History of Development of MEIO Versus MRP/DRP

Why SAP is About to Change Its Inventory Optimization Story

Executive Summary

  • SAP has provided a misleading story on inventory optimization.
  • SAP has a specific extractive pattern when partnering with vendors.
  • We predict if SAP has a good chance of being good at inventory optimization and multi echelon planning.

Introduction to APO Inventory Optimization

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.

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 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 on their software partnerships which I have traced back to the 1990s.

Steps

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 of 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 of the funding for this initiative.
  4. Declare no intent to develop a competitive product to the partner vendor and 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 substantially 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 a 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 remarkably coy when discussing MCA, and declared that they always had built their adapter to any service parts planning application. They 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 undoubted 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 efficient 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.

What the Information From Customers Tells Us

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 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 provide some transparency into what the optimizer is doing and simulating 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 an in-depth application as well.

SAP’s Sweet Spot?

Cost optimization was never a good fit for SAP because it 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 the 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 customers.

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 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 fundamental, 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 substantial 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.

Conclusion

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 about 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 businesses 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 more appropriate for MEIO. Gartner will begin to rate SAP MEIO higher than it should be, because of SAP 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.

Search Our Other Supply Chain Optimization Content

Brightwork Explorer for Service Level & Stock Management

Faster and More Straightforward Approach than Inventory Optimization

Inventory optimization started with a bang but failed to live up to the hype that was built up for it. Inventory optimization software is normally overly complex and while the idea is right, successes with inventory optimization are rare.

After seeing many failed inventory optimization projects we developed a simpler and less invasive way of modeling service levels and inventory. The Brightwork Explorer is free to access until it sees “serious usage” and is free for academics and students. Select the image below for more details.

References

MEIO Book

What is MEIO?

This book explains the emerging technology of inventory optimization and multi-echelon (MEIO) supply planning. The book takes a complex subject and effectively communicates what MEIO is about in plain English terms. This is the only book currently available that describes MEIO for practitioners, rather for mathematicians or academics.

The Interaction with Service Levels

The this book explains how inventory optimization allows the entire supply plan to be controlled with service levels, and how multi-echelon technology answers the question of where to locate inventory in the supply network.
This is the only book on inventory optimization and multi echelon planning which compares how different best of breed vendors apply MEIO technology to their products. It also explains why this technology is so important for supply planning and why companies should be actively investigating this method.
The book moves smoothly between concepts to screen shots and descriptions of how the screens are configured and used. This provides the reader with some of the most intriguing areas of functionality within a variety of applications.
Chapters
  • Chapter 1: Introduction
  • Chapter 2: Where Inventory Optimization and Multi-Echelon Planning
  • Fit within the Supply Chain Planning Footprint
  • Chapter 3: Inventory Optimization Explained
  • Chapter 4: Multi-Echelon Planning Explained
  • Chapter 5: How Inventory Optimization and Multi-Echelon Work
  • Together to Optimize the Supply Plan
  • Chapter 6: MEIO Versus Cost Optimization
  • Chapter 7: MEIO and Simulation
  • Chapter 8: MEIO and Service Level Agreements
  • Chapter 9: How MEIO is Different from APS and MRP/DRP
  • Chapter 10: Conclusion
  • References
  • Vendor Acknowledgements and Profiles
  • Author Profile
  • Abbreviations
  • Links in the Book
  • Appendix A: MEIO Visibility and Analytics
  • Appendix B: The History of Development of MEIO Versus MRP/DRP

Why Target Stock Level Not Safety Inventory is the Right Focus

Executive Summary

  • Safety stock is set in practice far differently than how it is explained in books.
  • To understand safety stock it is helpful to consider the target stock level.
  • Safety stock, target stock level is connected to inventory optimization and multi echelon.

Introduction

Safety inventory or safety stock is widely misunderstood and with many problems in setting the value logically. You will learn how it is set and the relationship to the target stocking level.

Overfocus on Safety Inventory

I have always found the many supply chain professionals and executives have been far too focused on safety inventory. Safety inventory is just that, the inventory that is carried to deal with unforeseen events. It could just as easily be called variability stock, or the stock that is held to account for variability in the supply chain. The exact formula is listed in this article. However, for this article, it’s merely necessary 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 Inventory is Often Set In Practice

Safety inventory can be calculated with a safety inventory formula, which adjusts with changes in the variability of 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 inventory enabled, and safety stock is usually updated manually with a variety of calculation techniques.

The 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 that must be actively managed.

Accounting for Variability in Non Inventory Optimization Supply Planning Applications

Unknown to a large contingent of companies that are running the older supply planning methods (MRP/DRP, Heuristic, Cost Optimization and Allocation), safety inventory is the only factor that accounts for variability in the supply chain from the inventory perspective.  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. 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 to mean to the cost optimizer about 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 primary supply chain objective is to minimize costs. This addresses an issue that 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 chosen method.

Inventory optimization and multi-echelon (MEIO) have a superior approach to setting the target stock level which is still not widely understood. MEIO applications can at a very fine level of detail set the target stock level based upon service levels that are applied at either the most disaggregated (product location) or 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 the software. This class of application uses the service level to set both the safety stock and the target stock level.

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 the calculation of the initial stocking level or target stock level.

TSLorSS

Understanding the Distinction between Target Stock Level and Safety Stock

When I have the conversation regarding MEIO and its relationship to safety inventory, 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 to 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 of one another. A company can implement dynamic safety stock without implementing inventory optimization, and vice versa.

The Right Focus

  • Safety inventory is critical, but it should never be the primary 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 inventory. These are questions related to improving the inputs to the formula, which is a different topic. Instead, target stock levels at a product location should be the focus.

MEIO applications allow 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.

Search Our Other Supply Chain Optimization Content

Brightwork Explorer for Service Level & Stock Management

Faster and More Straightforward Approach than Inventory Optimization

Inventory optimization started with a bang but failed to live up to the hype that was built up for it. Inventory optimization software is normally overly complex and while the idea is right, successes with inventory optimization are rare.

After seeing many failed inventory optimization projects we developed a simpler and less invasive way of modeling service levels and inventory. The Brightwork Explorer is free to access until it sees “serious usage” and is free for academics and students. Select the image below for more details.

References

MEIO Book

What is MEIO?

This book explains the emerging technology of inventory optimization and multi-echelon (MEIO) supply planning. The book takes a complex subject and effectively communicates what MEIO is about in plain English terms. This is the only book currently available that describes MEIO for practitioners, rather for mathematicians or academics.

The Interaction with Service Levels

The this book explains how inventory optimization allows the entire supply plan to be controlled with service levels, and how multi-echelon technology answers the question of where to locate inventory in the supply network.
This is the only book on inventory optimization and multi echelon planning which compares how different best of breed vendors apply MEIO technology to their products. It also explains why this technology is so important for supply planning and why companies should be actively investigating this method.
The book moves smoothly between concepts to screen shots and descriptions of how the screens are configured and used. This provides the reader with some of the most intriguing areas of functionality within a variety of applications.
Chapters
  • Chapter 1: Introduction
  • Chapter 2: Where Inventory Optimization and Multi-Echelon Planning
  • Fit within the Supply Chain Planning Footprint
  • Chapter 3: Inventory Optimization Explained
  • Chapter 4: Multi-Echelon Planning Explained
  • Chapter 5: How Inventory Optimization and Multi-Echelon Work
  • Together to Optimize the Supply Plan
  • Chapter 6: MEIO Versus Cost Optimization
  • Chapter 7: MEIO and Simulation
  • Chapter 8: MEIO and Service Level Agreements
  • Chapter 9: How MEIO is Different from APS and MRP/DRP
  • Chapter 10: Conclusion
  • References
  • Vendor Acknowledgements and Profiles
  • Author Profile
  • Abbreviations
  • Links in the Book
  • Appendix A: MEIO Visibility and Analytics
  • Appendix B: The History of Development of MEIO Versus MRP/DRP

How to Understand Segmentation vs Inventory Optimization

Executive Summary

  • Supply chain segmentation is a method of inventory classification.
  • Supply chain segmentation is employed in niche supply chain vendors.

Introduction to Segmentation

Segmentation is a method of dividing the product location database. In this aricle, you will learn how segmentation compares to inventory optimization.

What is Inventory Optimization

There are some problems in the inventory optimization space relating to what is being communicated to potential clients.

One issue relates to what is claimed to be inventory optimization and what is not.

This is because some vendors that perform product database segmentation, calling their solutions inventory optimization. This is a problem for the following reasons:

  1. Segmentation has many benefits, which happen to be different from inventory optimization. By calling the software inventory optimization, segmentation will not become known in its right.
  2. Buyers, already confused, will end up further confused.
  3. Segmentation is not the same thing as inventory optimization.

What is Supply Chain Segmentation?

Supply Chain Segmentation is a method of selecting portions of the product database and applying changes to its control parameters.

  • For instance, one could select all SKU-Locations or product locations that are above a certain number of inventory turns per year and apply on economic order quantity to them.
  • The ability of Supply Chain Segmentation is critical because it allows planners to more efficiently control their products, and because it is a very direct method of filtering and control.

Along with filtering capability comes an ability to report on the products within the planning system. By performing filtration on different characteristics, the planner can gain a better appreciation and understanding for their products overall. It can fulfill many of the master data maintenance of the planning system.

Supply Chain Segmentation Versus Classification of Inventory

Supply Chain Segmentation should not be confused with the classification of inventory. Classification of inventory places inventory into categories such as A, B, C. Supply Chain Segmentation is about the categorization of product locations for treating them differently with the application different inventory parameters (lot size, reorder point, etc.) and even different supply planning or forecasting methods.

How Is This Segmentation Different From Inventory Optimization?

Inventory optimization is the ability to derive stocking levels from service levels. The definition continues to be a problem regarding being understood by prospective buyers. There are some reasons for this. Several vendors have confused its meaning through directly hijacking the term to be trendy, while many consultants have overused the term, and in fact, do not know themselves the term’s actual definition.

The more flexible and abstract the setting of the service level is, the more powerful the inventory optimization software can be considered to be. The lowest level of inventory optimization is at the product location, and the highest is the customer. However, not every customer wants, needs or is capable of managing their service levels by the client. Thus MEIO software selection is only partially about the level of the service level specificity of the application.

Supply Chain Segmentation, on the other hand, is about parameter control functionality, and an entirely different category of software from inventory optimization. For instance, the ability to apply a particular inventory parameter to a segment of the product database should not even be on the list of selection criteria for inventory optimization. However, it would be central to the selection of segmentation software.

Discerning the Difference Between Inventory Optimization and Supply Chain Segmentation

It is important to have questions ready when interviewing different vendors. The questions below can help prospective clients to understand what type of software they are dealing with in this space.

  1. Is this product segmentation or inventory optimization software?
  2. Where can the service level be set in the application (i.e. product/location, customer, location)?
  3. What specifically is being optimized?

Forecast-ability of the Product Location Combination

One of the first places to start is with the forecast-ability of the product location combination or PLC. Forecast-ability is a measure of how predictive the selected forecast model is. This is often presented within forecast systems as the fitted R-Square. Applications can sometimes provide the fitted R-Square for not only the individual PLC.

They can also do this for the complete product database — or a weighed PLC value. Variability factors can be used to determine the forecast-ability of a PLC with a formula as is explained in this article.
Forecast Error Assignment A PLC can then be coded for whether it is forecast-able. If it is forecast-able, this leads to another set of questions, and if it is not forecast-able, this leads to a different set of questions. To help people follow this conditional logic, it is programmed in the calculation form below. Try switching the first drop down between forecast-able and unforecast-able to see how the rest of the calculation form changes. 

Forecast Model Used

For the PLCs that are not assigned a level forecast, the forecast model that is assigned should be part of the PLC coding. In the calculation form below,  this selection is available.

Master Data Review Cycle

As explained earlier, the PLCs must be reviewed and updated on a periodic cycle. PLCs differ with their review. Before computers were available, PLCs were placed on a review cycle. This review cycle was for actually calculating order quantities.

A review cycle might look something like this:

  • Products 11234 to 11500 – 2nd Monday of the Month
  • Products 11500 to 1534 – 2nd Tuesday of the Month

Computers did not compute the order quantities; this was something that had to be performed my inventory analysts. When computers did arrive, software vendors began touting their “perpetual inventory” abilities.

This meant that when a goods receipt was recorded, the inventory was immediately recalculated.

  • This also allowed companies to carry less inventory. Before computers, safety stock had to cover not only variability in lead time and forecasts but also the longer period between reviews. In a computerized system, if a larger than forecasted order comes in, it may reduce the planned stock below the reorder point. The instantaneous calculation will cause a new order to be generated.
  • In a manual periodic review system, that product may need to wait until it was recalculated by an inventory analyst. That is unless the analysts reviewed the large orders and then recalculated just those PLCs ahead of the rest of the PLCs in their rotation.

The book Decision Systems for Inventory Management and Production Planning proposes an advantage to periodic review and periodic ordering.

“Items may be produced on the same piece of equipment, purchased from the same supplier, or shipped in the same transportation mode. In any of these situations coordination of replenishment may be attractive. In such a case periodic review is particularly appealing in that all items in a coordinated group can be given the same review interval. In contrast, under continuous review a replenishment decision can be made at practically any moment in time, hence the load is less predictable. A rhythmic, rather than random pattern is usually more appealing to the staff.”

This master data review cycle concept is the same concept as was applied previously to inventory management. Of course, a lot less work because this review cycle is for setting master data — and prevents the settings from falling out of date.

This is also important because master data is often changed in reaction to short-term needs. But is often not changed back.

What is Forecastability?

The first thing to understand is that the term forecastable does not refer to whether an item will or will not be forecasted. Rather the term applies to whether it makes sense to add extra effort to performing forecasting.

Forecastability is a measurement of how much likely benefit can be obtained by putting forecasting resources into a forecasted item. The measurement of forecastability moves the forecasted items into three potential categories. I quote from the book Supply Chain Forecasting Software.

“Many of the products that I have analyzed over the years from different companies are clearly unforecastable. There is a simple reason for this. Many difficult to forecast products have no discernable pattern in their demand history, and without this, no mathematical algorithm can create a good forecast. This is not generally understood. I believe that part of the reason misallocate effort on very hard to forecast products is due to a misimpression about when statistical forecasting can add value, and when it can’t.

Most companies actively increase the intermittency of their demand and reduce its forecastability by doing things like creating promotions and instituting end of quarter sales “pushes.” Customers respond to these behaviors by further batching their demand. It is well known that eventually customers become habituated to end of quarter price reductions, and postpone their buying in anticipation of the end of quarter. These are just a few examples, but there are a host of programs often initiated by companies, which make demand less forecastable than it ordinarily would be if natural or true demand were received.”

The testing for forecastability does not mean those elements that are declared as tough to forecast will not still receive a forecast.

The Question to Ask Regarding Forecastability

One of the first questions to ask is whether there is value to actively generating a forecast. In some cases, the answer is no. However, instead of recognizing that a product is not forecastable and adjusting to this reality, more sophisticated mathematics are often employed in a vain attempt to improve the forecast. Clients I have worked for in the past have adopted this philosophy, as have the majority of consultants and vendors I have worked with, and this philosophy is also reflected in forecasting academic papers I have read. Since so many well-educated people agree on this thinking, it must be correct—right? Well, actually they don’t all agree.

A number of academics have written on the concept of unforecastable products, but for some reason, their research does not seem to get sampled and disseminated. However, the scholarly literature is not objectively sampled. In fact, most consultants in don’t read it at all. Proven approaches like turning off forecasting for unforecastable products leads to short, and insufficiently lucrative consulting engagements.

Success Through Using More Sophisticated Forecasting Models/Mathematics for Poor Demand Histories?

However, there is little evidence that sophisticated mathematics can improve the forecast of difficult-to-forecast products, and this is a problem. Some studies do not show improvement from more advanced methods. But first, the improvement is never very large, and secondly, other studies come by later to contradict the original studies.

In addition, complex methods should have to exceed a higher bar. Academics can apply complex methods in a laboratory environment over a few products far more easily than can be done by industry. This fact, along with the point that sophisticated methods are much more expensive for industry to implement than simple methods, is rarely mentioned.

This point is made very well by J. Scott Armstrong:

“Use simple methods unless a strong case can be made for complexity. One of the most enduring and useful conclusions from research on forecasting is that simple methods are generally as accurate as complex methods. Evidence relevant to the issue of simplicity comes from studies of judgment (Armstrong 1985), extrapolation (Armstrong 1984, Makridakis et al. 1982, and Schnaars 1984), and econometric methods (Allen and Fildes 2001). Simplicity also aids decision makers’ understanding and implementation, reduces the likelihood of mistakes, and is less expensive.”

The Inconvenient Truth About Statistical Forecasting

For statistical forecasting, the only products that can be forecasted are those that have a discernible pattern to their demand history, and not all products have this pattern. Forecastability can usually be determined—or at least indicated—without any math by simply observing a line graph of a product’s three-year demand history. If there is no discernible pattern, it is unlikely that the product is forecastable with mathematical methods. (Products that are using just the last few periods to create a forecast are the exception to this rule.) An algorithm that can appear to be predictive can be built for unforecastable products, but more often than not this is an illusion created by the forecaster who over-fitted the forecast.

As is pointed out by Michael Gilliland, just because a model can be built to match the past, does not mean it should be used to perform forecasting:

“The statistical approach is based on the assumption that there is a structure or pattern in the behavior we are trying to forecast. As human beings, we are very good at finding structure and pattern in the world around us—even when none exists. Clouds look like poodles, a burnt cheese sandwich reveals the Virgin Mary, and an ant’s innocent meandering in the sand caricatures of Winston Churchill. We readily come up with lucid explanations of the ups and downs of the stock market and of demand for our products and services. Unfortunately, the patterns we see may not be real, and even if they are, we have no assurance they will continue into the future.”

Stable Product Forecasting

Products that have a very stable history exist at the other end of the continuum of forecast difficulty. Typically, it is very easy to forecast for products with a stable demand history; however, if this is the case, actively forecasting the product does not add very much value to supply planning (the ultimate consumer of the demand plan) because a product with stable demand history does not need to be forecasted. Products with stable demand can be managed effectively and efficiently with reorder point logic, where orders are based upon a reorder point or a reorder period. Very stable and very unstable products converge in their forecasting approach, as is evidenced by the fact that a many-period moving average is equally useful for products with both a stable demand history and products with an unstable demand history.

When both stable and unstable demand history products are run through a best-fit forecasting procedure, the normal result is that both will be fitted with a stable or level forecast. Companies have a very strong tendency to actively forecast all items in their product database without first asking the following question:

“What is the value added by forecasting for the different product categories?”

The Rule of Thumb

The rule of thumb is simple:

“A forecast adds value to the supply planning process when the demand planning system is creating a forecast for a product for which there is a discernible pattern for demand and if the forecast is not simply a constant or relatively constant value.”

Creating forecasts for the entire product database for S&OP forecasting or for other purposes may be important and necessary. However, the forecasting process that results in a demand plan being sent to supply planning can be segregated based on the rule of the value added to supply planning.

What is Being Tested?

The concept behind this test is that for product location combinations with sufficiently intermittent demand, it is not useful or value-add for companies to be forecasting them. For a title to be forecastable, there must be some discernible pattern.

Without a pattern, the best that any forecasting engine can do is create a level forecast which only averages the previous demand volumes. The issue of the diminishing marginal utility to forecasts was brought up by George Plossl in his book Production and Inventory Control over twenty-five years ago.

“The present rational approach recognizes that forecasts will always be subject to error and that, while there are tools available to improve the art of forecasting, the amount of money and effort put into applying such tools rapidly reaches a point of diminishing return. Beyond this point, it is far more profitable to develop flexibility to cope with forecast inaccuracy instead of trying to improve forecasts. The best solution is to develop a formal forecasting program and a system that detects and measures forecast errors and then to react quickly to correct for such errors. This solution is covered in this chapter in detail.” – George Plossl

Forecasts Being Generated at a Sufficient Level of Accuracy

At the point where forecasts cannot be generated with a sufficient accuracy level, it no longer makes sense to forecast the item, and instead, it is recommended that the item is removed from the forecasting system and be managed purely with consumption logic in the ERP system. It is not always the case that these items should move towards consumptive logic, but it is often the case. This is an extremely rarely made recommendation, so I have this method thoroughly explained here.

When to Switch to Reorder Point Planning

Reorder point planning is activated by populating product location fields in either SAP ERP’s Material Master, in SAP SNP’s Product Location Master, or in the material object in any supply planning engine. Sometimes people will say something like “reorder point with forecasts,” however a reorder point is a method used without projections.

The APO or ERP Formula

The determination of whether a product will be exclusively kept in APO, or kept both in APO and in SAP ERP can be determined by a formula which will run off of several key measurements that can be obtained from the statistical export file from a forecasting environment.

The Forecastable or Unforecastable Formula

The formula I have developed is listed below. It certainly is not be used in a pure form for every company and should be adjusted per company. However, one can start by using it, and tune it through showing the results with a group of people with the domain expertise to provide input as to whether the results of the adjusted formula “seems” correct.

=IF(R-Square>0.7,”Forecastable”,IF(AND(R-Square>.15,Standard Deviation/Series Mean<3,Series Mean>3, MAD>Series Mean*0.333333),”Forecastable”,”Unforecastable”))

The Flow of Forecasts

The entire flow of this approach can be described in the graphic below. Then the formula above, or some modification of the formula can be run against each item to determine if the material will be placed in the forecasting engine, or instead only reside in ERP or the supply planning engine and be entirely controlled by the consumptive logic settings.

How Companies and Implementers Ignore the Research

System implementers are not adjusting their approach to be considerate of the research in this area. The results for many decades now is consistent in showing that more complex forecasting techniques do not improve forecastability of difficult to forecast items and certainly do not pay off given their implementation investment, and long-term maintenance costs. A perfect example of this is the Crostons method, a method that Wayne Fu of Servigistics and myself discuss in this are an article as a highly complex formula which is very popular in software, but which has extremely limited areas where it can defeat many periods moving average.

Reorder Points Don’t Provide Visibility?

Comments that reorder points “don’t provide visibility” miss the point that the supply planning system can only provide visibility which is commensurate with the demand plan, which is the quality of the demand plan.

Even the most sophisticated cost optimizer solution for supply planning will not provide visibility if the forecast is of poor quality. On the other hand, products that have very low forecast error and are primarily a level forecast also do not benefit from forecasting effort beyond simple automation. This is because a level forecast is emulated with a reorder point. That is they provide the same result to supply planning.

  • Many companies are spending time forecasting items that are not “forecastable.”
  • Much of the history of computerized demand planning has been spent in attempting to apply very complex methods under the assumption that there is always a method of developing a good forecast, as long as enough effort is placed into forecasts.
  • This approach has had decades to prove itself out and has failed to improve forecast accuracy both at any company I have consulting with and in meta-analysis in the academic literature.
  • What is not recognized is that not every product in the database is forecastable.

The Benefits of Applying No Statistical Forecast

There are many circumstances where creating a statistical forecast is not helpful. This is because there is no pattern that any statistical forecast can use to create a reasonable projection. In most cases, the standard approach is to go ahead and create the forecast in any case and populate the planner user interface with values — values that the planner will typically ignore.

In this article, I am going to question this orthodoxy regarding the forecast. The reason for this is I have come to the conclusion that items that cannot have a good statistical forecast generated for them do not help planners. Secondly, it miscommunicates to the planner. That is — the implication is that the statistical forecasting system is adding value to the process — when in fact isn’t. One of the most significant forecasting issues in supply chain departments is the use of planners for non-value added activities. Creating a forecast tends to both underuse statistical forecasting and make their planners perform too many adjustments and overrides.

Communicating the Limits of a Statistical Forecast

By creating no forecast, this approach is honest with the planners and tells them

“The statistical forecasting methods has nothing to offer on this particular item.” 

This helps in two ways:

  1. It clearly communicates that the planner must control the forecast for this item.
  2. It reinforces the concept that different things need to be forecasted with various approaches. A few examples of these different approaches are listed below:
  3. 100% statistically forecasted items
  4. Statistically forecasted + manually adjusted items
  5. 100% manually adjusted items

Other authors are quite clear that different items require different approaches – and my experience shows that this is always true after I analyze the company’s product database. While this is a constant, very few companies incorporate this knowledge into how they forecast. Yes, the term forecastability has become standard at this point, how many companies use forecastability? The answer is very few. Segmentation of the product database is one of the most powerful ways to manage the forecasting process, allowing companies to have a much better chance of improving forecast accuracy.

Conclusion

The inventory optimization space is crowded, with everyone declaring they have inventory optimization. Among true inventory optimization vendors there are significant design approach differences that make them better or worse fits for different environments. However, the first step in an inventory optimization software selection is removing segmentation vendors. Segmentation software is still quite a value, but it is important to know what you are buying and what you can expect from your software purchases.

The Problem: Preparing for Inventory Optimization

Inventory optimization projects tend to take a long time and to be a significant expense. As with most complex implementations, the actual effective usage of inventory optimization software will significantly lag after whatever the initial project plan predicts. For companies that are interested in inventory optimization, we have a simpler solution that should be tested first before investing in inventory optimization software.

A major part of getting supply planning right is setting these parameters. Testing of the extracted parameters of ERP and external supply planning systems clearly shows that these values are poorly maintained. The result is far worse planning results than could be obtained otherwise.

Being Part of the Solution: Our Evolution of Thinking on Maintaining Inventory Parameters

Maintaining inventory parameters like rounding values and lot size in systems comes with a number of negatives that tend to not be discussed. One issue is that when using ERP systems, inventory parameters are typically managed on a “one by one” basis. This leads to individual planners entering values without any consideration for how inventory parameters are set across the supply network. After years we have given up managing safety stock or other inventory parameters in we now calculate inventory parameters in our application, the Brightwork Explorer, and then simply upload the data into the ERP system. See our link below. We have developed a SaaS application that sets the inventory parameters that allow for simulations to be created very quickly. These parameters can then be easily exported and it allows for far more control over the parameters. In our testing, the approach, which is within the Brightwork Explorer is one of the most effective methods for managing planning in any system. This approach is laid out in the book How to Repair Your MRP System.

In our testing, the approach, which is within the Brightwork Explorer is one of the most effective methods for managing planning in SAP applications.

Brightwork Explorer for Service Level & Safety Stock Setting

Service Level & Safety Stock Setting

Setting service levels and inventory can be performed far more easily than is done at the vast majority of companies. Click the image to see how.

Search Our Other Supply Planning Content

References

MEIO Book

What is MEIO?

This book explains the emerging technology of inventory optimization and multi-echelon (MEIO) supply planning. The book takes a complex subject and effectively communicates what MEIO is about in plain English terms. This is the only book currently available that describes MEIO for practitioners, rather for mathematicians or academics.

The Interaction with Service Levels

The this book explains how inventory optimization allows the entire supply plan to be controlled with service levels, and how multi-echelon technology answers the question of where to locate inventory in the supply network.
This is the only book on inventory optimization and multi echelon planning which compares how different best of breed vendors apply MEIO technology to their products. It also explains why this technology is so important for supply planning and why companies should be actively investigating this method.
The book moves smoothly between concepts to screen shots and descriptions of how the screens are configured and used. This provides the reader with some of the most intriguing areas of functionality within a variety of applications.
Chapters
  • Chapter 1: Introduction
  • Chapter 2: Where Inventory Optimization and Multi-Echelon Planning
  • Fit within the Supply Chain Planning Footprint
  • Chapter 3: Inventory Optimization Explained
  • Chapter 4: Multi-Echelon Planning Explained
  • Chapter 5: How Inventory Optimization and Multi-Echelon Work
  • Together to Optimize the Supply Plan
  • Chapter 6: MEIO Versus Cost Optimization
  • Chapter 7: MEIO and Simulation
  • Chapter 8: MEIO and Service Level Agreements
  • Chapter 9: How MEIO is Different from APS and MRP/DRP
  • Chapter 10: Conclusion
  • References
  • Vendor Acknowledgements and Profiles
  • Author Profile
  • Abbreviations
  • Links in the Book
  • Appendix A: MEIO Visibility and Analytics
  • Appendix B: The History of Development of MEIO Versus MRP/DRP

How to Best Understand Inventory Optimization

Executive Summary

  • This is an introduction to inventory optimization that explains where MEIO fits into the supply chain planning space.
  • There is a relationship between service level and inventory strategy.

Introduction to Inventory Optimization

Inventory optimization is one of the important supply planning methods. You will learn how inventory optimization works.

What is Inventory Optimization

Inventory optimization is inventory system software that answers the question of how much to keep in inventory, while multi-echelon planning answers the question of where to keep inventory in the supply network.

Unlike supply planning techniques that use sequential processing or calculation, the MEIO inventory system software calculates the level of service level impact of carrying one additional item at every product location combination and then sorts the list of options by their contribution to the level of service levels and selects the best contributor.

Where Inventory Optimization Fits into the Supply Chain Planning Software Space

  • As you can see, MEIO is its own category of supply planning and is one of the three major methods of supply planning.
  • MEIO is the most recently developed method and is also the least understood among supply chain professionals.

The Definition Of Inventory Optimization

  • Inventory optimization is the derivation of stocking levels throughout the supply planning network based on service level targets.
  • Inventory optimization answers the question of how much inventory should be carried, while—as I’ll discuss later— multi-echelon answers the question of where in the supply network quantities should be carried.

Unsurprisingly, these are the two most important questions in supply planning. Although all inventory optimization works this way, specifically how stocking levels are controlled by service levels depends on the individual approach of each particular MEIO vendor.

The inventory optimization inventory system software can be further described by where in the supply network service levels can be set.

I have come to call this either the “inventory service level specificity” or the “service level hierarchy.” This determines how the model is controlled and, therefore, it is important that companies understand what it is and how the control of the level of service differs among MEIO vendors. That is, where the implementing company wants to set the service level must match where the selected software allows the service level to be set. To read more about this topic see the post at the link below.

The inventory optimization inventory system software is further modified by the following:

  • Its Specificity: That is where in the supply chain the service level can be set.
  • Its Automation: How much manual work is required to set the service levels.
  • Its Universality: Whether the inventory optimization can be used by one department, or by multiple departments within a company.

Relationship Between Service Level and Inventory Strategy

The relationship between inventory and service levels is non-linear; higher and higher service levels require disproportionate increases in inventory to support them. The closer service levels come to one hundred percent, the more extreme the costs become. This relationship is one of the best-documented relationships in supply-chain management.

service-level-versus-inventory-cost

This graphic has been seen at one time or another by most supply chain professionals, and it demonstrates the fact that companies must decide what levels of service they can afford and, most importantly, what levels of service their customers are willing to pay for. See this calculated for one’s inventory is critical to setting the appropriate inventory strategy, as well as setting appropriate and reachable fill rate and level of service goals. 

toolsgroup-service-level-inventory-graphic

This is the same relationship with actual data in an inventory optimization application. This can allow inventory strategy to be set for a product location combination a group of product location combinations or for any grouping larger than that. 

This brings up the following question….

SLFMEIO

That is what is the appropriate level of service, where for what items. What is the best inventory strategy? For this one can use the mathematics of inventory optimization as a strategic tool as well as a tool for operations. 

The MEIO Inventory System Software Control Over Service Levels

One of the major differences between MEIO and MRP, DRP and APS systems for supply planning is that MEIO has straightforward control over service levels. In all other supply planning methods, the only direct control over the level of service level is the dynamic safety stock calculation. This can only be calculated locally (at one particular product-location combination) and is only for a portion of the TSL. MEIO can move the entire planned system-wide inventory up or down, much like the water level in a shark tank, and can do so very precisely depending upon the level of service selected.

This offers the supply planner unparalleled simulation capabilities, allowing him or her to tune the supply plan and to do so quickly.

Stages of Supply Chain Management

Supply chain management has had difficulty in pushing forward to using better techniques. This is called the stages of supply chain management. Stages of supply chain management are essentially maturity model for the use of a technique.

Stages of supply chain management apply to all the domains, demand planning, supply planning, production planning, etc. Inventory optimization is currently one of the most advanced techniques that can be used. Therefore it represents one of the most advanced stages of supply chain management. Inventory optimization only applies to the supply planning.

Conclusion

The inventory optimization inventory system software is effective for supply planning because it is customized for the most important business goal of many, although certainly not all, supply planning organizations: the minimization of inventory at any level of service. One of MEIO’s major features is the control it gives planners and organizations over the level of service level. Highlighting their flexibility, MEIO applications can also start from an inventory goal and work toward the level of service.

MEIO software can demonstrate the relationship of every possible combination of the level of service level versus inventory investment and can recreate the relationship based on SKU level modeling. This capability replicates the inventory-to-service-levels graphic that is familiar to most supply chain

One of MEIO’s major features is the control it gives planners and organizations over the level of service level. Highlighting their flexibility, MEIO applications can also start from an inventory goal and work toward the level of service. MEIO software can demonstrate the relationship of every possible combination of the level of service level versus inventory investment and can recreate the relationship based on SKU level modeling. This capability replicates the inventory-to-service-levels graphic that is familiar to most supply chain professionals and does so in a way that is very precisely based upon the company’s real data, making MEIO applications very powerful for simulation. In fact, several MEIO applications allow for simulation by planners and do not require any special set-up.

Inventory optimization and its accompanying technology multi-echelon planning are one of the most advanced stages of supply chain management.

Search Our Other Supply Chain Optimization Content

Brightwork Explorer for Service Level & Stock Management

Faster and More Straightforward Approach than Inventory Optimization

Inventory optimization started with a bang but failed to live up to the hype that was built up for it. Inventory optimization software is normally overly complex and while the idea is right, successes with inventory optimization are rare.

After seeing many failed inventory optimization projects we developed a simpler and less invasive way of modeling service levels and inventory. The Brightwork Explorer is free to access until it sees “serious usage” and is free for academics and students. Select the image below for more details.

Reference

MEIO Book

What is MEIO?

This book explains the emerging technology of inventory optimization and multi-echelon (MEIO) supply planning. The book takes a complex subject and effectively communicates what MEIO is about in plain English terms. This is the only book currently available that describes MEIO for practitioners, rather for mathematicians or academics.

The Interaction with Service Levels

The this book explains how inventory optimization allows the entire supply plan to be controlled with service levels, and how multi-echelon technology answers the question of where to locate inventory in the supply network.
This is the only book on inventory optimization and multi echelon planning which compares how different best of breed vendors apply MEIO technology to their products. It also explains why this technology is so important for supply planning and why companies should be actively investigating this method.
The book moves smoothly between concepts to screen shots and descriptions of how the screens are configured and used. This provides the reader with some of the most intriguing areas of functionality within a variety of applications.
Chapters
  • Chapter 1: Introduction
  • Chapter 2: Where Inventory Optimization and Multi-Echelon Planning
  • Fit within the Supply Chain Planning Footprint
  • Chapter 3: Inventory Optimization Explained
  • Chapter 4: Multi-Echelon Planning Explained
  • Chapter 5: How Inventory Optimization and Multi-Echelon Work
  • Together to Optimize the Supply Plan
  • Chapter 6: MEIO Versus Cost Optimization
  • Chapter 7: MEIO and Simulation
  • Chapter 8: MEIO and Service Level Agreements
  • Chapter 9: How MEIO is Different from APS and MRP/DRP
  • Chapter 10: Conclusion
  • References
  • Vendor Acknowledgements and Profiles
  • Author Profile
  • Abbreviations
  • Links in the Book
  • Appendix A: MEIO Visibility and Analytics
  • Appendix B: The History of Development of MEIO Versus MRP/DRP

How to Understand SmartOps MIPO

Executive Summary

  • MIPO is the SmartOps inventory optimization and multi echelon application.
  • MIPO has a specific software design that is discussed in this article.

SmartOps

SmartOps is a software company which makes several products, but the subject of this post will be their MIPO product (Multistage Inventory Planning and Optimization). SmartOps is one of the major vendors in this space, and currently gets the majority of the press, one for this reason for this being that they have very tightly tied themselves to SAP.

MIPO

MIPO is optimization and multi echelon simulation tool that is primarily concerned with setting safety stock and inventory targets. MIPO is a product location-based service level optimizer that provides some fast views into how metrics such as pipeline stock and safety stock changes with service level changes. It also has an alert system, which can be evaluated after each simulation run. Unlike some of the other solutions in this space, MIPO does not perform forecasting, (although their DIM (Demand Intelligence Module) does, however, MIPO uses the forecast to calculate how products will be treated in supply planning.

Thus MIPO requires the forecast from either the ERP system or planning system.

The SmartOps Software Design

After MIPO performs its calculations, SmartOps integrates to either the SAP execution or planning system by sending either parameter(s) that populate the material master in SAP ERP or actual safety stock values that populate the APO planning book.

For companies that are not setting up service level agreements and which want a very simple and straightforward integration (as SmartOps only integrates master data and not transaction data to SAP) to either ERP or SAP) ERP, SmartOps would be a good choice. This is likely why SmartOps was selected by SAP as their partner for multi echelon and inventory optimization (MEIO).

How SmartOps Rates on the Inventory Optimization Specificity

The inventory optimization specificity is a term that I defined to describe the various levels at which service level can be set in inventory optimization software. The inventory optimization specificity determines how service levels are set in the inventory optimization software is, although it does not describe the quality of the mathematics of the optimization (either inventory or multi echelon).

As is listed in the post below, setting service levels at the product location is how many companies and people think of performing inventory optimization.

Conclusion

MEIO vendors have different approaches, and SmartOps is one approach which focuses on parameter calculation. One of the most important factors to a successful MEIO implementation is matching the approach of the software to client needs. Along with IBM ILOG Inventory Analyst, SmartOps can be implemented quickly because they integrate at the master data level with the planning system or execution system.

Neither Inventory Analyst or SmartOps MIPO would be appropriate for companies that want transaction recommendations (purchase order, stock transport order, sales order recommendations), or those that want to manage service level agreements (SLAs) and manage the service level at the customer. However, it would be very appropriate for companies looking for a fast return on investment and which want the tone of the most straightforward integrations to SAP.

Search Our Other Supply Chain Optimization Content

References

Brightwork Explorer for Service Level & Stock Management

Faster and More Straightforward Approach than Inventory Optimization

Inventory optimization started with a bang but failed to live up to the hype that was built up for it. Inventory optimization software is normally overly complex and while the idea is right, successes with inventory optimization are rare.

After seeing many failed inventory optimization projects we developed a simpler and less invasive way of modeling service levels and inventory. The Brightwork Explorer is free to access until it sees “serious usage” and is free for academics and students. Select the image below for more details.

MEIO Book

What is MEIO?

This book explains the emerging technology of inventory optimization and multi-echelon (MEIO) supply planning. The book takes a complex subject and effectively communicates what MEIO is about in plain English terms. This is the only book currently available that describes MEIO for practitioners, rather for mathematicians or academics.

The Interaction with Service Levels

The this book explains how inventory optimization allows the entire supply plan to be controlled with service levels, and how multi-echelon technology answers the question of where to locate inventory in the supply network.
This is the only book on inventory optimization and multi echelon planning which compares how different best of breed vendors apply MEIO technology to their products. It also explains why this technology is so important for supply planning and why companies should be actively investigating this method.
The book moves smoothly between concepts to screen shots and descriptions of how the screens are configured and used. This provides the reader with some of the most intriguing areas of functionality within a variety of applications.
Chapters
  • Chapter 1: Introduction
  • Chapter 2: Where Inventory Optimization and Multi-Echelon Planning
  • Fit within the Supply Chain Planning Footprint
  • Chapter 3: Inventory Optimization Explained
  • Chapter 4: Multi-Echelon Planning Explained
  • Chapter 5: How Inventory Optimization and Multi-Echelon Work
  • Together to Optimize the Supply Plan
  • Chapter 6: MEIO Versus Cost Optimization
  • Chapter 7: MEIO and Simulation
  • Chapter 8: MEIO and Service Level Agreements
  • Chapter 9: How MEIO is Different from APS and MRP/DRP
  • Chapter 10: Conclusion
  • References
  • Vendor Acknowledgements and Profiles
  • Author Profile
  • Abbreviations
  • Links in the Book
  • Appendix A: MEIO Visibility and Analytics
  • Appendix B: The History of Development of MEIO Versus MRP/DRP

Considering ILOG Inventory Optimization and Multi Echelon

Executive Summary

  • What is ILOG?
  • How do the products that IBM acquired work, and how are they different from other inventory optimization and multi echelon planning offerings?
  • What is the problem with the ILOG acquisition by IBM?

What Is ILOG?

IBM ILOG, formerly just ILOG, which includes the merged LogicTools which ILOG purchased in 2007, is a company that provides advanced supply chain software.

“ILOG was created in 2007 and is a major supplier of software products in three areas: optimization, visualization, and business rules. The optimization products are ILOG CPLEX for LP (Linear Programming), and MIP (Mixed Integer Programming) and ILOG Solver for constraint programming.” – Real Optimization with SAP APO

They also offer products in the areas of network design to inventory optimization. The inventory optimization and multi echelon product are called IBM ILOG Inventory Analyst.

How Does Inventory Analyst Work?

ILOG Inventory Analyst is according to IBM material, the only product they have that does both strategic and tactical planning. However, like SmartOps, it does not create transaction recommendations (i.e. purchase requisitions, stock transport requisitions). After evaluating Inventory Analyst, it sounds as if it has a duplicate footprint to the SmartOps inventory optimization product called MIPO.

What is the Scope of Inventory Analyst?

A quotation from IBM collateral gives one pause. The quote is the following:

“Training and implementation can be completed in seven to 10 business days, with a total project timeline of around 60 days. Companies report operational improvement within90 days.”IBM

This brings up the question of what this solution is. No planning system that I am aware of can be implemented in two weeks, so Inventory Analyst may not be a planning system at all, but a parameter and safety stock calculator. This approach can add value, however, in the view of this author, taking this approach creates a smaller footprint for the inventory optimization and multi echelon functionality than should exist. Inventory optimization and multi echelon should not be an offline adjunct to the planning system, updating its parameters, but rather should be deeply integrated and central to it.

Is Being Acquired by IBM Good for Software?

The problem is that these large companies like IBM are very bureaucratic, so being acquired by them can be like being acquired by the Department of Motor Vehicles. Endless meetings and bureaucracy, as well as obligatory rah rah session, tend to suck the life out of creative types who often move off to less structured pastures. This is one reason why so little innovation is generated by large companies, despite all the hype to the contrary.

Thus the main point of acquiring software is to pitch it to IBM’s current client base, so it’s a financial consideration over a product solution. However, this brings up a separate issue…

Conflicts of Interest

“How objective can IBM be when it is comparing ILOG vs. SmartOps? IBM is paid by companies to perform vendor evaluations and recommendations, which is already bad enough with its extensive involvement with SAP, which is a company they do not own. However, this has an added dimension of bias when they are pitching software that they do own. For instance, would it be wise to hire Oracle to perform an evaluation as to whether to install Oracle or a competitor? Even if Larry Ellison sent you a letter promising to be unbiased?Gartner, not known for calling out conflicts of interests even brought up the following:

This provides a logical “home” for SCM solutions focused on process innovation, although it does bring into question the independence of IBM consulting when it will likely be intended, in some fashion, toward using IBM SCM tools to help clients manage their supply chains.”Gartner

Reference Accounts for Optimization

I wrote this article to possibly evaluate the Inventory Analyst for a possible project. I had heard of ILOG previously (and even used to drive past their Palo Alto office for several years). However, I had been unaware that they had an inventory optimization project (note I am saying inventory optimization, not cost-based optimization for which they are well-known). After researching, I found that ILOG’s most popular tool historically had been their network design tools and their CPLEX generalized optimizer. (the user manual for which is available at this article.)

CPLEX is used to teach optimization at universities around the world. As for inventory optimization, it does not appear that ILOG has many reference accounts in stock optimization. This is not to say the solution should be discounted out of hand, but that the added risk needs to be considered and taken into account by the purchasing company.

What is ILOG’s Sweet Spot?

This blog is to at least some degree being able to differentiate the various MEIO software. This can allow customers to make more informed decisions. In that vein, I found this quote from Gartner interesting…

The center of gravity, however, is focused on SCM process innovation, so users should be aware of this. The result means that IBM is not targeting the broad, wider market where SCM packaged applications reside (where LogicTools had primarily focused in the past), but is better oriented where configuration, and even customization, are sought.

Inventory Analyst

Inventory Analyst seems like a possible solution for clients looking for an offline parameter calculator and simulation engine. I do not consider it a planning engine because it does not make recommendations that are sent to the ERP system, but rather interact with either the advanced planning or ERP system by overwriting master data.

Gartner’s View

As a general point, while Gartner stated that they found the rationalization between previous IBM products like DIOS and the new ILOG products now under IBM’s umbrella to be rational, I really didn’t. (Let’s just say Gartner gets a check from IBM ever year to see things IBM’s way, which explains why they are so inaccurate when predicting the future of the products from the large vendors, which is described in this article.)

Getting back to ILOG, It seems that there is significant overlap between different products and that the purchase had more to do with buying a customer base rather than any inherent product logic for the acquisition.

IBM Product Mishmash

Clearly, several of the product need to be merged into fewer products and the marketing literature needs to be cleaned up with this pruning process. These are fundamental questions of product management — “who is doing what?”, “what are the demarcations between the solutions?” and so on. It is likely that this process is underway.

However, how long can IBM continue to develop ILOG within IBM? Many of the developers never wanted to work for a large bureaucracy, and after a year, many are already probably chafing at the yoke. While Gartner is optimistic about how much money IBM is paying them to write articles about their products, it is not axiomatic that these products will continue to be developed with the type of concentration that they have been in the past.

Conclusion

IBM seems to have a lightweight solution, however, unless IBM is already the implementation partner on the account, it would be difficult for me to recommend IBM’s Inventory Analyst because the product comes with all the IBM baggage, which will mean being slowly extracted from by IBM’s consulting division. IBM simply can not play well with other consulting companies or independent contractors, and often even their clients. And they are a bad vendor to have in your building.

The purchase of ILOG has simply made the situation worse and even less trustworthy than they were before. All of these things makes ILOG a solution that I would not recommend to clients. There are many excellent alternatives from higher quality vendors available.

Search Our Other Supply Chain Optimization Content

Brightwork Explorer for Service Level & Stock Management

Faster and More Straightforward Approach than Inventory Optimization

Inventory optimization started with a bang but failed to live up to the hype that was built up for it. Inventory optimization software is normally overly complex and while the idea is right, successes with inventory optimization are rare.

After seeing many failed inventory optimization projects we developed a simpler and less invasive way of modeling service levels and inventory. The Brightwork Explorer is free to access until it sees “serious usage” and is free for academics and students. Select the image below for more details.

References

“Real Optimization with SAP APO,” Josef Kallrath, Thomas I. Maindl, Springer Press, 2006

MEIO Book

What is MEIO?

This book explains the emerging technology of inventory optimization and multi-echelon (MEIO) supply planning. The book takes a complex subject and effectively communicates what MEIO is about in plain English terms. This is the only book currently available that describes MEIO for practitioners, rather for mathematicians or academics.

The Interaction with Service Levels

The this book explains how inventory optimization allows the entire supply plan to be controlled with service levels, and how multi-echelon technology answers the question of where to locate inventory in the supply network.
This is the only book on inventory optimization and multi echelon planning which compares how different best of breed vendors apply MEIO technology to their products. It also explains why this technology is so important for supply planning and why companies should be actively investigating this method.
The book moves smoothly between concepts to screen shots and descriptions of how the screens are configured and used. This provides the reader with some of the most intriguing areas of functionality within a variety of applications.
Chapters
  • Chapter 1: Introduction
  • Chapter 2: Where Inventory Optimization and Multi-Echelon Planning
  • Fit within the Supply Chain Planning Footprint
  • Chapter 3: Inventory Optimization Explained
  • Chapter 4: Multi-Echelon Planning Explained
  • Chapter 5: How Inventory Optimization and Multi-Echelon Work
  • Together to Optimize the Supply Plan
  • Chapter 6: MEIO Versus Cost Optimization
  • Chapter 7: MEIO and Simulation
  • Chapter 8: MEIO and Service Level Agreements
  • Chapter 9: How MEIO is Different from APS and MRP/DRP
  • Chapter 10: Conclusion
  • References
  • Vendor Acknowledgements and Profiles
  • Author Profile
  • Abbreviations
  • Links in the Book
  • Appendix A: MEIO Visibility and Analytics
  • Appendix B: The History of Development of MEIO Versus MRP/DRP

How to Better Understand Effective Lead Time

Executive Summary

  • What is Effective Lead Time?
  • How is Effective Lead Time Different From “Normal” Lead Time?
  • What is the Similarity to the Delivery Lead Time or Order Lead Time?
  • Why is Effective Lead Time Central to Multi Echelon Planning and the Key to Understanding the Topic?


Introduction

Interestingly, the term “effective lead time“ is both rare and very important to understanding multi echelon planning. See this post on multi echelon planning after you have read this for a primer. 

Effective lead-time is not an intuitive concept, as I can relay from my experience explaining the concept to some people. I was exposed to the concept of effective lead-time for the first time through MCA Solutions’ manuals, and I certainly did not understand effective lead-time the first time I was exposed to it. Since then, I have written several articles positioning effective lead-time as the foundational concept of multi-echelon planning. No other supply planning method (MRP/DRP, heuristic, allocation, or cost optimization) has this concept or capability, and as such, none are as efficient at locating inventory as MEIO applications.

Effective Lead Time Versus The “Normal” Lead Time Concept

Effective lead-time is not the standard static lead-time between two locations that are brought in through the master data (which is how most supply chain professionals are trained to understand lead-times), but instead, it is a calculated value. Unlike standard lead times, effective lead-times are situational. It is the lead-time required in the particular circumstance or scenario in question. With multi-echelon software, the lead-times between the DC and RDC change depending upon the stocking quantity and the service level at the RDC. Software that lacks multi-echelon capability keeps the same static lead time regardless of the inventory held at the RDC.

Flexible Calculation

Effective lead-time—the concept that stocking positions are determined and affected by connected locations and the ability to model this in the decision making — is why this functionality is more accurate in determining where inventory should be stocked than the other methods of supply planning.

Effective lead-time variable calculation of the delivery lead time or order lead time based upon the flexible calculation of things like the procurement lead time, production lead time. Is the total lead-time required to deliver the product to its final destination?

  • It is variable and dependent upon the stocking positions of higher echelons in the supply network.
  • This is a conditional concept of lead time and can be considered the delivery lead time or order lead time in reality. That is it is the delivery lead time or order lead time based on the circumstance of the order.

This concept is entirely foreign to the normal usage of the term lead time, which is static and hard-coded into a system. The concept presented before effective lead time is that the total lead time is some fixed value. But if we look at the order lead time or delivery lead time of a particular order, we can see that the lead time or effective lead time changes depending upon whether and where the stock is in the supply network at the time the order is placed.

In the excellent paper by Cohen, Agrawal, and Agrawal on effective asset deployment, this is described.

Similarly, investing in additional safety stock at a central depot reduces the effective lead-time for replenishment at the “child” locations connected to it. This lead-time reduction will, in turn, affect the stocking requirements at the child locations. Alternatively, such decisions are often constrained by the budgets allocated to the service organization. Consequently, if a particular asset is assigned to a specific location, it affects what can be assigned to other locations. Thus, the service levels that can be offered to customers at various locations are affected by these decisions, and are, therefore, interrelated; a high level of service to one customer may imply a lower level of service to another. – Achieving Breakthrough Service Delivery Through Dynamic Asset Deployment Strategies, Cohen, Agrawal and Agrawal 2004

Definition of Effective Lead Time

Different demand levels, lead to different circumstances and different needs to move to a higher echelon in the supply network.

  • The most important thing to consider is that while lead times between locations do not change (in the short term) effective lead times do change.
  • For software to be considered multi echelon, it must have the ability to reflect the changes in effective lead time in its planning. This, combined with inventory optimization, is what allows the software to properly
  • This, coupled with inventory optimization, is what allows the software to properly position, inventory to the right location, and in the right quantity based upon the demand, the current stocking position, and the service level.

It can also be described graphically which can allow the reader to more intuitively understand what effective lead time is.

Other Users of the Term Effective Lead Time

Another use of the term is when a company needs to determine if it has the raw materials/components/packaging material to make an order quantity.

  • If a company can produce the sales order quantity from the available stock of all input materials, then the effective lead time is the production lead time.
  • If the order quantity exceeds this, the effective lead time must include the procurement lead time.

That is the production lead time and procurement lead time’s implication into the effective lead time is conditional based upon the stock position in the network.

Obviously being able to calculate the delivery lead time or order lead time while conditionally including the production lead time or procurement lead time is a very sophisticated mathematical feat.

Conclusion

Two of the rules of what makes software multi echelon are the ability to manage effective lead time.

  1. Effective Lead-time: Users must have the ability to compare the stocking position at different locations by calculating effective lead-times.
  2. Account for All Lead-time Variations:

Effective lead time requires software to be properly employed and calculated. However, even as a concept it is important to understanding how supply networks operate.

Search Our Other Supply Planning Content

References

Brightwork Explorer for Service Level & Stock Management

Faster and More Straightforward Approach than Inventory Optimization

Inventory optimization started with a bang but failed to live up to the hype that was built up for it. Inventory optimization software is normally overly complex and while the idea is right, successes with inventory optimization are rare.

After seeing many failed inventory optimization projects we developed a simpler and less invasive way of modeling service levels and inventory. The Brightwork Explorer is free to access until it sees “serious usage” and is free for academics and students. Select the image below for more details.

What is MEIO?

This book explains the emerging technology of inventory optimization and multi-echelon (MEIO) supply planning. The book takes a complex subject and effectively communicates what MEIO is about in plain English terms. This is the only book currently available that describes MEIO for practitioners, rather for mathematicians or academics.

The Interaction with Service Levels

The this book explains how inventory optimization allows the entire supply plan to be controlled with service levels, and how multi-echelon technology answers the question of where to locate inventory in the supply network.
This is the only book on inventory optimization and multi echelon planning which compares how different best of breed vendors apply MEIO technology to their products. It also explains why this technology is so important for supply planning and why companies should be actively investigating this method.
The book moves smoothly between concepts to screen shots and descriptions of how the screens are configured and used. This provides the reader with some of the most intriguing areas of functionality within a variety of applications.
Chapters
  • Chapter 1: Introduction
  • Chapter 2: Where Inventory Optimization and Multi-Echelon Planning
  • Fit within the Supply Chain Planning Footprint
  • Chapter 3: Inventory Optimization Explained
  • Chapter 4: Multi-Echelon Planning Explained
  • Chapter 5: How Inventory Optimization and Multi-Echelon Work
  • Together to Optimize the Supply Plan
  • Chapter 6: MEIO Versus Cost Optimization
  • Chapter 7: MEIO and Simulation
  • Chapter 8: MEIO and Service Level Agreements
  • Chapter 9: How MEIO is Different from APS and MRP/DRP
  • Chapter 10: Conclusion
  • References
  • Vendor Acknowledgements and Profiles
  • Author Profile
  • Abbreviations
  • Links in the Book
  • Appendix A: MEIO Visibility and Analytics
  • Appendix B: The History of Development of MEIO Versus MRP/DRP

Why Its Time for the SAP xApps Program to be Terminated

Executive Summary

  • The xApp program was developed to allow SAP to co-opt competing vendors and to allow them to take the IP of these xApp vendors.
  • Why the xApp program is such a problem and so anti-competitive?

Introduction

The SAP xApp program has been a commercial failure. This is good because the xApp program is not much more than a marketing agreement between SAP and smaller vendors. SAP co-opts best of breed vendors and provides them with more market exposure. It also confuses clients as to what software vendors are doing what and seems to violate the principle that the company doing software development receives the compensation.

How The Arrangement Works

The xApp program is where software vendors agree to give over 40% of their revenue on a software sale to co-market with SAP and be brought into their accounts. However, it gets worse than even this. Software vendors that are on the SAP price list have to give over between 60 and 70% of the software license, and furthermore, the money from the customer is first paid to SAP. SAP then is responsible for paying the third-party software vendor on a schedule that may not be immediate.

This program makes a lot of money for SAP, but is it right?

The Reseller Program

SAP has essentially added a line of business over the past few years. That is of software reseller. Through various programs such as xApps, approved solutions among others, SAP is now introducing software to its clients, and taking a percentage (anywhere from 40 to 70% of the software license. There happen to be several of these agreements that SAP has in the SCM space. The question arises as to why software companies would give such a hefty amount of money over to a competitor. The answer is that SAP gives these companies exposure that they would not ordinarily get.

The Problem with Being Resold by SAP

Something is very un-kosher about the largest software vendor reselling other software and taking such a large chunk of money. Is SAP simply using its monopoly position with customers to in effect sell access? This appears to be the case. Some analysts point out that these programs are good because they help fill out the product line of SAP. The person who points this out needs to state who they are saying it is good for. It does not seem to be good for the third-party vendor or for the customer. Secondly, companies can do their own research and find third-party solutions themselves. This is supposed to be the role of large consulting companies to help with this research, but the major firms are so SAP biased, that they often do not do this role properly. The issue is when high-status partners see third-party solutions as a threat to their revenues.

Large consulting companies have SAP resourced to sell, so small solutions get less focus. Also, how unbiased is this program? If say one third-party software company is on the price list, and another third-party company is not, even though the solution is better for the customer, wouldn’t only the company that is allowing SAP to take 1/2 of its license revenue always be recommended? Is the fact that SAP is making so much money from these deals being declared to the client? I do not think it is because if this were known, I don’t think clients would agree to it.

There are some problems with this xApps program, and they are listed below:

Issue #1: SAP Faking Functionality That Resides with the xApp Vendor

SAP can and does pretend that it has far more functionality that it does. So SAP salesmen can say that “we have that capability through our xApp,” which is another way of saying that they don’t have it at all.

Issue #2: Customer Confusion

Customers end up getting very confused as to who is doing what. Is the functionality within SAP, is it at the third-party vendor? Who is doing what?

Issue #3: Exaggerated Integration

The integration is almost always oversold. SAP, in fact, invests very little in the integration process and creates just an essential enough integration to tell customers “the solution is integrated.”

Issue #4: Creating Bastardized 1/2 Copies of the Best of Breed

The resulting solution often ends up being less than the best. To insert more SAP functionality, some parts of the third party vendor’s functionality and SAP functionality are inserted, not because this results in the best solution but because then a new “product” can be said to exist.

Issue #5: Taking Revenues from the Actual IP Creator

With SAP taking 40% to 70% of the revenues for the software that was due to the creators of the software, the xApp program takes revenues from where the work was done and gives it to where it was not done, which is SAP. (That is interesting because I thought we were all about compensating the creators of intellectual property in the US system.)

Issue #6: The Program is an IP “Straw”

The xApp program is just a Trojan horse by SAP. Through “working with” the third part vendors to integrate them to SAP, SAP eventually hopes to replace all of these vendors with their products, which will work eerily like the software of the third-party vendors. I show in this article on the history of advanced planning software much of the APO design appears to be taken from SAP’s joint venture with i2 Technologies in the late 1990’s (listed below). SAP co-opted work from Commerce One before dumping them and effectively ending the company, and after evaluating SPP, I am noticing many concepts that seem directly copied from MCA Solutions. For vendors, partnerships with SAP never last long and often result in bad outcomes for the smaller vendor. Because SAP is so powerful, there is a lot of fear of speaking out against them, so these facts do not tend to get aired in published material or on the web. (If I worked for any of the large consulting companies, I would receive pressure from a senior partner to remove this article.)

Issue #7: An Anti Competitive Program

This arrangement is decidedly anti-market and is essentially a concession granted to SAP due to its monopoly position in the marketplace. It is simply unfair to both be subjected to extensive free market drivel by people with little understanding of economics and then also observe the large anti-market conglomerates like SAP engage in monopolistic practices. It would be fair to say that SAP likes the free market about as much as Goldman Sacks does.

xApps for Inventory Optimization

I believe at one time there somewhere around 140 xApps. How many there are currently is unknown to us as we no longer hear the term, and the term may have been changed by SAP and the program renamed. The area we know best is inventory optimization where SAP partnered with two firms, SmartOps and MCA Solutions. The three-year agreement with MCA has now expired. In the example of SmartOps, they provide the inventory optimization and SAP integrates to them. It’s important to understand that the inventory optimization capability is part of SmartOps’s product and does not have anything to do with any of SAP’s products. Instead, SAP integrates to SmartOps, as it would integrate into another application.

The Best Approach When Dealing with xApps

In my view, it’s far better to approach the vendor (such as SmartOps) directly and buy the software from them rather than buying it through SAP. Furthermore, this will allow the software vendor to better service the customer because more of the revenues are flowing to those that created and maintain the solution. Intellectual property rights are a huge issue……..when a larger company feels as if their intellectual property is consumed without proper compensation (as the entertainment and pharmaceutical industry lobbying and public relation programs can attest) however, when the perpetrator is a large company benefiting from the intellectual property of a smaller company, all of a sudden the issue becomes greyer, and the relationship gets called “a strategic partnership.” The US intellectual property protection system is where intellectual property rights seem to be relative. Large companies have infinite intellectual property rights (and the right to expropriate IP that they had nothing to do with creating), medium-sized companies have medium-sized intellectual property rights, and individuals have none whatsoever. It takes a very fancy degree from the best law school not to notice this.

Conclusion

Only a thoroughly unethical company would create something like the xApp program.

SAP is asking that companies pay a toll to SAP for a very small amount of work in creating partnerships with software firms. xApps have been unsuccessful in the marketplace, but less for the reasons listed above and more because SAP has a very hard time working with other software vendors. The fact the SAP can even attempt such a program leads to the conclusion that SAP has become too big, and like Microsoft is now causing a negative or a smothering effect on the industry. In the US system, this is when the Federal Trade Commission is asked to come in and check to see if any anti-trust rules are being broken. The xApp program is a perfect example of a monopolistic entity throwing its weight around with smaller vendors.

Post Script

As I write this addition, it is now two years since I stated that I thought it was time for the xApps program to die. At this point, I can confidently say the xApp program is dead. While there are a few vendors that are on SAP’s price list like SmartOps, in general, most vendors who wanted to have this partnership with SAP have already been burned, and the program is no longer active. I have declared this in the following prediction, related to the end of the line for Solution Manager.

Search Our Other SAP Partnerships Content

References

For those interested, a basic introduction to US anti-trust law can be found below. Also, companies can be reported for violating anti-trust laws at the link below this.

https://www.ftc.gov/bc/antitrust/index.shtm

https://www.ftc.gov/ftc/contact.shtm

How to Best Understand Multi Echelon Planning

Executive Summary

  • Multi echelon planning uses advanced mathematics to perform supply planning with each location knowing the inventory of other the locations in the supply network.
  • There are specific tests that can be applied to any multi-echelon system.

Introduction

Multi echelon planning is the most advanced location planning currently available in supply chain planning. You will lean about multi echelon planning from many dimensions in this article.

What is Multi Echelon Planning?

  • Multi echelon planning can be understood in many ways. It is a concept and technology that has only recently begun to have software available to be implemented, and its mindshare is increasing a supply chain organizations. While the underlying logic of
  • While the underlying logic of multi echelon is quite complicated, its business impact is easy to understand. The primary barrier to understanding
  • The primary barrier to multi understanding echelon is doing away with one of the core assumptions of supply planning.
  • Multi echelon planning has an important impact on the role of the inventory manager.

Multi Echelon Definition

Multi echelon capability is the ability of software to see the entire supply network and manage the inventory in that network as a “pool,” rather than as a group of independent locations. Independent location planning is the assumption that must be dispensed with to understand multi echelon planning. As a mnemonic device, multi echelon planning could just as easily be called“pooled location inventory planning.”

multi-echelon-inventory-problem

Dr. Lee’s Multi Echelon Test

I found a splendid definition or at least an explanation from a white paper on the topic from Manhattan Associates which was written by Dr. Calvin Lee. This paper explains at a deep level what the topic is. It takes a while to digest, but once you do, you will understand fully what multi echelon optimization is. A quote from the paper is included below:

“Managing inventory in a multi echelon network vs. a single echelon network presents major pitfalls. One is the failure to achieve true network inventory optimization because replenishment strategies are applied to one echelon without regard to its impact on the other echelons. A network view of inventory usage up and down the demand chain is absent when you are only dealing with a single echelon of locations. The complexities of managing inventory increase significantly for a multi echelon distribution network with multiple tiers of locations (i.e., a network comprising a central warehouse and downstream customer-facing locations). All locations are under the internal control of a single enterprise. Instead of simply replenishing the warehouse or the DCs that sit between your supplier and your end customers, as in the single-echelon situation, you also need to contend with the problems of replenishing another distribution point between your supplier and your DCs. For the purposes of this paper, we will refer to this additional distribution point as an RDC. The objective of multi echelon inventory management is to deliver the desired end customer service levels at minimum network inventory, with the inventory divided among the various echelons. Note: We use the terms “RDC” and “DC” to distinguish the entities in the separate echelons. For a manufacturer or wholesaler, the terms “hub” and “spoke” could be equally applicable. For a retailer, the terms “central warehouse” and “store” might be relevant. For clarity, we will focus on the interaction between two echelons.The logic is easily extended to more than two echelons through recursion. In addition, we will use the term “enterprise” to refer to the distribution entity as a single, cohesive organization.”Manhattan Associates

What is Multi Echelon Planning?

Multi-echelon planning represents the “ME” in the MEIO acronym. However, the term is used much less frequently than inventory optimization. Interestingly, multi-echelon planning was researched earlier than inventory optimization; the first multi-echelon planning research paper was published in 1958, while inventory optimization was not commonly written about until the 1970s. The logic to determine stocking decisions as presented in the first paper on multi-echelon planning was not service level (inventory optimization) but rather a cost function with different stock-out costs per echelon. It was not until several years later, in 1976, that multi-echelon planning and inventory optimization mathematics were combined. The term “echelon” is generally understood as multiple levels in the hierarchy of the supply network. However, this definition requires an explanation for those who are unfamiliar with the term.

Moving stock between predefined parent and child locations in a supply network is called “deployment.” In deployment, specific parent locations supply specific child locations. These locations can be called many things, and companies typically assign slightly different names to locations that have the same function. Plants are often designated as the first parent echelon. Plants then feed depots or regional distribution centers. These locations, which are children to the plants, are themselves parents to the distribution centers. The assignment between parent and child locations—the valid location-to-location combinations in the supply network—is held in a table in the supply planning application. Each specialized layer is known as an “echelon.”

How Many Echelons?

There can be any number of echelons in a supply network. The number of echelons varies by company size and industry. For instance, a finished goods distributor that does no manufacturing would tend to have fewer echelons. A company that both manufacturers and services their product would have more.

The term “echelon” first appeared in published form in a 1958 paper by A.J. Clark, who explained the reason behind selecting this complicated way of saying ”layer” or “level.”

“The word ‘echelon’ is used rather than ‘level’ to avoid confusion with stock levels, rather than ‘stage’—although the word has been used in this context—because ‘multi-stage problems’ has recently been used to designate problems in which time is divided into discrete decision intervals or stages.”

The number of Google searches for these terms provides a good understanding of how frequently people are thinking about or researching them. According to Google, there were, in one month, 6,600 searches globally for “inventory optimization” but only 2,400 searches for “multi-echelon.” One apparent reason for inventory optimization’s popularity is that it has been used much more frequently in promotional literature. While most supply chain professionals have an idea that inventory optimization is connected to service level planning, it’s rare that I run into people other than MEIO vendors who understand the definition of multi echelon planning.

The Questions that Each Term Answers

Inventory optimization and multi-echelon planning answer different questions regarding the supply plan, but one is not more important than the other. Together, they answer the two most important questions in supply planning:

  1. How much should be carried? (Answered by inventory optimization)
  2. Where in the supply network should quantities be transported? (Answered by multi-echelon planning)

Inventory optimization and multi-echelon planning work in conjunction with each other to place the optimal amounts at the optimal supply network location based on the forecast. A much less favorite topic than inventory optimization in discussions about supply chains, multi-echelon functionality often does not get its fair share of attention, and talks of MEIO tend to focus more on the service level benefits than on the positioning benefits of MEIO applications. This chapter will explain why multi-echelon is such an essential capability for supply chain organizations to have.

Multi-Echelon Planning

Defined “Multi-echelon inventory optimization” is the official full technical name of what I refer to as either “multi-echelon” or “multi-echelon planning,” and is often shortened to differentiate it from inventory optimization. Its full name is also quite a mouthful, so it certainly makes sense to use a shorter term. Multi-echelon planning is functionality that allows users to plan their supply network in a specific way—a way that changes the standard assumptions about the relationship between locations. Unlike earlier methods of supply planning (which assume location independence), multi echelon software thinks that the various locations in the supply network are interdependent—and it has the mathematics to treat them as such.

In multi-echelon planning, the stocking at a parent location affects the stocking decision and service level at the child location—a simple thing to say, but with huge implications. Other supply planning approaches do not work in this manner as they treat each location as independent of other locations regarding stocking decisions. However, the multi-echelon assumption is a better reflection of reality as the stocking positions of related locations in a supply network do influence each other.

A Multi-Echelon Network Explained

One of the greatest impediments to understanding the concept of multi-echelon software functionality is confusing it with the frequently used term “multi-echelon supply chains.” As we just discussed, an echelon is simply a layer of locations within a supply network. Any supply network with more than one echelon is considered multi-echelon. However, when an MRP and DRP system plan a multi-echelon supply network, does that make the software multi-echelon? Multi-echelon software refers to a specific technology while the other term—multi-echelon supply chains— merely refers to the physical setup of a supply chain. Separating these terms is not made any easier because some vendors have attempted to blur this distinction to obscure the fact that they lack multi-echelon functionality. While all supply planning applications deal with multi-echelon networks, not all supply planning applications have the ability to plan the supply network using the mathematics of multi-echelon inventory optimization. This distinction is simple, yet vital to understanding multi-echelon software functionality and to making effective software selection decisions.

Example of a Multi-Echelon Network

A multi-echelon supply network is simply a network of locations, which has multiple levels, or echelons. The simplest multi-echelon supply network is made up of two echelons. The easiest way to understand this relationship is to see it represented graphically. Both a single-echelon network and a multi-echelon network are illustrated on the next page.

As the company on the left side only controls the stocking location and quantity for the DCs (distribution centers), and in this example, the DCs do not supply each other; the supply network is a single echelon. However, only small companies have a supply network that resembles this configuration. Most companies of any size have a regional distribution center. If the company on the left were to begin to allow inter-DC transfers, they would also have a multi-echelon network. A single-echelon supply network can quickly become multi-echelon by the simple act of accepting material from a supplier in just one location (for instance, to benefit from a volume discount) rather than taking separate shipments from the supplier to multiple facilities.

Varying Complexity of Supply Networks

While most companies have multi-echelon networks, not all supply networks are of equal complexity from the perspective of multi-echelon. The more locations, and the more echelons (regional DCs, which feed DCs, which feed forward stocking locations, etc.), the more complex the multi-echelon problem becomes, and the more beneficial the implementation of MEIO software would be. Service parts networks are known for having a high number of echelons due partially to their need for forward stocking locations that can quickly service expensive equipment, thus minimizing equipment downtime. Service parts networks have the additional complexity of needing to move repairable items to locations in the supply network where they can be serviced. Therefore, it is not surprising that one of the early innovators in multi-echelon inventory optimization was MCA Solutions, a vendor that focused on the service parts market. Furthermore, the earliest papers on multi-echelon and inventory optimization were directed toward optimizing service parts networks, not finished goods networks.

MEIO’s Value Adds to the Planning Process

Lack of understanding of how multi-echelon inventory optimization adds value to the planning process is an impediment to understanding the technology itself. For this I turn to Dr. Calvin Lee, an expert in multi-echelon, who has this to say on the topic of multi-echelon complexity:

“Managing inventory in a multi-echelon network versus in a single echelon network presents major pitfalls. One is the failure to achieve true network inventory optimization because replenishment strategies are applied to one echelon without regard to its impact on the other echelons. A network view of inventory usage up and down the demand chain is absent when you are only dealing with a single echelon of locations. The complexities of managing inventory increase significantly for a multi-echelon distribution network with multiple tiers of locations (i.e., a network comprising a central warehouse and downstream customer-facing locations). All locations are under the internal control of a single enterprise.”

One of the essential points made by Dr. Lee is the very common failure to achieve true network inventory optimization because replenishment strategies are applied to one echelon without regard to its impact on the other echelons. This is referred to as “independent” or “sequential location” planning and is described in the graphic below.

The Tests for True Multi Echelon Optimization

Dr. Lee laid out the following criteria for whether a software application is MEIO in his well-known MEIO white paper, “Multi-Echelon Inventory Optimization,” which I still consider the best white paper written on MEIO. I have paraphrased his bullets below (and changed some of the descriptions slightly). I have also provided my commentary (which is parenthetically next to each bullet point). I do not agree with Dr. Lee on each point; however, in explaining what Dr. Lee laid out, and in some cases offering an opposing viewpoint, I hope to provide you with a thorough understanding of each of the criteria to help you make up your mind.

I have paraphrased his bullets (and changed some of the descriptions slightly) below and have provided my commentary, I don’t always agree with Dr. Lee on each point, however, in explaining why readers can get an even better understanding of each of the criteria and make up their mind:

  1. Forecast only at the DCs: Avoid multiple independent forecast updates in each echelon by allowing the primary demand signal at the DCs to drive the forecasts in all echelons.
  2. Effective Lead Time: Must have the ability to compare the stocking position at different locations by calculating effective lead times. (to find out more about this capability, see this article).
  3. Account For All Lead Time Variations: I would classify this as a nice to have. Some vendors like MCA Solutions and ToolsGroup can do it. However, software that cannot do this can still be multi-echelon, and still add significant value to the supply plan.
  4. Monitor and Manage the Bullwhip Effect: The Bullwhip Effect is the well-known problem of over-response because locations are planned independently of one another (locations are planned independently between organizations as well, and the Bullwhip Effect exists inside and outside of supply chain organizations). Dr. Lee lists this as a separate item from point 2. However, I would argue point 2. Takes care of this.
  5. Enable Visibility Up and Down the Supply Chain: All supply planning software should do this, but it is not distinctly a multi echelon criterion. Visibility could be provided solely by an excellent interface. The best visibility enabled view in a supply planning engine I have seen is in ToolsGroup SO99, which perhaps not coincidentally is a multi echelon application.
  6. Synchronize Order Strategies: “Synchronizing the order cycles at the DCs with RDC (regional distribution center) operations reduced lead-times and lead-time variations between RDC and DCs.” (A multi-echelon approach makes this possible because the enterprise controls how and when a product enters and leaves the RDC. This is a nuanced criterion in that it is also rarely discussed. The concept of managing ordering such that it is coordinated between locations is a great leap conceptually for most supply chain practitioners.)
  7. Offer Differentiated Service Levels: “The RDC can provide different service levels (for the same product) to different DCs. A multi-echelon approach makes this possible because the enterprise controls how and when a product leaves the DC.” (Here Dr. Lee is speaking of different service levels per location rather than different service levels per customer. Differentiated service levels per customer would fall into the category of inventory optimization.)
  8. Correctly Model the Interactive Effects of Alternative Replenishment Strategies of One Echelon or Another: I place this in the category of simulation and agree that multi echelon software should have the ability to perform simulation efficiently.  Luckily most MEIO software does.

Evaluating the Relative Importance of the Criteria

Different people will read this list of criteria and come to their conclusions as to the essential features of multi-echelon planning, but I consider the second point to be the most important. While at one time the ability to plan locations at different service levels was state-of-the-art, some MEIO software has moved even beyond that to other approaches and service level aggregation above the product location. This enables them to plan at the customer or contract (a contract is a special MEIO capability for service parts planning that supports a large piece of equipment such as an airplane or earth-moving construction equipment; the equipment is the “contract”).

The criterion of not forecasting at internal supply network locations is very important. It dovetails with the concept of managing all the inventory-carrying locations as an “inventory pool” and is quite different from the present way of thinking about this topic. Forecasting only at forward locations also has the added benefit of reducing the forecast error. It is also the most accurate way of representing demand for MEIO software. Most supply chain organizations create forecasts, which are allocated to the initial point of demand. Distribution centers that sell to a customer have the sales orders allocated against the location that fulfills the customer demand. That part is simple; however, the interesting question is whether the regional distribution centers (RDCs) should also have a forecast. The answer is that they do not need one as they derive their demand from the forecast at the DCs. In practice, some companies still create RDC forecasts, but with multi-echelon software, it is unnecessary to generate any forecast except the forecast at the DC. This is required to allow multi-echelon planning to perform all of its functions correctly.

Commentary on Dr. Lee’s Tests

Of the test criteria above, I consider the ability to calculate effective lead times and manage the entire supply network as a single virtual location to be the most critical test of whether software contains multi echelon functionality. If the software does not include this functionality, it is not multi echelon at all. However, as Dr. Lee’s tests show above, there is a continuum by which software can be graded regarding its degree of multi echelon capability. This list is extremely useful to use when evaluating different MEIO vendors.

The Drivers for New and Moved Stock

The Manhattan Associates white paper sets up the following drivers in its example of what determines the decision of being in new stock at a product location.

  1. Demand
  2. Demand Variation
  3. Replenishment Frequency
  4. Order Supply Strategy
  5. Service Level Goals
  6. Inventory Position

Next, the Manhattan white paper compares a non-multi echelon decision, with a multi echelon decision, and notes that the multi echelon decision is much more complicated.

“In this single-echelon situation, the lead times are between the DC and its external supplier. The enterprise’s order supply strategies depend on its internal cost factors—such as those associated with handling and carrying inventory—and the external supplier’s ordering constraints and bracket discounts. For this reason, the replenishment quantities depend on a combination of internal and external factors. Now consider the same product in a multi echelon network that includes an RDC between the suppliers and the DCs. The same inventory drivers described in the preceding section apply for the SKU at the RDC location. However, some significant issues emerge: What is the proper measure of demand to the RDC, and how should this demand be forecasted?

  • How do you measure the demand variation into the RDC?
  • How does the trend toward larger orders from the RDC to the supplier affect the order supply strategy for the RDC SKU?
  • What is the optimal service level goal between the RDC and its “customers,” which are the DCs?
  • How do you factor the individual DCs’ inventory positions into the RDC replenishment decisions?”Manhattan and Associates

Questions that Non Multi Echelon Software Cannot Ask

These are some questions that non-multi echelon software cannot even ask because it does not set up the problem in the same way. Instead, each location is treated as an island, as if its decisions do not impact the stocking decisions of the other locations that either relies on it or on which it relies. This independent location assumption is an oversimplification and false assumption which is baked into all MRP / DRP and APS software. However, after working in supply chain planning systems for over a decade, I never really understood that it was a false assumption until I began to understand the assumptions inherent to multi echelon software. In multi echelon software, the locations affect one another. A child location does not have to stock as much if a parent location is stocked sufficiently. This is only one of the decisions that multi echelon software can help a company understand.

Aside from gaining a fuller understanding of the multi echelon problem, this paper also focused our attention on the relationship between the RC and the DC.

Dr. Calvin Lee’s Observation on Managing Inventory

In Dr. Calvin Lee’s paper Multi Echelon Inventory Optimization he points out that managing inventory in a multi echelon network vs. a single-echelon network presents major pitfalls. One is the failure to achieve real network inventory optimization because replenishment strategies are applied to one echelon without regard to its impact on the other echelons. This is referred to as independent or sequential location planning and is described in the graphic below.


A network view of inventory usage up and down the demand chain is absent when you are only dealing with a single echelon of locations. Another pitfall is to base upper-echelon replenishment decisions on inaccurate demand forecasts. These traps can create substantial negative consequences according to Dr. Lee.

The Problem Being Solved

Thus if the software is not doing this while it may face a multi echelon problem, it is not solving it with multi echelon capability. Instead, they are solving the multi echelon problem sequentially; solving the problem at one level in the network, then moving on to determine inventory levels at the next level. The levels in the supply network are treated as islands from one another.

The vast majority of planning software is addressing the different levels, or echelons, in the supply network as independent islands from one another. However, this is not in fact representative of the reality of supply chains, and in this way software that models in this way is not realistic. Instead, the locations should be managed as an integrated whole. Software that works in the old non-multi echelon way is so common, and the author has worked in software that works in this limited way for so long, that he did not see the missing component regarding multi echelon capability until exposed to this software.

RDC to DC Lead Times

One of the giveaways whether the software is multi echelon is how it treats the lead times. That is the lead times between the DC and RDC need to change depending upon the stocking quantity, or the service level, at the RDC. Software that is not genuinely multi echelon keeps the same static lead time no matter what the inventory held at the RDC.

The Natural Inclination to Position Inventory Close to the Customer

One reason why this is important is that without adjusting this lead time, the RDC and DC are not pooling inventory and auto-adjusting for each other’s inventory positions. Furthermore, this creates a natural inclination to position inventory “closer to the customer,” or at the DC. Thus too much inventory ends up too far forward, requiring more costly intra-echelon stock transfers to meet the demand.

This is the problem in many service supply chains such as automotive (and why many dealerships attempt to deal with it with a weekly milk-run between a group of dealers). It is a problem of particular concern for service supply chains, which need to make sure they keep expensive and or less frequently repaired items at the RDC, however, it is also a problem for finished goods supply chains. There is no supply chain which employs an intermediate storage facility (i.e., RDC) that cannot benefit from multi echelon capability.

Grouped Purchasing Also Poses a Multi echelon Problem

Companies can still have multi echelon problems even if there are no regional DCs. This is because of pooled purchasing which is performed to meet a quantity discount.

A New Approach to Supply Planning

Multi-echelon breaks with the old approach of treating locations in the supply network as independent from one another and plans the network as a pool of inventory, which has the added benefit of relocating the best possible quantity of inventory to the appropriate location. This topic is covered in detail in this article.

If successful, it would mean that setting a service level at a product location would not be necessary. Applying software with multi echelon capability, in concept, allows the software to decide the appropriate service level at a location as well as the stocking level based upon service levels set in the customer contract. Virtually all supply chain planning methods cannot directly connect the client service level to supply chain operations. To do this, the software must be both capable of inventory optimization and multi echelon planning. It requires both areas of functionality to make the appropriate determination.

Multi Echelon Planning and The Inventory Manager

One needs to consider how multi echelon technology improves the abilities of the inventory manager and to supply planning. The job of the inventory manager is so much simpler than the job of the inventory manager in companies that do not use multi echelon software.

No human can perform the calculations that multi echelon technology can perform. This means that before the inventory manager even begins their job, the inventory manager has all of the dependent stocking positions calculated for them. This is a tremendous time saving. Under non multi echelon planning systems, there is zero dependency calculation. Therefore under these conditions, the inventory manager must derive and stock far more locations. With multi echelon planning the right places to set as stocking locations are determined. This is because effective lead time is calculated by multi echelon planning software. Under the standard approach, the inventory manager has to spend so much time evaluating alternate sources of supply and performing a stock transfer when the inventory manager could be spending there time in far more effective ways.

Conclusion

To understand what multi echelon software is doing, it is essential to understand what constitutes a multi echelon supply chain, and secondly how multi echelon’s capabilities change how supply planning can be performed to result in better plans. Multi echelon planning greatly reduces the effort that is placed on the human resources in supply planning like the inventory manager. Multi echelon actually changes the role description of the inventory manager to make the job far more strategic in nature. At so many companies the role of the inventory manager is execution focused rather than truly planning in orientation.

Much less emphasis is placed on multi-echelon planning functionality than inventory optimization functionality even though both work in conjunction in MEIO software. It is not accurate to consider one to be more important that the other. Many people think that multi-echelon planning describes the act of planning a multi-leveled supply network when in fact it is a distinct mathematical functionality that only MEIO applications have. Multi-echelon planning is not easy for even experienced supply chain professionals to understand, and a major reason for this is that it works fundamentally differently from MRP/DRP and APS systems. These systems, which assume static (transportation mode independent) lead-times, are currently the most widely installed and their assumptions are quite naturally the accepted ones for those who work in the field. With the term “multi-echelon,” my observation is that we have yet to get past the buzzword phase into a real understanding of what multi-echelon means, at least for the majority of supply chain professionals exposed to the concept. Furthermore, the promotional activities of several vendors have commingled multi-echelon planning with the physical multi-echelon supply network, when in fact the two terms describe two different things and, as a result, have set back attempts to educate people as to the proper meaning of the word.

The Opportunity for Service Supply Chains

Multi-echelon planning software provides an excellent opportunity for service supply chains that need to ensure they keep expensive and less frequently repaired items at the RDC. However, all but the most straightforward supply chains benefit from multi-echelon functionality. Effective lead-times are the central concept in multi-echelon planning. While lead-times for the same mode between locations do not change in the short-term (in the long-term, the supply network can be reconfigured), effective lead-times are changing continuously depending on the circumstance of the demand and the stocking positions of the related locations. The effective lead-times must continually change in the application’s calculations for software to be functional for multi-echelon planning. This, combined with inventory optimization functionality, is what allows the software to properly position inventory in the right location and in the right quantity based on demand, current stocking position, and service levels.

When MEIO Calculates a Lower Stock Level

It is important that everyone involved in a MEIO implementation or trained in MEIO software understands effective lead-time and its implications for planning. I have seen cases where the implementing company did not do nearly enough to explain MEIO and the planners interpreted the implemented system as carrying insufficient levels of inventory. The directors at this company asked the planners to keep their old pre-MEIO days’ supply targets unchanged. Therefore, the effect of the MEIO implementation at this company was minimal. What was not understood is that MEIO will calculate a lower stocking level because MEIO systems can see the interactions between the locations in a way that non-MEIO systems cannot. If planners are using an older concept based upon less sophisticated mathematics as a reference point for how inventory should be calculated, they are less likely to accept the results of the MEIO system and will tend to override it, thus undermining the benefits of the system. If this happens, not only should the planners be blamed (which is a common area to be called out), but also the implementation, which did not accomplish its objective to educate both the planners and the supply chain planning decision makers. If a superior technology is given to people and they are appropriately educated as to how it works, and if it improves their condition, they will naturally gravitate toward using it. However, if they don’t understand it, and don’t know why the results it generates are different from what they are used to, they have every reason to reject it.

How Multi Echelon Mathematics Break the Traditional Assumptions of Supply Planning

For those who are being exposed to this topic for the first time, it may take several readings and several weeks to understand all the implications of multi-echelon, because of multi-echelon mathematics break with the previous assumptions held by most supply chain professionals. But “getting” something the first time should not necessarily be a goal of understanding complex subject matter. Complex subjects often require multiple exposures. Once understood, the multi-echelon method of inventory positioning in the supply network cannot help but be seen as significantly superior to the old ways of determining the best place for the stock to be positioned. Although often ignored or trivialized, multi-echelon planning is truly an equal partner to inventory optimization in MEIO.

The Problem: Preparing for Inventory Optimization

Inventory optimization projects tend to take a long time and to be a significant expense. As with most complex implementations, the actual effective usage of inventory optimization software will significantly lag after whatever the initial project plan predicts. For companies that are interested in inventory optimization, we have a simpler solution that should be tested first before investing in inventory optimization software.

A major part of getting supply planning right is setting these parameters. Testing of the extracted parameters of ERP and external supply planning systems clearly shows that these values are poorly maintained. The result is far worse planning results than could be obtained otherwise.

Being Part of the Solution: Our Evolution of Thinking on Maintaining Inventory Parameters

Maintaining inventory parameters like rounding values and lot size in systems comes with a number of negatives that tend to not be discussed. One issue is that when using ERP systems, inventory parameters are typically managed on a “one by one” basis. This leads to individual planners entering values without any consideration for how inventory parameters are set across the supply network. After years we have given up managing safety stock or other inventory parameters in we now calculate inventory parameters in our application, the Brightwork Explorer, and then simply upload the data into the ERP system. See our link below. We have developed a SaaS application that sets the inventory parameters that allow for simulations to be created very quickly. These parameters can then be easily exported and it allows for far more control over the parameters. In our testing, the approach, which is within the Brightwork Explorer is one of the most effective methods for managing planning in any system. This approach is laid out in the book How to Repair Your MRP System.

In our testing, the approach, which is within the Brightwork Explorer is one of the most effective methods for managing planning in SAP applications.

Brightwork Explorer for Service Level & Safety Stock Setting

Service Level & Safety Stock Setting

Setting service levels and inventory can be performed far more easily than is done at the vast majority of companies. Click the image to see how.

Search Our Other Supply Chain Optimization Content

References

Steve Wedell, MCA Solutions

The white paper written by Dr. Calvin Lee. Calvin Lee was one of the originators of Evant, a software company that focused on inventory optimization.

Dr. Lee’s white paper can be found  here: https://www.gsb.stanford.edu/scforum/login/pdfs/MEIO_whtppr.pdf

Evant was purchased by Manhattan Associates for $50 million, and they rebranded some of Calvin’s work as their own.

https://www.eweek.com/c/a/IT-Management/Manhattan-Associates-to-Acquire-Evant/

MEIO Book

What is MEIO?

This book explains the emerging technology of inventory optimization and multi-echelon (MEIO) supply planning. The book takes a complex subject and effectively communicates what MEIO is about in plain English terms. This is the only book currently available that describes MEIO for practitioners, rather for mathematicians or academics.

The Interaction with Service Levels

The this book explains how inventory optimization allows the entire supply plan to be controlled with service levels, and how multi-echelon technology answers the question of where to locate inventory in the supply network.
This is the only book on inventory optimization and multi echelon planning which compares how different best of breed vendors apply MEIO technology to their products. It also explains why this technology is so important for supply planning and why companies should be actively investigating this method.
The book moves smoothly between concepts to screen shots and descriptions of how the screens are configured and used. This provides the reader with some of the most intriguing areas of functionality within a variety of applications.
Chapters
  • Chapter 1: Introduction
  • Chapter 2: Where Inventory Optimization and Multi-Echelon Planning
  • Fit within the Supply Chain Planning Footprint
  • Chapter 3: Inventory Optimization Explained
  • Chapter 4: Multi-Echelon Planning Explained
  • Chapter 5: How Inventory Optimization and Multi-Echelon Work
  • Together to Optimize the Supply Plan
  • Chapter 6: MEIO Versus Cost Optimization
  • Chapter 7: MEIO and Simulation
  • Chapter 8: MEIO and Service Level Agreements
  • Chapter 9: How MEIO is Different from APS and MRP/DRP
  • Chapter 10: Conclusion
  • References
  • Vendor Acknowledgements and Profiles
  • Author Profile
  • Abbreviations
  • Links in the Book
  • Appendix A: MEIO Visibility and Analytics
  • Appendix B: The History of Development of MEIO Versus MRP/DRP