Why execution is often the weakest link in the maintenance process

So deliberately investigating another layer of hidden problems inside execution feels counterintuitive.

But hear me out.

Of all the work that actually made it through the maintenance process correctly:

• gatekeeping provided the right information
• a due date was assigned
• the work got planned in time
• it made it onto the schedule

…and then execution still failed.

In the earlier stages of the maintenance process, you will probably find even more situations where the process itself was not correctly followed. But improving the earlier phases will barely show up in your KPIs if the work still gets blocked later during execution anyway.

All you achieve is that the workorder gets stuck later in the process instead of earlier.

But once workorders consistently make it through execution as well, your KPIs finally start changing for the right reasons.

And of course, the numbers themselves are not the goal.

Lowering your emergency breakdown KPI is not the goal. Lowering the actual number of emergency breakdowns is.

Improving the KPIs simply reflects that the operation itself is improving:

• lower maintenance costs
• higher reliability
• less rework
• less operational disruption

Plus, all the earlier effort was not wasted.

A PM plan review only matters if the resulting work actually gets executed. Reliability analysis only matters if the corrective actions reach the field. Inspection programs only matter if the findings turn into completed workorders. Engineering improvements only matter if the operation consistently follows through operationally.

Before execution even begins, you already invested:

• engineering time
• planner effort
• inspections
• smart sensors
• preparation work

Only for the intended work never to actually get completed.

And when execution fails, the work usually creates even more effort afterward:

• replanning
• rescheduling
• additional coordination
• repeated preparation
• repeated discussions

Often involving the largest amount of operational time from the most people in the entire process.

So where do you start?

Not by saying: "From now on we will execute what was planned."

And also not by immediately concluding: "Production never releases the asset anyway, so there is nothing we can do about it."

You start by measuring first.

On a weekly basis, planners should give the reasons why scheduled work did not become mechanically complete in the system.

And something interesting happens almost immediately.

Many workorders were actually completed — they were simply never updated correctly in the ERP system.

During the first weeks, this comes up constantly.

But pretty soon, people start checking their statuses beforehand because nobody wants to repeatedly explain in meetings that the work was already done but never administratively completed.

And that alone already improves:

• backlog pollution
• false overdues
• false plan attainment failures
• incorrect lead times

There are many reasons why work does not get executed. And every site has different ones.

The trick is not trying to solve everything at once.

The trick is identifying which execution failures are relatively preventable.

Categorise the workorders by reason. Measure which preventable causes affect the largest amount of workorders. Start fixing those first.

Because many execution problems initially look much larger and more structural than they actually are.

And once execution becomes visible operationally, you often discover that a surprising amount of disruption was actually predictable long before execution week even started.

You will find that most causes are preventable either by taking the work off the schedule on time, or by alerting the planner early enough so he can still do something about it.

ERP systems are basically like phones without notification features. You actively have to search for new information and manually check whether everything is still in order instead of getting notified when it is not. That is why planners easily miss things.

Since no matter what the outcome of the analysis is, implementing a proper notification system will almost always create direct improvements. So you might even want to start there before fully analysing everything.

The challenge is that you need a lot of logic behind such a system. You have to build alerts for many different operational situations because you still do not know which root causes are actually creating most of the execution failures.

There are two dangerous paths when implementing such a notification system:

When planners, schedulers or engineers receive too many irrelevant or incorrect alerts, they eventually stop listening to them.

But perhaps even more dangerous: the alerts are actually valuable and trusted, but they only catch half of the situations you are trying to prevent. People stop checking manually because they trust the system, while the same execution failures still continue happening in the background.

By starting with execution review first, you solve both problems.

You create a much more effective alert system while simultaneously measuring whether the system itself is actually working.

What we strongly believe is that maintenance improvement should first unburden the maintenance professional.

There are often 2 to 4 hours a day — at some sites even 6 — wasted on manual administrative work and chasing information across disconnected systems.

Reduce that first.

So maintenance specialists can spend more time using the knowledge they already have to keep the plant running smoothly instead of constantly fighting systems and searching for information.

And that is why we believe you should first measure, then implement alerts, and keep measuring whether the system is actually improving execution.

For a preview of such a measuring system: dashboard.gusty.ai/demo ↗

For a demo of such an alert system, reach out.