Predictive Maintenance Software: Where It Fits With a CMMS

Motor 27 has an alert. Now what?

A vibration-monitoring system identifies abnormal behavior on Motor 27. It suggests a developing bearing problem. Now what?

• Does somebody inspect it?
• Does a work order get created?
• Should maintenance intervene now or continue monitoring?
• When can production release the equipment?
• Is the required bearing available?
• How urgent is this finding beside other maintenance work?
• What happens if the technician opens the machine and finds a sound bearing with a misaligned coupling?
• Does that field finding reach the system that generated the alert?

Detecting something and maintaining it are separate parts of the operating process.

Their connection explains where predictive-maintenance technology fits with maintenance-management software. Condition information has value when it arrives early enough, with enough credibility and context, to change a maintenance decision. The resulting work should preserve evidence that can improve the next decision.

PHYSICAL CONDITION → MEASUREMENT / SIGNAL → DETECTION → DIAGNOSIS → PROGNOSIS, WHERE SUPPORTED → MAINTENANCE DECISION → WORK → FIELD FINDING / ACTION / RESULT → FEEDBACK

A CMMS is especially relevant to the decision, work, result and history portions of this chain. Product boundaries vary. Some platforms cover condition analytics and work management together; others exchange information across systems.

Clarify what the software actually does

Software marketing often uses condition monitoring, anomaly detection, diagnosis, prognosis, condition-based maintenance and predictive maintenance interchangeably. Industry definitions also vary. Buyers can still separate the underlying information problems.

A NIST-authored review describes diagnostics as detecting, isolating and identifying faults, while prognostics concern predicting future performance or remaining useful life. It also emphasizes actionable information for decision-making.[1]

DOE’s federal O&M guide describes predictive maintenance as detecting the onset of degradation so it can be addressed before significant deterioration, while stressing appropriate application, training and sustained program support.[2]

What exactly is being predicted?

“Predictive” can refer to several outputs. Each supports a different maintenance conversation.

• An abnormal condition
• A probable fault
• A degradation trend
• The likelihood of a future event
• A future condition
• Remaining useful life
• A recommended intervention time

A product may provide one or several of these. A rising vibration trend, a bearing-fault diagnosis and an estimated time before a defined limit are distinct claims.

• What input evidence is used?
• What output is produced?
• What does that output mean operationally?
• How is uncertainty or confidence represented?
• Which maintenance decision is the output intended to support?

Ask the vendor to demonstrate these answers with a real use case. A model name, anomaly score or health color does not explain what has been inferred about the equipment.

Remaining useful life is information for a decision

Suppose software displays “Estimated remaining useful life: 37 days.” Maintenance should not interpret that number as an exact failure date.

NASA prognostics research treats remaining useful life as a prediction under uncertainty. Its framework separates current-state estimation from prediction of future states until a failure threshold, and accounts for multiple uncertainty sources.[3]

The uncertainty in a particular estimate can involve measurements, model structure, degradation assumptions, future loads or operating conditions, environmental conditions and available historical data. The relevant sources depend on the method and use case.

A remaining-useful-life estimate informs a decision; it does not schedule failure.

Predictability belongs to the failure mode

“Can we predict failures on Pump 14?” is too broad. Pump 14 can lose function through different mechanisms. Some produce measurable degradation before functional failure. Others produce little useful warning, or their warning cannot be captured economically in time to act.

ASSET → IMPORTANT FAILURE MODE → DETECTABLE CONDITION? → USEFUL WARNING TIME? → APPROPRIATE MEASUREMENT? → ACTIONABLE MAINTENANCE RESPONSE?

This sequence prevents an equipment label from standing in for a use case. It also prevents criticality alone from becoming a sensor-installation plan.

The equipment maintenance software guide explains how identity, components, condition and maintenance history accumulate around an individual asset. Predictive evaluation adds a failure-mode-specific question: can developing degradation be observed early enough to change action?

Check predictive-maintenance readiness

The following readiness test is practical buyer guidance. It is not a formal reliability-engineering decision model.

A NIST-hosted PHM white paper proposes beginning with desired operational outcomes and use cases, assessing current maintenance and health-ready capability, then selecting cost-effective asset-condition-management strategies.[4]

The existence of a sensor does not establish a predictive-maintenance use case.

