A digital software robot that automates business processes, reduces the workload of your employees and thus minimizes costs. Sounds tempting? It is! Not for nothing are so-called RPA tools currently on everyone’s lips. But what is actually behind this new technology and what can RPA products really do? In this article, you will learn in which process areas RPA software can be used sensibly, how it relates to Business Process Management (BPM) and where it should be treated with caution!
Robotic Process Automation simply explained
Robotic Process Automation (RPA) is currently experiencing a real hype. It is the automated processing of rule-based business processes at the graphical user interface level. After receiving instructions, software bots are able to work completely on their own. Users are thus spared unpopular activities such as repeated data entry and can devote their time to other tasks.
The following graphic shows an overview of the potential benefits of robotic process automation tools.
Suitable use cases for RPA include (according to MindMajix) website scraping, product ordering, and data synchronization. McKinsey Digital emphasizes that human capabilities such as judgment and emotional intelligence are not present in RPA tools. This means that in contrast to cognitive automation, the focus is on simple or strongly rule-based tasks.
How does RPA work in the first place?
RPA products are characterized by their ability to perform interactions at the UI level through so-called “robots”. This means that the “robots” open a UI like a user and then imitate mouse clicks and keyboard inputs. The foundation of this technology comes from the domain of UI testing tools – so some RPA vendors originally come from this field and have adapted their product to use RPA.
By linking multiple UI interactions in a workflow, a process, i.e. a sequence of UI interactions, can then also be mapped. The template for the robot interactions can be created classically by configuration or, with some manufacturers, recorded with a type of “recorder”.
RPA also offers the possibility to perform interactions with systems that do not offer a modern API (legacy systems) or for which only UI access exists for other reasons.
However, there are risks to using RPA. One of the biggest vulnerabilities is the dependency on the UI. In the case of a high change frequency, regular rework of the robotic records is required.
Bernd Rücker definitely recognizes potential in the targeted use of RPA. He advocates the software as a quick fix for outdated system integration that is not compatible with modern systems. However, the automation tool is only suitable as a short-term solution. Modernizing the system landscape is inevitable in the long run.
We have summarized for you where the strengths and weaknesses of RPA software lie and guide you through relevant areas of conflict.
1. Integration in system landscape
RPA must be integrated as external software into the existing system landscape and connected with interfaces. The technical requirements for this are relatively low and it also works without modern APIs. A user interface that is accessible from the automation system and a user account in the target system are completely sufficient.
However, to ensure that no gaps are created here, this step should be carried out by IT specialists. According to Rücker, IT architecture, infrastructure and security are the main factors to consider here. Users from the various business units do not have the expertise to perform the system integration without risk.
2. Security concept
The introduction of RPA software must go hand in hand with security policies. Thus, authorization concepts have to be decided. While individual users have limited operating rights, the bot needs user accounts and access rights to the data and functions of all target systems. If the actions to be automated contain sensitive data, (personal, financial, orders, etc.), then this information is also accessible to any administrator of the RPA solution. Not every organization is ready to accept this.
The problem with this is that it becomes difficult to track which bot performed which activity in which business unit. In addition, users can also suddenly serve processes from other departments, but are not able to verify the results properly.
3. On-premises vs. cloud
Another important factor with regard to a proper security concept is the type of data management. The majority of all companies have their own servers with strong firewalls. In the future, however, the cloud could become more and more important (lower costs and data crashes), making the company’s internal data part of the Internet and thus easier for hackers to tap into. Here, especially in the case of sensitive data, careful consideration should be given to whether the use of external software via the cloud fits into the company’s own security system.
The risk is exacerbated in the case of cloud-based installations:
- The target applications must be made accessible to the cloud.
- The critical user accounts for the automations are stored in the cloud and thus tend to be more at risk.
4. Test cycle result check
Installing RPA software alone does not get the job done. In order for the processes to be carried out by the digital robots in as much detail as possible, all steps must first be mapped accurately. BPM – and in this context also DBP (Digital Business Platform) – are therefore indispensable as a basis. They ensure the automatic mapping of the processes, while RPA takes care of the execution. Ideally, the two form a symphony. However, if the BPM area lacks precision, the potential of RPA cannot be properly exploited either. Once the basics are in place, the first RPA test cycles can be started. Key users must check that these tests have been carried out correctly and that the results are accurate. The protocols should be checked intensively at the beginning and at least randomly later on.
5. Process changes and responsibility
An automation tool that can (theoretically) be managed by end users as well as key users and IT gives a lot of room for the question of responsibility. Who determines how the tool should be applied and managed? Who bears the responsibility? In addition, any process changes outside the RPA tool will disrupt the workflow and the software will need to be adapted and continuously updated accordingly. Ideally, IT experts should take care of teaching the bots the new processes.
6. Complex process issues vs. “monkeywork”
The core competence of RPA products is to perform simple, rule-based processes. Repetitive, clearly specified work can be taken over by the bots, which is particularly worthwhile if the volume of these use cases is high. However, if more complex use cases are to be executed automatically, this requires a lot of effort in terms of creation and maintenance. Whether and when this is worthwhile must therefore be decided on the basis of a cost/benefit analysis.
7. Quality assurance and analytics in RPA
Good error handling, validations and audit logs are key to stable automation in any automation solution. These factors are especially important in RPA because it uses an API that tends to be unstable (namely, the UI) and works with potentially very privileged accounts of the target systems. Serious errors can occur in the process. With solid error handling and alerting, problems are then at least noticed early on. The test logs of the RPA tool must therefore be checked regularly and the results analyzed. Depending on the complexity, this can be done either by users, key users or IT. The effort is thus shifted from testing to analysis. The question is how extensive the time savings really are.
RPA and BPM: comparison and recommended use
RPA as new automation software and the classic BPM approach are not mutually exclusive, but complement each other. A solid BPM foundation in combination with professionally managed RPA can lead to an all-around successful process automation. The following is an overview of concrete deployment recommendations.
When should RPA tools be used?
- Strictly rule-based use cases are available
- Modern, API-based automation is not possible
- The automations are small and clear (few case distinctions and execution paths)
- The target systems are relatively stable user interface systems (e.g., legacy systems at the end of their lifecycle)
- The lifecycle of the target systems is controllable (so that one can react early to new versions and the associated problems), which mostly applies to in-house applications.
In which cases does BPM (with API based interfaces) make sense?
- When modern interfaces are available
- In more complex E-to-end processes
When is a collaboration use case recommended?
End-to-end BPM automation is not possible because one or more legacy systems are involved that do not offer modern API’s. Using an RPA or UI test tool, a “legacy interface” can then be created for a specific process step, thus preventing the media break in the End-to-end process.
Our conclusion
Used correctly and embedded in a solid IT strategy, RPA can effectively be a further step towards modern process automation. So RPA definitely has its justification in the BPM automation environment, but it must be used consciously and selectively.
In our opinion, this area of application is relatively small and limited: Automations with systems that do not provide modern interfaces. RPA thus tends to take on the thankless role of a temporary “painkiller” limited to specific use cases for enterprise process automation deployment. As with all temporary solutions, one must be aware that a solution must ultimately be implemented twice: As a temporary and as a “real” version.
If a modern API is available, automation should definitely be done on this basis. This type of automation is supported by all BPM systems. Today, modern web applications are developed according to an API-first paradigm, so that the need for UI-based interfaces à la RPA will gradually disappear. Even if, in principle, almost all processes could be executed with RPA tools, the user interface as API is too unstable as an underlying basis for comprehensive enterprise automation.
