Robotic Process Automation (RPA) is a type of automation that has gained momentum as companies are looking to implement automation in their businesses. As Head of Project Delivery, having worked with automation for over 15 years, I have seen first-hand that this can often be a very short-sighted approach. This is because it does not consider the overall complexity of orchestration.
Firstly, we must understand what RPA is. At a basic level, without resorting to dictionaries, it is a software application that replicates the actions of a human interacting with the user interface (UI) of another application. RPA allows you to interact with a single system and communicates with this in three ways:
- Thick client application management. The RPA technology interfaces with the controls of an application at an operating system level, regardless of how that application is displaying the information. For example, RPA will know that there is a text box and a button which are labeled and is why, with a little logic behind it, RPA will be able to fill in a form with given parameters.Thin client application management. The RPA technology interfaces with the components of the web page sent by a web server. This can be achieved in two ways:
- a. By simulating the behaviour of the internet browser and consuming what the web server sends and respond accordingly
- b. By interfacing, as an application, with an internet browser. This method will interact with the components of the application created by the browser, it will be able to access to the Document Object Model (DOM) of the web page and interact with it
- Screen scraping. The RPA application analyses the images displayed to the user, understands the contents and interact with it. The image is analysed by an image processing engine which can read information and detect the position of elements. Once what can be seen is established, it can send mouse clicks or text to the application.
However, RPA operates within set parameters and does not contain any logic on how to communicate with applications. Considering this, RPA is a technical automation means, an enabler. It allows our Cortex Intelligent Automation platform to communicate with an application. RPA acts as the observation and action means inside the wider intelligent orchestration functionality. Within the context of Cortex RPA is just an API that provides a means to achieve the orchestration.
We prefer to use direct API connectivity to all the applications as it is a more robust method of communication. However, I have considered some circumstances in which the use of RPA can be an advantage. This has been hard but I have found the following:
- No API connection is required. Implies that there is no IT involvement (i.e. open ports, no special users to access the application, etc.). In some companies the processes of achieving connectivity to third party systems APIs can be very complicated and time consuming.
- The application or infrastructure does not need to be adapted to accommodate automation.
In terms of disadvantages, these have been combined into commonly themed groups:
- RPA is dependent on the business logic implemented in the UI. RPA depends not only on the underlying business logic of the application but on how it displays this information.
- If UI logic changes, it stops working. Any upgrades to the third-party system will require a revisit of how the RPA parameters are defined.
- Implementation time increases. All the exception conditions, must be identified and rectified by trial and error. This manual configuration makes it more prone to error.
- Machine speed is not always an option with RPA. The UI may only be responsive to human pace.
- Reduced reliability. As RPA is often used outside the original constraints of its specifications, this type of interaction is natively prone to errors.
Irrespective of the advantages and disadvantages in the use of RPA, there are use cases for businesses where there is no initial option other than to deploy RPA:
- Legacy systems. There are some systems which do not provide APIs and the only way to automate them is through RPA.
- UI with a lot of business logic. In badly architected systems, in which there is a lot of business logic in the UI, it might not be viable to replicate the logic in the orchestration platform.
- Security. In some environments, the network segregation (i.e. air gaps) might make it impossible to have a direct connectivity to the API
- Budget/political issues. Due to the internal practices, RPA may be the only way in which one department can automate the use of one application
In conclusion, RPA is a way to communicate with systems. RPA automates tasks at a very basic level but does not give you rounded orchestration. RPA will allow the insertion of a record to an application but not retrieve the data from all the different sources: user input, CMDBs, inventories, etc. To be able to orchestrate the end to end process you need an engine that coordinates all the different aspects of the processes into a flow. Based on hardcoded scripts RPA technology is more fragile than agile in implementation.
When considering the RPA it must be used wisely, as a long-term solution it can be problematic. My recommendation is that if you have, or are going to implement an interface through RPA, alongside this you should work on a contingency plan to address the improvement of that communication or consider management and orchestration of your automation with Intelligent Automation which goes beyond the constraints of RPA.