A signal can be technically measurable and operationally unhelpful. Warning that arrives after the last practical intervention window may not change the decision. A plausible alert without a defined response can generate information without improving maintenance.

Where the CMMS fits

Condition and predictive capabilities may hold sensor readings, trends, anomalies, condition assessments, diagnostic outputs, degradation estimates and, in some cases, prognostic outputs such as remaining useful life.

A CMMS may hold equipment identity, maintenance history, open work, priorities, procedures, technicians, labor, parts, inspections, schedules, completed work, costs and field findings.

Some products cover both sets. The buying question concerns continuity across the handoff: how does condition intelligence become controlled maintenance action while retaining its source and context?

SENSOR / INSPECTION / CONTROL SYSTEM → CONDITION / PREDICTIVE ANALYTICS → ALERT / RECOMMENDATION → MAINTENANCE DECISION → CMMS / WORK MANAGEMENT: TRIAGE, PRIORITY, WORK ORDER, PLANNING, PARTS, SCHEDULE, ASSIGNMENT, EXECUTION → FIELD FINDING + ACTION + RESULT → MAINTENANCE HISTORY → FEEDBACK

DOE’s O&M guide describes CMMS functions including work-order generation, prioritization and equipment-linked history.[2] The maintenance work order software guide examines how a maintenance need should move through preparation, execution and evidence.

Predictive technology often sits upstream of work creation. Useful integration can also carry work status, field findings, component replacement and maintenance results back toward the condition process.

Review alerts before creating work

Automatic work-order creation can be appropriate for a well-understood alert and response. Applying it to every alert can flood the work system with duplicates, low-value tasks or findings that first need interpretation.

Depending on the operation, alert review may lead to work creation, inspection, another measurement, continued monitoring, deferral to an operating window, escalation, dismissal, duplicate identification, association with existing work, or recognition that the condition has cleared.

• Does every alert create a work order?
• If review is required, where does triage occur?
• Can reviewers see the source evidence and relevant maintenance history?
• Can the system preserve why an alert was deferred, dismissed or connected to existing work?

FEMP guidance for operating energy-management information systems describes these systems as human-in-the-loop tools and identifies failure to act on findings, verify corrections or tune fault-detection rules as practical operating problems.[5]

Wrong alerts have operational consequences

Repeated low-value alerts can consume technician time, planner attention, inspections, equipment access, parts and operating disruption. They can also reduce confidence in the alert stream. Missing an important developing failure may carry a much greater consequence.

Ask what happens operationally when the system is wrong in either direction.

The answer depends on the asset, failure mode, consequence, intervention cost and cost of missed detection. One universal accuracy target cannot represent all of those tradeoffs.

Model metrics can support evaluation. Buyers also need operational measures: which alerts led to useful findings, which created avoidable work, which important conditions were found elsewhere, and how decisions changed.

Priority should combine condition and consequence

An anomaly score or degradation estimate supplies one part of a maintenance decision. Priority may also depend on asset consequence, redundancy, production requirements, degradation rate, operating windows, parts availability, repair duration, existing work, and the ability to continue monitoring safely.

A universal priority formula would hide local operating judgments. The software should preserve the alert’s meaning while allowing the operation to apply its own consequence and constraint information.

The maintenance scheduling guide addresses what happens after demand enters the work system: readiness, skills, materials, equipment access and operating constraints shape the commitment.

Prediction, decision, work

A predictive system reports: “Developing bearing condition detected.” Maintenance still needs to decide whether the evidence is credible, whether inspection is needed, whether related work already exists, how urgent the condition is, which procedure and parts may be required, when equipment access is possible, and who can perform the work.

A prediction has maintenance value when it can become a decision and, when appropriate, executable work.

1. Preserve the originating alert, asset, component, time and evidence.
2. Review the alert in operating and maintenance context.
3. Record the disposition and decision.
4. Create or connect controlled work when action is required.
5. Plan access, procedure, labor, parts and timing.
6. Capture what technicians observe and do.
7. Connect the result back to the alert and condition history.

For production environments, the CMMS for manufacturing guide explains how equipment access and production consequence affect maintenance execution.

Field reality should close the loop

The system predicts an outer-race bearing defect. A technician opens the equipment and finds the bearing acceptable and the coupling misaligned. If the work order records only “Completed,” the maintenance system knows activity occurred. The predictive process may never receive evidence that the diagnosis and field finding differed.

