Who wouldn't want to automate repetitive and time-consuming computing chores? Jair Godschalk, Managing Director of SER Solutions Deutschland, knows from his own experience with SER customers just how high expectations can be among companies looking to enhance efficiency, improve service and save costs with process automation. But for an area currently attracting such considerable hype, is robotic process automation (RPA) really the right way to go? In this Chief Tech Talk, Dr. Gregor Joeris, Chief Technology Officer of the SER Group, and Jair clear up misconceptions and misunderstandings surrounding RPA and demonstrate why business process management (BPM) is often the better choice for companies seeking end-to-end automation of business processes across multiple departments.

Godschalk: The topic of RPA has been receiving a lot of airtime lately in talks with our customers. There's so much hype right now surrounding robotic process automation, and much of what customers hear and read is raising high hopes and expectations. But what does RPA really have to offer — and how do you define RPA?

Joeris: RPA is a way for companies to automate structured tasks that involve a handful of process steps and are repeated several times daily — like transferring data from one IT system to another, for example. RPA can relieve employees of tasks that take up a great deal of their time but contribute little in the way of value creation and are prone to errors such as typos.

Godschalk: But business process management is also capable of automation, which is frequently a source of confusion: Customers always ask me how RPA differs from BPM. How would you explain the difference? Does BPM go beyond RPA?

Joeris: Exactly. RPA solutions have a far more limited scope of application than BPM software does. RPA is relatively superficial. It doesn't work via APIs — all it does is mimic data input by a human. Really, we should be calling it RTA: robotic task automation. This would make it clear that it's just about simulating the clicking and typing of a data entry clerk. Companies can use RPA to speed up a workflow, but not improve its quality or usefulness. A bad process will always be a bad process, with or without RPA. By contrast, BPM offers a much broader approach that covers the digitalization, automation and optimization of entire business processes from start to finish. BPM also interconnects processes across different systems and departments. Employees stay involved in workflows and remain responsible for decision-making. Automation can be a helpful tool here, but cannot replace BPM altogether.

Godschalk: RPA works at its best helping to save time by performing simple, repetitive tasks — things that the software can handle simultaneously, whereas an employee would have to carry them out consecutively. This kind of application needs simple rules with few exceptions. The biggest advantage is that, unlike employees, it can work around the clock, won't get tired or lose concentration. 

Joeris: A great example is a company's purchasing department: Somebody has to spend a great deal of time searching supplier websites and portals for the best prices and compiling price lists to ensure the company is getting the best deal. It's tedious work that involves a lot of mouse clicks. An RPA application can automate this task and generate price lists at frequent intervals — error-free and without tiring. You'll find these kinds of repetitive, structured tasks in any company. But once we move into the realm of adaptive and ad hoc processes, RPA quickly reaches its limits. 

Godschalk: What are those limits — can you give a specific example?

Joeris: Let's look at customer service: When a customer places an order, makes a complaint or simply needs some information, the RPA application can quickly and seamlessly retrieve all the available data on the customer or the service case, or add new customer data to the system. However, since it only mimics data input, it is incapable of making decisions. As a digital colleague, RPA is limited to a supporting role only. A BPM solution, on the other hand, optimizes the entire process from end to end, from the initial contact to the purchase and after-sales. This approach makes it possible to involve specific employees in individual customer cases on the basis of their availability and expertise.

Godschalk: So, on the one hand we have BPM with its comprehensive business process approach that precisely models, executes, monitors and ultimately improves company workflows in line with business values. On the other hand, we have RPA as a digital helper that can be slotted into specific workflows, like in purchasing or accounting. So actually, there's no need to view it as an either/or decision, since RPA can in many cases be a useful addition to BPM. But the terms still cause a great deal of confusion and create false expectations — why is that?

Joeris: Companies frequently assume RPA and BPM are essentially interchangeable, and so believe that RPA is capable of automating processes from end to end. But they are confusing two separate things here. RPA is comparable to a tool, whereas BPM is management software. They're not in the same league. RPA can only automate straightforward, repetitive manual sub-tasks as part of a whole process. BPM, on the other hand, can do a lot more: Not only can it manage and automate workflows, it can also design and improve entire processes — because BPM adds transparency. Its analysis and reporting functions help to uncover data silos and bottlenecks in the system landscape and thus trigger the corresponding improvements. You could say that RPA is the machinist and BPM the engineer. 

Godschalk: I feel like we need to explain this difference better to companies, so they can understand the limitations of RPA. 

Joeris: It's true that companies often want to deploy RPA for complex processes or use it to replace solutions entirely — which goes far beyond the capabilities of this tool. It should be said that calling it robotic process automation creates expectations that the technology cannot live up to. As I mentioned, robotic task automation (RTA) would be a better name for it. Added to that, it takes time and money to fully replicate all employee activities using RPA. In many cases, existing automation tools are perfectly adequate and RPA is unlikely to add any real value. However, companies should be aware that BPM is always the more comprehensive solution and the one that will offer lasting value. If data is transferred via an API, the process will become more streamlined and efficient over time than with a workaround using RPA, since this would inevitably lead to dissatisfaction with overly complex processes at the latest within five years of being rolled out. It goes without saying that BPM takes up more resources up front, especially in IT. But it's definitely the more prudent choice over the long term. 

Godschalk: There seems to be a widespread misconception that RPA is ready to run out of the box and can be deployed company-wide. But simply attempting a sweeping migration of complex business processes to RPA is virtually guaranteed to fail. It's like trying to run before you can walk. A better way is to start by looking at which processes take up a lot of time and are fairly low in terms of their complexity. These are perfect candidates for automation quick wins. 

Joeris: It's true. Simply jumping in at the deep end and rolling out a technical solution won't work without a strategy and the right management. Before implementing any form of automation, it's always advisable to bring in process owners to estimate the complexity of the task and the work involved. There are certain criteria you can apply to assess whether an application is generally suitable for automation. 

Godschalk: What are they?

Joeris: You should ask yourself the following questions:

• How big is the share of manual input in a certain process?
• How often is this input needed and how long does the process step take?
• How many employees, systems and technologies do I need?
• What are the disadvantages of not having application integration?
• What are the disadvantages if processing is incorrect?
• How important do I consider automation to be and what benefits do I see it bringing?

Godschalk: Unlike RPA, BPM includes key functions for automating processes — in capacity management, for instance. Transparency at process level can also be ensured automatically with BPM, which is essential if companies want to conform to compliance guidelines. With its end-to-end approach, BPM offers significantly more opportunities over plain automation when it comes to improving processes.

Joeris: Definitely. We know that from our own experience. Customers who use our Doxis business process management (BPM) software, for example, can model, organize and work on not only ad hoc processes but also standard and automated workflows — and flexibly combine them as required. Say a company wants to extend its standard invoicing process to include extra review steps, or convert recurring ad hoc workflows in customer service into a standard process — it can do this fast, flexibly and with little administrative effort.

Godschalk: Our customer Raffinerie Heide springs to mind here. They recently chose Doxis BPM because it offers structured and ad hoc workflows as well as a flexible combination of the two. Raffinerie Heide used Doxis to introduce workflows for invoice verification and project approval, as well as an obligation workflow to demonstrate the fulfillment of its obligations to finance partners. As a result, the company has significantly cut document processing times and achieved full transparency — even without RPA. 

Joeris: I would even go so far as to say: "Thank goodness without RPA!" Because actually all RPA does is automate workarounds. BPM enhances processes, automates the entire workflow and implements automatic process steps that will remain streamlined and efficient in the long run via APIs. I can only congratulate Raffinerie Heide on its forward-looking approach and successful implementation.