CMMS Integrations: What Should Connect and Why?

A CMMS can connect to almost anything. That does not mean it should. Integration creates value when information crossing a system boundary changes maintenance work or lets another system use maintenance information appropriately.

The first question is not whether the CMMS integrates with the ERP.

What truth belongs in each system, and what event requires that truth to cross the boundary?

Integration begins with authority

Different systems can hold different responsibilities: spatial systems for geometry, the CMMS for maintenance activity and work history, request systems for customer service requests, financial systems for accounting, and operational systems for runtime information.

Decide those responsibilities before designing an interface.

Connect systems after deciding what each system is allowed to be right about.

Authority Before Interface

Authority Before Interface is a CMMSBuyersGuide framework. For each integration identify each field before discussing API, file or middleware.

Object
Authoritative system
Consuming system
Trigger
Data and meaning transferred
Direction
Timing
Confirmation
Exception owner

One object can contain several truths

Pump P-104 can exist in multiple systems. A spatial system may own its geometry, the CMMS its maintenance hierarchy and history, and the ERP its financial information.

This extends the concept in CMMS versus ERP. An asset can carry physical truth, maintenance truth, spatial truth, financial truth and operational truth, and different systems can legitimately own different meanings.

Shared identity does not require shared authority.

Start from the maintenance event

Instead of saying “we need ERP integration,” describe the event. A technician uses Bearing B-17 on WO-1048. The CMMS may need work cost, part consumption and asset history. The ERP may need the corresponding enterprise transaction. Now the integration requirement has meaning.

Integrate the consequence, not the software category.

Event-to-Truth

Event-to-Truth is a CMMSBuyersGuide framework.

EVENT → MAINTENANCE CONSEQUENCE → ENTERPRISE CONSEQUENCE → AUTHORITIES → TRANSFER → CONFIRMATION

What happened?
What changed for maintenance?
What changed elsewhere?
Who owns each resulting truth?
What crosses?
How is success confirmed?

GIS

GIS and CMMS integration may support asset location, map selection, work creation, spatial context or linear assets. Do not reduce the requirement to whether a map is visible.

The Identity Change Test

Take a GIS-managed asset. Split, merge, rename, retire or replace it. Then ask:

Which system initiates the change?
What identifier survives?
What happens to open work?
What happens to history?
What happens if integration fails halfway through?

SCADA and runtime systems

Operational systems may know runtime, state, process values or alarms. The CMMS may need selected information to trigger maintenance or provide context, as discussed in the predictive maintenance guide. Do not replicate telemetry merely because it is technically available.

Move the information needed for the maintenance decision, not every value the source system can produce.

Information Minimum is a CMMSBuyersGuide framework: what is the minimum information required to create the intended maintenance consequence? Use sufficient information rather than maximum information.

ERP and finance

Ask what crosses the boundary: purchase request, purchase order, receipt, part issue, labor, work cost, project or vendor. Then identify who creates it, who approves it, who owns status and who confirms completion.

Where parts and storeroom transactions are involved, work through the behavior described in the CMMS inventory guide.

Synchronization without authority can create two systems that disagree more efficiently.

Customer and request systems

A request can originate outside the CMMS and create maintenance work without turning the CMMS into the customer-service system.

What identifier links request to work?
What status returns?
Who communicates closure?
What happens when maintenance discovers additional work?

Documents

Do not integrate repositories simply to duplicate files. Decide whether the CMMS needs a copy, a link, a version, metadata, read access or a controlled document, and identify which system owns the current version.

Integration Purpose

Integration Purpose is a CMMSBuyersGuide framework. Every integration should have an explicit purpose. If nobody can name it, reconsider the integration.

Create work
Enrich work
Change maintenance state
Consume resource
Preserve history
Support decision
Return status
Financialize event
Synchronize identity

Interface is not integration

An API establishes a communication mechanism. It does not establish that objects map, that authority is clear, that events trigger correctly, that exceptions recover or that history remains coherent.

API availability answers how systems might communicate. Integration design answers what the communication means.

Integration Contract

The Integration Contract is a CMMSBuyersGuide technical and operational framework, not a legal contract. For each interface document:

Source
Destination
Object
Authority
Trigger
Payload
Direction
Frequency
Acknowledgment
Error behavior
Retry
Owner
Audit and trace

Timing follows consequence

Integration can be real time, near real time, scheduled batch or a manual controlled transfer. Do not default to real time. Ask how quickly the maintenance consequence needs to exist.

Integration speed should follow consequence speed.

Failure is part of integration design

Test what happens when the ERP rejects a transaction, GIS is unavailable, the API times out, a duplicate message arrives, the source object disappears, authentication expires or a payload is incomplete.

An integration is not fully designed until failure has an owner.

Exception Ownership is a CMMSBuyersGuide framework. For each failure determine detection, visibility, retry, manual recovery, owner and reconciliation. Avoid silent divergence.

Somerville requires integration planning

Somerville requires the selected proposer to facilitate requirements gathering meetings with relevant City staff, submit an integration plan for each requested system describing how data will be shared on an ongoing basis, obtain City approval before proceeding, and deliver a deployed integration solution. It also states that the final integration solution for each system or source will be defined based on the proposer response and the final scope of the work.

Integration belongs in the implementation boundary and the commercial boundary.

The integration demo

Use a consequence chain, then ask the vendor to show the trace.

WO-1048 requires Bearing B-17.
The technician issues the part.
Maintenance history and cost update.
The required enterprise transaction is created.
The receiving system rejects it.
The CMMS exposes the failure.
The error is corrected.
The transaction retries.
The systems reconcile.

The Trace Test is a CMMSBuyersGuide framework. Follow an important maintenance event forward into every affected system, then follow the resulting enterprise record backward to the originating maintenance event.

A good integration lets you explain where an important transaction came from and where it went.

Not everything has to integrate at go-live

Classify integrations as go-live critical, early phase, later value or optional.

AlexRenew listed its business systems as potential points of integration, including SCADA, financials, construction, laboratory, timekeeping, LIMS and procurement, and stated that it will evaluate and decide on integrations after selection.

Integration architecture can be complete before every integration is built.

Integration Necessity

Integration Necessity is a CMMSBuyersGuide framework. Ask whether maintenance can operate safely and correctly without this integration at go-live. If it cannot, the integration is go-live critical. If it can, identify the manual bridge, the risk it creates and the value automation would add, then phase deliberately.

Carry those decisions into the implementation plan and the data migration plan.

Final perspective

CMMS integration is about preserving coherent truth while maintenance events cross system boundaries.