CMMS implementation and selection: seven phases, a scorecard, and the data build that decides the result
A CMMS implementation as seven phases with the trap in each, selecting against weighted criteria with scenarios run on the plant's own data, the design that comes before configuration, the data build and why it cannot be a copy, where configuration ends and customisation begins, and what go-live actually is. With a free selection scorecard and migration checklist.
Key takeaways
- A CMMS implementation is a maintenance project that happens to involve software. The software is chosen in the second of seven phases and the result is decided in the fourth, where the hierarchy, the codes, the plans and the history are built.
- Selection is done against weighted criteria with scenarios run on the plant's own data, not against a demonstration. The scorecard records the reasons, which is what the project reads a year later when someone asks why.
- Configure before you customise. What the design needs done by configuration a trained administrator can maintain. Customisation is named, costed, and paid for again at every upgrade.
- Migration is not a copy. The asset hierarchy is rebuilt to the design, the master data is cleaned, the failure codes are agreed, and the history worth keeping is loaded while the rest is archived readable.
- Go-live is the start, not the finish. The system is working when the data coming out of it is trusted, which is months later, and the project is staffed to that point.
Two sites buy the same CMMS in the same year. Three years later one runs its maintenance from it: the backlog is real, the schedule comes out of it, the history is coded and the reliability engineer trusts the MTBF it reports. The other has a system that generates PMs nobody closes, a hierarchy copied from the old system with its duplicates intact, and a spreadsheet beside it where the planning actually happens. The software is the same. The difference is the implementation, and in particular the data.
A CMMS implementation is a maintenance project that happens to involve software. It has seven phases, the software is chosen in the second and the result is decided in the fourth, where the hierarchy, the codes, the plans and the history are built. This guide sets out the phases and the trap in each, how the selection is scored so that the reasons survive, what has to be designed before anything is configured, what the data build involves and why it cannot be a copy, where configuration ends and customisation begins, and what go-live actually is. A selection scorecard with the migration checklist comes with it. The CMMS versus EAM piece covers which kind of system to be selecting at all.
Free download
CMMS selection scorecard
A weighted scorecard with twelve criteria, what to look for and the scenario to ask for against each, columns for three candidates with the weighted totals worked out from what you enter, and the migration checklist and the phases on sheets of their own.
The seven phases
The phases run in order and each produces something the next starts from. The case says what good looks like. The selection scores candidates against it. The design decides the hierarchy, the codes and the workflows before anything is configured. The data build makes the registers, the plans and the history the system will run on. Configuration and integration build the design. Testing walks real work through it and training teaches each role their own part. Go-live cuts over and stabilisation watches the measures until the data is trusted. The table carries the trap in each, and the traps are not exotic. Each is a phase done out of order or done as a copy of what was there.
1Case and scope
A one-page statement of what good looks like, and what is out of scope
The trap
A case written as a software feature list rather than a maintenance outcome
2Requirements and selection
A scored selection with the reasons recorded
The trap
Scoring the demonstration instead of the scenario; letting the vendor choose the data
3Design
A design document the configuration is built from and tested against
The trap
Configuring as you go, so the design is whatever the consultant did first
4Data build and migration
A loaded system that reconciles to the registers it came from
The trap
Treating migration as a copy. Bad data in the old system is bad data with a new interface
5Configure and integrate
A configured system in a test environment, with the integrations exchanging real records
The trap
Customising what should have been configured, which costs on every upgrade
6Test and train
Signed test scenarios, trained users, written procedures
The trap
Training on the software rather than on the plant's process in the software
7Go live and stabilise
Work managed in the new system, the backlog under control, the old system read-only
The trap
Declaring success at go-live. The system is working when the data coming out of it is trusted, which is months later
→ The software is bought in phase 2 and the result is decided in phase 4
| Phase | What it does | What it produces | The trap |
|---|---|---|---|
| Case and scope | Say what the system is for in the plant's own terms: the work it has to manage, the data it has to hold, the reports it has to produce, the systems it has to talk to | A one-page statement of what good looks like, and what is out of scope | A case written as a software feature list rather than a maintenance outcome |
| Requirements and selection | Turn the case into weighted criteria, score the candidates against them with real scenarios and the plant's own data, and check the references | A scored selection with the reasons recorded | Scoring the demonstration instead of the scenario; letting the vendor choose the data |
| Design | Decide the hierarchy, the numbering, the codes, the work order types, the workflows, the roles and permissions, and the integration points, before anything is configured | A design document the configuration is built from and tested against | Configuring as you go, so the design is whatever the consultant did first |
| Data build and migration | Clean, structure and load the asset register, the hierarchy, the failure codes, the bills of materials, the job plans, the maintenance plans, the stores catalogue and the history worth keeping | A loaded system that reconciles to the registers it came from | Treating migration as a copy. Bad data in the old system is bad data with a new interface |
| Configure and integrate | Build the design: screens, workflows, reports, mobile, the links to the ERP, the historian and the document system | A configured system in a test environment, with the integrations exchanging real records | Customising what should have been configured, which costs on every upgrade |
| Test and train | Walk real work through the system end to end: a notification to a closed work order, a PM generation, a stores issue, a month-end report. Train every role on their own work | Signed test scenarios, trained users, written procedures | Training on the software rather than on the plant's process in the software |
| Go live and stabilise | Cut over on a planned date with the old system frozen, support on the floor, and the measures watched daily for the first months | Work managed in the new system, the backlog under control, the old system read-only | Declaring success at go-live. The system is working when the data coming out of it is trusted, which is months later |
Selecting against the plant, not the demonstration
A vendor's demonstration shows the product at its best on the vendor's data. A selection scores the product on the plant's own work. The method is to turn the case into weighted criteria, write a scenario for each that the plant would recognise, give every candidate the same extract of the plant's data in advance, and score what each does with it. Walk a breakdown from the operator's notification to a coded, closed work order with history. Build next week's schedule from the real backlog and read the compliance report after. Load the hierarchy extract and move a motor between locations with its history intact. Reserve a critical spare from a work order.
The table gives the twelve criteria on the scorecard, with default weights that a site adjusts to its own case and the scenario to ask for under each. The scores are recorded with the reasons, because the selection will be questioned a year later by someone who was not in the room, and because the reasons are the first draft of the design.
| Criterion | Weight | What to look for | The scenario to ask for |
|---|---|---|---|
| Work management | 15 | Notification to work order to close-out in the plant's own flow, with planning fields, status control and failure coding at close | Walk a breakdown from the operator's report to a coded, closed work order with history |
| Planning and scheduling | 12 | A backlog that can be filtered and prioritised, job plans with materials and labour, a weekly schedule the supervisor can work from, schedule compliance measured | Build next week's schedule from our backlog and show the compliance report after |
| Asset hierarchy and master data | 12 | Functional locations and equipment as separate things, a hierarchy to ISO 14224 depth, failure codes per equipment class, change control on master data | Load our hierarchy extract and show a motor moving from one location to another with its history intact |
| Preventive maintenance | 10 | Time, meter and condition triggers, nested plans, PM compliance measured, route-based tasks | Create a 4,000 hour gearbox oil change triggered from a historian meter |
| Inventory and procurement | 8 | Stores catalogue linked to bills of materials, reservations from work orders, min and max, reorder, the link to the ERP purchasing | Reserve a critical spare from a work order and show the stock movement |
| Mobile | 8 | Work orders, readings and photos on a device, offline where the plant has no coverage, no re-keying | Close a work order on a phone with no signal and show it arriving when it reconnects |
| Integration | 10 | Published interfaces to the ERP, the historian, the document system and the condition monitoring tools, with the data flows the design needs | Show a historian alarm raising a notification, and a work order's costs arriving in the ERP |
| Reporting and analysis | 8 | The maintenance KPIs out of the box, data accessible to the site's own reporting tools without an export | Show MTBF by equipment class for the last year from our loaded data |
| Configuration against customisation | 5 | What the design needs done by configuration a trained administrator can maintain, with customisation named and costed | Which of our requirements need code, and what happens to that code at the next upgrade? |
| Data migration tooling | 4 | Load templates, validation, a rehearsal environment, reconciliation reports | Show the load of our asset register extract and the validation errors it raises |
| Vendor and support | 4 | Local support in the plant's hours, a roadmap, references in the same industry at the same scale | Name three sites like ours we can call |
| Cost over ten years | 4 | Licences, hosting, implementation, integration, customisation, upgrades, support and the internal effort, over the life | The ten year total, with the assumptions written down |
Give every vendor the same extract of your data a week before, and score what they do with it, not what they show you.
Design before configuration
The design is the set of decisions the configuration is built from, and it is written down before the first screen is configured: the asset hierarchy and its depth, the numbering, the equipment classes and the failure codes per class, the work order types and the statuses each passes through, the priority scheme, the planning fields that are mandatory at each status, the roles and what each may do, the reports, and the integration points with the ERP, the historian and the document system. Operations, maintenance, reliability, stores and finance are all in the design, because the system serves all of them and a design done by one of them is undone by the others at go-live.
Configuring as you go produces a system whose design is whatever the consultant did first, and whose reasons left with the consultant. The design document is also what the testing is written against: a scenario passes when the system does what the design says, not when the consultant says it works.
The data build
This is the phase that decides the result, and it is the one most often planned as a copy. The old system's hierarchy has duplicates, orphans and equipment at the wrong level. Its master data has blanks in the fields that matter. Its failure codes were never used because there were two hundred of them. Copying all of that into the new system gives the old problems a new interface. The data is built instead: the hierarchy rebuilt to the design, the master data cleaned and completed against the engineering asset register, the failure codes agreed with the supervisors who will use them, the bills of materials and job plans built for the critical equipment first, the maintenance plans loaded with their last-done dates so the first cycle generates on the right day.
History is the hard decision. Closed work orders for the critical equipment, where they carry failure codes, are worth loading, because the reliability analysis needs them. The rest is archived in a form that can still be read, which is cheaper than loading it and safer than deleting it. The decision is made per equipment class, written down, and the archive is tested before the old system is switched off. The table is the migration checklist, with the state each item has to be in before cut-over. Master data covers why the build matters to the schedule afterwards.
| Item | What has to be done | Ready when |
|---|---|---|
| Asset hierarchy | Rebuilt to the design, not copied. Functional locations and equipment separated, to ISO 14224 depth, every maintainable item with a class | Reconciles to the engineering asset register |
| Equipment master data | Make, model, serial, ratings, criticality, the datasheet reference, the parent location | No blanks in the mandatory fields; duplicates merged |
| Failure codes | Problem, cause and remedy codes per equipment class, from ISO 14224 or the site's own, short enough to be used | Agreed with reliability and the supervisors before load |
| Bills of materials | The spares against each equipment, linked to the stores catalogue | Critical equipment complete; the rest built over the first year |
| Job plans | The standard task lists with labour, materials, permits and documents, for the recurring work first | The top PM and corrective jobs by hours covered at go-live |
| Maintenance plans | The PM schedule with its triggers, loaded with the last-done dates so the first cycle generates correctly | Every plan generates its first work order on the right date in the rehearsal |
| Stores catalogue | Part numbers, descriptions, bins, min and max, suppliers, linked to the bills of materials | Counted and reconciled at cut-over |
| Open work | Open notifications and work orders, carried across with their status and planning | Nothing open in the old system after cut-over |
| History | Closed work orders for the critical equipment, with failure codes where they exist; the rest archived readable, not loaded | Decided per class, written down, and the archive tested |
| People and roles | Users, crafts, crews, cost centres, permissions by role | Every role tested on their own scenarios |
Bad data in the old system is bad data with a new interface. Build the registers, do not copy them.
Configure, integrate, and customise last
Configuration is using the product's own options to build the design: fields, screens, workflows, codes, reports, permissions. Everything configured survives an upgrade. Customisation is code the product does not contain, and it is reworked, retested and paid for at every upgrade for the life of the system. A requirement that needs customisation is first questioned, because the process can often change more cheaply than the software, then named, costed over ten years and approved as a customisation rather than slipped in as configuration. The scorecard has a criterion for it, because the honest vendors will say which requirements need code and the others will not.
Integration is where the system meets the rest: costs to the ERP, meter readings and condition alarms from the historian, documents from the document system, purchase orders back. Each interface is a design decision with a data flow, an owner on each side and a test with real records, and the software for 24/7 operations piece covers what those interfaces need to survive.
Test, train, cut over, stabilise
Testing walks real work through the system end to end: a notification to a closed work order, a PM generation across a month, a stores issue and its cost arriving in the ERP, the month-end report. Each scenario is written from the design and signed by the people who will do that work. Training is by role on that role's own scenarios, on the plant's process in the system, not on the software's menus. A supervisor is trained to approve the work their crew raises, not to use the approval screen.
Cut-over is a planned date with the old system frozen the week before, the final data loads reconciled, and support on the floor for the first weeks. Stabilisation is the months after, when the measures are watched daily: the backlog, the PM compliance, the work orders closed with codes, the stores reconciliation. The system is working when the data coming out of it is trusted, and the project is staffed and funded to that point rather than to the go-live date. Declaring success at go-live is the last trap and the most common.
Where it fails
- A case written as a feature list, so the selection scores features and the design has no outcome to serve.
- The demonstration scored instead of the scenario, on the vendor's data instead of the plant's.
- Configuring from the first week, so the design is whatever was done first and the reasons left with the consultant.
- The hierarchy and the master data copied across with their duplicates and blanks intact.
- Two hundred failure codes, agreed with nobody, used by no one.
- Customisation where configuration would have done, paid for again at every upgrade.
- Training on the software's menus rather than the plant's process in the system.
- Support withdrawn at go-live, and the spreadsheet back beside the system within the quarter.
Common questions
What is a CMMS implementation?
The project that takes a plant from its current way of managing maintenance to a computerised maintenance management system, or a new one: the business case, the selection, the design of the hierarchy, codes and workflows, the data build and migration, the configuration and integration, the testing and training, and the cut-over and stabilisation. Most of the effort is in the data and the process, not the software, which is why the same product succeeds on one site and fails on the next.
How do you select a CMMS?
Write down what the system is for in the plant's own terms, turn that into weighted criteria, and score each candidate against them using scenarios run on the plant's own data: a breakdown from the operator's report to a coded closed work order, next week's schedule built from the real backlog, a PM triggered from a historian meter. Check references at sites of the same kind and scale. Record the scores and the reasons. The scorecard with this guide carries twelve criteria with default weights to adjust.
What is the difference between configuration and customisation?
Configuration is setting up the product's own options: fields, screens, workflows, codes, reports, permissions, using the tools the vendor supplies and supports through upgrades. Customisation is writing code the product does not contain, which the vendor does not support and which has to be reworked, retested and paid for at every upgrade. A good design is met by configuration wherever it can be. Where customisation is unavoidable it is named, costed over ten years and approved as such.
How is data migrated to a new CMMS?
By building, not copying. The asset hierarchy is rebuilt to the design, usually to ISO 14224 depth with functional locations and equipment separated. The equipment master data is cleaned and completed. Failure codes are agreed per equipment class. Bills of materials, job plans and maintenance plans are built for the critical equipment first and loaded with their last-done dates. Open work is carried across. History is loaded for the critical equipment where it is coded and archived readable for the rest. Each load is rehearsed and reconciled to the register it came from before the cut-over.
How long does a CMMS implementation take?
It depends on the state of the data more than the size of the plant. The software can be configured in weeks. Rebuilding a hierarchy, cleaning master data and building plans for a plant that never had them properly takes months, and that work cannot be bought from the vendor because it needs the plant's own engineers and supervisors. A project plan that allots the data build the same time as the configuration has not looked at the data.
What goes wrong in CMMS implementations?
The same things, repeatedly. The case is written as a feature list rather than a maintenance outcome. The selection scores the demonstration. The design is done by configuring as you go. The data is copied rather than built, so the old system's problems arrive with a new interface. The product is customised where it should have been configured. Training is on the software rather than the plant's process in it. And success is declared at go-live, with the support withdrawn before the data is trusted.
Key terms
Plain-language definitions from our glossary for the concepts this article leans on.
Standards and further reading
- ISO 14224:2016 Collection and exchange of reliability and maintenance data for equipment (ISO)
- ISO 55001:2024 Asset management system requirements (ISO)
- IEC 81346-1:2022 Industrial systems, installations and equipment: structuring principles and reference designations (IEC)
- Best practices, metrics and guidelines for maintenance and reliability (SMRP)
- BS EN 13306:2017 Maintenance: maintenance terminology (BSI)
Related case studies and tools
Related reading
Working through something like this?
See how we approach these initiatives, or tell us what you are dealing with.