The first four weeks with a CMMS

Most rollouts that go wrong do so in the first month, and almost always by trying to cover too much: someone decides to load the full inventory, it takes half a year, and the team loses steam before seeing any result.

Here’s an alternative four-week plan. It won’t leave the system finished — that takes months — but it leaves something genuinely working, which is what makes the project survive.

Before you start: two decisions

How far you want to go. Just record the technical work and pull reports, or have the system reach all the way to purchasing and admin? The first can be rolled out in weeks; the second requires prior agreements that take longer than the configuration itself.

Who owns the project. Someone in-house who knows the operation and can make decisions without calling a meeting for every question. It doesn’t have to be someone from IT.

Week 1: the critical assets

Not the full inventory. The equipment that stops production or service if it fails, plus anything with a regulatory obligation. Usually fewer than fifty units.

For each one, the minimum: location, model, serial number, installation date, and warranty expiration. That last one is the piece of data that pays for itself soonest, because it prevents paying for repairs on equipment that was still covered.

And the most important thing this week, even though it looks secondary: group them by system, family, and model. That classification is what lets everything else be configured once for many pieces of equipment, instead of one by one. This is covered in more detail in asset management.

Week 2: schedules and frequencies

For each family — not each piece of equipment — what needs to be checked and how often.

Checklists resolve in a cascade — asset, model, subfamily, family — so you define them once per equipment type. Few fields, well chosen: an eight-point template that gets filled in properly beats a forty-point one that gets filled in halfway.

And the fields that record a measurement, with their minimum and maximum value, because that’s what turns the check into a usable data point.

Where the content comes from: the manufacturer’s manual, the regulation when there is one, and — above all — the people who have spent years attending to that equipment. That third source is the most valuable, and the only one that disappears.

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

Week 3: the field team

The week that decides the project.

A small group of technicians, working with the orders already being generated, using the app for real: stopwatch inside the order, checklist filled in, photos, and signature. And working without coverage, which is how it’s going to be most of the time.

That trial always produces two things: configuration tweaks nobody had foreseen — a field that gets in the way, a notification that annoys people — and the arguments to convince everyone else. One technician telling another that they no longer call the office convinces more than any training session.

The way to know it’s going well isn’t the absence of complaints: it’s that the complaints are specific. That means they’re actually using it.

Week 4: unplanned work coming in

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

You need to decide where incidents come in from — backend, client access with a photo, or an email inbox that the system turns into reports — and unify it. As long as there are three parallel channels, there’s no reliable backlog list.

And define the statuses: five, with agreed meaning, their maximum time, and their associated email when relevant. It’s an hour-long conversation that avoids months of ambiguity over what “in progress” means.

What should be working by the end of the month

If the plan has gone well, this:

• Preventive orders generating themselves with an owner and a date.
• Technicians closing them in the field, with measured times.
• Checklists for critical equipment written, with their values.
• Incidents coming in through one channel, with priority and deadline.
• And the first report with real data.

That last point is what justifies the project to whoever is paying for it: showing a figure the company didn’t have before.

What comes next, and there’s no rush

Warehouse and purchasing, once orders are already closing smoothly. The warehouse starts to make sense once consumption gets recorded when the order closes.

Documentation, starting with what expires: certificates, contracts, and insurance with their dates in the document manager, which warns before they expire.

Client portal, once there’s content worth showing. An empty portal generates more calls than it avoids.

ERP integration, once the rest has been running smoothly for months.

What to do with the old history

The question that stalls a lot of people when starting out, and the short answer is: almost nothing.

Migrating years of paper work orders is expensive and pays off little, because what actually gets consulted is the recent data. What is worth bringing over is the asset inventory with its installation dates, active warranties, and documentation still in force, because that’s what gives context from day one.

The history gets built going forward. In twelve months there’s enough to start deciding with data — which equipment concentrates the breakdowns, which frequencies are excessive — and in three years, enough that you won’t want to go back.

It’s worth telling the team this at the start, because the feeling of “we’re entering data for nothing” is real during the first few weeks and disappears as soon as the first report comes out that actually answers something.

The four mistakes to avoid

Starting with the full inventory. The most common one, and the one that leaves the most projects half-finished.

Configuring it without the people who will use it. What’s designed in a meeting room collides with reality on day one.

Turning on every module on day one. Nothing unused adds value, and everything visible but unused subtracts clarity.

Expecting the system to fix the process. If nobody decides who handles what and with what priority, it will just record the same chaos with more precision.

If you want us to map out what the rollout would look like for your case, you can request a demo or write to us.