The technical side of predictive maintenance — sensors, signal processing, machine learning models — gets most of the attention. The operational side — how an alert from a condition monitoring system actually becomes a completed work order in your CMMS, with parts staged and a tech scheduled — gets far less. This gap is where a lot of predictive maintenance programs fail to deliver their promised value. The sensor saw the bearing problem. The RUL model flagged it. And then the alert sat in a dashboard that nobody checked regularly, or it generated a notification that went to an inbox already full of other alerts, or it was manually re-entered into the CMMS by whoever happened to notice it that week.
Closing the loop between the predictive alert and the completed corrective action is a workflow design problem, not a technology problem. This article is about how to design that workflow to be reliable, sustainable, and resistant to the alert fatigue that kills most PDM programs within 18 months of deployment.
The Alert-to-Work-Order Gap
Most condition monitoring systems generate alerts. Most CMMS systems receive and track work orders. Between alert generation and work order creation, there is typically a human-in-the-loop step — a reliability engineer or maintenance planner reviews the alert, decides it warrants action, creates or requests a work order, and adds it to the maintenance backlog. That human step is necessary for quality control, but it's also where alerts stall and die.
The reasons are predictable: the alert system generates too many alerts (false positive problem), the reliability engineer reviewing them doesn't have clear criteria for when to escalate to a work order, the CMMS and the condition monitoring system are disconnected so creating the work order means re-entering information manually, and there's no tracking of whether a work order was eventually created for each alert and what was found at the bearing when the work was done. You can't improve a process you can't measure.
Designing the Alert Tier Structure
The first design decision is how many alert levels to define and what action each level triggers. A common pattern that works well for rotating equipment condition monitoring:
Level 1 — Watch: A change from baseline that is statistically significant but within the normal variation band for this machine class. No immediate action. Triggers: increased monitoring frequency (if your system supports dynamic sampling rates), annotation in the trending log, no work order. The reliability engineer's job here is to confirm the alert is not an artifact (sensor issue, recent maintenance, process change) and continue monitoring.
Level 2 — Investigate: The condition has progressed beyond normal variation. RUL confidence interval lower bound (P10) is >30 days. Action: create an investigation work order in the CMMS — a short inspection task to verify the alert with supplemental measurement (route-based vibration data, thermal image, oil sample). This is a low-cost gate before committing to a corrective maintenance work order.
Level 3 — Plan: Investigation confirmed the condition. RUL P10 is 15–30 days. Action: create a corrective maintenance work order, specify parts required, assign priority, schedule within the maintenance window. The work order type in your CMMS should be "predictive/condition-based" — not "breakdown" — so you can separate planned corrective maintenance from emergency response in your KPIs.
Level 4 — Immediate: RUL P10 <15 days, or condition has shown rapid progression in the last monitoring cycle. Action: immediate work order creation, expedite parts if necessary, flag for operations to assess risk of continued operation.
The specific RUL thresholds should be adjusted for your plant's maintenance planning cycle and parts lead times. If your standard bearing stock isn't on the shelf and requires 3-week procurement, your Level 3 trigger needs to be earlier than 15 days.
CMMS Integration: What Actually Needs to Be Connected
The three CMMS systems most commonly deployed in heavy industrial facilities — IBM Maximo, SAP PM, and Infor EAM — all support external system integration through REST APIs, web services, or SOAP endpoints. The technical integration is generally straightforward; the harder part is agreeing on the data schema and the trigger logic.
For a predictive alert to automatically create or request a CMMS work order, the condition monitoring system needs to provide at minimum:
- Asset identifier: The equipment ID as it exists in the CMMS asset register, not just the monitoring system's internal tag. This requires an asset master alignment step during implementation — ensuring that every monitored point is mapped to the correct functional location and equipment record in the CMMS. This step takes longer than expected at most sites.
- Failure mode description: Not just "bearing alert" but the specific fault hypothesis — "outer race defect, BPFO sidebands elevated, 4.2x baseline amplitude." This goes into the work order description and gives the technician executing the work order diagnostic context.
- Recommended action: Inspection, replace, lubricate, vibrate check. The right action should be encoded in the alert type, not left for the planner to decide from a vibration trend chart they may not know how to interpret.
- Priority and due date: Derived from the RUL P10 estimate. The CMMS work order priority field needs to be populated with a value that actually reflects the urgency — not just "medium" for everything, which causes the priority field to be ignored.
- Hyperlink back to the monitoring dashboard: The technician executing the work order should be able to click from the work order to the live trend chart for that asset. This closes the information loop and lets the tech confirm the condition hasn't changed between work order creation and execution.
For Maximo specifically: the standard integration pattern uses the Maximo REST API (MXWO/MXSR object structures) for work order creation and the MXASSET structure for equipment record lookup. SAP PM uses the IW31 transaction equivalent via the PM notification/order API. Infor EAM uses the REST API for work request creation against the equipment record. All three require authentication tokens and handle duplicate prevention differently — your integration layer needs to check for existing open work orders on the same asset before creating a new one.
The False Alarm Problem and How to Design Around It
Alert fatigue is real and it kills PDM programs. When reliability engineers start seeing 40 alerts per week and 35 of them result in "bearing was fine, no action taken," they stop taking the alerts seriously. Within six months, the condition monitoring system is still running, the data is still being collected, and nobody is looking at the alerts anymore. The program has effectively failed without anyone declaring it failed.
The primary lever for managing false alarm rate is alert threshold calibration, and it requires feedback data to do correctly. If you don't know your false positive rate — because you're not recording bearing condition at every intervention that came from a predictive alert — you can't calibrate your thresholds. The feedback loop from finding at repair back to alert quality is not optional; it is the mechanism by which the system improves.
Practical design principles for managing false alarm rate:
- Never auto-create a Level 3 or 4 work order without a human review step. The human review is a quality gate, not a bottleneck — a 15-minute review by the reliability engineer is the right investment before creating a corrective maintenance work order for a critical asset.
- Build a 48-hour window into Level 2 investigation alerts before they escalate to Level 3. Many short-term anomalies in condition monitoring are transient — process upsets, temporary load changes, sensor coupling issues. A 48-hour stabilization window eliminates a large fraction of these without requiring human intervention on each one.
- Record the finding at every bearing removal in the CMMS work order. "Bearing removed — outer race spall confirmed, 40mm2 area" or "Bearing removed — no visible damage, replaced preventively." This data feeds the alert calibration cycle. Without it, you're tuning thresholds blind.
What Good Looks Like After 12 Months
A well-integrated PDM workflow after 12 months of operation should show measurable shifts in your maintenance KPIs:
- Planned vs. unplanned corrective ratio for the monitored asset class should be moving toward 70/30 or better (planned:unplanned). If you're still seeing the same ratio you had before PDM deployment, the alerts aren't translating to scheduled work orders.
- Mean time between failure for the monitored bearings should be increasing, or mean time to repair should be decreasing (because you're doing planned replacements with parts on hand, not emergency scrambles).
- Alert confirmation rate (fraction of Level 3+ alerts that result in a confirmed defect at bearing removal) should be above 70%. Below 50% means your alert thresholds are too sensitive; above 90% for a long period may indicate you're setting thresholds too conservatively and missing early-stage detections.
The CMMS integration is where predictive maintenance technology either pays off or wastes the organization's investment. The sensors and models are the front end; the work order system and the maintenance execution are the back end; and the feedback loop between them — what you find at repair, how that updates the model, how the model improves its alert accuracy — is the mechanism that makes the program get better over time rather than staying static.
Getting the workflow design right from the start matters more than getting the sensor technology perfect. We've seen sites with good instrumentation and poor workflow integration generate negligible business value from their PDM investment, and sites with more modest sensor arrays and tight CMMS integration consistently delivering measurable reductions in unplanned downtime. The workflow is the product, not the sensor.