Tag: choice combinations
The Myth of Build-to-Order
In working with manufacturers of configurable products, we have never met one that did not claim that they only build to order. “We don’t build until we have an order in hand” they all say. At first we believed them. A whole generation of companies has been transfixed by Michael Dell. No finished goods inventory; don’t assemble the parts until you know exactly what the customer wants; get the cash before you build the product.
Dell can assemble a computer in three minutes. A truck or a backhoe takes a little longer. But the same ideas should apply! Right?
Dell builds computers for final customers who come to its web site or its 1-800 phone line. Most manufacturers of expensive, complex products are once removed from their final customers. Their immediate customers are dealers. Final customers go to distributors and dealers to buy backhoes, tractors, work trucks, lighting fixtures, industrial fans, and so forth. The “customer orders” that the manufacturers so proudly wave are not final customer orders, they are actually channel/dealer orders. (Okay, this is an exaggeration, some are actual customer orders passed through by the dealers.) And how do the dealers place orders? They guess. They choose combinations of 30 or more options based on their experience. One manufacturer we worked with kept referring to these as “Christian orders”. After a while we asked them what they meant by “Christian orders”. With a big smile they said “Oh, we just take them on faith.”
So the dealers order certain product choice combinations to stock based on their intuition, and those units sit on their lots until they sell. Sure looks like finished goods inventory. There is some ambiguity about who actually owns the inventory. The manufacturer will say that the inventory belongs to the channel or dealer, so it’s not my problem any more. The dealer will say that the manufacturer finances his inventory; some cases has to take back the units and give his money back if a unit sits too long. In any case, the manufacturer knows that the dealer is not going to order any more units while his lot is full of “stale inventory” or “lot rocks”. (See Chrysler’s desperate attempt to force its dealers to accept more cars in 2008.)
So Dell computers are built to order. (And now also built-to-stock for their new retail model for stores such as Best Buy and Wal-Mart.) Jumbo jets are also built to order. But most configurable products are still a combination of build-to-order and build-to-stock, with manufacturers and dealers playing hot potato with the inventory. This means that somebody should be looking at the history of what combinations sold in the past, and trying to make sure that the stuff that they build is the stuff that sells! Looking at the sales patterns and trends is a very fast, efficient and intelligent way to determine what to carry. This is a more reliable than believing in Christian Orders or relying on dealers’ intuition. The manufacturers should be giving the dealers guidance on what to stock and order based on their global visibility into sales and customer buying trends. Customers buy combinations of features, and they do this in predictable ways. Detecting and using the patterns can make inventory turn faster, even if, technically it doesn’t exist.
Customer Buying Patterns – What you can learn From Pizza Sales
First order take rates tell us about the relative popularity of different options. For example, consider a small set of possible pizza toppings.
|
Topping |
Take Rate |
|
Pepperoni |
40% |
|
Mushrooms |
20% |
|
Pineapple |
3% |
|
Canadian Bacon |
3% |
|
Green Peppers |
10% |
Customer buying patterns really start with second order take rates, which tell us about pairs of options, or toppings. Second order take rates tell us about relative popularity, but they also reveal something deeper: dependence. If you know that a pizza has pineapple on it, there is a very good chance that it also has Canadian bacon. This is dependence. In this case the reason is that there is a widely known “Hawaiian Pizza” that has both of these toppings. In general, customers don’t flip coins or roll dice. They select options that “hang together” in some way. The patterns can be seen in the combined take rates. Let me illustrate with three examples that are contrived to illustrate some important points. First consider pepperoni and mushrooms together.
|
|
|
Mushrooms |
|
|
|
|
No |
Yes |
|
Pepperoni |
No |
18% |
12% |
|
Yes |
32% |
8% |
|
In this table you can see that pepperoni has a 40% take rate, since 32% of pizzas have pepperoni without mushrooms, and 8% have pepperoni with mushrooms. In the same way, 20% have mushrooms, because 12% have mushrooms without pepperoni and 8% have mushrooms with pepperoni. This illustrates the first law of second order take rates: the first order take rates must be preserved. But this table contains no new information. Customers are apparently ordering pepperoni and mushrooms independently. This is revealed by the fact that 8% is exactly 20% of 40%. Knowing that a pizza has pepperoni does not give us any clue about whether or not it has mushrooms. Similarly, knowing that it has mushrooms is useless in guessing if it has pepperoni.
As a second example, consider the two toppings that are on every Hawaiian pizza: pineapple and Canadian bacon.
|
|
|
Canadian Bacon |
|
|
|
|
No |
Yes |
|
Pineapple |
No |
97% |
0% |
|
|
Yes |
0% |
3% |
For simplicity, I have made this an example of complete dependence: a pizza has pineapple if and only if it has Canadian bacon. Notice that the first order take rates (3% for each) are preserved.
The third example is the really important one: partial dependence. This is illustrated here by pineapple and green peppers.
|
|
|
Green Peppers |
|
|
|
|
No |
Yes |
|
Pineapple |
No |
89% |
8% |
|
Yes |
1% |
2% |
|
In this case, the first order take rates are also preserved: 3% for pineapple and 10% for green peppers. But these two choices are not independent. The take rate for pineapple and green peppers together is 2%, which is much greater than 10% of 3%, which would be only 0.3%.
Exercise for the reader: show that if we know that the pizza has green peppers, then there is a 20% chance that it has pineapple. (Much greater than its 3% first order take rate.) And if we know that it has pineapple, then there is a whopping 67% chance that it has green peppers!
So second order take rates capture information about how customers are combining toppings, and we can use that information to make predictions.
What does the stairway to complexity tell us?
If a product is too complex, where is the complexity coming from? Which features are causing the explosion in the number of build combinations? The stairway to complexity tells us where to look.
The stairway to complexity shows how the number of unique configurations drops as features are removed. Here is another stairway for a backhoe with 30 features.

