How many RPA Bots are needed?
A little bit of research has suggested that RPA could be a solution but how many Bots (Software Robots) will be required.
Of course, RPA vendors will try to sell “Bundles” of Bots for their commercial advantage and hope to get a business committed to lots of usage.
Generally, businesses want to start with “One” process, implement that automation to verify that the ROI is attractive before making further investments.
That desire raises the question, “How many RPA Bots?”
Not all RPA Bots are equal.
RPA can be categorized into attended and unattended automation.
- Attended bots work alongside humans and are triggered by user actions.
- Unattended bots operate independently and can run tasks without human intervention.
Calculating the number of Attended RPA Bots, is simple. One per person involved in the interaction with the automation.
The choice between attended and unattended automation will influence the number of bots needed. Unattended bots can operate 24 x 7, potentially reducing the total number of bots required.
How much work can a single RPA Bot complete?
RPA has been created to automate activity that a person would otherwise perform on a computer system.
One way to consider the capability is if the RPA Bot is working at the same speed as a person, how many people performed that activity?
RPA Bots can react faster than a person, particularly over an extended period and when doing “Boring” work. Speed of processing often becomes limited by the response of the system that the RPA Bot is engaging with.
RPA Bots can make use of APIs (Application Programme Interfaces) which are technical and not used by people but can deliver the same functionality, at speed and are usually more reliable than GUI screens.
When an automation is created with RPA Bots using APIs they are usually faster at completing the work than a person.
Yes, it is obvious, but an RPA Bot can only complete work when it is available.
This matters as RPA Bots might provide available capacity 24 hours a day, but there might not be work available for some of the hours.
RPA Bots – examining some details
Each RPA Bot can only do one thing at a time.
Most RPA solutions are not designed to exploit complex threading within the processing of a single Bot.
The RPA vendors will have exploited threading within the technology but that is not generally surfaced to be used in the design individual automations.
UiPath software does expose a bit of capability to exploit threads with its ability to separate “Foreground tasks” (e.g. Involve a GUI action) and “Background tasks”.
This provides the potential for multiple “Background tasks” to be executed “Concurrently” by using the CPUs threading architecture.
Drains on RPA Bot performance
The drains on RPA Bot performance are often in the design of processes rather than the pure execution time.
- The time RPA Bot processes wait for work to be available – “idle time”.
Each “Start” and “Stop” of an RPA Bot incurs a portion of processing time that can be considered as “Overhead”.
The “Overhead” is the time taken for the RPA Bot to establish connection with the Orchestrator, verify the licence, determine the process to be executed, verify the version of the code on the Bot is current, communicate log information and monitoring information with the Orchestrator, etc.
When performance is a key factor, it can be more effective for an automation to be designed with a “Repeated” checking for available for work rather than a more frequent “Starting” and “Stopping” of an RPA bot. It uses CPU in the checking activity but reduces the “Overhead” processes.
A very modular design will offer attractions from an architectural perspective, but it may perform worse that a large single block of code.
When performance is a major consideration, factors such as:
- the CPUs used for RPA Bot execution
- the speed of the network
- the speed for the storage devices
should be thought about as an alternative to simply providing more RPA Bot licences.
During the development of an automation, it is good practice to generate very detailed information into log files so that the logic can be investigated and debugged effectively.
Once an RPA Bot is executing an automation in production, the amount of information to be logged for monitoring purposes should be a lot less than during development. Minimizing RPA Bot log activity will increase performance.
Perspective on number of RPA Bots
In an ideal world it would be possible to forecast exactly how many RPA Bots will be required before a project starts so that a financial budget can be set.
For a first RPA implementation there is often not enough detailed performance information available on the systems that will be used in the automation to project the required capacity with a high degree of accuracy.
If the design for the automation is scalable, it should be possible to add additional RPA Bots into the production solution as late as the User Testing activity in the project. This would provide one solution to a performance challenge.
Manging RPA Bot workload
There can be a trade-off to be made between the cost of additional RPA Bots and some work taking longer to complete.
Workload peaks and troughs can require careful consideration not just from a technical perspective but also from a business priority angle.
One of the strengths of RPA Bots is that they can be assigned any task.
For scenarios where there is a pool of available RPA Bots, the appropriate priority setting for automation tasks can be really helpful.
The pool capacity can be focussed on processing Priority 1 tasks as quickly as possible. When there is available capacity within the pool, the configuration might execute a range of automations some of which could have long processing times.
A design consideration for automations that could incur long elapsed time, is to design for workload to be “Parked” and resumed later should there be a need to process higher priority workload.
Automations with No People!
RPA Bots are usually considered to replace work performed by people.
There can be scenarios, where an automation is required for a process which has never been performed by a person.
Estimating the number of RPA Bots required will still need to consider workload, concurrency and elapsed times. Some prototypes may be necessary to gain some benchmark data.
For more information on Robotic Process Automation (RPA) as well as Agentic Automation and the journey to implement automation please see our website: https://www.ether-solutions.co.uk/.
Manager’s Guide to Automation: https://www.ether-solutions.co.uk/managers-guide-to-automation-using-software-robots/
#businessbeyondautomation
Article Author
David Martin
Managing Director, Ether Solutions
https://www.ether-solutions.co.uk/
