Responsible RPA Fuels Actionable Insights 

Imagine spending eight hours of your day performing data entry or data movement from one program to another—Control + C then Control + V, copy and paste, from one screen to another all day long. This repetitive, manual, and time-intensive work becomes your working life.

When systems are not integrated, whether for lack of system flexibility or lack of resources, and data must still flow between these systems, data needs to be moved manually. Typically, these data movement tasks are repetitive and mindless. And the truth is that people are generally not very good with repetitive, mundane tasks. When we perform the same mindless tasks over and over, we make mistakes, whereas computers do not.

RObotic process automation 

When most people first hear about Robotic Process Automation (RPA), they tend to think about robots building cars or Arnold Schwarzenegger as the “Terminator.” Instead, RPA is the automation of manual tasks within the digital domain. It leverages business logic and structured inputs to automate repetitive, rule-based tasks of a knowledge worker – someone spending most of their time on the computer extracting data, building reports, and running analytics. RPA aims to remove mundane tasks from the knowledge worker so they can spend more time performing value-add work.

RPA tools work on the presentation layer (also known as the user interface) so they can identify elements of both web and software applications and interact with visual elements on the screen. RPA works on the same interfaces we use, emulating the keystrokes and mouse clicks users perform. Thus, RPA can start applications, fill out forms, type emails, move information from one screen to another, perform the click of a mouse, and much more.

With companies pushing their organizations to a higher level of data quality, RPA can be seen as a solution to remove error-prone tasks from the workforce and keep employees focused on serving their customers, or on more creative and productive work. Over the past few years, RPA has made a huge splash in the technology sector and saved companies both time and money.

When to use rpa?  

We all perform manual, rule-based tasks every day. Some of them add up to only minutes of our week, while others may demand many hours. The ideal use case for RPA is a time-consuming, manual, rules-based process with few edge cases that is performed frequently in one or more systems. The less likely the current state process is to change, the more lasting value automation can provide. Even if the process changes, RPA can still make sense, as long as the ramp-up time to implement RPA is significantly less than the time spent to perform the work manually. After all, a computer defined by logic makes fewer mistakes than a human.

Think of RPA as a short-term solution for system integration. Longer-term, the organization should look to integrate platforms within the internal IT environment to ensure flexibility and more seamless integration. RPA can also serve as a longer-term solution for moving highly valued information across applications where human involvement raises compliance or security concerns.

Organizations looking to use RPA to automate a process should ensure the task satisfies the following criteria:

1. Rule-based: Use pre-defined logic for decision making. If workers find themselves using the keywords “if,” “then,” or “when” while describing their tasks, then the process might be a good candidate for RPA.

2. Repeatable: Ensure the process is both manual and repeatable, with consistency and few exceptions every time the process is followed. Further, confirm that an automated solution saves enough time to warrant the investment to automate the process.

3. Standards-based: Use electronic or easily readable input for the technology associated with RPA, such as optical character recognition (OCR). Typically, this is either a spreadsheet
or a system with structurally defined locations where we know the source and target destinations for the data.

4. Stable: Ensure no drastic changes to the process are expected in the short term.

implementation

The typical implementation process for an RPA project starts with an analysis phase to understand the business process, determine whether the process is a good candidate for RPA, and define the business rules for the process. In the analysis phase, make sure to ask the business the following questions:

The solution design phase turns the “as-is” business processes into the “to-be” business rules laid out for an RPA developer to automate the business process. The RPA developer turns the business rules into an RPA script that completes the defined tasks. When the script is run, developers affectionately refer to the execution as a “bot” (short for robot). The bot tasks are tested by the developer to ensure the bot is performing as expected. Afterwards, user acceptance testing (UAT) is performed in conjunction with the business unit that was previously performing the task to validate the results of the bot. When the RPA bot goes live, the process is moved from test to production, monitored, measured, and lessons learned are documented. Whenever the internal IT environment changes, the bot is adjusted and improved. 

Industry leaders in developing RPA software offer implementation in a few different flavors; code-heavy and meant for developers, as well as a more intuitive user interface that is geared towards non-technical people:

Visual constructs: Process flows are assembled using drag-and-drop modules

Recording: Users’ actions can be recorded and then translated to programmatic actions in sequence and modifiable code (like creating a macro in Excel)

Coding: Actions can be created and modified using the tool’s coding language

Most experienced RPA developers use all three of these methods to build automated processes, often within the same initiative.

STATE OF THE INDUSTRY

Advanced Analytics & Machine Learning: A few enhancements to traditional RPA have surfaced over the past few years, including intelligent process automation, which blends RPA with artificial intelligence such as machine learning, speech, and text analytics. An example of this technology includes website chatbots interacting with customers and then triggering an RPA robot to take the input from the customer and route them to frequently asked questions on a website, or a human if the given question has not been asked before. In essence, the artificial intelligence creates a set of criteria to track performance. Over time, and after the bot takes correct and incorrect action on more questions, the bot will “learn” to route customers to the correct answer rather than a person.

A more complex example is using RPA to automate invoice processing for accounts payable departments. Invoices can come in many different formats, sizes, and mediums. RPA providers release solutions for changes in invoices by using machine learning to train the bots in capturing the correct information from various forms.

