This article was written when I was involved in the RPA industry as an IT manager. However, driving efficiency with RPA is something that I no longer undertake on a full-time basis. The full context for this message is detailed on the following page.

How to establish an enterprise RPA strategy starts by sharing two popular IT governance frameworks. The intro quoted below is a great summary, but you can feel free to skip it if you're already familiar.

"Two popular frameworks used in information technology are Controlling Objectives for Information and Related Technology (COBIT) as well as Information Technology Infrastructure Library (ITIL).

COBIT is focused on controlling enterprise IT and establishing a roadmap for where it'll go. In other words, COBIT focuses on reducing risks and establishing a strategy. ITIL is focused on continuous improvement and efficient operations; it focuses on best practices that improve outcomes for [a] business (Leinov, 2018).

You may think of ITIL as tactical and of COBIT as strategic. It’s possible your company is already using some of these libraries within specific departments (such as ITIL within IT support and COBIT within finance). Which framework, or combination of them, is used is likely already decided upon by our company.

The reality is that any framework is better than the ‘automate first, think about it later’ mentality. Simply 'winging it' will result in an RPA program running out of steam, automating the wrong processes, or being tactical at the expense of not seeing the bigger picture."

A popular framework not covered in the previous article is Capability Maturity Model Integration (aka CMMI). The Carnegie Mellon Software Engineering Institute, which was heavily involved in its creation, states the CMMI’s intent as ‘[helping] integrate traditionally separate organizational functions, set process improvement goals and priorities, provide guidance for quality processes, and provide a point of reference for appraising current processes.”’

CMMI, COBIT, and ITIL all offer means to score the capability of an organization’s maturity. What makes COBIT unique is that it makes room for the inclusion of other frameworks to meet established objectives. Whether it’s The Open Group Architecture Framework (TOGAF), CMMI, ITL, or Six Sigma — COBIT can incorporate all of them depending on business requirements.

What is RPA governance?

From a COBIT 5 perspective, governance is important to make sure that IT delivery and maintenance processes are in line with an organization’s objectives, that external requirements (such as regulations) are met, that the organization continuously improves, and that risk is well managed.

COBIT is encouraged to be customized, so you can think of it as a ‘plug and play’ framework. Its 5 principles are as follows (Soujanya, 2019):

👩‍💼

Principle 1: Meeting stakeholder needs

👨🏽‍💼

Principle 2: Covering the enterprise end to end

🏛️

Principle 3: Applying a single integrated framework

☯️

Principle 4: Enabling a holistic approach

🖋️

Principle 5: Separating governance from management

The principles themselves are built on seven ‘enablers’ as well, which consist of:

1. Principles, Policies, and Frameworks

2. Processes

3. Organizational Structures

4. Culture, Ethics, and Behavior

5. Information

6. Services, Infrastructure, Applications

7. People, Skills, and Competencies

