12. The Art of Modeling

As you’ve seen throughout this book, network design is about making a decision about your supply chain. When you are in the midst of analyzing data, are talking to different people in the organization, and are worried about the deadline, the most common trap you can fall into is thinking that the goal of the project is to exactly replicate the current situation. This thinking leads to too much effort in collecting data, too much effort in building a perfect model, and, in the end, failing to create a model that can be used to make a good business decision. In other words, if you try to exactly replicate reality, your model will be just as complicated and just as expensive as reality.

Instead, you need to keep in mind that the objective of the model is to make a good decision for the supply chain. This is why modeling is more of an art than a science. You’ve seen the science of solving these problems throughout this book. The art of these problems is setting up the models so that they can give the business the information it needs to make a decision and take action.

It should be noted that the definition of a good decision almost certainly includes some timeline. Businesses move fast. A great decision delivered too late is much worse than a good decision delivered in time to act. Keep in mind the adage attributed to Voltaire: “The perfect is the enemy of the good.”

Of course, generic adages don’t help directly with network design. In this chapter, we will explore the following specific areas that will help you build better models:

1. Start by understanding the supply chain.

2. Separate the trivial from the important.

3. Start with small models and iterate.

4. Run a lot of scenarios—don’t be afraid to experiment.

5. Don’t be afraid of including things in the model that don’t exist in the actual supply chain.

6. Models are not a substitute for due diligence and decision making.

7. Optimization will do anything to save a penny.

The next two chapters cover the important topics of data aggregation and running a project.

Understanding the Supply Chain

Before starting your network design project and data collection, it is important to complete a scoping session to ensure that all key stakeholders agree on the exact questions being answered, availability of data, aggregation schemes, and output expectations. This discussion and the decisions that come from it will shape the rest of the project from start to finish.

This session should include representatives from Production, Warehousing, Transportation, Finance, IT, and any associated Project Analysts. Ensuring participation from all associated areas from the start ensures significantly less pushback on solution implementation after you are well into the project.

A good early step is to draw a diagram of the physical structure of the supply chain on a white board to understand the current flow. Drawing this diagram helps the team to better understand the full scope of the supply chain. Different members of the team may have thought about only their portion of the supply chain. Seeing the full supply chain in one diagram is a great way to understand it and a great way to get various people in the organization to agree that it is correct.

For example, a retailer may draw the diagram shown in Figure 12.1 on the white board to show the flow of their product from the vendors to their vendor’s warehouses (called DCs—distribution centers) and then their own DCs and on to the stores.

Figure 12.1. Schematic of a Supply Chain for a Typical Retailer

Note that we have not drawn every store, but the general groups and categories of stores. In this supply chain, the retailer is looking back to its vendor locations.

With this diagram in place, the retailer can start to ask questions about whether they really want to include the vendors and vendor locations. They can ask whether they have missed any important flows in the supply chain. For example, does the vendor ship product directly to the stores, and is that important? If these retailers sell online, someone on the team will quickly realize that this diagram has omitted the online customers. Also, as the team draws the diagram, you might realize that there are different types of stores that require different rules. For example, smaller stores in the city center may receive deliveries from an intermediate depot. Or, if the retailer is a grocer, you may need to include different warehouses for frozen, refrigerated, or ambient warehouse types.

A consumer packaged goods (CPG) manufacturer (or any industrial manufacturing firm) would have a different diagram. For example, a typical CPG company’s supply chain may look like the schematic shown in Figure 12.2.

Figure 12.2. Schematic of Supply Chains for a Consumer Products Company

In this case, there is more focus on modeling the manufacturing process. The location of the raw material vendors can play a role in what product is made where and where plants are located. There may be multiple manufacturing steps that are performed at different locations. Also, note that the end customers include both the retailer’s warehouses (referred to as the Retailer DC—distribution center) and the B2C (Business to Consumer—or online) Channel. Many manufacturing firms are starting to sell their product directly online. This creates the need for a different type of customer. For example, they may ship in full truckloads to the retailer’s DCs, but may ship small-parcel for the online business. Also, in this case, all product goes to a Consumer Products distribution center (DC) before moving to the customers. The team should also ask themselves whether the plants can ship directly to the customers and bypass an additional distribution center.

An industrial manufacturing company, like a chemical company, will have the same general structure except their customers may be other manufacturing companies.

