Automate Your Mainframe With Any RPA Tool Better

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.

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.

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.

With RPA, It’s Not Just “Point A to Point B”

Imagine you decide one day to go shopping for a new ride. You do a quick Web search for what’s available, what’s in your price range, who’s selling what in your area, and so forth. However, something strange occurs. No matter where you go and no matter how you word your search, you keep coming up with a silver-colored, base-level, four-door sedan — mind you, it’s the same basic silver car, over and over. Every dealer’s website emphasizes that you don’t need different vehicle choices because it doesn’t matter what you get: all you want to do is get from Point A to Point B.

You say to yourself, “This can’t be right. What if I need more room to carry my family and friends around? What if I want something with more horsepower? What if I want a different color? What if I want some special features?”

And you’ve got it: This can’t be right. Yet that’s precisely how some vendors want you to think about robotic process automation (RPA). They want you to think it’s pretty much a commodity now, that one product is about the same as another, and that it doesn’t matter all that much which one you get. “Additional features? Bah! You don’t need those. Ability to handle complex tasks? Pfft! That’s not what RPA does! Server-based connectivity with mainframes? Ridiculous! It doesn’t matter.”

Well . . . yes, maybe you do; yes, it does; and yes, it does.

As much as some of the vendors out there may want to pretend that there’s no difference among the offerings, it just isn’t so. We’ll set that straight in a moment.

 

RPA: More Than Just a Silver Sedan

First, let’s start at the beginning. What exactly is RPA?

In its simplest form, the meaning of RPA is automating human-executed processes with no changes to the existing infrastructure or applications. Among RPA vendors, most interpret this to mean a software robot running on a desktop and interacting with the same user interfaces used by humans. Moreover, the general perception apparently is that there are two types of automation: RPA and everything else.

In this mindset, RPA is billed as the easy entry product that quickly automates mundane tasks to free up users to do the more important and interesting work; so, naturally, many people consider all RPA products to be equal when it comes to automating processes. It comes down to a feature checklist to determine which RPA product(s) to choose for each organization: whatever is an RPA product — by this interpretation, something that runs on a desktop and interacts with the user interface — will be considered. It’s silver sedans all the way down.

(OK, sorry; wrong metaphor.)

There is one big problem with this: not everybody wants or needs a silver sedan! There are many different types of processes that can be automated. Here are two big mistakes organizations make:

  • They lump all RPA products into the same bucket and look at only the feature list.
  • They consider only mundane, simple tasks/processes for RPA automation.

Companies, Evaluate Your Processes

When considering automation opportunities (as we’ve discussed in earlier blog posts here), companies should first look at all processes, from the complex to the simple (“mundane”), and then find the right tool — and they shouldn’t look at just the tools that fit the simplistic definition of RPA.

There is a continuum of process complexity that ranges from simple through moderate to complex. Traditional RPA tools can handle simple, and some moderate, processes, while they struggle with some moderate and most complex processes. For these reasons, your automation strategy should include several tools, one for each complexity level. Many companies already choose at least a couple of products for their standard RPA solution. But these choices typically are based on either the best two feature sets (the classic “look-for-the-most-bullets-in-the-feature-list” approach) or one product for unattended automation and one for attended (also called assisted) automation.

Some families need multiple vehicles: a nice-sized crossover to carry everybody around, an econo-car for workday commuting, and maybe even a sporty car for one or more teenagers. One silver sedan just won’t cut it. And, when it comes to RPA, one product isn’t enough. What you really should have is one RPA tool for attended automation and two or three others for unattended automation. The reason you should have only one attended solution is because the users who interact with it can be confused by having to learn multiple products. You should find the best-of-breed product and do a thorough evaluation of it with end users to make sure it meets their needs. For attended automation, the users are key to your success, so find a product that is easy to use, yet powerful enough to handle users’ needs.

The reason you need more than one unattended solution is because, again, the same silver sedan can’t fit everyone’s needs. One RPA product might not be able to successfully automate some of the more complex processes and another might not be cost effective for simple processes. You should look at the problems you’re trying to solve and choose the appropriate solution to each problem.

