Ready to Make Robotic Process Automation Happen? Read this First.

There’s certainly good reason to feel ready to make robotic process automation (RPA) happen. The technology can deliver on its promises and has been integrated into business service offerings by such companies as Cognizant, TCS, and Genpact. RPA benefits are real and impressive: 25-50% cost reductions, 200%+ more efficiency than FTEs, higher quality.  The past few years appear to have turned the automation decision from an “if” to a “when”. So what could go wrong? Read about a few things that could – and see if they look familiar.

Ten years ago, few people were aware of robotic software technology, which at that point was limited to screen-scraping tools, automation macros and scripts. Concurrently, there was wide recognition of maturing ERP and CRM system technology aimed at bringing automated processes and integrated data analytics to company operations and supply chains.

Looking back, a case can be made that prospects for robotic technology were underestimated at that time. It’s understandable. Screen-scraping reliability was imperfect, macros and scripts had limited capabilities, and everything required at least some familiarity with coding. What fan base it did have was overwhelmingly on the IT side of the house.

A case can also be made that, within the same timeframe, the disruptive potential for ERP and CRM technologies was overestimated. Granted, they have transformed business operations: from the use of data to the manner in which processes and supply chains are engineered, optimized and automated; the business world has been changed. But hopes were high for much more – particularly for enterprise-wide process and data flow integration. Unfortunately, that hasn’t happened.

 A landscape of technologies has emerged to address those unrealized integration dreams: BPM; Data Warehousing; Data Analytics/BI and Big Data. A common thread through all of these cures is that large scale deployments are needed to justify the big investments these technologies require.

A need for options to more large scale implementations created opportunities for newly developed robotic automation products - more capable, functional, and intuitive - and also orders of magnitude less expensive than the aforementioned technologies. Thus, we arrive at the not “if” but “when” mindset mentioned at the top of the post.

After all, what could go wrong?

Robotic Process Automation: Easy or Hard?

There are many things that could go wrong in a robotic software implementation – most of which are reasonably similar to missteps common to other types of software deployments. The type of ‘wrong’ addressed in this post is an error of such substance that it almost irrevocably dooms the implementation to failure. With robotic software, misunderstanding and/or underestimating the difficulty and effort required to automate business workflows is such an error.

This is not that same as saying robotic products are hard for non-technical business users to learn and use. What is means is that business processes vary widely in complexity and today’s top-tier RPA products are designed to automate across that range.

Three Words that make Automation Complex

Three words mark the difference between simple and complex process automation. The words are “if”, “then” and “or”.  They’re important because they introduce the elements of conditionality and flow control into the automation algorithm – aka, complexity.

Take for example, an agent assist process that pulls additional customer information onto a screen. The process rules could be rigid – database information is pulled onto a screen when DB names and existing screen names are exact matches. The process rules could be elastic. For example, if the last name is Brown, then DB information is pulled when the last name is an exact match or the variance is a last letter of “e” (Browne).

Business users can quickly learn to automate processes with rigid rules – often within a few days. They find it easy to use intuitive, Visio-like tools to turn their process expertise into a visual mapping of activity sequences. Meanwhile, behind the scenes and unknown to them, the RPA product is taking their sequence maps and generating the required robotic software automation code.

Highly conditional rules-driven workflows, on the other hand, require automation by business users with considerably more robotic software training. As a recent Harvard Business Review article stated, “Business operations people who have process and subject matter expertise but no programming experience can, with only a few weeks of training, start automating processes with RPA tools.” Although the language “only a few weeks” gives the impression of a quick & easy route to success, real-world BPO experience tells me that pulling people with “process and subject matter expertise” away from operations for several weeks is a very big deal.

Managing Capabilities and Expectations

Ideally, the processes targeted for early robotic process automation will have a large number of repetitive activities with tightly defined, unconditional rules. A recommended tactic for identifying and targeting ideal processes is to focus on activities that involve data: not data manipulation or transformation, but rather simple data movement.

Automating data movement is relatively easy for business users to learn and execute because those activities are generally repetitive and of a “from point A to point B” nature. For example, unconditional processing sequences which extract data from several databases and/or applications, or a manual transaction-based data migration from a sunset legacy system into a newly deployed application.  

To prevent an automation implementation from going wrong, early steps must be taken to define the nature of the processes to be automated, determine their likely complexity and determine if the user group has the capability – both in skill and time – to take on the implementation. Unless the group very clearly has the capability, then ways to supplement their resources – perhaps from IT bandwidth – need to be found.  If capacity is suspect and means to supplement it are not clear and committed, the project should be placed in abeyance until conditions are right. The risks of failure will be too high.

If capacity is good, then planning should continue as it would for any software implementation. However, because robotic process automation is relatively unknown, likely to be a new experience for all concerned – and often a threat to the very business users it will free from repetitious drudgery, a great deal of care should be given to setting proper expectations and conditions for success.

Training timelines should be elastic, early implementation milestones should be relatively easy to achieve, and automation benefits should be acknowledged but downplayed. Concerns over job losses from automation should be dealt with right up front – and with as many specific facts as can be mustered. Few valued employees enjoy drudgery or boredom. However, even fewer relish losing their jobs. Management should give careful thought as to how employee roles can change for the better once repetitive tasks are significantly reduced – before implementation planning begins. Belatedly releasing good news into a negative environment is a self-inflicted morale blow that should never be allowed to happen.