If your business has processes but still spends most of its time firefighting, the problem is probably not that you need more procedures.

It is usually that the process on paper does not match the way work actually enters, moves through and gets managed inside the business.

You may have:

• SOPs
• Checklists
• CRM stages
• Job sheets
• Approval processes
• Project plans
• Handover forms
• Weekly meetings
• Software workflows

and still feel as though every day starts with:

“Right, what the fuck has happened now?”

That happens when the surrounding operating system is weak.

The process says how normal work should happen.

The business keeps creating abnormal work.

Poor information.

Last-minute promises.

Insufficient capacity.

Unclear ownership.

Missing decisions.

Constant interruptions.

Exceptions nobody designed for.

Managers overriding the process.

Customers bypassing it.

People finding workarounds because following the official version makes getting the job done harder.

The answer is not necessarily another procedure.

It is understanding why the business keeps forcing people out of the process you already have.

A documented process is not the same as a functioning system

This distinction matters.

A process might say:

1. Sales confirms scope.
2. Operations reviews capacity.
3. Customer receives start date.
4. Materials are ordered.
5. Job is scheduled.
6. Delivery begins.

Looks excellent.

What actually happens?

Sales promises Friday before Operations sees it.

Operations discovers the job on Wednesday.

Materials are unavailable.

The customer has already booked contractors around you.

Everyone panics.

Purchasing pays extra for urgent delivery.

Operations moves another customer's job.

That customer complains.

The owner gets involved.

Technically, you have a process.

Operationally, nobody protected it.

The problem is not:

“People need to follow the process better.”

Maybe they do.

But first ask why the organisation repeatedly creates circumstances where bypassing the process feels necessary.

Processes fail when the surrounding behaviour contradicts them

Imagine your procedure says:

All quotations above £25,000 require margin review before issue.

Good.

Then the owner says:

“This one's urgent. Just get it out.”

What did everybody learn?

The process applies until urgency appears.

Next time, the Sales Director makes the same judgement.

Then a Sales Manager.

Eventually:

Urgent = ignore process.

The written procedure still exists.

The real process has evolved.

This is one reason I am cautious when companies respond to operational chaos by writing more SOPs.

HSE guidance on management systems makes a surprisingly relevant point beyond health and safety: organisations can become too focused on formal documentation and lose sight of the human implementation of the system itself. Its wider Plan, Do, Check, Act framework emphasises that a management system needs implementation, monitoring and review, not merely documentation.

That principle translates extremely well into ordinary business operations.

A process only exists if the organisation can reliably operate it.

The process on paper and the work people actually do are often different

Researchers sometimes distinguish between work as imagined and work as done.

That difference is useful.

Management imagines:

Customer request enters here.

Employee follows steps.

Output appears there.

Employees experience:

Customer forgot information.

System is down.

Supplier changed delivery.

Manager is unavailable.

Previous job overran.

Customer changed scope.

Another department needs something urgently.

Software requires eleven clicks for something that can be done in Excel in two minutes.

So people adapt.

A 2026 Safety Science study examining procedural work in a petrochemical environment found substantial variation between written procedures and successful work as actually performed, with context explaining much of that variation. That is a specialist high-risk environment and should not be generalised mechanically to every SME, but the underlying point is valuable: divergence from procedure is not always simple disobedience. Sometimes people are adapting to conditions the written process did not accommodate.

If your employees repeatedly work around a process, ask why.

The workaround may be the problem.

Or it may be evidence of the problem.

Reactive businesses usually have recurring emergencies

This is one of the easiest diagnostic clues.

Look at the last month of firefighting.

How much was genuinely unpredictable?

Customer's building flooded.

Key employee had an accident.

Supplier suddenly entered administration.

Fine.

Those are genuine exceptions.

Now compare:

Material wasn't ordered.

Customer requirements unclear.

Nobody knew who was responsible.

Quote promised something Operations couldn't deliver.

Invoice incorrect.

Employee wasn't trained.

Schedule changed at the last minute.

Owner had not made a decision.

Customer chased because nobody updated them.

Manager discovered deadline too late.

Those are not random emergencies.

They are recurring operational patterns.

If the same category of emergency happens repeatedly, stop calling it an emergency.

It is part of your system.

Your business may have procedures but no operating rhythm

This is another distinction.

Processes explain how individual pieces of work happen.

An operating rhythm makes sure the wider business notices what needs attention before it becomes urgent.

For example:

Weekly capacity review.

Sales and Operations planning.

