Insights / Perspective / Business process reengineering (BPR)
PerspectiveRedesign before you automate
Automating a poor process makes the problem faster. Why redesign should come first, which steps to remove and combine, and when a process is ready for technology.
Automation is easier to buy than ever. Workflow tools, robotic process automation, low-code platforms and AI assistants promise to take repetitive work off people’s desks in weeks. The temptation is to point them at whatever process is causing the most pain and automate it as it stands.
Automating a poor process makes the problem faster. Redesign first, automate second. A process with unnecessary steps, redundant approvals and frequent rework will still have all of them once automated. The difference is that they now run at machine speed, are harder to see, and are embedded in software that costs money to change.
Why the instinct is to automate first
The pressure to automate immediately is understandable. Staff are overloaded, backlogs are growing and leaders want visible progress. Automation feels concrete in a way that process redesign does not. There is a tool to buy, a project to launch and a demonstration to watch.
Redesign, by contrast, involves difficult conversations. It asks why steps exist, who owns them and whether they still matter. It may challenge long-standing habits, team boundaries and approval rights. It is slower to show results and harder to put in a slide.
Yet experience across many automation programmes points the same way. Projects that automate existing processes without examining them tend to deliver less than expected, need more exceptions handling than planned and break when the process changes. Projects that redesign first tend to need less automation, and the automation they do need works better.
Remove steps
Question every step that exists only for historical reasons.
Processes accumulate steps over time. A check added after a mistake years ago. A report produced for a manager who has since left. A copy sent to a team that no longer uses it. An approval required by a policy that has been superseded. Each step made sense when it was added. Many no longer do.
- For each step, ask what would happen if it stopped. If the answer is nothing, or very little, remove it.
- Ask who uses the output of each step. If nobody can name a user, the step is a candidate for removal.
- Ask whether a check catches real errors. If it almost never finds a problem, consider replacing it with a periodic sample.
- Ask whether the step exists because of a rule, and whether that rule still applies.
Consider a typical customer refund process. It might involve the service agent filling in a form, a team leader approving it, finance checking it, a second finance colleague approving the payment and an administrator updating a spreadsheet. Automating this as it stands would produce a workflow with five stages. Redesign might show that refunds below a set value could be approved by the agent, that the spreadsheet duplicates the system, and that one finance check is enough. The process that remains is simpler to automate, or may barely need automating at all.
Every step you automate is a step you maintain
Automated steps need testing, monitoring and updating whenever systems or rules change. Removing a step before automation saves not only its running cost but every future cost of maintaining it.
Combine handoffs
Fewer handoffs mean fewer delays and errors.
Every time work passes from one person or team to another, it waits in a queue, risks losing information and creates uncertainty about who is responsible. Automation can speed up the transfer, but it cannot remove the wait for someone on the other side to pick the work up, or the confusion when something goes wrong between teams.
Redesign can often combine steps so that one person or team handles more of the work end to end. A single case owner who can check, approve and complete a routine request removes several handoffs at once. Where specialist input is genuinely needed, it can be brought in as a consultation rather than a full transfer of responsibility.
Combining handoffs also clarifies accountability. When one person owns a case from start to finish, they can answer the customer’s question about where it stands, and they have both the reason and the means to fix problems as they arise. Automation built around that owner supports their judgement rather than replacing a chain of partial responsibilities with a chain of partial scripts.
Then automate
Apply technology to a clean, stable process.
Once unnecessary steps are gone and handoffs are reduced, the process that remains is a much better candidate for automation. It is simpler, so it costs less to build. It has fewer exceptions, so the automation handles more cases without human intervention. It is understood and documented, so the people building the automation know what they are building.
- Run the redesigned process manually for a few weeks to confirm it is stable before automating.
- Automate the highest-volume, most rule-based steps first.
- Design clear routes for exceptions, so cases the automation cannot handle reach a person quickly.
- Measure the same things before and after, such as cycle time, error rate and cost per case.
We had a robotic automation project lined up for our invoice process. The redesign workshop removed four of the nine steps. In the end we automated two, and the whole thing cost a fraction of the original estimate.
Finance director, logistics client
A practical sequence
Before approving any automation project, ask to see the current process map and the redesigned one. If there is no redesigned version, send the project back for a short redesign phase, typically a few weeks. Ask the team to show which steps they removed, which handoffs they combined, and what benefit the redesign alone delivers. Then approve automation for what remains. The project will be smaller, faster and more likely to deliver what it promises.
Source: Intelliversal analysis.
