Analytics and RPA — the perfect team

Analytics and RPA — the perfect team

I keep hearing that robotic process automation (RPA) is simple to use, doesn’t require a programmer, and can automate any business process. Unfortunately, we all know this isn’t entirely true. But, even if it were, there is more to automation than the RPA tool itself. Let’s look at a standard automation process used to automate business processes.

Five phases to getting automation right

In 2010, OpenConnect worked with several customers to develop the OpenConnect Approach to Process Automation. This approach consists of five phases — Discover, Design, Build, Execute, and Measure — as shown in the diagram below. It is an end-to-end, iterative process that helps companies (a.) identify automation opportunities based on their automation strategy, (b.) design and build the solution, and (c.) measure the results of the robots.

This process has been used by several of our customers for many years, helping them successfully implement automation robots to improve quality, increase throughput, and reduce costs. But how is this process any different than others? After all, it’s very similar to many other processes you find in the RPA world. The major difference is how this process is implemented and executed.

The OpenConnect Approach to Process Automation uses a combination of analytics tools and automation tools to provide:

  • A list of automation opportunities in order of importance
  • The best path to take to get the highest throughput
  • The steps taken for each process/task
  • A document showing the details of the process/task
  • Robot measurements that can be used to help identify improvements

The importance of analytics

I think everyone would agree that analytics can improve automation; and many RPA companies provide analytics; but most RPA analytics tools available today show only what the robots did, not how to automate the process involved. The analytics data is created by the robots’ activity; so, before you get any data to analyze —i.e., Measure — you first must Discover, Design, Build, and Execute. And, while the data helps you improve the existing robots, it doesn’t help build the process logic in the first place.

Since RPA is automating what people do, we need to know what people do. The standard way to understand what people do is — to ask them! Sit down with a subject matter expert (SME) or a business analyst (BA), and have him/her walk you through the process. People who have used this method know that it’s not the best way to get the information you need. First, if you don’t ask the right questions, your process is going to have major holes that you won’t discover until you start to build the logic. Second, if you ask 10 people how to do something, you’ll probably get at least five different answers. What people tell you will be based on their experience; so, if you get a more experienced user, you might get more accurate data.

You can capture a few workers’ activities . . .

There are some tools available that allow you to capture what a person does and then use that information in the RPA tool to create your robot logic. To use one of these tools, you first install a piece of software on one or more desktop computers, and then have people start the recorder every time they execute a process. Typically, the tool provides an option to enter information for each step. This could include business logic or notes about why the person did something.

It’s true that this can help get the information into the RPA tool more quickly, but the data is only as good as the person executing the process. Also, what about process variations? Does the user have to navigate every possible path for this to be accurate? And how is the business logic captured? Finally, how reliable is the data when the person knows his/her activities are being recorded, much less when he/she is actually starting each recording manually?

So, on the face of it, although this initially may sound like a great feature, all it really does is help you get the data (useful or not) into the RPA tool. However, most RPA tools already have a “record” feature, so why couldn’t you just do the same thing within the RPA tool itself?

. . . or you can capture and analyze the workforce’s activities

Now, let’s consider a better way. Instead of capturing what one or two people are doing, why not capture the activity of the entire workforce?

Let’s say you have a fairly complex process, one that takes a user several weeks to learn and a couple of months to master. It contains multiple decision points and complex logic. Let’s say also that you have 200 people executing this process multiple times every day. If you could passively capture the data for every user, for every process, and for multiple days or week, you would have every variation, every decision point, and every screen used in the process. And users wouldn’t even be aware that their activity is being captured, so you’d get realistic data from actual users doing actual work — not from a few users being very careful about how they execute a process because they know they’re being recorded.

That sounds right; but how do you sift through all the data so you can make sense of it?

First, you must identify the users who execute the process the most often and with the highest efficiency. I have heard many people say that you don’t need to improve the process for RPA, because robots don’t care if it’s efficient. Well, the robots may not care, but you should care; because, the more efficient the process, the fewer robots you’ll need in the first place! That’s why I believe it’s important to learn the most efficient way to execute a process; and the right analytics can help you gain that knowledge.

How finding the “happy path” helps you

After you’ve narrowed down who the top users are, you then must understand the paths they take and identify the best one — commonly called the “happy path.” To do this, you need a tool that can automatically show you the process, and all its variations, in a graphical format that’s easy to understand and analyze.

The process map should be detailed enough to show the decision points, but not so detailed that it adds unnecessary clutter. Maybe User A goes to Screen 3 followed by Screen 2, but User B goes to Screen 2 followed by Screen 3. Does it really matter? In most cases, probably not. But it could. That’s why you must have control over the data that goes into the process map. For some activities, you might include several screens per activity; but, for others, you may want only one screen per activity. (An activity is displayed as a box in the process map, and lines connect the various activities based on user navigation.) You should also be able to analyze each variation by human “think-time.” If your goal is to reduce costs, automating the path with the greatest amount of human “think-time” will provide the best ROI.

Once you’ve identified the “happy path,” you should be able to document the selected process. Since all of the data is in the system, it should be a simple matter of clicking on a button to create the documentation. But how do you capture the business logic? You can capture what people do and how they do it but, for now, you can’t capture why people do it. The why refers to the business logic. We know that a user entered a specific value into a field, causing a specific action; but we don’t know why the user entered that value in that field.

This is where you need to include an SME, so he/she can help document those rules. Still, this is much different than the manual process I mentioned at the beginning of this article. We aren’t asking an SME to go through the process and provide details; instead, we’re asking the SME to review a document that already has all the screen-shots and navigation steps (the what) and asking him/her to add the why (the business logic). The SME simply adds text to explain why the user entered that value in that field.

Summing up: The right way

Since most of the time building automation logic is in the Discover and Design phases of the process (again, please refer to the diagram), using the right analytics can reduce the time to automate by as much as 50%. It also improves the quality of the automation and helps you identify the most efficient paths, which reduces the number of robots required. Fewer robots means a more economical deployment, purely and simply. This is the right way to automate.

Don’t be fooled when you hear people say they “identify what people do and automatically automate it.” I’m very skeptical about such claims if those making them have acted without proper analysis and the benefit of business logic provided by a knowledgeable human! To be sure, we eventually will get there with artificial intelligence, but we aren’t there yet.