Automated maintenance systems: the operator control test

Automated maintenance systems should make missing work harder to hide. They should not merely move a neglected task from a clipboard into a nicer screen. I have built enough automation to know that software can complete every run and still be wrong, which is a mildly inconvenient feature for software marketed as automatic.

On one client workflow, usage data appeared to process normally. There was no dramatic crash and no obvious red banner. A logic error quietly stopped assigning one customer's usage correctly. The problem surfaced at month end, when the client tried to bill from the records and found that the system had been wrong for a whole month. They could not invent the missing usage, so they had to eat the cost.

That changed how I judge maintenance automation. A green job status is not proof that the maintenance promise was kept. My rule is that every consequential workflow needs an expected outcome, an owner, and evidence that the outcome happened.

Start with the maintenance promise

An automated maintenance system is not one product. It is the operating layer that connects requests, assets, schedules, decisions, work orders, people, vendors, and proof.

The first design question is not whether to buy sensors or replace the CMMS. It is: what must reliably happen for this asset or facility?

A useful promise sounds like this:

• Every urgent request is acknowledged and assigned within the agreed window.
• Every preventive task produces a completion record or an owned exception.
• Every failed inspection creates a decision, not just another notification.
• Every outside dispatch has an accepted owner, due time, and closeout record.
• Every safety-sensitive task follows the authorized procedure before work begins.

The U.S. Department of Energy's Operations and Maintenance Best Practices Guide frames operations and maintenance as a managed program with planning, measurement, and continuous attention. That is the useful buyer frame. The software supports the program. It does not own the promise.

I map that promise against the facilities and maintenance automation layer before choosing tools. If the team cannot name the promised outcome, automating the current process will usually make confusion arrive faster.

Keep one source of truth

Most maintenance environments already have more than one record surface. Requests arrive by email, phone, form, radio, sensor, spreadsheet, and vendor portal. The CMMS may hold work orders, while purchasing holds parts status and finance holds vendor approval.

The system needs a declared source of truth for each consequential fact:

This is why I treat maintenance as business process automation, not a collection of triggers. A trigger can create a work order. It cannot decide which record wins when an email, sensor, and technician disagree.

A good automation layer prepares the record, checks required fields, routes it, and reports exceptions. It does not create a second shadow database that operators must reconcile by hand later.

Automate the evidence before the authority

The safest early automation is usually evidence collection and routing.

For example, a system can:

1. Convert an approved request into a structured work order.
2. Match the request to an asset identifier.
3. Attach manuals, photos, prior failures, and open parts issues.
4. Route the work to the correct internal team or vendor.
5. Watch for acceptance, arrival, completion, and closeout evidence.
6. Escalate a missing event to a named operator.

That removes chasing without giving the system unlimited authority.

Condition data can improve timing, but a prediction is still an input to a decision. My predictive maintenance guide for operators uses the same distinction: a score can prioritize inspection, while the operating team still owns the maintenance decision and production tradeoff.

Safety-sensitive work needs an even clearer boundary. OSHA's control of hazardous energy standard defines procedures and responsibilities for servicing and maintenance where unexpected energization could cause harm. An automation may prepare the work package or verify that required fields exist. It should not quietly replace the authorized person's responsibility.

Design for the exceptions that actually happen

The happy path is the easiest part of maintenance automation. The useful design work begins when:

• A sensor event has no matching asset.
• The same request arrives through two channels.
• A technician completes work but omits required evidence.
• A vendor accepts the dispatch and then misses the arrival window.
• A part is substituted without updating the work order.
• A recurring task closes while the underlying condition remains unresolved.
• The CMMS is unavailable when an urgent request arrives.

Each exception needs four things: a detection rule, an owner, a response window, and a recovery step.

The CMMS operator control test matters here. Buyers should ask whether the system can expose missing records, duplicate work, rejected updates, and stale assignments without requiring somebody to inspect execution logs.

Outside vendors need the same treatment. My vendor dispatch and SLA tracking pattern keeps acceptance, due time, status, and evidence in one visible lane. Sending the email is not the outcome. A closed request with defensible evidence is the outcome.

Test for silent failure

A maintenance system can fail loudly, quietly, or honestly. Loud failure is uncomfortable but visible. Quiet failure is expensive. Honest failure is the goal because the system knows what proof is missing and tells the right person.

I test these controls before expanding a maintenance automation:

• Count reconciliation: Did every accepted input create one expected record?
• State reconciliation: Did every completed task reach the authoritative system?
• Age checks: Which requests, assignments, or vendor dispatches have stopped moving?
• Evidence checks: Which closeouts lack a technician, result, image, reading, or approval?
• Duplicate controls: Did retries create extra work orders or notifications?
• Permission checks: Can the workflow perform only the actions its role requires?
• Recovery tests: Can an operator safely replay, reassign, or close the exception?

NIST SP 800-53 includes controls for configuration management, inventory, monitoring, and accountability. I apply the same practical discipline to maintenance automation. Know what is running, what it may change, who owns it, and what evidence reveals drift.

The silent-failure lesson also appears in my accounting automation control test. Different department, same operating problem: a workflow that reports success while the business record is incomplete is not successful.

Rehearse recovery before rollout

I do not trust a maintenance lane until the team has seen it fail on purpose.

A useful drill includes:

1. Submit a valid request and prove the full path.
2. Submit a duplicate and confirm only one work order survives.
3. Remove a required asset identifier and confirm the request is held visibly.
4. Make the downstream system unavailable and confirm the input is preserved.
5. Miss a vendor acceptance window and confirm escalation reaches the named owner.
6. Complete work without required evidence and confirm the record cannot quietly pass.
7. Replay the failed event and confirm the final record is correct, not duplicated.
8. Use the manual fallback and reconcile it when the system returns.

This is not a technical demonstration. The maintenance lead should be able to explain what happened, what was protected, and what to do next.

If recovery requires the original builder to read code at midnight, the handoff is not finished. Operators need runbooks, access, alert ownership, and a visible stop path.

When not to hire us for this

You do not need a custom automated maintenance system when your current CMMS already supports the required routing and reports, and the real issue is that nobody uses the fields consistently. Fix the operating discipline first.

You also do not need sensors on every asset because predictive maintenance sounds modern. Start where downtime, inspection burden, repeat failure, or missing evidence creates a real business cost. A calendar and a well-owned work order can be the right answer for a stable, low-risk asset.

Custom work makes sense when requests cross several systems, exceptions are expensive, the CMMS lacks a necessary connection, or the team cannot prove that maintenance promises are being kept.

Use an operator buying test

Before buying automated maintenance systems, I want clear answers to these questions:

• Promise: What maintenance outcome must happen every time?
• Source of truth: Which system owns assets, work orders, approval, and completion?
• Trigger: Which events may create or update work?
• Authority: What may happen automatically, and what requires an authorized person?
• Exception: Who owns missing, conflicting, duplicate, or stale records?
• Evidence: What proves the work was accepted, performed, and closed correctly?
• Recovery: How does the team stop, replay, reassign, or use a manual fallback?
• Handoff: Who owns credentials, alerts, vendors, runbooks, and changes after launch?
• Measure: Which business result proves the system improved maintenance rather than producing more activity?

The best automated maintenance system is not the one with the most sensors or the busiest dashboard. It is the one where operators can see the promise, trust the record, catch missing work, and recover without guessing.