Process Discovery Can Change the Pace of Success for RPA

Robotic Process Automation (RPA) has been a major topic of interest over the past few years. It isn’t a new concept, but with the advent of new delivery options, the results that can be achieved are continually improving. In order to improve any process by making it more efficient or lowering its operational costs, though, we must first understand how it currently works. That’s where process discovery and documentation are key to your overall success.

Let’s use common analogy – automotive performance. Does improved performance mean you want to go from 0 to 60 mph quicker, improve handling or achieve better fuel efficiency? You first need to understand what better performance means to you, and then you can take inventory of what you already have. At that point, you can put a plan in place to improve your vehicle’s performance. If you want more horsepower, you wouldn’t replace the tires. Likewise installing a new cold air intake won’t upgrade your car’s handling. If you rush out and buy something you think you need, without understanding what you have, you may end up with an expensive credit card bill and the same old car.

It’s no different when scaling your RPA practice. To implement an effective automation solution, you need a strong understanding of your end goal, as well as a good handle on your current situation. UiPath has a great RPA Adoption Model addressing a strategic Top-Down approach versus a task-level Bottom-Up approach and when each makes sense. Leveraging the right analysis and documentation, in the form of process mining, process intelligence and Artificial Intelligence (AI), can help achieve your desired performance and at a faster rate, resulting in a very powerful automation solution.

At OpenConnect, we think we have the secret sauce to improve any process — large or small, basic or complex. Even if you don’t know where to start in your automation journey, we can help. It starts with accurately capturing the right activities and tasks being performed. You can get log data from larger packaged software like SAP and Salesforce. However, if you aren’t including desktop tasks, you are not seeing the full automation opportunity. Using WorkiQ we capture EVERY task that occurs on the desktop, and we do it natively. It’s not an experiment or done it a lab setting. The tasks are captured where your people are doing actual work without interrupting the user. It doesn’t capture how the work is supposed to be performed, but it captures how it is actually being completed. Once this data set is collected, we port that to process mining solutions like PAFnow to execute a deep analysis on all data sets and process possibilities. We can also send it to our DiscoveriQ tool for quick process documentation outputs of known process activities and variations. By using analytics to help design the outcome you are able to produce a result that improves your speed to ROI, overall cost savings and the final outcome.

As you consider your automation drive, remember to take a look at your current processes and activities to chart your path forward. Once you have that in your sights, 0 – 60 in under 6 seconds is right around the corner.

Automate Your Mainframe With Any RPA Tool

Robotic Process Automation (RPA) provides a quick and inexpensive way to automate business processes. But there’s a catch. You can’t, and shouldn’t, automate all processes. There are specific processes that are better suited for RPA than others. There are some processes that simply can’t be automated with RPA.

Forrester’s Rule of Five

According to Forrester, there are certain attributes associated with business processes that make them more appropriate for RPA. Forrester’s Rule of Five suggests that you should look for tasks with fewer than:

  • Five decisions made
  • Five applications accessed
  • Five hundred clicks

Mainframe Automation

Some also believe that there are certain types of data sources that are difficult to automate. One of those is mainframe applications using “green screens”. These applications require a desktop terminal emulator for users to interact with the applications, and the navigation of these applications can be very complex. Most mainframe applications wouldn’t meet Forrester’s Rule of Five.

Emulator Interaction

The way RPA tools automate mainframe applications is to interact with the same terminal emulator used by end users. There are typically two ways to interact with an emulator and many RPA products only support one of them. The two ways to interact with an emulator are:

  • Extended High-Level Language Application Programming Interface (EHLLAPI)
  • Screen scraping the emulator screen

EHLLAPI is much more accurate than screen scraping but is still difficult to use and doesn’t provide full functionality. Also, depending on the age of the emulator, it may not support the same calls built into the RPA tool. Because of this complexity, as well as the complexity of the mainframe processes, many RPA companies consider automating mainframe processes to be an advanced feature that requires a more advanced programmer.

Some RPA tools use screen scraping which is the same way they interact with Citrix applications. You have to know the screen coordinates of objects and data in order to interact with the screen. This is very inaccurate and should only be used as a last resort and for very small tasks.

There’s A Better Way

There is another way to automate mainframe applications, and it works with your existing RPA tool. Instead of interacting with a terminal emulator, why not interact directly with the mainframe the same way a terminal emulator does? OpenConnect has been providing mainframe connectivity products for many years and has the technology to automate mainframe applications without a desktop emulator.

How it Works

