Taming Entropy: From Waterwheels to Robotic Process Automation (RPA) - Part 2

In Part 1 of this article, we talked about the march towards greater process integration and automation as being one of the fundamental characteristics of our evolution as a society. In this second installment, we’re going to focus closely on what RPA is (and, just as importantly, what it isn’t) – and how the RPA adoption process can be accelerate by reusing assets the organization may already have in place.

What is Robotic Process Automation (RPA)?

According to the UIPath, one of the top software makers in the industry, RPA is a technology that allows users to build software “robots” which emulate the actions of a human interacting with various information systems to execute a business process.

The RPA robots, once launched, can manipulate applications in ways that imitates how human users interface with those applications. RPA robots can log into applications, copy data from an image or an application, paste data into another application or electronic form, extract data from browsers – and do this again and again, accurately and around the clock.

Simple activities based on pre-defined decision paths may be performed entirely by a so-called “unattended RPA robot”, while more complex activities that require a human’s input or judgement call to trigger an action can be programmed into “attended RPA robots” that act as productivity aids to human users. 

Just like a human employee, the RPA robot acts at the application’s Graphical User Interface (GUI) level, by using the information that is presented to it through the GUI. In the words of The Lab consultancy, a company which specializes in improvement through standardization:

“When properly configured, RPA knits together mainframe fields, cloud-based software fields, and desktop applications like Excel into a single, streamlined, standardized, and automatic process “

Unlike a human employee, a RPA robot can perform a repetitive activity very fast, error-free, with no need for breaks, and therefore more cost-effectively. This presents significant benefits, not least of which being the fact that RPA robots can relieve the human workforce of huge amounts of routine work. They can monitor sites for specific types of information, sift through reams of documentation, search large database systems, or analyze and reply to questions or requests from customers.

And this is not all, as RPA robots can offer a host of other benefits:

• RPA robots can easily ramp up to handle spikes in demand, with zero delays and at little additional cost.
• Since the RPA robots’ activities are automated through software, every action they take leaves behind a complete and auditable audit trail.
• RPA robots are continuously productive independently of time-zones and geographical locations. For organizations working with offshored and near-shored staffing, RPA robots may prove to be an overall more cost-effective alternative.
• Since RPA robots are programmed to handle small sets of activities, maintaining and modifying a robot is fairly easy and can be done by business users (although IT support is generally advisable).
• They never complain!

One area ripe for using RPA to speed up execution is the insurance industry. Taking health insurance as an illustration, large health insurers such as the BlueCross BlueShield companies have, over time, created layers upon layers of processes and information systems. They struggle to operate a cornucopia of technologies, many still mainframe-based, while at the same time striving to stay in lock-step with continuously evolving legislation and regulatory requirements. 

Claims processing is a complex endeavor by which medical claims submitted by health care providers get compared against a roster of eligibility conditions, health insurance plans and policies, provider network contracts, cohorts of exception rules and so forth. Claims processing agents often have to switch between disparate systems and databases to gather the data they need to verify a claim, and frequently have to make calls to the originating providers to get additional clarifications.

RPA robots can alleviate much of the routine research work by logging into the appropriate systems, extracting, comparing and collating data, and only escalating to the claims processing agents’ attention those claims that cannot be resolved through pre-programmed business rules. According to the same article mentioned above published by The Lab, leveraging RPA to close “the last mile” in claims processing could lead to a 50% reduction of health insurance claims processing costs, and to an increase in claims processing speed by up to 70%.

Still, before jumping to the conclusion that RPA can solve all integration-related ills and challenges, it is important to note that the following key points:

• RPA contributes to the enterprise integration by acting at the system (and specifically at the presentation/GUI) layer;
• RPA assists with process automation, but NOT with process improvement; and,
• RPA does NOT replace system integration at the platform, technology, and data layers of the architecture stack.

The last point is particularly critical in understanding the difference between RPA and ‘traditional’ system integration. RPA is not a data exchange mechanism between systems, and it is not intended to provide long-term, large-scale system integration across all (or even most) architectural layers. What it does provide is an expedient and relatively inexpensive way to bypass big-budget system integration initiatives in favor of immediate results and ROI.

Leslie Willcocks, professor of technology, work, and globalization at the London School of Economics’ Department of Management, describes the business case for RPA as follows: 

“When organizations consider proof-of-concept for RPA, they look at the business case and compare it to an IT solution. Often that’s pretty unflattering for IT. In one organization we looked at, the return on investment for RPA was about 200 percent in the first year, and they could implement it within three months. The IT solution did the same thing but with a three-year payback period, and it was going to take nine months to implement.”

