What Poka-Yoke Are And Are Not, And How To Sustain Them

Chet Marchwinski recently exhumed a 2011 discussion about Poka-Yoke that had been started by the following question:

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.

In short, I can think of two reasons for production supervisors to disconnect Poka-Yoke:

1. No production supervisor in his right mind would disconnect devices that make the work easier for operators. If they do disconnect them, the most likely explanation is that the devices described as “Poka-Yoke” actually add work for the operator. If you have to pick a part from one of ten open bins in front of you, you will spend precious seconds finding the right one; if all bins are covered with lids except the right one, not only are you physically prevented from picking the wrong one but you don’t have to look for it. It makes your job easier. On the other hand, if you have to scan a bar code on the part to validate the pick, it adds to your work load and your supervisor will pull the plug on the next production rush.
2. The manufacturing process is not ready for Poka-Yoke. A production supervisor is quoted in the question as saying “operators can’t run production and cope with the complexity of our machines.” This suggests that the line has process capability issues that must be addressed before implementing Poka-Yoke.

The following paragraphs elaborate on these points.

Poka-Yoke: An Approach To Quality Improvement

These issues have been treated in previous posts since the start of this blog four years ago:

• Not Exactly Poka-Yoke and Chaku-Chaku (1/14/2015)
• Using Poka-Yoke Techniques for Early Defect Detection | Accelerate Management | Jennifer R. (11/8/2014)
• Yet Another Post About Poka-Yoke (8/8/2013)
• Poka-Yoke at Toyota: the Current State (3/10/2013)
• Key details on Poka-Yoke/Mistake-Proofing (11/22/2011)

To this day, the best way to learn about Poka-Yoke is from cases, and the best English-language source is still the big red book from 1987 with its 240 examples,  some of which date back to the 1960s. Most of them are easy to understand and still relevant, but they don’t address the prevention of errors with software, computer-controlled equipment, or distinct products that have the same external geometry, like computers built in the same enclosures but configured with different processors, memory, or disks. And the short theoretical introduction in the big red book doesn’t address many key issues. It neither clearly defines what a Poka-Yoke is, nor the context in which it is the best way to improve quality. The following common characteristics, however, emerge from when you consider the examples:

1. Poka-Yoke are devices to prevent mistakes. It’s all about people. A feature in an automatic machine that detects and responds to malfunctions, while useful, is not a Poka-Yoke. In a manual operation, a Poka-Yoke makes a mistake physically impossible; in a machine operation, it prevents the operator passing on parts with a defects introduced by the machine.
2. A Poka-Yoke works 100% of the time. It flows logically from what it is. A device that reduces the rate of human error by 95%, while useful, is not a Poka-Yoke. A device that fails good parts, even rarely, is not a Poka-Yoke either.
3. A Poka-Yoke does not add work for the operator. This is essential, because devices that do add work are disconnected or bypassed under pressure.

Also, obviously, the time to implement Poka-Yoke is when human error is the main cause of defects. The logical consequences are as follows:

1. Process capability must not be an issue. The process can reliably hold the required tolerances. Otherwise, nothing else matters until it does, and the relevant tool to achieve it are not Poka-Yoke but design of experiments (DOE). This brings you down from double-digit percent defectives to low single-digits.
2. Rapid detection and response to discrete problems like tool breakage has already been applied. This is often not the case in jobshops, even with capable processes. It is achieved by converting to one-piece flow in integrated lines, which cannot be done unless the processes are capable. This takes you the next order of magnitude down to a few thousand defective ppm.

Only once you have passed these two levels does prevention of human error rise to the top in quality improvement. For some reason, this strategic perspective is not found in the literature on quality, where the boosters of statistical methods like DOE ignore other approaches while the inventor of Poka-Yoke, Shigeo Shingo, dismisses statistics as a distraction. Fro details, see When To Use Statistics, One-Piece Flow, or Mistake-Proofing To Improve Quality. Since that paper was written in 2001, Toyota has introduced additional techniques that have helped sustain Poka-Yoke and further improve quality, specifically Change Point Management (CPM), and Jikotei Kanketsu (JKK, 自工程完結, or “autonomous process completion”).

Poka-Yoke And Error Prevention

Poka-Yoke is at the apex of error-prevention. We marvel at the ingenuity and simplicity of Poka-Yoke devices, but we have yet to invent one for every defect opportunity, and, until we do, must rely on less powerful tools. The first, usually counterproductive reaction to human error is to blame the human for being sloppy; the second, to identify lack of training as a cause. Only by asking “Why?” a few more times do you identify deficiencies in the design of the process’s human interface.

Training and Instructions

