10 things you need to know about RPA

Robotic process automation, or RPA, has been in the news a lot lately. These include the potential to automate work as well as fears of putting people out of work.

When I first heard of RPA, it conjured up visions of clanking metal robots. But, it is nothing of the sort.

RPA uses software programs that help mimic human actions on a computer. For those familiar with Excel macros, think of RPA as Excel macros on steroids. RPA software allows the mimicking or re-creation of human actions on a computer.

RPA thus automates actions that use some business rules. While some salesperson coined the term RPA with R for Robotic, a more suitable but mundane term might have been Software Process Automation.

When you hear the term “bots” or “robots” in reference to RPA they are software programs doing things faster than we humans can without taking coffee breaks, falling sick or needing to eat or sleep.

With that narrow, single-minded purpose those programs do behave robotically like similar systems such as adaptive cruise control in your car. Automation combined with AI and machine learning, is often referred to as Intelligent Automation.

In the federal government, the President’s Management Agenda and the Office of Management and Budget memo M-18-23 dated Aug. 27, 2018, “Shifting from Low-Value-work to High-Value work” emphasizes the importance of RPA and other techniques to liberate human workers from monotonous, low-end tasks.

Budgets are shrinking with further cuts anticipated in the future. At the same time, workloads remain the same or are increasing. Government managers would be wise to adopt RPA as a means to "do more with less" in executing their mission.

Now that you understand the concept of RPA, what do you need to know to determine if it is right for your customer’s organization and if it is, how to implement and operate software robots. Here are 10 points to keep in mind.

1. Can RPA automate any process?

RPA is not a panacea for all process automation. A process involving steps that are repetitive and based on business rules is amenable to RPA. If processes involve reasoning, making a judgment and taking different types of actions based on scenarios, those processes may not be a good fit for RPA.

On one of our Homeland Security Department contracts, we identified and evaluated 10 different process candidates for RPA. By the time we mapped the processes and finished the evaluation, eight of those 10 processes had dropped out. Most of those 8 processes involved large variations in information, exceptions to the rules and the need for intelligent human decision making. Of the remaining two processes, one automated a large part of the process showing a 67 percent savings in clock time as well as human labor. Identifying, evaluating and selecting the right process to automate is an important first step.

2. Which processes to select for RPA

When embarking on your RPA journey, select a process which has a high potential to be a winner. That is a no-brainer, right? Teams often get this wrong. Once you have identified many process candidates, rack them and stack them as follows:

1. Low complexity, low benefit
2. Low complexity, high benefit
3. High complexity, low benefit
4. High complexity, high benefit

Get your team together to brainstorm different process candidates for RPA. Put each on a sticky note and categorize them along the four categories above. Start with the “b” category of cases first. It is important to get that first win to satisfy both yourself as well as obtain and sustain buy-in from key stakeholders and senior management. Start with a limited scope pilot, score a victory and then expand the scope wider.

3. Partial automation is a great start

You do not have to automate a process from end to end. After the first few wins, another way to approach case selection is to identify steps in a process which you can automate. Automating repetitive, high volume steps in a long, involved process can be a significant win.

There are many examples in the government that would fit the bill for full or partial automation. These include the various steps in procurement (market research, vendor analysis, price analysis, RFP creation, award process, contracts closeout), finance (data entry, reconciliation, reports), Freedom of Information Act responses, analyzing data reported on forms, data reconciliation between systems – to name a few.

4. Selecting an RPA tool

The RPA market is reminiscent of the dot.com boom of the late nineties and early part of the millennium. I remember tracking some 14 top search vendors like Alta Vista, Lycos, InfoSeek, AskJeeves, Yahoo. There was also a little startup called Google. As the world wide web developed and search technologies matured there was a big shakeout, with most of these companies vanishing. Currently a small set of vendors like Google and Microsoft Bing rule search with the others being footnotes of history.

There are more than 50 RPA vendors in the market currently. Some got an earlier start than others and some have venture capital backing. These vendors offer products that are very similar and with the same technological foundations. Within the software industry, we categorize them as ‘low code-no code’ because they use pre-built ‘building blocks’ and workflows rather than lines of code.