The number of build combinations drops from 934 down to 1 as we remove the features. Behind the graph is the actual list of features in the order they were removed. In the table below, the features are ranked from 1 to 30, corresponding to the steps in the graph.

If we want to simplify our product, this ranking of the features tells us where to start. The greatest contributor to complexity is the Buckets, of which there are 34 different kinds. The number of build combinations would drop from 934 to 838 if we didn’t have to worry about Buckets.
Is the ordering of the features in the stairway the same as the ordering by number of options? The first feature in the stairway is certainly the one with the most options (34). But Tran_Control has the second largest number of options (9), and doesn’t appear in the stairway until step 15. So there is more going on than just the number of options.
The amount of complexity introduced by a feature depends not just on the number of options, but on the relative popularity of the different options. Having two options that are split 50% to 50% is much worse than if they are split 90% to 10%. (See earlier post: Entropy of a coin toss.)
Introducing a new feature only increases product complexity if it splits existing configurations that would otherwise be the same. One manufacturer insisted that his product was so complex because it was produced for many different countries. But the number of unique build combinations was exactly the same whether the Country feature was included or not.
Stairway to (Product) Complexity (a.k.a. Why Do I have SO Much Stuff!!!)
In the last post I introduced two ideas about the sales history of any product. First, the number of unique configurations, or build combinations, depends on which features are included in its description. Second, the number of unique combinations drops whenever a feature is removed. A natural question to ask at this point is: Which feature, if it were removed, would lead to the greatest decrease in the number of unique configurations?
This is an easy question to answer, if we have a way of counting the number of unique configurations in any input set of configurations. This is really just a matter of sorting, so suppose we have such a counting algorithm. We try removing the features, one at a time. In each case we apply our counting algorithm to get a score. The score is the number of surviving unique configurations. The feature with the lowest score is the winner (like golf).
Now suppose that we permanently remove the winner, and repeat the contest again. This will determine a second winner, which can also be removed. We keep repeating until there are no features left. Now imagine a graph with the number of features removed on the x-axis and the number of surviving unique configurations on the y-axis. This is the stairway to complexity.

