The Four Factors that Make Up the Master Schedule for the Supply Plan

Executive Summary

  • Four planning controls define the master schedule. These are the constraints, the timing, a limited number of products and a limited BOM explosion, but it is necessary to consider why this is the case.
  • We explain these areas as well as how the master schedule is related to S&OP.


Different companies use the term Master Schedule or Master Production Schedule (MPS) in often inaccurate ways. In the vast majority of cases, it is not the official definition of the term. In many cases, it is used interchangeably with the term MRP or even the forecast, which is incorrect. It turns out that Wikipedia has a reasonably good definition of the MPS.

“A master production schedule (MPS) is a plan for individual commodities to be produced in each time period such as production, staffing, inventory, etc.[1] It is usually linked to manufacturing where the plan indicates when and how much of each product will be demanded.[2] This plan quantifies significant processes, parts, and other resources in order to optimize production, to identify bottlenecks, and to anticipate needs and completed goods. Since an MPS drives much factory activity, its accuracy and viability dramatically affect profitability. Typical MPSs are created by software with user tweaking.”

However, Wikipedia falls a bit short in drawing a distinction between the MPS and other plans.

An MPS run is a combination of four things that relate to product, timing, constraining and the BOM. These are listed below:

  • Product: A subset of the overall product database.
  • Timing: Run ahead of the initial supply planning run.
  • Constrained: MPS runs are constrained, which of course is not possible with MRP (which is strange then that MPS is a type of MRP run.)
  • BOM: The Bill of Material is not exploded with the master schedule.

Why These Four Factors?

These factors make up the master schedule because it allows the master schedule to be created as almost a simulation run. The reason for each factor is included below:

A Subset of the Overall Database

The reason for making the MPS run a subset of the overall product database is twofold.

  1. The first reason is that the MPS run is to only be for critical parts.
  2. A second reason, which is now dated, is that earlier computer system was limited in processing capabilities, and order to get the MPS to run in a timely manner, and possibly to run it multiple times, it was important to limit the amount of data the system had to process.

This leads to a related topic of whether MPS itself is an anachronism, which is covered in this article.

Why Constraints?

This makes the master schedule more realistic. However, this is more of an additive factor. The master schedule runs tend to be constrained, but of course, a constrained planning run could lack any of the other three factors and not be a master schedule.

Why Timing?

The MPS must be run before the network or initial planning run.

Obviously, a simulation run like the MPS would make little sense if it were run after or at the same time as the initial planning run.

Why Limited BOM Explosion?

This is well described by a quote from SAP.

“In the MPS menu there is a separate single-level planning run, which can be executed as single-item planning or total planning. This planning run only includes the master schedule items. Dependent requirements are created for the BOM level directly below the planning level. Levels below this, however, are not planned. This means that the MRP controller can authorize any changes to the master plan before they affect the various BOM levels.” – SAP Help

Interestingly, the sentence in blue is no longer a selling point of MPS, as it assumes that the system does not have a simulation environment. That is a copy of the system model that connects to the user interface). However, with modern systems, simulation environments can be used to perform planning at any level of detail without affecting the “production” instance.

For more on MPS see this article.


MPS is used in a way by most companies in a way that does not meet the definition of MPS. Now the MPS has transformed to mean the initial planning run. Many of the purposes of an MPS can now be fulfilled with a simulation version which is not limited in any way regarding is BOM explosion or the segmentation of the product database. Beyond that, most companies do not have an MPS process or an S&OP process for that matter. So many terms are being used describe things companies do not do.

The vast majority of companies are just reacting and running their planning systems as short-term planning systems. They are not doing many of the sophisticated things that are often read about in books. The fact that they are using expensive systems does not change how the systems are used in practice.

Search Our Supply Planning Articles

Supply Planning Research Contact

  • Interested in Our Supply Planning Research?

    The software space is controlled by vendors, consulting firms and IT analysts who often provide self-serving and incorrect advice at the top rates.

    • We have a better track record of being correct than any of the well-known brands.
    • If this type of accuracy interests you, contact us and we will be in touch.