OpenConnect technology connects to the mainframe using TN3270, the same protocol used by terminal emulators. The software maintains a persistent session with the mainframe and handles all of the screen mapping. The difference is there is no actual screen. Everything is in memory and the raw data is processed directly instead of sending to a screen for human, or robot, interaction. This reduces overhead and dramatically increases performance.  Because it’s server-based, it will support thousands of concurrent sessions on a single platform.

ConnectiQ is a product that includes this technology and works well for integration with RPA tools. ConnectiQ does not rely on an API to interact with the mainframe application. It has access to the raw 3270 data, so it “sees” every attribute and every character making it more accurate than technology that uses an API or screen scraping.

Design Tasks Without Code

A task designer tool called Configure is provided to create the tasks that interact with the mainframe screens. It’s designed to be used by people who know the applications and processes, not programmers. Configure allows you to create tasks that perform common functions. Tasks can call other tasks allowing for reuse of common functions and reduction in time to deliver value. Once the tasks are complete, you simply deploy to the server and mark it as available to the services. Version control is provided natively and allows you to support multiple versions for each environment.

Users can access the tasks through web service calls using SOAP or RESTful services. This allows customers to integrate mainframe application data into any application including customer portals, mobile apps, front-office applications, back-office applications, and RPA robots.

ConnectiQ Provides Flexibility & Value

RPA tools provide methods to call web services to retrieve information. ConnectiQ provides the complex navigation of mainframe screens with high accuracy. Whether the mainframe applications are 10% of the process or 100% of the process, ConnectiQ is the right solution to embed mainframe applications into your RPA strategy. The tasks you create for RPA can also be used for other external applications such as customer/partner portals which provides even more value.

Automating Requirements Gathering for your Automation Process

With any software development project, the most time-consuming, critical factor is getting the requirements right. Meeting with employees, documenting their work, recording the necessary data, and more. For an automation project, you need to know the exact process flow from start to finish, including screen names, screen captures of each screen, and specific field-by-field steps taken on each screen.  These are the details used to create automation scripts, and it can’t be done without them. This means dedicating hours and resources to subject-matter experts and end users through the discovery process and having someone sit with process workers and gather all of this detailed information.

More and more we work with companies that come to us already frustrated with what lies ahead. They have a laundry list of processes they need to automate. But to make this happen they must first complete the discovery and requirement efforts which can be completely overwhelming and complex. It’s hard to see a light at the end of the tunnel when you aren’t sure where it begins.

With years of experience implementing complex RPA projects, we understand that sometimes the hardest part is getting started. Having a workforce monitoring solution in our portfolio, we’ve worked with clients to change the way automation projects get done. Our solutions help save time—and unnecessary stress—by automating the requirements needed to kick off any automation project.

Leveraging real-time data by monitoring employees as they work, OpenConnect captures a complete and accurate understanding of the details needed to visually map the process.  We developed DiscoveriQ to compile the required screen shots, illustrate the step-by-step field level details of the process, and automatically generate a requirements document.

Using DiscoveriQ reduces the requirements and discovery process by as much as 70% while also ensuring the accuracy of those requirements. This means less iterations of your automation code.

If your company is struggling with pending automation projects, regardless of which RPA solution you are using, schedule a demonstration of DiscoveriQ. Click here to learn more.

Success Is Best When Shared: The Importance of Measuring RPA Outcomes

This is the third post in a three-part series (Part 1, Part 2) that outlines the steps for automation project success.

When embarking on and completing any kind of process improvement project, many leaders forget to baseline pre-project performance metrics. This is extremely important for your automation initiatives to gain support for moving forward with automation of additional processes. It provides tangible measurements to track success and communicate it throughout the organization. Here are key components to include in your report.

Establish a baseline. Before starting your automation project, reference the agreed upon success criteria identified in your goal alignment workshop (see my first post in this series, “Three Steps to Jump-start Your Process Automation Project”). For each of the goals and KPIs identified by your team, take a baseline measurement of how the organization is currently performing against those metrics.

Communicate the big picture. From the very start of the project, plan to create a presentation to share the vision of what the project will look like when complete, and share the projected ROI. This helps communicate exactly what to expect, while also establishing the baseline. Your presentation should depict a very clear picture of the current state and how work is getting done. This should be followed by a description of the improvements you will make, the goals you wish to achieve, and a projected return on investment.

Share your metrics. After you have launched your RPA bots and had enough time to realize results of your project, complete the presentation with the end-state metrics. Include the following in your report, and be sure to share it with all business stakeholders and others who would benefit:

  • Project goals
  • Pain points
  • Persona profiles for each of the types of users doing the work
    • Name and title
    • Job description
    • KPIs by which they are measured
    • Personal pain points
  • Current state process map
  • Current state performance metrics
  • Final state process map
  • Final state performance metrics
  • Tangible improvement metrics
  • Intangible improvement metrics
  • Return on investment
  • Lessons learned