Vertical Offerings: Other providers supply vertical offerings to implement multiple pre-packaged bots in specific integration points between systems in the business’s IT infrastructure. These solutions reduce the implementation time due to a prior understanding of the integrations between commonly used internal platforms.

Organizational Change Management (OCM): While there are many benefits to RPA, the technology has a stigma for the potential to eliminate jobs. Depending on the implementation methods, this presents the employer with the challenge of managing talent, retraining, and refocusing work on more meaningful and rewarding initiatives. RPA developers need to know the ins and outs of the business process they are automating, and these details should come from the worker who is actively performing the task. Workers whose job processes are being automated tend to cooperate better with RPA efforts when OCM teams frame automation as a positive enabler to concentrate on other predefined work. Employees will resist aiding automation efforts when their jobs are threatened, but this risk can be minimized when adequate effort is spent to restructure their job role or train them with new and exciting skills.

TRADEOFFS IN AUTOMATION VS. MANUAL WORK

For most organizations, RPA implementation can be a middle ground between existing manual processes and a custom-built integration.

Time to Production: RPA is relatively quick to implement, requiring minimal change to legacy systems and integrating quickly and easily with existing systems and processes. Many large companies have long-standing, outdated legacy systems that would take months if not years to revamp and build a custom solution. RPA can come in as a quick and valuable interim solution at a low cost until a custom solution is deployed.

Efficiency: RPA can remove lag time between user groups since the bots work 24/7 and perform keystrokes faster than a manual process. However, speed is limited by the presentation layer of the software with which the bot is interacting. Full-stack modernized solutions still outperform bots when it comes to speed and efficiency.

Technical Investment: Because RPA can be visually constructed, simple solutions require much less technical expertise than a full custom build. However, fundamental knowledge of coding concepts is required for error handling and robust solutions.

Adaptability: RPA is best used for well-defined, repetitive tasks that are not likely to change. RPA’s limited ability to adjust to front-end format changes is its primary drawback. Changes to the front-end of a web application or other technology platform where RPA interacts may cause the bot to break, requiring rework or complete rebuilds. With proper positioning of RPA, long-term roadmaps, maintenance, and governance plans, this risk can be managed responsibly. The increasing trend of using artificial intelligence in conjunction with RPA should increase the adaptability of RPA in the long term, but overall RPA is inflexible.

The image below shows how RPA (the blue robot) compares to manual processes (human silhouette) as opposed to a full-stack implementation (the cylinders).

RPA RESPONSIBLY

Given the tradeoffs mentioned above, RPA can be a great tool for one-off tasks when the bot build time is either far less than the time required to manually perform the task or around the same time with a much lower error rate. For instance, transferring metadata about an organization’s reporting inventory from a spreadsheet to a documentation template in a website is a perfect use case for RPA. Metadata about thousands of reports can be cataloged in Confluence in hours rather than weeks of manually keying in the values from the spreadsheet and inevitably incurring many errors. 

Another excellent use case for RPA is automating a legacy system to expand the life of that system. By removing the most manual or error-prone aspects of the system, organizations can live with the system for a longer period of time. However, by integrating RPA with legacy systems, the sunk cost increases, maintenance costs increase, and many dependencies are created. These concerns manifest as technical debt that allows for less flexibility in the future for replatforming. After RPA is coupled with legacy systems and portions of the technology environment get replaced, any of the processes that the bot interacts with will need to be revamped or even reconstructed. On the bright side, not all technical debt is bad technical debt if that debt is structured. Utilizing RPA accomplishes a quick win by automating a business process while buying some time and bandwidth for the organization to focus on refactoring the process into an Application Programming Interface (API) at a normal pace.

RPA tends to be a poor choice for highly regulatory environments requiring high uptimes, strict service level agreements, and security patches, all contributing to many unplanned changes. Similarly, architectures that include third-party platforms tend to have a high velocity of changes to both visual and back-end elements, contributing to a scope of change risk. For example, an unhealthy implementation of RPA would be in an architecture that includes third-party platforms processing credit card payments. These transactions are business-critical, requiring an uptime that is not guaranteed by RPA. Similarly, regulations, laws, and security precautions on the information contained within these transactions are forever changing, contributing to frequent architecture updates.

For these reasons, adequate planning is required when considering production-level implementations of RPA. Calculated assessments on frequency of planned and unplanned changes with source or destination platforms and their consequences are critical to risk management. Simple strategies, such as persisting fields leveraged by robots in a hidden state until new fields are ready to be programmed into the bot, can make a world of difference in maintaining an RPA solution and leading a successful replatform effort to a healthier architecture.

SO WHAT? 

RPA is typically low-cost and easy to implement, requiring only small teams and standard open-source software without deep systems integrations. With RPA, businesses can automate many mundane, rules-based, repetitive tasks that tend to be error-prone. By removing the low-value, high effort processes from knowledge workers’ daily tasks, their time can be refocused on performing more value-add work. Focusing the workforce in other areas allows the business to reduce costs, procure deeper value out of their workers, and increase efficiency. RPA solutions are far less error prone than humans, thus raising the standards of data accuracy and data quality to build successful machine learning models and improve trust. Ultimately, this ensures that organizations gain high-quality, accurate, and actionable insights to inform better decision-making.