5W – Robotic Process Automation (RPA)

Thank you for reading! Please see “Why 5W?”  for context, methodology and disclaimers.

RPA Overview

Robotic process automation (RPA) is a modern-day (read: fancy) name for ‘macro‘, a use-case-specific execution of a series of steps to automate a task in a software program. Where macros are typically associated with a single application, RPA extends this paradigm across multiple applications, from on the desktop to the web and through service layers in commercial applications.

The end results: less switching between applications by users, fewer errors when moving data between applications, faster execution time, and more. Primary beneficiaries of RPA are end users, system owners and IT, who can manage RPA implementations centrally, standardizing and supporting overall integration efforts.

For context, consider comparing RPA to Macros. Macros are tiny, use-case-specific, user-recordable programs that enable end users to automate repeated tasks like formatting, copying formulas, moving data and so on. Users record keystrokes and trigger the action via a user-defined hotkey (Control-1, for example) to make changes to the target document. Macros were typically associated with a single application (i.e., Word, Excel, and more) .. but a few years back, Microsoft introduced Visual Basic for Applications (VBA), replacing Word Macros (Word Basic) and Excel Macros to execute actions across Office Applications and further extend the model. Where the original macros were application-specific (i.e., only worked and enacted document changes from their host application), VBA enabled users to launch and control other Office applications remotely. Examples include updating a table in a Word document from Excel, inserting graphics into a Word document from PowerPoint and more.

RPA extends this model even further, executing commands across multiple applications from the desktop. These include locally-installed (via API or keystroke), Browser- / Web-based (via web forms or Web Service layers) and through richly-defined service layers in commercial online applications. RPA automates computer tasks that are structured, routine and repetitive, placing the user in control of executing commands across multiple applications to get work done.

RPA is not a replacement for users, but a tool to execute small tasks across applications. This is especially helpful where tasks are repetitive, the number of users performing these tasks is significant and where the risks (and potential costs) of errors are significant. Using RPA saves users’ time and frees them to do other more important (and interesting) work for the company.

RPA automation (automation routines typically referred to as ‘bots’) can be small or large, individually- or centrally managed and perform unattended or attended (user intervention required at certain points) tasks for users and the company. An analysis of automatable tasks a company should consider should be performed through Discovery, and later through POC and thorough project planning. Best practice: write smaller bots to perform oft-used tasks that can be called by more complex routines.

Last, RPA is a platform implementation, meaning that focusing on customer use cases is of paramount importance. RPA must satisfy the use cases the customer needs the most, cost-effectively and with robust, but light-touch management.

RPA Business Benefits 

Organizations continually add and update LOB systems through necessity, digital transformation, upgrades, acquisition and other changes. These may be as simple as transitioning a paper process into a new application, or as complex as integrating a new subsidiary (and all the underlying systems within). This creates complexity within a company environment as existing LOB use cases are abruptly managed by different, or worse, LOB applications performing the same services to the business.

Adding and changing systems quickly puts the end user at the center, occurring at a rate where the user’s day-to-day activities become chaotic. Combine changes to systems with organizational restructure within a company, and you’ll quickly realize users are surrounded by multiple systems, entering, copying and pasting data between them in real-time. Some activities may include transformation calculations (currency and time zone, for example), applying business rules (expense account or purchasing limits), etc., increasing complexity and accuracy risk. End users face:

  • Many process touchpoints
  • Massive amounts of data
  • Disconnected Systems
  • Disparate Audiences
  • Manual Entry / Transformation
  • Risk of Errors

Most companies solve this by putting additional users into the mix, which increases costs, further increasing complexity and the risk of errors. It also calls into question the company’s training capabilities, where companies must consider:

  • The time it takes to train new employees across multiple applications.
  • Employee turnover in these departments.
  • Training effectiveness / veracity.
  • QA and audits for the affected systems.
  • Feedback loop to resolve errors and improve training.

