RCM and FMEA Software: Why Nobody Can Trace What Your PM Tasks Actually Prevent

Why maintenance strategy is the one thing your CMMS cannot give you

A reliability manager at a copper concentrator filters preventive tasks for the mill area and gets back four thousand of them. Roughly a third came from the OEM manuals when the plant was commissioned. Another third were added after incidents, each one a reasonable reaction by a superintendent who is no longer here. The rest nobody can account for at all. He has been asked to take twelve percent out of the maintenance budget and he cannot answer the only question that matters: which of these four thousand tasks is preventing a specific failure, and which is labour and a bag of grease.

That is the gap. SAP PM, Maximo, Ellipse and Infor EAM are execution systems. They are excellent at recording that task 30044 was completed on Tuesday by two fitters in 3.5 hours. Not one of them has a field for why task 30044 exists. There is no link from a task to the failure mode it addresses, no link from that failure mode to the function it protects, and no record of who set the interval or on what evidence. Strategy is the missing layer, and in most plants it survives as a folder of workshop spreadsheets from a consulting engagement four years ago.

What that costs, from our work with asset intensive operators: reliability engineers spend weeks per area rebuilding analysis that was already done and then lost, PM compliance gets reported in the high nineties while the same equipment keeps failing the same way, and every budget cycle becomes an argument with no evidence on either side. When the engineer who ran the last study leaves, the reasoning leaves and the task list stays. That is how a pump ends up with a monthly greasing route when its real failure mode is a mechanical seal nobody inspects.

Problem 1: the task list is inherited, and inheritance is not a decision

An OEM writes a maintenance manual to protect itself during the warranty period and to sell parts. It does not know your duty cycle, your ore hardness, your ambient temperature, or that this gearbox runs at sixty percent load because the circuit was debottlenecked in 2016. The manual says quarterly. Quarterly went into the CMMS as a maintenance plan and it has been running for nine years.

SAE JA1011 sets out the seven questions a process has to answer before it can be called reliability centred maintenance, and the honest position at most plants is that the current task list has never been through any of them. Nobody has written down the function, the functional failure, the failure mode, or the effect. The task exists because it was typed in.

What a custom build does: it makes the chain explicit and mandatory. Asset, function, functional failure, failure mode, effect, consequence category, task, interval, and the name of the engineer who approved it with a date. Every task in the CMMS gets a parent. Tasks that cannot find a parent are flagged as candidates for deletion, and that report is usually the fastest money the system ever returns. In our experience the first pass across a large area typically removes or re-intervals a meaningful slice of the task population, and every removal has a written justification attached to it, which is what makes it survive contact with the safety department.

Problem 2: what the specialist tools do well, and where they stop

Be fair to the incumbents, because they are good software. ARMS Reliability OnePM is built around exactly this idea of a living strategy library with reuse across similar assets, and if your asset base is genuinely templated it will get you a long way. Hexagon Reliasoft is the strongest thing available for Weibull life data analysis and formal RCM and FMEA worksheets under IEC 60812. Isograph Availability Workbench does RAM simulation properly, so if the question is production availability of a train of equipment it is the right tool. GE Vernova APM is the broadest of the four and the heaviest to own.

Where all of them stop is the same place: the return trip. An RCM study is worthless until the approved task shows up in front of a planner as a maintenance item on a maintenance plan, with the right task list, the right work centre, the right materials, and the right cycle. In SAP PM that means general task lists, maintenance items, maintenance plans and strategies, each with its own master data rules that your organisation has customised. In Maximo it means job plans, PM records and route stops. The specialist tools export a spreadsheet. Somebody then keys it in, and because keying in four thousand rows is intolerable, the study sits in the folder and nothing changes on the floor.

The second thing they stop short of is your asset hierarchy. Criticality is not a number, it is a decision framework your business already owns, usually a risk matrix with your own consequence categories for safety, environment, production loss per hour and regulatory exposure. Every plant has customised it. Generic criticality wizards give you an answer your risk committee will not accept.

Problem 3: the analysis has no feedback loop

