RCM and FMEA Software Problems: The 7 That Cost Real Money and How to Avoid Them

Why does the analysis without write-back scope failure happen so often?

Reliability projects get scoped around the part everyone finds interesting. Failure mode libraries, criticality matrices, task selection logic and Weibull fitting are genuinely satisfying engineering work, and a demonstration of them looks impressive to a steering committee. Writing a maintenance plan into SAP PM does not look impressive to anybody, so it becomes phase two, and phase two does not get funded because phase one produced no measurable change.

The economics make this worse than it sounds. The value of a strategy layer is entirely in what it changes at the plant: tasks removed, intervals corrected, new tasks created against failure modes nobody was addressing. None of that happens while the output is a spreadsheet. Meanwhile the tasks that already exist keep running, and a third of them typically came from an original equipment manufacturer manual written to protect a warranty and sell parts, with no knowledge of your duty cycle, your ambient conditions or the fact that a gearbox has run at reduced load since a debottlenecking years ago.

The fix is to make write-back part of the first release and to scope everything else around it. Take one area, one plant and the equipment classes carrying the most unplanned downtime, and prove the loop end to end: failure mode to task to approved interval to a maintenance plan a planner can see. A narrow loop that closes beats a broad analysis that does not, and it is the version that gets a second round of funding.

What goes wrong when the asset hierarchy and failure history are migrated?

Two data problems sink these projects, and both are visible before anyone writes code.

The first is the functional location hierarchy. In most plants that have been through acquisitions or expansions, the same crusher appears more than once under different codes, decommissioned equipment is still present, and naming conventions changed twice. A strategy layer sitting on top of that hierarchy inherits every duplicate, so a template applied to a hundred instances is really applied to eighty seven real assets and thirteen ghosts. Software cannot fix this, and no amount of clever matching substitutes for a reliability engineer deciding which record is real.

The second is failure history. The evidence you want lives as free text in notification long descriptions and work order completion notes, written by different technicians across years, where a bearing failure appears as noisy DE brg, bearing knocking and NDE bearing collapsed. Nobody has time to read tens of thousands of those, so the intervals in your current strategy are based on engineering judgement rather than on what actually happened.

The fix is to sequence it correctly. Clean the hierarchy first, with anybody, before choosing tooling, because a strategy built on a broken hierarchy is worse than none: it looks governed and is not. For history, classify notification text against your failure mode library with a language model, then put every mapping through a review queue where a reliability engineer confirms or corrects. Expect the model to be confidently wrong on a portion of records, budget the review time, and let the corrections improve the mapping.

Why does CMMS write-back break after launch?

Getting the first batch of tasks into the maintenance system is the milestone everyone celebrates. The failures arrive afterwards.

In SAP PM the objects are specific: general task lists, maintenance items, maintenance plans, strategies and packages, each with master data rules your organisation has customised over years. A write path that works against a clean development client meets production data with mandatory fields nobody mentioned, work centres that no longer exist, and a transport path through your landscape that is not the developer's to control. In Maximo it is job plans, PM records and route stops, with the same class of surprises.

Three specific failure patterns recur. Partial batch failures, where eight hundred rows are submitted and forty fail validation, leaving the strategy and the maintenance system in states that disagree and nobody sure which. Silent overwrite, where a write-back replaces a maintenance plan that a planner had adjusted locally for a genuine reason, and the planner loses trust permanently. And version drift after an upgrade, where a field length or a mandatory flag changes and the nightly job starts failing at a time nobody watches.

The fix is to design the write-back as a transactional, reviewable process rather than a data push. Changes queue as a proposed set that a planner approves, failures land in a queue with the specific validation message rather than a generic error, and every write is reversible. Ask the developer what happens on a validation failure halfway through a batch before you sign, because the answer tells you whether they have done this.

What happens when your risk framework and change control are not covered?

Two gaps turn a working system into shelfware within a year.

