AI CMMS, EAM, APM and Predictive Maintenance: An Honest Taxonomy

If you have been asked to evaluate maintenance software in the last two years, you have run into a vocabulary problem. A vendor calls their product an AI CMMS. Another calls the same feature set asset performance management. A third says predictive maintenance and means a vibration sensor. A fourth says predictive maintenance and means a language model that summarises work order history. Your finance director says EAM because that is the line item in the capital plan.

The words are not interchangeable, and the differences are not marketing. They describe different jobs, different data, different failure modes and different reasons to say no. This page is an attempt to define them plainly, be fair about what each category is genuinely good at, and say where each one stops.

Nothing here is a ranking. There is no category that wins. Most utilities that run well are running several of these at once, deliberately.

Why the vocabulary drifted

Two things happened at the same time.

First, the categories converged in the market. Vendors that started with work orders added condition data. Vendors that started with condition data added work orders. A product that was clearly a CMMS in 2015 now ships planning aids, mobile workflows and analytics, and calls itself a platform. That convergence is real and mostly good for buyers.

Second, “AI” arrived as a modifier that attaches to anything. It is applied to search, to scheduling, to forecasting and to text generation, all inside the same product page. The modifier survives the convergence and hides it.

The result is that two products described identically can differ in the most important respect: what they are authoritative over, and what they will not decide. That is the distinction worth recovering.

CMMS: the system of record for work

A computerized maintenance management system holds the asset register, the work orders, the preventive maintenance schedules, the labour records and the parts consumed. It answers questions about what exists, what was done, by whom, when, at what cost, and what is due next.

That is the job, and a good CMMS does it well. It is worth being direct about this because the category takes an unfair beating in current marketing. A CMMS is a system of record. Being a system of record means being conservative, being auditable, being slow to change state, and requiring a human to assert that something happened. Those are correct design properties for a database that a regulator, a rate case, an insurer or a lawyer may eventually read. A system that cheerfully rewrote its own history to be more helpful would be worse at its actual job.

The CMMS is also where your institutional discipline lives. A well configured asset hierarchy, sensible failure codes, and PM schedules that reflect how your plant actually runs are worth more than most software you could buy on top of them. Utilities that have done this work have a real asset, and it should not be discarded to chase a new interface.

Where a CMMS stops: it records the outcome of coordination, not the coordination. A work order tells you that work exists, its priority, its assignee and its asset. It does not gather the evidence, confirm the part on the shelf matches the part on the asset, chase the supplier, or route the approval. Those things happen in phone calls, inboxes and hallways, and the CMMS receives the summary afterward.

EAM: the same discipline over a longer horizon

Enterprise asset management is often described as a bigger CMMS, and the difference really is closer to scope than to kind. Gartner’s IT glossary defines enterprise asset management as asset register, work order management, inventory and procurement functions in an integrated business software package, which is a fair description of the overlap. The distinction in practice is horizon and audience.

A CMMS is oriented to the maintenance department and the current work week. An EAM is oriented to the organisation and the asset life cycle: acquisition, condition, renewal, disposal, capital planning, depreciation and the financial reporting that follows from all of it. ISO 55000:2024 sets the vocabulary and principles for this field, and defines asset management as the coordinated activity of an organisation to realise value from assets, which is a different unit of analysis than a work order.

For a US municipal utility, the reporting requirement is usually concrete. GASB Statement No. 34, issued in June 1999, changed government financial reporting to include infrastructure assets, and offered the modified approach as an alternative to depreciation. Under the modified approach, a government must perform condition assessments of eligible infrastructure assets at least every three years, document them in a way that can be replicated, and make an annual estimate of the amount needed to maintain and preserve those assets at the condition level it has established and disclosed (Federal Highway Administration primer on GASB 34, November 2000). If your organisation uses that approach, the condition data and the maintenance record are not a convenience. They are the evidence behind the financial statement.

Where an EAM stops: the same place, one level up. It is authoritative about what you own, what condition it is in, what it cost and what it will cost. It is not the thing that gets a failed pump back in service on a Tuesday.

APM: condition, risk and criticality