Brightwork MRP & S&OP Explorer for Constraining

Improving Your Constraint Planning

Brightwork Research & Analysis offers the following supply planning tuning software with a new approach to managing capacity constraints, which is free to use in the beginning. See by clicking the image below:


Capacity Planning Book

Combining Two Types of Capacity Planning

This book is called capacity management because it encompasses two areas of planning that are usually discussed independently. Short-term capacity leveling or capacity constraining, which is the movement of demand to fit within the available supply, and long-term capacity planning. This is the planning of long-term market demand to determine if the capacity should be changed.

Using Comparative Applications

In this book, both topics are covered, and they are included using multiple software applications to explain the concepts of capacity management. These are two closely related processes. However, they are often discussed separately. This book combines their explanation as well as their relationship to one another.

By reading this book you will learn:

  • How resources are modeled in capacity management systems.
  • How the structured nature of capabilities leveling and constraining differs from capacity planning.
  • How the various planning processes fit into one another, and where the gaps can be found.
  • The time horizons of the capacity management process.
  • How to improve capacity management at your company.


  • Chapter 1: Introduction
  • Chapter 2: Capacity Leveling
  • Chapter 3: Constraint Based Planning
  • Chapter 4: Resources
  • Chapter 5: Forecast Consumption, Allocation, Scheduling Direction and Timing
  • Chapter 6: Capacity Planning with S&OP and the MPS
  • Chapter 7: The Relationship Between Planning Systems and S&OP System
  • Conclusion

Setting the Right Inventory Carry Cost Percentage

Executive Summary

  • Inventory carry cost is a controversial topic because of the assumptions.
  • We cover how to properly set the inventory carry cost.


Inventory carry cost is necessary for the supply chain as it allows a company to determine its costs of keeping inventory. It is also a key input into the economic order quantity, which in its base formulation (there are many EOQ formulas) trades off the cost of carrying inventory versus the cost of ordering inventory. EOQ sounds like a very straightforward formula until you ask companies to estimate their inventory carry cost and order cost.

Inventory Carrying Cost Inputs

You generally cannot simply go to the finance department in a company as they tend to know the cost of money, or the capital cost of the company, but not the other costs associated with inventory carry cost. This is a combined cost which accounts for:

  1. The cost of capital
  2. The cost of the storage facility for the product
  3. The cost of the product becoming obsolete or going bad (say as in in the case of perishables)
  4. The cost of the product being damaged while being stored

Experience in Estimating Inventory Carry Cost

I have asked about this value for many clients to perform modeling and create EOQ driven ordering quantities and frequencies. They almost always tell me that they don’t have a good number. They then ask me if I know of one.

George Plossl does a good job of explaining the arbitrary nature of such estimations in the book.”

Production and Inventory Control.” I have a quote from the book below:

“Inventory Carrying Cost: The inventory carrying cost is a useful concept (albeit an artificial one) required by the mathematical formulas used in lot-sizing calculations. As listed earlier, many separate elements are assumed to make up this cost. Obsolescence is a reality in any inventory but this cost element in the inventory carrying cost varies widely with time and is not the same for different items in an inventory (that is, it is highest for style items). This would indicate that a different carrying cost might be used for each item in the stock list. This is obviously impractical and an average figure is usually chosen, either for all products or for each major type of product. Identical reasoning applies to deterioration costs. The whole discussion is purely academic. The inventory carrying cost has practical use only as a management policy variable which, rather than being a fixed. magic number, is one that should be manipulated to attain the overall objectives of the company. “ George Plossl

Estimating Inventory Carrying Cost

Inventory carrying cost is an estimation of the percentage of the product cost that in consumed in holding the product for one year. It is often used in inventory formulas as well as cost optimization. In many popular articles that cover the subject superficially, it is often stated that a good inventory carrying cost is between 20 to 25%.

I could spend lots of time estimating this for each company, as pointed out by George Plossl, the value would always be an average. And will be too high for some products and too high for others. The major item I look for is how perishable the company’s product is. If it is more towards the perishable end of the spectrum, I increase the inventory carry cost; If it is not, I decrease the inventory carry cost.


