For companies embarking on introducing RPA to their organisation and doing everything inhouse, these are the cost factors to consider for developing and running their own RPA automations:
RPA needs to be instructed what to do. To do this, a script is writtten (in other words code for the Robot). This code comprises of instructional code blocks. For instance, one block might instruct the robot to ‘Open Browser’, while another might ask the Robot to read some text and conclude a next action.
At Autane, we use an RPA ‘instructional’ language called Robotframework which is built with Python code blocks, either ‘off-the-shelf’ code written by other developers or custom instructions written by our own developers to conduct more tailored actions for our clients and their office tasks.
At time of writing this article, dayrates for a Salaried RPA Developer range from £228 to £428 per day, and anything from £334 to £675 per day using an RPA Contractor. So considering it can take a RPA programmer anything from 3 to 20+ days to deliver a ‘production’ ready Bot, and using a professional inhouse RPA developer, it will cost anything from £700 to £8,500+ per project to program an RPA Bot, and anything from £1,000 to £13,500+ per project using an RPA Contractor.
Note if the company opts for a Robots-As-A-Service (RAAS) such as a company like ourselves, the initial outlay is much much lower. More on this later.
For those delivering RPA using their own inhouse team, not surprisely the more complex the task to be programmed, the longer it will take to code, and subsequently the higher the investment cost and slower the payback.
Complexity is not a bad thing per se though, particularly if the benefits of automating the process are enough to provide a favourable payback. But of course, it is important to get an estimate of development complexity and programming costs so the business case can be assessed before embarking on the project. So, what factors affect development time and how can they be used for an estimate?
How many applications, screens and other process steps are involved?
If you only have a few steps in the process, using only one software application, then clearly this is going to be the easiest to program and implement. That said, it is possible to automate processes of 20 steps or more cost effectively. At Autane, we have automated tasks with process steps well over 20, and multiple applications.
As a rule of thumb for a first time RPA project, multiply the process steps by 1 hour per step to provide an approximate development time. Every step will not take 1 hour to program, but some might take several hours to complete, while others might take less than 15 mins, hence averaging this way accounts for this.
First time RPA process for this Software application?
Although there is a common approach to structuring a software application, behind the scenes the application developers can have their own ways of presenting text fields and buttons to the screen. Accordingly for the RPA developer, it means for a first RPA automation on this application, that they have to spend more working out how things work and how to get the Robot to interact with the software effectively.
It is like building a working relationship with a new client. Initially it takes times to work out how the client wants things done. Thereafter however, the supplier knows how to deliver in the way the client wants it, and it tends to be plain sailing.
When an RPA programmer is dealing with a new software application, they need more time to get to know it and it can add up to 50-100% more time.
Quality of the specification – Process Design Document (PDD)
The specification document used for RPA development is known as a Process Development Document (PDD). This is an important document, both for the client to outline to the developer what they want the RPA Bot to do, but also for the developer themselves. In fact, a thorough and easily understandable PDD makes development much easier. If all the developer needs to know is in the Process Design Document and there is no need for toing and froing between the client to answer questions, the programming exercise is much quicker.
The quality of the PDD in turn is dependent on the availability of a Subject Matter Expert (SME); someone who knows the process in depth and can help document it accurately.
Without an SME on board and/or a quality PDD, you can multiply development time by 25% or more.
Number of Exceptions – what to do if certain situations happen.
An exception occurs when the Bot comes across something that does not follow the main automation path, an ‘Exception’ from it. They can be split into System and Logic exceptions.
An example of a System exception is when the robot struggles to log into a software application. If the Bot’s program has not been designed to cope with this situation, the automation will just fail and cause an error. RPA developers will need to add a specific code to deal with this situation so the automation can self-recovery and continue, or inform a human.
Logic exceptions generally describe transactions that do not fit into the expected format. So, for instance, if the Bot inputs a part number and two records appear when normally only record should be present, the developer will need to instruct the Robot how to deal with it.
As you imagine, the more exceptions that the RPA developer needs to cater for, the more time it will take. Generally, add 1-2 hours per exception.
Is the input Digital?
It is easier to program the Bot if the process inputs are digital. For example, information submitted on a digital form or PDF, or involving a copy and paste of data from one digital document/application and then processing it on another.
All is not lost if the inputs into the process are perhaps scanned on a printer. The difference though is that with digital inputs the characters are automatically understandable for the Bot, whereas in a scanned document they are presented to the automation as an image, and the words and characters need to be read. This is known as Optical Character Recognition (OCR).
OCR is quite complex but today it is possible just integrate the RPA program with external OCR services which take a text image and translate it into a string of characters, buying the service on a per document basis. The document input might then need some pre-processing or some extra manipulation to get a satisfactory level of accuracy though. Understandable this takes extra time and can take a developer a day or more to get right.
Adding Brain Power/AI ?
Again, complexity will increase if the Bot requires extra brain power and a highly level of cognitive ability. The processes that are easiest to automate follow a set pattern of decisions and centred around a fixed number of options. On the other hand, if the Robot needs an algorithm in order to determine an outcome, and Machine Learning might be necessary, it will naturally require extra developer time.
In addition, if the input data is not structured, and needs to be extracted from a block of text, then this also requires additional development time, perhaps involving some type of Neuro Linguistic Processing (NLP).
Again, the Bot can tap into an external service for this, which makes the reading and extracting process easier, but AI could add anything from a day or two, or even double the amount of programming time necessary if it involves writing unique code.
Test and ‘Babysitting’ time
A good developer will take the PDD and create a test schedule from it. In a way, this is about translating and making a list of the process steps the client wanted, and testing that the robot does each of them correctly. However even if the Bot passes the test, it might still experience some bugs.
Humans are very adaptable and will automatically, and subconsciously, change how they do something if presented with some data which does not fit into a specified format. So if a human comes across an expected exception, they will probably just deal with it and adapt, perhaps without registering that is what they are doing.
Robots on the other hand, can only do what they are programmed to do. You can create some flexibility with exception handling, but if these subconscious actions are missed from the PDD, then the Bot might fail in production. Consequently, it is important that new RPA automations are ‘Babysat’ by a developer, with live data, so these anomalies can be programmed out.
Hence, add at a day or two to fully test/debug a process and to babysit the first runs.
Recently amongst the RPA community there has been debate surrounding Low Code platforms and the idea of ‘Citizen Developers’. The idea is that you can train internal staff to use low code RPA platforms so they can develop their own automations to automate aspects of their own work. These platforms tend to have a graphical drag-and-drop interface that creates an RPA flowchart and automatically the actions to go along with it, such as clicking a mouse, entering data into a field etc. Platforms with this sort of interface include UiPath, BluePrism and Microsoft’s Power Automate.
On first impression this sounds like a great, and almost utopian idea. Your employees actually make their own Bots to perform their work more efficiently, with the whole organisation becoming more productive and responsive as a result!
For larger organisations, this approach might be possible, but there are a few issues with this approach which are particularly relevant to smaller organisations:
- Does the organisation have the time to train internal staff and support them to deliver RPA automations?
- What happens if these ‘Citizen Developers’ move on, together with their skills. Who maintains and runs these robots then?
- Some of these low code platforms only supply robots on annual license. Hence if your only fulfilling half the capacity of the license, the cost per minute to run the Bots are effectively doubled. Accordingly, if you do not fill the Robot’s capacity you might not see the benefits
- There is only so far which the skills of Citizen developers will stretch, and applications could be limited to basic automations and limit the scope of the projects.
In reality then, most organisations are far more likely to use their own inhouse developer or a professional contractor for their RPA projects at the rates above.
Regarding running costs, the day to day running costs of an RPA robot can be anything from £zero per hour (if everything was programmed in a core language such as Python or .NET, and run on a completely open source program on a local computer/server), to between £2+ per hour if the Bot runs on a hosted server and its activities are managed by an orchestrator (control centre). However as I mentioned above, some RPA platforms only license the Bots by the year. So if you don’t utilise the Bot 24/7/365, the effective hourly running costs can be much higher per hour.
Autane provides a RAAS service, and our prices for run time minutes might seem higher, however our customers only pay for the time the Bot is actually running. Our prices still provide very attractive savings and benefits to our customers though. You can estimate your own RPA project costs and payback using our online RPA Cost and Payback Estimator tool.
RPA Bots operate in environments where they do not normally have control. What we mean by environments is the Software Applications and Platforms which the RPA Bots perform actions on, and these are managed and updated by other companies. If those companies change the user interface for instance, while a human will just click the new button (in the new HTML structure), the Bot needs to be told this. Also new upgrades can cause an RPA robot to fail. For instance, new and unexpected PopUps which might appear, or a change to the protocol when and after logging into a system. All these scenarios need maintenance and specifically additional code added to the RPA robot.
As an estimate, the cost of maintaining an RPA Bot is anything from 10% to 20% of the initial development costs per year. So, according to above, anything from £70 to £1,700 per year based on the lower and upper development figures above.
Our RAAS pricing includes maintenance, and without a longterm contract, it’s in our interest to keep the Bot running and customers happy with the service.