Why Maintenance Systems Record Work but Do Not Coordinate the Fix
A CMMS is a system of record, and that is exactly what it should be. The question is who, or what, coordinates the work between the alarm and the closed work order.
Working on a live operating problem? Book Your 20-Minute Assessment
If you run maintenance for critical infrastructure, you already own a system of record. It holds your assets, your work orders, your history, and your regulatory evidence trail. It is probably well configured, and your team has spent years making it fit the way you operate. None of that is the problem.
The problem shows up in the hours between an alarm and a closed work order. In that window, someone pulls trend data from one screen, asset history from another, a parts list from a third, and a supplier number from an inbox. Someone decides which fault this actually is, confirms the part on the shelf matches the part on the asset, and chases an approval. The system of record captures the outcome of that effort. It was never designed to do the effort itself.
That distinction, between recording work and coordinating it, is the subject of this article.
Coordination can sit between operational context and the authoritative business record without creating a control path
Figure 1. Coordination can sit between operational context and the authoritative business record without creating a control path. Three stacked zones. Operational context contains SCADA events, historian trends, and monitoring findings, with a read-only one-way connection to an AIMMS coordination record. That record contains evidence, blockers, approvals, parts, suppliers, and closeout. A separately gated connection can update authoritative business records in CMMS, EAM, ERP, inventory, and procurement only after the customer-specific integration is built, tested, and approved. No path returns to plant control.
The record is doing its job
A CMMS or EAM exists to answer a specific set of questions with authority. What assets do we own? What work was done, by whom, and when? What did it cost? What is scheduled next? What does the auditor need to see?
These are not small questions. Regulated utilities and critical facilities depend on the answers being right, defensible, and durable for years. A good system of record earns its place by being the single authoritative version of asset and work history.
Modern platforms keep getting better at this, and many now add planning aids, mobile workflows, and AI features on top of the record. That is healthy evolution. The point here is narrower: whatever sits on top, the center of gravity of a system of record is documentation and process integrity. Coordinating an active repair is a different job with different requirements.
A record is not coordination
Consider what a work order actually asserts: work exists, here is its priority, its assignee, its asset, and what was reported. Now consider what still has to happen before that work order closes well.
Someone has to assemble the evidence: the alarm history, the trend leading into the event, the last interventions on that asset, the failure modes that fit the symptoms. That evidence lives across monitoring systems, historians, and the record itself, and it does not assemble on its own.
Someone has to guide the diagnosis. A symptom is not a fault. Getting from “high vibration on pump 3” to “bearing wear on the drive end, replace and check alignment” takes reasoning, and often takes the one technician who has seen this asset fail before.
Someone has to verify the part. Not “a bearing is in stock” but this bearing, matching this asset’s actual configuration, which may not match the drawing after two decades of modifications.
Someone has to confirm real availability, not the inventory count but what is physically on the shelf. If it is not there, someone has to move a supplier: quotes, callbacks, follow-up.
Someone has to complete the approval package, with the evidence attached, and chase it when it stalls.
And someone should capture what the veteran technician knew: the workaround, the torque value that is not in the manual, the reason this asset always fails in August. Most of the time, nobody does.
A work order documents that this work exists. It does not do any of the above. That is not a flaw in the product. It is a boundary of the category.
Three layers, and the gap between them
It helps to name the layers plainly.
The system of detection
SCADA, condition monitoring, BMS, historians. These systems surface the event. They tell you something changed, and they hold the raw signal data that explains what happened and when. They do not know your work process, your parts, or your approval chain.
The system of record
CMMS, EAM, and the ERP behind it. These hold work history, asset data, inventory positions, purchasing, and cost. They are the authority on what is true administratively. They do not watch the process in real time, and they act when a person enters something.
The coordination between them
Between detection and record sits everything described above: evidence gathering, diagnosis, part verification, supplier contact, approvals, closeout quality. Today, in almost every operation, that layer is made of people: phone calls, browser tabs, radio traffic, spreadsheets, inboxes, and the memory of your most experienced staff.
That works, until the experienced staff retire, the work volume grows, or the event happens at 2 a.m. The coordination layer is real. It is just unwritten, unmeasured, and carried entirely by humans switching between systems that were never designed to talk to each other about an active repair.
Why more fields and another dashboard do not close the gap
The instinctive fix is to extend what you have. Add fields to the work order. Add an integration. Add a dashboard that shows detection data next to work data.
Each of these helps at the margin, and none of them changes the nature of the gap.
More fields make the record richer, but a person still fills them in after the coordination happened. They document the fix more completely. They do not produce the fix.
Dashboards put information side by side, but a dashboard still waits for a person to look, interpret, and act. Visibility is not coordination. A screen showing the alarm next to the work order leaves the diagnosis, the part check, the supplier call, and the approval chase exactly where they were.
Integrations move data between systems, which is necessary plumbing. But syncing a record from one database to another decides nothing, verifies nothing, and moves no one.
The gap is not a data gap. It is a work gap. Closing it requires something that carries the work forward between systems, not something that displays more of it.
Why replacement is the wrong answer too
If the record cannot coordinate, the tempting conclusion is to replace it with something that can. For critical infrastructure, that conclusion fails on contact with reality.
The record must stay authoritative. Your regulatory posture, action history, cost accounting, and institutional memory live there. Any tool that asks you to move that history, or to maintain a second competing version of the truth, creates risk instead of removing it.
The investment is real. Utilities and operators have spent years, sometimes decades, configuring these systems around their assets and regulatory obligations. Rip and replace is a multi-year project with its own failure modes, undertaken to solve a problem that is not actually in the record.
The honest framing is complementary. SCADA and monitoring surface the event. The CMMS, EAM, and ERP hold work, asset, and supply data. What is missing is a layer that brings the evidence together, guides the repair, and handles the digital coordination across those systems, inside the customer’s rules. The record stays the record.
What a coordination layer must respect
If a coordination layer is going to sit in the middle of critical operations, it has to meet a specific bar.
Existing systems remain in place. The layer works with the CMMS, EAM, ERP, and monitoring stack you already run. It reads from them and, where permitted, writes back to them. It does not replace them or hold a competing master record.
Writeback is configured per customer. What gets written, to which system, in which fields, and under what conditions is your decision, set to match your governance, not a vendor default.
Operational connectivity is read-only. Connections to SCADA and control-adjacent systems observe. They never command. A maintenance coordination layer has no business writing to a control system, and any architecture that blurs that line should end the conversation.
Autonomy boundaries are customer-defined. What the layer may do on its own, what requires a named human approval, and what it may never do are rules you set, per action type, per site if needed. Autonomy is a dial you control, not a mode you accept.
Every action leaves a receipt. Every read, draft, writeback, supplier message, and approval is logged with what happened, when, on whose authority, and on what evidence. If the trail cannot support a formal review, the layer does not belong in a regulated operation.
Questions to ask any vendor, including us
AI maintenance coordination is becoming a crowded claim. Whoever you evaluate, these questions separate substance from demo.
Where does the evidence come from? Which of my actual systems does it read, through what connection, and what happens when a source is unavailable?
What actions can it actually take? Not what it recommends, but what it executes, in which of my systems, from what list of permitted actions.
Who approves? Show me how a human approval is required, recorded, and enforced, and how I change the boundary later.
What happens when facts change mid-repair? If stock is wrong or a supplier slips, does the system notice and re-plan, or wait for a person to catch it?
What does the action trail show? Ask to see a real trail for a completed action, end to end. If the answer is a summary rather than a log, keep asking.
Any vendor doing this work honestly will welcome all five.
Where AIMMS fits
EQUA AIMMS is built as that coordination layer, and only that. Detection stays with your monitoring systems. The record stays with your CMMS, EAM, and ERP. AIMMS brings the evidence together when an event occurs, guides the repair, and handles the digital coordination across those systems, inside boundaries you define, with a receipt for every action.
Your system of record is doing its job. The open question is who coordinates everything between the alarm and the closed work order. Today that is your best people, working across tabs and phone calls. It deserves a layer of its own.