The stairway shown above is for a product (commercial stoves) with 23 features. The number of unique configurations starts at 1223 and drops to just 1 as the features are removed. The features are removed by looking for the biggest drop at each step.
Abstract:
Product complexity is driven by large number of options. Companies struggle to determine which feature choices are driving complexity. They typically “randomly cut choices” to streamline and rationalize SKUs. The cost of product complexity is tremendous on engineering. The current PLM systems do not have a method to measure this and provide intelligent feedback to engineers on how to standardize platforms to reduce engineering and maintenance costs. This article clearly details the metrics around product complexity and how to solve this issue.
The Number of Choice Combinations Depend…
The number of choice combinations depend on which product features are included. The build combinations is the product mix or the marketing mix.
Let’s consider the sales history of our product. There are two very important numbers: the number of units sold and the number of unique configurations. The number of units is well defined, but the number of unique configurations is ambiguous. The ambiguity comes from the fact that there will be more unique configurations if we use more features, especially soft features, to describe our product.
One very special soft feature is a Serial Number, or VIN (Vehicle Identification Number). The whole purpose of the Serial Number is to make each instance of the product unique. So if we look at our sales history and include Serial Number, we will see that the number of unique configurations is exactly the same as the number of units of the product (instances).
If we want to begin to understand the demand for our product we have to see which instances are actually the same. That means we have to get rid of the Serial Numbers. When we do, the instances collapse into groups of now unique configurations; that is, unique without Serial Number.
If we are interested in the tangible features of the product, then we may want to take out other soft features as well. Geographic region is important for some purposes, but may be a distraction when we are interested in the physical product. Taking out the geographic region feature will cause another reduction in the number of unique configurations. The red, V8, convertible in Florida will get combined with the red, V8, convertible in New York.
Sometimes we are interested in the variants of our product ignoring color. We know that every real variant is going to come in several colors, but we want to look at the product without the distraction of color. This is sometimes called the “body in white”. So the red, V8, convertible and the green, V8, convertible collapse into the V8, convertible.
The point I am making is that the number of unique configurations depends on which features are included, and this number drops whenever a feature is taken away. Mathematically, this is called “projecting out the feature”.
The number of unique configurations is at most the number of units sold, and at a minimum it is just one. If we take away all of the features, then every unit looks the same, which means just one configuration. There is a path from one extreme to the other that we will introduce next time.
By the way – understanding this is important as product complexity is a key driver of process complexity.
The Entropy of a Coin Toss.
A product is a collection of features, and each feature has mutually exclusive options. If a feature has only two options, then the choice is like a coin toss. The information contained in that choice is measured by entropy.
Entropy is a concept from classical thermodynamics that deals with the amount of disorder in a physical system (see http://en.wikipedia.org/wiki/Entropy). It was extended to information theory by Claude Shannon (see http://en.wikipedia.org/wiki/Entropy_(information_theory)). Shannon used entropy as a measure of the amount of information in a message. The simplest example is a coin toss. If we toss a fair coin, there is a 50% chance of getting tails, and a 50% chance of getting heads. Shannon defined the outcome of this experiment as having an entropy, or information content, of one bit. If I send a message (say 0 or 1) to tell you the result (tail or head), that message contains one bit of information.
Things start to get interesting when the coin is not fair. Consider a two-headed coin. The tossing experiment always results in heads, and the message will always be 1. According to Shannon, the information content of this message is zero.
If the coin is weighted so that the probability of tails is 25% and the probability of heads is 75%, then Shannon assigns an entropy of 0.811278. There is some information in knowing the outcome of the coin toss, but not as much as for a fair coin, because we already know that it will probably be heads. The graph below shows the entropy as a function of the probability of getting heads. When this probability is zero or one, the entropy is zero. The entropy reaches its maximum of one when the coin is fair (50%).
Where did the 0.811278 come from? How is the entropy actually computed?

We can’t answer this without introducing logarithms to the base two. In English, two to the third power is eight, so three is the logarithm of eight to the base two. We can write “blog” to mean log to the base 2, or binary log. If p denotes the probability of heads, then entropy is computed by the formula:
Entropy = -p*blog(p) – (1-p)*blog(1-p).
Logarithms to the base 2 arise naturally because one coin toss (2 outcomes) has entropy one, two coin tosses (4 outcomes) has entropy two, three coin tosses (8 outcomes) has entropy three, and so forth.









