Tip of the Month: November 2012In Lean Manufacturing one-piece flow is the state of perfection that we aspire to. Why? It unlocks many operational and economic benefits: faster cycle time, higher quality, and greater efficiency. The economically optimal batch size for a manufacturing process is an economic tradeoff, but it is a tradeoff that can be shifted to favor small batches. We’ve learned to make one-piece flow economically feasible by driving down transaction cost per batch. One-piece flow is unquestionably a sound objective for a manufacturing process.
But, is one-piece flow also a state of perfection for product development? In my experience, product developers actually have fewer constraints than manufacturing and this creates far greater opportunities for batch size reduction. In product development it is quite practical to decrease lot sizes below one item.
In manufacturing we handle physical objects, and physical objects can only be in one place at a time.* The shaft is either on the lathe or the grinder – it cannot be in both places at once. In product development we work on information, and information can be in two places at the same time. This creates opportunities that do not exist in manufacturing.
Let’s start with a simple example. In product development we often produce engineering drawings that prescribe many important characteristics of a manufactured part. If such drawings are viewed as physical objects, then the smallest quantity of information that can be transferred is one drawing. Engineering finishes its work and then transfers its work product to manufacturing.
The smartest product developers do not operate this way. Instead they recognize that the information on a drawing can be divided into much smaller batches. A drawing typically specifies many details about a part. In the limit, each individual detail can be transferred in a separate batch. A drawing with 100 dimensions might allow us to drop our batch size by another two orders of magnitude.
Of course, in practice we never go to this theoretical limit because we still must respect the economic tradeoff between holding cost and transaction cost. It rarely makes sense to transfer single dimensions because transaction cost dominates at very small batches and the value of receiving an isolated dimension is often quite small. So, while we routinely use batch sizes smaller than a complete drawing, I’ve never seen companies transfer one dimension at a time. Most often, we break the drawing up into multiple release levels, at times as many at 6 to 8, and freeze certain data elements at each release level.
But, let’s push a little harder on this. Is transferring one dimension at a time really our theoretical lower limit? No, and this is where it gets interesting. While a single dimension may appear to be the smallest atomic unit we can transfer, this is not the case when we are transferring information.
To explain this I need to clarify how engineers think about information. Engineers measure the amount of information contained in a message by the amount of uncertainty it resolves. If p is the probability of an event, then the information contained in knowing that event occurred is:
Information = - log2 (p)
One bit of information is sufficient to identify which of two equally likely outcome has occurred. (When p = 50%, then I = 1.) Two bits is enough information to distinguish four equally likely outcomes. More probable outcomes have lower information content, and less probable ones have more information content. If I told you there was an 80 percent chance of rain tomorrow when it actually rains this outcome contains 0.32 bits of information. If it does not rain, which is less probable, more uncertainty is resolved and this outcome provides 2.32 bits of information. Notice that information can come in quantities smaller than one bit, and therein lies the opportunity. We do not have to treat an individual fact as the atomic unit that sets the lower limit on batch size. We can transfer information about a fact in multiple small batches as our confidence in this fact grows.
Perhaps an example would help. I was once working with a semiconductor company that was designing a specialized chip for the TV industry. Classic development practice would require them to define the requirements for this chip before they designed it. Unfortunately the requirements could not be known with certainty until the standards committee published their standard. So, what did they do? They made an educated guess as to what the standard would be. They were only partially correct, so they had to redo portions of their design. Even with this rework, they had their chip available months ahead of any other competitor and ended up with 70 percent market share in the segment.
Importantly they were not waiting for an atomic fact to become 100 percent certain before they transferred it. As soon as they had a useful amount of certainty they began working with this information. Did working with uncertain information cause expensive rework? Yes. However, the cost of the rework was small compared to the economic benefit of the cycle time savings.
As product developers we can learn many interesting things from manufacturing, often much more than we think. However, we should respect that fact that the physical world of manufacturing differs in very important ways from the world of product development. Don’t let the idea of one-piece flow become an unnecessary mental limit on the way you think about batch size. It is not the limit for a skillful product developer.
* For hard-core physicists this is untrue, but for most readers it is a pretty useful approximation of reality.