Once a project is completed, a common question is, “How do we deploy this improvement to other areas in the company?” A fair number of formal improvement structures include the final step of “standardize,” implying that the improvement is laterally copied or deployed into other, similar situations. Yet this seems to fly in the face of the idea that work groups are in the best position to improve their own processes.
ADVERTISEMENT |
I believe this becomes much less of a paradox if we understand a core concept of improvement: We’re using the scientific method.
How I think science works
In science, there’s no central authority deciding which ideas are good and worth including into some kind of standard documentation. Rather, we have the concept of peer review and scientific consensus.
Someone makes what she believes is a discovery. She publishes not only the discovery itself, but also the theoretical base and the experimental method and evidence that led to the discovery. Other scientists attempt to replicate the results. Those attempts are often expanded or extended to understand more about the discovery. As new pieces of the puzzle come to light, scientists have what seem to be isolated bits of knowledge. But as other pieces come into place around them, they can see where their contributions and their expertise might fit in to add clarification or fill in a gap.
If the results can’t be replicated at all, the discovery is called into serious question.
Thus, science is a self-organized, collaborative effort rather than a centrally managed process. It works because there’s a free and open exchange among scientists. It doesn’t work if everyone is working in isolation, even if they have the same information, because they can’t key in on others’ insights. What we have is a continuous chatter of scientists who are “thinking out loud”: Others are hearing them, and ideas are kicked back and forth until there’s a measure of stability. This stability lasts until someone discovers something that doesn’t fit the model, and the cycle starts again.
How I think most companies try to work
On the other hand, what a lot of people in the continuous improvement world seem to try to do is this: Somebody has a good idea and “proves” it. That idea is published in the form of, “Hey, this is better. Do it like this from now on.” We continue to see “standardization” as something that is static and audited into place. (That trick never works.)
What about yokoten? Doesn’t that mean “lateral deployment” or “standardize?”
According to my Japanese-speaking friends, yes, it does mean that, sort of. When these Japanese jargon terms take on a meaning in our English-speaking vernacular, I like to go back to the source and really understand the intent.
Yokogawa ni tenkai suru (literally: to transmit, develop, or convey sideways) is the longer expression of which yokoten is the abbreviation. In daily usage, yokoten has pretty much the same meaning, just a bit more mundane in scope—along the lines of sharing a lesson learned. Yoko means “side; sideways; lateral. Ten is just the first half of tenkai, “to develop or transmit.” Thus, yokotenkai.
If you take a good look at the internal context of the Toyota Production System, it’s much more than just telling someone to follow the new standard; it’s more like science.
How a work team could use the scientific approach
A work team has a great idea. They try it out experimentally. Then, rather than trying to enforce standardization, the organization publishes what has been learned—i.e., how knowledge about a process, tricky quality problem, or whatever has been extended. You could summarize this as, “We used to know x; now we know x+y.”
The company also publishes how that knowledge was gained, i.e., “Here are the experiments we ran, the conditions, and what we learned at each step.”
Another team can now take that baseline of knowledge and use it to:
1. Validate, via experimentation, if its conditions are similar. Rather than blindly applying a procedure, the team repeats the experiment to validate the original data and increase its own understanding.
2. Apply that knowledge as a higher platform from which to extend its own improvement project.
Sometimes there’s just a good idea
I’m not advocating running experiments to validate that “the wheel” is a workable concept. We know that. Likewise, if an improvement is a clever, mistake-proofing device or jig (or something along those lines), of course you make more of them and distribute them.
On the other hand, there might be a process for which the new mistake-proofing fixture won’t work. But if teams applied the method used to create the fixture, they might come up with something that works for them, or something that works better.
“That works but...” is a launching point to eliminate the next obstacle and pass the information around again.
Oh... and this is how rocket science is done.
First published Feb. 17, 2015, at The Lean Thinker.
Add new comment