Simple to Moderate Processes

Simple to moderate processes are those processes that have simple logic and few decision points. For those, look at standard desktop-based RPA tools. You can find a list of the usual suspects by searching on the Web; but don’t choose one just because it has the highest rating from Gartner or Forrester or another analyst you may prefer. Instead, look at the strengths and weaknesses of each tool and compare that data to your actual requirements.

Desktop-based RPA tools should be used to automate mundane, simple tasks. These products are designed to sit on a desktop and automate processes exactly like a human. They are perfect for simple processes such as data entry, but may not be appropriate for complex processes that require advanced business logic or have many decision points. Many of these products also provide a server to allow you to monitor the desktops and robots, and to dynamically scale when needed. Still, don’t be fooled by the presence of a server here: in most cases, the server does not contain any business logic or allow robots to share information. This is not server-based RPA.

Moderate to Complex Processes

For automating moderate to complex processes, you should look for solutions that specifically state that they can automate complex processes. These solutions are usually server-based, as opposed to desktop-based, and usually have some proprietary technology that allows them to access applications more efficiently and accurately, and with high scalability and availability.

These systems are designed to handle complex logic and usually provide more than just desktop access. For example, access to Web-based applications might be accomplished through a server-based Web browser allowing higher scalability, efficiency and accuracy. Another example is mainframe “green-screen” access. A desktop-based RPA product interacts with mainframes through a desktop-based terminal emulator via either EHLLAPI or screen-scraping, both of which present major challenges unless access to the mainframe is a very small part of the overall picture.

What to Look For in RPA

Here are some guidelines that can help you choose the right solution:

  • How long does it take an end user to learn the process?
    – Hours to a few days = simple process.
    – Days to a week = moderate process.
    – More than a week = complex process.
  • How large is the daily inventory of work and how many humans does it take to complete it?
    – Requires 10 or fewer workers = low-volume process.
    – Requires 50 or fewer workers = medium-volume process.
    – Requires more than 50 workers = high-volume process.
  • What is the impact to the business if the process isn’t executed properly?
    – Minimal impact = low.
    – Fines that could hurt the bottom line = moderate.
    – Fines and interest that add up to millions = high.

The Bottom Line: Where the Rubber Meets the Road

Remember, basic silver sedans won’t serve everyone when it comes to RPA. Even though the desktop RPA vendors have managed to make a name for themselves, there are better RPA solutions available for high-volume, high-value, complex processes. You don’t need a complex, BPM-like solution to automate these processes. RPA technology will work — so long as the architecture of the solution is designed to handle it.

Free RPA: What’s the Big Deal?

You probably know by now that at least one company in our industry is offering a free RPA tool. You may be wondering: is that good or bad for the RPA industry? I guess that depends on whether you’re a provider or a buyer. I think the buyer perspective is obvious, so let’s look at it from the provider perspective.

If you’re a provider, and you have a desktop-based RPA tool, then you should be concerned. You should be looking for ways to add value to your product, so you can focus on the additional value you provide and not the RPA functionality. Of course, you could also try to compete strictly on features and functions, but it’s hard to compete with free. Or maybe you believe you already have a product that can compete with free. I guess you’ll soon find out.

But is it good or bad for the industry? I believe the answer is both.

On the one hand, it’s good because it will force vendors to look for ways to improve their tools beyond RPA. On the other hand, it’s bad because it makes it easier for companies to implement desktop RPA tools. Why is that bad? Because RPA is not necessarily the right solution for all situations. RPA has definite advantages and can be the right solution, but it can also cause a lot of problems if it’s not implemented correctly.

Best Practices for Implementing RPA