One of the current (2016) issues with using a value between 20 and 25% is that they have tended to be created when interest rates and inflation (which is built into interest rates) was higher. Therefore, those companies that use the higher figure would tend to overestimate inventory carry cost. One of the perplexing things about using quantified values for both order cost and inventory carry cost is that the order quantities become much higher than is “politically acceptable” within companies.

This is one reason that companies often ignore quantification of order quantities and determine the order quantity using judgment methods.

See our EOQ calculator at this link.

Also, learn about the limitations of EOQ at this link.

Search Our Supply Planning Articles

Supply Planning Research Contact

  • Interested in Our Supply Planning Research?

    The software space is controlled by vendors, consulting firms and IT analysts who often provide self-serving and incorrect advice at the top rates.

    • We have a better track record of being correct than any of the well-known brands.
    • If this type of accuracy interests you, contact us and we will be in touch.

Brightwork MRP & S&OP Explorer for Order Optimization

Order Sizing and Optimization

Order optimization is necessary in order to get the predicted value from ERP and other supply planning applications. The Brightwork MRP & S&OP Explorer does exactly this, and it is free to use in the beginning until it sees “serious usage.” It is permanently free to academics and students. See by clicking the image below:


Production and Inventory Control: Techniques and Principles 2nd Edition,” George Plossl, Prentice Hall, 1985

Lean and Reorder Point Planning Book

Lean and Reorder Point 2

Lean and Reorder Point Planning: Implementing the Approach the Right Way in Software

A Lost Art of Reorder Point Setting?

Setting reorder points is a bit of a lost art as company after company over-rely upon advanced supply planning methods to create the supply plan. Proponents of Lean are often in companies trying to get a movement to Lean. However, how does one implement Lean in software?

Implementing Lean in Software

All supply planning applications have “Lean” controls built within them. And there are in fact some situations where reorder points will provide a superior output. With supply planning, even within a single company, it is not one size fits all. The trick is understanding when to deploy each of the approaches available in software that companies already own.

Are Reorder Points Too Simple?

Reorder points are often considered to be simplistic, but under the exact circumstances, they work quite well.

There are simply a great number of misunderstandings regarding reorder points – misunderstandings that this book helps clear up.

Rather than “picking a side,” this book shows the advantages and disadvantages of each.

  • Understand the Lean Versus the MRP debate.
  • How Lean relates to reordering points.
  • Understand when to use reorder points.
  • When to use reorder points versus MRP.
  • The relationship between forecastability and reorder points.
  • How to mix Lean/re-order points and MRP to more efficiently perform supply planning.


  • Chapter 1: Introduction
  • Chapter 2: The Lean versus MRP Debate.
  • Chapter 3: Where Supply Planning Fits Within The Supply Plan
  • Chapter 4: Reorder Point Planning
  • Chapter 5: Lean Planning.
  • Chapter 6: Where Lean and Reorder Points are Applicable
  • Chapter 7: Determining When to use Lean Versus MRP
  • Chapter 8: Mixing Lean and Reorder Points with MRP-Type Planning

Software Ratings: Supply Planning

Software Ratings

Brightwork Research & Analysis offers the following free supply planning software analysis and ratings. See by clicking the image below:


What If You Paid Nothing for SAP Software: Supply Planning

Executive Summary

  • TCO can be calculated with a number of different assumptions.
  • We estimate SAP’s TCO if the license cost is removed.

Background and Motivation for the SAP TCO Research

When I am often told about the reasons for decisions to go with software that I am familiar with, the logic often does not seem to make sense.

The main comparison points of enterprise software are the TCO and the application’s functionality. However, companies primarily look for solutions from vendors that they are already working with and then allow the issue of integration to play a primary decision-making role. Therefore, they essentially ignore TCO (most tend to make decisions without knowing the estimated TCO), focusing more on initial software acquisition cost, and de-emphasize the functionality comparison between applications

The Basis for Estimation

