Poka-Yoke for Knowledge: Why Your FMEA Stays Empty

Years ago an engineer refused to write what he knew into the FMEA.

He said why out loud, in the meeting. Writing it down would reduce his own value in the company.

His answer was more honest than the form I was holding.

The incentive nobody designs for

In almost every plant there is one person who gets called when a particular machine stops. His knowledge is in no document. Everybody knows this and nobody fixes it.

The company rewards him for knowing what others do not. Then it asks him to write it down. It is asking him to reduce the reason he gets called.

Eliyahu Goldratt put the mechanism in one sentence: tell me how you measure me and I will tell you how I will behave. That engineer is measured on what only he can solve. He behaves exactly as he is measured.

The usual answer is a reminder, a template, or a training session. All three assume the problem is attention. It is not.

What Shingo actually said

Shigeo Shingo drew a line that most quality departments still blur. He separated the error from the defect. People make errors. Errors become defects only when nothing stops them in between.

His conclusion was not to ask people to be more careful. Careful is not a control. He designed the step so that the wrong action could not be completed: a fixture that only accepts the part in one orientation, a jig that will not close over a missing washer.

The point of poka-yoke is that it removes the dependency on human attention at the moment the attention is most likely to lapse.

Read the same idea against your FMEA. If the document fills only when somebody remembers, feels generous, and has an hour, the system depends on attention. There is no control.

Why the Excel FMEA dies twice

An FMEA in a spreadsheet fails in two separate places, and the second one is the reason so many of them look busy and still help nobody.

It fails at capture. Writing into it is a separate act, after the real work is finished. It competes with the next complaint. It has no deadline that anyone enforces. So it fills unevenly, mostly by the people with the least to lose.

It fails at retrieval. Even the rows that got written are hard to reach later. The engineer who needs them six months on does not know the file exists, cannot search across twelve versions of it on SharePoint, and does not know which one was current. So the knowledge is technically written and practically gone.

That second failure is why “we already document everything” and “we solve the same problem twice a year” are both true in the same plant.

What a safeguard for knowledge has to do

If attention is not the control, four properties have to hold. None of them is about software.

Capture has to be a by-product of the work. The knowledge is recorded because the case was closed, not because somebody was asked afterwards. If there is a separate step, there will be exceptions, and exceptions become the rule.

The record has to carry its source. A cause without the document, batch or measurement behind it is an opinion with formatting. The next engineer needs to be able to check it, not trust it.

Retrieval has to happen at the moment of need. Not on request, not after a search. When a similar problem is described, what was already learned has to arrive with it.

The person who writes must not pay for writing. This is the one that decides whether the other three ever run. If contributing knowledge costs status, the system will be worked around no matter how good it is.

What this produces

This is what we build at Galileon. Not a place to store documents, and not another form. A system where every closed case feeds the next one.

What that produces for the engineer, measured on our own pilot sample of 10 customer complaints with Slovenian manufacturers, January to March 2026:

• The corrective action step goes from three days of meetings to about thirty seconds for a first proposal, because the proposals come from actions that already worked on confirmed causes.
• The problem description step produces roughly three times more usable suggestions than a blank template, because it starts from similar cases instead of an empty page.
• Full traceability from the customer complaint to the preventive action, so the audit question “show me how you got here” has an answer that already exists.

What the engineer does not do: fill a knowledge base. The record is written because the case was closed.

What stays with the engineer

Agents will collect data the way people collect it today, and there will be far more of it than there is now. The last step still belongs to a person.

The judgement that does not move is analytical and critical thinking, and it shows up in four decisions:

• what does not belong to this problem
• what is noise and what is a signal
• where the interpretation is wrong
• which data has to be collected again, on a larger sample

More data raises the value of deciding which of it actually speaks to the problem.

The line worth drawing

There is a version of this where every company builds its own. Code is cheap now, so things that should have been refused get built anyway, and the result is a product with many functions and no affection behind any of them.

The question worth asking before that starts is which part is genuinely your domain, and which part is better left to people who work on it every day, hold far more data, and will ship something better than an internal MVP.

The answer is yours to give. It is worth giving deliberately rather than by drift.

More on galileon.si

• Two Years to Describe One Defect: What Toyota’s Recall Teaches About Problem Definition - what happens upstream of this, when the problem is never described well enough for the analysis to hold.
• How SolveR works
• Data security

References

• Shigeo Shingo, Zero Quality Control: Source Inspection and the Poka-Yoke System, Productivity Press, 1986. Publisher page
• Eliyahu M. Goldratt, on measurement and behaviour. Goldratt Consulting