Abid Mustafa: Inside Robotic Process Automation

Abid Mustafa specializes in RPA, Robotics and Artificial Intelligence. He leads the Business Cognition and Excellence at Etisalat, a leading telecoms operator in the MENA region.

Abid Mustafa: Sure, there is little doubt that Robotics Processes Automation (RPA) is extremely popular amongst technical savvy people. However, outside the technology realm, business users often struggle to understand RPA and its applicability to solve business problems.

There are three major reasons for this confusion, in my opinion:

The first reason is that RPA starts in IT departments.

When it comes to the implementation of RPA, the classical approach is the IT department takes over the lead while business users have little exposure to the technology – in the sense of development and hence deep understanding. The lack of acquaintance reinforces the perception that RPA is similar to other automation tools and solutions, which is the exclusive purview of IT. Subsequently, the onus on business users to explore and learn RPA dramatically diminishes. This is further compounded by the inability of technologists to effectively articulate the benefits of RPA and explain how it differs from system automation, which leads us to the second point, mainly:

The second reason is that business users do not understand the difference between RPA and system automation.

There is a lack of direct interaction with RPA, which causes business users to fail to understand the difference between that and system automation. To many business users, RPA is system automation and this typically means that users are required to specify business requirements, submit them to IT and, if one is “lucky”, the RPA solution will be delivered. To give a broader context: RPA was designed to overcome the delays in the conventional SDLC (Software Development Life Cycle) — business requirements capture to design and implement development of the solution by IT. This is because unlike system automation, RPA works with the user layer only, and mimics human behavior such as navigation, cut and paste, data entry, data extraction and so forth. To make it easier you can take a look at this illustration (Figure 1.0), which highlights the differences between RPA and system automation, and also points out the limitations of RPA – which can be overcome by a combination of Artificial Intelligence (AI) and RPA.

From experience, I can tell that once business users are able to grasp this reality, it becomes very easy for them to understand the applicability of RPA technology. Additionally, the technology is easy to use and this makes business users extremely adept at generating use cases. Yes, IT developers are still required, but having switched on business users identifying numerous use cases helps in the adoption of RPA technology and in the deployment of software robots.

And finally, the third reason is that RPA not only starts but stays in IT.

This fact puts off many business users from adopting the technology. The dangers of such organizational inertia fueled by the fear of “robots replacing jobs” will derail any RPA implementation. Hence, it is imperative for those responsible for RPA to overcome permanent barriers between business users and their technology partners. Breaking down organizational silos and effectively communicating RPA benefits to business users should become the mainstay of IT departments.

Well, briefly put, RPA implementations stand a good chance of success if business users are educated about RPA, understand its benefits and have a chance to play around with the technology. The latter point is especially relevant, as it provides business users the opportunity to see the difference between RPA and system automation, and comprehend the ease at which the technology can be applied. Consequently, it is incumbent upon senior executives to encourage CIOs to relinquish control of RPA and hand it over to business users. By doing so, RPA use cases driven by business users will usher in a golden period of RPA success and make the investment in the technology worthwhile. Of course, on the long term a Robotics Centre of Excellence (RCoE) should be the stretch aim, to facilitate internal business-technology interactions.

Again, from experience, leaving out all the formalities and frameworks to establish such a center, I could observe that the creation of a RCoE can be a daunting task. Being digital in nature, all too often the focus lies on wrong things, namely on resources and tools, where to focus should be on process, since tools and resources are plentiful and really good. In short, one does not need to reinvent the wheel. Larger organizations tend to gravitate towards a federated model of RCoEs—these are distributed centers of robotic excellence established in business functions like finance, HR, operations and so on—where IT relinquishes control over recording but maintains primacy over orchestration. The latter is intended to preserve the security of all deployed software robots, as well as to keep licensing costs to a minimum. Nevertheless, irrespective of the RCoE model adopted by organizations, it is always necessary to take a step back and look at the big picture prior to embarking on the robotics process automation (RPA) journey.

In short: business users possess abundance ingenuity to exploit software robots to replace human interface tasks with machines and they should be allowed to experiment as soon as possible. However, they have an uncanny ability to avoid necessary process changes that accompany this transformation. This is dangerous because if processes are left unchanged an additional layer of complexity is added, which makes RPA solutions in the long run more cumbersome to use. You could compare it to for example taking a shortcut when driving, only to realize that the road is under maintenance, a situation which will actually add time to your journey.

Another aspect is the fact that trying to circumvent system automation plans, which most of the larger companies have, also carries risks. There is little indication that the software development life cycle (SDLC) is about to disappear. SDLC, although perceived as cumbersome and slow, provides an important service to business users by delivering solutions that reduce the scope and magnitude of collective manual tasks.

Moreover, in some cases, SDLC can also eliminate laborious tasks altogether, if implemented the right way. Hence, it is important for business users to be conscious about new system functionality that is likely to make the software robots obsolete.