That consideration leads to the obvious question, “So just exactly how do you implement RPA correctly?” Here are some best practices I would suggest.

  1. Access applications and data using the most efficient, accurate, scalable way available. — The desktop user interface isn’t the best, but may be the only option. I’ll soon talk about what you should do if it’s not.
  2. Make sure the IT department is involved and that you’re on the change control list. — Caution: If you’re using RPA with an application that sees a lot of UI changes, this could hamper IT and delay application improvements requested by other departments; and that will not make you very popular with the folks in IT. Remember: RPA tools rely on a consistent user interface. If your IT department changes the user interface to improve usability, RPA robots may stop working.
  3. Centralize the logic and runtime execution so that you have better control. — A free RPA tool could proliferate rogue departments’ automating applications without the knowledge of their IT department. This could cause major issues and cost the organization a lot of money. It gets back to having a good automation strategy and, possibly, a center of excellence. [Editor’s note: Kevin discusses these and other aspects in his five-part series on robotic process automation, which begins here.]
  4. Provide full auditing and reporting capabilities.
  5. To avoid issues with changing UIs, use APIs, Web services, and database calls as much as possible.
  6. Use RPA when it’s the only option available, and avoid the desktop as much as possible. — I’ll explain that in more detail next.

You Really Can Get Around the Desktop

Now you might be saying, “Okay, so just how do you ‘avoid the desktop as much as possible,’ and why is that important?”

First, by “the desktop,” I really mean Windows. We all know that Windows updates occur frequently, and Windows applications rely on the underlying operating system to function properly. I have seen updates in Windows and/or applications kill RPA robots.

That’s why you should avoid desktops if possible; but how?

Believe it or not, there are other ways to access many of the same applications without accessing a Windows desktop environment. OpenConnect has been providing automation solutions for over 10 years, and has always looked at automation from an enterprise level. That’s led us to stress the superiority of a server-based approach.

There are two common types of applications that can be accessed from a server: mainframe 3270 applications and Web applications. The OpenConnect automation platform, AutoiQ, has a proprietary data connector that allows it to connect directly to mainframes via the TN3270 protocol. With AutoiQ, you interact with the exact same screens that end users access on their desktop, except that there is no desktop. All sessions run in memory, and a single server supports thousands of concurrent sessions. There’s no desktop and no Windows, just pure, raw 3270 data, processed 15 times faster than desktop-based RPA tools can do it; and the process is 100% accurate.

Embrace Web Services and a Server-based Environment

In a similar vein, there are two different ways to access Web applications other than through a desktop-based browser. The first is through Web services. They’re machine-to-machine communications and are typically available in modern Web applications. By accessing the application through Web services, you completely avoid the user interface altogether. No change control issues occur, because you’re not accessing the user interface.

The other way to access Web applications is using a server-based browser environment. Server-based browsers don’t run on Windows and don’t depend on specific browsers’ functionality. Note that this approach won’t work for all applications; but you should be able to minimize the desktop access.

A few other items that can be avoided include file access and file parsing (reading). Network access to files and the parsing of files can all take place on a server. It is common to have to read Excel, Word, and PDF files as part of an automated process. All of these file types, and more, can be accessed using server-based technology — again, avoiding the desktop as much as possible.

Here’s Why You Should Minimize the Desktop’s Role

The goal isn’t to eliminate the desktop. That’s probably impossible for most environments. But you should be able to minimize the number of desktops required, thus minimizing the risk. Your approach should be to look for ways to do the work on the server, instead of a desktop. You may find that you can end up with 25% to 50% fewer desktops you originally thought you would need.

With this approach, the desktop becomes just another data source so, if there’s a free tool available, that’s good. The value is in the server and how it executes processes and manages robots — not in the tool used on the desktop.

Free RPA Is a Move in the Right Direction

In my opinion, a free RPA tool is good news. It will impel the industry to create tools that provide automation the right way. That means using the right tool for the job, or application, rather than doing everything on the desktop.

I believe the presence of free RPA tools will move our industry to act in ways that will benefit all of us, users and providers alike. I also believe that, regardless of the automation tool you select, you’ll have a better chance of filling your automation if you follow the guidelines I’ve described in this post and elsewhere.

