Robotic process automation: Part I of a five-part series

Part I: What is RPA, and why should CIOs care?

Robotic process automation (RPA) has become very popular in the last couple of years. It’s become such a mainstream topic that you can find RPA-related articles in publications such as the New York Times1 and the Wall Street Journal2. So, what is RPA, and why has it become so popular?

Automation — specifically, process automation — has been around for more than a decade. However, RPA is a specific type of process automation. The robotic part means a software robot that mimics a human. More to the point, it means software that interacts with the same applications and interfaces that humans use. It’s important to understand this: it has many implications; and it’s the major distinguishing characteristic among process automation, business process automation (BPA), and robotic process automation.

Robotic process automation

There are several reasons RPA has become popular in recent years. Businesses are constantly under pressure to reduce costs, but they can’t rely on their IT departments to be responsive to their needs. RPA allows businesses to use automation without requiring IT involvement. Mind you, that approach is not best! However, it can help them implement a solution much faster. Even some IT departments have embraced RPA, because it’s easy to implement and requires no application or infrastructure changes. This allows the IT departments to deliver value to the business more quickly and efficiently. However, many see it as merely a Band-Aid® for legacy applications in which they don’t want to invest.

Part of a strategy

It’s a fact that automation reduces costs — in some cases, dramatically. But most CIOs don’t see RPA as strategic. Instead, they view RPA as a tactical approach that’s best for the business users or individual IT departments to use on a case-by-case basis. Still, CIOs should embrace RPA for what it is, rather than avoiding it for what it’s not. Yes, RPA is a Band-Aid for some situations, but it’s also an effective way to save money quickly. To be sure, a company should use RPA as part of an overall automation strategy or a digital transformation initiative. The company should not use RPA as a “one-off” solution for one process and one department.

RPA tools also have limitations. Why? Because, in most cases, the entire targeted process is running on a desktop PC. As a result, that limits you to the flexibility of the RPA tool and the robustness (or lack thereof) of the desktop environment. If your process has complex logic, it’s less likely that an RPA tool can automate it. Also, there are certain types of application interfaces that work well for humans, but are a challenge for automation. Two examples are mainframe applications and Web-based applications. You usually can access both using server-based technology that’s more powerful and more accurate than a default desktop interface allows.

A better way

Why not use the best of both worlds? That would be a server-based process automation solution that utilizes RPA technology to interact with the desktop applications when it makes sense to do so.

Here’s an example. Let’s say you have a process that uses a client/server application, a Web-based application, and a mainframe application, along with some standard desktop applications such as Excel® and Outlook®. With a pure RPA tool, you will have to create a process that runs on the desktop and interacts with all of these applications. If the logic isn’t too complex, then you might be okay, but it’s still a lot of applications with which to interact. However, if the logic is complex — well, good luck. This will be a challenge for most RPA tools.

A better approach is to have a server-based solution that runs all of the business logic and process information. This gives it the power to process complex logic and keep track of the hundreds of software robots that could be running at any one time. Such an approach also enables the server to connect directly with the Web-based application, using standard Web services. This eliminates otherwise required “screen-scraping” on the desktop or navigating a browser’s document object model (DOM). Ideally, the server-based solution can also access the mainframe applications directly on the network without “screen-scraping” a desktop-based mainframe emulator. (Of course, the desktop applications have to reside on a desktop, and that’s where the RPA tool comes into play. However, there is no need for complex logic to run on the desktop, since the logic is running where it should be: on the server.)

This approach allows you to take advantage of the RPA tools that are getting much attention, while still implementing them in a more robust, server-based environment that can be part of a strategic automation initiative. This is no Band-Aid approach. And it’s something a CIO can and should embrace: yes, bring in RPA and allow the business units to use it, but control it and implement it in a centralized, enterprise-level environment.

Part II: Creating a process automation strategy.
Band-Aid is a registered trademark of Johnson & Johnson Services, Inc. Excel and Outlook are registered trademarks of Microsoft Corporation.