Your New System Won’t Fix an Old Way of Working

Business process improvement means fixing how work actually flows — removing unnecessary steps, clarifying ownership, eliminating inconsistency — before introducing new technology to support it. Most businesses do this backwards: they buy a system first and hope the software will straighten out a workflow that’s never been clearly defined. It doesn’t. Technology executes a process exactly as it’s given to it, inefficiencies included, just faster and with a better interface.

This isn’t an argument against digitising or automating. It’s an argument about sequence. A process has to actually work before it’s worth encoding into software — otherwise the business ends up paying for technology that makes an existing problem harder to see, not easier to fix.

“Old Process + New Technology” Is a Predictable Equation

This pattern is common enough to be almost mechanical: take a process nobody has reviewed in years, wrap it in a new system, and the outcome is nearly always the same — the same number of handoffs, the same approval delays, just running through a nicer interface.

Software doesn’t know a process is broken. It just executes whatever it’s told, faithfully and at scale.

Understanding the Existing Workflow Before Changing Anything

Most teams can describe their process in general terms but struggle to describe it precisely — who actually does each step, how long each one genuinely takes, and where exceptions get handled differently depending on who’s involved. That precision matters, because a process improvement effort built on a vague or idealised version of the workflow fixes a process that doesn’t actually exist.

The most reliable way to understand a workflow is to trace a handful of real, recent examples through it end to end — not the textbook version anyone would describe from memory, but what actually happened the last three or four times it ran.

Identifying the Real Bottlenecks

A bottleneck isn’t always the step that looks slowest. Sometimes it’s a fast step that depends on one person who’s frequently unavailable, or an approval that technically takes five minutes but sits untouched for three days because nobody owns prioritising it. Finding the real bottleneck means looking at where work waits, not just where work happens.

• Where does a task sit idle the longest before anyone picks it up?
• Which step depends on a single person’s availability rather than a role?
• Where does information get re-entered because two systems or forms don’t talk to each other?
• Which approvals exist out of habit rather than genuine necessity?

Removing Unnecessary Steps Before Standardising

Simplifying comes before standardising for a reason: there’s no value in making an unnecessary step consistent. A process with five approval layers doesn’t improve by making all five run identically — it improves by asking honestly which of the five need to exist. Removing a step is almost always more valuable than optimising it.

Standardisation: Making the Process the Same Every Time

Once a process is simplified down to its necessary steps, standardisation means everyone follows the same version of it — not a close approximation shaped by habit or personal preference. Two different staff members handling the same type of request should produce the same outcome, following the same steps, in roughly the same time.

This is the step that makes digitising genuinely useful rather than cosmetic. Software is excellent at enforcing a single, consistent version of a process. It is far less useful at accommodating five slightly different unofficial versions of the same workflow.

Introducing The Snazzy Process-to-Technology Fit Model™

To make this sequence concrete, we built The Snazzy Process-to-Technology Fit Model™ — six stages that move a workflow from its current, often messy state to a genuinely automated one, in the order that actually works.

Notice where technology actually enters this model: at stage four, not stage one. The first three stages — Understand, Simplify, Standardise — are entirely process work, and they are also the stages most frequently skipped under deadline pressure. Skipping straight to Digitise is exactly how a broken process ends up encoded into a new system instead of fixed by one.

The same sequencing problem shows up at rollout stage — see “Technology Doesn’t Fail. Implementation Does.” for what happens when a system is configured before the business is ready for it.

From Manual to Digital to Automated: Each Stage Has a Prerequisite

Manual, digital and automated aren’t three unrelated options to choose between — they’re a progression, and each stage depends on the one before it being genuinely solid. Automating a process that was never properly standardised just means the business now has an inconsistent process running without anyone watching it.

Involving the People Who Actually Do the Work

The people closest to a process — the ones doing it daily, not the managers describing it from a distance — usually know exactly where it breaks down, because they are the ones working around the breakage every day. Process redesign that happens without their input tends to fix the version of the process that exists on paper, not the version that actually runs.

Involving frontline staff early also solves a second problem: a redesigned process they helped shape is one they understand and are far more likely to follow once it’s standardised and digitised, rather than quietly reverting to their own workaround.

When Automation Actually Belongs in the Sequence

Automation is the highest-leverage stage in this model, and also the one most likely to backfire if it arrives too early. A process is ready for automation once it has been simplified, standardised, and has run reliably in its digital form for long enough to prove it’s stable — not the moment the budget for an automation tool becomes

Preparing Teams for Change

Process change fails as often from how it’s introduced as from how it’s designed. A team that experiences a change as something that happened to them, without explanation or involvement, tends to resist it quietly — reverting to old habits whenever the new version is inconvenient. Framing the change around the specific problem it solves, and involving the team in identifying that problem in the first place, consistently produces more durable adoption than announcing a finished redesign top-down.

Process Improvement Checklist

Before digitising or automating any workflow, check the basics:

☐  The current process has been traced through several real, recent examples — not described from memory

☐  Every unnecessary step or approval layer has been questioned and, where possible, removed

☐  The remaining process runs the same way regardless of who is executing it

☐  The people who do the work daily were involved in identifying what to change

☐  The process has run reliably in a simplified, standardised form before any automation is introduced

Frequently Asked Questions

Why does digitising a broken process make it worse instead of better?

Digitising preserves whatever steps, handoffs and delays already exist in a process — it just moves them into software. Without simplifying and standardising first, the business ends up with the same bottlenecks running at a higher speed, with added software cost on top.

What’s the difference between simplifying and standardising a process?

Simplifying means removing unnecessary steps so only what’s genuinely needed remains. Standardising means ensuring that remaining process runs the same way every time, regardless of who carries it out. Simplifying should always come first.

How do I know if a process is ready to be automated?

A process is generally ready once it has been simplified, standardised, and has run reliably in a digital form for long enough to prove it’s stable. Automating an untested or inconsistent process just scales the inconsistency.

The Takeaway

New technology amplifies whatever process it’s given — it doesn’t correct it. A business that digitises or automates a broken workflow without fixing it first ends up with the same problem, now running faster and harder to unwind because it’s embedded in a system rather than living in habit. Fix the process before you automate it, and the technology finally gets to do what it was meant to do.

Fix the process before you automate it.