I have been working in the Robotics Process Automation(RPA) space for the past 18 months. In this blog post I aim to capture my observations and learnings of my RPA journey so far.
The first step of the journey begins with identification of the right set of processes to automate. So which processes do we select as candidates for RPA?
Selection of candidate processes for RPA
Processes lined up for RPA show the following characteristics:-
- ‘Swivel Chair’ work
‘Swivel Chair’ work is essentially working on multiple applications to achieve a business outcome/take a task to a successful conclusion. For a claim adjudication, the service representative will probably interact with a call recording system to accept and close a call, imaging system to retrieve/update/store claim documentation, an administration system to adjudicate the claim and Customer Relationship Management(CRM) to capture customer interaction/action taken notes.
- Data Entry
A lot of labour force is dedicated to digitizing data. The data is received in multiple formats (csv, excel, document pdf etc) via multitude of channels (mail, email, fax etc) and needs to be keyed in to organisation’s standard format before it can be taken up for downstream business processing.
All organisations need some kind of reconciliation routines. They could be as mundane as checking if all tasks submitted in the morning have been acted upon or all financial transactions as reported by intermediary/broker etc are reconciled to the client accounts. Such routines could run daily, hourly, monthly and require a dedicated human force to run and validate the run outcomes.
Structured data/machine readable
A key element for achieving a successful RPA implementation is to ensure that all data points/inputs relevant for automation are captured in structured data format. The data needs to be machine readable. In case any input data is unstructured, processes need to be put in place to convert unstructured data into structured. Typically images or text are the input or starting point of the process. Unless the image or text is in a standardised format, it is difficult to extract processing data points. Separate human intervention is required to digitize this portion of the process.
The process logic needs to be rules based. The correlation between the input data, business processing rules and the outcome or decision should be translatable to something like a decision table. There should not be any need for any human judgement or intuition.
Some of the applications involved in the process under automation are legacy. It is difficult to find lower environments for testing and also creating test data appropriate for testing is a challenge. Care should be taken to ensure that environment and production grade data is available for testing.
Volumes & Complexity
The next key element the process needs to meet is volumes. A process might meet all the above mentioned process behavioural criteria but might have very low volumes. RPA tooling costs $$, hence to achieve ROI we need to have adequate daily volumes to justify our initial investments and subsequent maintenance costs.
As the degree of complexity of automation increases, even if the process remains rules oriented, the investment cost in implementing and running the automation goes up, in turn negatively affecting the expected Return Of Investment(ROI). One needs to take a step back and evaluate if it makes sense to automate such a complex process.
The complexity of work to volumes trade-off which is well captured in the following table.
If the work is not too complex, decision/adjudication rules are well-defined and unambiguous; volumes are high, it is a very suitable case for RPA. Work of low complexity and low volumes typically continue to remain manual as the ROI is low. High complexity, low volume work remain with human SMEs. High complexity, high volume work might introduce scope for cognitive automation/processing as need to deal with ambiguity and human judgement increases.
We have identified candidate processes for RPA. We have determined that the processes have adequate volumes to sustain ROI. Now we actually need to validate and ensure the back of the envelope calculation is accurate.
The first thing to do is conduct a time and motion study of your business process. Identify the areas in the process flow which will be automated. Identify the current time spent by human worker in that activity and the potential savings that will be generated. Some processes are straight forward. For example, the reconciliation/data entry type of processes can be made human touch free and the operational efficiencies are easily measurable. The ‘swivel chair’ work on the other hand might not be simple. If the RPA is screen scrapping based, there is no performance difference as the robot is interacting with the same system which the human does. The only place where a robot potentially saves time is in the human thinking and action portion. Even here we tend to underestimate the efficiency of human workforce. Repetitiveness to the same set of actions over a period of time has made them very efficient. So with swivel chair work we need to do additional optimisation such as information consolidation from multiple collaborating applications and automation of application update.
RPA Implementation vs IT Implementation
There are some key fundamental differences between the way RPA implementations are done vis-a-vis IT implementations.
- RPA implementations are non-invasive. As a practice, there is no change done to the underlying applications. The interface remains unchanged. IT implementations spanning more than one application usually involves the need to create/expose APIs (Web Services/file based etc) so that the applications can communicate with each other.
- Process is running in production. Unlike IT implementations which are enhancement of functionality or involve developing new functionality, the process lined up for RPA is already in production albeit under human delivery. It is already functioning at 99.**% efficiency with 99.**% accuracy rate. So when we do put the RPA implementation in PROD it needs to function with the same if not better efficiency from day one. Unlike their human counterparts, the robots do not have the luxury of ramp up time.
- ‘Do not harm’. The RPA implementation is expected to be designed with care to ensure that it works as expected but more so that it does not generate unexpected outcomes. If an implementation is supposed to select ‘Approved’ in the drop down, it is fine if it selects the Approved value. It is fine if it does not select approved and fails, however it is unacceptable that it selects ‘Denied’ value.
- Shorter development lifecycle. RPA tooling vendors have oversold the promise that RPA development lifecycle is fast. Yes, RPA implementation is fast if all things such as requirements, ROI validation and ancillary requirements such as security and application/environment availability fall in place. However generally that is not true and getting all the ‘bells and whistles’ in place take time.
- Environment. Unlike IT which uses a secure protected PROD environment, by itself RPA uses the desktop environment. This environment is fragile and not designed grounds up for automation; human intervention is a norm. Unless a separate dedicated desktop environment is established or Server OS based environment created, the inherent instability of the Windows 7 desktop environment causes a lot of operations issues.
- Team Impact. Unlike IT implementations which augment business operations capacity and capability, RPA implementations are targeted to optimize man power. The RPA implementation has a direct impact on the operations team. As an implementer one needs to be cognizant of the fact and its impact on operations morale.
Authentication And Authorisation
Once you have decided to automate a particular process the next step is to create robotic userid and roles.
Let’s discuss the userid first. Do we create a functional/service userid or do we create a normal human like userid? From a convenience and replicability of existing processes it makes sense to create a normal human like userid. This id will need to be created in the organization’s active directory and all security repositories of collaborating applications which do not use active directory based authentication. This is where things get interesting. Typically active directory user id creation is part of employee onboarding process. So will the robot undergo an employee onboarding process? Will it be assigned a desk, a desktop/laptop, a salary? This might seem laughable but the onboarding processes are so aligned to expecting a human being as the end user, there is no concept of a virtual robotic user. You will find that your onboarding processes has SSN or parking lot slot as a mandatory column. The onboarding process needs a serious revisit to support a virtual robot worker onboarding. You might want to use some kind of a naming convention to differentiate between a human and robotic worker.
Next comes the role. To ensure adherence to ‘Least Access Privilege’ policy, one needs to ensure that we create a new role for the robotic userid. It would be easy to reuse a human role, but in a typical automation scenario we will only do automation of a portion of process. Hence reusing the human role will provide the robotic userid with privileges exceeding its requirements. Creating a new independent role ensures that we are only assigning the required privileges to the userid and auto enhancement of privileges by using a common role shared with human users is prevented.
The robotic userid will have a password expiry policy. So we will need to associate a human owner for the robotic userid. Enhancements will need to be made to existing password management methodology to support this paradigm.
All activities done by robotic userid should be traceable and auditable. The associated human owner of the robotic userid will be deemed accountable for all robotic activities. Given the sensitivities involved, it is prudent to ensure an appropriate human owner onboarding/offboarding process is in place to cover assignment changes or attrition.
The RPA automation cannot thrive in a standalone fashion. The RPA implementations need an entire ecosystem of components to support them.
They need a capability to support
Queuing – There a batch or lot of tasks to process via automation. A limited set of robots will process a large number of tasks. Queuing will help achieve request throttling.
Monitoring – The implementation will need monitoring of the RPA robotic infrastructure as well task monitoring and management.
Robot-Human handoff – In spite of best efforts, we will inevitably need human intervention. This could be under exceptional circumstances or as a part of the normal operational process flow
Environmental Robustness – Unlike production grade robust server environments, the robotic desktop environment is a normal human user environment where the expectation is that any environmental stability issues can be troubleshooted by the human user. Such an assumption has disastrous consequences for the robot. Care should be taken to ensure that the environment is made stable typically by creating a newer Windows 7 environment in Virtual desktop setup or if RPA tooling/desktop tooling supports using Windows Server.
Type of robot
RPA tooling supports two types of robots, one is assisted automation and second is unassisted automation.
Selection process is summarized via the following table
|Criteria||Assisted Automation||Unassisted Automation|
|Process Characteristics||Process is adhoc
human intervention / judgement necessary for process initiation
|Continous or schedule bound process|
|Volumes||Low, makes assigning dedicated robots cost ineffective||Large|
To summarize, RPA capability development is not a trivial affair. Developing robotic process automation expertise requires extensive planning, ROI validation and significant investment of time and efforts of dedicated cross-functional resources to achieve successful augmentation of RPA in your organization automation’s armory.