From craft to process in maintenance

In many companies, maintenance works, and works well. What happens is that it works by craft: there are two or three people who know what needs doing, when, and how, and they do it.

That’s not a flaw. It’s a fragile situation. And the difference between craft and process isn’t the quality of the work: it’s what happens when those people aren’t there.

How to spot the craft model

The signs are pretty clear:

• The answer to “when was this last checked?” starts with “ask…”
• The maintenance plan exists, but only one person knows it in full.
• When that person is on vacation, only the urgent stuff gets done, nothing else.
• Nobody knows how much it costs to maintain a specific piece of equipment.
• If someone leaves, part of the operation goes with them.

None of this stops you from working. All of it stops you from growing, and all of it gets paid for at once, the day the key person changes companies.

What turning it into a process means

It doesn’t mean burying it in bureaucracy. It means the information stops living in people’s heads and the work gets generated on its own, not because someone happened to remember.

Five steps, in order.

1. Write down what gets checked

The first and most valuable one. What to look at on each type of equipment, in what order, and against what reference values.

Checklists are defined by equipment family and resolve in cascade —asset, model, subfamily, family— so it isn’t a documentation project: it’s an afternoon per family, and it covers two hundred units.

Where the content comes from: the manufacturer’s manual, the standard where there is one, and above all the people who’ve spent years working on that equipment. That third source is the most valuable, and the only one that disappears.

2. Let the plan generate itself

A task that only lives on a calendar —or in someone’s head— doesn’t complain when it doesn’t get done.

Preventive maintenance generates work orders with an assignee and a date, based on the checklist and the frequency, checking beforehand whether the day is a holiday and whether the technician is available.

And if wear depends on usage, the asset can carry a counter with a limit and a warning percentage, so the order gets generated once the threshold is crossed.

3. Let the recording happen in the field

This is what turns the work into information. Timer running inside the order itself, material consumed logged against the warehouse, checklist filled in, photos and signature, from the app and without a signal.

If it gets logged at the end of the day, the data exists but isn’t reliable, and a process built on unreliable data isn’t a process.

4. Let work come in through a single channel

As long as reports come in through three different channels, the backlog will be incomplete and distribution will depend on who happened to pick up the phone.

An incident can come in from the backend, from client access with a photo, or from a mailbox that the system converts into reports. With its priority and its maximum time per status, so overdue items stand out.

5. Let someone look at the data

An hour every quarter, with the reports in front of you: what percentage of the plan has been executed, which units concentrate the anomalies, which frequencies to raise or lower, and which assets have racked up a cost that no longer justifies repairing them.

It’s the first thing that disappears from the calendar, and the thing that turns a recording system into a process of improvement.

What you gain, beyond robustness

It becomes possible to delegate. A new technician can carry out an inspection correctly because it’s written down, not because someone explained it to them.

It becomes possible to grow. Opening a new site means registering its equipment under families that already exist, inheriting the checklist, frequency, and documentation.

It becomes possible to prove it. Legal maintenance —which isn’t a separate module, but the same preventive-maintenance mechanism using the checklist the standard requires— rests on the history, the completed checklists, and the documentation with its dates.

It becomes possible to sell. In service companies, being able to show the executed plan and response times changes the tone of a proposal.

The key-person risk, with numbers

Worth putting a number on it, because in the abstract it convinces nobody.

Think of the person who knows the most about your facilities and answer this: if they weren’t around tomorrow, how long would it take to find out what gets checked on your most critical unit, and how often? Where’s its documentation? What was done to it last time, and what was left pending?

If the answer to all three is “weeks” or “we’d have to rebuild it,” that’s the risk. And it doesn’t get covered by insurance: it gets covered by writing it down.

The cost of writing it down is an afternoon per equipment family. The cost of not doing it gets paid in full, all at once, and always at the worst moment.

What not to lose along the way

The craft still matters. Turning it into a process doesn’t mean replacing the judgment of the person who knows: it means getting it out of their head so it’s available to everyone.

And it’s worth not overdoing it. A process with twenty mandatory fields that nobody looks at is worse than the craft model, because it adds work without adding information. The rule is the same as always: every field you require has to come back to someone as something useful.

Where to start

With step 1, on the critical assets, since it’s the one that depends least on buying anything. Writing down what gets checked on the equipment that stops production or service if it fails works the same regardless of tool, and it’s the piece of work that takes the longest.

And do it with the person who knows the most, not despite them. There’s usually some reluctance —writing down what you know can feel like giving away your value— and it gets defused by explaining the opposite: no longer being the only one who can fix something is exactly what lets them take a real vacation and focus on what only they can do.

If you want to see how it would look formalized, you can request a demo.