Select & Scope the Asset

Process Steps

1. 01

   Rank assets by criticality

   Intent

   Score every asset against safety, environment, production, quality and cost consequences so RCM effort is spent where the reliability payback is largest.

   Inputs

   • Complete asset register from the CMMS
   • Site criticality matrix (typically 5×5)
   • 12–36 months of work-order history and downtime data
   • Safety, environmental and quality incident history

   Actions

   • Run a workshop with operations, maintenance and reliability
   • Apply a 5×5 (or site-standard) criticality matrix
   • Score consequence on the worst credible failure, not the average
   • Publish the ranked list and A/B/C bands
   • Sanity-check against bad-actor downtime and repair-cost data

   People

   Reliability engineer facilitates. Operations supervisor, maintenance leader, process engineer and safety representative score together — never a single-discipline exercise.

   Process

   Criticality is scored on consequence, not likelihood. The matrix is applied consistently across every asset; scores are peer-reviewed before publication.

   Technology

   CMMS asset register with a criticality field. Criticality matrix template. CMMS downtime and cost-of-failure reports.

   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: scoring criticality by asset age or replacement cost
   • The opposite of: one person scoring in isolation
   • The opposite of: criticality never loaded back into the CMMS

   What Bad Looks Like

   • Scoring criticality by asset age or replacement cost — misses process consequence
   • One person scoring in isolation — bias goes unchallenged
   • Criticality never loaded back into the CMMS — no operational effect

   Outputs

   • Ranked criticality list with A/B/C bands loaded into the CMMS
   • Shortlist of A-class assets nominated for RCM
   • Audit trail of scoring rationale for each asset
2. 02

   Define system boundaries

   Intent

   Draw a physical and functional boundary so the RCM team knows exactly what is in and out of scope before functions are written.

   Inputs

   • P&IDs and functional block diagrams
   • Plant layout / general arrangement drawings
   • Utilities and control-system interface lists

   Actions

   • Identify all inputs, outputs and interfaces crossing the boundary
   • List sub-systems and major components inside the boundary
   • Mark utilities (power, air, water, control signals) as inputs, not analysis scope
   • Agree exclusions in writing and get facilitator + asset owner sign-off

   People

   Reliability engineer draws the boundary with the process engineer. Maintenance and operations verify no critical interfaces are missed.

   Process

   Boundary is agreed before functions are written. Any change to the boundary mid-analysis is a controlled decision — logged with the reason.

   Technology

   P&IDs, functional block diagrams and a boundary-diagram template. Store the signed diagram in the RCM analysis pack.

   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: boundary too wide
   • The opposite of: boundary too narrow
   • The opposite of: verbal-only boundary

   What Bad Looks Like

   • Boundary too wide — the team spends months on interfaces someone else owns
   • Boundary too narrow — critical failure modes fall outside the analysis
   • Verbal-only boundary — arguments erupt during FMEA about what's included

   Outputs

   • Boundary diagram with in-scope / out-of-scope items clearly marked
   • Interface list showing every input and output crossing the boundary
   • Signed exclusions register
3. 03

   Set the analysis charter

   Intent

   Lock objectives, deliverables, resource, timeline and decision authority in writing before any workshop time is booked.

   Inputs

   • Criticality shortlist from Step 1.1
   • Boundary diagram from Step 1.2
   • Facilitator, SME and approver availability

   Actions

   • Nominate the facilitator, core SMEs and executive approver
   • Set the target completion date and named review gates
   • Define success in measurable terms — task list, PM changes, redesign proposals, KPI baseline
   • Circulate the charter to every named participant for sign-off

   People

   Asset owner sponsors and signs. Reliability engineer drafts. Operations, maintenance and safety leads acknowledge participation commitment.

   Process

   The charter is a contract — no workshop starts until it is signed. Every accepted change to scope goes back through the sponsor.

   Technology

   Charter template stored with the analysis pack. Calendar bookings and workshop attendance register.

   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: no approver named
   • The opposite of: charter treated as paperwork
   • The opposite of: success left undefined

   What Bad Looks Like

   • No approver named — decisions stall for weeks at every branch
   • Charter treated as paperwork — scope drifts on day one
   • Success left undefined — nobody can tell if the analysis paid back

   Outputs

   • Signed RCM analysis charter
   • Meeting cadence and workshop schedule
   • RACI showing decision authority for each output

People

Reliability engineer facilitates. Operations, maintenance, engineering and safety supply the SMEs. Asset owner signs the charter.

Process

Criticality assessment feeds asset selection. Charter locks scope so the team cannot drift.

Technology

CMMS asset register with criticality field. P&IDs and functional block diagrams. Criticality matrix template.

Phase Outputs

• Signed RCM analysis charter
• Ranked candidate asset list with A/B/C bands
• Boundary diagram with in-scope / out-of-scope items