A Sensitivity Analysis Approach for Supply Chain Optimization
Executive Summary
- In the supply chain, sensitivity analysis is related to S&OP.
- External optimizers are available for sensitivity analysis, and we cover how this all works.
Companies that do not perform sensitivity analysis can be in the dark about how many capital improvements in any one constraint will improve their operations.
The Definition of Supply Chain Simulation?
Simulation is a planning run, which may be performed on the production system (in a simulation version, or in a separate simulation environment–in the same software or in different software), which is not intended to have its recommendations sent to the ERP system for execution. The results are analyzed within the planning system, and the planning run is frequently performed with repetitive checks to the results and often changes to master data parameters. Simulation is sometimes performed on different hardware, or on different instances of the application but on the same hardware.
This definition is taken from my book Supply Planning with MRP/DRP and APS Software.
Introduction to Constraints
As is discussed in other articles on this blog, sensitivity analysis – which is the study of how the solution changes depending upon changes to different variables. The objective is to find ranges of change where the solution is “sensitive” to changes in the variables – which is not often performed in supply chain optimization.
Instead, companies show a strong preference for using optimizers by feeding them unchanging constraints. Sensitivity analysis is one of the major benefits of optimization, but it is not part of the supply planning process. Instead, it is part of the S&OP process. Supply planning plans within the constraints, while S&OP and strategic planning generally plan for demand, observe limitations, and then determine if it is profitable to increase the system’s capacity through investment.
Production Systems Versus Strategic Systems
Because of this dichotomy between S&OP and standard supply planning, enterprise vendors that offer optimizers within supply planning applications do not direct their applications towards sensitivity analysis. On the other hand, most companies do not use general optimizers (such as CPLEX, MATLAB, or even Frontline Solver) to perform sensitivity analysis. Instead, strategic decisions regarding constraints are made with spreadsheets. Even without sensitivity analysis tools in enterprise solutions, companies have several excellent options for performing sensitivity analysis. I have these options listed below:
- Create a simplified optimization model in a general solver
- Run the enterprise optimizer in simulation mode and gather the solution points to develop a graphic for a particular variable/constraint to output combination
For more details on general solvers, see this article.
The Difficulty in Convincing Companies to Buy Strategic Optimizers
Each approach has positives and negatives. Most companies are typically opposed to bringing in and purchasing a second optimizer for any supply chain planning area. This is because they are told that they can get everything they need from their enterprise optimizer. (To be clear, even companies that do not use optimizers for their production systems can still use optimizers for sensitivity analysis.) Therefore, when approached with another optimization purchase, they typically dig in their heels. However, while using an enterprise optimizer for sensitivity analysis is politically easier to get through, this approach often does not scale very well and ends up consuming resources that were already allocated to merely maintaining the production system.
Secondly, enterprise optimizers tend to (I say tend to because some enterprise optimizers are better than others in simulation) be less effective in sensitivity analysis than either general solvers or spreadsheet-based solvers. Therefore, what the company gains in reduced software costs and fewer skill sets (using another optimizer often requires a separate resource or the cross-training of one resource) they lose efficiency. An important related issue is that general optimizers are multi-purpose, as they can also be used to verify production optimizers as described in this article.
There is an important distinction between optimizers in enterprise software versus optimizer engines/solvers in modeling languages. The following quote is instructive:
The reason for preferring C and C++ may also lie in the fact that in software companies such as SAP or i2 Technologies, far more people are found with a computer science background than a mathematical programming background. In the latter community modeling languages are more frequently used supporting the concept of strictly separating the data, model and solution methods. – Real Optimization with SAP APO
However, if SAP APO would become open in the sense that the user can access the variables and constraints, a modeling language would definitely be the better choice. A modeling language would also make it easier to modify and extend the predefined model – Real Optimization with SAP APO
Open modeling languages/solvers include applications like CPLEX and MatLab. In these applications, the actual mathematics is visible to the user and can be adjusted. With enterprise software, the mathematics is proprietary. The implementing company can only understand the optimizer from the documentation that the vendor makes available and from observing the optimization results. This is a fundamental difference between enterprise software optimizers and modeling languages. Other differences are also explained:
When it comes to optimization, standard business software products such as SAP APO do not offer LP and MILP modeling per se on the equation level, but provide a standard MILP formulation suitable for a wide variety of real-world problems that is configured by manipulating data objects in the business application. Hardly anywhere (are) terms such as variable or constraint can be found. The modeling parameters are set by defining supply chain related objects such as product,s location, transportation lanes, lot sizes, resource capacities, etc.. – Real Optimization with SAP APO
Therefore the modeling is stated in very business-oriented terms, with the actual mathematics hidden and the terminology of modeling languages like MatLab mostly unused.
Sensitivity Analysis
Most solvers can perform sensitivity analysis. This allows the modeler to gain insights into the relationships between the variables. This is another important use of optimization, which is to gain a deeper understanding of the problem. This is particularly beneficial in determining the benefits of changing constraints. For instance, merely running an optimizer can tell you the best decisions to take; however, it can be extremely beneficial to alter the constraints that change the assumption of the optimizer in many cases. In supply chain planning, this can mean adding warehouse space. When running in production, a supply network optimizer will respect a constraint placed on a location and stop sending it material after it has reached this cap. However, the strategic use of an optimizer, which had sensitivity analysis, would tell the modeler how the optimal solution changes by increasing the warehouse’s capacity. This is one example, but any constraint can be analyzed in this way, and it is a secondary use of the optimizer that is quite rarely used in supply chain planning.
Sensitivity analysis is important from a practical perspective. Because we seldom know all of the parameters in a model with perfect accuracy, it makes sense to study how results would differ if there were some differences in the original parameter values. If we find that our results are robust–that is, a change in a parameter causes little or no change in our decision–then we tend to proceed with some confidence in those decisions. – Optimization Modeling with Spreadsheets
Enterprise optimization software tends not to focus on sensitivity analysis usually will have few tools to help the modeler in this regard. Instead, the objective enterprise optimizers are to use them to run the business. Enterprise optimizers also have their mathematics hidden from the modeler. However, sensitivity analysis can be done by making adjustments to the master data parameters in successive runs, or what is generally known as simulation.
How Far is an Optimizer Solution from the Optimal?
One common question is both what percentage of the overall solution was optimal. This percentage is determined by the number of sub-problems that the optimizer broke the problem down into and what percentage of those solved optimally (i.e., met the objective function). For instance, the optimizer in SAP SNP breaks issues by product. So if a company has 1000 products, SNP divides that into 1000 sub-problems. Each sub-problem is, in essence, a sub-network of all locations that pertain to that product.
Distance from Optimal
The SNP optimizer log shows the percentage of problems that met the objective function and were therefore solved optimally and those that did not. So if 500 sub-problems of the 1000 total solved optimally, the percent optimally solved is 50%. However, what is left out is how far the remaining problems were from being solved optimally. This is displayed graphically below:
Sub-problem A and sub-problem B both failed to solve optimally. However, B is a better solution than A. Unfortunately, it is not possible with SNP to determine the percent the recommended solution is away from the optimal solution. If the system knew the optimal solution, it could merely select it. This brings up an interesting topic of how the optimizer knows that the solution is not optimal in the first place.
Finding a Feasible Solution
When an optimizer is unable (for whatever reason) to find an optimal solution (customarily called “feasible, not optimal”), it will still generate a solution. However, it isn’t easy to know how far that solution is from the optimal solution and the difference between them. The optimal solution is not made apparent in the diagnostic tools available with the SAP SNP optimizer or other spreadsheet optimizers I have used in the past.
The Shadow Price in Supply Chain Optimization
The shadow price is one of the central concepts in a sensitivity analysis (Which analyzes how the solution changes depending upon changes to different variables, the objective being finding ranges of change where the solution is “sensitive” to changes in the variables. This can provide quantitative support for things like investing in certain business areas to increase specific constraints.)
The Shadow Price as the Specific Change in the Optimization’s Objective Function
While sensitivity analysis is the term used to describe the overall process of analyzing the relationship between constraints and the objective function, the shadow price is the specific change in the objective function.
Change or “Relaxing” the Constraint
I am using the term change, but the technical definition is to “relax” a constraint. Constraint relaxation is not only used for sensitivity analysis; it is also an essential strategy for troubleshooting a lengthy optimization runtime.
For instance, constraints A, B, and C had the following shadow prices:
- A = 1
- B = 2
- C = 3
The constraint to investigate for adding more capacity would seem to be C. This is because it has the highest break-even price, and that objective function is most sensitive to an increase in C.
But this is only the price at which it would be attractive to add more capacity, it does not say, and the optimizer does not know the actual cost to add capacity to C.
Adding Hypothetical Costs
The actual costs to add capacity of each could be the following:
- A = 1.2
- B = 1.6
- C = 3.2
In this scenario, B becomes the constraint to add capacity to, as it the only restriction with an actual cost with a lower value than the shadow price.
How Much More?
However, sensitivity analysis of this type only holds for one optimization and one setting of constraints. For instance, if more capacity is added to B, there will eventually come when the other variables become advantageous to add capacity. This is shown in the sensitivity model’s output along with its RHS (value on the right-hand side of the inequality).
Therefore the output of sensitivity analysis for these variables might look like the following:
The allowable increase column tells the modeler how much more capacity can be added before the shadow price decreases. Under the assumption above, where B is where the capacity is to be added, the shadow price applies up to 100 units. Beyond that, the shadow price decreases.
The Importance of Good Terminology in Sensitivity Analysis
In supply chain analysis and planning, the term shadow price is relatively rarely used. This should naturally be expected as sensitivity analysis is also seldom performed. Sensitivity analysis is not typically output from enterprise optimizers. And enterprise optimizers are the predominant software in supply chain planning.
Obscuring the Truth of Optimization
Companies tend to have tunnel vision when it comes to optimization. They are told, and they tend to believe enterprise vendors tell them that the only solution they need is the vendor’s solution. It is not explained that general optimization solvers or spreadsheet solvers do different things and have different orientations than enterprise solvers.
Instead, capacity analysis tends to be adjusted by operations without the use of an optimizer. This is often true even at companies that already have enterprise optimizers that are in production. Companies that do perform sensitivity analysis typically run enterprise optimizers that are used to support the production environment in simulation mode (as described in this article)
The Lack of Scientific Testing in Industry
However, most simulation efforts in supply chain organizations tend to break down over time because of poor methodology, poor tool selection, and a lack of interest and investment. The vast majority lack a scientific environment, and executives are typically unwilling to pay to keep long-term records of optimization results. Sadly, few companies are even capable of documenting their simulation results effectively. (see this post for details)
The upshot of all of this is that when performing sensitivity analysis for supply chain organizations, it will generally be necessary to explain the topic from a starting place as if the company had never heard of the topic before.
Conclusion
Enterprise optimizers and modeling languages/solvers are designed to support different processes. Enterprise optimizers are designed for canned implementations where the company looks to implement a production optimizer to run the business with limited visibility into what the optimizer is doing. Modeling languages/solvers are designed to offer an unlimited amount of customization. They often have analytical tools (MatLab offers graphics capabilities, so the optimizer can be viewed in terms of its performance as well as having its mathematical output analyzed). A bit part of this is sensitivity analysis. Additionally, for very specialized problems, enterprise optimizers are typically not the right choice. And a custom written optimizer in a modeling language/solver is preferable over using a preconfigured enterprise optimizer.
In general, my view is that enterprise optimizers tend to be overemphasized at the expense of modeling languages/solvers. Enterprise optimizers can be used for strategic analysis (and there are significant differences between various enterprise optimizers in this regard). However, they are more time-consuming and expensive to perform a simulation with than modeling languages/solvers. However, it is also not necessary to choose between the two. I have increasingly come around to the concept that a modeling language/solver should be used in conjunction with an enterprise solver to gain flexibility and speed of adjustment that enterprise optimizers tend to lack.
There are several different options available to companies who want to perform more strategic sensitivity analysis with optimization software. For companies with no enterprise/production optimizer, the most logical choice is to purchase and either train an in-house resource or hire a consulting to use the optimizer to perform the necessary sensitivity analysis. For companies that do have enterprise/production optimizers, the decision becomes more complex. While the vast majority of companies will prefer to turn their enterprise optimizer into a dual-purpose engine to support production and perform sensitivity analysis, this is often not the best decision. For companies that have more capable enterprise optimizers in the simulation, this may be the right choice. I would recommend buying and using a modeling language/solvers like MatLab or a spreadsheet-based solver such as Frontline Solver for those that do not.
References
Optimization Modeling with Spreadsheets, Kenneth Baker, Wiley, 2011
Real Optimization with SAP APO, Josef Kallrath, Thomas I. Maindl, Springer Press, 2006
https://en.wikipedia.org/wiki/Shadow_price