For business decision-makers responsible for delivering results and showing progress quickly – the RPA option can be a winner.

Business Architecture as Critical Input for Successful RPA Implementations

This summer I decided, somewhat on the spur of the moment, to go to Los Angeles for a couple of weeks. Lo’ and behold, no longer did I arrive in L.A. that temperatures spiked above 100 degrees Fahrenheit and the city turned into a massive oven. So, marooned inside my apartment for most of my L.A. vacation and with plenty of time on my hands, I did the next best thing possible and took the free RPA online training offered by UIPath. (Disclaimer: I have absolutely no affiliation with UIPath.)

The RPA implementation training was, first off, comprehensive, well-structured and persuasively presented. However, I couldn’t help but notice that no mention at all was made of the value offered by business architects in supporting an RPA initiative.

Let me elaborate on why this is a gap – and, to do so, let me start by describing the implementation methodology recommended by UIPath, with the note that the methodology is not tool-specific and that other vendors such as Blue Prism and WorkFusion recommend similar approaches.

In brief, a typical RPA implementation consists of four phases:

1. Selecting the most suitable activities for automation;
2. Choosing a first activity to serve as a proof of concept for the RPA and developing software robots to automate the process;
3. Expanding the pilot to include the remainder of the activities selected for automation while putting in place governance and maintenance mechanisms to maintain the integrity of the RPA installation; and
4. Rolling out the RPA robots for use in production.

Of these phases, the initial (and arguably the most important) phase of the RPA implementation is the selection of activities best suited for RPA. To minimize re-work and keep the RPA implementation cost-effective, the methodology recommends zeroing in on activities with the following characteristics:

• Highly manual, repetitive, and performed on a frequent basis (at least daily or weekly);
• Large volumes of transactions;
• Based on clear, standardized rules;
• Mature and stable, and not slated for any changes in the short term;
• Receive input data in a standard readable electronic format;
• Have few or no exceptions requiring special handling; and,
• The savings accrued through automation are equivalent to at least 2 full-time employees’ costs.

These process selection criteria ensure that activities selected for automation are impactful, are not subject to near-term change, are not too trivial, and once automated, can be executed with minimal human intervention. The selection process weeds out those activities that are redundant, duplicative or ill-defined, which should be the subject of business process improvements. It also leaves out activities supported by systems about to be replaced.

By including business architects into this effort, the organization can substantially speed up the selection processes as the existing business architecture repository or knowledge-base already contains an inventory of capabilities, processes and subsumed activities, together with metadata concerning alignment with policies and/or goals, currency or obsolescence, usage, criticality (in the form of value streams), as well as data and system mappings.

During the next two phases (Proof of Concept and Pilot), the activities selected for automation are analyzed in minute detail, step by step, and then replicated into software-driven actions by using the robot-building features offered by UIPath and other similar RPA tools. For the robot to work properly, it is imperative that each and every action performed by the human operator be mirrored, precisely and in its entirety, by the RPA robot.

Here, too, engaging with the business architects in the client organization can yield precision and efficiency benefits. Whether in the form of process flow diagrams, BPMN diagrams, decision trees, business rule matrices, use case scenarios, state-based tables and/or event-based models, business architects already have the core ingredients required for an accurate process or activity definition.

Additional tools such as process mining, which entails parsing the system event logs for those activities supported by existing information systems, can augment the existing process architecture information with real-life, granular activity data.

A summary of the organization’s extant artifacts and other inputs essential for RPA implementation purposes is provided in the presentation below. As the presentation shows, business architecture is not the only source of information for RPA; other valuable inputs come from adjacent disciplines – for example, business analysis and process engineering. Used in concert, these inputs reinforce each other and provide the RPA analysts with a rich source of foundational data to mine, compare and contrast, in order to arrive at the ‘final truth’ which can be programmed into an RPA robot.

Figure 2: RPA Implementation – Click the image to run the presentation

Conclusion

Robotic Process Automation (RPA) has emerged as a critical tool in our march forward towards greater integration and process optimization. While RPA alone is not a panacea, RPA can provide high value in a short timeframe for those business functions comprising of manual, routine, and highly repetitive human activities.

Once an organization decides to invest in RPA, the implementation team does not have to start with a blank sheet of paper. Most organizations have already invested in disciplines such as business architecture, business analysis, process improvement and even process engineering.

In the spirit of good business architecture practices, those responsible for the success of the RPA adoption should look for opportunities to reuse and up-value the work that has already been done internally.

Business architecture artifacts, in conjunction with business analysis documentation, process improvement outputs and process mining reports, provide a solid foundation to any RPA implementation efforts and can contribute substantially to the speed, precision and success of RPA.