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:
- 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.
- 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.
- If the device or method causes strain to the employee it won’t last. Substituting Muri for Muda is not a good trade off.
- 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.
- 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.
- 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.
- 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.
One can easily justify applying resources to mistake-proofing when the cost of the mistakes is high, and there is a common consensus that fixing the errors would be beneficial. How do you justify it when the cost of the mistake is far lower than the cost to mistake-proof the process?
One will of course argue that every mistake has many hidden costs, or that it reveals deeper root causes that are symptomatic of waste elsewhere, etc. But can you envision a situation where the cost of perfection is too high, and therefore there is a tolerable level of mistake-making?
Jason,
Thanks for your question. Shigeo Shingo stipulated three rules for poka-yoke devices, the third of which was “low-cost”, perhaps anticipating the diminishing returns argument prevalent then as now. His book, “Zero Quality Control” has many examples of low-cost devices, and my experience has also been that frontline employees can become very good at devising low-cost poka-yokes. In fact, I’ve never seen an instance where the cost of prevention was greater than the cost of rework, sorting or scrap; not to mention the impact on employee morale when problems are not fixed, or the customer who is on the receiving end of the ‘occasional’ defect.
I have, however, seen many instances where defects were not addressed in the name of diminishing returns, and subsequently many problems that were not reported because they were deemed to be too small. When the principle, ‘pass no defects’ is replaced with ‘pass no costly defects’, we have chosen our level of stagnation, friendly neither to employee or customer. One notable example comes to mind. Here is the link:
http://philosophia.uncg.edu/phi361-metivier/module-2-why-does-business-need-ethics/case-the-ford-pinto/
Regards,
Bruce
Nice article. In point 5, there could be a third cause besides “device not used” and “device does not work” for why defects persist – “device not suited”. Strangely enough, the text in that point is itself an example. Presumably, a spell-checker was used on this article, the spell-checker did work but it could not pick-up that PCDA should actually be PDCA! The default dictionary was not suitable for the text being examined.
I had an opportunity in 1989 to discuss Poka-Yoke (inadvertent mistake proofing) with Shingo himself. Below are extracts from my notes on his comments, and my own experiences over the last 24 years. Initially he chided me for talking about it as an individual technique, and said it should be seen as the tool for implementing his system of ‘source inspection’ and guaranteeing zero defects/accidents.
Shingo explained that traditional ‘long cycle’ inspection systems wait until an error in action produces a defective item. The defective item is then found by inspecting the output. His concept of source inspection uses the ‘short cycle’ inspection system. In this system the action itself is checked 100% using mechanical means. If an error occurs, immediate action is taken to correct it before a defect is produced. With this methodology we can guarantee zero defects to the final customer.
The basic system is simple;
The Poka-Yoke methods/devices should be designed to detect deviation from the standard actions and outputs required to satisfy the customer’s requirements. *
This can be done in three ways;
a) Physical contact.
b) Fixed values.
c) Motion steps.
In some cases at the original design stage the part can be made a Poka-Yoke device by ensuring it can only be assembled/used in the correct way.
They should also check for deviation in the 3M’s of actions and items;
Missing. Action or item not there.
Misplaced Action or item there, but in wrong position.
Malformed. Action or item are there but wrong, size, shape, colour, temp etc.
When designing Poka-Yoke devices they must check for specific deviations in the 3M’s using; a, b and c. This can be done with a ‘what can go wrong’ 3 M’s analysis.
The Poka-Yoke device should then;
1) Control the operation. Stop the process when an error or defect occurs.
2) Warn the operator. Signal to the operator that an error or defect has occurred.
They should be applied at the following check points;
1) The source action. (source check) This is the ideal as it gives zero defects.
2) Output of the action. (self check) This is our second choice as the output will be defective if the PY device is activated, but it will not be passed to the internal customer.
3) Before the next process. (successive check). At this stage the item will be defective if the PY device is activated, but it cannot go to the final customer.
With this system in place it is now possible to consistently achieve;
‘Zero Defects in our activities and production processes’.
This was Shingo’s original goal in 1965.
If applied to safety it is possible to achieve ‘Zero Accidents’. I do not understand why this methodology is not more widely used in this area.
The most impressive example of Shingo’s system I have experienced was on an assembly line for inlet manifolds in Japan. We were allowed to work on the line and challenged to produce a defective assembly. It was impossible to produce one, and we had some very talented people trying.
Once our front line people understand this system they become some of the best designers of Poka-Yoke devices.
Poka-yoke should be seen as the device for implementing Shingo’s zero defects system.
The goal is to identify deviation from the desired conditions or actions in any situation.
A good example is the selector stick on an automatic car gearbox. If the stick is not in the park position the poke-yoke switch is not activated and the engine will not start. Zero defects in all situations.
Shingoe pointed out to me that this would be impossible to achieve with statistical techniques.
Thanks Bruce and Sid.
Bruce I read the article on the Pinto. Very sobering. To me it is obvious that Ford’s decision was unethical and shows how pragmatism can lead us into treacherous waters. But do you have an example of a less ethically problematic or more nuanced situation where the cost of the mistake proofing process could exceed the benefit?
Also, Sid, what would Shingoe say when you can’t create a device to mistake-proof? What if you want to mistake proof a process, or a situation where a human being has to make a judgment call? Is that even possible, or does that just create Muri?
For context, I’m a Grower at a nursery. We have some mechanized processes, but much of what we do involves looking at a living thing in front of us and deciding if it should get planted or thrown out. Things often get planted when they shouldn’t be. We try to establish standards and training, but mistakes still get through due to human nature. One begins to wonder if the effort to mistake proof this process would grind the whole thing to a halt. In this respect, waste is sometimes seen as the lubricant that keeps the whole thing going. You could achieve zero waste, but the cost of going from 99.9% perfect to 100% perfect would put you out of business and drive your employees nuts. As a perfectionist, conceding to this view would be terribly difficult for me, but I’m trying to explore possible future states here…
Jason, if you did a 3 M’s analysis (Missing*, misplaced or malformed) on a plant cuttings, you could then create a pictorial guide for your people’s decision process and training. This would give them a more consistent decision process for selection or rejection. There are vision systems to do this, but they would be uneconomic for this application.
* On a young plant you want somethings to.be missing.
While the focus seems to be on mistake proofing “machines,” I think that there is an interesting analogy in the development world – A written process instruction can be developed in response to a mistake that has occurred. Negative terminology, lack of practitioner involvement in process development, insufficient time allocation for process steps, etc. will lead to implementation issues and, when implemation does occur, the negative environment that is created will also limit feedback / refinement if the process turns out to be overly convoluted / does not work as intended.