Choosing a CMMS: What Data to Keep and What to Check Before You Buy

A computerized maintenance management system is chosen once and then lived with for years, so the decision deserves more scrutiny than a feature comparison. The useful question is not which product carries the longest list of functions, but which one will hold the data your department actually relies on.

What the System Is Really For

A CMMS is the record of work. What was done, to which device, by whom, when and at what cost. Almost everything else a technology management service produces is derived from that record, including budget arguments, inspection readiness, recall response and evidence that planned maintenance happened.

Systems rarely fail because they lack features. They fail because the data inside them stops being true, and because nobody notices until a surveyor or an incident investigation asks a question the record cannot answer.

That is why the evaluation should begin with your own data model rather than with a vendor demonstration. A product that fits your fields and workflows will outperform a richer product that forces you to abandon them.

Deciding What Data You Will Keep

Before opening a single brochure, write down the fields your department would defend in an audit. The list is usually shorter than vendors expect and more specific than their standard configuration.

• A unique asset identifier, its location and the department accountable for it.
• Manufacturer, model and serial number, held separately so they can be searched.
• Risk classification, maintenance strategy and the source of the maintenance interval.
• Work order history with labour, parts, findings and the technician who signed it off.
• Documents that support the device: manuals, service reports, calibration certificates, acceptance records.
• Contract, warranty and software version details where those change what you are allowed to do.

Every field needs an owner and a moment in the workflow where it is updated. A field that is filled at installation and never touched again is a liability, because it will be quoted as fact long after it has stopped being one.

The Functions That Decide the Purchase

Most systems can store an asset list and print a work order. The differences that matter appear when you look at how the system behaves under real conditions, with incomplete information and a technician standing at a bedside.

Read that table as a set of tests to run in a sandbox, not as a list of promises to collect. Vendors answer questions optimistically, and a configured demonstration with your own sample records reveals far more than a scripted tour.

Interfaces and Data Ownership

A CMMS is never the only system in the building. Finance holds the purchase record, procurement holds the contract, the clinical system holds the location of the patient and the security team holds a growing list of connected devices. The maintenance system has to exchange information with at least some of them.

Ask what the interface actually transfers, how often, and what happens when a record fails to match. A nightly file that silently drops unmatched rows is worse than no interface at all, because it creates two versions of the truth that diverge slowly.

Data ownership belongs in the contract, not in a conversation. You should know who owns the records, how you get a complete export, in what format, and at what cost if you leave. The same question applies to attachments, which are often the hardest thing to migrate.

Cost Beyond the Licence

Licence fees are the easiest line to compare and usually the smallest part of the total. Implementation, data migration, interface work, validation, training and the internal time to clean an existing register all sit outside the subscription and all consume the same budget.

It is worth costing the first year honestly, including the hours your own technicians will spend on configuration instead of maintenance. A system that demands more administrative effort than it removes will be quietly abandoned, and the licence will keep being paid.

Running a Pilot Before Commitment

Where a vendor permits it, run a short pilot on one device family in one area. Load real records, close real work orders, produce one report that a manager would actually use and one that a surveyor might ask for.

The pilot answers the questions that demonstrations cannot: how long a work order takes to close, whether the search finds a device by the number printed on its label, and whether the people doing the work find the interface tolerable at the end of a shift.

A Decision You Can Defend

Choose the system whose data model matches the way your department already reasons about equipment, then insist that the fields you specified survive implementation unchanged. A medical device inventory that is accurate and a preventive maintenance schedule that reflects manufacturer instructions are worth more than any additional module.

The measure of a good purchase is not the demonstration. It is whether, a year later, the record can still answer a simple question about a single device without anyone having to reconstruct it from memory.