Given the competitive nature of the market, there is a lot of sales noise about who is better. Going with one of the top 5 vendors (pick your favorite analysts like Gartner or Forrester) should be a low-risk way to get started. Start small. It would also be wise to buy more than one product and see the differences for yourself.

5. The case to re-engineer processes, or not

We see that the business processes in most agencies can be re-engineered to be more efficient as well as consistent. Unless agencies follow standard operating procedures, most processes end up being ad-hoc. The question is: Do you automate a sub-par process or do you first re-engineer it and make it efficient before automating it?

My company Brillient has participated in many projects in the commercial and government sectors re-engineering processes. These often span multiple teams, departments, systems and different calibers of people. Business process re-engineering is a holistic exercise involving data flow, data taxonomy, IT systems, organizational culture, recruitment, and training.

BPR also is a multi-year change management journey that large consulting firms love because they can bill their clients a lot of money. I am of the opinion that in the interest of momentum and scoring successes it is fine to automate a process that is not optimal. Automating, deriving the benefits and simultaneously looking to improve the process is a more practical approach.

6. RPA can preserve institutional memory

The federal government faces the imminent challenge of a large baby boomer retirement in the next few years. GovExec reports that 15 percent of federal employees are eligible to retire today. According to data maintained by the Office of Personnel Management, in five years that number will spike to 30 percent.

When these boomers retire, decades of experience, knowledge, business acumen and lessons learned will walk out of the door with them. The incoming wave of younger employees is from a different generation used to different tools, techniques, and technologies. Bridging the knowledge gap will be a formidable challenge for most agencies. RPA would be a good way to capture and automate many of the current processes. As such, it becomes a tool to capture the institutional memory of an agency even as the boomers retire.

7. RPA is not like implementing an IT system but needs IT

Since RPA automates business processes, business teams can implement most RPA projects. That might lead some to believe that they can do so without any CIO involvement.

But remember that RPA involves software installed on agency computers and servers, which automatically involves the office of the CIO. When you have many RPA bots operating they also have an impact on network traffic, load on IT systems, servers and databases all of which the CIO has to account for and take care of. As such, CIO is an integral stakeholder in any RPA effort.

8. RPA bots need caring and feeding

Like human workers, these robotic workers need caring and feeding as well. Bots, once developed, tested and deployed into production need monitoring to ensure they are functioning correctly. Changes or upgrades to downstream and upstream systems have an impact on RPA bots that operate on those systems.

For example, a change to the web interface of a mission system on which an RPA bot is operating might cause the bot to fail (if the change is substantial enough). Teams utilizing RPA should register themselves with system owners as an impacted party so they will be informed of system changes. Also, every bot should have a person acting as a ‘custodian,’ ensuring timely change control.

After the initial RPA pilots and efforts are a success, teams would be wise to establish a governance process that takes all of this into account and defines roles, responsibilities, service-level agreements, etc. These will span many departments within an agency and require coordination and stakeholder support.

9. RPA is not a band-aid to replace systems

Across federal agencies temporary, ad-hoc solutions developed as a “band-aid” often end up lasting for many years and sometimes becoming permanent solutions. RPA does not replace IT systems nor is it a band-aid. RPA automates the human processes and interactions with systems and bridging tasks performed by different individuals and groups.

For instance, RPA could automate human tasks working with grants management or case management systems. However, it is not a substitute for either type of system. The IRS is consolidating over 140 case management systems into one system, a laudable initiative. While this may take some time, it is worth developing RPA tools to automate work with existing case management systems. As the new solution replaces the older systems, the need for those specific bots goes away. New bots can automate human interaction with the new system.

10. Will RPA eliminate jobs?

When robots started showing up to mow our grass and vacuum our carpets, some of us assumed that the lawn care companies and vacuum manufacturers would soon be out of business. While that might still happen someday, it has not happened yet. RPA bots are far from being real robots but are more helpers to human workers that lighten the monotony of certain tasks. RPA automates tasks, not jobs.

Automating monotonous, lower-value work might actually make many jobs more interesting and exciting. As someone in the government once mentioned: “I did not get a 4-year degree to copy and paste”.

It may be harder initially to use RPA to automate the work of unionized labor based on how collective bargaining agreements are defined. It may be more expedient to get started with non-union labor to gain some momentum and deliver results. Inevitably, unions will also see the value of making the lives of their workers more valuable and interesting.