Dear Gemba Coach,
I’m an engineering student working on my master’s thesis, which focuses on the Lean philosophy and specifically on Lean tools. Different authors often use the words “methods” or “tools” without making a distinction between these two concepts. For example, some authors refer to TPM as a method while others call it tools. I think that TPM, JIT, SMED, Heijunka are methods and the 5S, VSM Kaizen are tools. Perhaps we could use the expression “solutions” to include both methods and tools? Where do you stand on this?
This reminds me, many years ago, in the previous century, before John Shook and Mike Rother published the seminal Learning To See, I remember some engineers who were discovering lean at the time argue the difference between the MIFA (Materials and Information Flow Analysis) and the MIFD (Materials and Information Flow Diagram). In your terms, we could probably say that the MIFA is a method (a procedure or processes for attaining an object according to Merriam Webster) while the MIFD is a tool (a device that aid in accomplishing a task according to Merriam Webster). With this in mind we could then make the case that Value Stream Mapping is a method whereas a Value Steam Map is a tool. One can easily forgive lean authors for using tool or method indifferently, because actually the same thing can be seen either as a method (the analytical process) or a tool (the formats supporting the process) according to the point one wishes to make, so let’s go to the Gemba and think about it from that perspective. Standing at the Gemba, I’d have to say this question is in fact more of an academic than a practical one. So let me jump straight to what I see as the critical point—the relation between the various things we call both tools AND methods and what you propose calling “solutions.”
The real question here is what are you trying to get done with these things in the first place? What problem are you trying to improve?
Notice that I didn’t use the word “solve”. That’s because lean methods/tools ARE NOT solutions. Actually, the word “solution” does not exist in the lean vocabulary. Lean guys talk instead about countermeasures. The word “solution” implies that there’s a definitive answer to the problem that goes against both experience and the kaizen spirit. And so we’d rather think in terms of temporary stopgap measures. Sure, the closer you can trace your countermeasure to the root cause of a problem, the more of a “solution” you will end up with. But it’s important to use the proper language: the word countermeasure reminds you and everyone else that no answer is either perfect or definitive.
This isn’t an idle point. Our minds grew while roaming the African veldt for quick certainty, not for open minded rigorous confirmation of hypotheses. However finding root cause countermeasures to complex problems requires careful observation and methodical hypothesis testing, which completely goes against the grain. So using the word “countermeasure” is a good reminder.
The lean methods/tools are not countermeasures either. The countermeasure is what comes out of using a method/tool rigorously.
Let’s go back to the gemba for a second. A little while ago I was on the shop floor looking at a group of engineers dealing with a recalcitrant robot. Because of all sorts of problems, the robot was often down. The people there had responded by adding an operator making the part manually with a clever little jig to hold the part. The operator worked occasionally, when parts were missing to complete the batch, and the engineers were looking at quality. Now, the operator worked more slowly than the robot, but as the operation was mostly welding, he actually made better welds than the robot, because the operator could adapt his welding to the components he was given. A large part of the trouble with the robot was that the new supplier selected in the Far East by Purchasing kept sending non-standard components. The robot couldn’t cope with this and either stopped or made bad parts.
Then someone asked the unthinkable: why don’t we just use operators, and forget about the robot (the robot requires a full time operator as well to feed in the components). The answer was obvious. The operator was far too slow to achieve the required piece rate.
But hang on a second. Required by whom? When the group calculated the customer Takt Time they found that the operator worked well within Takt. The difference would be between one reliable operator per shift (three heads) as opposed to one operator feeding the robot for two shifts (two heads) overproducing and hence stockpiling an entire shift.
Only a genuine lean fanatic would argue that Takt has to be followed no matter what. The correct principle is flow when you can, pull when you can’t. In the case of capacity equipment such as presses that work much faster than Takt it often makes sense to batch. Yet in some cases, you’ll put the presses in flow with the rest of the cell because the cycle is close to the takt, and it puts pressure on the presses to work dependably. It depends. Takt Time is NOT A SOLUTION. It’s an ANALYSIS METHOD to see how you fare against an ideal world of regular customer demand and thus to have a different look at your costs management to offset the unit price calculation (three operators and no robot could be less costly than two operators plus one robot if you take into account all the additional costs of the robot, but the robot’s unit cost calculation will often be much lower).
Lean methods and tools spring out of applying scientific thinking to the shop floor. Astronomy is a method (calculating orbits, and, well, all that weird stuff about looking for the 93% dark matter in the cosmic radiation) and a telescope is a tool. Their purpose is to describe the universe more accurately so that we can take the correct decisions about living in it (although changing neighborhoods remains somewhat problematic). Lean methods and tools are about describing the reality of the shop floor in a way to reveal the true cost and the added cost due to waste. Nothing more, but still a big thing.
Consider lean as “a procedure or process for attaining an object”. The object of these particular procedures is NOT to resolve the problem, but to learn by:
- Visualizing the process to reveal problems
- Describing the problem more accurately
- Seeking root cause by asking why and scratching one’s head
- Studying countermeasures to see what works and what doesn’t.
Lean is a system inasmuch as these various methods/tools are interrelated and comprise a full way of analyzing business. Please don’t conclude “Ah, it’s a philosophy!” however. That’s where sensei Bob Woods from The Gold Mine will roll his eyes and snap that it’s a practice. Indeed, the point of lean is that you get better and better at your job by practicing the tools in real life as part of your work, every day. And you get better at developing mutual trust when you practice the same tools with others. As a result, when all people practice the lean tools all the time together, they come up with smarter processes, and answers they had not thought of before – creating sustainable results. As Taiichi Ohno once instructed my father’s sensei: “Don’t look with your eyes, look with your feet. Don’t think with you head, think with your hands.”
Challenge! Open mind! It’s not too late to change your mind. Rather than thinking about your thesis in terms of a lean philosophy applied through its tools, change your perspective, angle of view, frame, and look at it as a practice acquired by using the tools repeatedly through which one develops one’s own autonomy in problem solving and vision or where to go next – and eventually, after just a few decades, one’s own deeper understanding of the short word “lean.”
