Learning the ropes of Robotic Process Automation (RPA)

Financial Services firms are constantly exploring transformation opportunities in these times of disruptive change. While several innovation and next-gen fintech ideas remain on the drawing board – jostling to get attention for business sponsorship and an implementable plan, Robotic Process Automation (RPA) is silently finding a well-carved place in back-office processes labyrinth of firms.

Afflicted with processing capabilities constraints and bottlenecks – resulting from challenges of legacy systems, lack of STP and data integration issues, RPA provides an effective way-out for process automation- without committing large IT investment budget and implementation timeline.

Besides bringing significant saving in manpower costs (by eliminating manual and repetitive efforts involved in operations), RPA promises huge potential to uplift process efficiency and reliability with reduced costs, errors and breakpoints.

What is RPA?

Robotic process automation in most simplistic terms involves usage of software tools that replicates human actions to interact with the user interface of a computer system or application to accomplish operational tasks.

To quote from the LSE Research Paper on The IT Function and Robotic Process Automation[i]:

RPA Software is ideally suited to replace humans for so called “swivel chair processes; processes where human task inputs from one set of systems (for example email), process those inputs using rules, and then enter the output into system of records (for example Enterprise Resource Planning systems).

Some of key characteristics of RPA solution could be summarized as: 

• RPA is a software solution which sits on top of existing systems without bringing any change in underlying systems.
• It accesses computer systems at the presentation layer – in the way a human interacts with systems (using login user id and password, and following the clicks/data inputs for queries and transactions).
• It does not store any data nor does it directly interact with business logic layers of applications.
• RPA solutions are typically deployed by business operations staff and require minimal involvement of IT.
• Some of the more advanced forms (also known as tertiary forms) of RPA solutions involve Cognitive Computing, intelligent automation, Machine learning, Natural Language Processing (NLP) and have capabilities to significantly enhance the processing capabilities with self-learning and adaptation mechanism.

What RPA does not promise?

• RPA is not to be construed as a solution or substitute for system integration and STP enablement issues.
• By any amount automation and within a sense of reasonable economic viability, RPA cannot substitute a human decision element (if the process involves human decision or intuitive inferences inputs).  For example, a good order verification of a legal certificate would ideally require a human eye view and verification of authenticity by touching the document.
• RPA benefit may be limited and incur additional recurring costs in a scenario of processes having less intensive manual efforts – e.g. replacing macro or other local tools (primarily to eliminate the risk of key resource or knowledge dependencies).
• While process orchestration (in conjunction with BPM or standalone) could be a feasible scenario, RPA is not necessarily an Enterprise wide solution.
• Self-adaptability or cognitive learning based RPA to deal with dynamic scenario and advanced human judgment requires strong tutoring capabilities (NLP and artificial intelligence).  It significantly affects economic viability, if business criticality of such process is less desirable.

Suitability: Which process is the right candidate?

The bigger question as to which process is most natural a fit for an RPA solution – well, there is no single conclusive view on the yardstick to be adopted.  By and large industry reckons that back-office processes with a high transaction volume, manual effort intensity and fragmented systems and processes, come closer in terms of RPA suitability and adoption.

Some of the key factors determining RPA suitability of a process have been summarized in the below diagram. It is worthwhile highlighting that each of the businesses would have their own set of processes, systems and technology specific intricacies.  A proper assessment of such factors would be a basic requisite for deciding RPA suitability of processes.  It would also help in formulating RPA implementation approach at a later stage.

Does any specific factor affect Business Case / Economic Viability?

There could be no simple cookbook approach for business case evaluation and it would require firm-specific assessment of involved cost heads and expected benefits. At the same time, some of below highlighted factors would require a close analysis:

