The following are  my inputs to a discussion on AME’s LinkedIn group initiated last August by Xola Qhogwana, which also  included contributions from Steve Bathe, Richard Foster, Karen Wilhelm, Steven Wade, Wesley Bushby, Ron Turkett, and Trevor Krawchyk.

When to use Poka-Yoke

Poka-Yokes prevent human error, and are therefore relevant when and only when human error is the main cause of your quality problems.

If you have process capability issues, focus on resolving them, not on preventing human error. What you need is deep understanding of your technology combined with statistical tools to enable your process to consistently hold tolerances.

If your process is capable but you are still producing in batches, focus on converting to flow to prevent your defectives being buried in WIP. Your problem is that it takes you too long to detect problems, not human error.

If your process is capable and you practice one-piece flow, then the defects you still produce are due to human error. At this point, and not before, Poka-Yoke is the relevant technique.

For details, see When to use statistics, one-piece flow, or mistake-proofing to improve quality.

Poka-Yokes do not require extensive a-priori analysis

Poka-Yokes are usually small devices, such as a permanent magnet to suck up a panel already containing a metal bracket, or a hole in a container to prevent overfill.

Doing an FMEA do decide whether to design and implement a Poka-Yoke is more expensive than just doing it. If you sort of think a process might need a Poka-Yoke and you have an idea of what it might be, just go ahead, try it, and document it in your company-specific Poka-Yoke library to inspire others. Don’t over-analyze it upfront. On the other hand, if you are building a spacecraft, you should definitely do an FMEA.

If it adds labor, it’s not a Poka-Yoke

By definition, also a Poka-Yoke device adds no labor. Manually scanned barcodes on parts to validate picks, for example, do not qualify as a Poka-Yokes because they add labor. A barcode that is automatically read or an RFID tag , on the other hand, would qualify. A Poka-Yoke has to become part of the process in the long run. If you look at the old big red book of Poka-Yoke from Productivity Press, you will notice that none of the examples adds labor, and there is a reason: any device that adds labor is likely to be bypassed under pressure.

This even happens with safety. Take, for example, the traditional approach of requiring the pressing of two buttons to start a press. How many times to you see plants where one button is taped down so that you can start the press with just the other one? By contrast, safety light curtains add no labor, and are not bypassed.

Using bar codes reading for data acquisition effectively eliminates the errors due to keyboarding because it is faster. If it weren’t, operators would revert to keyboarding and typos would creep back in. This is exactly what you see happening after two or three failed attempts at scanning a code. A barcode on a workpiece that is automatically read can be a Poka-Yoke. The workpiece passes under a reader in the proper orientation and under good lighting conditions and the barcode is reliably read. Under these conditions, it can even drive the lighting of the proper bins in a pick-to-light system. It does not work as a Poka-Yoke s if an operator has to wave a bar code gun in front of a part for pick validation.

Just because you use a device with the intent of preventing mistakes doesn’t mean it works. You have to make sure it does, and not just at the time you implement it. If you don’t pay attention, Poka-Yokes tend to deteriorate and to be set aside, for example when new operators are assigned to the station.