A pharmaceutical supply chain may have yet another structure and it may have plants located around the world. The diagram shown in Figure 12.3 depicts a typical pharmaceutical supply chain.

Figure 12.3. Schematic of Supply Chain for a Pharmaceutical Company

A typical pharmaceutical supply chain consists of a series of steps performed at different plants located around the world. The supply chain starts with sourcing of ingredients and raw materials from specialized vendors, shipping products into an Active Pharmaceutical Ingredient (API) manufacturing location. The API is the chemical formulation that makes the drug work. The API is then shipped in bulk to a finished goods (FG) plant that turns the API into pills, tablets, and liquids that are then packaged in the right doses. The finished goods are stocked in a central warehouse (called FG DC in this case) that ships to their regional affiliates and various sales channels.

With the previous examples, you can see how supply chain structures can be very different depending on different industries. They can also capture the unique characteristics of the company.

As you are creating the diagram, you want to ask as many probing questions as possible to make sure you understand the full modeling requirements. We have provided a set of questions, in the text that follows, as a good guide to help get you started. A typical approach that has worked well in the past is to get the group talking by asking everyone to describe their expectations for the project in general. Often many of the questions will be answered during this initial discussion. The provided questions can then be used to help further the discussion and to finalize official scope documentation. Though not all questions need be answered, the more information gathered the better. The output of this discussion also directly guides your next step, which is to begin the data collection process.

The following list of questions will help you define the objective, constraints, and decision variables. These questions are just a list to get you started. You should make sure you ask plenty of follow-up questions and make sure you capture many details. Later, you will need to sort through the answers and separate the important from the trivial (more on this later in the chapter). But, for now, getting detail is important.

1. What is the objective of your network optimization study? For example, are you trying to:

a. Reduce transportation costs? Reduce total costs? Reduce costs after a merger?

b. Reduce the delivery time to customers?

c. Better use your capacity or add new capacity to cope with growth or a new channel?

2. What are the key decisions you want to make? What specific output should be available after the completion of this project?

3. Which portions of your network may change and which are fixed for the purposes of this study?

4. How much of your supply chain do you need to include in the study? Do you need to include both manufacturing and warehousing in the study?

5. What is the desired project start date? (Completion date?) What is driving the completion date? If the timeline is short, you may not be able to create a detailed model.

As part of the study, you also need to understand the data that must be collected. Often, understanding the data will help you ask better questions from the list just presented. That is, these questions should not necessarily be sequential, but should be iterative. To understand the data, it is often a good practice to focus your questions on the physical supply chain and the different types of products, customers, warehouses, plants, and transportation. Here is a starter set of questions:

1. How many different products or SKUs do you manufacture or distribute?

a. How do you currently categorize and group these products?

b. Where do these products come from? What are your options?

c. Will you need to consider the key raw materials that go into the finished goods? How do you categorize your raw materials?

2. How many warehouses do you have? Where are they located? Where do they get product? Who do they ship to? How are they different from each other (are some for all products, some for frozen products, some for online customers, and so on)? How do you measure warehouse capacity? Do you want to consider new warehouses? What are the fixed and variable costs of the warehouses?

3. How many plants and suppliers do you have? Where are they located? What do they make? Where do they send their products? How do you measure their capacity? Can the same product be made in multiple locations? What are the fixed and variable costs of the plants?

4. How many customers do you have? Where are they located? Is there wide variation in the demand of each customer? How can they receive product? How do you group your customers? Do you have different channels? Do the customers have different service requirements (need to be within 100 miles of a warehouse, need to receive product in three days)?

5. How do you ship product throughout your supply chain? Where do you use rail, truckload, less-than-truckload, parcel? What are your rules for when you use different modes?

Now that you have a working diagram of the supply chain and the details behind that diagram, it is time to start thinking about the model. By now, you know quite a lot (too much, maybe) and it is time to determine what to model.

Separating the Important from the Trivial

Often, the difference between a model that leads to decisions that save the firm millions of dollars and a modeling project that fails is the ability to separate the important from the trivial. If a modeling project tries to get down to every last detail, not leave out a single exception that happens in practice, or include every minute decision, most often it gets bogged down to the point of failure.

