PFMEA Practice Clarification (Part 1) | Why Can't "Operator Error" Be a Failure Mode? —— Identifying the Boundary Between Failure Modes and Failure Causes

1. A Scene from the Review Meeting: "Operator Error" in the Failure Mode Column

A company was holding a PFMEA review meeting, and when they turned to the assembly process page, the failure mode column prominently displayed "operator omits washer" and "operator error causes bolt not tightened." The review expert asked, "What problems will the product of this process have?" The engineer confidently replied, "It's operator error; they get careless and omit it." The expert then asked, "What state does the product end up in after the omission?" The meeting room fell silent for a few seconds—everyone realized that the entire table lacked the description "washer omitted (product missing washer)," and all the failure modes were about "what the operator did wrong" rather than "what the product became."

This is not an isolated case. Writing operator errors or mistakes as failure modes is one of the most common and hidden errors in PFMEA preparation. It may seem "logical"—after all, failures are indeed caused by human operations—but once the wrong position is written, the subsequent severity rating, cause analysis, and improvement measures all become misaligned. This article will clarify the boundary between failure modes (FM) and failure causes (FC) once and for all.

2. Standard Definitions: Failure Modes Are "Product Nonconformities," Not "Human Errors"

Let's start with two standard definitions.

AIAG FMEA Fourth Edition defines process failure modes as the ways in which a process fails to meet process requirements and/or product design intent. Specifically for PFMEA, the failure modes of the process are "product characteristics that do not meet design intent or process requirements." In other words, when writing failure modes, the question to answer is: Which characteristic of the product/semi-finished product from this process does not meet the requirements? Not: Which action did the operator perform incorrectly?

AIAG-VDA FMEA Handbook (2019) has a clearer structure. It breaks down the PFMEA analysis object into three layers:

• Focused Element (Process and Its Output): The product/semi-finished product processed by the process—its failure is the failure mode (FM).
• Superior Element/End User: Downstream processes or the entire vehicle/end customer—their failures are the failure effects (FE).
• Process Elements (4M: Man, Machine, Material, Method): The input elements of the process—their failures are the failure causes (FC).

Note that "man" (Man/operator) is part of the process elements in the AIAG-VDA framework. Therefore, operator errors, mistakes, and negligence are positioned as failure causes (FC), not failure modes (FM). The correct way to write FM is: "the state of the finished/semi-finished product does not meet the requirements."

The definition in the AIAG glossary (collected by Elsmar Cove) also confirms this: A failure mode is "a manner in which a product or process fails to perform its intended function (design intent or performance requirement)." The subject of the manner is "product or process," not "human."

The granularity of failure mode descriptions is also important. Common types of failure modes in the industry include: complete failure (function not realized at all, e.g., "no output"), partial failure (performance below requirements, e.g., "insufficient torque"), intermittent failure (sometimes good, sometimes bad, e.g., "poor contact"), degradation failure (performance deteriorates over time, e.g., "seal aging and leakage"), and unexpected function (an unintended function appears, e.g., "misoperation"). All five types focus on the "state of the product/characteristic," not on "what the human did." When writing failure modes, you can check if your description aligns with the product state using these five types.

Another point of confusion is that failure modes should be described at a "observable and measurable" level, but not slide into "operational details." For example, "bolt torque below the lower specification limit" is an appropriate level of granularity—it directly corresponds to the torque characteristic of the product and is measurable. "Operator did not hear the click" is not appropriate—it describes the operational process, not the product state. The correct granularity standard: the inspector can directly check the failure mode without inferring the operational process.

3. Three-Layer Structure: Each Concept in Its Place

When the three concepts are placed together, the boundaries become very clear. Using "washer omitted" as an example:

Key points: Failure modes must focus on the "product state" and be inspectable, observable, and measurable. "Missing washer" can be detected through visual inspection or sensors; "operator omitted" can only be inferred from the result, and it is not a product state. Similarly, "bolt torque below the lower specification limit" is a failure mode, while "operator did not follow torque settings" is a failure cause.

4. Four Rulers: Quickly Determine if You Have Written a Failure Mode

During the review, you don't need to memorize the definitions; use the following four rulers to measure each item. If any one of them fails, what you have written is a cause, not a mode:

Ruler One: Is the subject the product or the human? The subject of the failure mode description must be "product/semi-finished product/characteristic" (e.g., "shell crack," "washer omitted," "hole diameter out of tolerance"); if the subject is "operator/operation/action" (e.g., "operator error," "omitted," "wrong tightening"), it is always a cause.

Ruler Two: Can it be inspected? Failure modes should be states that can be directly confirmed by inspection methods. "Missing washer" can be inspected; "human forgot" cannot. If the inspector can check the failure mode list, it is a qualified FM list.

Ruler Three: Who is the severity (S) rated for? Severity (S) is rated based on the impact of the failure mode on the customer, not on the operator. If "operator error" is used as FM, the team will either be unable to rate S or will rate it based on the impact of "human error," which makes S/O/D meaningless—S is the first weight in risk ranking.

Ruler Four: Can multiple causes be listed? Multiple failure causes should be listed under one failure mode. "Washer omitted" can list several causes: operator omitted, material shortage not detected, poka-yoke failure, work sequence change, etc. However, what can be listed under "operator omitted"? "Operator in a bad mood"? If a cause lists another cause, it indicates that the hierarchy is already confused.

The following examples will make the distinction clearer:

5. The Cost of Writing in the Wrong Place

Some people think, "It's just a matter of wording, the meaning is similar." In reality, the cost of writing in the wrong place is systemic:

