Criteria for choosing an adaptable ERP

Integrated management systems — ERPs — emerged to handle accounting, invoicing, purchasing, inventory, and production planning in one place, instead of one program per department. That’s still their job, and they do it well.

What’s changed is the expectation. Today they’re also asked to talk to everything else, and that’s where the ones that adapt part ways from the ones that force you to adapt. Here are the criteria that matter, and why maintenance is the case that tests them best.

1. Being comprehensive

Being able to cover the company’s areas and departments without leaving gaps that need patching with spreadsheets. It doesn’t mean doing everything: it means that whatever it does, it does with the same data and without duplicating it.

The practical test is simple: ask how many times a new client gets typed in from the moment they come in to the moment they get invoiced. If the answer is more than once, the system isn’t as comprehensive as it looks.

2. Being modular

Being deployable in parts and able to grow afterward. That’s what lets you start with what’s urgent without buying, all at once, functionality you won’t use for another two years.

Here it’s worth asking an uncomfortable and very revealing question: what happens when you need something that’s in another module. If the answer is a contract extension every time a new need comes up, the real cost of the system isn’t the one in the initial quote.

3. Being adaptable

This is the criterion that encompasses the other two. Adaptable means it supports specific modules alongside the standard ones, to cover what each company actually needs without turning it into a custom build that’s impossible to maintain.

And within this criterion lies the connection between an ERP and maintenance.

Why maintenance is the acid test

Almost no ERP handles maintenance well, and not out of neglect: it simply isn’t its territory. Specifically, it leaves out four things.

The asset record as a history. Not the purchased item, but the installed unit: 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.

Frequency. An ERP doesn’t generate the semiannual inspection for two hundred units on its own, nor does it check whether the due date falls on a holiday or whether the technician is on vacation.

Field work. This is the clearest gap. ERPs are built for an office, and maintenance happens on a rooftop, in a basement, or in a warehouse with no signal.

The relationship with whoever receives the service. Who reported it, at what priority, what was promised, and what can be proven afterward.

A CMMS covers exactly that, which is why it fits as a specific module alongside the ERP instead of competing with it. It’s covered in more detail in how the integration is approached.

The boundary: who owns each piece of data

This is the decision that determines whether the integration works, 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 a single place where it’s created and edited; the other system receives it and doesn’t touch it.

It makes sense if you think about who creates each thing: a new client is born in the sales process, not in maintenance; a spare part gets consumed when a technician opens the box, not when someone invoices it.

Without that agreed boundary, the same thing always happens: the same client ends up existing twice under two codes, someone corrects an item in the wrong system, and the next sync undoes the correction. It’s not a software bug; it’s a design flaw.

What to ask about integrations

The question “do you integrate with X?” doesn’t help, because the answer is always yes. The ones that do are these.

What data travels, and in which direction? Not every connector does the same thing. Some only bring in master data — customers, addresses, items — and send nothing back; some export orders for invoicing but don’t import anything. GMAO CLOUD’s integrations catalog lists the scope of each one: for example, Sage X3 imports customers, addresses, and items, but does not export work orders.

How often? Real time is almost never needed. Closed orders arriving every night is usually enough, and it’s far cheaper to maintain.

What if my system isn’t on the list? That’s the most common case. What matters then is that generic paths exist: REST API, SOAP, direct database access, CSV or FTP exchange. Those cover the cases nobody anticipated, including fifteen-year-old custom systems.

Who resolves conflicts? There will be a duplicate client and an item with no code. It’s worth deciding beforehand who looks into it and by what rule.

What not to do

Migrate the ERP just to be able to do maintenance. It’s an expensive project, with a long learning curve and risk to the invoicing process. If the ERP works, the sensible move is to leave it and add the missing piece on top.

Try to sync everything in both directions. It’s the fastest way to turn a project that could be simple into a complicated one. Start by bringing in customers and items and sending closed work orders with their hours and consumption, and leave the rest for once that part has been running for months without anyone needing to look at it.

Assume traceability survives the jump. If the data travels but who did what and when gets lost along the way, the integration has turned a record into a figure. What gives history its value is being able to reconstruct the intervention.

And a note on project ordering, because the question always comes up: it’s rarely a good idea to tackle the ERP and maintenance at the same time. They compete for the same people and the same organizational patience. The sensible thing is to start with whichever solves the problem that hurts most today and leave the other for once the first has been running on its own for months.

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