When we phrase it like this, it looks easy to avoid this pitfall. However, in practice, it is not so easy. There will be strong forces in play that will push you into more and more detail. For example, there will be a strong feeling that if the model does not represent the supply chain, we cannot trust the results and we cannot get others to believe our analysis. If we simply give into these forces and feelings, and try to model everything, our models will fail. Instead, we need to understand that these forces exist and work to address them and still build a practical model.

The art of modeling requires that our models capture the important aspects of a problem, that they don’t get bogged down in the trivial, and that we and others can trust the results.

There is no magic to separating the important from the trivial, and you may not even be able to do this prior to digging into the problem. Although the list is not comprehensive, here are some tips to help you develop better intuition for separating the important from the trivial:

• Realize that there are different types of decisions and aspects to the problem—Just realizing that there may be important and trivial decisions is a good first step. This allows you to realize that you can separate out different decisions and then you can decide which ones to include or exclude later.

• Remember the 80/20 Rule—This common rule of thumb helps you realize that 80% of your sales come from 20% of your customers, 20% of your products account for 80% of the business, 20% of the supply chain changes will lead to 80% of the savings, and so on. It is not a hard-and-fast rule, but helps remind the team that if you are spending most of your time trying to understand an aspect of the business that accounts for 1% of the supply chain costs, you may not be focused on the right things.

• Exceptions are captured in an optimal baseline—Almost every supply chain has many different exceptions and special cases. These can be very difficult, if not impossible, to capture. One thing to keep in mind is that we take care of some of this problem with the optimal baseline. In the optimal baseline, we are coming up with a solution to the supply chain that assumes that there are no exceptions. Then, we compare our optimization runs to the optimal baseline. It is not that we assume that exceptions won’t happen; it is that we know they will, and that is why we compare back to the optimal baseline. See Chapter 8, “Baselines and Optimal Baselines,” for more details.

• Address the areas the model does not cover—Even if we have removed the trivial aspects from the model, it may still be in your best interest to make sure you cover these aspects. Covering it does not mean modeling it. It could mean adding in the impacts after the model runs, or it could mean just discussing this aspect during the presentation of the results.

Start with Small Models and Iterate

We have found that starting with small models and incrementally creating ever-more-complex models is an effective way to get to a final model and final decision.

The outline of this book provided you with different building blocks you can use to start simple and add complexity. You saw how you could start with the simple center of gravity model to determine the best supply chain considering just service. Then, you could add complexity by adding one element at a time like

• Capacity

• Transportation costs

• Facility costs

• Multiple echelons

The benefits of this approach are these:

• It allows you to test your data and model incrementally.

• It enables you to better explain your final results if you know the impact that each new element has on the model.

• It allows you to separate the important from the trivial by being able to see the effect of different elements of the model. If something has no impact, you might consider leaving it out.

• You may find that you come up with your answer before you have to build the full model. That is, as you iterate and build more detailed models, you may find that you have a model that answers your questions with less complexity than you were planning on adding.

Run a Lot of Scenarios—Don’t Be Afraid to Experiment

The benefit of creating a model of your supply chain is that you can test different ideas, different data sets, and different strategies. It is important to note the alternatives to building a model before making a decision:

• Just implement the change and see what happens. This has the advantage of being very real—you know what the results are. Of course, this comes with the big downside that if you get it wrong, the firm could be financially wrecked.

• Use intuition and judgment. This has the advantage of being quick, but the big downside is that it does not take advantage of data nor does it allow you to sort through the myriad of possible solutions.

Many firms rely on some version of these alternatives. It should be no surprise that the resulting supply chains leave a lot of money on the table or don’t support the overall business strategy.

With a model you have the ability to do much better, but only if you make use of one of the big advantages of a model—the ability to run a lot of scenarios. Often these scenarios are called “what-if” analysis. You can test what would happen if something were changed. And that “something” is up to your creativity.

After you build a model, it is relatively easy to run different scenarios. Besides the debugging benefits we discuss later in this chapter, running scenarios allows you to gain a deeper understanding of your supply chain and better prepare for future possibilities.

Most supply chains are relatively complex with many different costs and parameters. By running the multiple scenarios, you can start to see how changes to one part of the supply chain impact another part, you can see how the variables interact, and you can get a sense of the important variables. You may also get other, unexpected ideas on how to improve your supply chain. One company we worked with wanted only the lowest cost network. However, when they found a solution that was just $3 million more expensive than the lowest cost solution but doubled the number of customers they could deliver to within one-day, they opted to implement the latter solution.

