FMECA and Criticality Analysis in Asset Reliability Management Indonesia

Direct answer (AEO): FMECA and criticality analysis are two different tools that are routinely confused, and the confusion is why both have a reputation for producing thick documents that nobody uses. Criticality analysis works top-down at asset level: it ranks which assets matter most to the business, using consequence and likelihood, so that effort can be allocated. FMECA works bottom-up at component level: it asks, for one specific asset, what could fail, what happens if it does, how it would be detected, and what should therefore be done. The correct relationship is sequential — criticality analysis decides which assets deserve an FMECA, and the FMECA decides what to do about each failure mode. Running FMECA on every asset wastes enormous effort on equipment that does not matter; running criticality analysis alone produces a ranked list with no maintenance decisions attached. In Indonesian asset-intensive operations, the discipline of sequencing the two correctly is the difference between a useful programme and a documentation exercise.

Running a criticality or FMECA study? Contact Tiaravib — email info@tiaravib.com or WhatsApp +62 821-1378-3727.

Two Tools, Occasionally Confused, and Why It Matters

Criticality analysis and FMECA are frequently described as if they were variations of the same exercise, and vendor material often blurs the distinction further by offering “criticality-based FMECA” as a single product. In practice the two sit at different levels of the organisation and answer different questions, and treating them as one activity is what produces studies that consume months and change nothing.

Criticality analysis is an allocation tool. It takes the asset base — potentially thousands of tagged items — and ranks them by how much their failure matters to the business, considering consequence and likelihood. Its purpose is to answer: where should attention go first? Its output is a ranked list with bands, and its consumers are the people who allocate monitoring effort, maintenance resources, spares budgets, and capital.

FMECA is a design tool. It takes one asset — a compressor, a pump, an electrical feeder — and works through its components asking what could fail, what the effect would be, how the failure would be detected, and what should therefore be done. Its purpose is to answer: for this machine, what maintenance is justified and what is not? Its output is a task list with intervals and a documentation of the reasoning. Its consumers are the planners and engineers who write the maintenance programme.

The connection between them is directional. A criticality assessment that stops at the ranking leaves the plant with a list but no instructions. An FMECA applied across the whole asset base applies design-level rigour to assets whose failure genuinely does not matter, which is both wasteful and counterproductive — a study covering everything takes so long that results arrive after the decisions they were meant to inform. The only coherent programme is: rank everything quickly, then engineer the few properly.

Getting Criticality Right

Criticality analysis is conceptually simple and frequently executed badly. The failure modes are consistent enough to list, and all of them are avoidable.

Combining consequence and likelihood into a single score. This is the most common methodological error. Consequence and likelihood answer different questions and drive different responses: a high-consequence, low-likelihood failure justifies protective measures and spares; a high-likelihood, low-consequence failure justifies preventive maintenance and redesign. Multiplying them into one number erases that distinction and produces rankings that no longer guide the appropriate action. The two axes must be retained separately and presented as a matrix, not collapsed into a league table.

Assessing criticality without a defined context. Consequence depends entirely on the scenario. A pump is critical if its failure stops a production line; the same pump is not critical if a spare sits in the warehouse. Criticality assessment must therefore begin with explicit definitions: what counts as a production loss, what redundancy is assumed, what the assessment period is. Without these definitions, two assessors will classify the same asset differently and the output will not be reproducible.

Assessment by the wrong people. Criticality requires knowledge of how the plant actually operates, not how it is documented. Operators, maintenance technicians, and process engineers hold that knowledge; a consultant working from P&IDs will produce a plausible ranking that misses the operational realities. The most defensible approach is a structured workshop with the people who run the plant, facilitated rather than dictated by the analyst.

No refresh mechanism. Criticality changes. A production line is re-purposed, redundancy is added, a spare is discontinued, a customer contract changes what counts as a consequential loss. A criticality assessment treated as a one-off project is out of date within two or three years and will be quietly ignored. Building an annual review into the process is what keeps it alive, and the review is inexpensive once the initial framework exists.

Running an FMECA Without It Stalling

An FMECA on a single complex machine can consume weeks if it is allowed to. The studies that complete and get used share a set of characteristics that keep them bounded.

Fix the boundary before starting. Decide what is inside and outside the analysis. A compressor FMECA should state explicitly whether it covers the driver, the lube oil console, the control system, and the associated piping, or only the compressor body. Without a stated boundary, the analysis expands indefinitely and the task list becomes unmanageable.

Work from failure history, not imagination. The most time-consuming and least useful FMECA exercise is brainstorming every theoretically conceivable failure mode. The corrective is to start from the plant’s own failure records plus industry failure data, and to consider only failure modes that are both plausible and consequential. A failure mode that has never occurred and is not physically credible does not need a task.

Force a decision on every failure mode. Each failure mode must end in one of a small number of outcomes: a condition-based task with an interval and a technique, a scheduled restoration or discard task with an interval, a redesign recommendation, a run-to-failure decision with documented justification, or a hidden failure requiring a proof test. A failure table with no decision column is not an FMECA, it is a list.

Record the reasoning, not just the answer. The most valuable output of a well-run FMECA is often the documented reason a task was not created. When the next engineer asks why a particular pump has no planned maintenance, the FMECA explains that the failure mode was assessed as tolerable given installed redundancy and a cheap replacement. Without that record, somebody will add the task back, and the organisation will drift toward over-maintenance one decision at a time.

