RPA in the Fast Lane
In his second interview with Detecon, Abid Mustafa, the Head of the Business Cognition and Excellence at Etisalat, explains how Robotic Process Automation (RPA) projects should be approached and ways RPA can benefit businesses in the long run.
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.
The questions were asked by Dan Dimitriu,Senior Consultant at Detecon.
Why RPA Mandates Ambitious Targets
Detecon: Mr. Abid, we are happy to interview you again. After the last article, we had some questions coming in from our readers, which we wanted to further discuss with you, given your hands-on experience with RPA.
In the last article we discussed about the impact of RPA on an organization. Going now one step further, our readers wanted to know what is an effective way to essentially gauge the success of RPA, even at the start of their RPA journey?
Abid Mustafa: Generally, the advent of RPA technology has got various industries excited and organizations are keen to exploit it in the workplace. Interestingly enough, the adoption of RPA technology by organizations has also spawned a hotly contested debate about measuring the success of the technology. Some advocate metrics such as the reduction of average handling times and the saved hours, while others view robotized processes and the reduction in FTEs as effective metrics.
From the hands-on experience we have so far, it can be said without a doubt that these are effective measures. However, for organizations at the commencement of the RPA journey, the prime focus should be the number of use cases identified and their conversion into the number of robots. This is because the generation of viable use cases for RPA implementation is the basis of all metrics and KPIs. Without use cases, there would be no robots, and without robots, metrics such as the reduction of average handling time, hours saved and FTE reduction become meaningless. Many organizations trying RPA for the first time do not put enough emphasis on this crucial step, creating a precarious basis for measuring RPA success, which that usually leads to the wrong conclusions.
Could you briefly explain how organizations could come up with the right RPA use cases?
First and foremost, we need to clarify something: namely that, identifying RPA use cases is a completely different process than the one employed for the discovery of use cases for system automation. When defining RPA use cases, this needs to be clear to every party involved. Now, system automation use cases, such as changes to CRM and ERP applications, have much longer cycle times and require more effort in terms of requirements elucidation, governance, and management, from IT assessment to deployment. RPA use cases—from inception to deployment—usually, based on my experience, have a much shorter life cycle, of typically 4 to 6 weeks compared to system automation, which can take from 6 months to 2 years. Hence, the criteria used to assess the suitability of RPA use cases is also different from the one used for the evaluation of system automation use cases. Characteristics such as: large volume of transactions (VoT), long handling times (LHT), critical choke points and dumb processes form the essential basis for RPA use case selection.
Moreover, the combination of shorter time to deployment and relatively simple use cases assessment criteria means that target setting is a continuously evolving picture – think of a truly agile development. What I mean by this: many organizations discover in the beginning that the number of software robots needed is of just a few, but after a while, the expansion in RPA deployment assumes exponential growth. This is unlike system automation, where the correlation between use case identification and solution deployment is linear for example business requirements translate into specific system changes.
That was an interesting insight. To go deeper in the issue, how can organizations make sure that they define relevant RPA use cases?
At the commencement of the RPA journey, it is important for organizations and managers to set aspirational targets— a certain number of use cases to cover a certain number of robots deployed, man hours saved etc. — that challenges business users to identify a huge number of use cases (the more the better). This is important because not all use cases will translate into a software robot, and if not enough cases are identified, one might come to the wrong conclusion that no software robots are needed. In fact, and as proven by several real-life implementations, one has to trawl througha large number of use cases to produce a small number of robots (i.e you have 20 uses cases, several steps are common, hence you create a synthesis robot for that). Thus, as business users grow accustomed to RPA technology, the ratio between use cases and robots deployed will invariably increase. Obviously, and this is another discussion, a mature process environment driven by structured data will greatly help in RPA use case generation and software robot deployment, as this minimizes process changes and repeated reconfiguration of robots. Business ecosystems that are contingent on unstructured data such as pdfs, jpeg files etc. will usually struggle to achieve targets.
From my personal observation I can say that given the exponential growth of RPA deployments, organizations should expect to quickly meet aspirational targets such as the number of use cases and the number of deployed robots. Once the aspirational targets are met, they should be revised upwards; and then, other metrics such as number of transactions performed by robots, FTE reduction, LHT reduction, hours saved, and so forth can be introduced to drive the next wave of robotization— by converting use cases into software bots. As a cautionary note, not every use case translates into robots and this could be due to a variety reasons such as poor VoT leading to a weak business case, technical feasibility issues or simply system automation making RPA redundant. Hence, the greater the number of use cases identified, the better is the translation into software bots.
By approaching target setting in this manner, organizations learn vital skills in identifying suitable RPA use cases and translating them into effective software robots. Hence, keeping target settings restricted to a couple of simple metrics will pay dividends in meeting the organization’s RPA ambitions.
Now that we understand what some of the potential pitfalls when designing RPA use cases are, how can we accelerate RPA implementation?
Well, like with any new technology, it takes time for business benefits to accrue. RPA is no exception in this department. However, unlike other technologies, RPA promises to deliver business benefits fairly quickly – atypical cycle is 4 to 6 weeks. The ease of designing robots and the avoidance of making deep system changes, as discussed in the previous questions, and the circumvention of integration with back end systems via APIs has made deployment much faster. Yet despite this, organizations seem to struggle with the time it takes to identify use cases and translate them into deployable software robots.
Now, this is something many may wonder, why do you think organizations struggle to identify use cases?
A major reason for this is that most organizations fail to make the necessary structural changes to support rapid RPA deployment. Organizations still prefer to work in archaic silo structures and this is an anathema to the agility required to support faster RPA deployments. For example, in Figure 1.0 you can see depicted the usual entrenched silos handling different activities.
Abid Mustafa: In a typical setting, as we all to know too well, RPA activities are undertaken sequentially in silos (see fig 1.0) and this prevents the communication and collaboration between different stakeholders from playing an effective role in accelerating RPA deployment. What do I mean by this is that business users define the RPA requirements, prioritize use cases and underwrite business cases. IT, on the other hand, assesses the technical suitability of use cases, designs and deploys robots. Meaningful collaboration takes place at two points: understanding the RPA requirements and user acceptance testing.
This waterfall approach to RPA implementation is exposed to constant misunderstandings between business expectations and what IT delivers, prone to lengthy delays and rebuffs ofRPA adoption. To overcome this perpetual source of frustration amongst various teams, organizations must adopt a more flexible approach to accelerate RPA implementation. Dual mode operation, devops, and the dynamic systems development method are some of the novel techniques that can offer organizations greater agility in rapidly expanding RPA implementation.
At the core of these methodologies lies an organizational structure that substitutes silos with permanent channels of communication and collaboration. Figure 2.0 shows how this model works and its impact on accelerating RPA implementation.
Can you elaborate more on this type of collaboration you propose?
Sure, in a nutshell, this new way of working ensures that at every activity of the RPA life cycle communication and collaboration happen continuously and not separately, between all the stakeholders. This should normally also lead to a compression of workspace (all team members should sit in the same office space) and time (no need to wait for responses from teams driven by internal OLAs), which ensures that use cases are rapidly identified and assessed for technical feasibility, errors are minimized during implementation, bugs detected in testing are resolved quickly, and all parties collaborate to make deployment issues non-existent. As all team members are available to resolve problems at each stage of the RPA life cycle, productivity is bound to increase. This is, of course, the ideal target picture. Usually, this is not possible because of deeper structural issues (i.e. business analyst is there for several projects and loses time trying to find time to meet members of all his projects, etc.) which we will not discuss now.
What would then be the solution for the “average” organization to tap into the correct approach explained before?
Well, the most important thing is that no organization is perfect and not panacea solution exists. Based on the hands-on experience we have and good practices we developed at Etisalat, we observed that organizations, regardless of their structural imperfections, can commit to making small (structural) changes to support the implementation of RPA on a project basis. What I can tell for sure is that they will not be disappointed with the results. We have employed such techniques many times and have succeeded in rapidly translating potential use cases into viable robots that yield, sometimes instantaneous business benefits. Apart from the business benefits, RPA adoption can have a powerful impact because organizational inertia and bureaucracy are kept to a minimum.
A question we get asked very often is how can RPA contribute to the digitization of an organization's operational capabilities. What are your thoughts on this?
The quest to digitize an organization’s operational capabilities demands agility, risk tolerance, acceptance of failure and innovation. It can be argued that innovation is the product of the first three organizational qualities, however, this would be an exaggeration. Actually, the most important element in producing operational efficiency is giving people more time to think, try out new ideas, fail and learn from their experiences. And here I challenge everyone who worked in operations to concur that time is forever in diminishing supply. In organizations embarking on the digitization journey, new operational traits like agility, risk tolerance, and acceptance of failure require time, but this time is needed for innovation to take root, mature and succeed. Coming back to RPA – until now, organizations have used Robotic Process Automation (RPA) to reduce costs, increase accuracy and reliability of process outputs, enhance customer experience and scale operations to meet growth. RPA is rarely used to foster a culture of innovation in operational departments.
Can you discuss a bit more about this aspect you mentioned last?
Sure! Mostly, operational departments are accustomed to creating workarounds to ensure KPIs are met and customers are happy. But workarounds are not healthy and add unnecessary layers of complexity to existing processes and systems. RPA can help. Despite this, some would contend that the ease of use of RPA encourages operational managers to produce even more workarounds without addressing root causes. There is little doubt that RPA is a double edge sword. Hence, operational managers can:
- manipulate RPA to create more workarounds and circumvent necessary processes reengineering/optimization and system automation work
- use RPA to give more time to operational staff to try new ideas on how to fix perennial problems
And here I can make an important note: the latter stipulates that the freed-up time accruing from temporary fixes should be dedicated to innovation.
To wrap up, the trouble is that many operational managers are hostages to bad habits, and once temporary fixes are in place, the staff is redirected to other operational chores. If handled properly, RPA can produce the right environment to stimulate operational innovation. For instance, in a call center environment, RPA can be used by the back office to temporarily reduce the average handling time (AHT). This reduction in AHT can provide more space to think about eliminating the need for manual intervention altogether and deploying a robot (after simplification of the process) that removes the need for the front office as well as the back office staff.
In conclusion, using RPA to provide more time for operational staff to fix longstanding issues or undertake work in a completely different way is a good way to foster innovation. Nonetheless, RPA’s success in cultivating innovation rests on operational managers encouraging staff to come up with temporary solutions and using the freed-up time to try new ideas. But the real question is: can operational managers change their habits to exploit RPA in order to instill innovation in the workforce?
Mr. Mustafa, thank you again for you time and the insightful discussion about RPA. We wish you all the best in your efforts in implementing RPA for your organization!