• Commercial terms and licensing: While common industry terminology and standards are yet to evolve, each solution vendor may have their own implementation methodology, toolkit, technology stack as well as commercial terms. To arrive at a comparable level of cost-benefit analysis, it is important to clearly understand the commercial terms being applied by a vendor for a robot license and its scope.  It can be applied at a varying level of usage: (a) as a part of single function within a process (b) multiple functions within a process (c) single or multiple functions for across multiple processes within enterprise.
• SME/Architect efforts and Testing: As in the case of any other software solution implementation, it would require active participation of SME and technical/data architects during design and implementation stages.  Also, suitable provisioning for environment and data-set up set-up for testing would be a basic prerequisite.  Accordingly, the above resources and efforts should be factored in as a part of overall implementation costs.
• Maintenance and Enhancements: RPA once implemented is not a fixed permanent solution. Like any other software solution, it would require re-configuration and adaptation to incorporate any new change/adjustments in the process flow. Accordingly, costs involved in maintenance over lifetime would be a required reckoning, besides factoring for periodic licensing costs and other infrastructure costs involved.
• Payback Period/ROI: At the stages of economic viability/business case evaluation, Pay-back period (or ROI) for some of the processes may not appear favorable in immediate term (say 2 years or less).  However, the same proposition would appear an attractive case, if the evaluation period is broadened to 3 years or above or a phased implementation approach is considered.
• Reusability and extensibility: When reusability and extensibility factors are considered during economic viability evaluation- i.e. a robot identified for a particular process can be reused or extended for a process having similar workflow characteristics, it can substantially improve the ROI profile.  It would be desirable to make a realistic assessment of reusability reckoning process specific nuances.  Applying heuristic approach may give a false sense of higher usability/extensibility, thus recognizing unrealistic business benefits.

What are the key implementation issues?

RPA implementation is expected to bring positive outcomes to organizations, if suitably planned.  Some of the below highlighted issues would require suitable analysis and careful planning for RPA implementation program, to mitigate any negative effects.

• Human effect: RPA directly influences the working pattern and job profile of involved employees. Before implementation of RPA, organization need to carefully communicate about changed set-up and re-organized role profiles. It requires planning for suitable training, up-skilling and re-deployment opportunities, in case a role becomes absolutely redundant. In absence of a proper plan and continuous communication, it may affect employee engagement level and overall loyalty and retention.
• Process Optimization/Simplification: Adoption of RPA without much analysis and exploring possibilities of process optimization and simplification (e.g. structured form/message in place of unstructured text or re-organizing the process steps to eliminate extra steps) can have limited benefits. Likewise, RPA cannot bring effective outcome, if system or data integration issues create hurdle in smooth processing.
• New Exceptions and Workflow Configuration: RPA is largely expected to enhance efficiency by smoothening the process flow and reduce the process breakpoints. At the same time, few expected scenarios should be suitably planned to avoid new surprises or unfavorable outcome:

1. New failure/exception points: New exception queue handling and configuration of workflow control should be designed to deal with process scenario not handled by RPA. It may require deployment of resources to review and resolve such RPA exception issues and re-submit to the workflow.
2. Common sense situation: Considering the fact many of operational scenario is not well-documented or based on basic common sense steps, RPA may not be able to handle those situation (like passing documents to other team member’s desk or calling someone across the desk to get inputs).
3. Bottleneck: Turnaround time for RPA based processing gets significantly reduced. In a situation of process generates exceptions or requires specific manual inputs, it would create a situation of large piling up with remainder of process remaining stuck for intervention. In non-RPA scenario, such unbalanced processing were less expected considering higher turnaround time at upstream steps.
4. Accumulation of errors: If RPA rules configuration and outcome is not thoroughly verified at different process steps, there is possibility of it keep adding to errors. It leads to a complex situation of error accumulating or spawning to further upstream/downstream errors.

• Progressive process control: An untested (unbridled) control to RPA at early stages of implementation may lead to scenario of unexpected or erroneous process outcome, involving costly resolution recourse. It would require a progressive approach for allowing full process control to RPA – i.e. at early stages manual verification and intervention is maintained at discrete process steps. As confidence of process outcome is realized, level of control is removed in a phased manner.
• Technology homogeneity: At the early stage of due-diligence and solution evaluation, if proper assessment of technology stack of the solution involved vs. enterprise technology stack has not been performed, it may bring the issue of managing heterogeneous technology stack and ensuing issues of new licensing and ongoing maintenance requirements.

[i] The Outsourcing Unit Working Research Paper Series – Paper 15/05 (Oct 2015) – The London School of Economics and Political Science

Read more by Indra Chourasia, here