Given organizations may not be able to integrate / consolidate / replace these systems in a timely manner through integration, consolidation or absorption. In an ideal world, cross-functional LOB applications would have:

  • A single interface with input consistency
  • Automatic business rules enforcement
  • Automation Calculations / Transformations
  • Centralized Management / Data Access
  • Alerting and routing for outliers and errors.

From a user perspective, most LOB systems appear isolated from each other, even though business use cases run in parallel, or may even overlap. Consider these two LOB applications:

  • Timekeeping software that records employee punch-in / punch-out for payroll.
  • Program management software that captures employee hours for project billing.

Both systems capture employee hours but for different audiences and purposes. If the timekeeping software had the capability to capture a project code, employees would need only access to one system to support both time tracking use cases. In most organizations, this kind of integration is simply not in place.

RPA Capabilities

The number of tasks users execute every day within an organization is staggering. This is especially true for companies who have multiple non-integrated systems with similar types of data (requiring manual data transfer, like cut and paste), legacy (even mainframe) source systems alongside operational systems, similar systems acquired through an acquisition, and so on. While automation cannot replace everything every user does, there exists a large number of tasks with aspects of repetition that can benefit from a level of automation. This is especially true if users are transferring data (with or without analyses) between systems that are not properly integrated. This is even more value if a large number of users are performing the same kinds of repetitive tasks across systems. More users, more systems, the more the chance of errors.

While every company has long-term IT Transformation initiatives that include integrating ‘all’ systems, not all systems should be integrated .. IT realizes this. Some systems have limited life spans (to be replaced or upgraded), others have limited operational audiences (so not worth the effort) or IT doesn’t have the bandwidth or the skill set, etc. Because of these factors, the systems are kept isolated and data transfer between them is left to the user. These companies are target-rich environments for an RPA implementation as an interim step toward eventual Digital Transformation.

RPA enables this, by supporting ‘lazy integration’, where users interact to perform pieces of data transfer activities between systems, in systems that lack full integration capabilities, have a short life, or other business factors.

To support end-customer use cases, capabilities to consider when evaluating an RPA operational platform include:

  • Desktop Analytics Framework: Allows for analysis of user interaction with applications to identify high-value application targets for RPA.
  • Centralized Management Console: IT monitors all RPA operations and assigns designates to manage individual and groups of users.
  • Role-Based Access Control (RBAC): IT sets policies that control user access, and allowed actions, preferably through (and integrating with) Directory Services and existing Group Policy.
  • System and Application API Connectivity: API connectivity should be used for any / all applications that support this access, preferably through a connector framework that includes commercial applications.
  • Monitoring / Alerting Framework: Real-time notification, governed by policy, delivered to devices.
  • Reporting / Analytics Framework: Dashboards containing Metrics and KPI assessment in an AAG display format.

This is a short, high-level list .. Industry-specific use cases will likely drive further capabilities.

