This Week in SCDigest

Supply Chain Network Design - By the Book

If you have been a reader of Supply Chain Digest for at least a few years or so, you may have noticed I have a fond spot for supply chain network design thinking and technologies.

There are a number of reasons for this. The main one right now is simply that if you have much beyond the most simple of supply chains, I really believe you have a competitive advantage if you maintain a network model and use it to help make better on-going decisions. I have talked to enough companies that are doing this (with Pepsico, really starting with Frito-Lay, being perhaps the most prominent example, but there are many more). But that said, not nearly enough.

The second is that supply chain network design is tied at the hip with overall supply chain strategy, isn't it? Your supply chain strategy in large measure will simply manifest itself in the network as designed and executed. Not sure we think in as detailed a way about this point as we might. The supply chain strategy evolves, but the network often is left behind, as is.

So it was welcome and timely when a new book titled "Supply Chain Network Design: Applying Optimization and Analytics to the Global Supply Chain" arrived in my mailbox, courtesy of my friend Dr. Michael Watson, formerly of IBM and now full time at Northwestern University, and Sara Lewis, Peter Cacioppi, and Jay Jayaraman, all of IBM.

The book has a little bit of a textbook feel to it, and I am sure was designed in part for college course work, but the important point is there are a lot of us who could benefit from such an education. Why? Because we are often using network design tools on either a consistent or occasional basis, and don't really understand what is going on inside that black box. Just as important, where all these tools can be applied, and (critically) the level of granularity of the data used in the model is usually not well understood by supply chain practitioners, who largely rely on consultants for that insight.

This book will empower practitioners to much better understand and drive some of that thinking themselves. In talking to Watson when the book was first launched, he said he thought it was important that supply chain managers have better understanding of the math and models being used using in a network design project, and I agree. If I was a VP of supply chain, I would make every member of my team read this book before starting a network design project.

Without going into a lot of the detail in this column of course, the book methodically (but in a very reader-friendly way) moves from very basic network design efforts and then shows how you can layer on from basic site location decisions to adding more complex service level considerations, performing scenario analysis, considering capacity constraints and needs, fixed and variable costs, modeling multiple tiers of the supply chain simultaneously, sourcing optimization and more.

As I know from the work he has done with SCDigest, Watson has an excellent way of taking a complex and scientific topic and making it understandable and interesting, and he and his colleagues have done that here as well.

Some of the insights that I found most interesting, besides basic education on how network optimization really works:

Relative to my thoughts above, early on the book cites the example of a company that just recently decided to close down a plant in Egypt supplying customers in the Middle East during the Arab Spring unrest. There was no time table for re-opening the facility. The CEO wanted to know almost immediately where that production should be moved.

You would want to be able to make that decision optimally of course. And the CEO wants an answer now, not weeks later. Just how do you do that without a network tool at the ready? An excel spreadsheet? You are confident in that answer?

The book also touches on the "data granularity" issue in various places, and in reality there is certainly some art mixed in with this science in terms of how detailed to get (recognizing that in general, the more detailed the data requirements, the greater the cost and time.)

"Our goal for collecting data for the network design model is to define the data needed with the right level of significance to make the relevant decision," the book notes. "It is a waste of time and often a risk to our project's success when we report the data with more significance than is warranted."

Watson et all make the commonsense but still not obvious observation that when using data such as demand forecasts or future transportation costs in the model, to get overly precise is silly, as these are just guesses likely to be wrong anyways. Also that sometimes network design projects falter because the team can't ever get to the level of data detail it thinks it needs to make a decision. But of course, a decision actually was made - to do nothing. This is the perfect getting in the way of the good, to quote the common phrase.

The book also observes how you think about fixed and variable costs is often critical the model. Yes, in the long run all costs are variable and in the short term most costs are fixed, but finding the right approach to this question can be of major importance in finding the optimal network design.

Using a "step" approach to say manufacturing or distribution costs often makes sense, the book notes, where fixed costs rise as various levels of output are reached. For example, if you expand a current DC to achieve more storage and throughput, then fixed costs will rise while variable cost per unit are likely to fall.

And probably most important here, you have to often (always?) be careful of using cost data straight from the accounting systems as inputs to the model. Those numbers may not be calculated in a way that really makes sense in terms of supply chain decisions, especially in terms of fixed and variable costs. The book says it is often necessary to go through each cost category and assign the percent that is fixed and what is variable, some effort to be sure but well worth the work in most cases.

Also interesting was the observation that some companies avoid network designs studies because they just don't want to think about the effort they perceive will be needed to redesign the current network. We could argue that this is a short-sighted view, but let's accept it for now.

However, that doesn't mean the network design tools can't add value. The book cites the example of Illinois Quality Parts, a distributor, which constructed a baseline model of how its network operated at the time. That effort showed some anomalies between the costs the model said should be incurred versus the actuals in some specific areas (think of how powerful this insight/capability would be!). The company was in the end able to save many millions by re-assigning some customers to different DCs, and fixing execution issues it did not know it had before the modeling exercise identified them - without touching its existing physical network.

There is a lot more, but you get the idea.

So I also wanted to bring in here Jeff Karrenbauer of Insight, a network design software and consulting firm. Like Mike Watson, David Simchi-Levi of MIT and a few others, Karrenbauer is known as one of the real gurus in this discipline.

We just held a Videocast in which Karrenbauer said that - here in 2012 - three recent and well-known companies all limited the scope of a network design project to where to place DCs. And did those as "big bang" projects, meaning the analysis and any resulting changes were performed, and no one was going to look at the network again until the next such project in five year or whatever. (See Supply Chain Network Design: Where the Real Money Is.)

But looking at the broader supply chain, and answering an on-going series of questions like what do I make or buy where and how have environmental changes are impacting optimality "is where the real money is," Karrenbauer says.

I am sure Watson and many others, including me, would agree.

There have been supply chain network design books before, but this is a really good one. There are many things in here that can help a company's supply chain thinking.

Supply chain strategy and network design cannot really be separated.

Do we need to get more knowledgeable about supply chain network design principles and models? Should more companies be using network optimization tools on a continuous basis. Let us know your thoughts at the Feedback section below.

View Web/Printable Version of this Page

Thanks for taking the lead (and a few arrows) on this Dan.

OK, we can all agree that "Perfect" is not easy, and in some cases may not even be worth the effort & cost required. But should that stop us from trying to achieve perfection to a level that is practical?

Isn't that why we do Continuous Improvement projects? What about Lean Kaizen and Six Sigma? The mantra has always been "it's not a destination, it's a journey"). And when we get close we frequently find that the destination shifts due to product or customer requirements, business strategy, etc.

Focusing on logistics - does anyone ever expect to achieve perfect "Perfect Orders"? If the answer is no should we give up this valuable metric?

I think we should have an agreed upon metric set for "Perfect Logistics" and a single comprehensive metric similar to the "Perfect Order Index". Something which includes selected measures across the supply chain from supplier to consumer. It should ignore numbers that are unique to specific industries as these would preclude our ability to benchmark institutions.

Steve Murray
Supply Chain Visions

More on Perfect Logistics:

Certainly there are going to be skeptics out there about perfect logistics, but it takes a lot of courage on your part to lay out the gauntlet and be a visionary on behalf of the industry.

Good Job!

Don Dovgin
Transportation Management Group

You know, you are really starting to have me convinced.

I think we are going to to start looking more at this vision in my company's logistics operations - but I can't let our customers starting thinking that's how it is going to be yet!

Arnie Leesman