How a maintenance program gets implemented

The hard part of a CMMS isn’t the software: it’s getting accurate data into it and getting the team to enter it without anyone having to chase them. Rollouts that go wrong almost never fail because of the tool; they fail because of the order in which things were done.

Here’s the order that works.

Before touching anything: three decisions

How far you want to manage. Just the technical work and its reports? Or also purchasing, budgets, and the client relationship? A narrow scope can be rolled out in weeks; one that crosses several departments requires prior agreements about who does what, and those agreements take longer than the configuration itself.

Who owns each piece of data. If there’s an ERP involved, this gets decided now, not later: the ERP owns customers, items, and price lists; the CMMS owns assets, interventions, and consumption. Without that agreed boundary, you end up with duplicate customers and fixes that undo themselves.

Who is the internal owner. Someone in-house has to own the project. They don’t need to be an IT person; they need to be able to make decisions and know the operation.

Phase 1: the asset inventory

It’s the most valuable work and the one that takes longest, so it pays to do it well and not do it in full.

You start with the critical assets: the ones that stop production or the service if they fail, and the ones with mandatory maintenance. For each one, the minimum useful data is where it is, what model it is, its serial number, when it was installed, and when its warranty ends. That last piece of data pays for itself: it’s very common to repair equipment still under warranty without knowing it.

In asset management you can add custom fields with their own type and unit, because the data describing a boiler isn’t the same as what describes an elevator. It’s worth grouping by model and family from the start: that’s what lets you configure something once for two hundred identical units.

The rest of the catalog comes later. Starting with the full inventory is the most repeated mistake, and the one that leaves the most projects half-done.

Phase 2: maintenance plans and frequencies

This is where the system starts working on its own. For each equipment family you define what needs to be checked — the checklist, with its fields and, where relevant, its minimum and maximum values — and how often.

Two things save a lot of work here. First, a maintenance plan can be attached to the asset, its model, its subfamily, or its family, and it resolves in cascade: you define it once for the whole family and only fine-tune it where a particular unit differs. Second, a single asset can have several frequencies at once — monthly is one thing, annual is another — which is how reality actually works.

With this configured, preventive maintenance generates its work orders on its own, first checking whether the day is a holiday and whether the technician is available.

Phase 3: how unplanned work comes in

Preventive maintenance is half of it. The other half is what shows up unannounced.

You need to decide where incidents come in from and unify it: the backend, the client access portal, or an email inbox the system converts into tickets. As long as there are three parallel channels — phone, WhatsApp, and email to different people — there won’t be a reliable backlog.

And you need to define the statuses an incident and a work order go through, with their maximum time and associated alerts. It’s a one-hour conversation that avoids months of ambiguity about what “in progress” actually means.

Phase 4: the field team

This is the phase that decides the project, and the one most often neglected.

The system is fed by the technician. If the app makes them lose time, logging gets postponed to the end of the day and stops being accurate. What works is starting with a small group of technicians and a small group of assets, over a few weeks, closing real work orders.

That trial always produces two things: configuration adjustments no one had foreseen, and, above all, the arguments to convince everyone else. A technician telling a colleague they no longer have to call the office to find out an asset’s history is more convincing than any training session.

It’s worth explaining from the start what the app solves in their day to day: the timer inside the work order, material consumption logged without paper, the client’s signature on screen, and working without a connection, which is what saves them from having to redo the work after coming up from the basement.

Phase 5: the warehouse and purchasing

This can be left until work orders are actually closing out, and that’s usually a good idea.

The warehouse starts to make sense once consumption is logged when the order closes, not before. From there you load items with their cost, minimum stock, and batches where needed, and the purchasing workflow when restocking is required.

Phase 6: reports, and back to the start

After a few months there’s history, and that’s when the part that justifies everything else begins. Reports — cost per asset, hours per technician, downtime, MTBF and MTTR, annual plan completion, anomalies — are used to correct what was configured at the start.

An asset that fails between inspections needs a higher frequency. One that never gives problems is probably over-maintained, and that costs money too. Without this phase, frequency gets decided once and is never revisited.

What makes a rollout fail

Starting with the full inventory. Six months loading data before seeing a result exhausts any team.

Configuring it without the people who will use it. A system configured in a meeting room collides with reality on the first day in the field.

Not closing the loop. If a technician logs an anomaly and nothing happens, they stop logging them. Rightly so.

Expecting it to fix the process. A CMMS doesn’t decide who handles what or with what priority. If that isn’t decided, the system will just record the same disorder with more precision.

If you’d like us to look at what a rollout would look like for you, you can request a demo or get in touch.