Dear Gemba Coach,
I’m the head of the lean program for an industrial company of 13,000 people worldwide. We’ve made tremendous progress increasing inventory turns, and now my CEO keeps asking me why quality is not progressing as fast. My lean team has become proficient at teaching flow but it’s not gaining traction when it comes to quality issues. Do you have any recommendations?
The long and short of it is that flow is easy, quality is hard. Achieving flow is easier than improving quality because the lean methods apply more quickly, visibly, and in almost every gemba you are looking at.
To analyze a flow problem at the gemba, you can start by wondering how to stabilize the volume demand over a period of time, and how to increase the mix flexibility by fraction and mix. Then evaluate the various ideas on how well they bring us closer to single-piece-flow at takt time. Once you’ve convinced people to (1) level the production plan, ( 2) hold all parts at the process that produced them and (3) increase changeovers by practicing SMED (leading up to the production operators handling changeovers themselves), then what can happen? It’s hard work, but you can see the gains with every step, and as you make progress the flow issues sort themselves out. I’m not saying flow is a piece of cake. You still need to deal with the usual amount of resistance and misunderstandings and a fair share of attempts that don’t pay off, but, basically, flow is similar in approach to PDCA: plan your next move, try it, check it out in terms of service and inventory, think about it and either adopt or adjust. Stay the course, and, as you’ve found out, results will come. And the groovy thing is that when results do come, they tend to be spectacular, and you get to be a hero. Not only is it nice to be right (first endorphin shot in the brain), but it’s double nice to be recognized for having doubled the inventory turns and liberated cash (second endorphin shot in the brain), so yippee, let’s do this again.
Why Problems Reappear
Quality is different. Applying generic methods like six sigma or PDCA to specific quality problems tend to be hard and frustrating because the failure rate of the attempts to solve the problem is high. In fact, (and this is one of my father Freddy’s key messages in quality), just finding the right factor before jumping in and solving the problem is no walk in the park. When it comes to quality, most people shoot from the hip, looking for a quick fix or a process change. And so invariably the quality issues reappear. Frustrating work. Why the difference?
Serious quality experts—the guys you call in when there’s a customer fire—work differently, and you can spot the difference immediately. The expert will start by observing, by really observing what is going on. Then they try to relate this problem to others that they have seen, situations with this problem cropping up in similar processes. Say they observe a machine producing flawed parts. In essence they start from what they know (after so many cycles, the guiding rail on this type of machine gets out of alignment), and then look for clues of whether this is happening or not. At the same time they take note of everything else relevant, looking for important details that a non-expert might have missed (such as a bad smell from the coolant, prompting a check for bacterial contamination).
Experts don’t quite follow a mental A3 process. They don’t follow a tick-the-box methodology. They recognize a typical case, run it in their minds in the specific situation (like a quick mental simulation), come up with an on-the-spot solution which they then try out. Most often, it works. When it doesn’t they go back to figuring out a different “typical” case, and try again. Certainly, from a lean point of view the number of cycles is wasteful and we’d like to find a way to get experts to get to the heart of the matter quicker, but first we need to understand how they work under fire. When there are extraordinary situations calling for immediate action, experts do not outline multiple options and then decide between these options. What they do is closer to:
- Observe the situation and look for specific cues
- Recognize a “typical” prototype case
- Simulate it in this instance
- Try it.
Which explains why quality is hard and flow is easy. Flow is about getting the right crates into the right trucks and the right products into the right crates: how hard can it be? Sure, some situations will be easier to deal with than others, but fundamentally the generic problems are the same whatever is being produced. Map the process, simplify the flow, reduce changeover time and something will happen; following the generic procedure is almost guaranteed to deliver visible improvements.
Messy
There is no generic procedure to help with quality problems. Quality problems tend to be unique to the part and the machine and problem “prototypes” are very narrowly linked to specific processes. To be good at solving quality problems requires a much greater catalogue of “problem prototypes” and their give-away clues. By nature, quality knowledge is local knowledge, or narrow process knowledge that is acquired by working for years with the same products, processes, and equipment, which is why corporate lean guys will find it hard to get into it.
If this is the case, then how does a method such as PDCA apply? This structured approach certainly applies. When the expert fails at his or her first attempt at recognizing the typical situation, for example, they start looking for another prototype. At this stage things get very messy, usually because the pressure is on and tempers are high. But that’s exactly when the power of PDCA kicks in. PDCA can be used not to recognize the prototype, but to organize and clarify how the expert moves from one prototype to the next, by being more formal about the “Check” and “Act” aspects of PDCA.
In effect, PDCA is essential in helping the expert grow their library of cases faster, and in a more structured manner. PDCA’s insistence on confirmation will push the expert into better mental testing of his or her prototypes before jumping to a solution. PDCA doesn’t help to solve the problem, so to speak. It’s of immense help in developing the knowledge to solve problems better. PDCA is also very helpful in getting the experts to communicate how they go about it, which is important when dealing with situations that involve many operational people. In this sense “P” is a unique opportunity to outline the prototypical case in mind, so that others can see it as well.
Unwieldy Andon
If quality knowledge is local knowledge, is there a lean tool to develop this faster? Certainly: andon. The principle that everyone must “stop at defect” acts as a freeze frame device on processes that allow local process owners (operator, team leader, group leader, technical support) to develop their catalogue of cue-to-prototype cases. When a process is stopped as it has just created a defective, the process owners can inspect it for “point of cause” (what, exactly is making the wrong part right now) and which parameters are out of spec. This can be a hard and frustrating process as anyone who has worked on false positives in testing machines will attest.
Such “freeze frame” action is about the only chance to develop experience with creating prototypal cause-and-effect logical chains that eliminate the problem completely from the process. Without andon, myths and legends about what makes process quality will continue to rule the day, and it will be hard to break the quality barrier of adding a 0 behind the comma in the ppm numbers.
But andon is also a very unwieldy tool. A pull system can be implemented with one smart guy at logistics learning the master scheduler role and pushing the kanban and supermarket system onto gemba supervisors. Andon is tougher: it requires a full social structure in which people react quickly to problems in the correct way. Teaching local management to use andon is much harder than getting them to use a pull system (whether they like it or not).
So, quality is a much harder nut to crack than flow because (1) unlike flow most quality knowledge is very local and specific (to a product, a process, an equipment, a site’s conditions), meaning quality experts will tend to be either very narrow process experts or local people who have learned to work with local conditions. Or (2) the lean tool to spur the development of local quality knowledge is much harder to implement than flow: andon requires full understanding and cooperation of the entire management chain, from the team leader to the site manager.
I don’t have any easy recommendations other than to get your lean experts to start by identifying the right quality expert when they want to run a quality–type action. Ideally, we should be able to do specific quality focused kaizen workshops by process to teach local people to better know their products and use their equipment. This would mean that the quality expert uses the PDCA structure of the workshop to pass on some of his or her knowledge to the gemba. Again, this might not be so easy, so the obvious first step when your lean guys are tackling quality problems is to recognize which process is at fault (even that is rarely easy), find the most knowledgeable guy in the organization about this process and invite them to the workshop, making a big point of listening to them carefully.
Your lean team probably avoids real quality issues because once bitten, twice shy; they must come to realize that while they need to confront quality problems (which are directly linked to customer satisfaction), a generalist approach will not solve quality concerns, ever. In fact, this is an excellent teamwork exercise for the lean team: learning to solve problems across functional boundaries.