Using the Output

The reason these studies acquire a reputation for being ineffective is that their output is frequently not connected to anything. An FMECA that produces a task list which is never loaded into the maintenance management system has produced nothing except a document. Three connection points determine whether the work delivers.

The first is the maintenance management system. Tasks identified must become work order templates with defined intervals and techniques, or they will not be executed. This sounds administrative and is the single most common point of failure. This connects directly to the predictive maintenance framework, which is where the condition-based tasks from FMECA become scheduled monitoring work.

The second is the monitoring programme. Every condition-based task identified in an FMECA becomes a measurement with a technique, an interval, and a reporting requirement. If the FMECA says a bearing failure should be detected by vibration at monthly intervals, the monitoring programme must contain that measurement at that interval on that asset. The criticality ranking feeds the monitoring priorities; the FMECA defines the specific measurements.

The third is the spares and capital processes. An FMECA that identifies a long-lead component with a high consequence of failure has identified a spares holding requirement and possibly a redundancy case. Those findings need to reach the people who control the spares budget and the capital plan, which means the study’s output must be routed beyond maintenance. This is where the study connects to the wider asset reliability management strategies that the organisation uses to allocate resources across competing demands.

Realistic Scope and Sequencing

For a typical Indonesian plant the practical programme is: a full asset-level criticality assessment across the tagged asset base, completed in weeks rather than months using structured workshops; functional analysis and FMECA on the top 5 to 15 percent of assets, chosen by criticality; and a formal RCM workshop on perhaps three to five machines where the economic consequence justifies the depth. Everything else continues on existing practice, reviewed when its criticality changes.

This scope is defensible to management because it is bounded, and it is technically sound because it concentrates rigour where the loss occurs. It also has a practical political advantage: results arrive quickly enough to be used, which builds support for extending the work. Programmes that attempt to analyse everything produce their first usable output after a year, by which time sponsorship has usually moved elsewhere.

The cyclic review is what sustains it. Each year, the failure history is examined against the criticality ranking: were the assets that failed the ones ranked as critical? If a low-ranked asset keeps causing problems, either the ranking was wrong or the asset has changed. Either way the ranking is updated, and the study remains a living tool rather than an archived document.

Related practice for Indonesian operators is set out in ISO 55001 practice and data quality controls.

Key Takeaways

• Criticality analysis allocates attention across the asset base; FMECA designs maintenance for a specific asset — they are sequential, not interchangeable.
• Apply FMECA only to assets that criticality identifies as consequential, typically 5 to 15 percent of the asset base.
• Keep consequence and likelihood separate, because they drive different maintenance responses and combining them destroys the information.
• Every FMECA failure mode must end in a decision: a task with an interval, a redesign, a run-to-failure justification, or a proof test.
• Record why tasks were not created — that reasoning prevents gradual drift back toward over-maintenance.
• Route output into the maintenance system, the monitoring programme, and the spares and capital processes, or the study produces only a document.

Frequently Asked Questions

What is the difference between criticality analysis and FMECA?

Criticality analysis ranks assets by how much their failure matters to the business, working top-down across the whole asset base. FMECA works bottom-up on one specific asset, asking what could fail, what happens, how it is detected, and what should be done. Criticality decides which assets deserve an FMECA; the FMECA decides the maintenance for each failure mode.

Should FMECA be applied to every asset?

No. Applying design-level analysis to assets whose failure does not matter wastes months and delays useful output past the point where decisions were needed. The defensible scope is 5 to 15 percent of the asset base, selected by criticality, with a handful of machines warranting a full RCM workshop.

Why should consequence and likelihood not be combined into one score?

Because they drive different responses. A high-consequence, low-likelihood failure justifies protective measures and spares; a high-likelihood, low-consequence failure justifies preventive tasks and redesign. Combining them into one number erases the distinction, and the resulting ranking no longer tells anyone what to do.

How do we keep an FMECA from taking months?

Fix the boundary at the start, work from actual failure history rather than brainstorming every conceivable mode, and force a decision on each mode as it is raised. A study that considers only plausible and consequential failure modes and ends each in a defined outcome completes in weeks rather than quarters.

What is the most common reason these studies produce no benefit?

The output is never connected to anything. Tasks identified do not become work order templates, monitoring requirements do not enter the monitoring programme, and spares findings never reach the spares budget. A study whose output stays in a document has changed nothing regardless of its technical quality.

How often should criticality be reviewed?

Annually, against the year’s failure history. Compare the assets that actually caused losses with the assets ranked as critical. Persistent problems on low-ranked assets indicate either a ranking error or a change in the asset’s role, and either way the ranking needs updating to remain useful.

To discuss criticality assessment or FMECA for your asset base, contact Tiaravib at info@tiaravib.com or WhatsApp +62 821-1378-3727.

FMECA and criticality work is best judged by what changes in the maintenance programme rather than by the quality of the document. Tiaravib has supported Indonesian asset-intensive operations since 1995 across criticality assessment, condition monitoring programme design, and reliability engineering, and the consistent lesson is that scope discipline determines whether the study is used. Relevant references include ISO 55001 for asset management system context, ISO 17359 for condition monitoring programme structure, and SMRP material on maintenance strategy practice.