I've been doing a lot of value stream mapping lately. I consider this a very important endeavor as these maps describe the architecture of a lean transformation. Value stream maps are the language of lean transformation, and like any language they cannot be learned and mastered just by taking a class. You have to practice them in a variety of different situations, and each time you do you learn a little more and get a little better at it. Continually striving toward mastery of this skill is, I feel, one of the hallmarks of a great learning organization.
Still I often find people resistant to taking this approach to organizational improvement. In particular they bristle at the idea of focusing on lead time. One of the key features of a VSM is the timeline at the bottom, sometimes called the "heartbeat" of the value stream. This gives you a quantitative measure of the effectiveness of the value stream by comparing total lead time to actual process time. But this also tends to bias opinions. Some say, "I'm not interested in improving lead time. My real problem is quality." Or, "Lead time isn't the issue, it's cost." Or any of a number of other arguments that focus on specific symptoms rather than the overall health of the value stream.
The important point to remember here is that lead time is a proxy for all those other process metrics. Lead time is increased by:
- Too much inventory, which adds cost.
- Poor quality, because it adds time for rework and remakes.
- Excessive cycle times, which add cost.
- Non-value-added processing, also costly.
- Scheduling and transactional requirements.
- Batch sizes.
- And a host of other things.
By focusing first on how you flow material (or information) to the customer, identifying and quantifying the impediments to that flow, and then attacking those impediments one by one you get a much clearer, coherent, and comprehensive improvement plan that focuses first on what matters most: the customer.
But the architecture of your lean transformation is only as good as the blueprint you draw up. Your VSM must be detailed and accurate enough to identify the barriers to flow and their relative impacts. No two value stream maps look alike, and there is no template or cookie cutter approach that will work. You have to go to gemba, walk the value stream, map the flow of value, and above all practice.
One thing I learned in value stream mapping. It's the "Suppose to be model". To often we begin with the "as is" step then move to the "to be" portion. But we never researched how the system was "suppose to be" when set up. Often time the "to be" model is just the original way the system was designed to work. Mobility of management and system creep are usually the culprit.
ReplyDeletehttp://www.leanplanet.org/