Starting continuous improvement without a history

Almost everything written about continuous improvement in maintenance assumes you already have a history. And the reasonable objection from someone who has just gone live is immediate: I’ve only been running this a month, I have nothing to compare against.

That’s true, and there are still things you can measure and fix from day one. Here they are, in the order they appear.

Month 1: percentage of plan executed

This is the only one that doesn’t depend on having a history, because it’s compared against the plan itself, not against the past.

From the first month you know how many of the preventive work orders generated were closed on time. And that figure alone already forces a decision.

If it’s well below target, the problem isn’t frequency or discipline: the plan is asking for more hours than you have. The fix is to cut scope, starting with the equipment that’s reviewed more often than necessary.

If it’s very high from the first month, it’s worth looking closely: usually it means the plan is too small, or that orders are being closed without the work actually being done.

Month 1: overdue orders left open

The other immediate indicator. If it grows, something isn’t working in the assignment or capacity, and you see it before anyone complains.

For this to exist, statuses need an associated maximum time, a half-hour configuration that’s one of the most cost-effective there is.

Month 2: time deviation

As soon as a few dozen orders have been closed with a timer, the first surprise of almost every rollout shows up: actual hours aren’t what people thought.

The work order stores target time, estimated time and the deviation. And that lets you fix two things without waiting a year: the planning estimates for the following weeks, and the pricing of jobs being sold below cost.

Month 2: team friction

Not an indicator — a source of improvement, and the fastest one.

The specific complaints from the first weeks — “this field is in the way,” “this alert is annoying,” “this makes me type things twice” — are exactly the information needed to fine-tune the configuration.

The rule for deciding: every field you ask for has to come back to someone as something useful. If it doesn’t come back, drop it. And if a technician resists logging something, it’s almost always because that data is useless to them.

Month 3: the first anomalies

After a couple of review cycles, the anomaly report stops being empty. And that allows the first real question: are the checks looking where things actually fail?

If breakdowns cluster around a component that isn’t on the checklist, more visits won’t change anything: you need to change the checklist. Adding two items to a family takes five minutes and rolls out to every piece of equipment through the cascade.

And the reverse: equipment with several cycles and not a single anomaly is probably over-maintained, and that’s the first source of hours for what actually needs them.

What you have to get right from day one

Because it shapes everything that comes after, and can’t be fixed later.

Accurate logging. The data from the first months is the baseline that future years will be compared against. If hours are jotted down from memory at the end of the day, that baseline is false, and you’ll never know whether anything actually improved.

Checklists that record values. A field with a minimum and maximum turns a round into a time series from the very first reading. Starting with checkboxes and adding values later means losing those months of series data.

Correct classification by family. This is what lets you later aggregate by model and by family, which is where the findings that matter are.

Anomalies that turn into work. If they’re logged and nothing happens, the technician stops logging them, and the report that would have had the most value stays empty forever.

Improvements that don’t need any data

There’s a group of fixes you can make in the first week because they don’t depend on measuring anything: just on looking at how things are set up.

Unify how work comes in. As long as requests arrive through three different channels, no to-do list will ever be complete, and everything you measure afterward will be built on incomplete data. A mailbox that the system turns into requests eliminates the manual step.

Define statuses with a clear meaning. Five, agreed in a one-hour conversation. It avoids months of ambiguity about what “in progress” means.

Calibrate alerts. Start with two or three statuses that trigger notifications. It’s much easier to add an alert than to remove one once people have learned to ignore the emails.

Load what expires. Certificates, contracts and insurance policies with their dates in the document manager. Half an afternoon of work, and one of the fastest things to pay off.

Register vans as warehouses. As long as material that travels isn’t in the system, stock will never add up, no matter how many months of history pile up.

When each thing shows up

To set expectations: accumulated cost per asset starts saying something at six months and starts driving decisions at a year. MTBF needs several failure cycles. And the ratio of preventive to corrective work takes months to move, which is exactly what makes it honest.

There’s a full walkthrough of the first year in what changes in a year with a CMMS.

The habit to build now

One hour a quarter with the reports in front of you, starting from the first quarter even if there’s little data. Not because of what you’ll decide — there won’t be much — but because it’s the habit that sustains everything afterward.

It’s the first thing to disappear from the calendar once the day fills up with urgent tasks. Scheduling it in the calendar with a set frequency works better than good intentions.

The full method is in continuous improvement in maintenance and the concrete changes are in the second part.

If you want to see what could be measured from month one in your case, you can request a demo.