First, severity (S) is distorted. The severity of the failure mode must be rated based on "the impact of the defect on the customer." If "operator error" is used as FM, the team will either be unable to rate S or will rate it based on the impact of "human error," which makes S/O/D meaningless—S is the first weight in risk ranking.

Second, cause analysis is blocked. If FM is written correctly, there is room to expand "why this product defect occurred" (multiple causes). If FM is written as a cause, the cause column will either be empty or repeat the same "operator error," breaking the analysis chain and preventing root causes from being traced to equipment, incoming materials, or methods.

Third, improvement measures are misaligned. Measures for FM are "detection" (adding inspection tools, poka-yoke detection), while measures for FC are "eliminating the cause" (poka-yoke improvement, automation, training). If "operator error" is used as FM, the measures will become slogans for "error" itself—such as "strengthen responsibility" or "pay attention to operation"—and none of the necessary poka-yoke, tooling improvements, or parameter controls will be proposed. This is one of the reasons why many companies do PFMEA year after year but see no reduction in nonconformities.

Fourth, it is easily exposed in audits. IATF 16949 auditors and customer process auditors will specifically check whether FM and FC are clearly distinguished. A PFMEA with "operator error" in the failure mode column is usually directly judged as invalid—because it does not identify any real product risks.

Fifth, inspection methods have no place. Failure modes are the "targets" for detection and control (inspection, poka-yoke detection)—each inspection item in the inspection plan and control plan corresponds to a failure mode. If FM is written as "operator error," the inspection items lose their target: you cannot design an inspection tool for "operator error," only for "missing washer" or "insufficient torque." If FM is misaligned, the detection measures and control plan will also be misaligned, which is one of the common roots of misalignment between PFMEA and the control plan.

Sixth, the connection between DFMEA and PFMEA is broken. DFMEA identifies the failure of product characteristics (such as "sealing failure"), and PFMEA should承接 these characteristics and clearly state "how the manufacturing process leads to the characteristic not meeting the requirements." If the FM in PFMEA is all about human errors, the main thread of product characteristics is broken, and the key characteristics (such as sealing, torque) from DFMEA will not find a place in PFMEA, breaking the chain of special characteristics transmission—this is precisely the most common issue caught in customer audits.

6. Practical Steps: Rewrite Failure Modes from the Process Function

Correcting the mistake of writing causes as modes does not require starting over. Follow these four steps:

Step One: Return to the Process Function. First, ask "What does this process ensure?"—not "What does the operator do?" but "What state should the product characteristics reach after this process is completed?" For example, the function of the tightening process is "bolt torque within the specification range," and the function of the assembly process is "washer correctly positioned."

Step Two: Infer Nonconformities from the Function. The opposite of the function is the failure mode: torque function nonconformity → "torque below the lower specification limit"; washer positioning function nonconformity → "washer omitted." Write using the structure "product characteristic + nonconformity state" to ensure it is inspectable.

Step Three: Expand Causes Using 4M. Under each failure mode, expand possible causes from the perspectives of man (operator error, insufficient training), machine (equipment drift, tool wear), material (incoming material abnormality, material shortage), and method (process parameter error, improper work sequence). Operator error is correct here as a cause.

Step Four: Review with the Rulers. Use the four rulers to check each row of the rewritten table: subject is the product, inspectable, S can be rated, multiple causes can be listed—pass all four, and the table is solid.

Let's walk through a complete example using a pressing process. Process function: press the bearing into the housing, with a pressing depth of 5±0.1 mm and a pressing force of 8 to 12 kN.

• Step One (Process Function): After pressing, the bearing positioning depth and pressing force meet the specifications.
• Step Two (Infer Failure Modes): Bearing not pressed to position (depth insufficient), pressing force exceeds the upper limit (bearing damage), pressing skew (coaxiality out of tolerance)—all three FMs focus on the product/characteristic state and are inspectable.
• Step Three (Expand Causes Using 4M): Taking "bearing not pressed to position" as an example—man: operator did not place the bearing correctly according to the procedure; machine: press travel switch drift, mold wear; material: bearing chamfer abnormality causing jamming; method: pressing parameter setting error. Operator error is correct here as a cause.
• Step Four (Review with the Rulers): "Bearing not pressed to position" has the subject as the product state, can be inspected with a depth gauge, severity is rated based on "abnormal operation/early failure," and lists four causes—passes all four rulers.

Now, let's look at what the incorrect version would look like: If the failure mode is written as "operator did not press to position," the cause column has nothing to write, the severity rating is unclear, and the inspection items cannot be designed—this row is useless. The same process, two different writing methods, results in vastly different analysis quality.

7. Common Misunderstandings and Self-Check List

The review chair can add a live question: randomly select a row and ask, "What product characteristic does this failure mode correspond to, how is it inspected, and what impact does it have on the customer?"—if the answer is not clear, it indicates the position is written incorrectly.

8. Conclusion

The failure modes in PFMEA answer "what is wrong with the product," not "what mistake did the human make." Operator errors always have their place—in the failure cause column, in 4M analysis, in poka-yoke measures—but they should never replace failure modes. Remember this: failure modes describe the product, failure causes describe process elements, and failure effects describe the customer; each layer in its place, and risks become clear.

Write the product state as the mode, human error as the cause, and keep the layers in their correct positions.

Knowledge code: 8.3.1

Version: v20260808

Author: Quality Think Tank Quality Think Tank is dedicated to providing systematic professional knowledge, methodologies, and practical tools for quality management practitioners, helping companies continuously improve their quality capabilities.