Robotic Process Automation: Part V (conclusion)

Part V: Managing Your Backlog of Automation Opportunities

Setting priorities is critical in a successful implementation of RPA. Here is a proven strategy for making it go more smoothly.

So you now have an RPA product and you implemented an automation strategy (or Center of Excellence). This means you should have a change control process. With it, you can plan changes to your automation solution before they actually occur.

This also means you have a strategy for identifying and prioritizing automation opportunities. You see, most people feel pretty good about their automation strategy — until multiple business units come into the mix. Then, the number of opportunities on the table increases to a level that makes prioritizing more difficult. You can easily end up having to tell one business unit that it will have to wait longer than expected because another, higher-priority opportunity came in.

Worse: when you prioritize by committee, your automation team can become a scapegoat for business units that aren’t meeting financial goals. You can also have some very uncomfortable meetings when you discuss the priority list.

Make sure you have a strategy team (sometimes called a steering committee) with executive involvement. This ensures that all decisions are based on the overall company needs, not just because one group “yelled” louder than the others!

You could also put in place a standard way of measuring the opportunities. This greatly increases the probability that everyone involved will agree on the priority list.

Let’s explore these various ways to identify and prioritize your opportunities.

Strategy Team

A strategy team identifies and prioritizes automation opportunities. It does so by working with the various business units; each unit proposes potential automation opportunities with the unit’s respective priorities. The strategy team should consist of at least one executive, one or more members of the automation team, and one member from each business unit. This team will put all of the various groups’ opportunities in a single prioritized list. The team should meet regularly — once per week or once per month, depending on the number of business units and opportunities.

This approach works well if you have a strong strategy team. Members of this team must be able to say “no” to a business unit if the opportunity isn’t a good fit. They also have to manage the expectations of each business unit and explain why that unit’s highest priority is well below that of other business units. Communication is key, and a well-documented, well-thought-out process is vital.

Problems occur when a member from one business unit constantly fights for higher priorities for that unit’s opportunities. A scoring system can help eliminate this infighting, but the system has to take into account each business unit’s key attributes. The scoring has to make sense for everyone.

Estimated Cost Savings

Another approach is to use the estimated cost savings as your key measurement. You can require each business unit to provide the potential cost savings for each opportunity it provides — but it has to show its math! One of the biggest problems organizations have is business units’ overestimating their cost savings just to get their project to the top of the list. They should be required to show the real numbers.

You can provide each business unit an Excel template that has fields for all of the data points required. The resulting spreadsheet can then be submitted to the automation team for review and inclusion in the backlog of work. The template will calculate the potential cost savings based on the time it takes a human to do the work and the potential automation success rate. You can estimate the cost of the work to be automated by first calculating the total human time spent in a process. Here’s how you do it:

  1. Multiply the time it takes for a human to execute the process by the number of times your company executes the process each year.
  2. Divide this number by the productive hours expected for each employee, and you get the number of full-time equivalents (FTEs) your company requires to do the work.
  3. Multiply the FTEs number with the all-in cost of an FTE to get the total cost of the process.
  4. Using subject matter experts, calculate the percent of the work that can you can automate successfully.
  5. Multiply that by the total cost to get your estimated cost savings.

This arms the automation team with hard data to help prioritize the backlog. It reduces the infighting and helps the process run more smoothly.

Workforce/process Analytics

Another approach is to use analytics to identify and prioritize automation opportunities. With the resulting data, you can then present your findings to the various business units. That way, you can get their buy-in and cooperation, instead of relying on them to provide the information. Depending on the analytics solution you use, you might also get additional benefits such as:

  • Workforce productivity improvement
  • Process improvement
  • Eliminate self-reporting of work/time

When choosing an analytics solution to use to identify automation opportunities, look for one that can measure workforce activity. That capability should allow you to capture the time it takes each user to execute processes. Then, compose a list of processes in which you sort them by total time spent, which is the same as cost. Process improvement products that measure the details of a process can also help in prioritizing. More importantly, they can help in identification of the process steps. This can help you automate more quickly, because RPA robots take the same steps as humans.