Also, by running different scenarios, you can prepare better for the future. When we are building a structure for our future supply chain, we have to make our best guesses about demand and costs in the future. So it is always best to test what would happen if demand went up or down, if it varied by region or part of the world, or if we lost or gained a new customer. It is also good to analyze what happens if costs change. For example, what would happen if the price of oil were to drop or rise significantly?

Part of the art of modeling and coming up with good answers is to not only test these varieties, but then come up with better answers. One way to think about a better answer is to come up with a robust solution. A robust solution is one that is reasonably good across a wide range of changes to the data.

For example, we worked with a firm that had designed an optimal supply chain that reduced transportation and warehousing costs by $4 million with no changes to service level. They were ready to implement this solution. However, when we analyzed the solution, we realized that the savings were being driven by one very large customer. If this customer was lost or its demand shrank, the new network would have been $500,000 more expensive than the existing structure. However, by coming up with alternatives, they found a solution that would still save $3.2 million if the new customer stayed and $2.8 million if they lost the new customer. In this case, the $800,000 of savings that they gave up was good insurance and made for a more robust solution.

Don’t Be Afraid of Including Things in the Model That Don’t Exist in the Actual Supply Chain

When you realize that the underlying mathematical optimization engine solves a problem in a systematically ruthless way, you can take advantage of this fact to help you make better decisions and make more efficient models.

For example,

• One way to trick the optimization into maximizing the number of customers within 400 miles of a warehouse is to set up a transportation rate structure so that all customers within 400 miles cost $1 per mile to service, and those outside of 400 miles cost $10 per mile to service. So if one customer is 399 miles away from the warehouse, each truckload costs $399. If it is 401 miles away, the cost is $4,010. If you don’t put any more costs into the model, the optimization engine will work very hard to get as much demand as possible within 400 miles. The costs of $1 and $10 are purely to guide the optimization to make the decision you want it to make.

• In our discussion of transportation costs, we mentioned that some transportation rates could be quite flat. That is, it may cost the same amount whether the load is going 10 miles versus 200 miles or 400 miles versus 800 miles. This can happen when you ship small-parcel, or ship with a third party with an extensive network in place and the marginal costs to them are just the extra touches—the vehicles are already moving. In this case, the customers may not be assigned to the closest warehouses. One quick trick is to add a small surcharge to all such shipments of something like $0.01 per mile. This cost will be trivial in the overall scheme of the model, but it can be enough to break the tie when the rates are the same between two warehouses and assign the customer to the closest facility. No such cost exists in the real world and you need to make sure that it gets subtracted later (unless it gets rounded out when you report on significant digits).

• For some models focused on the U.S. with significant imports from Asia, you may model the supply location as the port of entry. For example, you model the supplier or plant in Long Beach, California. There is no such plant there, but it helps simplify the modeling without impacting the decision.

This list could go on and on. The key idea is that if you understand the underlying optimization engine, you can set up structures to get the model to help make the key trade-offs you need to make.

Models Are Not a Substitute for Due Diligence and Decision Making

All through this book, we have been talking about the value and importance of network modeling, so this point may sound like minimizing the value of modeling. However, it is important to remember and remind others about the concept of modeling. A model by definition is meant to be a representation of a real entity, be it a facility or equipment or a supply chain. No matter how detailed or precise (again going by our previous reference to precision in modeling) a model is, it can never represent reality entirely. All network models will have some degree of assumptions and simplified rules. As a result, it is important to use the outputs of the model along with other factors and analysis to make decisions. Network modeling is designed to provide decision support and is not a substitute for required due diligence and decision making. It is important to remember that the results are based on best available data and estimates at the time and may likely change in the future.

We worked on a network study for a company where the final results recommended closing a warehouse in New Jersey and opening a new warehouse in Memphis. The existing cost with the New Jersey warehouse was $10 million and the modeled baseline cost was $9.5 million; and this was good enough for decision making. When the model ran, the Memphis solution in the model came out to $7 million with the baseline demand. After the recommendations were accepted and the implementation was started, the Finance team revised their logistics budget for the following year and set it to $7 million.