In another case, the system predicts bearing degradation and the technician confirms bearing spalling. That confirmation is valuable evidence.

ALERT / PREDICTION → MAINTENANCE DECISION → WORK → FIELD FINDING → ACTION → RESULT → FEEDBACK

The predictive system should inform maintenance, and maintenance should inform the predictive process.

Feedback can mean linking confirmed or incorrect findings to the alert, reviewing alert quality, adjusting thresholds, updating rules or models through an appropriate controlled process, and improving human decisions. It does not require automatic model retraining.

The central requirement is continuity: field reality should remain connected to the information that initiated the decision.

A prediction is a claim that should encounter reality

The maintenance tracking software guide distinguishes recorded facts, derived information and interpretation. Predictive maintenance adds a future-facing layer.

MEASUREMENT: WHAT DID WE OBSERVE? → INTERPRETATION: WHAT DOES THE SYSTEM THINK IT MEANS? → PREDICTION: WHAT MAY HAPPEN? → DECISION: WHAT WILL MAINTENANCE DO? → FIELD REALITY: WHAT DID WE FIND?

A prediction can be technically well-founded while remaining a claim about a future state. Linking it to decisions and later findings creates the evidence needed for validation and learning. This is a disciplined use of predictive information, rather than distrust of it.

Condition-triggered work may still be classified as corrective

Monitoring may detect degradation or a fault after it has begun and before the equipment loses its required function. Maintenance then intervenes because of the detected condition.

A peer-reviewed paper co-authored by NIST researchers explains that, under some maintenance definitions, work initiated after potential failure is detected may still be categorized as corrective even when PHM allowed intervention before functional failure.[6]

An increase in some condition-triggered corrective work does not by itself establish that a predictive program is failing. A reduction in corrective-work count also cannot serve as the only success test. Buyers need to understand how the organization classifies condition-triggered work and what its measures include.

Terminology varies. The useful requirement is consistent classification that allows the organization to explain what initiated the work and what outcome followed.

Predictive and preventive methods can coexist

The preventive maintenance software guide treats recurring work as a trigger-to-evidence process. Predictive information provides another possible trigger when a suitable failure mode produces actionable condition evidence.

Different failure modes may be managed through run-to-failure decisions, calendar-based or usage-based PM, inspections, condition-based action, prognostic methods, or redesign that removes the failure mode.

A low-consequence component may not justify sophisticated monitoring. A failure mode without detectable degradation may be a weak predictive candidate. A straightforward PM can remain economical. A condition-based approach can be useful without a future RUL estimate.

Evaluate the economics of the full system

Potential value can arise from avoiding consequential failures, reducing unnecessary interventions, choosing better intervention timing, preparing labor and parts, coordinating operating windows, extending component use where appropriate, reducing secondary damage or improving diagnosis.

The complete cost can include sensors, installation, connectivity, data infrastructure, software, integration, configuration or model work, monitoring and analysis, training, upkeep of the monitoring system, and investigations generated by alerts.

A NIST procedural guide for condition-monitoring investment analysis explains that value assessment should account for system-level risk, monitoring performance, implementation costs and the difficulty of valuing failures that may be prevented.[7]

No general ROI figure can determine whether a use case is worthwhile. Buyers should compare a defined failure mode, baseline maintenance approach, expected decision change, operational consequence, monitoring performance and full lifecycle cost.

The CMMSBuyersGuide predictive-maintenance framework

This is a CMMSBuyersGuide framework, not an industry standard. It keeps the buying conversation anchored to an operating use case.

CONSEQUENCE → FAILURE MODE → EVIDENCE → DETECTION / DIAGNOSIS / PROGNOSIS → DECISION → WORK → RESULT → FEEDBACK

1. CONSEQUENCE — Is this failure important enough to justify better warning?
2. FAILURE MODE — What specifically are we trying to anticipate?
3. EVIDENCE — Does degradation create a useful measurable signal?
4. DETECTION / DIAGNOSIS / PROGNOSIS — What can the technology actually tell us?
5. DECISION — What action changes because we know?
6. WORK — How does the decision become controlled maintenance?
7. RESULT — What did technicians find and do?
8. FEEDBACK — Was the information useful, and what should change?

A weak link can break the use case. Strong sensing with no response path produces alerts without action. Efficient work execution with no field detail prevents validation. Detailed findings with no connection to the original alert lose the learning loop.