I visit clients often post go-live on SAP APO and have developed a good sample of companies. I know the typical length of an APO implementation, as well the costs of maintaining APO. I also work with some best-of-breed vendors. Because I had access to information from several important sources and was able to make times estimations based on personal experience, I decided to perform a total cost analysis between SNP and a best of breed supply planning vendor.

The Scope of the Analysis

This analysis is limited to the major planning applications. I have developed estimates for costs of APO modules versus best-of-breed applications for the areas which I have first-hand knowledge, which is demand planning, supply planning, service parts planning and production planning and scheduling.

Why SAP License Costs are Set to Zero

SAP license costs are difficult to determine. There is little doubt they have some of the highest average license costs in the enterprise market, but their application pricing dramatically fluctuates. Additionally, the pricing ‘s hard to determine for one application because it may be bundled with other software. Regarding publicly available rates, SAP has a government price sheet. However, the price sheet is based on an arcane point system that is designed not to allow anyone to calculate a price independently, but at the same time meeting the US government requirement that they have a price sheet. I worked with this sheet for around an hour and a half, and then realized, it was not meant to be deciphered.

SAP license costs are shrouded in mystery. However, when I performed the analysis, even without SAP license costs, I found SAP TCO costs to be so high that even without any license costs or SAP support costs (which are based upon the license costs) the best of breed vendors were still easily beating SAP TCO in all the application areas.

Secondly, any article which does not rank SAP as #1 in whatever it is being compared with is open to immediate criticism. (In fact, the easiest way to have a soft life in IT is to skip any analysis and declare SAP the victor. In doing this, you are not required to provide any evidence, but simply say something like “SAP supports best practices.”) On the other hand, one can denigrate best of breed applications on the most feeble grounds and receive glowing reviews. However, criticize SAP, and you can expect criticism in return. Therefore, to counteract this concern with bias, I decided to tilt the playing field in SAP’s direction by making all of the license costs free. So this analysis assumes you never had to pay anything for SAP’s software or their support. Doing this does one other thing, it emphasizes the point that the license cost should not be the primary focus of the comparison and that other costs predominated in the TCO. Therefore, free software can end up being not the best decision.

Analysis Assumptions

There are some assumptions in this analysis. One of the most important is the duration of the implementation. This is one of the trickier things to set. Software companies tend to deemphasize this number, which is why I had to use my experience to adjust the results to what I have seen. SAP implementations take the longest of any enterprise vendor, and there are excellent reasons for this, which I get into later in this article.

However, for both SAP and the best-of-breed vendor, I have included a range and the estimated TCO for each regarding implementation is based upon an average. There is no perfect analysis of this type that can be created because of all the different variables. However, not being able to attain perfection should not get in the way of attempting estimation. This is logically correct, but also one way or another, these types of analyses must be performed, and I always think it’s better to take a shot at estimation rather than to throw one’s hands up and say its unknowable.

The TCO Analysis

This TCO analysis has been permanently moved to this link

According to this estimate, the SAP TCO is higher than the best of breed application I compared it against. Having worked in SAP as long as I have, I intuitively I knew the SAP TCO would be higher, but even I was surprised by how much higher it was. Here are some of the reasons.

SAP’s Implementations take Significantly Longer than Best of Breed Implementations

  1. SAP’s software is tough to understand and is highly encapsulated. SAP has so many settings which allow the system to behave in different ways that extensive time must be spent in both learning the settings and understanding the interactions between the configuration. The statement that SAP is filled with “best practices,” is incorrect, because a best practice approach prescribes that the system defines specific ways of doing things, when in fact, SAP follows the “comprehensive approach.” This includes a seemingly unlimited number of ways of configuring the system.
  2.  SAP’s marketing and product management strategy are to cover functionality as broadly as possible so they can always say “we have it.” This same development approach spans across applications, as I observe the same thing in different product lines such as SAP BW. This is one reason SAP’s TCO is probably headed even higher in the future. What will eventually bring SAP down is when it becomes so complicated that their applications are no longer maintainable, or when a major technology shift, such as SaaS, impacts the enterprise software market that undermines SAP’s natural monopolistic advantages. However, the long story short on this topic is that product management is writing checks that development cannot cash. Testing each area of functionality to ensure (part of what I do by the way) imposes more work and more time on the implementation.
  3. The large consulting companies have built their business model around SAP and extended the time of SAP implementations to maximizes their billing hours. SAP made a strategic decision quite some time ago to let the consulting companies control the speed of implementation to be recommended by the major consulting firms, regardless of the fit between the application and the client need.