Pipeline review.

Cash review.

Project review.

Management scorecard.

Customer-risk review.

Recruitment planning.

The exact rhythm depends on the business.

Without those recurring management loops, processes operate in isolation.

Sales follows its process.

Operations follows its process.

Finance follows its process.

Then the outputs collide.

A management system needs feedback.

ONS's Management and Expectations Survey measures structured management practices across areas including continuous improvement, KPIs, targets and people management. Its latest published analysis found stronger structured management practices were associated with higher productivity and resilience, while larger businesses generally reported more structured practices than smaller ones. ONS is clear these relationships are associations rather than proof that one practice automatically causes a particular performance improvement.

The useful lesson is simpler:

Good operations require more than procedures.

They require monitoring and adjustment.

The missing part is often “Check” and “Act”

Businesses love:

Plan.

Do.

Create process.

Train employee.

Go.

Then six months later everybody complains that the process does not work.

What happened to:

Check?

Act?

HSE's Plan, Do, Check, Act model is designed for health and safety management, but it provides an excellent general management principle:

Plan what should happen.

Do it.

Check whether it actually works.

Act on what you learn.

Then repeat.

A process should not be treated like scripture.

It is a current best-known method.

Reality gives you data.

Use it.

Problem 1: The process was designed for the perfect job

This is common.

The workflow works beautifully when:

Customer information is complete.

Product is standard.

Everyone is available.

Supplier delivers.

Job starts on time.

Nothing changes.

Wonderful.

How often does that happen?

If 40% of your work contains meaningful exceptions, your process needs an exception path.

Not 400 separate procedures.

A sensible method for handling deviation.

For example:

What qualifies as an exception?

Who can decide?

What information do they need?

What customer communication occurs?

What thresholds trigger escalation?

Without this, every non-standard situation becomes:

“Can somebody ask Adam?”

Now the process exists.

And so does the owner bottleneck.

Problem 2: Nobody owns the process end to end

Departments own their bit.

Nobody owns the outcome.

Sales says:

“We handed it over.”

Operations says:

“The handover was shit.”

Finance says:

“Nobody told us.”

Customer says:

“I don't care which department caused it.”

Correct.

Processes frequently fail at the joins.

Who owns:

Sales to Operations?

Operations to Finance?

Customer complaint to resolution?

Enquiry to quote?

Quote to mobilisation?

Project completion to invoice?

If responsibility disappears at departmental boundaries, the organisation becomes reactive precisely where work changes hands.

Handoffs deserve disproportionate attention

Imagine each department is 95% reliable.

Excellent.

But a customer journey contains five significant handoffs.

Every handoff creates an opportunity for:

Missing information.

Delay.

Different assumptions.

Lost ownership.

You do not need more departmental procedures.

You may need better interfaces.

Ask at every handoff:

What information must be complete?

Who confirms receipt?

Who owns the next step?

What happens if something is missing?

How quickly should it move?

This is boring operational design.

It prevents enormous amounts of firefighting.

Problem 3: Inputs are poor

A process cannot produce reliable output from permanently unreliable input.

Operations receives:

Half-complete scope.

Wrong measurements.

Missing purchase order.

Unconfirmed delivery address.

Unclear deadline.

Then everyone expects Operations to:

“Follow the process.”

What process?

The first step should probably be:

Do not accept incomplete input.

This applies everywhere.

Payroll receives missing hours.

Finance receives incomplete job information.

Sales receives rubbish leads.

Marketing receives vague propositions.

Managers receive problems without facts.

Define minimum input standards.

Sometimes the easiest way to stop downstream chaos is to stop upstream rubbish entering the process.

Problem 4: The process does not match capacity

You can have the best scheduling process in Britain.

If you have:

100 hours of capacity

and:

140 hours of committed work

you are still going to become reactive.

Process cannot repeal mathematics.

Something will:

Move.

Rush.

Overrun.

Receive overtime.

Miss deadline.

Require subcontractors.

Disappoint somebody.

This is why capacity and process have to be designed together.

Article #68 looked at the profit consequences when too much work enters a weak operating system.

Article #76 looked at the same issue from scale readiness.

If your business is permanently overloaded, stop asking employees to process their way out of a capacity problem.

Problem 5: Your priorities change faster than the process can cope

Monday:

Project A is urgent.

Tuesday:

Forget A. Customer B is furious.

Wednesday:

Director says C has to happen.

Thursday:

Sales promises D.

Friday:

Everyone asks why Project A is late.