Asset performance management sits between the record and the physics. Gartner’s market definition frames APM as the capabilities of data capture, integration, visualisation and analytics tied together for the explicit purpose of improving the reliability and availability of physical assets.

In practice an APM tool is where you decide which assets matter most, what their risk profile is, what condition they are in now, and where limited money should go. It is the natural home for criticality ranking, risk based inspection intervals, remaining useful life estimates and reliability analysis.

APM is the category most likely to change what a maintenance organisation does, because it changes what gets prioritised. It is also the category most dependent on data quality you may not have. Criticality models are only as good as the asset hierarchy underneath them, and remaining life estimates are only as good as the failure history you have recorded. This is a case where the incumbent system of record determines the ceiling on the analytics.

Where APM stops: it tells you what to worry about and roughly when. It does not run the repair.

Predictive maintenance and condition monitoring: a different problem entirely

Condition monitoring is measurement. Vibration analysis, infrared thermography, oil and wear debris analysis, motor current signature analysis, ultrasound, plus process parameters like flow, pressure and power draw. ISO 17359:2018 gives the general procedure to consider when setting up a condition monitoring programme, names the parameter families typically used, including vibration, temperature, tribology, flow rate, contamination, power and speed, and covers detecting the symptoms of root cause failure modes and setting alert and alarm criteria. It is a mature discipline with decades of practice and its own standards behind it.

Predictive maintenance is what you do with that measurement: estimate that a failure is coming, and intervene before it arrives. Machine learning has changed how parts of this are done. A model trained on historian data is aimed at pattern changes that a fixed threshold does not register until later, and at combinations of variables that no single alarm limit is watching. Whether a particular model achieves that on your plant is a question for your own data and your own trial, not for a vendor’s claim.

Here is the precision that matters for a buyer. Prediction and coordination are different problems with different success criteria.

A prediction problem is judged on whether the warning was right and early enough to act on. It fails through false positives, missed detections and lead times too short to be useful. Its inputs are sensor and process data. Its output is a belief about the future.

A coordination problem is judged on whether the work actually got done, correctly and with a defensible record. It fails through a part that was not on the shelf, a quote that sat in an inbox, an approval nobody chased, a permit that expired, a closeout with no photos. Its inputs are people, parts, suppliers, policies and records. Its output is a completed repair.

A perfect prediction that arrives on a Friday afternoon and needs a part with a fourteen week lead time has not saved you anything by itself. That is not an argument against prediction. It is an argument that solving one problem does not solve the other, and that buying the first while assuming you bought the second is a common and expensive mistake.

“AI CMMS”: what vendors currently mean

This is the term people actually search for, and it is the least stable term in the list. Used honestly, it means a CMMS that has added machine learning or language model features. The trouble is that it currently names at least three genuinely different capabilities, and product pages rarely say which one is in the box.

Natural language search and summarisation over existing records. Ask “what have we done to Pump 3 in the last two years” and get an answer assembled from work order history, instead of writing a filter. Draft a work order description from a spoken note. Summarise a long history for a handover. This is the most common meaning today, it is useful, and it is comparatively low risk because it reads rather than writes. Its failure mode is confident summarisation of an incomplete record, which is worth testing for directly during an evaluation.

Automated scheduling, prioritisation and planning. Suggest which PMs to move, rank a backlog, estimate labour hours, group work by location or shutdown window. This is genuine optimisation, and it can save planner time when the constraints it optimises against are complete. Its failure mode is a recommendation that does not know about a constraint living outside the system, such as a crew certification, a permit, or a regulatory inspection window.

Failure prediction. The predictive maintenance capability described above, packaged inside the CMMS. Its failure mode is that it needs condition data the CMMS usually does not hold, so it either depends on an integration to a historian or it predicts from work order history alone, which is a much weaker signal.

The buyer’s real problem is not that any of these is bad. All three are legitimate. The problem is that they are sold under one label, so two quotes that both say AI CMMS may not be comparable at all. The practical response is to stop asking whether a product has AI, and start asking which of the three it does, what data it needs to do it, and what happens when it is wrong.

A note on the word “agentic”

The market currently uses “agentic” to mean software that takes multi step actions toward a goal, rather than answering a question and stopping. A search feature answers. Something described as agentic is supposed to do a sequence: look something up, decide, act, check, continue.