From a functional perspective, the RPA platform must support multiple end-user operations. Please recognize the RPA approach to automation is from the User perspective (i.e., replacing connecting to, interacting with and keying into multiple systems). A short list of capabilities, presented from activities end users perform across multiple applications:

  • Launch Applications: Locally-installed, browser-based or through remote automation.
  • Secure Credential Storage: Necessary for multiple system and application logins.
  • Configuration / Scripting / Limited Coding Requirement: This is implied with RPA .. a library of configurable connectors is expected, providing a standardized means to access packaged applications without writing scripts or code. With that said, the capability to extend an operation through simple scripting (and limited coding) is a key differentiator for an RPA platform.
  • Log in to Applications: Local and browser-based (this includes finding the ‘user’ and ‘password’ fields as well as the ‘submit’ button).
  • Copy and Paste Data: While copy-and-paste are implied, the ability to navigate to the proper fields in the source and target applications is critical to ensure data arrives in the proper target fields.
  • Move files and folders: This includes local, remote and web-based folders; the latter will require configurable credentials. Note that once files reach their intended destination, there may also be requirements to allow access to other users / groups.
  • Extract and Process Data: This includes structured and semi-structured data, as well as from documents, PDFs, emails and forms. Recognize that many of the currently-manual interactions involve users looking at multiple screens / windows (source and target), performing standard (but executed ad-hoc) calculations entering data into the target systems.
  • Read and Write to Databases: If local, may require additional desktop implementation (ODBC, Native API, and so on), if remote is likely handled through a Web Services or Data Services layer.
  • Open Emails and Attachments: As above (extract and process), users will open emails and attachments, view and act upon the data therein.
  • Scrape data from Web Pages: As above (extract and process), open web pages, view and act upon displayed data.
  • Perform Transformations and Calculations: An RPA implementation needs the capability to acquire, calculate and transform data from one or more system sources and insert the results into the target system.
  • Extend (and Capture) ‘Tribal Knowledge’: Users take these kinds of operations for granted, just ‘knowing’ when a particular policy should be enforced. Unhappily, these kinds of operations don’t automate well, unless this knowledge can be captured as rules to improve the RPA implementation.

It is safe to presume that a robust RPA will manage the bulk of the tasks as described above. With that said, not all organizations need all the capabilities .. this can be teased out during Discovery with an end customer to amplify capabilities and applicability within their environment.

RPA Versus BPM

RPA versus BPM is a common question that will generate objections when approaching end customers. I go into detail on this on another W5 post.

Note that many organizations already suffer from system sprawl (multiple systems whose capabilities and audiences overlap) .. while most have not corrected this condition through integration or BPM (both of which require significant oversight and effort), some will have offerings in the works.

Does RPA replace BPM? Can it? It depends (it always does).

I mention above that RPA is a means to achieve ‘lazy integration’. Given that companies are likely managing multiple systems with overlapping capabilities and audiences (this means a lot of user intervention and suggests RPA opportunities), follows a few scenarios of which to be aware:

  • Multiple ERP, Payroll, accounting systems, etc., with which users must interact through individual interfaces.
  • Multiple operational facilities (call centers / manufacturing / data centers .. especially if these locations were added during acquisitions), requiring manual data acquisition / consolidation.
  • Combinations of SaaS and on-premises LOB applications performing similar functions, or where combining data provides improved context for operations and reporting.

RPA can provide a means for companies to provide many of the benefits of BPM avoiding a larger system migration. This is especially valuable to companies whose systems have limited life spans or limited audiences.

RPA Use Cases

A wide variety of companies can use RPA effectively to reduce errors, save time and release their staff for more important work. While any industry could benefit from an RPA solution, some sample use cases include:

Multi-System Integration

A robust RPA platform will enable IT and end users to connect locally-installed, SaaS-based and cloud LOB systems. An inventory of systems and use cases is a critical part an engagement conversation, amplifying the applicability of an RPA implementation within the end-customer environment. Key bits to capture include identifying these systems, the complexity of manual integration and the number of users who go through these manual operations. Capturing the amount of time users spend in these operations would be very helpful, but in many cases, initial contacts may only have ballpark estimates. Capturing more detail will help identify and illustrate pain points, capturing opportunities to drive the conversation forward.

Workflow Automation

A very common use case: document workflow, including expense reports, purchase orders, accounts payable and so on. Many companies have LOB applications that support internal approval workflows, but as soon as documents transition from one system to another (i.e., an approved expense report to writing a check or hours collected in a timekeeping application to a payroll system), a user typically sends an email notification to another advising there’s an action on their part. It’s fairly easy to point out the inability to track workflows once they leave one application .. noting the target application may not have any knowledge of an impending transaction as they lack a formal integration methodology.

Look-up / Transformation / Validation Functions