That is not process failure.

That is leadership-induced volatility.

Employees cannot work systematically if management repeatedly scrambles the sequence.

Sometimes priorities genuinely change.

Fine.

But the cost of change should be visible.

If D moves forward:

What moves backwards?

Who gets told?

What resource shifts?

What commercial consequence exists?

Article #83 dealt with this at strategic level.

The same principle applies operationally.

Everything cannot move to the front of the queue without something else moving backwards.

Problem 6: Sales is allowed to override Operations

This deserves special attention because it creates enormous operational reactivity.

Sales wins work.

Excellent.

Then promises:

Price.

Scope.

Delivery date.

Customisation.

Response time.

Without asking the people who need to deliver it.

Now the organisation has two choices.

Break the promise.

Or break the system.

Usually it chooses the system.

Operations bends.

Employees work late.

Purchasing rushes.

Margin disappears.

Owner intervenes.

Then everybody complains that Operations is always reactive.

The reaction began upstream.

A healthy commercial process needs boundaries around what can be promised without delivery input.

Sales should be able to sell.

Operations should not need clairvoyance.

Problem 7: The official process is too difficult

This is where employee workarounds become fascinating.

Suppose entering a customer job properly requires:

Open system.

Complete 24 fields.

Upload document.

Select category.

Create task.

Notify manager.

Employees discover:

Send Dave a WhatsApp.

Dave sorts it.

Guess which process wins under pressure?

Research into business-process workarounds describes them as adaptations people use to overcome obstacles, exceptions or constraints that prevent the official system from helping them achieve the intended outcome efficiently.

Do not automatically respond:

“We need better compliance.”

Perhaps.

Or perhaps the official process is shit.

Watch somebody actually use it.

Count:

Clicks.

Duplicate data.

Waiting.

Approvals.

Handoffs.

If the unofficial route is dramatically easier, people are telling you something.

Problem 8: You have too many approvals

Approvals feel like control.

Sometimes they are.

Sometimes they are latency.

Purchase £200?

Manager.

Customer credit £100?

Director.

Small scheduling change?

Owner.

Discount 3%?

Commercial Director.

Now ordinary work repeatedly waits for somebody senior.

Then becomes urgent because it waited.

Then the senior person receives:

URGENT APPROVAL REQUIRED.

The business appears reactive.

But the urgency was designed into the authority structure.

Use decision boundaries.

What can employees decide?

What can managers decide?

What thresholds genuinely require escalation?

Article #78 explored this as owner dependency.

Good process gives capable people enough authority to keep ordinary work ordinary.

Problem 9: Managers solve instead of manage

Something goes wrong.

Manager jumps in.

Fixes it.

Next problem.

Fixes that.

Excellent employee.

Terrible long-term system.

The question after the immediate issue should be:

Why did this happen?

If the manager never gets beyond:

Resolve.

Resolve.

Resolve.

then recurring causes survive.

This is the operational form of the Fixer Loop.

Firefighting feels productive because the feedback is immediate.

Problem existed.

You acted.

Problem gone.

Process improvement is slower.

Problem existed.

You investigated.

Changed system.

Maybe you prevented 50 future problems nobody will ever see.

Less dramatic.

Much more valuable.

Problem 10: Heroics are rewarded more visibly than prevention

This creates a fascinating cultural problem.

Employee stays until 10pm fixing a disaster.

Everybody says:

Amazing commitment.

Another employee quietly redesigns the workflow so the disaster never happens again.

Nobody notices.

What behaviour did you reward?

Businesses become addicted to heroics because heroics are visible.

Prevention is invisible.

A well-run system can look less impressive because fewer dramatic rescues happen.

That is the point.

Celebrate:

Problems eliminated.

Errors reduced.

Better handoffs.

Capacity improved.

Dependencies removed.

Not only the people standing in the smoke holding the extinguisher.

Problem 11: Your meetings report problems rather than manage them

Weekly meeting:

Job A is late.

Customer B unhappy.

Project C over budget.

Sales missed target.

Fine.

What changes?

If next week's meeting contains the same items, the meeting is reporting reality rather than managing it.

For recurring problems ask:

What is the root cause?

What action changes the system?

Who owns it?

By when?

How will we know it worked?

Otherwise management meetings become a weekly guided tour of dysfunction.

Problem 12: Your KPIs are lagging too far behind

Revenue down.

Margin down.

Customer complained.

Job late.

Those are useful.

They are also often late.

What earlier measure would have warned you?

