How to Choose Processes for RPA: A Scoring Method That Works

Robotic process automation works best on high-volume, rules-based work that people do the same way every time. It works badly on processes that change often, depend on judgement or pull data from screens that move around. Picking well means the first bot pays for itself quickly and earns the trust you need for the next one.

On the treasury automation project at Access Bank, end-of-day GL reconciliation took over eight hours of analyst time every day. After automation it took 45 minutes. That kind of result starts with choosing the right process.

The first three measure value. The fourth measures complexity. You want high value and manageable complexity.

This is the scoring model inside the BA Workbench's Process & RPA Scorer:

• Frequency is worth up to 40 points, reaching the maximum at 40 or more runs a month.
• Manual effort is worth up to 35 points, reaching the maximum at 90 or more minutes per run.
• Error rate is worth up to 25 points, in proportion to the percentage of runs with errors.

That gives a value score out of 100. Complexity is rated separately: one system is low, two or three is medium, and four or more is high.

Here are three illustrative process steps from a finance operations team, scored with the model above:

Also look at the hours: the reconciliation report uses 44 hours of staff time a month, statement requests 67 hours and payment validation 45 hours. Scores rank the candidates; hours make the business case. Always show both.

A high score isn't enough. Before committing, confirm that the process:

• Follows clear rules. If people make judgement calls, capture those rules first or keep a human in the loop.
• Uses structured, digital inputs. Scanned documents and free-text emails need extra tooling.
• Is stable. If the process or the screens are about to change, wait.
• Has manageable exceptions. Define what the bot does when it meets something unexpected, and who picks it up.
• Has an owner. Someone in the business must own the bot's output after go-live.

Once a process is chosen, the bot specification should cover five things: what triggers it, what inputs it needs, the processing rules step by step, how each exception is handled and escalated, and what it outputs and to whom. On the treasury project, that meant mapping each process in BPMN first, then writing a specification per bot and running UAT with Finance, IT and Audit before go-live.

• The process is broken. Automating it just makes the mistakes faster, so fix the process first.
• A system change is coming that removes the manual work anyway.
• Volumes are low and the work is varied. People are cheaper and more flexible there.