Reported as a market term, that is a real and useful distinction, and it maps onto the difference between the first meaning of AI CMMS and the coordination problem set out above. Used as a product claim, it tells you nothing on its own. The questions that make it meaningful are the ones about boundaries: which actions, decided by whom, bounded by what limits, reversible how, and recorded where. Multi step action without answers to those questions is a risk a buyer has to price, not a feature. We avoid the word for our own product for exactly this reason, and it is worth pressing any vendor who uses it.

The comparison

Category	What it is for	What it is authoritative over	The question it answers	Where it stops
CMMS	Managing and recording maintenance work	Work orders, PM schedules, labour, parts consumed, asset register	What work exists, what was done, by whom, when, at what cost	It records the outcome of coordination, not the coordination itself
EAM	Managing assets across their life cycle	Asset life cycle, condition history, capital planning, depreciation and reporting	What we own, what condition it is in, what it will cost to keep	It plans and reports; it does not execute a specific repair
APM	Improving reliability and availability	Criticality, risk models, condition assessment, remaining useful life	Which assets should worry us, and how much	It tells you what to prioritise, not how to get it fixed
Predictive maintenance and condition monitoring	Detecting degradation before failure	Sensor and process data, models, alarm criteria	Is this asset heading for failure, and how soon	It produces a warning; the work after the warning is out of scope
“AI CMMS” (as marketed)	Adding search, scheduling or prediction to a CMMS	Whatever the underlying CMMS was authoritative over	Depends entirely on which of the three capabilities is included	The label does not tell you, which is the buyer’s problem

The category none of these names

Read down the last column. Every category stops at a boundary, and the boundaries share an edge. Detection ends at the alarm. Prioritisation ends at the ranking. The record begins at the closed work order. Between the alarm and the closed work order there is a stretch of work that is nobody’s product category.

That stretch is concrete: assembling the evidence for what actually failed, working the fault down from symptom to cause, tracking the safety items and permits, verifying that the part in the storeroom is the part on the asset, getting quotes when it is not, routing the approval to whoever holds the spend authority, keeping the record current while all of this happens, and closing out with proof.

This is not a novel observation, and it is worth showing that the reliability engineering literature named these components long before anyone sold software for them. IEC 61703:2016, adopted in Europe as EN 61703:2016, gives mathematical expressions for dependability terms that IEC 60050-192:2015 defines. Its clause list is instructive. It handles mean repair time (192-07-21) and mean active corrective maintenance time (192-07-22) as quantities separate from mean time to restoration (192-07-23), and gives mean administrative delay (192-07-26) and mean logistic delay (192-07-27) clauses of their own. Its glossary of acronyms carries mean technical delay alongside them, described there as the expectation of the technical delay. Figure 2 of the standard is titled, plainly, “Constituents of down time” (IEC 61703:2016, free preview).

Two things follow from that.

The first is a terminology correction that is worth making inside your own organisation. In the standard, MTTR is mean time to restoration, and mean repair time is a different, narrower quantity with its own acronym. Many maintenance teams use MTTR loosely to mean downtime, which quietly folds in production loss and startup that no maintenance decision controls. If you are going to measure a change, decide which clock you mean and hold it fixed.

The second is the substantive point. The standard treats administrative delay and logistic delay as named constituents of down time, not as noise. Waiting for a decision is a measured quantity. Waiting for a part is a measured quantity. If your improvement effort has been aimed entirely at repair time, and your restoration time has barely moved, the decomposition tells you where to look. It also tells you that the coordination work is not a soft problem that resists measurement. It has been formally decomposed for years.

No category in the table above owns those components. A CMMS records that they occurred. An APM tool may show you their cost. A predictive model tries to give you more warning before they start. None of them do the work.

Questions worth asking in an evaluation

If you take one practical thing from this page, take the list of questions that make the categories separate again.

Ask which system remains the system of record after the purchase, and get the answer in writing. If a product intends to replace your CMMS, that is a migration project with its own risks, and it should be evaluated as one. If it intends to sit on top, ask exactly which fields it writes back, and when.