Most automation projects result in significant improvements and cost savings. You will have a very impressive story to tell once the project is complete. The best way to ensure that you can build on that by implementing other projects is to build excitement by sharing your story.

If you are trying to get buy-in for your RPA project before having that experience, OpenConnect has developed a service called DiscoverNow to help build a business case. It illustrates a potential end result based on our years of experience implementing these projects for our customers. We can use the same methodology to help tell your story once the project is complete. Let OpenConnect help make you a superhero for your business! Call today to schedule your DiscoverNow session.

How User-centric Discovery Can Ensure the Success of Your Automation Project

Henry Ford once said, “If I had asked people what they wanted, they would have said, ‘faster horses.’”

I am always amazed that many companies don’t get feedback from the people who actually do the work. Instead, they still define their requirements by bringing a group of leaders and subject matter experts into a room and asking what they need. Don’t get me wrong; good ideas come from these meetings, but you can miss opportunities to really make improvements and eliminate things that are holding you back.

This comes from sitting down with the people doing the work, day in and day out. Listening to the challenges they face will give you the opportunity to try something new and different to dramatically change the way work gets done. While this task appears beneficial, the approach may seem daunting. Here are tried-and-true methods our clients have used to get the right solutions for their operations.

Zone in on key performers. When starting the process automation project, identify one or two top performers and a few from the bottom of the pool. Next, spend some time walking in their shoes with the goal of documenting a day-in-the-life of your process workers. This is the only way to truly understand why they do their work the way they do.

Walk in their shoes — literally. The most effective way of doing this is through user observations or “shadowing” the user in their environment. Sit in their cubicle. Ask them to narrate the work they are doing. Question when you need more detail. Request screen shots and copies of any materials they use, such as “cheat sheets” and reference materials. This ensures you have the details to build requirements. Take note of any complaints or challenges. At the end of your time together, ask for a list of their top three “pain points.”

Leverage your tools. To ensure a truly accurate snapshot of the work being done, consider enhancing your discovery process with analytics tools. OpenConnect’s WorkiQ and DiscoveriQ automatically gather detailed process data. This provides “time and motion” data to show the duration being spent in the applications required to complete the process. It gives insight into productive vs. non-productive activity for each user. It will also give you a significant head start on documenting the process automation requirement. In the end, you have an accurate benchmark of your as-is process to later compare with the automated solution.

Determine: what’s in it for them? It’s critical to understand what motivates your process workers. This is a major factor that drives work behavior. Take time understanding the KPIs by which they are being measured. Uncover any personal concerns that negate their performance.

Having the full and complete picture of how work is really getting done gives you all the information needed to map out next steps. It opens the gate for new and innovative ways of tackling the work. It also identifies opportunities to automate the parts of the process that do not require cognitive human interaction.

User-centric discovery has been proven to reduce re-work both in software design and for RPA projects.Equally as important, it helps with user acceptance rates when a new solution is rolled out. This is because the end users have participated in the process and feel a sense of ownership.

If you missed Part 1 of this blog series, click here to read “Three Steps to Jump-start Your Process Automation Project.” Next time, we will share the importance of measuring the success of your automation project.

In the meantime, OpenConnect is ready to guide you through the discovery process and help build a business case. Click here to contact us today to schedule a DiscoverNow session.

Your RPA Strategy Is Out of Control

Many companies decided to start their RPA journey by experimenting with one RPA product and one process just to get a feel for it. One thing led to another and soon they had multiple processes automated and were planning even more. However, department A wasn’t talking to departments B or C, and each department started on their journey independently. When someone in the organization finally decided it was time to put some structure around RPA, they ended up with multiple RPA products with no real strategy to manage the environments.

The main reason for creating a structure, or center of excellence, around RPA is to ensure the business departments are able to effectively manage their automation strategy without negatively impacting the company as a whole, including the IT department. RPA works by interacting with application screens. It’s important for the business to understand if/when those screens could change, so the robot navigation can be updated to accommodate those changes. It’s also important for IT to know that robots are working against the user interface of the applications so they can appropriately manage the application resources to ensure there is no negative impact on performance. After all, robots are faster than humans and could have an impact on the applications.

