Mistake-Proofing Mistakes

There is a popular lore provided by Shigeo Shingo, that the original name for mistake-proofing (Poka-Yoke) was “fool-proofing” (Baka-Yoke). Shingo chided managers at Panasonic for using the latter term, as it was disrespectful to workers, essentially calling them fools. Shingo substituted the word “mistake” for “fool”, because, as he aptly noted, making mistakes is part of humanity. “Mistakes are inevitable,” he said, “but the defects that arise from them are not.”

Notwithstanding Mr. Shingo’s admonitions, however, I still hear the term “fool-proofing” used regularly, and occasionally with a little more venom, “idiot-proofing.”   No doubt, these derogatory terms, along with others like ‘screw-up’ and its less gentile derivatives, have given a bad name to one of the most energizing, empowering and creative tools from the TPS toolbox. Many organizations never even get out the blocks with this technique because of an overt insulting, blame environment. Who wants to report a mistake, when the reward is blame and ridicule? Like Mr. T, managers tend to blurt out the wrong words when mistakes occur. Bad habits die hard.

But even for more enlightened managers there are still some common hurdles to creating a really powerful Poka-Yoke system. A few weeks ago I gave a short Webinar for AME on Poka-Yoke, and was asked this question by a viewer:

“How do I ensure the effectiveness in use of the Poka-Yoke device? People usually don’t want to continue using it.”

Here, with a few embellishments, was my response:

“The general answer to this question from today’s Webinar is that if people don’t find a particular tool purposeful, they don’t use it.  More specifically for poka-yoke, there are seven reasons that the tool is not seen to purposeful by team members:

1. Sometimes to assure quality, an additional step is added to the operation to prevent or detect the defect, but this step is not considered in the standardized work, i.e., no additional time is allowed.   If the device or method requires an extra step that takes more time (e.g. use of a check list or matching parts to a template) then employees will feel rushed and pressured to choose between rate and quality.
2. A corollary to the lack of standardized work is the lack of communication to team members, team leaders and managers. An undocumented and untrained standard is not a standard.
3. If the device or method causes strain to the employee it won’t last. Substituting Muri for Muda is not a good trade off.
4. For detect-type poka-yoke devices (i.e., a defect is created, but is detected before it can pass to the next operation), the concept involves swarming the defect when it’s trapped in order to understand its root cause. I see many cases where defects are trapped, but there is no follow up. Defects pile up, or they are picked up occasionally by engineering or quality, and no feedback goes back to the production line.  When problems don’t get fixed, this promotes cynicism.  It’s not poka-yoke, just a scrap sorter.
5. Sometimes, as suggested in the question above, a device is put in place, but the defect persists. This could mean the device isn’t used by the team member, but it can also mean the device just doesn’t work.  More PCDA is needed.   If the device doesn’t work, team members will be the first to know.   Telling them to use something that doesn’t work is disrespectful and disengaging.
6. The term Poka-Yoke is used too broadly to describe countermeasures that have nothing to do with human error, but relate more to providing proper tooling and fixturing to team members. For example, if a particular job requires super human sensor capability to complete (more Muri), creating fixturing to make the job doable is not a Poka-Yoke solution.   My father, who was a machinist by trade and an artist by avocation, could draw a straight line freehand around an entire room. Most of the rest of us would want a straight edge and a level to complete that task.   The point is when we refer to such countermeasures as “mistake-proofing”, we’re once again disrespecting team members.
7. Most importantly, if the employee who uses the device is not included in the solution, there is typically little commitment to use it, especially if any of points 1 through 6 apply.

That’s the long-winded answer to the short question.  The short answer to that question is that the “technical” portion of poka-yoke doesn’t work if it is not grounded by a quality culture.”

Perhaps you can think of some other common mistake-proofing mistakes to share with our readers. Please let me hear from you.

O.L.D.

By the way, a few years ago, GBMP made a Lean Training DVD about poka-yoke called "Achieving Zero Defects By Respecting Human Nature". If you'd like to learn more about poka-yoke and how to apply it in your organization, check it out here where you can read about it, view a clip from the video and purchase it if you'd like.