Bad Actor Analysis for Asset Reliability Management
Direct answer (AEO): Bad actor analysis is a repeatable method for interrogating maintenance and production data to identify the small number of assets responsible for a disproportionate share of downtime, lost production, or maintenance cost — then eliminating the root causes so those assets stop recurring. Within asset reliability management it is the highest-yield diagnostic step available, because it works on evidence the organisation already owns. Most plants find that a small minority of tags generates the majority of unplanned events; bad actor analysis finds those tags, ranks them by impact rather than by complaint, and converts each one into a documented defect elimination project instead of another reactive repair.
Need bad actor analysis support in Indonesia? Contact Tiaravib — email info@tiaravib.com or WhatsApp +62 821-1378-3727.
At a Glance
- What it is: a data-driven ranking of assets by their contribution to downtime, production loss, or cost, followed by structured root cause elimination on the worst offenders.
- Core premise: failure is not evenly distributed. A small fraction of equipment accounts for the majority of unplanned events in almost every plant.
- Primary data needed: work order history with failure codes, downtime records, production loss figures, and repair cost — all from the existing CMMS where possible.
- Key output: a prioritised bad actor register with quantified impact, an assigned root cause owner, and a corrective action with a completion date.
- Difference from criticality: criticality asks how bad a failure would be; bad actor analysis asks which failures are actually happening and draining value now.
Why a Small Number of Assets Cause Most of the Trouble
Reliability data has a stubborn shape. When you plot unplanned events, downtime hours, or repair cost against assets, the distribution is not flat and not normal — it is heavily skewed. A handful of tags sit far to the right of the curve and account for a share of the total problem that is far out of proportion to their number. This is the same pattern that appears in safety incidents, insurance claims, and defect counts, and it is the entire justification for bad actor analysis.
The practical consequence is enormous. A plant that treats every failure as an independent event spreads its improvement effort evenly across hundreds of assets and moves the overall reliability needle slowly, if at all. A plant that accepts the skew and concentrates effort on the dozen or two dozen worst performers can retire a large share of its downtime with a small number of well-chosen projects.
There is a cultural obstacle, and it is worth naming. Bad actor analysis is a formal, evidence-based challenge to the way the plant has been working. It usually reveals that the same equipment has been failing the same way for years, that each failure was closed as a separate work order, and that nobody ever asked why it kept happening. That is not a comfortable finding, which is precisely why the method must be anchored to data rather than to opinion — the data cannot be argued with, and it cannot be dismissed as a consultant’s theory.
Bad actor analysis also complements equipment criticality ranking rather than duplicating it. Criticality is prospective: it asks what would happen if an asset failed. Bad actor analysis is retrospective: it asks what is already happening. A plant needs both. Criticality tells you where to place monitoring and spares; bad actor analysis tells you where to send the defect elimination team first, and the two lists are frequently and usefully different.
The Data Foundations of a Defensible Bad Actor Analysis
The quality of the output is capped by the quality of the input. Before any ranking is produced, four data sets must be assembled and sanity-checked.
Work order history. Every corrective work order against a tag, with its failure code, repair description, and completion date. The failure coding is where most plants are weakest: free-text descriptions that say “repaired pump” tell an analyst nothing about mechanism, and codes applied by whoever closed the order fastest produce a ranking that reflects coding behaviour rather than equipment behaviour.
Downtime and production impact. Work order counts alone are misleading. A pump that fails monthly but is swapped in twenty minutes with a standby is not a bad actor in the way a compressor that fails once a year and costs three days of production is. Cost of unreliability — not event count — is usually the right ranking currency, and it must be sourced from production or finance rather than estimated by the maintenance department.
Repair and replacement cost. Parts, labour, and any contracted services consumed per event. This is readily available in most CMMS installations and is useful for ranking equipment whose failures do not stop production but steadily consume budget.
Operating context. Throughput, duty, service conditions, and any recent process changes. Two identical pumps in different services are not comparable, and a ranking that ignores duty will recommend redesign when the real fix is a suction strainer.
Where the CMMS data is too poor to support ranking — a common situation in Indonesian plants with long service lives and informal history — the analysis can begin with a short data rehabilitation phase: re-code the last two to three years of corrective work against a standard failure taxonomy, reconcile downtime figures with production records, and only then rank. This costs time but converts the entire subsequent program from an opinion exercise into an evidence exercise.
The Bad Actor Analysis Method, Step by Step
1. Define the impact metric and the analysis window
Choose the currency of the ranking and state it explicitly — cost of unreliability, unplanned downtime hours, lost production volume, or a weighted composite. Then define the look-back period. Three years is typical: long enough to capture low-frequency high-consequence events, short enough that equipment modifications and process changes do not distort the comparison.
2. Rank every asset on the single chosen metric
Produce the ranking on one metric first, not a blended score. A single clear metric is defensible in a management meeting and can be interrogated. Blended scores invite arguments about weighting that consume the meeting without improving the list. The familiar shape will appear — a short head accounting for a large share of the total — and that head is your candidate list.
3. Filter for genuine bad actors
Applying a Pareto cut alone is not sufficient. Each candidate must be screened against the following tests before it earns a place on the register.
- Repeatability:</strong yes, bad actors repeat. A one-off catastrophic event is a serious finding but is not a bad actor in the analytical sense, because there is no recurrence to eliminate.
- Controllability: is the failure mechanism within the plant’s control, or is it genuine exogenous wear-out of an asset already scheduled for replacement? Both can be acted on, but the actions are different.
- Data integrity: can the failures be verified against physical evidence, or is the tag simply used as a catch-all for work that belonged elsewhere?
- Perspective: has the asset been the subject of a previous bad actor project that failed to deliver? If so, the previous root cause was wrong, and that is itself a high-priority finding.
4. Perform a formal root cause analysis on each confirmed bad actor
This is where the value is created, and where programs most often stop short. Ranking without root cause analysis merely produces a more educated version of the existing complaint list. Each confirmed bad actor needs a structured investigation — causal factor charting, fault tree analysis, or a five-why chain disciplined by physical evidence — that terminates in a mechanism, not a component. “Bearing failed” is a symptom. “Water ingress through a failed lip seal caused lubricant degradation and accelerated raceway spalling” is a mechanism, and only a mechanism tells you what to change.
5. Convert findings into owned corrective actions
Every root cause must generate a specific corrective action with a named owner, a due date, and a defined verification method. Actions that change design, operating procedure, or maintenance strategy are usually more durable than actions that change inspection frequency, because inspection only detects the problem sooner; it does not prevent it.
6. Verify the outcome, then close the loop
A bad actor is not closed when the work order is signed off. It is closed when the asset has run a defined period — typically twelve months or a full operating cycle — without recurrence, and the result is recorded so the plant can demonstrate the value of the program. Assets that recur after a completed project return to the register with the escalation that implies.
Ranking Currencies: Choosing the Right Impact Metric
| Impact metric | When to use it | Strength | Principal weakness |
|---|---|---|---|
| Unplanned downtime hours | Plant is throughput-constrained and shutdown time is the binding constraint | Objective, easy to extract from production records | Ignores severity; a short high-consequence trip scores the same as a long nuisance shutdown |
| Cost of unreliability | Management needs a financial business case for the improvement program | Speaks the language of capital allocation; aggregates different failure types fairly | Sensitive to the production cost per hour assumption, which should be validated by finance |
| Lost production volume | Product value varies widely or the plant produces multiple grades | Captures commercial impact directly | Requires accurate production allocation data by unit and by time window |
| Maintenance cost | Reliability budget is the constraint, or failures consume spares without stopping output | Available in the CMMS immediately, no production data required | Favours cheap, frequent repairs over rare expensive ones and misses consequence entirely |
| Event frequency | Early screening when no cost data exists yet | Fastest to produce; useful for a first pass | Actively misleading on its own — high-frequency low-impact events crowd out the true bad actors |
A defensible program usually runs the ranking on cost of unreliability as the primary metric, with downtime hours and event frequency as secondary views used to interrogate the primary list rather than to build a competing one.
Bad Actor Analysis Versus Other Reliability Methods
The method is often confused with adjacent techniques, and the distinctions matter because each answers a different question and produces a different action.
Versus criticality ranking. Criticality is consequence-based and forward-looking; it does not require any failure to have occurred. Bad actor analysis is occurrence-based and backward-looking; it requires history. An asset can be criticality band A and never have failed, in which case it belongs on the monitoring program but not on the bad actor register.
Versus root cause analysis. Root cause analysis is the tool applied to one event or one asset. Bad actor analysis is the portfolio-level process that decides which events and assets deserve that tool. Running root cause analysis without bad actor analysis means performing expensive investigations on whichever failure happened to annoy management most recently.
Versus reliability-centred maintenance. RCM designs a maintenance strategy from failure modes and consequences, ideally before failures accumulate. Bad actor analysis targets the equipment where the existing strategy has already visibly failed. In practice they feed each other: the root causes found by bad actor analysis frequently expose where the RCM logic or the PM scope is wrong.
What a Tiaravib Bad Actor Analysis Engagement Delivers
Tiaravib has supported reliability improvement at Indonesian process, power, and manufacturing sites since 1995, and bad actor analysis is frequently the point at which a reliability program starts producing visible, measurable results — because it is the first activity that removes failures permanently rather than monitoring them more closely.
We begin by extracting and cleaning the work order history, then re-coding it against a consistent failure taxonomy where the existing coding will not support analysis. We agree the impact metric with the client and with finance, so the ranking is expressed in a currency management already accepts. We produce the ranked register with the Pareto structure made explicit, screen the candidates against the repeatability and controllability tests, and then facilitate root cause analysis with the cross-functional team that owns the equipment — including operations, whose process knowledge is usually decisive on questions of duty and service condition.
Every investigation terminates in a corrective action with an owner, a date, and a verification period. The register is handed over live and revision-controlled, so the client’s own reliability engineer can run the next cycle without us. The output connects directly to asset aging management follow-through work such as criticality re-ranking, PM scope revision, spare parts strategy adjustment, and design modification where the root cause proves to be a specification error rather than a maintenance one.
ISO 14224 defines the reliability and maintenance data collection format that makes a repeat-failure analysis statistically meaningful, and is the recommended basis for bad actor records.
Once a bad actor is identified, its spare part holding decision usually changes, which is where a reliability centred spare part strategy connects to the analysis.
Bad actors also tend to be the assets where condition based monitoring earns its cost fastest, because the failure mode is already known and repeatable.
Key Takeaways
- Failure is heavily skewed. A small minority of assets generates most unplanned downtime, and bad actor analysis exists to find them deliberately rather than by accident.
- Rank on impact, not on event count. Cost of unreliability or downtime hours produces a usable list; frequency alone actively misleads.
- Screen the Pareto head. Repeatability, controllability, data integrity, and prior failed projects all filter the candidate list before any investigation begins.
- The deliverable is a mechanism, not a component. Root cause analysis that concludes “bearing failed” has not started; it needs to reach water ingress, misalignment, or a specification error.
- Owned actions with verification close the loop. A bad actor is retired only after a defined recurrence-free period, and that verification is what proves the program’s value.
- Data quality sets the ceiling. Re-coding two to three years of history against a standard taxonomy is often the highest-return preparation step in the entire program.
Frequently Asked Questions
How do we identify bad actors when our maintenance data is unreliable?
Start with a bounded data rehabilitation phase rather than abandoning the analysis. Extract the corrective work history for the last two to three years, re-code it against a consistent failure taxonomy, and reconcile downtime figures against production records. Even imperfect history usually contains a clear signal once it is coded consistently, because the skew in the distribution is strong enough to survive moderate noise. Where specific tags remain ambiguous, resolve them through physical inspection and operator interviews, and mark the resulting scores as provisional so the uncertainty is visible to everyone who uses the register.
How many bad actors should a typical plant expect to find?
The count follows from the Pareto structure rather than from a target. In most plants the top 5 to 10 percent of tags accounts for a substantial majority of unplanned downtime and cost, so a register of one or two dozen assets is common for a single-site facility of moderate size. The important discipline is not the number but the cut: set the threshold from the impact curve, not from how many projects the team feels able to run. Managing ten verified projects to completion delivers far more than opening forty and finishing none.
What is the difference between a bad actor and a critical asset?
A critical asset is one whose failure would have severe consequences, whether or not it has ever failed; a bad actor is one that is actually failing repeatedly and demonstrably consuming value. The two categories overlap but are not the same. A critical asset with an excellent reliability record belongs on a monitoring and spares program but not on the bad actor register. A low-criticality asset that fails weekly and consumes maintenance hours may well be a bad actor, because the aggregate cost, even without production impact, justifies eliminating the cause.
How long should a bad actor project take from analysis to closure?
The ranking and root cause analysis can usually be completed within one to two months for a focused register, with the investigation workshops concentrated in a few days. The corrective actions then run on their own timelines, which may be days for a procedure change or many months for a design modification or a spare part re-specification. Closure depends on verification, so a project is not finished until the asset has run a defined recurrence-free period, typically twelve months or one full operating cycle for the equipment type.
Does bad actor analysis replace our preventive maintenance program?
No, and treating it as a replacement is a common and expensive mistake. Bad actor analysis is a corrective, targeted activity that eliminates the causes of visible recurring failures. A preventive and predictive maintenance program is what prevents failures from establishing themselves in the first place. Plants need both, and the healthy long-term state is one in which the bad actor register stays short and stable because the programme has eliminated the underlying defects rather than continuing to catch new ones.
How do we keep the bad actor register alive after the first cycle?
Give the register a named owner, a fixed review cadence, and an automatic entry rule. The review should run quarterly at minimum, with new entries added automatically from the work order system whenever an asset crosses the agreed impact threshold, and with recurrence by a previously closed bad actor triggering escalation rather than a fresh investigation. The register should also be a standing agenda item in the reliability meeting, so that the corrective actions are tracked with the same visibility as production and safety actions rather than being allowed to drift.
External references: ISO 14224 reliability data collection and the U.S. Department of Energy.
For a site assessment or pilot proposal, contact Tiaravib via WhatsApp +62 821-1378-3727 or info@tiaravib.com.
