About the Author

Dr. Michael Watson, one of the industry’s foremost experts on supply chain network design and advanced analytics, is a columnist and subject matter expert (SME) for Supply Chain Digest.

Dr. Watson, of Northwestern University, was the lead author of the just released book Supply Chain Network Design, co-authored with Sara Lewis, Peter Cacioppi, and Jay Jayaraman, all of IBM. (See Supply Chain Network Design – the Book.)

Prior to his current role at Northwestern, Watson was a key manager in IBM's network optimization group. In addition to his roles at IBM and now at Northwestern, Watson is director of The Optimization and Analytics Group.

By Dr. Michael Watson

March 21, 2012

Top Three Ways Supply Chain Models Can Go Wrong

Can a Model go Wrong and Lead to Bad Decisions? Are Some Firms Hesitant to Use Models because of Bad Experiences in the Past?

Dr. Watson Says:

If you understand the way models can go wrong, it can help you prevent it from happening in your organization.

What Do You Say?

We’ve discussed the benefits of supply chain modeling many times. However, not every manager is convinced that they should be modeling. In fact, after a recent column by SCDigest editor Dan Gilmore calling for more companies to model their supply chains, one reader asked if the fear of bad models leading to terrible supply chain decisions wasn’t a key factor in some companies avoiding modeling.

Maybe part of the fear is that a model can lead to a bad result. Or, perhaps, you have heard of modeling projects that went wrong.

Like any complex task, modeling can go wrong, lead to bad results, and leave you hesitant to try again.

If you understand the way models can go wrong, it should help you prevent it from happening in your organization. Here are the top 3 ways your model can go wrong and what you can do about it.

The results come out, but do not suggest a change. Technically, I call this a success. But, everyone still feels like the project was a big letdown. At the start of the project, there were high hopes that you would find a lot of savings. Everyone puts a lot of time and effort into the project only to make no changes. But, remember, if you didn't do the modeling, you may have invested in real change (closing a facility) that would have ended up costing the company much more than what you invested in the project. In this case, don't give up on modeling and remember that avoiding bad decisions can be just as important as making positive changes.

You never get results and have to cancel the modeling project. This is a failure. The modeling effort drags on and on, and in the end you never get results from the model. Of course, poor project management may be to blame. However, if we focus on the modeling aspects, it is likely that the team got caught up in trying to build an overly complex model, couldn't get over the fact the data was never going to be perfect, or let themselves focus on too many side issues rather than the main issue. In this case, the best advice is to start with simple models with estimates for data and then refine. In the rare cases that a unique constraint is causing the whole project to stall, seek expert advice—there is usually a way around every issue.

You implement the results and they turn out to be wrong. This is a total disaster. You trusted the model, implemented the results, and the business performs worse. The most likely cause here is that the technical team really didn't know what they were doing and built models that did not represent reality. And, the management team did not do their job and ask the tough questions of the model and demand to fully understand the results and the robustness of the solution. To prevent this, make sure your technical team understands fully what they are doing and make sure the management team ask tough questions. One easy way to help avoid this problem is to run a lot of scenarios and analyze the results. If there are problems in the model, it will tend to come out during this process.

You can run into the 2nd and 3rd problems with your own team or with external consultants who might not have the experience you thought they did. One of the reasons we wrote a book on network design is that we felt like analysts and mangers didn’t understand the technology behind the tools they were using. If they understood the technology better, they could build better models and ask better questions.

Final Thoughts:

One thing you should keep in mind is that you may still run into the 3rd failure if you don’t do supply chain modeling. Guessing at the right answer can lead the wrong solution. And, remember, doing nothing is a model that says your supply chain is just fine. So, even if you don’t model, you don’t get off the hook.