Why isn't the maintenance process followed — and why don't redesigns fix it?

The two rarely fully match.

Since;

• Still too many overdues
• Statuses still don't reflect reality
• Backlog keeps growing
• Priority 3 workorders become priority 1 workorders
• Still a firefighting culture

And usually, the maintenance manager feels it most strongly.

Because initiatives get launched. Processes get redesigned. Meetings happen. Training gets rolled out.

And six months later, much of the behaviour quietly returns to what it was before.

The instinctive explanation is usually: "the team is not following the process."

Which then creates the standard response:

• redesign the process
• retrain the team
• reinforce compliance
• tighten governance

But in practice, that rarely fixes the underlying problem for very long.

Because the issue is almost never simply: "people do not want to follow the process."

The reality is more complicated than that.

At most sites, three different forces overlap continuously:

• people only partially know the process
• people only partially agree with the process
• people are only partially able to follow the process consistently

And those three forces constantly interact with each other.

That is why redesigns alone rarely stick.

What "the process is not being followed" actually looks like

Most organisations already have a maintenance process documented somewhere.

Usually:

• inside a document management system
• inside procedures
• inside workflow diagrams
• inside training material

Often hundreds of pages long.

And operationally, most people doing the work have never fully read it.

Instead, the process is usually learned informally:

• from colleagues
• from supervisors
• from experience
• from operational shortcuts that evolved over time

And gradually, the "real" process becomes whatever the organisation can realistically execute under daily operational pressure.

That difference matters enormously.

Because many organisations assume: "If people are not following the documented process, they must not understand it."

But operational reality is rarely that simple.

The first force: people partially know the process

This part is real.

There are always areas where:

• technicians
• planners
• supervisors
• engineers

do not fully understand certain process expectations.

A common example:

A technician partially completes work and leaves a note explaining what still needs follow-up.

Operationally, the planner should:

• close the current workorder
• create a follow-up notification
• reset the workflow correctly

But somewhere in the chain, that convention was never clearly transferred.

The planner learned from another planner. That planner learned from someone else. And eventually small process assumptions become inconsistent.

This absolutely happens.

But it is also clearly not the entire explanation.

Because when you analyse operational maintenance data deeply, you quickly see behaviour that cannot simply be explained by lack of knowledge.

For example:

In many backlog cleanups, GUSTY finds workorders where technicians clearly wrote: "work completed"

while the workorder itself still remained in: "new" status.

That means multiple workflow steps were skipped entirely.

Not because nobody knew they existed.

But because something else overrode the process operationally.

And that means the second and third forces are also active.

The second force: people partially disagree with the process

Sometimes the team understands the process perfectly well.

They simply do not believe the documented workflow matches operational reality.

For example:

A technician resets an alarm. The alarm clears. The process says: close the workorder immediately.

But the technician already knows what is likely to happen operationally: the alarm may return tomorrow.

If he closes the workorder now and the alarm returns tomorrow, then:

• a new notification must be created
• planning starts again
• administration repeats
• additional effort gets created

Operationally, waiting a few days before closing may actually be more efficient.

So the technician adapts behaviour to reality.

And importantly: often the technician is not irrational for doing this.

The process may genuinely create more operational friction than the alternative behaviour.

This is one of the reasons maintenance organisations struggle so much with compliance-driven redesigns.

Because asking people to "follow the process" becomes equivalent to asking them to work less efficiently operationally.

Eventually, reality wins.

The third force: people are not fully able to follow the process

This is the biggest force — and usually the least understood.

"Not able to" does not mean: "people did not try."

It usually appears in two forms.

The first form: lack of visibility

Maintenance ERP systems are largely transactional systems.

Information often exists somewhere in the system:

• technician notes
• longtext
• deferred comments
• failed execution attempts
• changed conditions

But the system does not actively surface what changed.

That means planners only discover important information if they happen to manually open the correct workorder at the correct time.

If they do not:

• statuses stay wrong
• follow-ups get missed
• workorders remain stale
• execution visibility drifts

This is not negligence.

The operational signal simply never surfaced itself.

The second form: time pressure

Maintenance organisations do not operate in smooth, evenly distributed workflows.

They operate in bursts.

There are periods where:

• urgent work explodes
• breakdowns dominate
• operational pressure spikes
• planners sprint continuously

During those moments, certain administrative actions naturally get deprioritised:

• status updates
• searching for missed work
• documenting follow-ups
• checking planning consistency

Not because the team believes those things are unimportant.

But because the organisation temporarily prioritises keeping the plant running above everything else.

And afterwards, the ERP system usually provides no structured mechanism forcing the organisation back toward operational recovery.

So incomplete actions remain incomplete.

Deeper read: What is firefighting culture in maintenance — and how do you stop it? — on why these urgent-work bursts gradually become the operating mode rather than the exception.

Why redesigns and training only partially work

This is why process redesigns often disappoint.

Redesigns usually improve:

• understanding
• documentation
• workflow clarity

Training improves:

• awareness
• onboarding
• procedural consistency

Those things absolutely help.

But they mostly address the first force: knowing.

The second and third forces often remain structurally unchanged.

And over time, operational pressure slowly pushes behaviour back toward whatever the system realistically supports.

For example:

A planner gets told: "close workorders earlier."

But after several cases where early closure created duplicate administration later, the planner adapts behaviour again.

Not because the planner rejects the process philosophically.

Because operational feedback taught him the alternative behaviour is safer or more efficient.

Eventually: the system reality overrides the documented process.

And this is exactly why many redesigns slowly decay after rollout.

The structural problem underneath all of this

Now zoom out for a moment.

Look at the rest of the plant.

Modern heavy industry already uses:

• smart sensors
• drones
• advanced process control
• integrated supply chains
• sophisticated production systems
• modern operational interfaces

Then look at many maintenance planners.

Operationally, many are still working inside ERP workflows fundamentally designed decades ago:

• transactional
• administrative
• passive
• reactive

The system records what already happened.

It rarely actively supports:

• operational prioritisation
• workflow guidance
• signal surfacing
• intelligent reminders
• dynamic follow-up

And that is the structural gap process redesigns alone cannot solve.

Because even the best-designed process eventually collapses back toward whatever the tooling environment actually supports operationally.

Deeper read: Maintenance maturity: from firefighting to control — how process adherence sits inside the broader maturity picture, and why advanced layers fail when the operational layer beneath them is broken.

The WhatsApp comparison

The easiest way to understand this problem is through a simple thought experiment.

Imagine WhatsApp worked like many maintenance ERP systems.

No notifications. No sorting by recent activity. No unread indicators. No prioritisation.

To discover whether anything important happened, you would need to manually open every conversation every single day.

Operationally, what would happen?

You would:

• miss things constantly
• forget conversations
• react late
• prioritise only the loudest issues
• spend enormous time searching manually

That is effectively how many planners already work.

Hundreds of workorders. No intelligent surfacing. No operational prioritisation. No structured reminders.

Everything important has to be manually discovered.

That is not a discipline issue.

That is a tooling and operational-visibility issue.

What changes when tooling actually supports the process

The real breakthrough happens when the operational tooling itself begins supporting the desired behaviour.

Because then all three forces start shrinking simultaneously.

Knowing improves because the next relevant action becomes visible directly inside operational context.

Agreeing improves because workflows can align more naturally with real operational behaviour instead of fighting it.

Able to improves because:

• signals surface automatically
• planners no longer rely purely on memory
• operational follow-up becomes manageable under pressure

At that point, following the process stops feeling like: "extra discipline."

And starts becoming: the easiest operational path.

That is usually the moment where process improvements finally become sustainable.