Skip to content
GMAO CLOUD
en

Integrating a CMMS with your ERP: how to approach it

What a CMMS covers that the ERP doesn't, how data is split between the two systems, and what criteria to use to decide the integration architecture.

Updated on 6 min read

  • Integrations
  • ERP
  • Maintenance management

The question almost always comes up at the same moment: the company already has an ERP that works, has run it for years and has no plans to change it, but maintenance is still managed with spreadsheets and paper work orders. Does that need another piece of software, or should the ERP handle it?

The short answer is that an ERP and a CMMS don’t compete: they cover different ground, and the real question is where to draw the line between them. The long answer is this article.

What an ERP does, and what it leaves out

An ERP —an integrated management system— was built to handle accounting, invoicing, purchasing, inventory and production. It does that well, and it’s where the customer master, the item master and the price lists should live.

What an ERP usually doesn’t solve is the technical work on the equipment itself. Specifically:

  • The asset record as history. Not the item that was purchased, but the equipment that’s installed: where it is, what serial number it has, what’s been done to it, what anomalies are still open, how much it’s cost so far.
  • Maintenance frequency. An ERP doesn’t generate the semiannual check for two hundred pieces of equipment on its own, nor does it check whether the due date falls on a public holiday.
  • Field work. This is the clearest gap. ERPs are desktop or browser applications built for an office, and maintenance happens on a rooftop, in a basement, or in a warehouse with no signal.
  • The relationship with the service customer. Who reported it, at what priority, what was promised, and what can be shown afterward.

Those four things are, precisely, what a CMMS does.

The boundary: who owns each piece of data

This is the decision that determines whether the integration will actually work, and it comes before any technical question.

The ERP owns customers, items and price lists. The CMMS owns assets, interventions and consumption. Each piece of data has exactly one place where it’s created and edited; the other system receives it and doesn’t touch it.

When that rule isn’t agreed on, the same thing always happens: the same customer ends up existing twice under two different codes, someone corrects an item in the wrong system, and the next sync undoes the correction. It’s not a software failure, it’s a design failure.

What information travels, and in which direction

Once the boundary is clear, the usual flow sorts itself out.

From the ERP to the CMMS come the master records: customers, addresses and items. That’s what avoids maintaining two separate catalogs of the same thing. That’s how the Sage X3 connector works, for example, importing those three blocks.

From the CMMS to the ERP go closed work orders, with their booked hours and consumed materials, which is exactly what the ERP needs for invoicing. The SAP connector exports orders for the invoicing and costing workflow; the Business Central and Navision connectors cover both directions.

The important nuance is that not every connector does the same thing. It’s worth checking the actual scope before assuming a given piece of data will simply flow through. The full catalog is on the integrations page, listing what each one exports and imports.

What a CMMS delivers that you notice from day one

These are the capabilities that lead a company with an ERP to add a CMMS, ranked by how quickly they’re noticed.

Identifying equipment in the field. Every asset with its QR code: the technician scans it and has the record, history and documentation right there without calling the office. Asset management also supports custom fields per equipment type, with their own units, because the data that describes a boiler isn’t the data that describes an elevator.

Working without signal. The technician app stores work orders, assets and documents on the device, and actions taken offline sync once a signal is recovered. It’s the functionality no desktop ERP covers.

Automatic preventive maintenance. The check routine attached to the asset, its model or a whole family, with its frequency, generating preventive work orders that also check public holidays and technician availability.

Documentation with expiration dates. The document manager attaches documents to almost any entity in the system, with an expiration date and a daily check of what’s about to lapse. It includes certificates with their number, scope, issuer and holder.

Customer access. Their own portal to open incidents, follow work orders, download reports and see their upcoming preventive visits.

Maintenance analytics. The reports an ERP doesn’t have because it isn’t its job: downtime, MTBF and MTTR, cost per equipment, hours per technician, annual preventive plan.

The subcontracting case

There’s a scenario that doesn’t quite fit the ERP-CMMS model and is worth mentioning, because it’s increasingly common: the company that contracts maintenance and the one that carries it out each run their own system.

The usual fix is files: one exports, the other imports, someone checks nothing is missing. It works until it doesn’t, and when it fails nobody knows which side lost the data. GMAO Cloud has a direct connector between installations, in both directions —from customer to subcontractor and back—, so work passes from one system to the other without an intermediate file and without having to reconcile two lists by hand.

The real advantage isn’t the time saved: it’s that the work order keeps its traceability as it crosses the boundary between the two companies, with its times and its consumption, instead of turning into a line on a delivery note.

Three criteria for deciding the architecture

It should be modular. The CMMS needs to be able to slot in alongside the ERP as one more piece, without requiring you to replace what already works. If the only way to use it is to migrate the ERP, the project gets ten times more expensive.

It should be adaptable. What you need today isn’t what you’ll need in three years. It’s worth having generic channels —REST API, SOAP, SQL, CSV, FTP— in addition to the specific connectors, because those are what cover the cases nobody foresaw.

Traceability shouldn’t break in the handoff. If data travels but loses who did what and when along the way, the integration has turned a record into a number. What gives the history its value is being able to reconstruct the intervention, not just its cost.

Start small

The integration that goes well almost always starts the same way: bring in customers and items from the ERP, send closed work orders back once a day, and leave the rest for once that part has been running for months without anyone needing to watch it.

If you’d like us to look at how it would fit with your current ERP, you can write to us via contact or request a demo.

← All articles

Shall we look at it with your way of working?

Leave your details and we will get in touch to see whether we fit. No commitment, no lock-in period.

We reply within one working day.