When putting structure around an RPA strategy, there are two very common but different approaches. The first is a federated approach. This approach allows each business department to use an RPA tool of their choice as long as they follow the guidelines set by the governing body. The other approach is unfederated, or centrally controlled. This approach would only allow the business departments to use an RPA product that is sanctioned by the governing body. This puts a great deal of responsibility on the governing body, but also prevents mayhem by insuring the RPA products have been fully tested and the management structure is in place to deal with any issues. Regardless of your approach (federated or centrally-controlled), you still have an issue any time you have multiple RPA products to manage.

So, how do you monitor, manage, and control all of your RPA products? One solution is to use an orchestration platform that supports third-party RPA tools. One such solution is AutoiQ from OpenConnect. AutoiQ utilizes a small software agent that runs on each desktop and interacts with the desktop robot. This allows an organization to solve multiple problems by:

  • Providing a solution that manages multiple vendor robots
  • Utilizing the best products for each department with governance
  • Integrating multiple vendor products into a single solution

AutoiQ provides a single interface to manage the desktop connections, credentials, and third-party robots. You can even create process definitions from a simple-to-use interface and call third-party robots to execute tasks. Since AutoiQ is task-oriented, you can create tasks to perform small units of work, such as “Get Customer Information,” and each task can utilize the RPA product chosen by the department that owns that task. AutoiQ will then orchestrate the various tasks, including tasks within AutoiQ, to execute an end-to-end process. By utilizing the advanced features of AutoiQ, and the existing RPA products, you can automate more processes, and more complex processes — all with a centrally managed enterprise-level automation solution. And, with the most advanced mainframe connectivity available, AutoiQ can reduce the amount of time per work item, which reduces the number of robots and desktops required to do the same amount of work. It’s one of the most effective tools to help take your RPA strategy from out-of-control to under control.

Is RPA Really Designed for Business People?

According to all of the marketing from RPA companies, any business person can use RPA and quickly automate their business processes. Unfortunately, most don’t get the expected return on investment and many can’t even automate more than a single, simple process. The main reason is that RPA is really programming. Yes, the RPA vendors try to make their tools easy to use. But if you have any business rules that are more than if-then statements, then you really should know some basic programming. For most business processes with an average amount of complexity, you will need someone with programming experience. But programmers aren’t subject matter experts on your business processes. So how do you educate them on the processes so they can create the automation logic?

One method is to use a task-oriented architecture. This will allow you to separate the business logic from the screen navigation so that the business analyst can focus on defining the process and a task programmer can focus on small simple tasks. A task-oriented architecture provides a section containing only business logic. The business logic calls tasks to perform work. For example, if you need to retrieve customer information the business logic would call a task called getCustomer, and it would pass in a customer ID. The task simply navigates screens and returns customer information based on the customer ID passed into the task. However, if you’re using a standard desktop-based RPA tool, there really is no way to separate the business logic and task logic. It still requires a programmer to create the business logic and the task.

The AutoiQ way

OpenConnect’s AutoiQ provides a better way. Since it’s server-based, not desktop-based, business analysts can create the business logic and programmers can create the tasks. The business logic is created through a standard Web interface and is fully versioned. This allows a business analyst to add logic then increment the version number before testing. If errors are found, a few mouse clicks gets you back to the previous version. You can add logic and change versions as often as you like without impacting the production version. The tasks can be created using standard RPA tools, the OpenConnect mainframe tool, standard Web services, or direct database access. Any of the most common RPA tools will work with AutoiQ. If you already invested in RPA but are having a difficult time actually automating your more complex processes, then use AutoiQ to handle the logic and your existing RPA tool to create the tasks.

In addition to providing version control for the process definition, AutoiQ also allows you to have different environments such as Dev, Test, and Production. A process that is marked as Dev will only access resources, credentials, and tasks that are also in the Dev environment. When promoted to another environment, it will then use the resources in that environment, allowing you to take advantage of standard environments without the need to move multiple pieces to different servers. Other RPA products require you to use a third-party version control system designed for programmers.

All of the AutoiQ features result in lower development costs, faster return on automation investments, and the necessary governance controls to deliver enterprise automation at scale. The flexibility and control built into AutoiQ give business people the power to master their RPA.

Three Steps to Jump-start Your Process Automation Project

Having worked with many companies on their process improvement initiatives, I have found that the hardest part of getting them started is simply figuring out where to start. There are so many opportunities for improvement, but most companies don’t have the luxury of tackling them all at once. So where do you start?

It’s important to pick the right processes to kick things off, because you must be able to show significant impact and return on investment for your improvements. The first project inevitably becomes the proof point for the value of your process improvement initiative.

