Every automation program has a version of the same story. A team identifies a painful process, a vendor lifts every step into RPA, and six months later the program owner is defending why the bots cost more to maintain than the people they replaced.
The mistake is mechanical: automating the current state instead of the target state. Current-state automation inherits every workaround, every historical exception, every polite cover-up the humans invented to keep the process working. The bots inherit them too.
Three questions that fix most of it
- What is this step for? If the step exists because a manager asked for a control in 2019, you don't automate the control: you remove it or replace it with a better one.
- Who is the customer of this step's output? If the output is a spreadsheet that nobody has opened in a quarter, you don't automate a bot to produce it faster.
- What breaks if this step disappears? If nothing breaks, delete it. You've just avoided a year of bot maintenance.
What 'target state' actually means
A good target-state design names three things explicitly: the system of record (where truth lives), the control points (who signs off on what), and the exceptions (what leaves the process to a human, and on what rule).
Once those three are named, the automation is obvious: RPA for the deterministic clicks, an agent for the exceptions, humans for the high-stakes calls. Skipping this step is what leaves enterprises with bot farms that cost more than the labour they replaced.
A focused engagement can do this
We run process engineering as a focused engagement: a discovery phase (shadow the team, capture current state) and a design phase (redesign the target state with the team, get sign-off). The output is a BPMN diagram, a controls matrix, an exception policy, and a backlog scored for automation fit.
After that engagement the automation program gets faster, cheaper, and, most importantly, it stops shipping bots that nobody can explain a year later.