What You Need to Know About Mistake-Proofing (Poka Yoke)
The goal of mistake-proofing or Poka Yoke is simple: to eliminate mistakes.
In order to eliminate mistakes, we need to modify processes so
that it is impossible to make them in the first place. With
mistake-proofing solutions, many repetitive tasks that depend upon
the memory of the worker are built into the process itself.
Mistake-proofing frees the time and minds of the workforce to pursue
more creative and value-adding activities.
involves a change in the mindset of the organization.
Organizations must establish a mistake-proofing mindset that
promotes the belief that it is unacceptable to allow for even a
small number of product or service defects. In companies that have
a six-sigma initiative, the six-sigma objective translates into a
goal of less than 3.4 defects per million opportunities or 3.4 DPMOs
Mistake-Proofing is focused on
eliminating mistakes so that the DPMO (defects per million
opportunities) is significantly reduced.
Go to top
Examples of Mistake-Proofing
The best way to teach Mistake-Proofing is through examples.
Mistake-Proofing Web- and Computer-Based Training has over 150
examples of Mistake-Proofing in a variety of settings including High
Volume Manufacturing, Assembly Operations, Job Shops, Process
Industries, Equipment Set-Up Reduction, and the office. For
more information on the training and to try a free demo lesson,
Ask “why?” 5 (or more) times to tunnel down into the root cause.
The answer to the first why is almost always an obvious symptom. The
secret behind the 5-whys technique is to accept the answer, but to
then ask why again and again until the root cause is uncovered.
Sometimes, the root cause can be found at the fourth or five why.
Often, however, you must ask “why?” more than 5-times.
What is—What isn’t Analysis
Often, listing what a problem is and isn’t helps get to the root
cause by a matter of elimination. What Is-What’s Isn’t questions
include: What happened? & What might you have expected to happen but
didn’t? Where did it happen? & Where didn’t it happen? What changed
in the process? & What didn’t change in the process? Which supplier
was involved? & Which wasn’t?
Data Collection & Data Display
Fact-based problem-solving – that’s what root cause analysis is
all about. To get facts, collect data from the process or create
data related to the process. To get facts, we collect data from the
process or create data related to the process. Once data have been
collected, there are a number of simple methods to analyze data
using graphical display techniques. Data display tools turn the data
into pictures and a picture of what has happened often leads to the
Techniques for collecting data from failure analysis include
reviewing physical evidence (much like crime scene investigation),
special testing, accelerated testing, and finite element analysis.
You might need special tools or techniques to review the physical
evidence (e.g. microscopy to look at a break surface) or you might
need to conduct special testing on the product or process itself.
Use well-designed and easy to use data collection forms. Good
detective skills can turn interviews into effective data collection
events. One of the most powerful, but also most under-used, data
collection tools is a concentration diagram.
Simulations can be used to collect data using computer modeling
software, pilot-plant experimentation, and if need be,
experimentation using the actual process itself. With the proper
model, a computer could help point the way to the root cause. Or it
might be pilot-plant trials or experimentation using the “real”
process that generates the data that leads to the root cause. In any
case, if you can recreate the problem, you are more apt to find the
While data display methods are usually easier to use, sometimes a
statistical analysis technique is needed to wring the real meaning
out of the data. SPC control charts will actively signal a problem
with a process. Correlation and regression analysis and multivariate
analysis may be needed to make sense of the data.
The “Root Cause” Question
Once you think you are at the root cause, take a step back and
ask yourself the root cause question– “Does this cause explain all
that is known about what the problem is, as well as all that is
known about what the problem isn’t?“ This is really a two-part
question: make sure the root cause found fits both the “is” and the
“isn’t” sections of the question. If the cause being tested doesn’t
fit both, then it’s probably not the root cause.
Go to top