Practical buyer questions

• What specific failure modes are we trying to detect or anticipate?
• What evidence precedes those failures?
• How much useful warning can that evidence provide?
• What exactly does the system detect, diagnose or predict?
• What uncertainty accompanies predictions?
• What maintenance decision changes because of the information?
• Who reviews an alert?
• When does an alert become a work order?
• How is maintenance priority determined?
• How does the predictive system identify the correct asset and component in the CMMS?
• Can maintenance see relevant history before deciding?
• What happens when maintenance chooses to monitor?
• Can we preserve why an alert was dismissed or deferred?
• Can field findings be linked to the original alert?
• Can confirmed findings be distinguished from false or low-value alerts?
• Does completed maintenance feed useful information back into the condition process?
• Can we evaluate operational value as well as alert volume?

Turn these operating questions into testable requirements using How to Build Your CMMS Requirements.

Vendor demo: follow one Motor 27 alert

Avoid beginning with “Show us your predictive dashboard.” Give the vendor a scenario that crosses the condition-to-work boundary.

Evidence and prediction

• What condition evidence produced the alert?
• What is raw measurement and what is processed information?
• Is the system detecting an anomaly, diagnosing a fault or making a prognosis?
• What exactly is being predicted?
• What confidence or uncertainty information is available?
• If RUL is provided, what does it mean and which assumptions influence it?

Context and decision

• Which asset and component does the alert belong to?
• Can the reviewer see relevant maintenance history?
• Does the alert create work automatically?
• If review is required, where does it occur and who participates?
• Who determines maintenance priority?
• What happens when maintenance decides to continue monitoring or dismiss the alert?

Work and feedback

• How does the alert become or connect to a work order?
• How do planning, parts and scheduling enter the process?
• How does the system prevent duplicate work?
• What happens when technicians find a different fault?
• Can the field finding and action link back to the original alert?
• Can confirmed predictions be distinguished from low-value alerts?
• Can completed maintenance affect future monitoring or analysis through an appropriate process?

Now show us how we would know whether the prediction was right or wrong—and whether acting on it created value.

The test does not require automatic machine learning. It requires feedback, traceability and an evaluable maintenance outcome.

Capabilities to evaluate

Select capabilities according to the failure modes, decisions and architecture your operation has defined. Every use case will not require every item.

• Sensor and data-source connectivity
• Condition trending and relevant visualization
• Anomaly and fault detection
• Diagnostic capabilities
• Prognostic capabilities and RUL where appropriate
• Confidence or uncertainty information
• Alert thresholds and rules
• Alert review, triage and disposition
• Asset and component mapping
• Access to maintenance history
• CMMS and work-management integration
• Controlled work-order creation and duplicate-work prevention
• Maintenance priority handling and technician notification
• Mobile access, inspection results and field findings
• Feedback connected to alert history
• Confirmed, unconfirmed and low-value finding tracking
• Alert-performance and operational-value analysis
• Connections to control, historian, IoT or other operational systems where required

Ask what integration preserves

“Does it integrate with our CMMS?” is only a starting question. Integration quality depends on the meaning, direction and continuity of the information exchanged.

• What information moves from the predictive system to the CMMS?
• What identifies the asset and component in both systems?
• Does the alert retain its evidence, time and source context?
• Can duplicate work be detected or avoided?
• Does work-order status flow back?
• Do inspection results and field findings flow back?
• Does component replacement or a meter reset affect monitoring appropriately?
• What happens when the asset hierarchy changes?
• What happens during a connectivity failure?
• Which system is authoritative for each kind of information?
• Can users trace completed work to the originating condition alert?

One architecture cannot fit every operation. Buyers should define the required information flow, ownership and failure behavior before accepting an integration diagram.

For a broader discussion of system boundaries, see CMMS vs EAM. For the foundational role of maintenance-management software, see What Is a CMMS?.

Follow the alert through maintenance and back

A sophisticated prediction is an intermediate output. The buyer still needs to ask what was observed, what the system thinks it means, what is being predicted, how uncertainty is represented, which maintenance decision changes, how that decision becomes work, what technicians find, whether the prediction is confirmed, and what happens after intervention.

The field result should remain available for the next alert, review and maintenance decision.

A prediction that never becomes a better maintenance decision is information without operational value. Follow the alert into maintenance, then follow the result back.