The Process on Paper Is Not the Process in Practice

Transformation programmes often begin with process maps. The mistake is assuming the map describes how the work is actually done.

The workshop produces a clean sequence: procedure, RACI, workflow, approvals, controls and governance. On paper, each step has an owner and every decision has a route.

Then you go into the operation.

A critical spreadsheet sits outside the system. Two approvals are bypassed because they add no value. Three process steps are performed together by one experienced person. A weekly report is produced but drives no decision. A local work-around keeps the asset moving because the formal operating model does not.

The documented process is work as imagined. Operational performance depends on understanding work as done.

01A process map is a starting point, not evidence

A documented process is still useful. It establishes intent, accountabilities, controls and the sequence an organisation believes should happen. It gives the investigation a place to begin.

It does not prove that the work happens that way. The people doing the task may be working with different information, equipment constraints, priorities or dependencies from those assumed when the process was designed.

The first diagnostic therefore needs two questions, asked separately:

• What is supposed to happen?
• What actually happens?

The Health and Safety Executive recommends using task analysis to inform procedures, including walking and talking through the task with the people who use them. That principle reaches beyond safety procedures. It is a practical way to test whether the operating model survives contact with the work.

02Deviation is not automatically a discipline failure

When practice differs from procedure, the instinct is often to retrain the team or enforce compliance. Sometimes that is correct. Often it is incomplete.

The difference may reflect poor practice. It may also be an intelligent adaptation to missing capability, unclear decision rights, unreliable data, an outdated procedure, an unnecessary control or a system that does not support the task.

The Energy Institute's human-performance guidance makes the same point: procedures do not always reflect work as done, and people can find that a task cannot be completed if every rule is followed exactly. That does not excuse unsafe behaviour. It changes the diagnostic question from “Who failed to follow the process?” to “Why does the process not support safe, effective delivery?”

A workaround is evidence. The task is to determine whether it is a risk, a useful adaptation or a symptom of a weak operating model.

03The gap has an operating cost

Small differences between documented and actual work accumulate. One team keeps a duplicate asset list. Another corrects failure codes manually. Urgent procurement compensates for poor planning. A performance analyst reconciles data from several systems before a KPI can be trusted. A supervisor rebuilds the schedule each week because the official plan does not reflect access constraints.

Each workaround may appear minor. Together they consume time, hide risk and weaken the link between investment and performance. They make capacity look available when people are already compensating for the system.

The symptoms are familiar:

• decisions move through informal routes;
• the same information is entered more than once;
• controls exist but do not affect behaviour;
• KPIs measure the process rather than the outcome;
• experienced individuals become single points of failure;
• performance depends on effort that never appears in the operating model.

The asset works. The organisation works. People compensate. But the investment case quietly leaks.

04Technology can make the wrong process faster

An ERP programme, workflow platform or AI initiative can standardise and accelerate work. It can also hard-code a process that was already disconnected from operational reality.

If a digital design begins with the documented workflow and never tests the work beside the people doing it, the programme may automate unnecessary approvals, reproduce poor data definitions and remove the flexibility that kept the operation functioning.

The sequence matters:

1. Understand the work. Establish the intended process and observe the actual practice.
2. Improve the work. Remove avoidable complexity, clarify decisions and close practical gaps.
3. Decide the technology. Specify what the system needs to enable, control or measure.

AI is not a strategy. It amplifies the foundations already present. Where the process, data and decision rights are sound, that can be powerful. Where they are not, technology can create faster and less visible failure.

05Go beside the people doing the work

In the Northumbrian Water Leading Asset Management programme, I worked client-side as People and Process Programme Manager. The task before the new enterprise asset-management system could be designed was to align operational and maintenance processes across three regions.

The system was not the starting point. The work was to understand where the regions used different definitions, controls and practices, then decide what should be common and what genuinely needed to remain different. Without that work, the technology would have automated three versions of the same process.

The same principle applied in a remote and minimal-personnel operations study for an offshore gas facility. I led the business-process workstream, mapping manual interventions and testing the operating and maintenance model required for fewer people on the facility. Around 80% of maintenance hours were corrective.

That percentage was evidence, not the diagnosis. The team still had to understand why work was corrective, where interventions occurred, which instrumentation and information gaps mattered, and what needed to change in the operating model and maintenance strategy.

06Separate BAU fixes from system change

Once the differences are visible, they need to be classified. Some belong to business as usual. Others cannot be solved without structural change.

A transformation programme should not spend £1 solving something the operation could fix for 10p. Equally, BAU should not be expected to absorb a genuine structural problem without authority, capacity or investment.

The distinction protects both sides. Operations gains permission to fix what it can. The programme focuses its resources on changes that truly require programme governance and investment.

07Use the difference as the diagnostic

The gap between process and practice is not noise to be removed from the analysis. It is where the useful questions begin.

Map the documented process → validate beside the people doing the work → quantify the differences → separate BAU fixes from system change → embed through KPIs, training and coaching.

That is the Oclas diagnostic method. It keeps the work grounded in operational evidence and converts observation into a decision-ready roadmap. It also reduces the risk of prescribing technology before the problem, value and route to change are understood.

08Five questions for leaders

Before approving the next ERP programme, AI initiative, operating-model redesign or transformation project, ask:

1. Do we know how this process is supposed to work?
2. Have we observed how it actually works?
3. Can we quantify the important differences?
4. Which differences can operations fix themselves?
5. Which genuinely require system or organisational change?

Operational performance improves when the organisation stops treating the process map as the truth and starts using it as the beginning of the investigation.

Sources: Health and Safety Executive, Procedures; Energy Institute, Making Compliance Easier.