The following story has been going on for several decades. Suppose you work with a company lucky enough to find a "niche" that works well for it. You offer products or services that customers like, and you are very good at developing and delivering them. You offer great quality and fast delivery at reasonable prices. You're lucky, but it happens all the time across all industries.

Take for example the concept of the product life cycle (PLC) that has been with us for several decades. Usually there are four stages distinguished in this concept: new product introduction, growth, maturity and decline. In the business world where the PLC concept was developed, product life cycles were at least six years or considerably more. In that case, the maturity stage is by far the longest one. During this stage, the rate of demand is relatively stable. Not surprising therefore, that most of the frameworks that have been around for some time are implicitly based upon this stage. In the area of goods flow control a good example is MRP, Material Requirements Planning, which forms the heart of all those ERP systems that companies around the globe have invested billions in. MRP extrapolates today's demand to estimate tomorrow's, which works fine if tomorrow's demand is roughly the same as today's, such as during the maturity stage of the PLC.

But, MRP will overestimate the amount of product needed in the future during the decline stage of the PLC, leading to obsolete stocks. And MRP will severely underestimate the amount of product needed in the future during production ramp-up, during the growth stage of the PLC. During decline, some kind of pull-based control mechanism would work much better. During product introduction and growth stage a planning mechanism will do the trick. But most high-tech companies, who all just finished their ERP implementation, are forced to treat all stages of the PLC as the maturity stage, even when most life cycles here last one or two years and consist of rapid growth followed by fast decline, with the maturity stage virtually non-existent...

Probably because PLCs are so short in high-tech markets, it has become common practice to incorporate the time required for product development into the concept of product life cycle. If product development takes two years and actual product life is a year, it makes a lot of sense to look at the whole three-year period. So, relatively new metrics such as time-to-market (TTM) and time-to-volume (TTV) have been developed to keep a sensible track of performance. Let's zoom in on these concepts of TTM and TTV that have become so crucial for corporate success in these industries. In managing the duration of these periods it - again - seems that managers are equipped with outdated concepts. Let's look at two of those.

The first is the quality gate . This sounds like a very sensible idea. Product development is usually divided in a number of stages, first conceptual and then technical design, followed by production tooling and preparation. That marks the TTM point, the next stage of production ramp-up is the step from time-to-market to time-to-volume. When rapid progress during this period becomes so crucial, it is obvious that managers want to speed it up. One sensible thought seems to make sure no sloppy work is transmitted downstream. So, you install a quality gate. You stipulate that the design documents that are transmitted to the next stage have to meet a high standard of quality, say 75-85% out of a 100% (100% being some metric for perfect quality). This way, you can be sure that no rubbish is sent downstream.

Once upon a time this management policy may have made perfect sense. Software was developed in this way some twenty-thirty years ago. Then it was called the "waterfall approach," because work would flow sequentially from one stage to another. But in software engineering this approach is now very much outdated. There, to speed up overall progress, parallel processing of tasks has become standard practice. The new term is concurrent engineering: let teams work on separate parts of the design concurrently and let information about intermediate progress flow back and forth between stages. In effect, that is the same as setting quality gates really low, say at 20-30%. Even if your design is still very premature, share it with the team next door anyway, because they can give you good and early feedback on what they like about it and what not. And, they themselves can get going with their own activities.

Why is allowing messy work to be shared such a great idea? Two reasons. One: people learn from making mistakes. So, the earlier they can start making mistakes, even on the basis of inputs that will change considerably, the better it is for their learning speed and subsequent work quality. Two: some design shortcomings you simply cannot foresee from the stage you are in. For instance, you cannot fully predict all the ways in which various components will interact with each other while you are designing one of those components. Or, your design looks great on paper or in 3-D but is very cumbersome to manufacture. So: the lower your quality gate, the sooner the next stage will start learning and the better and earlier the feedback you will be receiving. This way, the faster your own quality level will go up, the fewer changes need to be transmitted downstream, the faster the downstream quality settles at a high level. In systems term it is a clear feedback loop that is repeated between every successive stage in development and production.

A final misguided management concept is that of cost-driven work outsourcing. Let's assume that manufacturing parts in China, or Mexico, or Hungary, costs a tenth of what it does in your Western home base. Simple MBA arithmetic will lead you to transfer all your production to these low-cost countries as possible. But, in high-tech settings, the period of production ramp-up is also crucial in achieving sufficient quality levels. Without early and adequate feedback from production regarding design flaws that only show up on the manufacturing flaws, or just sensible design changes that make the product easier to manufacture, time-to-volume will not be reached soon enough. The result is far lower margins due to rapid price erosion and far lower market share due to later penetration and lower reputation for quality and reliability. Those are much harder to quantify in outdated cost-only arithmetic, but at least as important in the real world. Using such a static analysis ignores the dynamics involved in production ramp-up. These imply that you will need at least some degree of local production close to the design center to make sure that feedback from manufacturing flows smoothly, timely and comprehensively back to the designers. Again, the feedback effects of information sharing between successive stages in the supply network are crucial. Yesterday's frameworks will lead you to ignore those. Systems Thinking won't.

This article is the fourth in a series of eight articles by Akkermans about Supply Network Dynamics. The 5th Wave will be described in the Sep/Oct edition of the Connector. To read the introduction to this series, click here.