Here is the test. Take a failure mode you wrote a task for two years ago. Can you show, without opening a spreadsheet, how many times that failure mode has occurred since, on that asset class, across all sites? At almost every plant the answer is no, because the evidence lives as free text in notification long descriptions and technician comments, and nobody has time to read forty thousand of them.

This is where a language model earns its place, and it is the only place in this category we would put one. Historical notifications and work order completion notes get classified against your failure mode library, so a bearing failure written up as noisy DE brg, bearing knocking and NDE bearing collapsed all land on the same mode. Once that mapping exists you can fit distributions to real intervals rather than assumed ones, and the strategy stops being an opinion. Expect the model to be confidently wrong on a portion of records, so the build has to include a review queue where a reliability engineer confirms or corrects, and the corrections train the mapping. We would not ship this without the human confirmation step.

Problem 4: strategy drifts, and the redo costs as much as the original

Plants re-run RCM every five years or so, usually from scratch, usually with consultants, usually because the last set of outputs became unfindable. That is the single largest avoidable cost in this whole area. Strategy is not a project deliverable, it is a register that needs an owner and a change process, the same way a P and ID does.

What a custom build does: version every analysis, require a management of change record to alter an approved task, and expose a drift report showing where the CMMS no longer matches the approved strategy. Somebody will always change a maintenance plan directly in SAP under pressure during a shutdown. That is fine and it will keep happening. What is not fine is nobody knowing. The drift report turns a silent divergence into a weekly agenda item.

What this costs and how long it takes

Across the projects Digital Heroes has delivered, the honest shape is this. A first release covering the failure mode library, your criticality framework, task selection and interval logic, and validated write-back to one CMMS runs $70,000 to $150,000 in 12 to 18 weeks. That is a system your reliability team uses on day one against a real area, not a pilot. Adding notification text classification, Weibull fitting on real history, RAM modelling, spares and BOM linkage, multi-site template governance and a drift and compliance dashboard takes the programme to $180,000 to $450,000 over 8 to 14 months.

What pushes cost up in this category specifically: SAP PM write-back is the big one, because your maintenance plan and task list master data has been customised and the transport and testing path through your SAP landscape is not ours to control. Multiple CMMS instances after acquisitions, each with a different functional location convention, is the second. Formal safety instrumented function work under IEC 61511, if you want protective device testing intervals in the same system, is a specialist workstream and should be priced as one. What keeps cost down: pick one area, one plant, and the equipment classes that carry the most unplanned downtime, and prove the loop end to end before you scale the library.

Build versus buy, honestly

Buy if you have a single site, a few hundred maintainable assets, and one reliability engineer. Reliasoft or Isograph plus disciplined spreadsheet governance is genuinely enough, and a custom build would be an expensive way to make the same decisions. Buy also if you are early in the maturity curve and do not yet have clean functional locations, because software cannot fix a hierarchy where the same crusher appears three times under different codes. Fix the master data first, with anybody, then talk about tooling.

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

How to choose a developer for reliability strategy software

Ask them to draw the data model on a whiteboard before you sign. You want to see asset class, functional location, function, functional failure, failure mode, task, interval and approval as distinct objects with the relationships drawn. A developer who draws assets and tasks with a line between them has built a task manager and is about to learn maintenance strategy on your budget.

Ask exactly how they will write back. The answer should name the object: general task list, maintenance item, maintenance plan, strategy and packages in SAP PM, or job plan and PM record in Maximo. If the answer is we will use the API, ask which one and what happens on a validation failure halfway through a batch of eight hundred.

Ask what they will do about templating. Reuse across similar assets is the entire economic case for this software, so ask how a template change propagates to two hundred instances that have local overrides, and what the engineer sees when it conflicts.

Ask who owns the code, the repository and the cloud accounts, and get it in the contract before kickoff. At Digital Heroes the client owns everything from the first commit and can hire anyone else to continue the work. Any developer who hedges on that is building a dependency rather than a system, and in a discipline where the whole point is removing single points of failure, that should end the conversation.