Revenue down:

Pipeline perhaps fell months earlier.

Margin down:

Labour overrun perhaps appeared weeks earlier.

Late project:

Milestones may have slipped repeatedly.

Customer complaint:

Response time may have deteriorated.

ONS's structured-management framework includes the use and review of KPIs precisely because responding effectively to problems depends partly on seeing performance early enough to manage it.

Build a small number of leading indicators around your most important processes.

You want warning.

Not an autopsy.

Problem 13: Nobody reviews recurring failures

A customer complaint is resolved.

Ticket closed.

Move on.

Same issue next month.

Resolve.

Close.

Next.

The company has customer service.

It does not have continuous improvement.

Track recurring categories.

Which errors happen repeatedly?

Which customer complaints repeat?

Which projects overrun for the same reason?

Which invoice errors recur?

Which emergency purchases occur again?

Pattern recognition turns reactivity into improvement.

Problem 14: Process changes are not fed back into the process

Someone discovers a better way.

Great.

They now use it personally.

The official SOP remains unchanged.

Another employee follows the old process.

Two realities emerge.

This is how process drift happens.

Create a simple method for updating standard work.

It does not need a governance committee of seventeen people.

Someone owns the process.

Changes are reviewed.

Approved where necessary.

Communicated.

Documentation updated.

Training adjusted.

Now learning becomes organisational.

Problem 15: Nobody owns continuous improvement

Ask:

Who is responsible for improving how this process works?

Common answer:

“Everyone.”

Dangerous.

Everyone should contribute.

Someone should own it.

Perhaps:

Operations Manager owns scheduling.

Sales Director owns opportunity management.

Finance owns invoicing.

The process owner should understand:

Performance.

Recurring failures.

Current version.

Cross-functional dependencies.

They do not perform every task.

They are accountable for the health of the system.

Problem 16: Technology created another layer rather than removing one

Old process:

Spreadsheet.

Email.

New process:

CRM.

Spreadsheet.

Email.

Teams message.

Congratulations.

Digital transformation.

Article #80 covered software evaluation in detail.

Technology should reduce:

Duplication.

Delay.

Manual transfer.

Invisible information.

If every system needs somebody manually copying data into another, the business has automated very little.

The more tools you add, the more important information ownership and integration become.

Problem 17: The owner keeps bypassing the system

This one may hurt.

Owner says:

“Everyone needs to follow the process.”

Then an important customer calls.

Owner promises something outside the process.

Employee objects.

Owner says:

“This one's different.”

Perhaps it genuinely is.

But every owner exception teaches everybody else how seriously the process should be taken.

If you need the ability to override it, define:

When.

Why.

Who gets informed.

What downstream consequences must be considered.

Owner authority is real.

So is owner responsibility for what their intervention creates.

Problem 18: Customers have learned they can bypass the process

Customer knows:

Normal email takes 24 hours.

WhatsApp the owner and it happens immediately.

What will they do?

WhatsApp the owner.

Or:

Normal change request requires planning.

Call Sales Director directly and ask for a favour.

Now your process competes with a faster unofficial route.

Availability Architecture matters here.

If you repeatedly reward escalation with faster service, you train people to escalate.

You need to make the normal route work well enough that escalation remains exceptional.

Problem 19: Employees are solving for their department, not the whole system

Finance introduces controls.

Operations slows.

Operations changes scheduling.

Sales suffers.

Sales creates workaround.

Finance loses visibility.

Nobody intended the overall mess.

Each department improved its local problem.

This is called local optimisation in various operational contexts.

The practical question is:

Did we improve the process, or did we simply move the inconvenience somewhere else?

End-to-end ownership matters precisely because departmental performance can improve while customer experience or overall efficiency gets worse.

Problem 20: The business grew but the process did not

Processes have capacity too.

At:

Five employees

you can shout across the room.

At:

Twenty-five

that becomes unreliable.

At:

Seventy-five

it becomes ridiculous.

Growth adds:

Handoffs.

Managers.

Locations.

Transactions.

Specialists.

Exceptions.

Article #86 will look more specifically at why standards can start slipping during growth.

For now, ask whether your current systems were designed for the business you used to be.

Something can work brilliantly at £2 million turnover and become completely inadequate at £8 million.

That is not necessarily failure.

The company changed.

The operating system needs changing too.

Stop asking, “Do we have a process?”

Ask five better questions.

1. Does the process describe reality?

Watch the work.

Not the PowerPoint.