Training does contribute to avoiding errors. It is necessary to make a new operator proficient, to jog the memory of one who has not done this job for a while, and to let supervisors notice discrepancies between prescribed methods and an operator’s practice. Effective training and instruction materials will not physically prevent mistakes, but they will reduce their likelihood. From TWI in the 1940s to today’s research on instructional design, much more work has been done in this area than is used in most companies. One example I used as a model is Ikea’s wordless assembly instructions, which fit the needs of Ikea’s worldwide customers, but would not be sufficient for production operations, because they don’t provide, for example, criteria to validate a step completion like “tighten until the indicator light turns green” or explanations of key points.

Cookbooks are a rare category that keeps selling well in hardback in the age of ebooks. They are essentially collections of instructions on how to make things, but it is astonishing to see how even the best still don’t apply well-known principles of instruction. Take, for example, Julia Child’s famous recipe for Boeuf Bourguignon. The layout of the page is definitely better than in most cookbooks, because it separates the recipe into a sequence of operations and provides a list of ingredients for each operation, as opposed to the recipe as a whole, which Tablespoon’s online version of the same recipe doesn’t do. Each operation is itself a sequence of steps each with its own key points and requiring different utensils, but it is all in an unstructured block of text, in which it is easy to miss a step or realize half-way through that you are missing a tool, as in the following excerpt:

The following table shows how the same information could be presented in a structured form, with check marks to track progress. On screen, checking off a step could even result in its vanishing, so that only the remaining steps appear.

Of course, if Julia Child had presented her recipes this way, her book might have risen to 2,000 pages instead of 700. At home, your dinner guests may not know that the meat is supposed have a light crust, and not notice that you skipped a browning step. In manufacturing processes, however, the consequences are more severe. If you supply engines with missing gaskets, the customer will definitely get back to you on it, and it pays to itemize the process in steps comprised of a single action verb with a single object, particularly when instructions are presented on screen rather than in hardcopy.

Usability Engineering

When developing training materials, you often realize that the actions required for the various tasks are more complex and counterintuitive than they should be, like the ones the apprentice alien in Pixar’s “Lifted” tries hard to follow. This is discussed in my recent conversation with Philip Marris and in Section 3 of The Purpose of Standard Work in Manufacturing. The art of making human interfaces to machines and systems simple and intuitive is called usability engineering, and it is widely applied in household appliances and consumer electronics, if not in production machinery. According to Art Smalley, Toyota has started applying it in its production lines to reduce both operator training costs and the rate at which mistakes occur.

https://www.youtube.com/watch?v=pY1_HrhwaXU

Again, usability engineering falls short of Poka-Yoke because it does not make mistakes impossible, only less likely. In The Design of Everyday Things, Don Norman offers a complete theory of faucets, which is a good example to get an idea what usability engineering consists of. Traditional faucets have separate knobs to control the flows of hot and cold water, making it a challenge to control what you are really interested in, namely flow rate and temperature. Based on usability engineering, modern faucets let you directly control flow rate and temperature.

As with faucets, the interfaces of many products are initially centered on their technology, and usability engineering migrates them towards the users’ purposes. For example, photographic cameras, as late as 1980, required users to set aperture, shutter speed, and distance, settings that were not directly related to what they wanted to do. 20 years later, the cameras offered predetermined settings for landscapes, portraits, sports, close-ups, etc. that allowed amateurs to reliably produce the pictures they intended, without having to study the proper combinations of aperture, speed and distance.

When originally introduced, the Mac computer was a paradox, in that it was a breakthrough in usability for end users, but not for programmers. My friend Caroline Rose, as a member of the original Macintosh development team, wrote the seven volumes of Inside Macintosh, the thousands of pages of small print a developer needed to master. 30 years later, today’s Mac is a much more sophisticated machine, with mobile siblings like the iPad and iPhone, but all you need to learn to write software for the whole family is to learn a language called Swift, that has a user guide of 46 pages, and multiple offerings of 3rd-party books mostly aimed at readers who have never developed for these machines before.

Conclusion

Within TPS, Poka-Yoke and the Kanban system are tools that attract attention, because they are clever and stand out in a factory tour. But we should put them in perspective. Poka-Yoke is worth pursuing, but only when human error is the main causes of quality defects, which occurs once the process is capable and production is organized to flow so that discrete breakdowns in the process are promptly detected.

In the meantime, providing effective instructions and applying usability engineering to the design operator workstations, while falling short of physically preventing mistakes, reduce their likelihood as well as training costs.  If you address the issues in the proper sequence, you will first reduce and then eliminate mistakes, while simultaneously reducing training costs and increasing productivity, and no production supervisor in his or her right mind would want to undo this.

This post only addresses technical issues. The effectiveness of changes on the shop floor and their acceptance by operators depends on their level of involvement in design and implementation. The question started with “I’m a manufacturing engineer and since I have started participating in kaizen workshops…” This statement makes me wonder what kind of workshops these were, and who was participating, but that is a different discussion.