What is wrong with this? The $7 million cost estimate was based on assumptions and estimates such as historical demand and nonnegotiated transportation rates. The model was designed to answer questions on the distribution network strategy—the scenario costs are meant to help quantify how much better the Memphis solution is compared to, say, a Chicago solution with a total cost of $10 million. This model was not meant to serve as a budgeting tool, and is not appropriate to use as a substitute for due diligence and analysis that goes with a budgeting process.

Optimization Will Do Anything to Save a Penny

When you set up a network design model and hit the run button on the optimization, the optimization is going to work as hard as possible to find the absolute best solution. If the optimization can find a solution that is one penny cheaper, it will do so.

A good modeler will keep this in mind.

This can impact how you set up the model. For example, you may want to artificially inflate the cost of opening a new plant to ensure that if the model does open the plant, it is a good decision (see the earlier section on including things in the model that don’t exist in reality).

This can impact how you analyze results. Specifically, this points back to the need for multiple scenarios (or what-ifs) and due diligence to test whether the model did, in fact, make a decision to save a penny. We have seen that executives have good intuition with regard to this. In our experience, if we show the executives the best four-warehouse locations, they will immediately ask what the cost is of the best three and the best five. Also, if one of your locations is Birmingham, Alabama, they will ask about the cost if it is in Atlanta. They are, in effect, trying to figure out whether the model is recommending one solution over another to save a penny.

Debugging Models

Earlier in the book, we saw how we can set up the model in ways that prevent a successful run. In the chapter on service levels, we saw how we set up a constraint that said all customers had to be within 800km of a warehouse and that we could have only three warehouses. There was no way for both of these things to be true at the same time. Supply chains are complex and the models you build will reflect that complexity. When you set up these models, you want to make sure they are correct. Sometimes the problems are obvious, but smaller, less obvious problems with your model may also lead you astray.

When a good software developer writes a program, they work hard to get the logic correct from the start, they double- and triple-check the logic, and then they thoroughly test the program with many data sets. There is no shame in finding a bug during the development process. Programs are complicated, with many different interactions. This is why the testing of programs is just as important as writing them. In fact, it is important to note that programs are tested during the writing phase. You do not wait until you have a program to test; you should test it throughout development.

Modeling your supply chain is a lot like writing a software program. Of course, commercial-grade network design software is already debugged. But when you set up your supply chain within these programs, you need to make sure it is doing what you want it to do. To ensure that it is working properly, we suggest that you follow the steps a programmer goes through.

To start, you should make sure you understand the key elements of the optimization model you have set up. These elements are explained in Chapter 1, “The Value of Supply Chain Network Design,” but are worth reviewing:

• Objective—What are you optimizing and how do you compare one solution with another?

• Constraints—What are the business restrictions you want to model?

• Decisions—What are you asking the model to do and what choices are you giving it?

• Data—What data will you load into the model and is the data what you expect it to be?

Taking a page from good software development, you should thoroughly test your model. Our experience has shown that people are hesitant to test until they have a complete model. We suggest you test throughout the process. In this case, testing a model consists of running a scenario. The scenario need not be complete. By testing and running various scenarios, you can test the logic of your model and the quality of the data. And, as a side benefit, you may also learn a few things about your supply chain that are worth investigating.

What are you looking for when you test? When you run a scenario, you are answering a few basic questions:

1. Did the model come back with a feasible solution? That is, did the optimization problem return a solution or did it come back with a message that the model is infeasible (commercial-grade packages can provide some messages as to what the problem may be).

2. Is the result doing something that makes sense? That is, did it pick locations that make sense, does the flow of product make sense? Does the solution follow the business rules we set up?

3. Do the output values look correct? That is, do the costs make sense?

Even if these three questions can be answered in the affirmative, you still want to test other possibilities. Remember, these models are complicated and there could be hundreds of millions of different possible solutions. You want to make sure that bad logic or bad data is not preventing other better solutions from surfacing. Running a lot of scenarios and forcing different solutions allows you to look for hidden problems that do not immediately surface. If during these tests you come up with a negative answer to one of the preceding questions, you need to dig deeper into your model.

