Identify Functional Failures

Process Steps

1. 01

   Restate each function as a failure

   Intent

   For every function, list every way it can fail against its standard — total, partial, high, low, intermittent, spurious.

   Inputs

   • Numbered function list from Phase 2
   • Historical failure events from the CMMS
   • Operator experience of nuisance events and near-misses

   Actions

   • Ask: fails high, fails low, fails intermittently, fails to start, fails to stop
   • Include over-performance and unwanted function where relevant
   • Number failures under their parent function (1.A, 1.B, 1.C…)
   • Test that every listed failure is a breach of a measurable standard

   People

   Reliability engineer facilitates. Operators supply the intermittent / partial failures that don't show up in the CMMS.

   Process

   Failures are enumerated per function before any Phase 4 discussion of causes. A failure without a parent function is invalid.

   Technology

   Failure register with function ID column and failure ID column.

   What Good Looks Like

   • Every reliability, maintenance and operations lead can point to where this step lives — decisions, evidence and outputs are in one place, not in someone's inbox.
   • The opposite of: only listing total-loss failures
   • The opposite of: jumping to causes before finishing failures
   • The opposite of: duplicate failures across functions because numbering is inconsistent

   What Bad Looks Like

   • Only listing total-loss failures — partial and unwanted failures ignored
   • Jumping to causes before finishing failures
   • Duplicate failures across functions because numbering is inconsistent

   Outputs

   • Complete list of functional failures per function
   • Numbering that maps every failure back to a parent function
2. 02

   Test each failure against the standard

   Intent

   Confirm every listed failure is a real breach of the Phase 2 performance standard — challenge unclear cases.

   Inputs

   • Draft functional-failure list from Step 3.1
   • Phase 2 performance standards
   • Trend data or event history for disputed cases

   Actions

   • Refer every proposed failure back to its parent standard
   • Escalate to the asset owner when the standard itself is disputed
   • Delete pseudo-failures that don't breach a measurable standard

   People

   Facilitator + operations supervisor. Asset owner is the tie-breaker on disputed standards.

   Process

   No failure enters Phase 4 without a clear parent standard. Any standard change is fed back into the Phase 2 register.

   Technology

   Same failure register as Step 3.1, with a validated-flag column.

   What Good Looks Like

   • Every reliability, maintenance and operations lead can point to where this step lives — decisions, evidence and outputs are in one place, not in someone's inbox.
   • The opposite of: keeping 'failures' that don't breach any standard
   • The opposite of: rewriting the standard on the fly to fit an observed event
   • The opposite of: skipping the validation pass because the FMEA is already booked

   What Bad Looks Like

   • Keeping 'failures' that don't breach any standard
   • Rewriting the standard on the fly to fit an observed event
   • Skipping the validation pass because the FMEA is already booked

   Outputs

   • Validated functional-failure list ready for FMEA
   • Standard-change register where Phase 2 statements needed revision

People

Reliability engineer + operations supervisor. Maintenance planner records historical events that map to each functional failure.

Process

Every functional failure links back to exactly one function. This structure protects the FMEA in Phase 4.

Technology

Failure register — column headed by function ID, failure ID and description.

Phase Outputs

• Complete list of functional failures per function
• Cross-reference back to CMMS work-order history