Continuous improvement: what to change in practice
The eight concrete changes that pay off most in a maintenance plan: periodicity, checklist templates, stock, workload distribution, alert intake, and replacement criteria.
Updated on 6 min read
- Continuous improvement
- Planning
- Warehouse
- Indicators
The first part covered the method: what to measure and how often to stop and look at it. This one covers what comes next, which is the part where people draw a blank: with the indicators in front of you, what do you actually change.
These are the eight changes that pay off most, ordered by how fast they show results.
1. Lower periodicities that are excessive
Counterintuitive, and almost always the first one. Every site has over-maintained equipment: checked four times a year because someone decided that a decade ago and nobody’s looked at it since.
The signal is clear: zero anomalies detected over several consecutive cycles. That doesn’t mean the check is working — it means one visit is probably unnecessary. Dropping from four to three visits on an equipment family frees up technician hours with no risk, and it’s the fastest way to fund what comes next.
2. Raise periodicities where things are failing
The other direction. If a piece of equipment breaks down between checks, the frequency is set wrong.
The data is in the intersection between corrective order history and the date of the last preventive visit. If the pattern repeats across several units of the same model, it’s not bad luck: it’s the periodicity.
3. Move from calendar to counter
When wear depends on use rather than time, adjusting the calendar is fighting against arithmetic. Two identical machines can carry very different service hours.
An asset can carry a counter — hours, cycles, kilometers — with a limit and a warning percentage: once a logged reading crosses the threshold, the preventive order generates automatically.
The sensible approach is to combine both: by time for what degrades whether it’s in use or not; by counter for what wears out through use.
4. Refine the checklist template, not just the frequency
Sometimes the problem isn’t how often something is checked, but what gets checked. If breakdowns concentrate on a component that isn’t on the checklist, more visits won’t change anything.
The anomaly report cross-referenced with the breakdown report shows that gap. Adding two checkpoints to a family’s template takes five minutes in checklists and rolls out to every piece of equipment in that family through the cascade — asset, model, subfamily, family.
And if fields don’t have a minimum and maximum value, add them: that’s the change that turns “it was checked” into “it was measured,” and without it there’s no trend to analyze.
5. Adjust stock to what actually moves
Two opposite problems coexist in almost every warehouse: references that stall jobs because there’s never any in stock, and references that have sat untouched for two years tying up money.
The reports on materials used and on movements show which is which. What gets consumed and stops a job if missing needs minimum stock in warehouses and items; what doesn’t move doesn’t.
And there’s one change that reconciles inventory on its own: registering each technician’s van as a warehouse. As long as the material that travels isn’t in the system, stock will never add up.
6. Redistribute workload
The universal pattern: half the team overloaded and the other half waiting, with nobody noticing until something is late.
The hours-per-technician report shows it. And the fix usually isn’t manual reassignment: it’s making unassigned work visible — in the calendar it can be color-coded — and letting technicians pick it up themselves, because they know if it’s on their way.
Watch for the side effect: with an open queue, people grab the easy jobs and a pile of difficult orders that nobody wants builds up. That’s corrected with real priorities and deadlines in incidents.
7. Fix how alerts come in
If alerts arrive through three channels, there’s no reliable pending list, and everything above gets measured against incomplete data.
The concrete change: unify. An alert can come in from the backend, from client access with a description and photo, or from a mailbox the system empties and converts into incidents. There’s no need to ban the phone; what’s needed is for whoever takes the call to log it in the same place.
And define statuses with their maximum time, so overdue items show up in a list instead of being discovered when someone complains.
8. Decide when to stop repairing
The change that moves the most money, and the one that gets put off the most, because nobody wants to make that call without data.
An asset can have its replacement cost and a warning percentage recorded: the system notifies when accumulated repair spend crosses that percentage. It doesn’t generate an order — renewing a piece of equipment is a business decision — but it puts the figure in front of you right when it matters, instead of inside a report nobody opened.
9. Remove from the list what isn’t maintenance
A cleanup change that frees up more time than it looks like. Many plans have accumulated tasks that aren’t maintenance: errands, administrative tasks, escorting a supplier, opening a door.
It’s not that they shouldn’t be done. It’s that if they come in as preventive orders, they muddy every indicator: they inflate the percentage of plan executed, lower the average time per intervention, and make the preventive-to-corrective ratio look better than it is.
The fix is to separate them by type, so they can be filtered out in reports. Then the real figure appears for how much of the team’s time actually goes into technical work, which is usually a lot less than everyone thought.
How to measure the effect without getting it wrong
Change one thing at a time, per family. If you touch periodicity and the checklist template at once on the same equipment, you won’t know which one caused the difference.
Look at the family, not the whole site. The overall figure has too much noise.
Give it one or two cycles. Measuring after three weeks and concluding it didn’t work is the most repeated mistake.
Note the date of the change. It seems obvious and almost never gets done; without it, before and after can’t be separated.
And what not to change
The requirement to log data. It’s tempting to lighten the checklist “so the technician takes less time,” and it works for a month: after that there’s no data, and continuous improvement runs out of raw material.
If a field is unnecessary, remove it because it doesn’t add value — not to save seconds. And if a technician resists logging something, it’s almost always because that data never comes back to them as anything useful.
If you want to see what changes would come out of your own history, you can request a demo or write to us.