That Day the CPK Report Came Out, the Whole Room Was Silent for Three Seconds, and Then I Decided to Talk About Poka-Yoke
"Director, this morning another batch of goods was assembled incorrectly at the packaging station. The part number was clearly posted next to it, but the operator still picked the wrong one. This is the third time this month." Xiao Chen told me with a helpless look. My brow furrowed when I heard this, thinking, "Here we go again." Everyone had just reviewed this recently, but the DPMO value was still as high as 6210, and the Cpk was only 1.08, a complete failure. In the meeting room, everyone looked at the report, and the air seemed to freeze for three seconds. It was then that I suddenly thought, have we been focusing on the wrong thing all this time? Instead of blaming people, shouldn't we think about how to make errors impossible in the first place?
Where's the Problem? To Put It Bluntly, It's "People"
Frankly speaking, to err is human. No matter how much you train, people will still have moments of oversight, especially in high-repetition, high-pressure environments like production lines. At this point, what we need isn't more S.O.P.s or stricter supervision, but "Poka-Yoke design." To put it simply, this thing makes errors impossible to occur, or if they do occur, they can be immediately detected. It's not about replacing human judgment, but about assisting people and reducing the chances of making mistakes.
In fact, Poka-Yoke design has three levels, and when we encounter problems in the factory, we usually choose which one to use based on the situation.
- First Level: Eliminating Error Sources (Source Inspection)
* Practical Example: Imagine you have a batch of parts, including two sizes, large and small, and operators often pick the wrong one. The simplest method is to design the material bins for the two sizes differently, or separate them with dividers, so that when an operator reaches in, it's impossible to pick the wrong size. In our factory, we've tried distinguishing packaging box colors for different part numbers, or directly using specialized jigs to ensure that only the correct parts can be inserted, making it impossible to fit other sized parts.
- Second Level: Immediate Warning (Warning)
* Practical Example: The most common approach is sensors. For instance, at our assembly station, if an operator doesn't screw a certain screw in place, the machine will immediately sound an alarm, or even stop the conveyor belt. Or, as mentioned earlier, if the wrong part number is picked, scanning the barcode will cause the system to directly display a red warning: "Part number error, please reconfirm!" This kind of immediate feedback prevents errors from flowing to the next station, reducing subsequent scrap costs.
- Third Level: Error Blocking (Control)
* Practical Example: For example, if a certain process requires specific parameters, and the operator sets them incorrectly, the machine will directly lock up, preventing the process from starting. Or, on our testing machine, if a certain test result exceeds specifications (e.g., voltage exceeding 1.8V), the machine will immediately stop testing, mark it as a defective product, or even directly remove the product from the production line, ensuring that defective products do not flow out.
The Most Common Pitfall: Believing Poka-Yoke Means Assigning More Tasks to People
To be honest, I've fallen into this trap before. There was a station where assembly errors frequently occurred, and my first thought was to "write a more detailed S.O.P." and then "add another inspection point." What was the result? Operators just had one more thing to do, which didn't truly solve the problem. The error rate didn't significantly decrease, and labor hours even increased. Later, I realized that true Poka-Yoke is about designing from the source to make errors impossible, rather than trying to remedy them after they occur. To put it simply, Poka-Yoke is a design-level problem, not a management-level problem.
One Thing You Can Do Today
Go back and look at the S.O.P.s you have, identify the points where errors most frequently occur, and think about how to "make errors impossible" from the source.