Poka-Yoke.

What poka-yoke is

Poka-yoke is Japanese for avoiding inadvertent errors, and in manufacturing it names a specific design discipline: change the part, the fixture, the tool or the sequence so that a human mistake either cannot physically happen or becomes visible within the same cycle, at the station where it happened. A connector keyed so it cannot mate backward is poka-yoke. So is a torque driver that counts fastenings and refuses to release the unit until every joint reports a good cycle.

The thinking comes from Shigeo Shingo and the Toyota Production System, and its core move is a distinction most quality systems blur: an error is not a defect. Errors, a skipped step, a reversed part, a wrong pick, are a normal output of human attention doing repetitive work. Defects are errors that were allowed to travel. Inspection accepts the link between the two and tries to filter the result. Poka-yoke breaks the link.

That is why the honest target is the error, not the operator. At 456 units per day, an error mode with a one in ten thousand chance per cycle will surface roughly every three weeks, forever, no matter who is on shift. A warning label and a training record do not change that arithmetic. A fixture pin does. Wherever a mistake is possible, enough shifts will eventually produce it, so the real choices are three: make it impossible, make it immediately visible, or plan on finding it at the customer, forever.

When not to poka-yoke

Error-proofing has a strong claim on any quality budget, which is exactly why it needs not-yet criteria. Do not build a device when:

• You cannot describe how the error actually happens. If the team has not watched the mistake occur, or reproduced it, the device will block a guess. Automating a wrong theory produces a station that is harder to use and exactly as unprotected as before.
• The risk is trivial while the top defect runs open. Gold-plating a cosmetic error mode with sensors while the number one customer escape has no barrier is a portfolio failure. Rank error modes by consequence and escape history first, then work the list.
• The step can simply be eliminated. If a fastened joint can become a formed feature, or a manual entry a barcode scan, removing the opportunity beats guarding it. Elimination sits at the top of the hierarchy below, and it is checked first.

How to implement one device

One error mode at a time, at the process, with the crew. The sequence:

1. 1

   Pick the top escape mode.

   Take it from the FMEA priority list, repeat root causes and customer complaint history, not from whatever looks easiest to put a sensor on. One error mode, one station, one device. A plant-wide error-proofing program launched everywhere at once produces mostly meetings.

2. 2

   Study how the error actually happens.

   Watch real cycles at the station, including end of shift, changeover and rework, because that is when errors cluster. Ask the operators where the traps are; they can usually name the near miss they catch weekly. Write the error mechanism in one sentence before designing anything.

3. 3

   Choose the highest feasible level of the hierarchy.

   Prevention beats detection, detection at the station beats detection downstream, and everything beats end-of-line inspection. Feasibility includes takt and maintenance: a simpler device that runs reliably at cycle speed beats a stronger one that needs a specialist every month.

4. 4

   Trial it with the crew that will live with it.

   Prototype cheaply and run at takt for a week or two. Count false triggers from day one: a device that flags good pieces teaches the area to ignore it, and an ignored device is worse than none, because it looks like protection.

5. 5

   Verify with data, not a demonstration.

   Compare the downstream defect rate before and after, over enough volume to mean something. Record the false trigger rate and the cycle time impact. Triggering reliably on a deliberately bad master piece is the acceptance test.

6. 6

   Write it into standard work and the control plan.

   The shift-start device check goes into the operator's standard work, the device becomes a control plan line, and every trigger gets an agreed next step. An undocumented device stops being checked the month its champion changes jobs.

The last step decides whether the device is still working in a year. The master piece check belongs in the operator's standard work, the device belongs on the control plan, and both belong in layered audits, because a device nobody verifies protects nobody.

A worked example: the fitting-torque station

The 450-person components manufacturer used across these guides, 456 units per day on two shifts with a takt of 118 seconds at final assembly, kept meeting the same defect: an under-torqued hydraulic fitting found at leak test, and occasionally at the customer. A root cause case had already produced a proper torque standard, yet the escape kept returning about once a week, because the residual error was not knowledge. Each unit carries six fittings, and under time pressure the sixth joint sometimes got the gun but not the full cycle. The numbers are illustrative; the pattern is not.

The countermeasure was a transducer torque driver with count verification, a counting device from the mechanism table below. The driver counts good torque cycles and the stand holds the unit until six OK signals register; a missed or incomplete joint lights the station and blocks release, all inside the 118 second cycle. The two-week trial surfaced one real design issue: rework units arriving with some joints already torqued caused false triggers, so rework got its own mode with a supervisor release and a log entry. After four weeks of clean data, the under-torque escape at leak test went to zero and the 100 percent containment check inherited from the RCCA case was stepped down to a sample.

Cheap beats clever

A mature poka-yoke portfolio looks unimpressive on a plant tour: pins, guides, templates, counters, limit switches. That is a feature. A 40 dollar asymmetric pin that makes wrong loading impossible beats a vision system nobody maintains, and it is worth being explicit about why: the pin has no drift, no lighting dependence, no parameters and no specialist. When it breaks, it breaks visibly. Complex detection fails quietly, and a quietly failed device is worse than none, because the area believes it is protected.

The other reason cheap wins is who can design it. Operators know where the traps are: which two labels look alike at 3 am, which part almost fits backward, which step gets skipped when the line runs behind. Make error-proofing a standing lane of kaizen: one error-proofing idea per team per month, built by the team with maintenance, costs little and steadily removes traps no capital project would ever reach.

What good devices have in common

• Adds zero motion and near zero seconds: at a 118 second takt, a device that costs three extra seconds per cycle will be bypassed by Thursday.
• Fails safe: when the device itself dies, the station stops, instead of passing unverified pieces.
• Testable in one minute with a known-bad master piece, so the shift-start check actually happens.
• Understandable by everyone in the area: a crew that cannot explain what it checks cannot notice when it stops checking.
• Cheap enough to copy, so the second and third stations do not need a budget cycle.

After the device: shrinking inspection

A device with clean data changes the downstream arithmetic. Containment checks installed during firefighting can step down to sampling, end-of-line inspection shrinks toward an audit, and scrap and rework stop taxing the quality metrics on the KPI baseline while the quality factor of OEE recovers. This is the payoff the hierarchy promises: prevention is paid for once and keeps paying, where inspection bills every shift.

What remains is the management chain around triggers. A device that stops a piece has done half the job; someone still has to contain the piece, decide its disposition, and notice that the same error mode has triggered nine times this month, which is a problem solving assignment, not a logbook line. This is where TeamGuru fits naturally: the quality alert management use case gives every triggered device a reaction workflow, with the alert raised at the station, containment and disposition carried by owners with dates, and repeat triggers visible enough to demand a root cause case.

On the roadmap, error-proofing keeps running inside the equipment and methods practice as the FMEA produces new priorities, in parallel with the kaizen pipeline, and its results reach the plant's Obeya and management reviews as fewer escapes and a falling cost of poor quality.

Frequently asked questions