OpenConnect’s Approach to Process Automation

OpenConnect has developed an approach to process automation that includes both workforce and process analytics tools to help identify and prioritize automation opportunities. We developed this approach nearly a decade ago, and many large customers have validated it. I have personally worked with many of these companies and have seen how powerful the combination of analytics and automation can be. If you follow the suggestions we have made in this series, I believe you will have similarly impressive results.

This is the conclusion of a five-part series about robotic process automation. The previous articles in the series are:

  • Part I, “What Is RPA, and Why Should CIOs Care?”
  • Part II, “Creating a Process Automation Strategy”
  • Part III, “Choosing the Right Process Automation Solution”
  • Part IV, “Pitfalls in Implementing Process Automation”

Excel is a trademark of Microsoft Corporation.

Robotic Process Automation: Part IV of a five-part series

Part IV: Pitfalls in Implementing Process Automation

You bought your shiny new RPA tool, and now you’re ready to build your software robots. Do you have an automation strategy? If not, see Part II. If you do, then you already have your top five to 10 automation opportunities defined, along with the expected ROI of each. You probably already have your requirements document for the first opportunity. You have your team in place and ready to go. But how do you really go about implementing process automation?

First Considerations

Before you hand over your RPA tool to a programmer, make sure you have applications — preferably test versions — and test data ready to go. After all, you don’t want your programmer using production applications and data! Make sure you have enough test data that the programmer can go through each scenario at least a dozen times.

Perhaps you have the type of data that either disappears or is moved to another state after processing. If so, make sure your programmer understands this and, therefore, waits until the end of the programming process before actually submitting the data.

Keep in mind that the programmer will run into issues, and must run the scenario multiple times with multiple pieces of data. That’s why you need enough records with the same issue — so the programmer can thoroughly test each scenario and each business rule.

Types of Testing

Testing is obviously a crucial part of implementing process automation.

When programming is complete, the programmer should run unit tests on each scenario and document the results. Some tools can self-document the unit tests.

The business should examine these results before moving to the next stage, system integration testing. All this really means is that you configure the new process into the server and then run the tests again, to make sure everything works from end to end. If your automation solution is a standalone desktop RPA tool, you probably won’t need to do system integration testing; but, with a more powerful, server-based automation solution, you will have that need.

The last step before moving to production is user acceptance testing (UAT). To do proper and thorough UAT, you need several records for each scenario. You also need records that fit multiple scenarios, so you can make sure the robots can handle multiple scenarios for a single record. A typical volume for each scenario is 100 records but, depending on your situation, you may need more, or fewer.

The Importance of Audit Logs

After running UAT, the business will evaluate the results, using the standard tools it has available. However, if your automation solution provides audit logs — and it should — that can be a great way to validate that the robots followed the correct rules. What often occurs is that the business tells you the robots didn’t work an item correctly. If you don’t have auditing capabilities, you’re looking at a long day of trying to figure out the problem.

I have worked with customers who said the robots did the work incorrectly. Yet, the audit logs showed the robots did exactly what they were programmed to do, based on the requirements document. It turned out that the requirements themselves were wrong. That’s a simple fix, with little time spent troubleshooting.

Trust me: make sure you have a product that provides audit logs!

When It’s “Go” Time

Now, finally, it’s time to deploy to the production environment. Here’s a typical scenario: everything works in unit testing, system integration testing, and UAT, but fails in production. What happened? There are two common causes for this:

  • The data used in all of the testing phases didn’t properly represent production data. You can fix this only by having good data. It’s critical that the data used in testing matches the production data.
  • Moving the code from test to production changed something. This may be due to the tool you’re using. Some products provide a deployment function that ensures the code you tested is exactly the same code you tested. This is a great feature! You should make sure it’s part of any product you choose.

Implementing process automation is a major, and wise, step for your company. Here’s hoping this post will help make it go a little more smoothly.