Ask what data the product needs on day one, and whether you have it. Failure prediction needs condition data. Criticality models need a clean hierarchy. Natural language search over work orders needs work orders that were written usefully. A demonstration on the vendor’s data tells you very little about performance on yours.

Ask what the product does when it is wrong, and who finds out. For a summary, the answer should be a citation back to source records you can open. For a recommendation, the answer should be a human decision point. For any action taken automatically, the answer should be a time stamped record of what was done, under whose authority, and how to reverse it.

Ask what the product is allowed to touch. For anything that connects to plant systems, the conservative default in water and wastewater is read only, and it is worth making a vendor argue for anything beyond it. Reading SCADA events and historian trends is a normal integration. Writing to a PLC, a DCS or a SCADA system is a different category of decision, and a maintenance coordination tool has no business in it.

Ask how you will know whether it worked. Pick the clock before the pilot starts, define the exclusions before you have results, and write down the denominator. A vendor unwilling to agree on a measurement definition in advance is telling you something.

Where we sit, stated plainly

This is the publisher’s own position, and you should read it as such.

EQUA AI builds EQUA AIMMS, which is aimed at exactly the stretch described above: the coordination work between a detected fault and a closed work order. It sits on top of the CMMS, EAM and ERP you already run. Those remain the systems of record, and we think that is correct, not a compromise. Operational connectivity is read only: AIMMS consumes SCADA events and historian trends, and it never writes to a PLC, DCS or SCADA system, never issues a setpoint, restart, interlock or actuator command. What it may do is defined by you, through roles, permissions, spend limits, safety policies and approval gates, and every permitted action leaves a time stamped receipt.

That places us in the taxonomy alongside the categories above rather than in place of any of them. If your problem is that you do not know which assets are about to fail, buy condition monitoring and predictive maintenance, and hold that vendor to the prediction. If your problem is that your asset register and capital plan disagree, that is an EAM problem. If your problem is that the record of work is unreliable, fix the CMMS configuration before buying anything new, because everything else inherits that ceiling.

If your problem is that the repair is understood on day one and finished on day nine, the categories above will not tell you why. The decomposition in IEC 61703 will.

Sources

• IEC. IEC 61703:2016, Mathematical expressions for reliability, availability, maintainability and maintenance support terms, Edition 2.0, August 2016. Adopted in Europe as EN 61703:2016. Publication page: webstore.iec.ch/en/publication/25646. The free preview carries the contents list, Figure 2 “Constituents of down time” and the glossary of acronyms cited above: sis.se preview of IEC 61703:2016.
• IEC. IEC 60050-192:2015, International Electrotechnical Vocabulary (IEV), Part 192: Dependability, February 2015. The source of the term references in square brackets in IEC 61703. webstore.iec.ch/en/publication/21886. The vocabulary is also readable at no cost via Electropedia.
• Governmental Accounting Standards Board. Statement No. 34, Basic Financial Statements and Management’s Discussion and Analysis for State and Local Governments, June 1999. Full text as hosted by PwC Viewpoint: gasbs34.pdf.
• Federal Highway Administration. Primer: GASB 34, November 2000. Summarises the modified approach requirements, including replicable condition assessments at least every three years and the annual estimate of the amount needed to maintain and preserve at the disclosed condition level. fhwa.dot.gov/infrastructure/asstmgmt/010019.pdf.
• ISO. ISO 55000:2024, Asset management: Vocabulary, overview and principles, second edition, July 2024. iso.org/standard/83053.html.
• ISO. ISO 17359:2018, Condition monitoring and diagnostics of machines: General guidelines, third edition, January 2018. iso.org/standard/71194.html.
• Gartner. IT Glossary: Enterprise Asset Management (EAM), accessed September 2026. Gartner’s glossary definition, quoted as such. gartner.com glossary entry.
• Gartner. Asset Performance Management Reviews and Ratings, market definition, accessed September 2026. Gartner’s market definition, quoted as such. gartner.com/reviews/market/asset-performance-management.
• US Environmental Protection Agency. Asset Management Plans and the Clean Water State Revolving Fund, accessed September 2026. Context on asset management expectations for US wastewater utilities. epa.gov/cwsrf/asset-management-plans-and-clean-water-state-revolving-fund.