The components of COBIT span the framework itself, which categorizes IT governance objectives by IT domains, process descriptions (what's involved for each process from a generic standpoint), control objectives (how the processes ought to be controlled), management guidelines (for aligning on objectives, measuring performance, relating processes, etc.), and the maturity model that helps to address gaps between the current and desired state.

The activities that are recommended for implementing RPA governance are covered in the remainder of this article.

Establish RPA governance structures

The first order of affairs is creating a governance structure to legitimize the prioritization of governance objectives and processes. In RPA, this governance structure may already exist in the form of a Software Development steering committee, an innovation council, or another body.

If the group doesn't already exist then leadership, and stakeholders that'd be involved in the oversight of automation, should determine how to best establish the group.

Automation steering committees typically report to the CIO in organizations with under two thousand employees. No matter how the steering committee are set up, there needs to be a separation between the governance group and the management group (according to COBIT best practices).

Another governance structure that's associated with RPA is a Center of Excellence, which focuses on the management as well as the proliferation of automation best practices. We discussed the RPA Center of Excellence and where it belongs in more detail in a previous article.

Define RPA governance objectives

There are a total of 40 governance objectives in COBIT broken out by 5 processes. Defining RPA governance objectives is undertaken by your RPA steering committee or leadership. The objectives picked should align to the company’s objectives and key results (OKRs) or goals (depending on what methodology is used).

The objectives that your company prioritizes also depend on the maturity of your RPA program. Objectives prioritized will establish expectations for what processes will be managed, controlled, and optimized, as well as the order that everything should follow.

Assess RPA risks and apply COBIT recommendations

Governance risk assessments are undertaken to identify what business risk stems from IT risk. This includes the use, ownership, operation, involvement, influence, and adoption of specific IT (Scherer, 2020).

In RPA, a risk could be building an automation which handles a growing amount of volume that can no longer be supported by manual intervention. When such automation fails, due to a change in the underlying logic or required applications, the work will get backlogged as there won’t be enough people to process items manually. If this work is constrained by an SLA, there could be monetary penalties or reputational damage at stake if the SLA is breached.

In other industries, such as in the healthcare or finance industry, companies are under strict regulation. If a vendor is used for developing bots for example, a separation has to be established between the vendor’s development and the operation of bots to make sure that no confidentiality or privacy laws are broken.

A risk assessment should be conducted, based on your company’s maturity, to determine what risks are present. Those risks should be further assessed for their impact and severity, as well as how they ought to be managed.

ISACA, the certification body behind COBIT, recommends the following regarding managing IT risk (COBIT 5 for Risk — A Powerful Tool for Risk Management, 2017):

• ‘Encourage executive management to demonstrate support for the risk management program.

• Identify the key organizational structures/roles that are required to build and sustain effective and efficient risk governance and risk management in the organization. COBIT 5 for Risk helps organizations to identify such roles by providing a specific description/definition of each role and structure. This helps organizations to establish their lines of defense for risk management.

• Risk management must be embedded in the normal process and form part of the daily management practice.

• Establish a risk-aware culture among all employees at all levels.

• Identify and develop metrics to serve as key risk indicators (KRIs) to describe and track indicators of risk.’

Develop RPA governance policies and procedures

To formalize governance, policies should be written which clearly define the governance group's stance on how the automation program must be led. From a management perspective, procedures need to be documented to outline how implementation, operation, and maintenance is controlled for compliant automation delivery.

If you have the right people in your governance body, as well as the right resources in your automation center of excellence, and the objectives of the RPA program at your company have been prioritized, the hard work is done.

Regarding documenting policies and procedures, it’s best to shoot for the sky but aim for the stars, knowing that the first, second, or third iterations probably won’t be perfect. What counts is getting something down and revising it when it's no longer the best representation of how your company operates.

Monitor RPA governance and continuously improve

As the number of bots continues to grow, and so does the associated risk of bot failure, it’s important that your company is diligent about tracking performance and continuously improving.

1. As the RPA program becomes a well-oiled machine, leadership should continue to monitor how governance is performing.

2. In the manner that your company established governance, is it hindering or enabling the automation program?

3. Are there gaps in how it is operating?

4. Does the RPA governance body feel that management is adequately addressing gaps in the objectives that have been established?

5. Are maintenance tasks being undertaken proactively or is there a high rate of bot downtime and enhancement development that is harming stakeholder satisfaction?

Hopefully this article has been informative and given you the pointers needed to knock RPA governance out of the park!

Footnote:

The term 'Robotic Process Automation' is used due to its popularity in the industry. Process automation is a clearer term that'll ideally replace 'RPA.'

References:

CMMI Institute - Home. (2019, June 21). https://cmmiinstitute.com

COBIT 5 for Risk—A Powerful Tool for Risk Management. (2017, July 5). ISACA. https://www.isaca.org/resources/news-and-trends/industry-news/2017/cobit-5-for-riska-powerful-tool-for-risk-management

Scherer, T. (2020, March 17). How is COBIT Related to Risk Management? https://reciprocity.com/how-is-cobit-related-to-risk-management/

Soujanya. (2019, March 14). What is COBIT Framework - COBIT Principles ? Mindmajix. https://mindmajix.com/cobit-framework

This article was written when I was involved in the RPA industry as an IT manager. However, driving efficiency with RPA is something that I no longer undertake on a full-time basis. The full context for this message is detailed on the following page.

Many consultants market themselves as prestigious and valuable players for their target industries, but the real challenge is knowing which firms can deliver on their promise (within scope, on time, and on budget).

This challenge of finding a great consultancy was well covered by an industry expert named Karen Phelan in the book “I’m Sorry I Broke Your Company - When Management Consultants Are the Problem, Not the Solution."

Phelan worked at Deloitte in the 1980s, as well as Gemini Consulting in the 1990’s, and various other big name firms. This article will refer to her work, as well as other writings, to highlight the red flags to look out for when searching for an automation consulting company.

Do your consultants bill transparently?

McKinsey, a leading consulting firm, assessed over 100 company sites spanning three continents, and various industries, and found that companies were paying 30-50% more than necessary for contracted services (Seven Ways to Stop Wasting Money in Contractor Management, 2017).

Given the fact that contractors are bought in for a specific project, and that consultants have an ongoing relationship with their clients which span various projects, it's fair to reason that companies can overpay just about the same with a consulting firm.

To get a better understanding of whether your own vendors (consultants or contractors) are worth the cost, you might want to dive deeper into their invoices.

Do they openly share the amount of hours worked and what the time was spent on? Or are they simply charging a total rate for specific line items, with little room to understand at a more granular level what the investment went towards?

McKinsey’s findings indicated the following activities helped improve cost with business partners:

📑

1. Job scoping

🔏

2. Understanding the details of work completed

👓

3. Receiving transparent invoices

💰

4. Cross-checking costs against original agreements

McKinsey goes on to establish that companies ought to audit even small spend (since it usually goes unnoticed by those approving it, but can add up over time). They also recommend that delivery-date deviations are recorded (compared to what was agreed upon).

Do your consultants specialize in everything?

If your consultants are supposed to deliver RPA development, but they fancy themselves experts in strategy, governance, or other matters, it should serve as a red flag (Bock, 2020).

It's not uncommon for software development contractors who have been beaten in bids by consultants to band up and form their own consulting agencies. Such practices blur the lines between contracting (short-term delivery) and consulting (strategizing and partnering for the long-term).

On the smaller end of consulting firms, you want to watch out for whether the company is simply a trusted partner in managed services (providing services for already implemented systems) or if they are actually established as a consulting firm. If you end up with a contractor overreaching into strategy and digital transformation, the negative ramifications may include decreased employee morale, missed deadlines, and other failures. For larger firms, you'll want to watch out for paying partner prices and getting a boilerplate solution that isn't tailored to your industry. Although the scope of what a larger firm delivers may be met on time and within budget, a boilerplate solution may not necessarily move the needle for your business's bottom line.

For more best practices to factor into your cost management approach you may want to review this McKinsey article.

Are your consultants not graded by their ability to cut-costs even though its their biggest selling point?

Consultants often establish relationships with their clients which sell RPA as a cost-cutting endeavor, but the reality is that goals presented in sales pitches are as likely to come to fruition as they are unlikely not to.

Before deciding on consultants' contract renewal, it’s important to consider how much was saved versus what was marketed. Many clients will initiate a proof of concept period with a vendor to confirm the quality of their work as well as the cost. It's important to note that while a proof of concept can validate the vendors' capabilities in implementation, it doesn't validate the costs that will be incurred to maintain and operate automation in the long-term.

👓

If cost-reduction goals are made, they should always be validated against actual performance. How much did the consultants' work impact the actual savings against the expected amount?

Do your consultants seem to glaze over the details?

As Bech summarized in 2019, no one can predict the future, not even consultants. Phelan’s book highlights the tendency of consultants to fly in, have a few workshops, and sell the ‘future vision’ to a handful of leaders.

‘And yes, consultants may travel all the time but as an unknown former worker of [a big consulting firm] tells “at some point I was annoyed. That was when I didn’t have rest for two months. I landed somewhere, worked the whole day and left again. Sometimes I even forgot where I was. There was no rest, only the current Project.” (Ariane Breyer, 2012).’ (Ena-Mar GmbH, 2018)

If your consultants engage in 'relationship building' where they merely fly in and shake hands for deal signing or project closing, then you may want to thread carefully. Working with partners that move at this pace doesn't mean that details are surely to get missed, but it can mean not being able to get the necessary value if your company isn't able to keep up during the allotted time.

The problem with consultants is that what should be their primary focus, helping their clients businesses succeed, often gets overshadowed by their priority to make money.

Do your consultants treat your business as a machine to be fixed?

Consultants that treat your business as a machine will fail to see the value that your people bring to the table.

💯

If your consultants use frameworks, strategies, and processes to bring out the best in human creativity, strategizing, and innovating, then they might be on the right track.

👃🏻

If consultants bring in ‘proprietary frameworks' and other malarkey, they are probably throwing out common sense. This common sense is very important and should not be overlooked - it includes ‘tapping into employees own energy, wisdom, and experience’ as Karen Phelan states.

Are your consultants just using your company for clout?

If the company you’re working with has never had a client in your industry, or you're their biggest client (in the industry or in general), it’s possible that they may benefit more from your company's clout than you will from using their services. You can notice that this might be happening if a firm provides a much lower rate than the rest of the competition (since they may be willing to eat into their profit margin for a chance of working with your company).

It sounds silly, but I've seen it all. In one instances, a mid-level consultanting agency used the brand name recognition of their client to win new deals (even though the endorsement was never formally made).

The threat of hiring a bad consulting firm is that they’ll take everything they learn in your business, use the addeed reputation of working with you to charge more, and use the newly gained knowledge to solve your top competitors' problems.

Red Flags

Archbow.com has additional 14 additional red flags you might want to consider when determining if your consultants are ‘worth their salt.’ Learn more by clicking the button below:

How's it shake out?

Communication is poor or begins to supplement internal communication

If you are relying on consultants to communicate between teams, as Phelan remarks in her book, “that is an expensive way to communicate.” Given the fact that consultants charge a high rate to drive costs down, you probably want to put an abrupt end to any newly minted bottleneck that involves third parties as the 'glue' between internal teams.

Do your consultants throw around Intelligent Automation, Hyper Automation, and AI Like hotcakes?

RPA delivery consultants are great at taking repeatable tasks that occur in high volumes and implementing automation that reduces costs. However, you should start to question their proposed value when they begin to speak about artificial intelligence, intelligent automation, or ‘hyper automation' with little to back it up academically. There's a big difference between having an RPA partner that can deliver IT solutions, and having a digital transformation partner that can deliver the strategy and business acumen necessary to truly take advantage of cutting edge technology in a way that is compliant, scalable, and profitable.

RPA may overlap with AI, in the sense of the computer vision that it uses, and its algorithmic way of working. However, RPA developers and solution architects don't have the same skillset that's needed for an AI data scientist to succeed.

🤔

If your consultants aren't leaders in Artificial Intelligence, or Machine Learning, then you may want to think twice before investing with them in anything 'Intelligent Automation' related.

Footnote:

The term 'Robotic Process Automation' is used due to its popularity in the industry. Process automation is a clearer term that'll ideally replace 'RPA.'

References:

Bech, H. P. (2019, November 2). I’m Sorry I Broke Your Company - Another Problem with Management Consulting. https://www.linkedin.com/pulse/20140910061505-170840-i-m-sorry-i-broke-your-company-another-problem-with-management-consulting/

Bock, D. (2020, June 9). 14 warning signs you’ve hired the wrong consultant. https://www.archbow.com/amp/2017/10/09/14-warning-signs-youve-hired-the-wrong-pharma-consultant

Ena-Mar GmbH. (2018, December 8). Consulting Stress Factors: Things that make your consultant job suck (sometimes). Consultiful. https://www.consultiful.com/consulting-stress-factors/

I’m Sorry I Broke Your Company: Is Consulting Always a Good Thing? – Results Map®. (n.d.). https://www.resultsmap.com/blog/im-sorry-i-broke-your-company-is-consulting-always-a-good-thing/

Schools, D. (2018, July 23). Consultants and writers are NOT entrepreneurs. But this will make you great at all three. Medium. https://entrepreneurshandbook.co/consultants-and-writers-you-are-not-entrepreneurs-d5d8020c7688

Seven ways to stop wasting money in contractor management. (2017, December 21). McKinsey & Company. https://www.mckinsey.com/capabilities/operations/our-insights/seven-ways-to-stop-wasting-money-in-contractor-management

This article was written when I was involved in the RPA industry as an IT manager. However, driving efficiency with RPA is something that I no longer undertake on a full-time basis. The full context for this message is detailed on the following page.

Corporate escapism is a phenomenon that takes place in organizations of any size.

Escapism can happen for a variety of reasons. One example is when when leadership experiences the the ‘I-am-almost retired’ syndrome which results in bad short-term decisions that will harm the company in the long-term (Møller Institute, 2017).

Joe DiVanna, who co-authored the previously referenced paper, concludes that some people act as escape artists who deflect decisions to a later date or another group. Other lesser known authors, argue that consulting groups are in fact ‘insurance policies’ for senior management that only take leaders out of the cross-hair if things go wrong, but also serves as a means to ‘justify’ decisions they’ve made but cannot get buy-in at the board level (Have Any of You Snake-oil Salesmen Ever Actually Added Any Value to Your Client’s Organisation?, 2017).

RPA can serve as a shiny new ‘book’ for companies to procure, show off, and feel good about keeping up with the times. In this manner, it can serve as a textbook definition of 'shelfware.'

Automation consultants may also serve as those who help to justify technology licenses and associated project investments. Consultants then do the ‘reading’ of the books up on the shelf to make enterprises look like they are executing on their vision of the future.

When the results go well, leadership is happy to consider themselves as being successful, but when it goes wrong they write the consultants off as bad. In other cases, the technology is written off as not being ready for the market, or the company's industry not being fit for the tech.

Avoiding the RPA shelfware trap

A company that poorly manages its software assets and ends up experiencing application sprawl may be tempted to buy RPA to ‘glue it all together.’

Consider, for example, that some companies use a variety of CRMs (due to siloed departments that emerge because of company growth or acquisitions). Poor enterprise architecture, and a lack of planning, can result in many redundant systems that don’t speak to each other and aren’t properly maintained (Joch, 2020).

Buying additional software, in the form of RPA cannot solve the underlying problems of application sprawl. It's also not going to solve for champions that have left the company (which brought specific software in originally), poor documentation, or a lack of governance.

To avoid RPA shelfware, it should be introduced from an enterprise architecture standpoint and not a ‘business initiative’ standpoint. The business layer operates on the ‘front-end’ of applications and automation operates on the same level.

If enterprise architects decide to pull the plug on systems, bring in new integration solutions, or otherwise change the foundational ‘back-end’ of the enterprise, then RPA benefits will be lost along with the time, money, and reputation that was invested in ‘piece-meal glue.’

I've seen this happen in the middle of projects because the business thought that they didn’t need to involve IT heavily in their consultant-driven implementations. Such a parallel workflow, between the business, consultants, and IT, causes double, or sometimes triple, work efforts and isn't sustainable in the long-term.

The only thing worse than leaving ‘RPA’ duct tape on the shelf is using it for everything…

Applying RPA to all problems is less tempting to companies that dip their 'toe in the water' rather than diving into costly RPA licenses. If companies stopped and noticed that competitors who have succeeded in RPA ‘maxed out’ their opportunities after building anywhere from a dozen to a hundred processes — they'd realize that the growth rate isn't infinite. It’s a classical ‘putting the cart before the horse’ problem.

Avoiding consultancy-based corporate escapism

Another way for the business to avoid RPA shelfware is to refrain from signing contracts for RPA consulting.

Outsourcing enterprise architecture to vendors won’t get you far because you’ll be paying them a premium just to learn about the environment, the gaps, and the solutions that are planned by your company — which often have nothing to do with RPA. Not to mention that your team members already know the ins-and-outs of the software and you're missing out on the benefit of including longstanding employees in the evolution of the enterprise (Fragile to Agile, 2014).

The best way to avoid consultancy-based escapism is to create accountability for strategy and automation projects internally. Companies will get a lot further owning their automation future than outsourcing it. This can be accomplished through:

1. Entrusting an IT team with standing up RPA capabilities after getting buy-in

2. Establishing a process improvement group within the business to partner on opportunities

3. Establishing an RPA governance body

If you want to read more on the dangers of relying on consultants for business strategy, then you may want to refer to "The Trouble with Strategy: The brutal reality of why business strategy doesn't work and what to do about it" by Kim Warren.

Beware of the RPA status quo bias

If executives make decisions based on cost-cutting trends, it won't help the company's bottom line. Nor will bringing in consultants to carry out those decisions. Merely throwing consultants a 'hard-ball' of cash and asking them to turn things around at a company can't be accomplished through IT delivery alone, although they'll sure make it sound like it can.

Before engaging in the tactical aspect of RPA planning and execution, it’s important to understand which way the river is flowing, who the stakeholders are and what their intent is, what the level of interest is, and what the underlying drivers are for exploring automation.

By mapping out the lay of the land it becomes clearer what aspect of the business is bent on innovation, who's skirting responsibility, and who's simply 'throwing pennies in the wishing well.' Having this map in hand can make the difference between getting to see your enterprise objectives come to fruition or getting lost in the mire.

Footnote:

The term 'Robotic Process Automation' is used due to its popularity in the industry. Process automation is a clearer term that'll ideally replace 'RPA.'

References:

Fragile to Agile. (2014, February 18). Philosophy. https://www.fragiletoagile.com.au/about/philosophy/ Have any of you snake-oil salesmen ever actually added any value to your client’s organisation? (2017, August 31).

Reddit. https://www.reddit.com/r/consulting/comments/6x8a34/have_any_of_you_snakeoil_salesmen_ever_actually/

Joch, A. (2020, May 6). 4 Secrets for Eliminating Shelfware. Technology Solutions That Drive Business. https://biztechmagazine.com/article/2016/08/4-secrets-eliminating-shelfware

Møller Institute. (2017, October 4). Steering the ship: corporate escapism vs sustained value. https://www.mollerinstitute.com/insights/steering-the-ship-corporate-escapism-vs-sustained-value/

This article was written when I was involved in the RPA industry as an IT manager. However, driving efficiency with RPA is something that I no longer undertake on a full-time basis. The full context for this message is detailed on the following page.

Traditional User Acceptance Testing (UAT) requires that the end-user, or a representative as close to the user as possible, completes testing to make sure that software meets requirements.

Testing for Robotic Process Automation (RPA) is different since what’s being tested is a robot’s execution of tasks and not the experience of an actual user.

When an attended robot is in question, testing is more approachable because a user can start a bot and see it run to completion on their machine. The user can also pause the robot, provide it with more scenarios, and restart it easier than with an unattended or hybrid bot.

Testing is still possible with bots that are not attended, but it requires additional consideration regarding environments to be used by the automation, data staging, and entry/exit criteria.

This article dives into the various types of RPA errors and ways to identify them before automated processes move to production. Although it is not comprehensive, it should serve as a good diving point for additional research and action on your part.

Simply relying on UAT won’t address errors that may be lurking under the surface due to gaps in requirements, programming, or bot design.

Types of Software Development Errors

The author of The Art of Agile Development categorizes software development defects as follows (James Shore: Alternatives to Acceptance Testing, 2010):

Programmer errors — those that are caused by programmers as they turn requirements into code.

Design errors — errors that are caused by a design gap or emerge because of growing complexity that isn't accounted for in the design.

Requirements errors — those that are caused by improperly documented and approved requirements (at the business level).

Systemic errors — those that are caused by the environment of software implementation and the processes used to deliver working software.

We’ll refer to these categories as we define the way RPA errors can be mitigated or removed.

Minimizing RPA programmer errors

Prevent programmer errors through the completion of unit tests, integration tests, and end-to-end integration tests.

An RPA unit test involves testing something in the smallest ‘unit’ possible, such as opening up Outlook or Excel, or loading the last fifty emails into computer memory for processing. James Shore goes on to further define a unit test as one that doesn’t cross process boundaries and doesn't involve input/output testing.

An example integration test would be confirming that emails from memory are properly saved into Excel (this crosses a process boundary and inputs information into a new application).

An integration test can usually be completed with ‘dummy’ data if it makes the development processes easier and there's no inherent risk in doing so. Some development workflows may be set up to test the smallest of changes in a 'development environment' which are promoted to higher stages (such as user acceptance testing) upon successful test results.

End-to-end testing would involve testing the entire bot, from the beginning to the end of the process. Such testing uses realistic data in a development or UAT environment. With end-to-end testing, feeding the bot ‘test’ values directly is discouraged except for when there's no better alternative.

When focusing on minimizing RPA programmer errors, we want to start by adopting test-driven development (TDD). TDD is a recommendation from James Shore as well, but it's also a leading process in development which improves quality and cycle time (Wikipedia contributors, 2020).

TDD accomplishes high quality by recommending the following:

1. First, writing unit tests that validate requirements pass

2. Secondly, writing the code to meet the requirements

3. Validating execution with unit tests from step one

Unit testing saves time that'd otherwise go towards developing code that isn’t required, and it also keeps development simple while improving developer morale.

Unit tests can be written through custom programming in UiPath, but there are also testing frameworks which come ready-made for this purpose including UiPath's Test Manager.

RPA consultants often have their own unit testing framework as well, but it’s important to note that testing is an evolving capability in this space. 'Automated automation tests' present their challenges and don't remove the need for pair programming.

After unit tests pass, and pair programming reviews are complete, integration tests are held. At this stage you might validate test cases such as:

1. Is the bot capable of connecting to the database?

2. Can the automation access the necessary APIs and can it run transactions that update the database as required?

There are testing frameworks which can handle integration test cases, but it’s important to note that peer code reviews are still critical to quality at this stage.

Some developers choose to correct issues themselves after completing unit testing and running preliminary integration tests, saving peer review for last. While such an approach might work for seasoned developers, junior developers benefit from peer coding early in the delivery of automation, as do senior developers when programming something completely new to them. If business users often discover issues that could have been identified in unit testing or integration tests, then that's a sign that the developers' process could be improved and it is worth raising for discussion with the right parties.

End-to-end testing is completed to verify all aspects of a bot's operation including automation of a user interface, the logic used, exception handling, database and API connections, and more. Whereas business users are sometimes involved in integration testing, they're always present for end-to-end tests.

Eliminating RPA design errors

RPA is an abstraction of programs (automated at the user interface layer) and is often developed using a drag-and-drop user interface. Because of this light approach, it's fitting that design remains simple to build, test, and expand upon.

James Shore has various resources regarding simple design, such as this blog post here.

Design errors often happen when you delegate design decisions to RPA developers that are at an entry or mid-level. Decisions ought to be made with the necessary business stakeholders and solution architects instead. If a solution architect isn't available, a senior developer may make such decisions with the necessary stakeholders.

Senior developers can usually handle the design of automation that save a few hours worth of transactions a day and run on one machine. For engaging projects which require the orchestration of multiple unattended bots, or projects that require dynamic machine provisioning for scaled processes, a solution architect is a must.

Additional resources from the software development practice can be applied to the context of RPA and have been linked below:

• Incremental Design and Architecture

• Refactoring

• Slack

• Technical Debt

Minimizing RPA requirements errors

Requirements are best documented when working with multiple teams (not just subject matter experts on one team) which factor in all levels of requirements:

1. The customer requirements

2. InfoSecurity and Compliance

3. Management

4. Employees

5. Leadership

6. Business partners

For companies starting off with automation, it's likely that some stakeholders, such as InfoSec and Compliance, will be more present in the first automation projects. After that, it's expected that documentation will have been established which defines how to address future projects within the necessary gaurdrails.

InfoSec and Compliance would still review proposed automation projects, to ensure that there are no inherente risks before development starts, but chances are they that'll be more hands-off as time goes on due to the nature of work becoming more routine.

Business analysis is a well documented field and it is a critical component to successful RPA implementations. There are extensive resources such as the Business Analysis - Third Edition book written by Debra Paul, James Cadle, and Donalds Yeates which go into more detail on the matter.

Don't delegate RPA business analysis to RPA developers.

Delegating RPA business analysis to RPA developers is a practice that should not take place. This blurs the lines between those that are responsible for understanding the business (and communicating the requirements) and those that deliver valid automation using RPA technology.

Combining developers with business analysts will create a nightmare fueled by contradictory intents.

RPA is a type of software development that can be just as complex as traditional development, and it comes with the same consequences as poorly written applications. Simply because the barrier to entry is lower with RPA doesn't mean that business analysis best practices can be thrown out. After all, if the RPA developer misses a requirement in their analysis, and does not develop it accordingly, they could very well miss the requirement in integration tests as well (since they would have created the test cases), and by the time the end-user is aware of the problem it will take that much more effort to resolve and re-test.

Eliminating RPA systemic errors

If the previous types of errors were properly accounted for, you'd end up with zero systemic errors. Errors that occur by this point indicate that there is something wrong with the processes used to deliver and test software.

Additional testing can be undertaken in the form of exploratory testing, in which testers use experience to determine where bugs may exist and where to create cases to catch them. James Shore recommends only bringing on exploratory testing when it's clear that bugs have escaped all other processes and additional oversight is required (and then dialing that back as necessary).

Should errors be discovered before production, or after, a root cause analysis should take place to determine what breakdown made it possible for the problem to manifest. Errors should also be prioritized for correction according to their severity and frequency.

Footnote:

The term 'Robotic Process Automation' is used due to its popularity in the industry. Process automation is a clearer term that'll ideally replace 'RPA.'

References:

James Shore: Alternatives to Acceptance Testing. (2010, February 28). http://www.jamesshore.com/v2/blog/2010/alternatives-to-acceptance-testing

Wikipedia contributors. (2020, February 7). Test-driven development. Wikipedia. https://en.wikipedia.org/wiki/Test-driven_development

This article was written when I was involved in the RPA industry as an IT manager. However, driving efficiency with RPA is something that I no longer undertake on a full-time basis. The full context for this message is detailed on the following page.

As a technology user, you’ve likely encountered uncanny bugs in tax preparation software, phone applications, and various other products and services. Such gaps are inherent due to differences in how people communicate with the world and how computers communicate with each other. For example, people use a base ten counting system and computers use base two.

Managing the ambiguity between how a person completes a process and how a computer should be instructed to complete the same process isn't a feat to take lightly. It requires concentrated effort between various people spanning analysts, RPA developers, solution architects, project managers, testing engineers, system administrators, and many others.

In this article we’ll run through top drivers of technical ambiguity and how to minimize or remove it all together.

Siloed Robotic Process Automation (RPA) operations

Siloed RPA implementation and operation leads to a breakdown in coordination between departments. A resulting lack of integration planning and collaboration then leads to a poor understanding of the overall automation architecture, and a broken view of business processes.

RPA problems can lead to negative implications including inconsistent data, failing downstream processes, and even poor reputation or legal ramifications.

When multiple departments sign contracts with RPA providers, it leaves the organization in a fragmented state that has little to no centralized oversight.

Unintentionally decentralized RPA initiatives result in automation scaling gaps which limit benefits and reliability for the enterprise.

Overcoming siloed RPA operations requires the establishment of a center of excellence and a governance model.

Governance should clearly establish the RPA strategy, how resources will collaborate effectively, the objectives, and the best practices to be applied. For example, HR can be a partner in the program to assess the impact of RPA on the company, highlight skill gaps, and develop training programs to upskill employees with extra time on their hands. In return, HR can also become an automation beneficiary to receive technology solutions that makes manual mundane work obsolete.

The best way for an RPA program to be managed at an enterprise level is by establishing an RPA Center of Excellence (Furlong, 2017).

Technical ambiguity

Even though companies stand to gain a lot from RPA, many are having trouble realizing the full potential due to technical debt they've incurred or continue to incur. RPA ambiguity is a result of poorly managed assets, improperly scaled infrastructure, and inadequate license usage.

Minimal oversight and a lack of applying best practices also drive technical ambiguity. Ambiguity that goes unresolved for too long can have a devastating effect on an organization’s ROI and stakeholder experience.

Consider, as an example, a fleet of fifty automated bots implemented without centralized logging in place. As it becomes apparent that this isn't scalable from a monitoring perspective, the backlog of work to standardize the logging could hold the company back from implementing new automation to drive actual value to the business.

Removing technical ambiguity requires that companies address questions spanning:

1. Asset management,

2. Support of RPA bots

3. And various other delivery process questions (Parikh, 2018).

IT support is an important factor which not only maintains the infrastructure and automated processes, but the function also takes direction from InfoSec on how to guarantee systems meeting security requirements.

Questions regarding ownership of functions, such as IT support, should be addressed early on in RPA programs. If resources don't currently exist for effective RPA support, then they must be accounted for from the start.

Getting clear buy-in that establishes ownership and accountability for the RPA program helps to resolve technical ambiguity. Keeping track of individual automation key contacts (spanning those that are responsible, accountable, consulted, and informed) is also a must. Being nimble to begin with is fine, but as the program matures, it's important that expectations and resources also mature.

Poorly managed change

Avoiding ambiguity requires documentation, version control, and testing procedures, among many other change management practices. To learn more about libraries or frameworks that document these, you can look into COBIT or ITIL (which was covered on the topic of defining an automation strategy).

Lack of formal hand-offs

When original teams that build automation move on from the company, or to another department, automation operation becomes problematic if the hand-off was not completed thoughtfully.

In a poor-hand off scenario, business users don’t know where the logs are, if the logs contain textual data only (or if screenshots are available), what the escalation procedures are (or who to escalate to), what the business exceptions are, how unknown business exceptions are handled, and so forth.

When everything is running fine, not knowing the answers to these questions isn’t detrimental to the business. It’s when ‘stuff’ hits the fan that these unknowns set alight blazing fires that need to be put out.

In organizations that value removing technical debt and ambiguity, it only takes a few repeat incidents where teams don’t have the necessary documentation or fallback procedures to get serious about change management.

For organizations that accept the status quo, it’s not unlikely that these impromptu fires and unnecessary calls will become their way of doing business. It's also not unlikely that eventually it becomes the way that their business is undone.

For companies that want to make automation resilient and reliable, it's important to prioritize:

1. The creation of a logging and monitoring standard.

2. RPA BCP plans along with assigned process owners that incidents are escalated to.

3. A quality control procedure for each process.

4. Technical documentation outlining exceptions and more.

Next steps

If you’re looking for strategy best practices for scaling an RPA program, you may want to review Scaling Intelligent Automation: 27 Strategy Best Practices.

Footnote:

The term 'Robotic Process Automation' is used due to its popularity in the industry. Process automation is a clearer term that'll ideally replace 'RPA.'

References:

Furlong, S. (2017, February 14). Overcoming the Challenges of Robotic Process Automation. Default. https://isg-one.com/articles/overcoming-the-challenges-of-robotic-process-automation

Parikh, S. (2018, February 12). RPA implementation – meet the challenges with the right approach. Nividous Intelligent Automation Company. https://nividous.com/blogs/rpa-implementation-challenges-and-right-approach

This article was written when I was involved in the RPA industry as an IT manager. However, driving efficiency with RPA is something that I no longer undertake on a full-time basis. The full context for this message is detailed on the following page.

A determining factor in the success or failure of companies is their propensity to falling trap to the status quo bias. Think for example of Blockbuster or Circuit City.

If your own company exhibits these traits (and you're accountable or responsible for automation's success), then you'll want to do everything within your purview to transform the business's weaknesses into strengths.

Internal or external IT resources know more about your business than you do

💡

Enterprises that rely on business-related context from IT departments (or third party consultants) don't know what they are missing out on until it's too late.

When no one within the business owns automation from a business perspective, that's a problem. Even if the IT providers continue to monitor systems as intended, the business is responsible for monitoring planned application changes, business process performance, and more.

In the event that a business owner leaves the company or department, and the hand-off of an automated process isn't seamless, that could result in IT knowing more about the process than the business. Such a state isn't ideal in the event that something breaks.

Without documentation, resolving issues requires digging up original requirement specifications, reviewing code line by line, and completing additional research just to get caught up to speed and determine how to proceed. Not to mention that if your IT partners are external consultants, then you're at threat for 'always needing consulting.' (Whittaker, n.d.).

Avoiding this situation from requires an investment into knowledge management in advance.

If you'd like to know more about specific documentation that is beneficial to produce and keep up-to-date in an automation program, please subscribe to this site's newsletter to be notified when an article is published on the topic.

Legacy systems which should be sunset are still maintained (and RPA is built on top of them)

If your company is maintaining legacy systems and not finding a healthy balance of when to shut them down, then it may suffer from the status quo bias.

RPA saves costs, but there are many scenarios in which implementing new platforms or upgrading your technology stack is the right answer. Simply relying on RPA to apply 'bandaids' to systems can be convenient, but it doesn't mean that it will always benefit the business in the long run.

If legacy systems stop being supported for example, there will be an immediate push to migrate to newer systems which will invalidate the entire RPA solutioning. Or at least, it will invalidate the investments made into automating the systems that were soon to arrive at their end-of-life.

Legacy systems also create a myriad of risks, including cyber risk. If your company has not quantified the opportunity cost of maintaining the current state, it would be best to do so. Jerry-rigging patches using RPA doesn't count as digital transformation and should be naturally avoided (The Risk of the Digital Status Quo, 2019).

The pitfalls of launching RPA in a culture that is adverse to change

Kim and Kankanhalli (2009) identified three categories of status quo biases within organizations:

1. Rational decision making

2. Cognitive misperception of loss aversion

3. Psychological commitment

All of these biases are directly related to whether an RPA program will succeed. The researchers define rational decision-making as an assessment between the costs and the benefits of change which takes place in advance of transitioning to new solutions. If the cost is greater than the benefits to remain in the current state, and those involved choose to do nothing, then that is the definition of the status quo bias according to the researchers.

In RPA projects, the status quo bias may be at play when employees learn that a vendor is paid hundreds of thousands of dollars to build pilot automation. Should employees decide that their manual work isn't worth the automation investment, it'd sow distrust and could establish a status quo bias. Although the cost might become normalized after some time, and regardless of it being normal to spend more during the investment period, the negative employee perception could in itself manifest a failed initiative.

The cost of an RPA proof of concept could be seen as a transition cost, according to Kim and Kankanhalli. Permanent costs would be seen as the investment required to maintain an RPA program permanently. Should employees perceive a loss of employment as a threat, they'd once again determine that the ‘cost’ of the program isn't worth it to them. The risk that's seen by employees would be defined as the uncertainty cost, per my understanding of the 2009 status quo paper, which would be the result of anxiety of the future state that RPA may create when change isn't well managed.

For employees, Kim and Kankanhalli’s work indicate that even small losses may be seen as losses that are greater than seeming gains due to cognitive misperception.

An employee might see the loss of 2 hours a day of mundane work as the loss of time that they have available to eat their lunch and have a relative amount of psychological safety from colleagues or bosses that threaten their comfort. An individual in this situation could improperly, although understandably, attribute the loss of 2 mundane working hours as being a greater loss than having the opportunity to complete work that is more thought-provoking.

Expanding on cognitive misperception as a leading factor of the status quo bias, consider that 52 percent of employees who voluntarily left their company felt that their manager or leadership could have done something differently to keep them in their job (Wigert, 2019). Oddly enough, over 50% of global companies have difficulty addressing employee retention and 50% of employees leave within the first two years of employment (Wright & Adler, 2019). It’s almost as if business is a coin toss...

In two years half of employees will leave, half of which would have stayed if their manager or leadership acted differently. It's arguable that at least half of the failed RPA initiatives could be resolved if the same management gaps that result in employee attrition were addressed.

If the attrition rate is so poor and if attrition affects productivity, since according to Wright and Adler it takes up to two years before new hires are as productive as tenured employees, you'd think that companies would do something differently to challenge the 'norm.' Knowing these numbers, as employees know throughout the matter of their work and life, it’s easy to see how they might be resistant to RPA.

If a quarter of employees feel like their employers aren’t doing enough to satisfy their expectations, what expectation does leadership with a subpar culture have for projects that rely on subject matter experts to aid RPA business analysts and executives in automating parts of their jobs?

Finally, the other driver for status quo bias is psychological commitment, which is due in part to sunk cost, social norms, and the desire to feel in control (Status Quo Bias in Decision Making on JSTOR, n.d.).

Sunk cost regarding RPA includes prior investments made in streamlining enterprise processes. This includes process improvement workshops, training sessions, and more.

Social norms refer to the social perception of the change — for example, robots will take over the world (as seen in popular science-fiction movies). Social norms for RPA that are negative about robots would detract stakeholders from their commitment to RPA success.

It's a common desire to feel in control. Handing over process execution to a robot and technical analysts definitely checks the box for ‘not feeling in control.’

The paper written by Kim and Kankanhalli, goes on to identify that colleague opinion regarding change can reduce perceived switching costs and increase switching benefits. Organizational support for an RPA initiative may cover transition costs (implementation) but doesn't fully satisfy the sunk costs that employees may feel about abandoning preexisting work.

Even if manual work wasn't that exciting to employees, it's their training and pride in accomplishing that work which they factor into the mental calculus of comparing the benefits of automation versus 'just doing it.'

In a company that doesn’t suffer from status quo bias, the culture would support change well and not remain encumbered by the past. For companies where employees feel the equation of change is against them, change will be much harder.

Release today, patch tomorrow

In today's software world, it's easy for companies to enter a ‘release today, patch it tomorrow’ situation. Whether it's out of interest in building shiny new things to drive sales with clients, or whether it's a result of not properly managing interdependencies between complex technology, carrying technical debt is a huge detractor to digital transformation.

In waterfall projects there eventually comes a point where a system gets decommissioned or the deadline has long passed and there’s a requirement to move onto a new system regardless of potential issues. This is one way technical debt can emerge. In an Agile environment, other factors may result in bugs, defects, and technical gaps, but it's important that the standard for robots is much higher.

The reality is that bots shouldn’t go live with bugs. They should only go live when unknown exceptions are gracefully handled, and all other exceptions get logged as business exceptions.

Bots can be deployed in an incremental fashion, but there's no room for logic ‘gaps’ in their performance, especially given the downstream ramifications. Whereas a bug in a product may cause a customer's action of updating their profile's username to fail, a bug in an automated process may cause hundreds of insurance cases to be improperly closed or worse. Given the volume that unattended robots can handle, it's critical that any company's challenges around technical debt or quality does not carry over to RPA.

One manner to ensure that success is achieved is through proper Agile training, test-driven development, and the use of both Process Definition Documents as well as Solution Design Documents. The reason Agile training is helpful is because it ensures that the right habits and mindset is shared by the teams responsible for building robots. As for test-driven development, it hinges on the business analysts' comprehensive understanding of the requirements and ensures that the context of testing methods provides valuable insight into what truly differentiates a success from a failure (further driving the development quality up and simplifying the user acceptance testing phase).

Footnote:

The term 'Robotic Process Automation' is used due to its popularity in the industry. Process automation is a clearer term that'll ideally replace 'RPA.'

References:

Kim, & Kankanhalli. (2009). Investigating User Resistance to Information Systems Implementation: A Status Quo Bias Perspective. MIS Quarterly, 33(3), 567. https://doi.org/10.2307/20650309

Status Quo Bias in Decision Making on JSTOR. (n.d.). https://www.jstor.org/stable/41760530

The Risk of the Digital Status Quo. (2019, October 17). Public Policy Forum. https://ppforum.ca/publications/digital-status-quo/

Whittaker, T. (n.d.). So, what does the status quo look like? https://blog.itsdelivers.com/productive-it-insights/so-what-does-the-status-quo-look-like

Wigert, B. S. M. A. B. (2019, March 13). This Fixable Problem Costs U.S. Businesses $1 Trillion. Gallup.com. https://www.gallup.com/workplace/247391/fixable-problem-costs-businesses-trillion.aspx

Wright, H., & Adler, F. (2019, February 15). Understanding Why Employees Leave: 10 Turnover Statistics You Need to Know. HR Partner. https://blog.hrpartner.io/understanding-why-employees-leave-10-turnover-statistics-you-need-to-know/

This article was written when I was involved in the RPA industry as an IT manager. However, driving efficiency with RPA is something that I no longer undertake on a full-time basis. The full context for this message is detailed on the following page.

It’s critical to establish an automation strategy so that the company is aligned on the vision and can overcome scaling challenges.

Two popular frameworks used in information technology are Controlling Objectives for Information and Related Technology (COBIT) as well as Information Technology Infrastructure Library (ITIL).

COBIT is focused on controlling enterprise IT and establishing a roadmap for where it'll go. In other words, COBIT focuses on reducing risks and establishing a strategy.

ITIL is focused on continuous improvement and efficient operations — it focuses on best practices that improve outcomes for the business (Leinov, 2018).

You may think of ITIL as tactical and of COBIT as strategic. It’s possible your company is already using some of these libraries within specific departments (such as ITIL within IT support and COBIT within accounting). Which framework or combination of frameworks is used is something that your company has likely already decided upon, but it's good to know about alternatives and where you can borrow knowledge from.

The reality is that any framework for managing IT solution delivery is better than the ‘automate first, think about it later’ mentality.

Simply 'winging it' will result in an RPA program running out of steam, automating the wrong processes, or being tactical at the expense of not seeing the bigger picture.

ITIL and COBIT aren't the only frameworks in existence, and it's worth exploring other options if your company is in need of a best practices library. This article in particular will focus on the main takeaways from COBIT’s 'Manage Strategy objective' and how those insights apply to establishing an automation strategy.

Strategy Management Using COBIT 2019

According to Process Symphony, COBIT suggests that strategy management should involve:

👓

1. Forming an overview of the business and IT environment

❓

2. Identifying what needs to take place to move towards the desired future state

📊

3. Accessing the existing digital maturity

🗺️

4. Establishing the roadmap to address any gaps between the desired state and the existing maturity

⭐

5. Prioritizing transformation

🏗️

6. Applying existing architecture that’s in place for IT or governance

To accomplish good strategy management, COBIT specifically recommends the following management practices:

APO0 2.01 - Understand enterprise context and direction:

Identifying what competitors are doing, where the industry is headed, and what regulations you’ll face in RPA are all important undertakings in this practice.

If you’re in the lending space and the competition is moving towards using AI to assess borrowers' risk, it’s important to recognize that trend and not over steer towards RPA automation. In the lending space example, you may want to explore both RPA and AI (known as intelligent automation) to remain on the cutting-edge.

If, on the other hand, you’re in the service industry with hundreds of employees working on IT demands spanning account management and troubleshooting, it'd be critical to identify how RPA can help and where the competition is heading.

Connecting with RPA software vendors or consultants through events, as well as reading their white papers, is a great way to become aware of the applications of automation in your industry. Remember that this information is biased with a skew towards the implementation, and payment, of RPA vendors or IT providers' services.

To remain impartial, you can 'mine’ the industry use-cases and do your due-diligence by connecting with other leaders in your line of work. Learn from their successes and also make note of their challenges. If the benefits you've heard of in RPA are tipping the scales in its favor, make sure you find counter arguments to develop a balanced view.

Set the context for what is and isn't in scope for RPA:

💸

It's not to say that RPA should be avoided, but that it's necessary to identify and avoid bad use cases for your industry.

Letting IT service providers drive the narrative of your company's automation roadmap could result in a 'gold brick road' phenomenon. You don't want to stop looking at the road because you think 'it's taken care of' only to end up left dealing with a broken suspension after running into potholes...

Be sure to factor your organization’s tendency for innovation adoption as well. Is your organization an innovator, an early adopter, an early majority, a late majority, or a laggard?

If there’s only a handful of companies succeeding with RPA in your space, and they have budgets that are fifty times greater than yours, its possible that as an early comer you'll be better of waiting until at least twenty more companies in your industry announce success with RPA. Granted, the number twenty isn't set in stone - it's just an example, but such an approach not only gives you an opportunity to catch up with the technology, but it also gives the market a chance to learn your industry.

In a smaller company you'll also have less opportunities for automation (most of the time) and you'll have less margin for error, which means that it's better to let the ecosystem spend money digging new wells of productivity. After they've established where the 'oil is flowing' buying up real estate in the victinity to profit from their discovers is in tow.

Even though RPA has been gaining steam over the past half decade, hiring a tried-and-true RPA specialist continues to be a challenge. As time goes on, that should hopefully become less difficult. But why wait for the industry to catch up when you can train existing IT specialists on RPA within your company?

APO0 2.02 - Assess current capabilities, performance, and digital maturity of the enterprise:

If your company’s IT department is already using ITIL as a framework, then use whatever materials are available from that framework, or another management lens, to determine what the current digital capabilities are.

In this objective, you'll also assess the supporting IT capabilities of your company to determine whether it'll be cost-effective to establish RPA as an in-house function or if consulting is recommended.

One must recognize where their company is at from a digital maturity perspective.

⚙️

1. Is there an established process improvement team that uses Lean or Six Sigma to improve processes? This is important for feeding opporuntities to a development team to implement.

📈

2. Are IT processes monitored automatically and continuously improved upon? This is important to gauge how well the automation can be managed based on existing capabilities (or if gaps exist that must be addressed).

👨🏼‍🏫

3. Do employees get trained in new skills (i.e., upskilling) after the processes they're responsible for are optimized and they don’t have to spend as much time completing them? This is critical to ensure that time saved up for employees is focused on value-added activities to truly realize benefits from RPA.

🖱️

4. Does the business have business analysts that document requirements for IT changes or new solutions? If not, they will need to be hired or contracted for the duration of proof of concept projects or the future program.

All of these questions, and more, must be answered to determine where IT is at from a perspective of being able to deliver and oversee RPA implementations. Likewise, it's important to understand where supporting business teams are at in their digital maturity:

👓

1. Does the business have a perspective allowing it to see where opportunities exist for automation? I.e. are analysts familiar with the underlying systems and the efficiencies that can emerge in their own work by better integrating them?

🔢

2. Does the business have clear metrics to share how processes are performing today and the benefits of improvement? If they don't, then going back to the process improvement drawing board and implementing an analytical approach to process management might be best.

🧠

3. Does the business have an overall mindset that's conducive to continuous improvement?

Assessing the company's maturity in digital data management is paramount to developing an enterprise RPA strategy.

For example, if hundreds of emails are sent in with scanned forms from customers, we'd say that the process is mostly analog — information has to be manually entered by an employee from the scanned forms. The delivery method of the form is digital, so the process is somewhat digitized, but not nearly enough to be ready to benefit from an RPA perspective. Sure, a third party IT service provider might tell you that they can get those forms read using Optical Character Recognition (if you pay them a fair amount of money and would like to purchase an OCR license from a vendor that integrates with your RPA solution), but that’s often not the best way to go it.

Consider for example that a form which is often typed out and printed by a customer would better serve the customer if available online so that they can fill it out on any of their devices and not have to worry about printing the form in advance (since not everyone has access to a printer). Furthermore, customers that are traveling wouldn’t be able to print out a form and would not be as satisfied having to wait a few days or weeks to get back home just to print a document to fill it out by hand.

APO0 2.03 Define target digital capabilities:

In the example above (where customers email forms), it'd be best for the organization to consider a customer relationship management system which can track a variety of requests. It'd also be great to intake information via digital forms, if the opportunity is there from an IT and enterprise prespective. Establishing such goals would allow the organization to plan for the upgrade of their systems, to stop relying on analog means, and to become fully digitized (with or without the requirement to implement any RPA).

Implementing digitization, at a level of optimal capability, should strive for a system which offers workflow automation out of the box. One can imagine in a customer request scenario that if a form is filled out with a specific product, then the task of reviewing and approving the customer’s details ought to go to a designated team as opposed to a general queue. This level of workflow automation, even though basic, would fulfill the concept of ‘digital transformation’ - the process would be digitally processed to some extent and not just 'digitized.'

Only after the organization has addressed its digital maturity and arrived at the most optimal capability of systems should it consider automation of remaining gaps. Otherwise, the company is at risk of automating bad processes such as those that rely on free-form email (which isn't scalable even with typed forms/OCR). The company is also at risk of funding something that'll never be profitable.

If it took 6 months to automate 10 processes using an email medium, and after 3 months the emailing system is replaced with a proper CRM, the bots would instantly become useless. Some companies can effectively predict the value of automation as being profitable, even if it'll be run for a temporary period (before a system migration a year or two out). There's no rulebook against building automation that has a known end-date from the very beginning, but it takes a serious consideration of the costs and benefitsto succeed in these edge-cases.

When the organization produces loss-makers, it becomes much more difficult to achieve success. This can lead to a frantic approach of automating things “faster” so that benefits can be realized before changes take place or automating as many things as possible, even if they provide small benefits.

To put this section simply, the target digital capabilities of an enterprise should not rest on RPA capabilities as a foundation. Digital capabilities refer to systems, processes, and integrations at the infrastructure level. Only after enterprise architects, process improvement teams, and system administrators have improved the system within their means should RPA be explored.

APO0 - 2.04 Conduct a gap analysis:

Analyze the current state as compared to the desired future state. Determine where gaps exist. This is dependent on the industry you’re in and the size of your company. There’s a lot of material on this topic, so we’ll let you dig deeper as needed.

APO0 - 2.05 Define the strategic plan and road map:

Without a plan, there’s no way to gauge whether you’ve succeeded or not. There’s also no way to get aligned with cross-functional stakeholders on how to achieve the vision and in what time frame to do so. At the very least, it's recommended to establish a six-month to a one-year plan for RPA proof of concept initiatives (as well as planning one to three years out after the first phase is completed).

For example, you might bring in consultants for 6 months to determine if RPA is practical at your company by creating five bots for specific processes that show the most potential for benefits and implementation success. During month three you’ll have to decide if you want to continue to support the bots that are being built (or have already been deployed), and you’ll likely be deciding whether this consultancy is the group you want to continue working with for the long-term.

The strategic plan may include:

1. How Automation Governance will be defined

2. Establishing where the RPA Center of Excellence (CoE) will be housed

3. The Automation Operating Model and cross-functional collaboration

4. Development resource allocation, training, or outsourcing

5. The cost-benefit model

APO0 - 2.06 Communicate the I&T strategy and direction:

After you’ve established the information and technology strategy, and received the necessary approvals from leadership, it’s now time to communicate the strategy. Change management practices, such as those from Prosci, may be helpful in meeting this objective.

Footnote:

The term 'Robotic Process Automation' is used due to its popularity in the industry. Process automation is a clearer term that'll ideally replace 'RPA.'

References:

Leinov, V. (2018, May 15). COBIT vs ITIL: a real-life example of what these two can do. ScienceSoft. https://www.scnsoft.com/blog/cobit-vs-itil

Process Symphony. (2019, June 2). Strategy Management APO02 (COBIT2019) – Process-Symphony – ITSM Knowledge Orchestrators. https://wiki.process-symphony.com.au/framework/lifecycle/process/strategy-management-apo02-cobit2019/

This article was written when I was involved in the RPA industry as an IT manager. However, driving efficiency with RPA is something that I no longer undertake on a full-time basis. The full context for this message is detailed on the following page.

Often times there's doubt over the cost of technology and its benefit to the business.

Consider the price of a mail server, firewalls, and other investments needed to keep email working properly within a company. It might seem absurd to spend tens of thousands of dollars on mail every single year when it's all added up. However, when comparing email to running a mail room, the cost becomes very reasonable very fast. This example may seem obvious, but it's exactly the type of issue that comes up within management on the topic of technology expenditure.

RPA is often seen as a ‘low-cost’ solution to deliver IT solutions for the business, but costs will inevitably stack as time goes on. As costs increase into the hundreds of thousands of dollars, it's important to track the benefits and always be able to justify automation. In early stage programs, benefit analysis will be the determining factor as to whether they scale beyond a proof of concept or get shut down.

Monitoring costs and benefits throughout the lifecycle of automation

As you read this article, make note of how you can document expected benefits before implementation of automation and how you can modify those expectations as new information emerges. For example, the first automation opportunity may seem to save $50,000 a year after factoring in all costs. After a proof of concept gets delivered, the scope is lowered of what is feasible for automation and savings then only account for $25,000 in total. Finally, after the automation's implementation, benefit monitoring indicates that only $18,000 in savings were realized due to unexpected maintenance requirements. This information will be valuable in making cost analysis as effective as possible, and it'll provide a baseline to assess how well investments hit their predicted targets as time goes on (and new incidents or upgrades emerge which further erode value).

Documenting tangible benefits

Tangible benefits (such as time saved per year and service-level agreement improvements) are a priority in analysis models — as are other metrics that easily convert to a dollar basis. A company considering tangible benefits might ask themselves 'how much do we value reducing turnaround times for customer requests?' If there’s a known penalty, such as having to pay a refund to the customer (or losing renewals) then we're able to quantify the savings of a better SLA.

Collecting expected benefits as early as possible when identifying automation opportunities is critical. Simply going off business user estimates of how long a task takes isn't enough to satisfy documentation requirements. This information should come from a business user, a subject matter expert, and/or management. Discrepancies should be carefully analyzed. One other way to gather this information is through a time-in motion study completed by an impartial and skillful analyst.

The reason relying solely on numbers provided by employees is avoided is because they can change dramatically depending on who you talk to. That's not to say that employees will outright give the wrong information to downgrade how long a process takes (for fear of losing their job to automation) - but rather, it's more a matter of them not having the full picture.

Consider that after a front-line worker completes a certain task, they don’t have visibility into how long it takes to complete quality assurance on their own work. The front-line worker also doesn't have visibility into how long it takes to complete a follow-up process that another department will undertake with the output of their efforts.

If a process is being evaluated as an automation opportunity, it’s important to assess it fairly by understanding exactly how much time and resources are required per transaction. The downstream impact of potential automation on quality insurance, related processes, and systems must be considered.

An objective and comprehensive cost analysis may take time and effort, but it is a cost of doing business in automation and shouldn't be an afterthought. Such an analysis is the lifeblood of justifying the operation of an automation program as well as its expansion. After all, you'd rather find out early on that a process isn't worth automating rather than a few weeks into its implementation and go-live.

Intangible benefits must also be factored

If customer satisfaction is suffering due to poor quality or slow turn-around times, what opportunities does automating a process represent? Would cutting 10% of negative reviews left every year improve reputation enough to justify the cost of implementing automation?

These types of questions have different answers across companies and industries (according to their go-to-market strategy and objectives). The nature of intangible benefits is that they're hard, if not impossible, to directly correlate to revenue or profit. As a result, the amount of processes that are prioritized for automation due mostly to their intangible benefits are likely going to be far and few in-between.

Focus on tangible savings and supplement with intangible benefits

A company that's a heavyweight in automation is in a better position to spend money on something that might look like a loss maker to beat the competition or derive other benefits. For a company that’s in the early stages of automation, taking on this kind of unknown risk isn't worth it, especially as the company is coming to terms with the total cost of operating and scaling their program.

Implementation costs

For implementation, it’s critical to determine how much it'll cost to develop bots in a given time frame. For example, if the first year of bot development will be undertaken by consultants — how much will that cost and what will the expenditure be to bring in internal developers towards the end of the year to take on development responsibilities?

Another important question to consider is at what point does the cost of the first RPA initiative (which is testing the waters within a business) move on from an implementation cost to an operational cost? Once your organization has their answer, it's important to stick to the guidepost and not move it for the interest of 'extending the viability study.'

Something else that must be considered is the cost of labor for the business’s investment into RPA. Subject matter experts, management, business analysts, and ancillary departments will be engaged throughout automation qualification and implementation.

Hours of resources add up quickly and it may not be possible to get an accurate number down for resources, but it's important to have a rough understanding of departmental costs. For example:

1. Costs of HR (upskilling in RPA, hiring, etc)

2. Costs of InfoSec (access, new workflows for tracking automation compliance)

3. Costs of specific departments engaged in automation

Keeping track of time (even in increments of 4 hours, for example) is also a great way to gain insights from RPA implementations. Trying to look back on a year of implementations to determine ‘how much did it require in terms of labor’ is a really difficult endeavor that relies on memory and inaccurate estimations.

It’s better to capture cost-benefit data up front and to optimize implementation efforts in two to four week sprints than it is to look back and see that the program didn't operate as well as it could have.

Re-evaluate consistently and question how the value could be improved. If something isn't panning out as intended, don't be fearful of pivoting or reducing spend as needed.

Infrastructure costs

Track everything that goes into infrastructure including RPA bot licenses, orchestration licenses, servers, supporting software (such as VPN software, antivirus, and so forth).

None of this is free and the more information that's gathered, even at a high-level perspective of ‘it costs about $1,000 to provision one machine with the necessary software and another $5,000 pear year for a bot license in 2022’ is a lot better than the perspective that it’s ‘free’ or ‘inexpensive.’

Establish a time frame to assess these costs and make sure that they are kept up to date. As time goes on costs will increase and it's beneficial to analyze performance and predict how changing variables will continue to impact your business.

Operational costs

How much does it cost to operate your RPA program? Whether this is a consulting cost, or an internal cost, what is the total investment required to support automation?

If you have a governance group that provides oversight to an Automation Center of Excellence, how much is that additional overhead incurring? If it’s necessary to bring on a change manager, an Agile trainer, or another resource, what is that cost and how are those costs allocated to individual automated processes (or to the entire program)?

Other questions include:

1. What does the operational cost look like on an expanded time frame two or three years down the road?

2. Is it sustainable to operate automation via third parties or is it better to bring it in house?

During implementation, it’s tempting to just 'onboard' additional bots and worry about the rest later. However, as an RPA program picks up steam, it’s necessary to consider the usage of bot servers:

1. Are the bots really running 24 hours a day? Or are they running closer to 10 hours a day? If so, the cost of their underlying infrastructure needs to be updated.

2. If a bot license is used 10% of the time, is there a way to get other processes added to that same server to reduce the cost of running a single process on it?

There’s a variety of metrics to track, forecast, and manage when running an RPA program. This article could only cover so much, but we hope it got you thinking about what would go into an automation cost-benefit analysis.

If you’d like to read more on the topic, you'd likely find value in ‘Understanding RPA ROI’ by the Institute for Robotic Process Automation & Artificial Intelligence.

Footnote:

The term 'Robotic Process Automation' is used due to its popularity in the industry. Process automation is a clearer term that'll ideally replace 'RPA.'

This article was written when I was involved in the RPA industry as an IT manager. However, driving efficiency with RPA is something that I no longer undertake on a full-time basis. The full context for this message is detailed on the following page.

Process automation is a growing trend and so is the question of what department it belongs in. This article explores what an Automation Center of Excellence is and which departments it can operate from best.

What is an Automation Center of Excellence?

The definition of a Center of Excellence (CoE) is a team which promotes collaboration and best practices related to a focus area to drive value (Strickler, 2016). In large organizations, the CoE is usually a department of its own.

Strickler goes on to state that the CoE is responsible for supporting lines of business through services or subject matter experts. They're also responsible for standards, methodologies, and tools, as well as training, performance monitoring, and governance.

Salesforce puts it best when they mention that CoEs have been around for decades, but people still have a hard time defining them in a consistent manner. Within their blog article, Salesforce goes on to share the perception of CoEs as being broken into best practice centers, DevOps centers, competency centers, and innovations centers (Evans, 2016).

CoEs may focus on process improvement, project management, quality assurance, risk and compliance, HR, and other areas of the business. They typically have a single focus area, although there are some which may have overlapping interests and capabilities.

Not all CoEs have the same level of resources or power, so it's crucial to recognize their limitations within your company and act accordingly.

1. Practice centers focus on breaking down barriers between departments and sharing industry best practices. You might think of these as a department of ‘coaches.’

2. DevOps centers are those that undertake implementation, development, and maintenance of solutions.

3. Competency centers would include something such as a Project Management Office that offers skilled resources to the organization (such as leading projects to successful completion).

4. Innovation centers, on the other hand, are responsible for creating new solutions from scratch or by synthesizing existing tools and processes anew.

What department does the Automation Center of Excellence belong to?

For those with a background in technology, they often see the Automation Center of Excellence as belonging to IT or Software Development. For those in operations, especially in companies that already have business improvement CoEs, they'll make the argument for having automation belong to a specific business group or unit.

One reason that business-oriented people see automation as belonging to them is due to the negative perception of IT cycle times. Regardless, industry experience has shown that RPA implementation, from a purely technology perspective, is often best seated within IT-orientated groups.

An exception could be made when a company is primarily technology-based and their employees have an above-average IT skill-set. Above average would cover experience with the software development lifecycle, version control, user acceptance testing, requirement gathering, and much more.

The only other time an automation CoE should be run outside an IT department is when there's a good case which doesn’t happen to rely on ‘IT takes too long’ or ‘RPA is low-code and doesn’t require coding’ types of arguments. These arguments don’t hold up in the long-term because issues will emerge in a non-IT team managing RPA.

For example, if a bot’s volume increases to the point where additional servers are required and the person who built the automation has left the company, it won't be easy to hire an RPA developer and have the business manage them and their IT delivery. It won't be easy in the sense that the business will have to overcome the very same hurdles that were originally stated as reasons for not having IT manage automations (that IT takes too long and that automation is easy enough to manage with low-code solutions within the business).

One thing to note is that executives may make the valid case for having RPA business analysts remain within a business group. In fact, this is a perfect argument to make because:

🤖

Analysts that have an intimate understanding of their industry are well served to create requirements for a process and to interpret where opportunities for where automation exist.

🖥️

IT resources, such as RPA developers and solution architects, work best when converting clearly defined business requirements into a cost-effective and scalable implementation. As long as the business analyst is set up for success when it comes to collaborating with the IT resources that would meet the business requirements, this approach is logical.

Cons to business teams running automation

If a business line, such as operations or marketing, decides to bring in a new automation suite like Automation Anywhere or BluePrism, they'll still require approval from IT. They'll also rely on IT for implementing infrastructure to support automation and for approving requests that make changes a reality.

If the business line experiences an incident with their automation, or fails to maintain development quality or scalability, the rest of the business will lose trust in RPA. Loss of trust results in eroded value and a more difficult roadway to an enterprise automation that runs as a profit-center.

Consider another scenario in which a business director asks for non-RPA resources from a technology Vice President, but that request is rejected due to limited resources or prioritization. In such a scenario where integration or system upgrades are denied, the business may easily jump into RPA ‘patching’ of processes because that's the only tool available to them (rather than considering the criticality of other solutions).

Patching problems disregards the importance of business process management and optimization before implementing technology. For example, if an underlying automation need is due to the reason that a company doesn't have a Customer Relationship Management system, automation should not be delivered that mirrors the functionality of a CRM in a piece-meal fashion. A piece-meal approach to automation, rather than employing the right systems, can be damaging to a company of any size as it results in duplicative work and unnecessary system complexity.

🩹

Giving the business a band-aid solution distracts from the conversations that need to take place to mature the organization's digital capabilities before addressing the gaps using RPA.

Does the Automation Center of Excellence need to be its own department?

An Automation Center of Excellence can be its own department within the IT business line or it can be a team that reports to a Software Development or IT director. The specific answer will depend on the size of the organization, the maturity of its RPA program, and its goals.

If an RPA initiative is in a proof-of-concept stage where contractors come in for 6 months, then it might make sense to have it managed under an existing IT department. If the end-goal is to make enterprise automation a strength of the company (provided as a service to other departments) then its worth exploring the creation of a new department that reports to an information or innovation line of business.

Under no circumstances should an IT team, or contractor, be managed solely through a business department of a company that doesn't specialize in IT.

Footnote:

The terms 'RPA' and 'Robotic Process Automation' are used due to their popularity in the industry. A simpler and less confusing term is process automation (which will hopefully overtake 'RPA' in the near future).

References:

Evans, M. (2016, February 9). Overcoming the Curse of the Center of Excellence Model (COE). Salesforce. https://www.salesforce.com/blog/center-of-excellence-curse/

Strickler, J. (2016, November 9). What is a Center of Excellence. WordPress.com. https://agileelements.wordpress.com/2008/10/29/what-is-a-center-of-excellence/

This article was written when I was involved in the RPA industry as an IT manager. However, driving efficiency with RPA is something that I no longer undertake on a full-time basis. The full context for this message is detailed on the following page.

If you refer to any automation consultant worth their salt, such as Laserfiche, you’ll quickly learn that Robotic Process Automation is only a ‘finger’ on the hand of Business Process Automation (Staff, 2018).

Business process automation focuses on the end-to-end process, whereas RPA focuses on automating tasks to reduce or remove bottlenecks. A great picture that sums up the differences is seen below:

Simple example of why RPA isn't always the answer

To exemplify how a business process would be managed in a support sense, we can imagine a customer calling in to reset their password:

1. First, they must navigate the call-tree using either number options or voice-based commands.

2. Secondly, they must authenticate themselves using an account number or pin.

3. Then the customer waits and is finally connected to an agent.

4. By this point, the customer likely has to repeat their issue and wait some more for the agent to complete their request.

Not ideal...

In the example provided above, the process may be well documented and it may also be consistent for all customers. But it certainly isn't optimized, and it has room for improvement. A classic mistake at this point would be implementing RPA to 'automate' all the pain points away.

Imagine in the example above that a consultant not familiar with the operations space claims that they can help agents complete such tasks with a click of a button (without requiring them to sign into an admin portal, tracking down the customer, and clicking to reset the password). Simply implementing RPA in this manner may not be the best use of technology.

Consider that the company representative for automation may have preferred that their agents not even pick up the phone for simple requests. If that preference doesn't make it down from leadership, an RPA consultant or IT partner may end up implementing a technical solution in a manner that isn't ideal.

A collapsible digression on the aforementioned topic 

One amusing thing to note is that many people equate call-trees or 'smart phone systems' with why automation is bad for the customer experience. Unfortunately, this is a concept that has to be broken, since such phone scripting relies more on voice recognition and totally different technology than RPA.

The example was also given because it raises questions around whether automating such a human interaction is beneficial. Contractors or consultants not familiar with a client's business may throw out things that sound great in whitepapers, but they don't always pan out the same way in the real world.

Considering that this password reset opportunity may provide representatives with a chance to offer a discounted renewal, or an upgrade to a new package, it may not be valuable to automate away. As long as customers can reset their password using a 'forgot your password link,' but they decide to call in, they should always get help especially if it it would result in the business's bottom line being improved as a result.

Improve processes first and then automate

Often times, the best avenue for companies is to re-imagine what processes would look like with the possibilities of RPA. Just automating the old way of completing a process doesn't mean that it'll be scalable in the long-run, nor does it mean that it'll result in the best outcome for the customer.

In the case of 'build a password reset bot,' one might consider that some websites use a one-time link or SMS in place of a password. Who's to say that your own company couldn't explore such an authentication method? It's not that your product needs to be redesigned, but rather, that there's more than one way to peel a potato and that appropriate alternatives must be explored. That type of problem solving and design thinking takes place at the process improvement level and not the 'RPA it away' level.

The problem with RPA initiatives is that they often involve bringing in costly resources who promise ‘fast’ turn-around times for automation. These resources, sometimes as third parties to the companies that hired them, promise results without requiring long meetings with executives or other forms of 'disruption.' What this fails to consider is that a process which is automated in this manner (of keeping everyone comfortable at a high-level) still bakes in inefficiencies for years to come.

The approach to 'flying by the seat of your RPA pants' goes against the crux of what lean process improvement sets out to accomplish.

RPA is only successful when it's used as a component for digital transformation, not as a foundation for it.

BPM and RPA go together

Not all companies are large enough to apply Business Process Management technology. Regardless of software usage, most companies use process management as a method to run their business. If they aren't mature in this area, they're likely not ready to implement RPA in a way that'll increase quality, decrease costs, and grow the business. Companies looking to improve their maturity model can explore ITIL, COBIT, or CMMI, which are covered further in How to Establish RPA Governance.

Where BPM comes in handy...

After a bot is put in place, the benefits must be measured, the maintenance must be timely and effective, and the individual bots must be well managed from a program aspect. If this doesn't take place then the program will have a hard time scaling, especially as individuals who were involved in its inception move onto other things or companies.

As this article is closed out, consider a quote from Bill Gates that sums it up perfectly:

"The first rule of any technology used in a business is that automation applied to an efficient operation will magnify the efficiency. The second is that automation applied to an inefficient operation will magnify the inefficiency." -Bill Gates

Footnote:

The term 'Robotic Process Automation' is used due to its popularity in the industry. Process automation is a clearer term that'll ideally replace 'RPA.'

References:

Staff, L. (2018, February 21). What is the difference between RPA and BPM? Enterprise Content Management (ECM) | Laserfiche. https://www.laserfiche.com/ecmblog/what-is-the-difference-between-robotic-process-automation-rpa-bpm/

This article discusses the cost of badly managed knowledge.

While this isn't directly related to Robotic Process Automation, it's important to consider that companies tackling automation are more successful when they establish a strong commitment to knowledge management.

The more documentation that exists around process design, process performance, and ancillary information, the easier it becomes to find opportunities for lean process improvement and automation.

On the other hand, large organizations that disregard their employees need to easily find and document critical information lose out on millions of dollars.

Knowledge management opportunity costs exemplified

Consider, for example, a company with 1,000 employees that are paid an average salary of $80,000. If they spend 2.5 hours searching for information each day and half of the time they can’t find what they’re looking for, that results in a 2.5 million dollar loss pear year (Feldman, S. and Sherman, C. (n.d.) the High Cost of Not Finding Information an IDC White Paper. - References - Scientific Research Publishing, 2016).

You might think the numbers above seem high, but when you consider how much time is spent tracking down files, emails, and other forms of records, they aren't that far off. Not to mention that IDC has been conducting studies on the value of knowledge management for decades so they're as reputable as sources can get.

IDC’s paper also reviews third party studies, such as those from Kit Sims Taylor in which it was determined that knowledge workers spent additional time recreating information after they were unable to find what was already documented internally on that topic.

When considering the cost of information duplication, the researchers arrived at an estimate of a company losing $5 million dollars per year (for those employing 1,000 workers).

Older business journals have tried to solve for the cost of knowledge management through the suggestion of information providers' knowledge pricing (within an internal organization) and information seekers’ departments paying for it (DeSouza et al., 2012). While such a method of evaluating knowledge was early for its time, the reality today is that organizations suffer from problems beyond the legacy academic theories and the variables that they attempted to factor for.

The modern enterprises' knowledge problems

Today's companies are mired in information portals ranging from intranet wikis, HR questions and answers, software development issue documentation, product planning documentation, CRM records and knowledge, and much more.

Employees aren't in a position to search all repositories of information when helping a client or customer. There are various solutions that help combine disparate systems into a single search solution (such as Coveo and Elastic search) but executives may view them as costly compared to existing search that's ‘free.’ Others may not even know they exist.

The mere act of buying search solutions also doesn't solve the problem of producing relevant and accurate information.

For the matter of training employees to document their knowledge, a training program such as Knowledge Centered Support (KCS) is beneficial. Once again, simply training employees in what it takes to document knowledge is problematic when stopping there and not fostering a culture incentivizes the right actions for the benefit of continuous improvement and productivity.

Companies that have tried to incentivize the creation of knowledge (through contests or paying out for a certain amount of articles written) have come to find out that low quality information was churned for cash. That same low quality information made it that much harder for them to find valuable documents needed to be productive. Put simply, knowledge management isn't something that you can 'pay employees to do' but rather, a culture that has to be instilled through effective change management.

Where will your company take it from here?

The good news is that any type of issue with knowledge management can be solved. Whether it’s systems not providing a single search solution, whether it’s outdated information that's low quality, or whether it’s a lack of training.

The not so good news for companies is that, like everything else, it’s going to take time and money. The benefits may not become readily apparent in a quarter or two, but rather, they are benefits that compound over the years.

The sooner you start to quantify the cost of knowledge management and how much opportunities are lost due to improper management, the sooner you’ll be on your way to recouping those losses and fostering a culture that values information.

If your organization is kicking off an RPA initiative and has suffered from poor knowledge management, then now would be a great time to prioritize an action plan. A great automation program isn't defined by only the present performance, but also the future of that program and how well it's documented, passed down, and its ability to continue increasing in value over time.

Footnote:

The term 'Robotic Process Automation' is used due to its popularity in the industry. Process automation is a clearer term that'll ideally replace 'RPA.'

References:

DeSouza, K. C., Yamakawa, S., Awazu, Y., Yamakawa, S., Awazu, Y., DeSouza, K. C., Bio, V., Yamakawa, S., Bio, F., Awazu, Y., Bio, F., Yamakawa, S., Bio, F., Awazu, Y., & Bio, F. (2012, July 5). PRICING ORGANIZATIONAL KNOWLEDGE: AN IMPERATIVE. Ivey Business Journal. https://iveybusinessjournal.com/publication/pricing-organizational-knowledge-an-imperative/

Feldman, S. and Sherman, C. (n.d.) The High Cost of Not Finding Information An IDC White Paper. - References - Scientific Research Publishing. (2016, June 21). https://www.scirp.org/(S(351jmbntvnsjt1aadkozje))/reference/referencespapers.aspx?referenceid=1840731

This article was written when I was involved in the RPA industry as an IT manager. However, driving efficiency with RPA is something that I no longer undertake on a full-time basis. The full context for this message is detailed on the following page.

As the adoption of automation picks up speed, vendors are in a frenzy to sell licenses for use-cases that RPA was never meant for. This article approaches the topic from a devil's advocate perspective.

If your company is considering an RPA investment then it's important to evaluate the opportunity in a balanced manner to avoid the risk of losing money or negatively impacting the business. If your company has already implemented an automation program but is facing challenges, then you may want to consider how to approach those gaps before they get out of hand.

RPA never makes mistakes — except when it fails

RPA is marketed as never making mistakes. While this is true in as far as it makes a minuscule amount of mistakes, it’s not true in the sense that ‘it never fails.’

Computer vision that RPA relies on is highly reliable but it has its faults. As underlying applications change, its possible for an automation to eventually run into the scenario where it executes an item in a way that no exception is triggered yet the desired effect doesn't take place.

For example, if an automation has to delete a record and then it shuts down the application after making the request, it may continue operating the same way when a popup in the application starts to appear which requires confirmation. Because the automation was developed to shut down the application after clicking delete, it's still able to complete its task, yet the record in question evaded the intended effect and no logging captured it. This isn't a fault of RPA vendors, and it may also not be a fault of RPA developers. But regardless of whether the issue emerged in business analysis, in monitoring, or another aspect of the automation operation or implementation, the fact remains that the consequences of such an error are serious for a business.

We can sit here and argue all day that 'computer vision' is highly accurate and that RPA never makes mistakes — but at the end of the day automation will break and someone will blame the technology and not the ecosystem that it lives within.

Considering RPA as a tool that never makes mistakes oversells the benefit of automation and downplays the amount of controls necessary to run resilient and reliable automation.

Horrible branding and horrible proposition

The proposition of RPA is that companies can assign less technically skilled employees to build automation with little to no code - this myth is explored further in 'Half a Dozen RPA Myths.'

Regarding the proposition of RPA, the little detail missed is that people are accustomed to robots being bad — think Terminator, layoffs, call-tree systems, and chatbots. Even employees that are interested in automating mundane processes will encounter challenges in a culture where doing so threatens the status quo.

On the other hand, process automation has existed for decades. Vendors such as Camunda and Flowable offer mature execution engines for business workflows. These tools support business process modeling and make it a breeze to integrate disparate systems through automation solutions.

From an automation standpoint, RPA is merely a ‘cog’ in the machine of business process management and automation. From a workflow perspective, RPA vendors oversell their orchestration capability as being a great use-case for a variety of needs which are often better handled by native platforms (such as the solutions available within Salesforce or Servicenow) or IPAAS platforms designed specifically for integration (such as Mulesoft).

The branding of certain vendors (which I won’t call out here) using flying robots is another insult to injury. It's a pure oversimplification of the complexity of robots and how people have to interact with them (through IT teams or consultants). Cute bots flying around may seem like a great marketing idea for an advertisement or two, but the fact that it's become the capstone of branding in this space is trite.

Is anyone really buying all these 'propeller heads' as the future?

Nothing is as easy as buying some technology, waving a wand, and automatically automating processes and saving money. Some professionals might read much into this section of the article, saying ‘but my proof of concept was easy and delivered results.’ To that I’ll say keep reading — succeeding at a proof of concept is easy — scaling value delivery from RPA is the challenging part.

Not enough consideration for scalability

The way some IT vendors are pitching use-cases for automation doesn’t factor in all underlying applications that'll get updated on a regular schedule (and will break the robots until maintenance is applied). When a company has a few dozen bots, this is manageable. When it gets to the point where hundreds of bots are in production, then this becomes a nightmare to work around.

Sure, the enterprise requesting automation should take this into account, but consultants and vendors also have a responsibility to pitch savings using a logarithmic return ratio, and not an 'exponential' one.

Automation vendors should also be doing more to offer best practices, and even solutions, to minimize the challenge of scaling. Some IT consultants could be doing better by addressing the challenges of maintaining a growing robot portfolio - especially as technology continues to evolve. One way that automation becomes more resilient is by pushing for API integrations over GUI automation as this ensures that less GUI upgrades will be necessary as underlying applications experience changes.

There are some players in the RPA space that support their clients' growth through an established operating model. Consider for example SmartRPA which offers solutions for intelligent robot orchestration and incident management.

Flawed RPA promises throw process improvement out with the bath water

Some overly excited consultants will tout the ability for RPA to automate processes in a matter of weeks. When this level of excitement is brought in at the executive level to usher in the ‘payroll savings,’ all other process improvement and lean reviews go out the door.

🤔

Why optimize a process when in a couple of weeks it could be fully automated?

RPA may be worth it, but when coupled with flawed promises and an implementation where process improvement doesn't drive automation, it stops being worth it really fast. Implementations will stretch out from 2 months into 6 months. Subject matter experts will express concerns with how much time they have to spend on requirement gathering and modifications, especially as time passes and changes emerge. This 'automate first, optimize later' approach is a sure-fire way to fail hard and fail fast.

RPA is marketed as a stand-alone solution or 'great bandaid'

Many business users in the space of RPA are ‘applying patches or band aids’ in the name of ‘emerging technology’ for better or worse. If this wasn’t the case, then failure rates of RPA initiatives as high as 50% wouldn't be so common.

Digital transformation is much more beneficial to companies, whether undertaken internally, through consulting initiatives, or through a supplier that offers services in this space.

RPA in of itself is not a catalyst for transformation - it is just a tool like any other. As a company advances in its digital journey, RPA can provide benefits in specific use cases where other solutions are too expensive or take too long to implement.

Arguably, most companies fail in RPA implementations because they aren't in the technology services business and can't replicate RPA success internally. Another challenge for non-IT companies is identifying a trustworthy partner to help them drive successful RPA outcomes. After all, if a client isn't savvy in a particular technology, how will they know if the services procured are worth it until it's too late? One suggestion to work around this risk is to rely on proven IT partners to assist in standing up RPA, or to find the right consultants based on previous results and not sales decks.

RPA is not worth it because it scares employees

If you’d think that the only group of employees that are scared of RPA's ability to cut jobs are business users that complete mundane tasks, then think again.

RPA’s promise to ‘reduce the need for mundane tasks’ can be understood by management as a threat to their employees’ livelihood that they feel responsible for, as well as a threat to management’s own jobs (if less employees are needed then there’s less room for growth or improving quality year over year), and as a threat to ancillary departments.

Consider for example that IT system administrators who are paid to create employee profiles in disparate systems (and to maintain updated records of access) may view RPA as a threat to their own jobs that they've worked very hard to achieve. It's these same administrators that RPA implementation success relies on.

Put simply, the idea of flying robots coming into ‘help out the little guy do less boring work’ is taken as a threat by most employees. I've spoken with business analysts that are threatened by process mining (which is offered by RPA vendors) because it reduces their value regarding process improvement discovery.

RPA also threatens junior level developers since everything they’ve learned, such as setting up automation to scrape data, integrate disparate systems, and other tasks, can all be accomplished by ‘citizen developers’ and the likes that have never studied software development. Nevermind that the idea of citizen developers is a marketing idea utilized by RPA vendors, and that junior developers are actually better served to develop RPA solutions than traditional business users. As long as RPA scares employees, either through marketing that isn't well thought out or messaging from leadership that employees don't fully believe in, it will work against the goals that enterprises set in driving efficiencies through automation.

Footnote:

The term 'Robotic Process Automation' is used due to its popularity in the industry. Process automation is a clearer term that'll ideally replace 'RPA.'

This article was written when I was involved in the RPA industry as an IT manager. However, driving efficiency with RPA is something that I no longer undertake on a full-time basis. The full context for this message is detailed on the following page.

🖊️

Editor's note: This dilemma was observed during the authoring of Half a Dozen Robotic Process Automation Myths and has been published as its own article to allow for additional discourse.

Imagine that across a team of five employees there are five types of work. Each type requires 20% of the employees' time (or 8 hours a week). This scenario will serve as the basis for the remainder of the article to evaluate contingencies that may be missed in decision-making in the interest of increasing efficiency within an enterprise.

Consider that if 100% capacity is expected to be created through automation (20% is 8 hours * 5 is 40 hours), then it appears that the time freed for the remaining employees (light green 20% row) could be used to complete Ernesto's remaining work (dark green 20% column). One might even go so far as to implement automation, confirm the savings, and promptly provide Ernesto with a layoff letter based on this hypothesis.

Sounds great right?

Maybe... but there's a catch...

Consider if the entire team was already operating at 10% of overtime per week (10% of 40 hours, or 4 hours per individual). This little fact wasn't factored in before letting Ernesto go, but he's gone and anxiously figuring out where he can apply next.

In the real world, one might expect that overtime was factored in proactively but things don't always pan out like they do in textbook decision-making. In some cases it may even be decided that a team in this scenario wouldn't mind the additional pay if overtime is needed. A company might even consider that the overtime pay would remain the same but it would be able to reduce the cost of employing Ernesto - at which point 'employing a robot' is alluring and appears to be a better proposition than retaining a person.

What the previous perspective doesn't account for...

The individuals that were stretched thin to begin with now have to work more challenging activities (the dark green activities from Ernesto). Additionally, the four-person team must work one more hour of overtime per week (to collectively account for Ernesto's prior overtime).

The human implication of this scenario isn't great — especially for a team that was taking a half hour lunch instead of a full hour. Maybe that team was skipping lunch altogether to meet their workload. This is an hour that belongs to them and might have allowed the individuals to hit the gym, get lunch with a friend, or simply decompress. With Ernesto's layoff, each remaining team member will be required to put in an additional hour per week (which could very likely be on a Friday evening to catch up from constantly being behind).

If the remaining team experiences an event that pushes them to the limit (such as an incident) it wouldn't be a surprise for the company to receive a resignation notice.

In the scenario of a voluntary departure on a team of four, taking on the workload of 46 hours per week would require the remaining three teammates to work an additional three hours per day. The manager that was involved in the layoff of the first employee may even find themselves picking up the workload during their own lunch or evenings. This would further erode the manager's ability to support their team and improve quality on the variable processes that have a higher propensity for errors.

The reality is that it would have been more beneficial to upskill one of the employees, or confirm if one would like to work part-time, as a result of the automation than simply laying an individual off.

Another alternative would have been giving team members the responsibility of working on other tasks that add value to the business after automation frees time up for this - but they'd still be available if an incident occurred with the RPA process or if someone left the company and picking up additional work was required.

For argument's sake, suppose that it was possible to shift the work of five employees in this example to just four (while mitigating or avoiding all direct negative ramifications). If management is successful in this endeavor and an employee is laid off on a team of individuals that have each been there for longer than three years, that'll still have indirect consequences for future automation projects. Think about the message it sends.

🤔

Would employees trust executives the next time they're asked for input on automation opportunities? 

🙌🏾

Would the teammates feel confident in helping document processes (which may enable further automation)?

The chances of putting future automation at risk are greatest when the Enterprise Evaluation Dilemma isn't properly accounted for. One benefit could undo the hard work of an entire year's worth of effort — just through an impromptu knee-jerk reaction to save direct dollars regardless of the indirect outcomes.

Proper accounting requires a balanced perspective that keeps the employees in mind, as well as the business's effectiveness (doing what's desired), efficiency (producing more with less), and ethics (treating workers like stakeholders and not mere cogs that fill employment seats).

The Conclusion

If the fifth employee in the case discussed were to leave by choice, then there may be no need to rehire (as everyone else has been cross-trained and they're able to comfortably handle the workload that they've taken on). Enough time would have also passed to know whether operating with four people became possible or whether a replacement would still be optimal. In this way, automation could enable the long-term transformation of the company rather than a means to potentially over-steer in the short-term at the cost of downstream ramifications.

Realistically, an automation can break in a couple of hours, days, weeks, or months after it is implemented. Vendor changes made for security or licensing purposes can cause such a breakage that can last anywhere from days to weeks.

Anything could happen, and in a worst case scenario, having a reduced team without having contingencies in place could be detrimental to the business.

Taking the approach of not laying anyone off would establish trust within the company and guarantee that future automation opportunity identification would remain transparent between teammates and leadership.

Granted, this is a scenario with a limited view for illustrating the multi-faceted approach of decision-making that is required for a successful automation program. The perspectives in this scenario have been shared so that decision makers can remember the implications and weigh all the options before making a critical decision. In light of RPA vendors' pitch, it's important to factor the success of the busines sin the long-term over the intent of vendors' selling more licenses in the short-term.

The term 'Robotic Process Automation' is used due to its popularity in the industry. Process automation is a clearer term that'll ideally replace 'RPA.'

This article was written when I was involved in the RPA industry as an IT manager. However, driving efficiency with RPA is something that I no longer undertake on a full-time basis. The full context for this message is detailed on the following page.

Android robots that resemble humans closely, but not perfectly, can provoke negative feelings of dislike and eeriness in humans [aka the “Uncanny Valley” effect] (Mathur et al., 2020).

The sentiment of 'uncanniness' has unfortunately made its way to Robotic Process Automation (RPA) efforts. When people learn about RPA, they envision a physical robot being involved in keyboard presses, clicks, and so on.

Even after some time has passed, the 'robotic' part continues to throw stakeholders off and sow confusion. For example: 'even if it's not a physical bot, doesn't that mean that it may still become a bad actor that starts wrecking havoc on our systems?' This type of concern is valid, given that people are conditioned to not trust robots through various films, books, and other media.

RPA should simply be called ‘Process Automation’ or 'Digital Automation.' Robotic Process Automation makes sense in the scope of a fulfillment center which integrates process automation with physical robots. Even so, the physical automation industry refers to the technology as 'robotics' and leave it at that.

There's also an imperative for consultants to start referring to RPA as ‘Intelligent Process Automation;' especially given the growing integration between RPA and Artificial Intelligence. The term 'Intelligent Automation' (IA) leaves a lot to be desired as well since not everything is intelligent. Some bots are merely scripts and have nothing to do with AI.

Given the popularity of the term 'RPA' you'll see it sprinkled throughout to make this content more accessible.

Robots will replace people

Contractors that implement automation solutions often equate Full Time Equivalent savings in a manner that makes it easy to confuse with Full Time Employee savings. For example, if you automate 20% of five employees’ tasks, you end up with an ‘FTE of 1' for a given year.

This proclamation sounds great on sales pitches but doesn't pan out the same in the real world. As they say, 'the devil is in the details,' and if you want to understand the ramifications of this myth/oversimplification, you will benefit from reading The Enterprise Evaluation Dilemma.

Robots run all day, and that makes them great

Consider the study of Asatiani and Penttinen (2016) which states that ‘the promise of RPA is not only to reduce costs (since robots can work around the clock with no salary), but also to eliminate the problems with management and miscommunication...’

It's clear that even research writers have gotten wind of the ‘robots don't need a salary can work all day long’ idea — this is a big win for RPA vendors but also a big red herring for those considering automation solutions' pros and cons.

Most businesses prefer to limit robots’ operations to a specified time frame. Most robots couldn't run 24/7/365 because they would need to go down for maintenance. One might even argue that a bot has a ‘salary’ measured in the resources required to keep it running (and licensed). Nothing is truly ever 'free.'

Most companies also prefer to keep automation running during business hours. If something goes wrong during the day, then not only will customers or employees be more likely to notice, but it'll also get fixed during working hours.

Even employees can work around the clock, but doing so requires a greater investment in maintaining shifts and dealing with shift change-overs. Anything can run around the clock (be it machinery or servers) and the selling point of bots being able to do this is neat but not the end-all-be-all feature.

Don’t let myths impact your company's decision making!

Robots are just macros

Thinking about robots as macros is fit for purposes of understanding what robots are from a development perspective. However, stating that they are ‘just’ macros erodes the value of what RPA truly is.

Let’s consider something slightly unrelated to RPA ... there are languages out there created for software development that have no purpose other than to be esoteric. One of these languages is called 'Brainf**k' and is Turing complete (meaning that it can be used to simulate any Turing machine). However, the language isn't practical or fit for use — it was created was merely to be unique.

If one were to look at a language such as Python and C# and state that it is ‘just Turing complete’ it'd be incorrect to put these two languages in the same boat as Brainf**k. You decide for yourself by examining a code snippet that prints 'Hello World' using this esoteric language:

++++++++[>++++[>++>+++>+++>+<<<<-]>+>+>->>+[<]<-]>>.>---.+++++++..+++.>>.<-.<.+++.------.--------.>>+.>++.

And compare that to Python:

print("Hello World!")

In the same line of thinking, RPA does fulfill (at a fundamental level) the same type of activity that an Excel macro would. However, what makes it unique is that it can accomplish automation within other Windows applications, within browsers, and across VPN connections.

RPA also comes with full-fledged development suites which doesn't compare to any little macro tool.

A typical macro is difficult to scale dynamically out of the box (for example, the process starts running on one computer, but if volume increases, it spins up execution on 10 more servers). In contrast, companies such as Blue Prism and Automation Anywhere offer orchestration capabilities that can execute thousands of transactions and distribute them across machines. If something goes wrong, the transactions are retried, then the exceptions kick out to a person to handle or document the issue accordingly. All of this can be reported on and analytics can be used to identify exactly how long processes are taking to run, where there are hang-ups, and how much time has been saved compared to completing the work manually.

You can think of RPA as having some macro capabilities, but they aren't merely macros.

RPA development doesn’t require the IT department

The concept of ‘citizen developers’ has been around for a long time. It refers to the concept that employees who aren't traditionally trained in software engineering or IT can develop IT solutions (Definition of Citizen Developer — Gartner Information Technology Glossary, n.d.).

Many professionals have a gripe with this term as it is quite vague. There are no-code solutions, low-code solutions, and high-code solutions available for solving IT gaps. Being a developer, even in a no-code tool set, requires a certain amount of logic and programmatic thinking. Adding 'citizen' in front of it erodes the value one expects from a developer.

Given the existence of ‘CSS Developers' who write cascading style sheet markup, the industry should be able to refer to a 'citizen developer' properly as a ‘Jr. RPA Developer' - someone who uses mostly no-code or low-code tools to deliver value through RPA.

The terminology is important because it means that the same departments which manage software development would have to train, support, and coach Jr. RPA Developers. It would make it clearer that as much as RPA vendors want you to believe anyone can build RPA, it's just not scalable without meaningful training or IT oversight.

Even though a junior RPA developer may be able to deploy attended bots that run on users’ machines, they'd have a hard time deploying bots to servers for higher-volume tasks. By the point that orchestration is required, a need also emerges for a senior developer (or solution architect) to design RPA infrastructure. There's also emerges a need for IT resources to provision servers and credentials that a bot can use. Not to mention that a data team may be needed for storing RPA execution data for record retention, visualization, and other purposes.

The myth that a business user can easily be trained in RPA to automate their own mundane tasks, and that of coworkers, can be a slippery slope that leads to RPA implementation risks and failures.

RPA’s only benefit is cost reduction

If one were to look at RPA as being a driver for improvements which optimize the bottom line, that'd be true. It'd also be true for HR, Legal, and other departments. Dollar savings are a desired result of most businesses given that the goal is to generate as much revenue with as little expense as possible.

However, viewing RPA as an initiative to reduce costs narrows the opportunities available for augmenting businesses. For example, if it costs a lot of money to have employees on for incident management and they come in the next day disgruntled that they had to wake up in the middle of the night to work - you might consider the benefits of automation. In some businesses, RPA can handle basic resets, troubleshooting steps, or at least support those handling incidents in communications, logging, and other time-consuming tasks.

If automating the top 20% most repeatable incident activities helps reduce or improve 20–40% of the incident calls, then that'll literally help your employees sleep better at night. It'll also improve customer experience. Having less turnover from employees will make sure that those with the most knowledge will be more likely to stick around, which will also improve the customer experience. Less expenses on hiring, as well as higher renewal rates for customers, all lead to increased profits.

In other words, if you had an opportunity to automate a process but it'd cost 20% more to run it in an automated manner to receive 80% faster ticket resolution or 25% higher satisfaction, would you do it? If you’re in a competitive landscape where you’re fighting for market margin and your customers’ contracts are worth so much more than the cost of automating a process, you might do it even if within a specific department (such as operations) the direct cost appears to not exceed the benefits.

RPA initiatives are inexpensive

Although the cost of automation infrastructure and licensing may seem affordable to enterprises that have a solution-fit, there are other costs that need to be factored accordingly.

What often becomes prohibitive for companies is the consulting services often require to begin RPA initiatives (and sometimes to operate them). There’s also the investment required internally that spans from business analysts and end users' time, executives' time for governance, and much more.

Management will need to establish a proper RPA program with proper governance, organizational support, and a clear strategy for success. If companies choose to hire internally, there’s also the ramp-up time that needs to be considered.

For large enterprises with a plethora of processes that have a high-volume and are repeatable, chances are high that RPA initiatives can become profitable within a few years. Achieving profitability requires managing automation expenses effectively, tracking all benefits, and meeting goals that drive leading indicators.

If an RPA program initiative gets off on the wrong foot due to misunderstandings such as the ones propagated by the myths in this article, then it can become an expensive undertaking. If those issues aren't resolved promptly, the entire program might go belly up

Now that you've read some of the inherent challenges, remember that you have the power to keep these issues from manifesting within your own company.

Footnote:

The term 'Robotic Process Automation' is used due to its popularity in the industry. Process automation is a clearer term that'll ideally replace 'RPA.'

References:

Asatiani, A., & Penttinen, E. (2016). Turning robotic process automation into commercial success – Case OpusCapita. Journal of Information Technology Teaching Cases, 6(2), 67–74. https://doi.org/10.1057/jittc.2016.5

Definition of Citizen Developer - Gartner Information Technology Glossary. (n.d.). Gartner. https://www.gartner.com/en/information-technology/glossary/citizen-developer

Mathur, M. B., Reichling, D. B., Lunardini, F., Geminiani, A., Antonietti, A., Ruijten, P. a. M., Levitan, C. A., Nave, G., Manfredi, D., Bessette-Symons, B., Szuts, A., & Aczel, B. (2020). Uncanny but not confusing: Multisite study of perceptual category confusion in the Uncanny Valley. Computers in Human Behavior. https://doi.org/10.1016/j.chb.2019.08.029

This article was written when I was involved in the RPA industry as an IT manager. However, driving efficiency with RPA is something that I no longer undertake on a full-time basis. The full context for this message is detailed on the following page.

Peter Drucker was quoted as saying ‘there is nothing so useless as doing efficiently that which should not be done at all." His wisdom continues to ring true today as readers reflect on the fact that robotic process automation (a technology) can only be successful when founded upon a business's process improvement initiative.

This article will examine the challenges of RPA — those that your company must mitigate, avoid, or augment to benefit from automation. The second half will cover specific use cases for top industries benefiting from RPA.

What minimizes RPA benefits?

EY, a top consulting firm, has reported that they’ve seen anywhere from 30–50% of RPA projects fail (10 Common Pitfalls to Avoid When Delivering Robotic Process Automation Projects, 2017). Their experience shows that failure is a result of a lack of business partnerships with IT, Cyber, Risk, HR, and other lines of business. Not treating RPA as part of a change program also causes issues.

On the other hand, EY has seen that automating most of a process (say 70%) is enough to realize cost-effective benefits. If a company attempts to go all in on automating a process, including all scenarios no matter how variable they can be, that increases the chance of failure. The 80/20 rule is paramount to RPA as it is to other facets of business - in this industry you want to focus on automating 20% of the work that will drive 80% of the results.

Another mistake that companies early in their RPA journey can make is not fully scoping the investment needed for infrastructure and for RPA development resources. Simply because a business user can build a proof of concept doesn't mean that their automation can scale to a resilient ecosystem that is profitable. Resilient solutions are those with excellent up-time, are proactively checked for upgrades (to avoid incidents), and are supported effectively (to guarantee success throughout years of operation).

Companies benefit most from RPA when they treat automation as a program through governance, proper management, and nimble execution. In an ideal setting, RPA would be seen as another tool in the toolbox of automation which includes:

1. Integration solutions (IPAAS)

2. Vendor’s workflow products already in use by the company (such as those from Microsoft or Salesforce)

3. Other automation avenues including Python, APIs, and workflow orchestration (such as Airflow).

What types of Robotic Process Automation are out there?

RPA bots come in a variety of attended, unattended, or hybrid options.

Attended bots run on a user’s machine and help them perform work more efficiently. The user can watch the bot as well as pause it.

The downside is that the user's computer can't be used for anything else (unless a virtual machine is run which allows for the minimization of the environment the bot runs in).

Some applications, such as web browsers, can also be automated in the background without the need for virtual machines. Automating applications in the background of a user's machine is referred to 'picture in picture' by some RPA vendors.

Unattended bots run on servers and are triggered by events such as database updates, emails, or business users.

Hybrid bots are a mix of attended and unattended bots. For example, an attended bot started manually could trigger the start of an unattended bot.

Use cases for the insurance industry

The insurance industry is notorious for high volume work due to the hundreds of thousands of cases processed yearly. RPA is a perfect fit for helping employees spend less time on manual data entry, updating claims, and detecting fraud.

As an example, the decision making tables used for fraud patterns in the insurance industry require checking disparate systems to establish fraud scores (Verma & Ramakrishna Mani, 2013).

Even though a system may use regression analysis (through AI) to compute a final fraud score, it still needs the data to do so. Verma and Mani establish that such data is often fed through manual work that surfaces public records (spanning judgments, foreclosures, criminal records, and address change frequency).

RPA evolves the process of collecting and entering case information into a seamless and efficient experience. With all of this manual work out of the way, employees can focus on completing the tasks that require human creativity and judgment.

RPA use cases for manufacturing companies

Manufacturing companies rely on modern and legacy software to execute their processes. Legacy software is needed due to constraints ranging from interoperability with factory machinery (which can last decades) as well as the desire to keep production uptime as high as possible.

Thankfully, RPA implementations can help manufacturers with quoting, invoicing, and other manual operations. Manufacturers already use Agile, data analytics, and physical robots, which gives them an advantage over other industries that aren't as comfortable with robotics (Tilley, 2017).

Use cases for healthcare companies

RPA is a great solution for digitizing information found on accounts payable and paper documents used in a plethora of processs. The benefits of healthcare billing automation includes the improvement of revenue cycle times as well as a reduction in the manual labor required.

Hospital staff must complete mundane tasks such as keying in order data or moving information between systems. Automated healthcare processes enable staff to better serve patients, increase positive outcomes, and reduce cost (Ostdick, 2017b).

RPA use cases for the telecom industry

Telephone and communications companies deal in a high amount of support tickets. Here, RPA is used to automate manual tasks that support representatives must complete while on the phone with customers. Automation in this industry reduces average handling time (AHT) and helps increase customer satisfaction as well as employee moral.

The telecom industry is dependent on technology, but it's also dependent on paperwork. The industry's paperwork gets stored in a scanned format and requires various amounts of processing that leads to customer delays. Scanned data is also a challenge in maturing analytics programs since they require accurate and recent data (Ostdick, 2017a).

The integration of Robotic Process Automation with intelligent document processing makes it possible to transform paper records into digital information.

Use cases for retail companies

Retailers have exciting opportunities to automate manual data processing between point of sale systems, CRM systems, social media, and much more.

Better integrated retail data can be used to:

1. Determine whether there is enough inventory in store

2. Determine whether pricing is appropriate

3. Identify where there are opportunities for promotion

Other use cases for retail include automating invoices, customer support requests, and order processing. For example, automation can enhance the productivity of agents (allowing them to handle more calls or returns during peak periods).

RPA use cases for the public sector

RPA has experienced great success in the public sector. Consider for example that North Tyneside, in partnership with ENGIE, reduced the cycle time of processing new benefit claims from 36 days to 25 days — which represents a 31% reduction (Hazlegreaves, 2017).

Ending note on RPA and AI

One unfounded fear within the public sector and other industries is that automation is in of itself Artificial Intelligence (which comes with its own concerns).

The reality is that RPA actions and results are easy to trace through the workflows they're developed in. Artificial intelligence on the other hand uses algorithms which aren't often as transparent. While RPA has the potential to integrate with AI, it doesn't have to be combined in the industries where AI presents unsolved challenges.

Footnote:

The term 'Robotic Process Automation' is used due to its popularity in the industry. Process automation is a clearer term that'll ideally replace 'RPA.'

References

10 common pitfalls to avoid when delivering Robotic Process Automation projects. (2017, June 14). EY. https://www.ey.com/en_ee/financial-services-emeia/get-ready-for-robotic-process-automation

Hazlegreaves, S. (2017, December 15). Rise of the robots in the public sector. Open Access Government. https://www.openaccessgovernment.org/rise-robots-public-sector/40598/

Tilley, J. (2017, September 7). Automation, robotics, and the factory of the future. McKinsey & Company. https://www.mckinsey.com/capabilities/operations/our-insights/automation-robotics-and-the-factory-of-the-future

Verma, R., & Ramakrishna Mani, S. (2013, December). Using analytics for insurance fraud detection. The Digital Insurerr. https://www.the-digital-insurer.com/wp-content/uploads/2013/12/53-insurance-fraud-detection.pdf

This article was written when I was involved in the RPA industry as an IT manager. However, driving efficiency with RPA is something that I no longer undertake on a full-time basis. The full context for this message is detailed on the following page.

Robotic Process Automation (RPA) is a cutting-edge technology that allows knowledge workers to escape repetitive work. Put in other words, process automation ‘takes the robot out of the human.’

According to a survey by Redwood Software, nearly all organizations have their people completing repetitive tasks and 74% of them spend over a quarter of their time on such monotony (Ostdick, 2020).

The delegation of menial duties to automation enables employees to apply their skills in meaningful ways that create value. These are activities such as those which span engaging with patients in healthcare, analyzing market trends in finance, or supervising production floor performance in manufacturing.

Until RPA came about, companies had little choice but to have their workers manually key data into systems. Not only was this time-consuming, but it was mind-numbing as well. A perfect example is seen within the sales industry, where sellers spend a fifth of their time on CRM activities (Krogue, 2018).

The other option to menial software usage, before RPA, was to develop custom software or to implement integration platforms. IT departments could take years to implement these alternatives, or they may have never been automated at all.

The allure of RPA is that cycle times for automating mundane tasks are decreased to a matter of a few weeks or months.

The benefits of RPA are fully realized when integrated into a process improvement program — this is something explored further in How Can My Company Benefit From RPA?

What’s Robotic Process Automation from a business process perspective?

Trite as it may sound, Robotic Process Automation is a technology which enmeshes people, processes, and IT. This perspective is explored through the article for its benefits and limitations.

From a process modeling perspective, specifically the business process modeling and notation (BPMN) specification, there are three levels of processes.

The Descriptive Process Model

The first level is the descriptive process model, which describes how the business perceives the process from a high-level, for example:

1. Who’s involved?

2. What are their responsibilities?

3. When is the process completed?

4. Where does the process take place?

5. What is the scope of the work?

The Operational Process Model

The second level is known as the Analytic or Operational Process Model, which describes the process in greater detail to a specific audience. The audience might span a process engineer, an integration analyst, or a process improvement consultant.

At this level, there are also specific metrics that are tracked for individual process executions (i.e., transactions) as well as the process itself (a summary view).

The Executable Process Model

The third BPMN level is known as the Executable Process Model. This document serves as an agreement between the process analyst and the process engineer as to how the process will be executed. The level of detail at this stage makes it possible to develop a process, produce test cases, identify room for improvement, provide context for metrics, and much more.

Business rules, in the form of tables or Decision-Making Notation, can compliment executable models as well. Executable process models may also reference the ingestion and storage of data required for execution (Business Process Incubator, 2015).

In the industry of RPA, process models and accompanying procedures are often documented in the ‘as-is’ state using Process Definition Documents (PDDs). PDDs are descriptive in nature. The proposed ‘to-be’ state is documented using a Solution Design Document (SDD), this describes the process from a technical automation prespective.

The RPA industry has shown that automation quality is enhanced when process models and planning are approached from a Business Process Management or Lean Six Sigma (rather than a mere PDD and SDD approach). It’s important to see it from a BPM perspective since RPA isn’t an end-all-be-all solution — it’s a technology that simply builds on Business Process Management.

Answering just how the process is completed today, and how it can be automated, is not enough to answer how the automation will impact the business, how it will enable other benefits, and how it will be maintained to deliver continuous value.

What’s RPA from a technology perspective?

Robotic Process Automation consists of two major components:

1. A software robot which imitates computer input (spanning mouse and keyboard movements for executing a process).

2. An orchestration mechanism that executes and checks the process as needed.

Some sources refer to RPA as being a subset of AI. While this may be true from isolated academic/technical perspectives, it’s important to not confuse RPA for AI.

The nuance is better understood as follows: the computer vision aspect of RPA’s ability to ‘view’ the screen is powered by AI ‘computer vision.’ However, the automation of interacting with those elements (including the logic and orchestration) is a subset of software engineering.

When RPA is combined with Artificial Intelligence which offers specialized cognitive capabilities, the resulting solution is called Intelligent Automation. Examples of cognitive capabilities include image detection, optical character recognition, and sentiment analysis. AI which processes unstructured information can compliment RPA, but that doesn’t mean that RPA is in of itself AI.

In other words, one can think of RPA as mimicking the steps one would take to complete a process using well-established steps and rules. AI on the other hand, can process massive amounts of data to determine which process it should complete or how certain information should be classified, handled, or generated.

What’s RPA from a people’s perspective?

RPA can be considered a threat to people and this can lead to employee anxiety. The fear of robots taking over one’s job can also lead to automation project failure because of direct or indirect resistance.

To contrast the human fear of losing a job, against the reality of the matter, one would consider that there are many methods of automation available for companies to use. CRMs, ERPs, and financial systems provide numerous opportunities for automation by including workflow capabilities (such as in Salesforce) and system connectors that remove the need for manual data entry.

The point is that automation opportunities are numerous and should be seen as an avenue to advance rather than something to fear. If employees cling too much to the old way of doing things, i.e. getting paid to move information from one system into another without any value add, there is no guarantee that their company won’t become the next Blockbuster.

It’s the responsibility of leaders to remind their people that innovation is inevitably a marker of success and that stagnation is a marker of failure.

In the short-term, some jobs may become redundant. For example, if a department acts as a cost center (in the case of a managed customer service provider) then a 20% savings through automation of mundane tasks could result in downsizing. That’s no different than self-checkout registers requiring retailers to employ fewer staff.

The reality is that for many businesses using RPA, employees with a tenure can take on work that’s more meaningful and variable. When a company is presented with the option of upskilling a reliable employee to become more valuable, they’ll often take that option instead of letting them go. Or at least that’s how it ought to happen for a company that’s figured out where they stand regarding the Enterprise Evaluation Dilemma.

From a people perspective, automating tasks that are boring and offer no job fulfillment allows individuals to lean into their creative side*. It also allows employees to focus on improving the business rather than dealing with an increasing amount of drudgery when they could be upskilling or connecting with customers more.

🧂

*A note should be made that not all additional work people take on because of automation is more enjoyable. Simply reducing the amount of repetitive tasks required for employees to complete does not gaurantee their management will provide more fulfilling activities as a result of automation.

Developing bots is easier than regular software, which means system administrators (who typically don’t produce new software) can make the jump into RPA should they be interested. Business users intent on making the switch to ‘BizDevOps’ also have a great opportunity in the emergence of RPA.

Footnote:

The term ‘Robotic Process Automation’ is used due to its popularity in the industry. Process automation is a clearer term that’ll ideally replace ‘RPA.’

References:

Business Process Incubator. (2015, October 22). BPMN Process Model – Descriptive, Analytic (Operational) to Executable. BPI - the Destination for Everything Process Related. https://www.businessprocessincubator.com/content/bpmn-process-model-descriptive-analytic-operational-to-executable/

Krogue, K. (2018, January 10). Why Sales Reps Spend Less Than 36% Of Time Selling (And Less Than 18% In CRM). Forbes. https://www.forbes.com/sites/kenkrogue/2018/01/10/why-sales-reps-spend-less-than-36-of-time-selling-and-less-than-18-in-crm/?sh=7bbbf7a4b998