AI Prescriptive Maintenance Fails Without CMMS, EAM and ERP Integration

An AI-generated maintenance recommendation has no value until planners can execute it, and execution lives in the CMMS, EAM platform or ERP maintenance module — not in the monitoring system that produced the alert. That is the central argument of Eranda Maldeniya, co-founder of Enterprise Analytics, who has more than 20 years of experience in enterprise software and leads the firm's proprietary AI product development.

Maldeniya's guidance, which draws on IBM's published overview of prescriptive maintenance, targets implementation teams connecting condition-monitoring platforms to the systems through which planners organize work and obtain approvals. IBM describes how teams use equipment-condition data to recommend interventions while accounting for operational and financial constraints.

What does a real workflow look like?

The worked example involves a critical production asset. A condition-monitoring system detects early bearing deterioration from vibration and temperature patterns and issues an alert before the next scheduled shutdown. The responsible engineer then weighs three options: intervene early, plan the repair during the shutdown, or request further monitoring.

To decide, the engineer reviews the asset's criticality, maintenance history and established maintenance instructions against engineering safety requirements. The planner checks spare parts and qualified resources against the production schedule. If the engineer recommends replacing the bearing during a planned stoppage, the planner must confirm a compatible part, qualified personnel and a stoppage date within the engineer's approved intervention window. A stock conflict or a scheduling clash goes back for review.

Maldeniya draws a hard line between two checks:

• Technical suitability: the reliability engineer verifies the proposed intervention addresses the equipment condition and complies with engineering requirements.
• Operational feasibility: the planner verifies the organization has the parts and people to do the work within the production schedule.

A team may accept the technical recommendation yet lack the resources to execute it, he notes. Connecting ERP and EAM records gives reviewers access to outstanding constraints and required approvals.

Where do integrations break?

Developers must first identify which system holds the authoritative record for each step, since a plant may split work management, procurement and budgeting across separate applications. The integration team should agree which records it can create or change in each one.

Identifier mapping is a known failure point. If developers cannot establish an unambiguous match between the monitoring platform's equipment identifiers and the maintenance system's records, the workflow must not update the asset record; it should route the mismatch for review.

Post-request verification matters equally. A receiving application may create only a draft work order that still requires approval or a parts reservation, and planners need that status before treating the job as ready. Maldeniya would retain links to supporting evidence and flag information reviewers still need to confirm. A reviewer facing a generic "approval required" notification must reconstruct the issue before deciding; a properly structured record presents the affected asset, the proposed task and the unresolved constraint together.

How much automation is safe?

Early deployments should let software prepare recommendations and draft work orders while people retain release authority, Maldeniya writes. Before extending automation, engineers should assess the consequences of error and validate controls for each action class. Purchasing a component and changing an equipment operating parameter demand separate decisions about permissions.

Developers should preserve the source alert, completed checks, recommendation, human changes and work-order reference, distributed across systems but reconstructable by any reviewer through links.

What should teams measure?

For an initial deployment Maldeniya would measure:

• Time from identifying a potential failure to approving a maintenance plan
• Percentage of recommendations requiring manual intervention
• Delays by cause — unavailable parts, resource shortages, production constraints
• Post-maintenance comparison of technicians' findings against the original recommendation

Over time, teams could assess unplanned downtime, asset availability, maintenance costs and overall equipment effectiveness (OEE). A defined baseline must come first, he warns: completing a work order does not establish that the team prevented a failure. Initial scope should cover one asset class and a defined set of interventions.

The bearing case illustrates the standard: a team should trace the original condition alert through engineering review, resource checks and completed work — a record that corrects future recommendations, exposes recurring delays and explains the decision to the next reviewer. The open question for adopters is whether their governance can keep human authority and audit trails intact as automation expands.