Where do people actually deviate?

Why?

2. Can the process handle normal variation?

Not every customer and job will be identical.

What happens when reality differs?

3. Do people have the capacity and authority to follow it?

A process requiring three hours when employees have one is fiction.

4. Do we know whether it is working?

Measures.

Feedback.

Exceptions.

Recurring failures.

5. Who improves it?

Someone needs to convert experience into better standard practice.

Those five questions tell you considerably more than whether an SOP exists.

Run a reactivity audit

For the next four weeks, capture every meaningful firefighting event.

Not every tiny interruption.

Things that:

Disrupt plans.

Require management escalation.

Create customer problems.

Cause overtime.

Damage margin.

Delay other work.

Require owner involvement.

For each event, record briefly:

What happened?

What was the immediate cause?

Where should the issue normally have been controlled?

Why wasn't it?

Was this truly unpredictable?

Has something similar happened before?

Then review the patterns.

Classify the fires

You will probably find categories.

Demand problem

Too much work entered.

Capacity problem

Insufficient people, equipment or time.

Handoff problem

Information or responsibility broke between functions.

Decision problem

Work waited for authority.

Information problem

Nobody knew something early enough.

Process-design problem

Official method does not match reality.

Compliance problem

Good process exists but is not being followed.

Management problem

Recurring issue is known but never permanently addressed.

Customer-boundary problem

Promises or exceptions repeatedly bypass normal control.

System problem

Technology or data does not flow properly.

Capability problem

People lack knowledge or training.

Now the word reactive becomes diagnostic rather than emotional.

Then find the Pareto of chaos

You may log 70 incidents.

Do not try to fix 70 things.

Perhaps:

Twenty-three relate to incomplete Sales handovers.

Fourteen relate to scheduling changes.

Eleven relate to missing approvals.

The majority of chaos may come from three underlying causes.

Start there.

Remove repeated causes.

Do not improve your ability to firefight all 70.

Trace each recurring problem upstream

Customer complains about late delivery.

Immediate cause:

Job started late.

Why?

Materials arrived late.

Why?

Ordered late.

Why?

Job was released to Purchasing late.

Why?

Scope remained unclear.

Why?

Sales handover was incomplete.

Now the intervention is not:

Tell Logistics to try harder.

The visible fire occurred in Logistics.

The system failure began in Sales handover.

This is the level of diagnosis you need.

Distinguish root cause from “five whys theatre”

Do not make people perform ritualistic questioning until somebody says:

“Because communication.”

The purpose is not exactly five questions.

It is understanding enough of the causal chain to change something useful.

Sometimes there are multiple causes.

Capacity plus poor handover plus unreliable supplier.

Fine.

Real businesses are messy.

Use judgement.

Decide whether to standardise, resource or redesign

Once you understand the cause, choose the appropriate intervention.

Standardise

The right method exists but is inconsistent.

Train.

Simplify.

Reinforce.

Resource

The process works but does not have enough capacity.

Add people.

Time.

Equipment.

Management.

Redesign

The process itself creates delay or failure.

Change it.

Automate

Repetitive manual work is causing avoidable errors or delay.

Delegate authority

Work repeatedly stalls at approval points.

Improve information

Management discovers problems too late.

Change commercial boundaries

Customers or Sales keep introducing work the operation cannot absorb.

Different problems need different medicine.

Create escalation rules

A reactive organisation often escalates either:

Everything.

Or nothing until disaster.

Define what should genuinely escalate.

Perhaps:

Margin below threshold.

Safety issue.

Contract variation above value.

Customer at risk.

Delivery failure above defined impact.

Cash exposure.

Legal or regulatory issue.

Everything else remains with the appropriate role.

This keeps leadership attention available for situations that genuinely deserve leadership.

Introduce protected planning horizons

Different businesses need different horizons.

Maybe:

Today.

This week.

Next four weeks.

Next quarter.

The point is to stop today's noise consuming all attention.

For example, an Operations review might look ahead four weeks and ask:

Where is capacity tight?

Which materials are at risk?

Which customers need decisions?

Which projects are likely to overrun?

That is proactive management.

You are deliberately finding tomorrow's fires while they are still smoke.

Build an interruption threshold

Not every problem needs to interrupt the current plan.

Ask:

Does this need resolving:

Now?

Today?

This week?

At the next review?

Without thresholds, urgency becomes contagious.

One person's concern becomes everybody's interruption.

This is where Article #63 on prioritising when everything feels urgent becomes useful.

