Category Archives: Aggregation

ITW’s use of the 80/20 Rule

Posted on by

Illinois Tool Works (ITW) is a $17B organization with over 800 different operating units.  One of their guiding principles is the 80/20 Rule.  Here is their description:

“A driving force behind much of our success at ITW is our 80/20 business process, a practice that keeps us focused on our most profitable products and customers. The concept underlying 80/20 is simple: 80 percent of a company’s sales are derived from the 20 percent of its product offering being sold to key customers.

 

Put simply, too often companies do not spend enough time on the critical 20 percent of their key customers and products and spend too much time on the lower volume 80 percent…”

Earlier this year, we had a chance to speak with ITW at SCOPE.  Interestingly, you can apply the 80/20 to your network design models as well.  We spend a lot of time in the book talking about how to aggregate your customers and products.  ITW’s 80/20 rule suggests another way build models– only build models that include the 20% of the customers or products that drive 80% of the business.  This simplifies your model and gets you focused on the most important parts of your business.  (If you are skeptical, you can always build two versions of the model– one with the most important 20% of your customers and one with all of the customers– and see if they give different answers).

How Can You Use a Map that is a 1:1 Scale?

Posted on by

The art of modeling is to create a model that reflects reality, but is not as complex as reality.  You want to a model you can work with and analyze to help make decisions about the real world.

In network design, a big part of simplifying your model is aggregating your customers and products.  You have thousands of unique customers (or unique ship-to locations) and you typically group these by geography.  Likewise, you group your thousands of products into a few product families.

If you seen a successful project, you know that the aggregation of customers and products does not impact the quality of the results.

We have found that it can be difficult to explain why you need to aggregate at all.  In our book, we list reasons you need to aggregate and even reasons why an aggregate model can be more accurate than a detailed model.

But, sometimes all these answers do not help you convince others.  And, if you can’t convince key people that aggregation is valid, they may reject your entire model.  So, it never hurts to have different ways to explain why you need to aggregate.

The book, Serious Play, offers a another nice reason.  Ask yourself:  how could you use a map of city that was on a 1:1 scale?  That is, how could you use a map that was as big as the city? You couldn’t use a map this big.

That is why maps are not an a 1:1 scale and it is the same reason models are not as complex as the supply chain it is modeling.

Models are like maps for the supply chain.  They can’t be as “big” (or complex) as the real supply chain.  If they were, they would not do you any good.  A real map of the city leaves out a lot of detail, but is still very accurate for making good decisions.  This is what we are doing with a network design model.  It leaves out a lot of detail, but it is still accurate enough for good decisions.