Gemba and Quality
Dear Gemba Coach,
We’ve made good progress on quality with Six Sigma, but we’ve reached a plateau. I’ve met a lean consultant who tells me I should spend more time on the shop floor, but I fail to see how it would improve quality?
Good question. The link is not immediate and many who have tried “management by walking about” have been frustrated by the lack of visible impact, beyond initial low-hanging fruits. Let’s take a step back. Things improve if there is some sort of improvement – learning mechanism in place, right? We don’t go to the Gemba open eyed, just to “see” what’s going on. This is more like industrial tourism, and it gets tedious and is annoying to the staff. Gemba walks are all about checking that our improvement strategy is being implemented at the right pace to get the intended results. Going to the Gemba is about checking (1) clear control points (where do I see that results are forthcoming) and (2) how good the improvement process really is (are people filling out the paperwork or really thinking deeply about their issues).
Quality is a difficult topic, and there are a variety of improvement mechanisms to implement in order to break the common barrier of rejects accounting for 2% to 5% of sales. I remember once showing a sensei our efforts to get quality rejects under 1% of sales and he just said: “add a zero.” It took me a while to figure that the challenge was to move from 0.9 % to 0.09 %. Let’s take the issues in sequence.
First, quality defects still reach customers. This means that someone either during the process or at final inspection made a mistake (an honest one) and packaged a defective product to ship to the customer. This is a basic containment issue. They didn’t see there was something wrong with the part. As employees are NOT GUILTY, going to the Gemba is the way to step into the cell and ask oneself: would I have spotted that bad part? The chances are there is nothing there to help you in terms of:
- Constant training of operators in observation
- A reaction system that encourages them to signal doubtful-looking parts.
Within the lean framework, frontline workers have three basic responsibilities:
- Follow standard work and work accurately without mistakes in quality and safety
- Report any abnormality to a more senior person
- Participate in kaizen and teamwork activities, and propose kaizen.
None of these missions are easy in themselves, and, at the Gemba we ask ourselves whether the organization we have in place helps or hinders operators to fulfill their responsibilities.
Melding Observation and Action
On the quality front: how often are operators trained to Deming’s Quality 101 principle of distinguishing a bad part from a good one. This is by no mean simple as many bad parts at customers were tested but allowed to go through because they were considered “borderline” by the line. Defining and teaching boundary conditions is an essential job of the quality department, to help value-adding staff to see the difference between a bad part and a good one. One key role for management on the Gemba is to ensure this process is in place and working properly. Ahem.
Secondly, what can an operator do if they have a borderline part? In most industrial companies I know, not much. At best, put it aside and never hear about it again. The “andon” system in lean blends observation and action. When an operator has a doubt about the part (it feels wrong) they pull on a cord which calls their team leader (a more senior operator, but not a manager) who knows enough of quality standards to decide on the spot whether the part is okay or not and whether something obvious can be fixed in the process (operator not following the standard).
The team leader has about one minute to make that call until the line stops and frontline management comes running. To achieve this requires: (1) rigorous and constant training of team leaders (who, in fact, train operators on the job through responding to the andon calls) and (2) the management structure to sustain this, with, in particular, quick managerial and support service reaction to problems which can’t be fixed in under one minute.
This is not a walk in the park, and Gemba presence is essential to implement such social systems. Most companies I know look at quality issues from the management perspective: once we have an acknowledged problem, how do we coordinate departments to solve it. The specificity of the lean approach is to look at quality from the operator’s perspective, and understanding this often necessitates hours, days, weeks, months, years on the Gemba before it becomes second nature.
Secondly, once we’ve taught the process to spot bad parts and stop them, we can wonder what created the bad part in the first place. This is what Six Sigma projects tend to target. Here again, presence on the Gemba is essential to see that the improvement mechanism is in place and works properly. Once it’s clear the problem goes beyond the cells’ ability to improve because it involves either maintenance, engineering or purchasing (many quality issues are caused by poor quality components), the company needs to have a system in place which controls the response lead-time between spotting the problem and resolving the problem (i.e., it never shows up again).
This is far from obvious. Most people are overworked and technical departments tend to make their own priorities. What comes from the shop floor is taken into account, then fitted into a queue somewhere and treated when there is time. This makes sense from the department ‘s own priorities, but the upshot is that value-adding processes are often left with binning bad parts for months. Management’s role at the Gemba is constant checking the technical problem-solving process and controlling the lead-time.
Engineers Have a Role
Quick response is all the more pressing in that, like a murder mystery, the longer investigators take to get the scene of the crime, the higher the chances of the real culprit to go away. If the machine is not stopped at the precise moment it made a bad part and if technical people can’t inspect its condition right away, finding the root cause of the problem is unlikely. Without root cause, the remaining answer will be to replace this or that which looks out of condition when we finally look at the machine, and invest in newer equipment - not very lean.
Managing the problem solving process has a further impact – it should feed into another learning mechanism: getting manufacturing engineers to better understand their machines so that they continuously improve their capability. One exercise I ask manufacturing engineers to do before they design the next generation machine is to improve availability and capability of the current equipment by ten percent in one week, as a “workshop.” They grumble that what’s the point since this is exactly the machine they’re going to replace soon. The point is, of course, that they understand the downtime, slowdown and quality issues of the current technical process well enough not to reproduce the problems in the next generation machine.
Finally, the root cause of many quality problems is in the very design of the product. Engineers tend to solve functionality issues – it’s hard enough to get the damn thing to work as it’s supposed to. Most of the time, they’re simply unaware of the difficulties some of their technical choices create for the rest of the process. A learning process that teaches engineers how to design quality into the product is worth several points of EBITDA.
Spending time at the Gemba doesn’t affect quality in any direct way – no manager is going to start making or checking parts. Just walking around and shaking people’s hands won’t improve quality either. However, quality will improve as the result of several improvement mechanisms kicking in:
- Improving the ability to spot a bad part by looking at it (or testing it)
- Reacting quicker to bad parts so that they are taken into account and the conditions of making the bad part can be observe and dealt with at team level
- Reacting quicker from a technical point of view to keep value adding staff in success conditions and to observe better what went wrong with the process or equipment
- Improving the integration of what we find out in the design of new machines and equipment
- Integrate what we find out in the design of the next generation of products.
None of these processes are easy, and people will resist the learning part as they just want to deal with the issue and move on to the “real work” of making parts, purchasing machines, CAD designing parts and so on.
The “A” Team
andon is a tool to embed learning into the day-to-day job. The operator pulls the cord when they have a question. The team leader answers. If the question is harder than it seems, the entire hierarchy gets mobilized sooner or late. The same sort of thinking can be applied to manufacturing engineering and product design. This is definitely a management job.
How can more Gemba presence improve quality? You can draw a clear picture of the learning mechanisms that should be triggered by every operator’s doubt. You can then stand on the Gemba and watch whether the improvement mechanism does kick in, and is followed to the A of the PDCA. When its not, you can grab people’s attention and repeat, repeat, repeat until they finally change their glasses and adopt a lean set.
Operator’s responsibilities are making parts according to standards, notifying abnormalities and proposing and participating to kaizen efforts. Similarly, management’s responsibility is to go and see at the Gemba whether people do what they’re trained to do, to point out abnormalities, and to keep the impetus on problem solving until issues are fundamentally solved. This will improve quality.
What can we do to instill some passion in leadership about our lean implementation?
Dear Gemba Coach,
I’m in a company that is trying to implement lean but sees it simply as a series of rote steps to iterate without the sort of passion by leadership inherent in a successful journey. What can we do to instill some passion?
Is agile project management simply lean thinking applied to software development?
Dear Gemba Coach,
You seem to distinguish between agile and lean, but to my understanding, agile is simply lean thinking applied to software development. Am I missing something?
Factory physics was once the rage, but I don't hear about it any more -- was it wrong?
Dear Gemba Coach,
What happened to factory physics? It used to be all the rage some years ago, but we hardly ever hear about it these days. Was it wrong?