Oliver Gramberg
Senior Consultant, ERNI Switzerland
Robotic process automation (RPA) is the automation of IT-based business processes that were previously performed manually by the user, through the UI of the systems being automated. For example, a query could be started in a production management system for monthly production data, and the result data copied into a financial system for report generation.
Now imagine a physical, humanoid robot sitting in front of a computer, using a mouse and keyboard to perform tasks – it could be like that.
In reality, it is all done in software, without the hardware overhead but with exactly the same actions performed against the UI of the automated systems – hence the name, “robotic.” The “robot” is a process on some computer executing the automation.
RPA is not factory automation, so there are neither production lines nor industrial robots involved here.
Benefits of RPA
As with all automation, the promise is that the human user is relieved of repetitive, tedious, error-prone tasks so she can concentrate on the higher-level, more complex, more rewarding parts of the job. Think of removing the steps of manually copying customer data from one system to another. Instead of having to focus on the “what” of her documentation process, the front office clerk can instead concentrate on the “why” of the calling customer’s problem.
Comparing RPA and system integration
System integration has the same purpose and achieves the same results as RPA, but uses programming interfaces (APIs) or data interfaces like message queues, and not the UI as RPA does, to access the systems being automated. The decision as to whether RPA or system integration should be applied must be based, among other factors, on:
- the availability of interfaces needed or the cost to buy or implement them
- the tools, processes and skills already present in or otherwise available to the organisation (modern RPA tools provide quite powerful record/replay capabilities, so often no programming is required)
- the expected stability (rate of change) of the interfaces and thus the maintenance costs of the automation
Comparing RPA and UI test automation
RPA is similar to automating tests on the UI level. Both share the basic techniques needed to identify screen elements like buttons, text fields or labels, and to interact with them by clicking, typing into or reading output from them. RPA can principally be implemented using test automation tools and techniques, and anybody proficient in implementing UI test automation should have no troubles at all to perform that task in an RPA project.
However, whereas an automated test generally has the purpose to quickly pinpoint a problem, and therefore will go as directly as possible to the place where such a problem can be identified, RPA has a different goal.
Here, the automated process must be able to handle variants, edge cases, errors, conditions and repetition.
Any meaningful process automated as RPA will be much larger than the average UI test.
Capabilities of today’s RPA tools
Modern RPA tools are complex software suites that come with both an IDE for developing, testing and debugging an automation and a run-time support system. The IDE’s features include:
- record/replay to capture a manual execution of a process
- a graphical editor for designing flow charts, BPMN diagrams or the like
- means to organise (partial) processes for reuse
- means to compose processes into bigger ones
- step-by-step execution of a process
- version management
The run-time system comprises a command centre and the robot software. The command centre allows the user:
- to manage a list of machines where the robot is installed
- to connect to the robots and monitor their availability
- to deploy versions of processes to robots
- to start and stop robots executing such deployed processes
Developing an RPA
On a rather high level, the following tasks or steps comprise an RPA effort:
- Tool selection: Can we do with our in-house UI test automation solution? If not, will we need professional support, or is a free RPA tool sufficient?
- Selection of processes to automate: This is a cost-benefit analysis involving questions like how often the automated process will be executed and how much it costs to automate it.
- Versioning and rollout planning: RPA must functionally match the versions of the software being automated; when will these versions be available? Which processes will run attended; which unattended? How many RPA server machines do we need for the unattended processes?
- Implementation and testing: This is not much different from any other software project or test automation effort.
- Training and rollout: People need to be trained in controlling the robots, both in terms of operations for the unattended robots and users for the attended robots supporting them. The RPA base system has to be installed and configured and process automation has to be assigned to the robots.
- Use, monitoring and maintenance: Change will happen, so the running RPA must be monitored for outcome quality and performance, and adjustments must be made. Changes in the products may negatively affect the automation and need to be reflected there.
Running an RPA
There are two modes of running RPA: attended and unattended. Attended means the automation runs on a user’s computer, may be triggered by events or by the user to execute a process, and may even interact with the user during execution, e.g., to let the user take a decision at a certain point and then continue based on that decision. Unattended means the automation usually runs on a displayless server (most probably virtualised) and must be programmed to be triggered only by events (timers, messages or others).
Attended mode is sometimes called robotic desktop automation (RDA). Its benefits are that a human user can be selectively supported and that the RPA need not cover all of the process to be useful. It can be used to give users a feeling of what RPA is able to do, or as a checkpoint in the migration to unattended mode. Unattended mode runs faster because it can be displayless and several robots can execute the same process in parallel, but it must fully be able to handle all process variants.
Maintenance, monitoring and QA
As with all automation, it is paramount to supervise and monitor the RPA for effectiveness and efficiency. Changes to the UI of the products may affect the quality of the RPA outcome and must be detected in time (better upfront).
Changes in frequency of processes to be executed may shift a robot’s workload and must be adapted to, if the control centre does not do so automatically.
Maintaining an RPA requires at least the same skills as developing, so it is important to retain sufficient levels of the required resources.
Change management
As with all change efforts, affected persons should be involved in all steps of the RPA introduction, both to keep them motivated in their own right as well as to make good use of their goodwill. They need to be informed at the very beginning and kept up to date throughout. They can help with deciding which processes to automate, in which order. They should be encouraged to provide feedback early on, and their input should be given appropriate attention. They should be trained on using (attended) RPA in time, and not all RPA should be enabled in one fell swoop. Finally, they should be an active part of the QA and maintenance phase.
Did you enjoy reading this technology post? You may also like the previous ones:
