ORDREL / LEARN · ENGLISH
Poka-Yoke: Manufacturing Mistake-Proofing Examples
Poka-yoke makes an error harder to commit or makes it detectable before an unacceptable result proceeds. Start with the specific error mechanism, then verify that the proposed control works under realistic conditions.
Name the error and the escape point
Describe what can go wrong, how it happens, where it can first be detected and what permits it to proceed. Distinguish an error in the process from a resulting defect. A control should address a supported mechanism, not a generic instruction to pay more attention.
Prevention changes the task so the error cannot occur within the defined conditions. Detection identifies it. A warning relies on a response; a stop or interlock prevents the next step only if it is correctly designed, validated and maintained. Software descriptions in a worksheet do not create physical controls.
Compare practical control ideas
Fictional manufacturing teaching example. These figures are not ORDREL customer results.
| Error mechanism | Candidate control | Challenge and limitation |
|---|---|---|
| A part can be loaded backward. | A keyed fixture that accepts only the intended orientation. | Try all plausible orientations with approved test pieces; check wear and similar parts. |
| The wrong leaflet variant can be packed. | Compare a verified identifier with the work requirement before release. | Test a mismatch, unreadable code and missing requirement; a readable wrong master record still fails. |
| A required fastener can be omitted. | A validated sequence/count check before the next operation. | Test missing and duplicate operations; a count alone may not prove correct torque or location. |
| A material quantity can be selected incorrectly. | A constrained choice or approved physical quantity control. | Check unusual orders and recovery paths; uncontrolled overrides can defeat the control. |
Choose the least complex control that reliably addresses the mechanism. These concepts require engineering and site approval; they are not instructions to modify safety-rated equipment or bypass an existing interlock.
Design a challenge test before the rollout
Write the expected behavior for a correct condition, each known incorrect condition, a missing or unreadable input and a failed control. Use approved non-saleable test items and the site’s existing change controls. Specify the safe response and who is authorized to recover the process.
Check usability: can a correct task be completed without confusion, and does a false alarm encourage bypassing the check? Record exceptions and maintenance needs. Never infer that a control is reliable merely because no error occurred during a short ordinary run.
Interpret a small fictional challenge
Suppose an approved test includes 12 mismatched test items and the proposed check identifies all 12. The observed challenge detection fraction is 12 ÷ 12 = 100%. This demonstrates those 12 conditions only; it is not proof of perfect detection in production or a validated reliability claim.
If one unreadable code proceeds without a decision, the trial has found a gap even when all readable mismatches were caught. Record the failure and revise the proposal before approval. Do not hide exceptions inside a high average detection percentage.
Document the proposal and its evidence
Use ORDREL’s mistake-proofing designer to connect the error, control concept, verification and follow-up. It helps structure a plan; it does not install an interlock, validate a safety system or guarantee zero defects.
Use 5 Whys to investigate the enabling conditions and Shift handover to communicate approved temporary controls and unresolved checks. Preserve the organization’s existing authorization and escalation procedures.
- Is training a poka-yoke? Training can support a method, but it does not by itself prevent the error.
- Is an alarm enough? Only if the detection and required response are appropriate to the consequence; assess that explicitly.
- Can a control create a new problem? Yes. Check ergonomics, false rejects, bypass incentives, maintenance and recovery.
Sources and method notes
Sources support the method definitions. Examples, interpretation and tool instructions are ORDREL teaching material, not an endorsement by the referenced organizations. See methods and corrections.