The first is criticality. Your business already owns a decision framework, usually a risk matrix with your own consequence categories for safety, environment, production loss per hour and regulatory exposure, signed off by a committee. Generic criticality wizards produce an answer that committee will not accept, so engineers override the scores manually and the overrides are not recorded. Within two quarters the criticality in the system and the criticality the business uses are different numbers. Encode your own matrix, including the thresholds and the escalation rules, and record who scored what and when.

The second is management of change. Somebody will always edit a maintenance plan directly in SAP under pressure during a shutdown. That is not a problem and it will keep happening. The problem is nobody knowing. Without a drift report comparing the approved strategy against what the maintenance system actually holds, the two diverge quietly and the strategy register becomes historical fiction, which is exactly how the last study became unfindable.

There is a third gap worth naming for regulated sites. If you intend to hold protective device and safety instrumented function testing intervals in the same system, that work falls under IEC 61511 and is a specialist workstream with its own competency requirements. Price it separately or keep it out. Building it approximately alongside general maintenance strategy is the wrong compromise.

Should you build custom or configure what you already own?

Plenty of operators should not build. With a single site, a few hundred maintainable assets and one reliability engineer, Hexagon Reliasoft or Isograph Availability Workbench plus disciplined spreadsheet governance is genuinely enough, and a custom build is an expensive way to reach the same decisions. Reliasoft remains the strongest option available for formal failure mode and effect worksheets under IEC 60812 and for Weibull life data analysis, and Isograph does availability simulation properly when the question is production availability across a train of equipment.

ARMS Reliability OnePM is built around exactly the idea of a living strategy library with reuse across similar assets, and if your asset base is genuinely templated it will take you a long way. GE Vernova APM is the broadest option and the heaviest to own. If you are early in the maturity curve and your functional locations are not clean, buy nothing yet and fix the master data first.

Build when two or more of these hold. You carry more than roughly three thousand maintainable assets, especially across sites, so template reuse is worth real money. Write-back is manual and therefore not happening. Your criticality framework is your own and no product accepts it without compromise. You need failure mode evidence extracted from years of work order history rather than from engineering judgement. Or your maintenance budget is under a cut and you need a defensible argument line by line rather than a percentage across the board.

How do hidden costs get into the quote?

The estimate moves in a small number of well known places.

• SAP PM write-back. The single largest driver, because your maintenance plan and task list master data has been customised and the testing and transport path through your landscape is not the developer's to control.
• Multiple maintenance systems. Acquisitions leave different instances with different functional location conventions, and each is its own integration with its own master data rules.
• Hierarchy cleanup. If duplicates and decommissioned equipment have to be resolved before templates mean anything, that is reliability engineer time and it belongs in the plan.
• History classification review. The model does the volume, engineers confirm the mappings, and that confirmation time is real and recurring during the first pass.
• Safety instrumented function scope. Testing intervals under IEC 61511 are a specialist workstream and should be priced as one rather than absorbed.
• Template governance. Propagating a template change to hundreds of instances that carry local overrides is genuine design work, not a bulk update.

What separates a build that works from one that fails here?

The builds that work make the chain explicit and mandatory: asset, function, functional failure, failure mode, effect, consequence category, task, interval, and the engineer who approved it with a date. Every task in the maintenance system gets a parent, and tasks that cannot find one are flagged as deletion candidates with a written justification attached, which is what lets the recommendation survive contact with the safety department. They also version every analysis and require a change record to alter an approved task.

The builds that fail draw assets and tasks with a line between them. That is a task manager, and it will not answer the only question the reliability manager actually has, which is what a given preventive task prevents. They also tend to treat criticality as a wizard output rather than as your own risk matrix, so the scores get overridden informally and stop meaning anything.

Three tests before signing. Ask them to draw the data model on a whiteboard, and check that function, functional failure and failure mode appear as distinct objects rather than as attributes. Ask exactly how they will write back, naming the object in your system, and what happens when forty rows in a batch of eight hundred fail validation. Ask how a template change propagates to instances that carry local overrides, and what the engineer sees when it conflicts. Then settle ownership of the code, repository and cloud accounts before kickoff, because in a discipline whose purpose is removing single points of failure, accepting a developer who holds your repository is an obvious contradiction.