In a nutshell, striking the right balance from the use of RPA to solve immediate business challenges that require heavy manual tasks across several systems can help departments until SDLC can deliver the right solution to retire such robots or get them deployed in other areas.

For example, it is common for RPA solutions to be used in areas where users have to navigate between multiple screens. This makes perfect sense if a unified desktop solution is not in the automation pipeline. However, if it is then the benefits of RPA deployment against system automation have to be prudently weighed. In the quest for speedy workarounds to complex business processes, users should think twice about using RPA to make their lives easier. Any planned system automation will not only kill software robots but also erode savings gained through efficiencies.

For far too long, businesses were at the mercy of IT to deliver automation. The maturity of RPA technology has emancipated business users and made them less reliant on IT. Nonetheless, this does not mean that business users have a free hand or can adopt an irresponsible attitude towards RPA. Any recklessness is guaranteed to provide several excuses—duplication of effort, wastage of resources and time, and increased costs—for the CIO to rein in rogue RPA practices. It would be a great shame if such behavior caused business users to lose control of RPA and again become totally reliant on IT.

Fortunately, the growing popularity of RPA is prompting organizations to intensify their efforts to take the technology more seriously. This means organizations want to understand the overall return on investment (RoI) when adopting RPA.

Subsequently, at the business user level, every RPA demand request has to be justified by a business case. This is a tricky subject because the business case fundamentally depends upon the way the organization has set up its internal cost structures. For small organizations, both the capital and operational expenditures (Capex and Opex) associated with RPA reside within a single department like IT.

However, in large organizations the Capex investment usually lies with a single department—notably IT—whereas, the Opex for RPA implementation is distributed across several departments such as Business Ops, HR, Finance, IT and others. To make matters more complicated, the governance of the business case to release budgets to support RPA development is undertaken mainly by Finance. Hence, the complete business case for RPA implementation is a summation of demand side business cases plus the supply side of a business case. With a myriad of stakeholders involved in the business case, it is important to establish a clear picture about the business case submitted with every RPA request, the overall governance process and the costs involved at each stage.

In such organizations, supply side costs associated with RPA implementations are not considered. This usually involves reduction in budgeted Opex to either support RPA use cases or justify investment in establishing RCoE. In the absence of additional Opex budget, FTE savings (reduction in full time and contract staff) underpins the feasibility of both scenarios.

The best candidates for RPA demand requests are processes or tasks that experience high volumes, exhibit large processing times, and are dumb, meaning they feature a low intellectual content not requiring too much human intervention, and simple to execute. However, it is quite common to discover that some tasks are not suitable for RPA. A process has many activities and each activity can be further decomposed into a number of tasks (see graphics below – Figure 2.0). For instance, in a particular activity, only 60% might  be suitable for RPA implementation.

Well, after defining the target processes that should be automated and checking whether this is feasible or not, the next logical step—many times overseen by many businesses—is to define parameters that can assist in calculating the savings.

Parameters like volume of transaction (VoT), average handling times (AHT), and FTE costs should become the basic ingredients of the business case. Other parameters include error rate (ER) — how many transactions the robot will fail to handle — and the time spent on configuring the robot post deployment. We could go on about defining parameters for business cases, but this is a whole topic on its own.

Hence, after having defined the foregoing parameters, one is in a position to draft a business case. To illustrate the intricacies of an RPA business use case, let us take a fictitious example, which involves a telecoms company handling 200,000 complex business complaints annually with a staff of 100 FTEs. Each complaint takes an average of one hour to process. Here’s a table (see below – Figure 3.0) that explains what happens when RPA technology is introduced. In scenario A, RPA is only effective for 60% of the VoT, and still manages to fail on 10% of the complaints. There is no reduction in AHT, and the number of hours saved is 108,000, which equates to 54 FTEs.

In scenario B, the performance of RPA improves resulting in 158,400 hours saved. This is equivalent to 79 FTEs. Nonetheless, the AHT remains the same. For scenario C, AHT drops to 5mins, the number of hours saved are 13,333, which is roughly the same as 7 FTEs. In this scenario, the number of hours saved is misleading, as 79 FTEs have already been earmarked as savings from scenario B.

Hence, other parameters like customer satisfaction and accuracy are required to evaluate the overall RPA performance. Despite cutting the AHT by 55 minutes in scenario C, the complaints activity still requires 21 FTEs to handle 41,600 complaints (where AHT remains 1 hour and there is an extra activity of discovering why 1600 complaints failed).

The cost of RPA implementation needs to be added before the business case makes sense. This includes a one-time set up cost of the RPA platform (Capex) and an annual Opex, which includes license fees, cost for professional services and the cost of developers (in house FTEs). Subsequently, the complete business case will be a summation of business demand for RPA and IT RPA Implementation costs.

In short, devising business cases for RPA implementation is contingent on the organization’s internal cost structures. For RCoE’s to be effective in drafting business cases, they need to collaborate with different stakeholders and be aware of the IT costs associated with the RPA demand.