top of page
Search

Error-Proof

  • Writer: hidet77
    hidet77
  • 12 hours ago
  • 4 min read

On social media, you’ll often see the claim that “Poka‑yoke” was invented by Shigeo Shingo.


That statement is only half the story.


When we go back to Shingo’s own writing, the picture is more nuanced and far more interesting than a simple “he invented a word” narrative.



From “Foolproof” to “Poka‑yoke.”


Shingo himself described Poka‑yoke as:


“Basically, it is the same line of thinking as ‘foolproof,’ which was thought to apply only to safety issues.”


The English word “foolproof” goes back at least to 1874, and it means:


So simple, plain, or reliable as to leave no opportunity for error, misuse, or failure.


The original idea, then, is not uniquely Japanese: it’s about designing things so that people cannot easily make mistakes, rather than expecting people to be perfect.


What Shingo did was to translate, adapt, and extend this way of thinking into the context of manufacturing and quality.



Why wasn’t it “Baka‑yoke” for long?


Early on in Japan, this concept was sometimes called “Baka‑yoke”:


“Baka” means fool or idiot.


• So “Baka‑yoke” literally means fool‑proofing.


You can imagine how that sounded to operators on the shop floor.


Being told that the system is designed to protect you, the baka, from your own mistakes is not exactly motivating or respectful. Unsurprisingly, operators didn’t like the term, and they were right to feel that way.


Shingo’s response was thoughtful. He changed the expression to “Poka‑yoke”:


“Poka” means careless miss or inadvertent slip.


• The term comes from shogi (Japanese chess), where it describes an unbelievable blunder — the kind of move you immediately regret.


This subtle change matters. The problem is no longer the foolish person but the fallible human being who can make a careless mistake under pressure, fatigue, or distraction. The focus shifts from blaming people to designing processes that anticipate human limitations.



The real power of Shingo’s contribution.


It’s tempting to obsess over who invented the term and where each word comes from. But that’s not where Shingo’s true contribution lies.


The important part is not the origin of the word, but the application of the concept.


Poka‑yoke is not a single tool or device. It’s not a shape you memorize or a trick you can copy from one factory to another. It is a way of thinking:


How can I design this process so that making an error is impossible or immediately obvious?


And that way of thinking must change every time the product or process changes.



Why can’t you copy & paste Poka‑yoke?


Even within the same company or technology, Poka‑yoke is highly contextual.


I made my first Poka‑yoke almost 20 years ago in a weld area. Since then, I’ve been eager to reuse the exact same design — but it has never quite worked out:


• The product design changed.


• The fixtures were different.


• The risks of error and types of mistakes were not identical.


I have implemented many similar ideas, but never exactly the same one.


This is the essence of Poka‑yoke in practice:


• It’s not about memorizing a catalog of clever jigs and fixtures.


• It’s about understanding the underlying principle, and then reshaping it to fit the specific product, process, and environment every single time.


If you treat Poka‑yoke as something you can just copy & paste, you miss its entire power.



From safety to quality… and beyond.


Originally, foolproofing was associated mainly with safety:


• Preventing people from getting injured.


• Ensuring machines could not be operated in dangerous ways.


Shingo’s breakthrough was to extend this logic to quality:


• Preventing defects before they occur.


• Detecting abnormal conditions at the earliest possible moment.


But if we truly follow Shingo’s thinking, we don’t have to stop at safety or quality. The same mindset can be applied across many aspects of operations:


Changeover: How can we design our tooling so it cannot be mounted in the wrong direction and allow die exchange without loss of efficiency?


Maintenance: How do we structure maintenance tasks so that critical steps cannot be skipped or forgotten?


Logistics: How can we design material flow so that the wrong part, quantity, or batch is almost impossible to pick or ship?


Standardized work: How can we arrange layout, tools, and sequence so that following the standard, most efficient method is the path of least resistance?


Wherever there is a risk of human error, there is an opportunity for Poka‑yoke.



Opening your mind to Poka‑yoke.


To truly embrace Poka‑yoke, we need to shift our questions:


• From: “Who made the mistake?”


• To: “How did the process allow this mistake to happen, and how can we redesign it so it won’t happen again?”


This is a fundamentally respectful stance. It assumes that:


• People are doing their best under the conditions given.


• It is our responsibility as designers, engineers, and leaders to create error‑resistant systems.


When we open our minds this way, Poka‑yoke becomes a general design philosophy rather than just a quality tool.



Kaizen as the evolving face of Poka‑yoke.


Many forms of Kaizen are simply the ongoing application of Poka‑yoke thinking:


• Understanding how and where errors occur.


• Redesigning work so those errors are prevented or exposed immediately.


• Adapting solutions to each product, process, and context, rather than copying what worked somewhere else.


This is why you can’t just copy & paste a Poka‑yoke.


You can be inspired by other examples — and you should be. But the real work is to:


1. Grasp the concept.


2. Study your own process.


3. Shape a unique error-proofing solution that fits your situation.


Shigeo Shingo gave us far more than a clever term. He gave us a way to look at work: one that assumes people are human, errors are natural, and good design makes the right way the easy way.


That’s the real legacy of Poka‑yoke.



Reference;

新郷重夫. (1985). 源流検査とポカヨケ・システム : 不良=0への挑戦 0QC方式への展開. 日本能率協会.

 
 
 

Comments


©2021 by HMOperationsManagement.com. Proudly created with Wix.com

bottom of page