Three very common end-user activities:

  • Look-up: The user switches between systems to obtain a value from a source system (or systems) and cuts / pastes the result in the target system(s).
  • Transformation: The user performs calculations between source(s) and target(s) when pasting the data.
  • Validation: The user enforces business rules when obtaining / entering the data, which may result in outliers (data that requires further validation, say an expense report that’s over their approval limit and must be sent elsewhere).

You may surmise that these (and other, similar) user activities are prone to error, through activity (missing transactions), calculation and / or follow-on actions.

These use cases are the easiest to tease out during Discovery, recognizing the workflows and the present systems the customer is using are key data points when amplifying applicability within a prospect environment.

RPA Providers

The biggest competitor to RPA is home-built business processes .. manual or with some level of automation, perhaps shared macros or via SOP documents. These kinds of solutions rely heavily on Tribal Knowledge, introducing discrepancies between end users and making it difficult and time-consuming to train. Last, home-built processes are higher-risk than any delivered in a centralized automation platform. In-Market companies include:

There are a number of consolidations / symbiotic partnerships in process at any given time, so this list is somewhat fluid.

ED: As Article Publish dates are frozen in time, it is quite possible that reviewed vendors and their capabilities may have advanced beyond those presented herein. Please accept my apologies for my shortcomings. A note to vendors: please reach out to advise your current offering capabilities and I will update accordingly.

RPA Audiences

While IT will need to be consulted and engaged for coordination, system access and eventual implementation, conversations will likely start with business audiences within an organization. In short, it is the business that is most keen to streamline processes and reduce errors while awaiting a Digital Transformation effort. Consider some sample audiences and use cases that result in business efficiencies:

  • HR: onboarding / offboarding processes, review processes, access management request processes, integration across multiple HR systems (in anticipation of an HRIS solution).
  • Finance: Real-time, interactive access between disparate financial and LOB systems.
  • Customer Success / Support: Real-time, interactive access between multiple CRMs, Support, OM, WM, and other customer support systems.
  • Operations: Real-time integration across disparate time tracking and operational systems.

It is important to note business audiences are the most likely to recognize (and speak about) usability shortcomings of current systems and processes. Thus, they are better equipped to make the business use case for RPA efforts. These audiences are performing repetitive keystrokes / operations, which enables them to significantly enhance RPA-enabled functionality and usability.

I don’t want to leave IT out .. besides their eventual operational role, IT can benefit from a robust RPA implementation with:

  • Top-level management across disparate system processes (coordinating backups and off-site backup storage transfer operations across vendor implementations).
  • Initiating Automated Access management process across systems responding to requests from HR and other business entities.
  • Data management: bots can automate numerous data-related activities such as entry, migration, extraction and validation.
  • Network management: bots can monitor server and system connections and capture performance metrics. Bots can detect threats of unauthorized access and alert admins, including executing security controls to deny access in real-time.
  • IT helpdesk management: bots can apply rule-based technical support actions to incoming requests, providing self-help assistance prior to engaging with IT support.
  • Security management: bots can automate monitoring security logs for suspicious activity, detecting system vulnerabilities and threats of unauthorized access.

In fact, RPA can help guide IT in system identification and prioritization when considering a Digital Transformation effort. Further, RPA can be both a stopgap and enable rapid prototyping for a pending DT effort, while enabling the business to work more efficiently.


RPA helps organizations manage the path to an eventual digital transformation, whether in their roadmap or manifesting through external business activities. RPA helps to address accelerated integration requirements facing organizations and their end users through automation, thus creating efficiencies and reducing the possibility of errors surfacing performing redundant operations. RPA frees up human resources to focus on more complex and creative tasks, leading to increased productivity and efficiency. The broader an RPA implementation, the more value an organization will realize from the investment.

While RPA offers numerous benefits, it is important to remember that it is not a one-size-fits-all solution. Each organization must carefully evaluate unique needs and requirements before implementing RPA to ensure that it is the right choice for them. It is important to have a comprehensive plan for implementation and management to ensure the success of RPA adoption.

%d bloggers like this: