If you’re planning on introducing RPA to your organisation and doing everything in-house, we’ve broken down the various costs involved in developing and running your own RPA automations, so that there are no surprises and you know exactly what you’re paying for at all times:
Scripting
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 the next course of 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.
It can take a RPA programmer anything from 3 to 20+ days to deliver a ‘production’ ready bot.
Based on these time frames, a professional inhouse RPA developer will cost anything from £700 to £8,500+ per project, and a contractor will cost anything from £1,000 to £13,500+ per project.
When you choose Robots as a Service (RaaS) when working with us, then the initial outlay and monthly costs are significantly lower than when working with a developer directly.
Development Complexity
When you deliver RPA using you own in-house team, it’s not surprising that the more complex the task to be programmed, the longer it will take to code. This also means your investment will be higher and the return on investment (ROI) will be far slower.
Complexity is not a bad thing in and of itself though, particularly if the benefits of automating the process are enough to outweigh the initial complexity of programming the RPA bot.
However, it’s always important to gain an understanding of development complexity and programming costs so the business case can be assessed before embarking on the project.
Here’s a look at 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 this is going to be the easiest to programme and implement.
However, it’s possible to automate processes of 20 steps or more and it still be cost effective.
At Autane, we have automated tasks that contain well above this, and include 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.
Each step won’t necessarily take 1 hour to programme, but some might take several hours to complete, while others might take less than 15 mins, so averaging this way helps to provide a more accurate estimate.
Is this the first time an RPA process has run on this Software application?
Although there’s a common approach to structuring a software application, behind the scenes the application developers will have their own ways of presenting text fields and buttons on the screen.
For the RPA developer, it means that the first RPA automation running on a software application, that they have to spend more time working out how things work and how to get the robot to interact with the software effectively.
Much like building a relationship with a new client, it will take some time to work out how they prefer things to be done.
When an RPA programmer is dealing with a new software application, they need more time to get to know it – adding up to 50-100% more time.
Quality of the specification – Process Definition Document (PDD)
The specification document used for RPA development is known as a Process Definition 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 Definition Document and there is no need for constant back and forth 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’ll see an increase in development time by 25% or more.
Number of Exceptions
An exception occurs when the bot comes across something that does not follow the main automation path, and is known as 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 programme 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-recover and continue, or inform a human so that they can step in.
Logic exceptions generally describe transactions that do not fit into the expected format.
So, for example, if the bot inputs a part number and two records appear when normally only one record should be present, the developer will need to instruct the robot on how to deal with it.
The more exceptions that the RPA developer needs to cater for, the more time it will take to programme. Generally, add 1-2 hours per exception.
Is the input Digital?
It is easier to programme 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 done using a non-digital document, for instance one which has been scanned.
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 and digitised.
This is known as Optical Character Recognition (OCR).
OCR is quite complex, but today it’s possible to just integrate the RPA programme 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. Understandably, 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 again increases developer time.
In addition, if the input data is not structured, and needs to be extracted from a block of text, this also requires additional development time, perhaps involving some type of Nature Language 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
If it’s not included already, a good developer will take the PDD and create a test schedule from it.
However even if the bot passes these tests, 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, and not programmed in the bot, then it 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 if necessary.
This is why it’s essential to add at a day or two to fully test/debug a process and to babysit the first runs.
Citizen Developers
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
- The skills of Citizen developers will only stretch so far, and applications could be limited to basic automations and limit the scope of the projects.
Based on these issues, most organisations are far more likely to use their own in-house developer or a professional contractor for their RPA projects.
Running Costs
Regarding running costs, the day to day running costs of an RPA robot can be anything from £0.00 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 annually, 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 while our prices for run time minutes might seem higher, our customers only pay for the time the bot is actually running.
Our prices still provide very attractive savings and benefits to our customers . You can estimate your own RPA project costs and payback using our online RPA Cost and Payback Estimator tool.
Maintenance
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.
New upgrades can cause an RPA robot to fail. For instance, new and unexpected pop-ups 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 any updates required to keep the bot running and customers happy with the service.