PFMEA Development & Revision

1.0 Position

The difference between a filled-in form and an analysis

A PFMEA passes document review easily. Almost any spreadsheet with the right columns will. It fails a different test: whether the failure modes listed are ones your process can actually produce, and whether the controls listed are ones you actually run.

Generic PFMEAs are recognizable within a page. They contain failure modes for operations you do not perform, detection controls that describe an inspection nobody does at that frequency, and causes written at a level so general — “operator error”, “machine malfunction” — that no action could ever follow from them.

The logic AiroQue holds the document to

Every line is a chain, and the chain has to hold from end to end:

Function and requirement

What the operation is supposed to achieve, stated concretely enough that a failure of it can be described. Vague functions produce vague failure modes.

Failure mode

The specific way the operation fails to meet the requirement, in the language of the process: undersize, mislocated, missed operation, wrong material, incomplete cure, incorrect torque sequence.

Effect and severity

What that failure causes downstream, at the next operation, at final inspection, at your customer, and in service. Severity is driven by the worst credible effect, using the scale your customer or quality system defines.

Cause

Written at the level where a control could actually act — a specific fixture, setting, material condition or handling step, not a category.

Prevention and detection controls

Separated deliberately, because they are not equivalent. Prevention changes the odds that the cause occurs; detection only changes the odds that the result escapes. Documents that blur the two overstate how protected the process is.

Evaluation and action

Risk evaluated by the method your program uses, with recommended actions that name what changes in the process — not “monitor” or “emphasize during training”.