Every automation programme 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 programme 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 two-week engagement can do this
We run process-engineering as a fixed two-week engagement: discovery week (shadow the team, capture current state), design week (redesign 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 programme gets faster, cheaper, and — most importantly — it stops shipping bots that nobody can explain a year later.