Anna Totterdell
Projects Director
The most common mistake in operational improvement is trying to fix everything at once.
You have read the articles. You understand that your data is messy, your systems are disconnected, your processes depend on individuals, and your spreadsheets are doing jobs they were never designed for. The problems are clear. The temptation is to launch a broad programme that addresses all of them simultaneously.
Do not do that.
Broad programmes fail. They take too long, cost too much, lose executive attention, and deliver results so slowly that the business loses faith before anything meaningful changes. The graveyard of mid-market IT and process strategy is littered with "transformation initiatives" that started with ambition and ended with a PowerPoint nobody reads.
Instead, do one thing. Do it properly. Do it end to end. And use the result to prove that this approach works.
How to pick the right process
Not every process is worth fixing first. You need to pick one that meets three criteria:
It is high-pain. The people who run it are frustrated by it. It consumes disproportionate time. It creates errors that cost money. It delays decisions. Leadership hears about it regularly, even if they have not acted on it.
It is high-visibility. The results of fixing it will be obvious to people beyond the immediate team. If you automate something that nobody notices, you have not built momentum. You need the improvement to be felt across the business - or at least across leadership.
It is bounded. The process has a clear start and end point. It touches a manageable number of systems. It can be mapped, fixed, and measured within weeks, not months. Avoid processes that sprawl across the entire organisation or require every system in the business to be connected before they can improve.
Common candidates: order processing, monthly financial reconciliation, client onboarding, supplier management, board reporting, invoice approval chains, HR onboarding workflows.
The right choice is usually the one that makes experienced people sigh when you mention it. The one that everyone agrees is painful but nobody has prioritised.
Map it honestly
Once you have chosen the process, map it as it actually works. Not the policy version. The real version.
Sit with the people who execute it. Walk through every step from trigger to completion. Where does the request come in? Who touches it first? What system do they use? What data do they enter? What happens next? Where does it move? Who approves it? Where does it get stuck? What are the common exceptions? What workarounds exist?
Document the manual steps - the emails, the spreadsheet lookups, the "I check with Sarah" moments. These are the places where time is lost, errors are introduced, and dependency on individuals is created.
The output should be an honest, detailed map of the process as it is today. It will not be pretty. It is not supposed to be. It is supposed to be accurate.
Identify the waste
With the map in front of you, the waste becomes visible.
Look for re-entry: places where the same data is entered into multiple systems by different people. Look for waiting: places where the process stalls because someone needs to approve, check, or forward something manually. Look for reconciliation: places where someone spends time making sure two sources of data agree. Look for workarounds: places where someone has built a personal system (usually a spreadsheet) to compensate for something the official systems cannot do.
Each of these is a specific, addressable problem. Not a vague inefficiency - a concrete point in the process where time, cost, or risk is being created unnecessarily.
Quantify them. How many hours per week does the re-entry consume? How many days does the average approval delay add to the cycle? How many errors per month does the reconciliation catch - and how many does it miss? Put numbers on it. Numbers are what turn "we should probably fix this" into "we are fixing this."
Fix it end to end - not one step
The critical principle: fix the entire process, not just a piece of it.
The temptation is to automate one step - the most obviously painful one - and declare victory. Resist that. Business automation applied to a single step within a broken process just moves the bottleneck. The step before it is still manual. The step after it is still manual. You have made one piece faster while the whole chain remains slow.
The process needs to be addressed from trigger to completion - systems connected, data structured, handoffs automated, exceptions handled. What that delivery actually looks like in practice, and how long it takes, is a separate question. But the scoping principle is non-negotiable: end to end, or not at all.
Set your baseline before you start
Before anything changes, agree on what you are measuring. How long does this process take today? How many manual touchpoints exist? How many errors occur per month? What do those errors cost?
These numbers are your baseline. Without them, you cannot prove the improvement - and without proof, you cannot build the momentum to do this again. The first process you fix is not just an improvement. It is the evidence that justifies everything that follows.
Why one process changes everything
The first process you fix is not just an improvement. It is a proof point.
It proves that mapped processes, structured data, and connected systems - the basics of data and systems integration - produce measurable results. It proves that the approach works in your business, with your systems, with your team. It proves that this is not theoretical.
And it creates demand. The team that benefited from the improvement will tell other teams. The leadership team that saw the metrics will ask what else can be done. The finance director who saw the cost reduction will want to apply the same approach elsewhere.
That is how operational improvement scales - not through a grand transformation programme, but through one visible success that creates appetite for the next one.
Pick the process. Map it. Fix it. Measure it. Then do it again.