The most common challenge is overcoming internal politics. It’s easy to become distracted by the leaders who are making the most noise about fixing their process when there might be other areas that can yield a better return for the company. Unless you get all of your stakeholders in the same room to prioritize your list as a team, you run the risk of focusing on the wrong area.

1. Align goals and get your team on the same page.

Start by setting aside half a day to get your leadership team on the same page. Your meeting should begin with a reminder of the overall goals of the company, and the ultimate goal of your process improvement initiative. Everyone should bring their list of processes they think need the most improvement.

2. Apply metrics to the processes you recommend for automation.

We all know you can’t automate all processes at once. That means that your team is going to need to prioritize. In order to remove the politics from your prioritization efforts, you must apply metrics to the processes you wish to automate:

  • What is the motivation for automating the process? Is it reducing costs, increasing throughput, improving quality, or something else?
  • What is the measure that represents the value of what needs to change? For example, measures might include cost per work item, time to complete, or number of errors.
  • What is the current value for the metrics being measured?
  • What is the goal for the metrics?

3. Prioritize based on facts.

Now that you know the “value” of each of the processes on your wish list, it’s easier to objectively prioritize the processes with the best interests of the company in mind. When you are able to successfully able to get your leadership team to think at the “big picture” level, you have a better chance of more quickly achieving return on your investment.

Now that you know where to start, it’s time to kick off your first automation project.

Next time, I’ll talk about using user-centric discovery to ensure you have the most accurate requirements ensuring a successful start your automation process.

In the meantime, if you’d like OpenConnect to guide you through your discovery process and help you to build a business case to justify your project, click here and contact us today to schedule a DiscoverNow session.

How RPA Gives You the Flexibility You Need

Over the past few years, the healthcare insurance industry has been the focus of a tidal wave of changes — regulations, new market challenges, open enrollment, labor challenges with business process outsourcing, and a significantly more complex operating environment. More than ever before, healthcare insurance companies can benefit from robotic process automation (RPA). Interestingly, the question we get the most is: “Where do we start?”

While we and other vendors can help you discover the processes in detail (for example, please see our complete-package solution), perhaps we can start with identifying the operations areas that will net the most significant ROI. OpenConnect has been helping healthcare insurance companies automate for over 12 years, and here are the top four areas where we have seen our customers derive the most significant benefits from automation:

  • Claims adjudication
  • Enrollment and membership services
  • Provider data services
  • Revenue cycle management

Each of these operations has a complex need for both human and robot interaction, due to the challenge of data management. If the data is incorrect or not normalized, core systems begin to create exceptions, which drives up the need for more human labor interaction. Even worse, the patient experience suffers.

For many companies, these menial tasks and other routine data-entry processes continue to be handled manually. The cost for maintaining that status quo can be steep: it costs $57,725 to hire and employ just one data entry worker (this figure is based on data gathered from the U.S. Bureau of Labor Statistics and the Center for American Progress).

Working the plan — but staying flexible

Let’s consider the game of football (for our friends outside the U.S., we mean what you call “American football,” not what we call “soccer”). In football, the quarterback’s job is to direct his team down the field. And, although the team has a game plan, the coaching staff isn’t afraid to have the quarterback “call an audible” to adjust to the opponent’s constantly changing defensive “looks.” Using his vision of the whole playing field, the quarterback’s situationally responsive selection could be either running the ball or throwing a pass – each of which may deliver a successful outcome.  In fact, the so-called “run/pass option” play has become increasingly popular, precisely because of that flexibility it gives teams.

Much like a football team’s need to change things on the fly as they see new and shifting challenges looming ahead, healthcare insurers also need the flexibility RPA can provide in their strategy. While claims tend to be the first focus, we see customers identify sub-processes every day that can change the outcome of the game — in this case, a correctly paid claim. Think back to the “top four areas” we identified earlier. We have many customers who are attacking claims adjudication and seeing trends in provider data inconsistencies. This new knowledge allows our customers to pivot and begin pointing robots at cleaning provider data, which results in improvement to all claims adjudication rates.

This is the benefit you achieve when robots are implemented based on detailed analysis performed before the implementation. Even when employees are buried in manual data entry work, they’re hard-pressed to raise the level of the team’s or company’s performance. Starting an automation strategy opens the lens to “calling audibles” for your operational performance. Just like a team that sticks to a game plan even after it’s become clear the other side has overcome it, an annual business plan that involves throwing more human labor and overtime at a problem doesn’t work anymore.

So, as you embrace automation for all the benefits it can and will bring you, be sure to choose not only a vendor but also a plan that will give you maximum flexibility to meet your challenges — both the ones you can see now and the ones you can’t quite see yet.

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.

Five phases of the automation process

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.