It is also worthwhile, in the early stages of model development, to develop a feel for the nature of optimization. Remember, at the heart of a network design tool is a purely mathematical engine that will inexorably seek the optimal solution. Model analysis and troubleshooting sometimes resembles reverse electronic psychoanalysis, as the flesh-and-blood modeler attempts to deduce the motivations that drive her digital advisor to make such odd decisions. It is better to encounter these conundrums with the simpler and faster models that arise early in the planning process. Thus, the modeler should dedicate some time to playful experimentation throughout the development of industrial-sized models, in order to familiarize herself with the “personality” of the optimization problem she is building.

Fixing Infeasible Models

If you are at the point where you cannot positively answer the first question, you obviously do not get a chance to evaluate the second two questions. So when the model does not run, what do you do?

First, a quick note about infeasible problems: As you have seen throughout this book, these problems are solved with mathematical optimization. If you simply write a mathematical optimization program, and feed the model data and constraints that conflict with each other, then the model will simply return an answer to you which states that the problem is infeasible. It would be up to you to try to determine what went wrong. Fortunately, commercial-grade network design software can help you pinpoint some problems. First, you know that the software itself has been tested, so you need to just focus on your model and data. Commercial-grade network design software has the ability to pick up some types of problems automatically. For example, if you load a demand of 100 and a total supply of 90, you will get a message that demand is greater than supply. There are a lot of cases like this. However, not everything can be pinpointed without deeper analysis.

You should be aware that not all contradictions can be found in such an easy way. In the example we mentioned at the start of this chapter, every customer was within 800km of at least one warehouse and most customers were within 800km of several warehouses. So you need to run the optimization to sort through the combinations to see whether there is some choice that can meet both restrictions. In more complex models, you may have many such potential contradictions and need the model to sort the combinations.

So for these more complex models, you may still need to do some debugging to get to a feasible model.

One technique we have found to be helpful is to run the model in a mode that allows you to find the least infeasible model by relaxing certain constraints. Some commercial-grade software will have this feature since it requires a difficult reformulation of the problem. This then allows you to determine how close to feasible you are. For example, are you able to meet 99% of the demand or 5%?

Moreover, a commercial-grade tool will include a “bottleneck” report that helps you identify the blocking constraints that are limiting your model’s ability to meet demand. Thus, if a partial solution is generated that meets 85% of demand, but whose only fully utilized facility is the Cleveland warehouse, then you are at least oriented toward a worthwhile starting point in the debugging process. This particular infeasibility might result from the modeler’s underestimating the capacity of the warehouse in question, or it might result from some more indirect problem, such as a shortage of shipping choices for Midwestern customers. But it would seem reasonable to conclude that the production capacity and shipping lanes associated with the Mexican production facility are likely not to blame.

Another approach is to create some high-cost dummy facilities and dummy transportation costs that are set up in a way that they will surely be feasible, but come at a high cost. If these facilities or transportation lanes are used, it can help point to potential problems.

Usually, infeasible models are the result of constraints that are too tight, constraints that contradict each other, or complex models with missing links. For example, when we define that we want three warehouses and every customer has to be within 800km, we may have constrained the problem so much that there are no possible solutions.

Constraints that contradict each other usually occur when you combine constraints that force a minimum at some point and a maximum somewhere else. For example, you may specify that a plant make at least a minimum of 100 units of a certain item. But because of other capacity restrictions (maybe not at the same location), it may not be possible to make 100 units at that location. The more complex the model, the harder these contradictions are to spot. Our experience has shown that examining the minimum constraints for problems is a good place to start.

Missing links in the supply chain are easy to spot in simple models, and commercial-grade software can pick this up. The problem occurs in complex models with multiple echelons. In these cases there may be links between all the pairs of sites you are interested in. But, based on the way you set up the model, there are certain products that need to get to certain destinations, but cannot do so because of the way you have set up the different flows.

After you have a model that runs and produces answers, you need to address the next two questions (Do the results make sense? and Does the output look correct?).

Fixing Feasible Models

When a model is feasible but is producing results that do not make sense, you need to investigate. This is true even when the results don’t make sense just a little bit. We have seen many models that have returned very counterintuitive results that turned out to be true. But to convince people they are true, you need to understand why the model gave the answers it did.

We worked with a company that had experienced rapid growth in Asia and needed a production plant in the region. Demand was growing fast in all parts of Asia, but China was by far the largest market. At the start of the project, the team thought that a plant in China would be the best solution. However, when they ran the network design model, the optimization runs kept suggesting a plant in Vietnam. The company was convinced that there was a mistake with either the model or the data. We had to investigate what was causing these results. It turned out that Vietnam did have higher transportation and duty costs, but because of the low cost of manufacturing and the lower fixed costs, it was indeed the best solution from a cost perspective.

