Build PFMEA from a failure chain to verified action

Build PFMEA from a failure chain to verified action

Process FMEA considers how a process could fail before relying on failures to teach the lesson. Start with scope, structure and intended functions. Connect the failure effect, failure mode and potential cause at the appropriate levels. Keep prevention controls separate from detection controls: stopping the wrong selection differs from finding an under-tightened joint afterwards. Evaluate risk with the applicable authorized method, choose actions, verify their implementation and effectiveness, and document the results. The seven-step approach organizes that work; it is not a reason to invent ratings or reproduce proprietary tables. A predicted cause in risk analysis is also not proof of the cause of a past incident.

Follow the method

1. Scope, structure + function
2. Failure chain
3. Existing controls
4. Evaluate risk + choose action
5. Verify + document

Connect a failure cause to a verified risk action

Fictional case: joint assembly can use the wrong program. The potential process failure is an under-tightened joint; the downstream effect is loss of joint function. Those distinctions remain in the core lesson. Facilitator Dev reviews a draft that repeats “wrong torque” in cause, mode and effect, with an invented risk number and a training action marked complete.

Follow the method

1. Wrong-program cause
2. Under-tightened mode
3. Lost-function effect
4. Action verification
5. Connected control

Do not put the same phrase in every failure column

Build a coherent cause–mode–effect chain, distinguish prevention from detection, and connect a proposed risk action to verification and controlled documents.

Fictional case: joint assembly can use the wrong program. The potential process failure is an under-tightened joint; the downstream effect is loss of joint function. Those distinctions remain in the core lesson. Facilitator Dev reviews a draft that repeats “wrong torque” in cause, mode and effect, with an invented risk number and a training action marked complete.

Role: Cross-functional process-risk team with engineering and quality owners

Normal condition

Process structure and intended functions lead to specific failure chains, existing controls, applicable risk evaluation and verified actions.

The gap

The worksheet looks populated but cannot explain what fails, why it might happen or how an action would change the risk.

• Use the applicable customer-authorized FMEA method and licensed criteria.
• No proprietary severity/occurrence/detection or Action Priority tables are reproduced or inferred.

1. Start from scope and function

   Dev identifies the assembly operation, interfaces and required joint function before writing failure statements. He asks who receives the output and what the receiving process depends on.

   Why: A failure chain needs a defined function and level of analysis. Without that context, a phrase may be mistaken for cause, mode or effect.

   Evidence: The reviewed scope connects operation and receiving function.

2. Separate the linked failure statements

   The team records wrong-program selection as a potential cause, under-tightening as the mode and loss of joint function as the effect. It checks the causal direction rather than merely filling columns.

   Why: The mode describes the process failing its function; cause explains how it could arise; effect describes its consequence at the relevant next level.

   Evidence: The three statements differ and form a coherent chain.

3. Distinguish existing controls

   A suitable program-selection prevention control would address the cause. A suitable joint-condition inspection would detect a resulting condition. The team records what actually exists, not what it hopes to add.

   Why: A proposed control is not an existing control, and detection does not necessarily prevent occurrence. This distinction affects the risk discussion and action choice.

   Evidence: Each control is marked existing or proposed and prevention or detection.

4. Evaluate and choose action through the applicable method

   Dev uses the authorized evaluation criteria and ownership process. In the AIAG/VDA approach the seven-step structure and Action Priority are not replaced by an invented RPN threshold.

   Why: Risk labels must come from the applicable method and evidence, not a convenient score. A public training example cannot supply a customer’s ratings or approval.

   Evidence: The record identifies the evaluation authority and keeps unsupported ratings blank.

5. Verify the action and update the connected controls

   The team proposes a controlled program-identity check or other engineered solution for specialist review, defines an authorized challenge and records evidence before changing residual-risk status. It aligns the control plan and instruction.

   Why: Completing a training session is an activity, not proof of effective prevention. Verification must test the intended failure mechanism and preserve the outcome.

   Evidence: The action has an owner, verification criterion and linked-document updates.

The proposed interlock is bypassable

During design review, the team finds a maintenance override that can bypass the proposed program check.

Include authorized override conditions, access and return-to-normal verification in the risk/action review before calling prevention effective.

A control that works only in the normal demonstration may leave a relevant failure path open. Do not remove the path from the FMEA because it is inconvenient.

The verification plan includes the permitted override scenario and its responsibility.

Run a practice session

Materials

• Blank failure-chain record
• Control cards
• No rating tables in this exercise

1. Define the function · 5 minutes

   Who relies on the output?

2. Separate the chain · 8 minutes

   Which phrase is the mode?

3. Review the label action · 10 minutes

   What does the scan actually detect?

4. Debrief bypass · 5 minutes

   Which path might the demonstration miss?

Debrief

• Require mechanism-specific verification rather than “train and monitor”.
• Accept different controls when the function and authority are explicit.

Draw the chain first, then connect each control to the cause or condition it addresses.

Transfer into the work

Owner: Process-risk owner and cross-functional team

Record: Failure chain, authorized evaluation, action evidence and controlled revisions

Review: At design/process changes and after relevant failures

Evidence: Verified control performance and aligned operational documents

Reopen the risk/action review when evidence exposes an unaddressed path or ineffective control.