SAP Resources Are More Expensive

  1. There is nothing controversial about this statement; it is well-known in IT circles.

SAP Has a Higher Manpower Support Requirement

  1. Getting back to the topic of application complexity and fragility, SAP only takes more resources to maintain. Something I recently had to work with was one method which was part of the functionality that did work but stopped working as of the release SCM 7.0. First, the problem that cropped up due to this needed to be diagnosed and explained (we did not find out about the broken functionality but perceived it through system problems. Once discovered, this functionality had to be changed to a method that did work, and the business had to invest time creating a new policy to work with the changed functionality. This was course expensive and time-consuming.

Integration is Overrated as a Cost

The cost differences between SAP and a best of breed application are quite large, and the frequently used argument, that the company wants an integrated solution, cannot reasonably be used to justify a decision to select SAP. I have not broken out the integration separately, as it is built into the consulting costs, but an adapter of even a few hundred thousand dollars would not tip the TCO in SAP favor. Also, the maintenance of the SAP CIF (the middleware that connects R/3 to APO) is vastly underrated. My experience and with developing custom adapters for connecting best of breed planning applications to SAP, I have become firmly convinced that the cost of maintaining the CIF is more than the cost of developing and maintaining a custom adapter. The CIF, which connects up APO to SAP ERP is unacceptably problematic.

Implication for ROI

According to most publicly available studies, around 1/2 of projects have a positive return on investment. However, this greatly depends upon the TCO of the solution and the functionality of the application that can be leveraged. SAP planning modules are so expensive compared to alternative solutions, and deliver a lower functionality level than the best-of-breed solution, that as a natural consequence they have a lower ROI and a lower percentage of positive ROI projects. However, the incorrect perception in the industry is just the opposite; that SAP is the safe vendor to choose.

Outsourced Support to Reduce Costs?

Companies now often outsource a portion of their support to India, so one might imagine that the support costs listed here could be reduced.

This is another frequently held assumption but does not prove out in reality. A good rule of thumb is that while the India-based resource is about 1/4rth as expensive, it takes more than twice as many individuals to get close to the same amount of support work done. Secondly, there must always be at least one in the country resource. Thirdly, this is a mess to manage. There are not only language and time barriers, but it appears some of the companies providing these resources are double booked the same resource on multiple clients. I have been dealing with this issue for several years now, and I end up having to read notes from the support team which is not spelled properly because of language barriers.

Outsource operations lack good professional management, and the client resources end up having to take over support organization tasks. I am not sure outsourced support works for any area very well, but it particularly unsuited to complex systems such as planning applications. When support is outsourced, the quality of support drops precipitously, and anyone in IT knows this. I provide a full treatment of the pitfalls in outsourcing SAP APO support in this article.

Implications of the Analysis

Indeed, other analysis with different assumptions will have different results. However, the TCO differential is so high between SAP and a best of breed solution, that it ‘s hard for me to envision any analysis where SAP has close to the same TCO as a best of breed solution. This means that SAP’s planning products cannot be justified by TCO and that companies must be able to obtain something from SAP that they cannot obtain from a best of breed application. Companies should be cognizant of the significant premium they are paying for SAP TCO.


If you confront SAP and large consulting firms and ask for a proper SAP TCO analysis, be prepared for a dispute on the true cost of their software and time required to go live. It is critical to make your decisions based on actual observations at multiple accounts. As I have in this article, and not based on hypothetically sales estimates from their sales team on how fast a solution can be brought live.

I have done the best job I could to bring the real world data to my estimates, and I even stacked the deck for SAP by removing all license costs, but the SAP TCO is still higher. By the way, this was also true in the other application areas I analyzed. The real world data shows across the board that SAP TCO is significantly higher than best-of-breed solutions.

Search Our Supply Planning Articles

Supply Planning Research Contact

  • Interested in Our Supply Planning Research?

    The software space is controlled by vendors, consulting firms and IT analysts who often provide self-serving and incorrect advice at the top rates.

    • We have a better track record of being correct than any of the well-known brands.
    • If this type of accuracy interests you, contact us and we will be in touch.


I cover TCO in detail in the following book.

TCO Book

Enterprise Software TCO: Calculating and Using Total Cost of Ownership for Decision Making

Getting to the Detail of TCO

One aspect of making a software purchasing decision is to compare the Total Cost of Ownership, or TCO, of the applications under consideration: what will the software cost you over its lifespan? But most companies don’t understand what dollar amounts to include in the TCO analysis or where to source these figures, or, if using TCO studies produced by consulting and IT analyst firms, how the TCO amounts were calculated and how to compare TCO across applications.

The Mechanics of TCO

Not only will this book help you appreciate the mechanics of TCO, but you will also gain insight as to the importance of TCO and understand how to strip away the biases and outside influences to make a real TCO comparison between applications.
By reading this book you will:
  • Understand why you need to look at TCO and not just ROI when making your purchasing decision.
  • Discover how an application, which at first glance may seem inexpensive when compared to its competition, could end up being more costly in the long run.
  • Gain an in-depth understanding of the cost, categories to include in an accurate and complete TCO analysis.
  • Learn why ERP systems are not a significant investment, based on their TCO.
  • Find out how to recognize and avoid superficial, incomplete or incorrect TCO analyses that could negatively impact your software purchase decision.
  • Appreciate the importance and cost-effectiveness of a TCO audit.
  • Learn how SCM Focus can provide you with unbiased and well-researched TCO analyses to assist you in your software selection.
  • Chapter 1:  Introduction
  • Chapter 2:  The Basics of TCO
  • Chapter 3:  The State of Enterprise TCO
  • Chapter 4:  ERP: The Multi-Billion Dollar TCO Analysis Failure
  • Chapter 5:  The TCO Method Used by Software Decisions
  • Chapter 6:  Using TCO for Better Decision Making

The Probability of Success of Different Supply Planning Methods

Executive Summary

  • What are the Different Supply Planning Methods?
  • How does each Supply Planning Method Stack up in Terms of Implementation Success?
  • What does the Complexity of the Supply Planning Method used Have to do with Implementation Success?

Selecting software, and the method within the software primarily by both brand and simply the hypothetical capability of the software, without considering the company’s ability to implement complex systems, and the experiences and difficulties that other companies have had with the more complex supply planning methods do not make a lot of sense.


The various methods of supply planning for advanced planning and scheduling are very different from one another. These methods, which are heuristics, allocation and cost optimization also differ greatly in their likelihood of being implemented successfully. During the software selection phase, typically a method is selected based on how well it meets the business requirements. Something which is left out of this analysis is the probability of success of the methods.

If one method provides all the things your business wants, but the company lacks the funding or expertise, or sustainable orientation to bring up a solution, it makes more sense to select a solution which can be implemented. It is extremely rare that I find that companies correctly estimate their abilities to bring up complex solutions. For instance, in the area of support, it is becoming increasingly common for companies to outsource support to India. 

However, the outsourced model was never designed for complex solutions like supply planning APS solutions which are some of the most complex systems that a company has.

Resolving issues requires a detailed understanding of the issues, domain expertise, the configuration history, etc.. It is not simply performing a password reset. Therefore, if a company wants to use outsourced support, to also not provide sufficient internal personnel for the implementation, etc…then the company should move towards an easier APS method and one which has a higher probability of success.

How the Different APS Methods Compare in Terms of Probability of Success


Heuristics have a very high success rate. The SAP SNP Network Heuristic is about as easy to use as MRP but has extra settings that require some analysis and troubleshooting. The SNP Heuristic is extremely fast and can be run as many times as per day because the heuristic provides the same result if it is run for the overall network as it does if it is run for a single location or a single product location combination. The SNP heuristic can also be run interactively which allows it to provide an instant update on the new situation.

CTM and Cost Optimization

However, there is a significant drop off in the success of the more complex methods which include allocation and cost optimization. Few companies have success with allocation or cost optimization. This is because this method is complex. There are both many screens of settings on each of these methods, but also these methods require detailed configuration and master data maintenance in the area of resources, as most companies that select these methods are interested in performing constraint-based planning.

Additionally, allocation requires the development and maintenance of a table which declares which customers should receive inventory over others. In cost optimization, costs must be developed and maintained for the transportation costs between locations, the storage costs at a location, the costs of violating (dipping into) safety stock, the cost of production, and the costs of missing a demand.

All of this entails work, and this work must be appropriately staffed. It also requires a clear understanding and clear declaration of the policies and communication of these policies to the individuals who are maintaining the configuration and master data.


While APS offers many more settings and more functionality, it has not had as high implementation success rates as MRP/DRP, which at this point are nearly universal within companies of any substantial size. The reasons why can vary as much as the specific method of APS implemented (heuristic, cost-based optimization, or allocation), and the probability of success differs very significantly between with heuristics being on one side of the continuum, and cost-based optimization and allocation being on the other.

However, as a general statement, the APS has been criticized for being overly complex, which I also agree with. Part of the complexity is due to the method. However, the fact that some solutions like SAP SNP are so complex has to do with the decision made by a development organization. This is connected to another topic, which is that companies do not seem to be selecting for software that has been naturally designed to be easily implemented.

Companies that try to reach for a more complex method, without providing the necessary preconditions, are worse off than if they had selected a more simple method. This is why it is so important to understand the differences in the probability of success between the different methods. It is also important to know how easy or difficult the particular software application is to configure and maintain and relating this back to an honest appraisal of how effective the company has been in the past in implementing complex systems before making a software selection decision.

Search Our Supply Planning Articles

Supply Planning Research Contact

  • Interested in Our Supply Planning Research?

    The software space is controlled by vendors, consulting firms and IT analysts who often provide self-serving and incorrect advice at the top rates.

    • We have a better track record of being correct than any of the well-known brands.
    • If this type of accuracy interests you, contact us and we will be in touch.


Supply Planning Book


Supply Planning with MRP, DRP and APS Software

Showing the Pathway for Improvement

Supply planning software, and by extension supply planning itself, could be used much more efficiently than it currently is. Why aren’t things better?

Providing an Overall Understanding of Supply Planning in Software

Unlike most books about software, this book showcases more than one vendor. Focusing an entire book on a single software application is beneficial for those that want to use the application in question solely. However, this book is designed for people that want to understand supply planning in systems.

  • What methods fall into APS?
  • How do the different methods work and how do they differ in how they generate output?
  • What is the sequence of supply planning runs?

These types of questions are answered for readers in this book.

This book explains the primary methods that are used for supply planning, the supply planning parameters that control the planning output as well as how they relate to one another.

Who is This Book For?

This book as a practical primer for anyone looking to perform a supply planning software selection, any person beginning a supply planning project, or anyone who just wants to understand supply planning software simply better.


  • Chapter 1: Introduction
  • Chapter 2: Where Supply Planning Fits Within the Supply Chain Planning Footprint
  • Chapter 3: MRP Explained
  • Chapter 4: DRP Explained
  • Chapter 5: APS Supply Planning Methods
  • Chapter 6: APS for Deployment
  • Chapter 7: Constraint-based Planning
  • Chapter 8: Reorder Point Planning
  • Chapter 9: Planning Parameters
  • Chapter 10: How MRP, DRP, and APS Relate to One Another
  • Chapter 11: Supply Planning Visibility and Master Data Management
  • Chapter 12: Understanding the Difference Between Production Versus Simulation