Not all stories turn out like that. Sometimes the strange results just mean that the model is not set up correctly.

This book cannot list all the problems you might encounter. However, keep in mind that the complex model you are debugging is nothing more than a combination of the different building blocks we talked about in this book. If you can understand each of the individual elements, it makes the more complex model less intimidating. We have found that a systematic way to look for problems is to focus on the main elements of an optimization problem. Each of these elements tends to lead to different types of problems. Let’s take each one in turn:

Fixing the Objective of the Optimization

Some problems with models are caused because the objective of the model is not set up like you want or you have not captured some important business aspect of the problem. Remember, the objective function is what guides the mathematical optimization engine and allows the engine to compare one solution to another. The optimization engine does just what you tell it to do, and nothing more.

So if you have an objective to minimize cost, the mathematical optimization engine will return a solution with the lowest cost. If you are looking at the output of this model it may look as though there are “better” solutions that will serve customers better. That is, a customer in Chicago may be getting their product from the warehouse in Dallas and not from the nearby warehouse in Indianapolis. However, you must keep in mind that the optimization engine did not ever consider service in its calculation.

If your objective function includes information about only transportation cost, do not expect the warehouse costs or plant costs to be considered. In fact, a solution based solely on transportation costs may turn out to make bad decisions on the warehouses or plants.

Also, keep in mind that the optimization does not have a mechanism to break ties. To the optimization, a tie is a tie, and whichever solution it finds first, it will return. This can often come up when you have relatively flat transportation costs. That is, it may cost the same to ship to a customer that is 100 miles away as it does to ship to one 500 miles away. So when the mathematical engine chooses to skip the warehouse that is 100 miles away and use the one that is 500 miles away, that is perfectly valid.

Fixing the objective is not always as straightforward as you might think. Sometimes, you can simply add a missing cost element to the objective and the model works fine. Other times, you may not want to add the missing cost, but simply add a constraint to the model to encourage more reasonable solutions. We discussed this earlier in the book when we excluded warehouse costs but put in constraints to limit the number of warehouses it picked.

The reason that fixing the objective is not straightforward is that you sometimes have objectives that cannot simply be added together. For example, you may want to minimize cost and minimize the weighted average distance to customers. We cannot simply combine these. In the section on multi-objective optimization, we talked about the ability to automatically run different objectives at the same time to develop a trade-off curve between the two.

You will find that many real-world problems you will encounter involve multiple objectives. Building a trade-off curve between these objectives is a good way to fix problems related to the objective.

Fixing the Constraints of the Optimization

When setting up the constraints, you need to strike the right balance between giving the model enough constraints to capture the reality of the business and restricting the model too much so that it is very limited in what results it can return.

In the case where there are not enough constraints, the model tends to return results with low costs but unrealistic business results. That is, the model is doing things that are just not possible. In this case, you need to tighten up the model by adding constraints and restricting things that cannot happen in practice. There is a side benefit to not having enough constraints: Sometimes it can allow you to see possible solutions that you didn’t think were possible. On more than one occasion, we have seen results from solutions that the client did not think were possible become possible when they saw the potential savings.

In the case where you have overrestricted the model, the results you are getting do not seem to be significantly different from the current state. That is, the model does not have enough freedom to find different solutions. One way this can happen is if you assume that the way things are done now is a constraint and not just a business practice. To avoid this problem, when you are building your model, you want to make sure that current practices are not necessarily listed as a constraint, and you want to make sure that constraints are real constraints. A real constraint is a real physical limit or a legal or contractual issue, or some rule that the company really cannot violate. If you vet your constraints carefully, you can avoid this problem.

Fixing the Decisions of the Optimization

The decisions or choices you allow the model to make are similar to constraints. If you do not give the model many decisions to make, you are limiting potentially different results and are likely seeing very similar answers to the current state of your supply chain. Often it is important to allow the model a variety of decisions to see which ones it takes.

We worked with a client who was looking to open or close warehouses. After many different runs, they found savings ranging from $300,000 to $500,000. Then, they allowed the model to make decisions on which plants to open or close. The savings went up to $7 million. They were not ready to make those kinds of decisions, but the model told them about the opportunity. After about 18 months, they changed the locations of their plants based on the model results.