The organisation needs the same discipline the individual owner does.

Protect improvement time

This is difficult precisely because improvement is rarely urgent.

The process review can wait.

The customer screaming cannot.

So improvement repeatedly moves.

And the customer keeps screaming.

Managers need protected time for:

Process review.

Root-cause work.

Training.

Documentation.

System improvements.

Capacity planning.

If 100% of management time is consumed running today's operation, the operation is unlikely to become substantially better.

You need some capacity to work on the system.

Better beats busier

This is where Agency becomes particularly relevant.

Work ethic asks:

How quickly can we solve today's twenty problems?

Agency asks:

Why did these twenty problems exist?

Work ethic matters.

There will always be moments where everybody needs to pull together and get something sorted.

But an organisation running permanently on exceptional effort has failed to turn learning into system improvement.

You do not want the world's best firefighters.

You want fewer fires.

A practical 90-day Reactive-to-Managed reset

You do not need to redesign the entire company.

Choose the area generating the most repeated disruption.

Weeks 1–2: Observe

Capture incidents.

Watch real work.

Talk to the people doing it.

Do not start by rewriting procedures.

Week 3: Diagnose

Group recurring problems.

Identify the few causes responsible for disproportionate disruption.

Weeks 4–5: Redesign

Decide what needs changing:

Input standards.

Handoffs.

Authority.

Capacity.

Technology.

Customer promises.

Process steps.

Weeks 6–7: Test

Run the revised method in real work.

Watch exceptions.

Do not assume the whiteboard version is correct.

Weeks 8–10: Standardise

Once it works:

Document enough.

Train.

Clarify ownership.

Set measures.

Weeks 11–13: Review

Did:

Escalations fall?

Customer issues fall?

Overtime reduce?

Jobs move faster?

Management interruptions drop?

If yes, keep improving.

If not, learn again.

That is continuous improvement.

Your scorecard should measure reactivity too

If reactivity is a real business problem, measure evidence of it.

Possibilities include:

Emergency purchases.

Owner escalations.

Late schedule changes.

Jobs started without complete information.

Overtime caused by avoidable planning failure.

Customer complaints caused by handoff failure.

Projects requiring senior rescue.

Do not collect twenty metrics.

Choose the few matching your recurring problems.

Then see whether improvement work changes them.

Management meetings should ask what stopped recurring

This is a better question than:

“What problems did we solve this week?”

Ask:

What recurring problem did we eliminate?

What process got better?

What dependency reduced?

What previously required escalation but now works normally?

This changes management attention from:

Activity.

towards:

System capability.

Some reactivity is healthy

This needs saying.

You do not want a business so rigid that employees cannot adapt.

Customers change.

Markets move.

Something unexpected happens.

Good businesses respond.

Being responsive and being reactive are not identical.

Responsive means:

We can adapt deliberately when reality changes.

Reactive means:

Reality repeatedly controls our priorities because we failed to anticipate, design or manage normal variation.

The objective is not zero interruptions.

It is making genuine exceptions exceptional again.

Do not process the life out of the company

There is another extreme.

Every previous mistake produces:

Another form.

Another approval.

Another field.

Another rule.

Eventually simple work becomes impossible.

People circumvent the bureaucracy.

Now management introduces another compliance rule.

Please stop.

Process should make good work easier and more reliable.

Not protect the company from every conceivable human judgement.

Where competent people can make sensible decisions within boundaries, let them.

The best process may be:

Three clear rules.

Not thirty-seven steps.

The strongest process is often the one employees want to use

Because it:

Makes sense.

Saves time.

Prevents mistakes.

Gives clarity.

Reduces repeated questions.

Allows them to get the job done.

If the official process constantly fights the people using it, investigate before blaming the people.

That is not softness.

It is operational intelligence.

Your business does not need more laminated folders

It needs fewer repeated surprises.

So if the organisation is permanently reactive despite having processes, stop writing procedures for a moment.

Look at the operating environment around them.

Are inputs reliable?

Are handoffs clear?

Is capacity realistic?

Can people make decisions?

Are priorities stable?

Does Sales respect delivery constraints?

Do systems communicate?

Do managers review recurring failure?

Does leadership override the rules?

Does anybody actually improve the process after learning something?

That is where the real system lives.

The procedure is only one component.

Processes do not make a business proactive.

Management closes the loop.

Plan.

Do.

Check.

Act.

Learn.

Improve.

Then make the next supposedly urgent problem slightly less likely to exist at all.