Why Create Poka-yokes—and Why Disconnect Them?
Dear Gemba Coach,
I’m a manufacturing engineer and since I have started participating in kaizen workshops, I have noticed that production supervisors tend to disconnect some of the poka-yokes we’ve put in place in the machines. When I challenge them about this they argue that operators can’t run production and cope with the complexity of our machines. I am perplexed by this and wondered whether you’d have a comment.
This is not unusual. In several cases, I’ve seen production teams abandon their automated equipment altogether and return to manual assembly processes and end up increasing productivity. There is no right or wrong in the matter, and it’s a question of spending more time at the Gemba observing how people actually connect to the machines in order to make good parts.
The three most common situations I’m familiar with are supervisors disconnecting in-built poka-yoke because:
- The poka-yoke (error-proofing device) is built in such a way that it adds to the operators’ burden in making the part.
- It’s so strict the machine is stopped all the time.
- It gives too many false positives that hinder production, or it’s so unreliable it’s down all the time.
Just the other day, I was looking at an automotive supplier’s efforts to build a pick-to-light system. In order to make sure the operator assembled various parts in the right sequence (which, they knew, had an impact on quality), they’d rigged the component bins with lights which would indicate to the operator which part to grab next. The engineers had also built in a poka-yoke: an electric cell spotting the person’s hand going into the bin. If the person skipped a part in the sequence, the process would stop, and if the person went into the same bin twice, ditto.
Regardless of how elaborate the engineering system was, the ergonomics of the workstation were unfortunately not so great. Operators had to reach over a conveyor (with the assembled product on it) and to dip into largish containers – which were particularly awkward when they had to grab the last remaining components in the bin. As a result, they had frequent mishaps, such as letting go of the part and having to fish for it again or, in a case of a complex-shaped component, having to shake the parts to extract one. As a result, the poka-yoke would be triggered and stop the process several times an hour, which got on everyone’s nerves (they had to call the supervisor and document the stop and so on.) There are easier methods of checking that the operator has grabbed the right part, such as asking them to push the light as they go. And these methods assume that people work hard at making good products rather than, as many engineers assume, that the equipment has to be people proof.
In a case of the second instance, an electronics company I know decided it had to tackle seriously its quality problems. So corporate issued an instruction to reprogram the machines with poka-yokes so that they’d stop at the first defect as opposed to all the varied rules they used locally (three consecutive defects, five defect in an hour, etc.). Asian plants reacted immediately, and chaos erupted in many areas where the process was really not under control. As a result they stepped back and planned a more layered approach, distinguishing machines with stop-at-defect (green sticker) and not-stop-at-defect (red sticker). In Europe, as can be expected, people went at it more cautiously, as the contradiction between stop-at-defect and hit capacity appeared starkly: don’t try it on an unstable process with capacity constraints. On the whole it has to be said that in this case the stop-at defect campaign had spectacular results, decreasing complaints by 30% globally.
Stop-at-defect is the test to see that you’re serious about quality. Without stop-at-defect, you can’t see the context of the problem when it occurs, and investigation happens too late – it is said that in murder investigation the probability to catch the killer decreases exponentially with the time it takes for the investigators to get on the scene. But stop-at-defect is first and foremost a social challenge. For it to succeed, you need a social structure ready and able to cope with it. If the frontline management is not primed and keen to investigate when the process stops, chances are they will disconnect the poka-yokes in order to run production smoothly, and trust to final inspection.
Finally, some of the poka-yokes manufacturing engineers dream up can be over-engineered or just too complex for the job. Cameras, for instance, are notoriously fickle and require lots of imagery software and computer crunch power to spot defects, particularly when there are variations on how the part is presented. In one such case, the supplier received numerous complaints from the OEM because of misplaced labels on the part. Since the label doesn’t do much functionally, no one at the supplier worried about it overmuch until it became a serious management issue. After many misunderstandings it was finally discovered the OEM has a poka-yoke reading the label on the part for traceability. Without the correct label, the assembly process would stop. In fact, if the label was slightly misaligned or misplaced, the assembly equipment would stop.
Lines with overly complex poka-yoke devices tend to lose much productivity by having operators simply run the part through the detection device again until a part would be consistently stopped. Not surprisingly, production management can be tempted to simply disconnect the poka- yoke in order to run the line.
Make Machines Talk
Poka-yokes are one of the tools in a lean system’s jidoka pillar. jidoka is one of the least studied (and as a result the least known) aspects of the Toyota Production System and many experts argue that it is also the hidden part of the iceberg: stocks reflect variations and leaning a process to carry less inventory requires a robust methodology to solve technical problems.
jidoka’s translation in plain English is complex as the Japanese kanji meanings are complex and very nuanced, open to a wide scope of interpretations. In the early days it was translated as “autonomation: automation with a human touch,” which, I don’t know about you, but I don’t find very enlightening. Two key aspects of jidoka are:
- Built-in-quality: stop rather than pass a defect forward.
- Separate human work from machine work (http://www.toyota-global.com/company/vision_philosophy/toyota_production_system/jidoka.html).
Poka-yokes are an essential part of jidoka inasmuch as they allow both detecting defects and separating human work from machine work (no need for a person to keep watch on that part of the process) – but if, and only if, they actually help to visualize or highlight problems. The essential idea is to “make the machine talk to the operator” rather than make the machine operator proof. Toyota’s current definition of jidoka is to drive daily improvements by:
- A machine detects a problem and communicates it.
- A situation deviates from the normal workflow.
- The line is stopped.
- Manager/supervisor removes the cause of the problem.
- Improvements are incorporated into the standard workflow so that good products can be produced. The emphasis is on machines detecting problems by themselves, and then humans reacting to it and solving the problem.
- Not hinder the operator in any way. Separating machine work from human work means that the machine can produce the part on its own while the person is dealing with the next step of the process. If the poka-yoke imposes on the operator to slow down or backtrack on the process, it’s the wrong solution.
- Identify and stop bad parts. There are prevention devices and detection devices. The ideal is to have prevention devices which stop the operator from making a mistake or stop a nonconforming part from progressing in the process. In many cases, this is hard to do so people build all sorts of detection devices – which is dangerous when the detection technology becomes too complex and not reliable enough.
- Give quick and specific feedback. The whole point of a poka- yoke is to be able to kaizen the process by eliminating the cause of the mistake. The purpose of the poka-yoke is to give the operator immediate feedback on what is wrong where, and stopping the equipment so that the person can safely inspect the various operating conditions and find out what’s wrong and fix it rather than run in degraded mode. For instance, make sure the defective part has to be taken out manually in order to inspect the process and analyze what went wrong.
- Be cheap and simple. Any device adds cost to the process both in terms of investment and operator labor. Cheap and simple devices can help the operator to do a better job, but unfortunately many poka-yokes I see are too elaborate and both costly and demanding for the people who have to build parts every day.
In fact, I believe you’re asking exactly the right question and are already on the path to solving it yourself. The ideal poka-yoke is a device invented by an operator in the course of doing kaizen. For instance, in one assembly process where they had to switch from one bin to the other according to variants, the operators simply covered the redundant part bin to avoid dipping in the wrong one. Or a simple modification of a fixture so that the part can’t be wrongly placed, and so on.
If you’re involving yourself in kaizen, you’ll probably discover that people are right to disconnect the poka-yokes that hinder them, but also that when they’re asked the right questions, operators can come up with very clever ideas to mistake-proof the process. The operational answer to your question would be to have manufacturing engineers to kaizen similar processes before designing the new machines so they understand the true purpose of poka-yokes from the operators’ perspective rather than as feats of engineering
Is my crazy new boss right that applying standardized work is the foundation of lean?
Dear Gemba Coach,
My new boss is a lean fanatic crazy about standards. He’s created a new team to audit standards and is telling us that applying standardized work is the foundation of lean. It’s creating a lot of resistance, and I don’t know what to make of it.
Can 5S apply to coding?
Dear Gemba Coach,
We’re exploring lean in software development. Can 5S apply to coding?
Isn’t there a better way to manage inventory than just-in-time?
Dear Gemba Coach,
This is 2019. Isn’t there a better way to manage inventory than just-in-time by now?