Sometimes giving the model “too many” decisions can be a good thing that leads to better results.

Fixing the Data of the Optimization

When debugging a model, we cannot forget about the data. Even though this is the most obvious and is where a lot of problems are found, you should not ignore the other elements of an optimization problem.

There are two main problems with the data:

1. It is wrong.

2. It is not accurate enough (go back to our discussion on significant digits).

When we say the data is wrong, we are thinking of possibilities like the following:

1. You have typos—you put in 1,000,000 when you meant 100.

2. You put in 100 when the correct value is 500.

3. When you moved data around, you accidentally assigned demand for Product #1 to Product #2.

4. Because of the way data was pulled, you are missing data for an entire division, product family, or type of customer.

While we can’t provide a magic bullet for avoiding the tedious work of checking the data carefully and doing normal data cleaning work (double-checking, looking for high and low values, looking at the top 20%, sorting the data by different criteria—customer, product, region, and so on), we have found that running a baseline and a lot of test scenarios is actually a good way to find problems with the data.

In Chapter 8, we talked about using the current state as a way to validate the model and data. So if the costs match up reasonably well, that is a good way to ensure that you are not missing data or have not misplaced decimal places.

By running the model a lot and forcing certain decisions, you can also look for problems with the data that does not get used in the baseline. That is, when you are optimizing, you may be using plants, warehouses, and transportation moves that are not used in the baseline. By running scenarios, you can see how this data behaves.

Fixing inaccurate data may or may not be an issue. Before you fix inaccurate data, you should review the discussion on significant digits in Chapter 1. In many cases, it may turn out that inaccurate data is actually as accurate as it needs to be. In other cases, it is important to run scenarios in which you change the data in question by +/-10%, +/-20%, and so on, to see how a data element actually changes the decisions. If the model does not change much as you change the data, this tells you not to focus on this data. If the model does change, you can either refine your model or make sure that your final results are robust even if this data does change.

Lessons Learned for the Art of Modeling

In this chapter, we introduced the art of modeling and debugging. Although you use optimization to solve these problems, a lot of thought goes into how you set up these models. This is the art of modeling. This chapter is a good starting point for learning the skills of setting up a good model and properly debugging it. But it takes practice to become a good modeler. If you combine what you learned in the first part of this book—what the finished models look like and how they behave—with the lessons from this chapter, you will be off to a fast start.

End-of-Chapter Questions

1. If you are creating a model and one of the key considerations is which port of entry you should use, why would you model the port like you would model a warehouse? What costs would be relevant for picking which port to use?

2. You are creating a model for a manufacturing company with four major plants and ten warehouses. They want to reduce costs by determining the optimal number and location of the plants and warehouses. During the initial set of meetings, one of the team members is very concerned about modeling the “samples” that the firm sends out. As part of the marketing of the product, the firm sends out quite a bit of sample product. This product is pulled from the plants or warehouses and shipped to customers via small-parcel. It accounts for about 10% of the demand records (and about 0.5% of the demand volume) and about 3% of the logistics costs. Should you include this part of the business in the model?

3. Open the model found in the file Debugging Example I.zip on the book Web site. In this model, the customer wants to minimize the average distance to customers. However, when the model runs, one warehouse serves the majority of the customers even though there are other warehouses that could be used and are closer to the customers. Why is this happening? How would you fix this model to remedy the situation?

4. Open the model found in the file Debugging Example II.zip on the book Web site. This model will not solve. Determine what is preventing the model from solving and how you would fix the problem.

5. Open the model found in the file Debugging Example III.zip on the book Web site. This model solves, but is returning a cost that is about 100 times higher than what you expect the result to be. Determine what the problem is and suggest how you would remedy the situation.

6. You are starting a network modeling project. When you ask the project manager what the objective of the study is, you get the answer, “We want to optimize the entire end-to-end supply chain.” Why doesn’t this answer help you? What additional information do you need?

7. Why shouldn’t your model be an exact one-to-one replica of the supply chain?

8. Using the diagram of the retailer from this chapter, draw the diagram of a retailer in which the urban stores are served only from regional warehouses, the rural stores are served from either the central warehouse or regional warehouses, and the online customers are served from a standalone warehouse that receives product directly from the vendors.