RPA : Don't count your Bots before they're hatched

Robotic Process Automation can deliver significant process improvement and cost optimization benefits to the organisations but on the other hand there are a lot of failed RPA projects with very less or no value-add to the business processes when the risk associated are not taken into account at the correct time. Things could go wrong at any stage during RPA implementation and one missing link can have a cascading impact on the life-cycle of the implementation.

Think about these scenarios - Product sold but not implemented properly / Product implemented successfully but client is not able to monitor bots transactions properly / Bots Transactions can be monitored properly but a lot of issues or changes during support phase - So we can’t actually count the bots until they give us real benefit in terms of ROI.

The major reason for failure could be vendor issues or wrong tool selection or unrealistic expectations or lack of good strategy or not well defined scope or wrong priorities or over budget or lot of support issues or UI dependency or any other reason. So it is important to take care of the worst case scenarios before starting the RPA journey to ensure you are ready with both preventive and corrective actions and prepared for the risks associated with the implementation.

What can possibly go wrong and at what stage?

The Sales Side Risks:

Fear of Unknown: While introducing the RPA as a product or service to any client the biggest hurdle is the “Fear Of Unknown” as only few people would have expected:

• Robots Working in the same office
• Robots Sharing the same system with other users
• Robots Controlled and tracked along with other users

This can create a lot of resistance in client’s mind –sometimes to an extent of rejecting the proposal until the impact and feasibility is properly communicated.

Stakeholder identification: Like any other project , RPA can have both Positive and Negative Stakeholders – based on who is interested in cost reduction and who is willing to increase the FTE numbers. There will be impact on implementation if we fail to identify key stakeholders who are most powerful and having high Interest both positive and negative at very initial stage itself.

Organization Culture : Another important hurdle while introducing the RPA solution is organisation culture – Organisation level approach and Innovation practices has to flow from strong leadership with an objective of percolating the change to the lowest level of organisation otherwise process improvements like RPA can never be sold to any organization even if it is sold, the implementation will face a lot of resistance.

Don't count your Bots before they're hatched as the work is not over until the real impact on productivity is realized.

The Implementation Side Risks:

POC Process Identification: Pick up a simple process with less exception to start with – objective should be to :

• Introduce the working model
• Get acquaintance with the organisation Process and how the things going to be with full model
• Make the client comfortable with RPA and its possible impact
• If possible pick up the pain point in current process in order to show case maximum benefit to client – process which are consuming more time or FTEs but can be easily automated via RPA

Setting up wrong priorities with business: RPA should not be treated as solution to all problems in all domains because it is actually not. It has a magical impact in some of the issues for e.g. it can handle legacy system without APIs but it also has limitations that it can’t read unstructured data from unstructured formats (Though merging cognitive and AI could further improve the process)

Not focusing on major Business transactions and flow : Key business process should be targeted first to make sure RPA actual impact can be shown at early stage itself.

Exception identification: Process which cannot fit in the Rules needs special attention – they need to be moved to the exception box to be handled manually and if the volume is high then the time and money spent in maintenance of exceptional handling will eat up your ROI on RPA. Pareto Rule can help in answering the exception handling question but if we fail to focus majorly on the main business scenarios, a lot of time will be spent on making rules for transaction not impacting the final automation outcome. The focus should be to reduce all or maximum exceptions from the 20% transactions that are impacting 80% of the business flow

Technical Issues:

Platform Uniformity: Product developed on platform A and tested on B then deployed on C will obviously create a lot of problems – In case of RPA the UI, resolution, HTML attributes all should be considered uniform for the development, testing and production environment.

Unstructured Data and Legacy Systems – More unstructured data and more unsynchronized systems means more issues and exceptions after implementation This might lead to move automation percentage going much below client’s Expectations as well.

Either be prepared for the “worst case scenarios” or be prepared to become another “failed case study”.

The Support Side Risks:

Controlling: Another very important aspect to think about is a detailed view on what is the situation after deploying the robots - What volume is flowing through every transaction gate? What is the % of exceptions after deploying the robots and how many exceptions can be further reduced? Analysis of scale up and down will be available or not after implementation and moving forward what is the plan to build standard policies and governance with RPA COE.

Change Management: Any expected change and the cost of that change should be analysed and also clearly communicated so that the change management or change request conflicts post implementation can be avoided. For e.g. The design should be independent of UI changes or configuration changes as much as possible and client should be informed that if UI changes are done they should be ready to pay a change request cost

Reporting : The data generated after the transactions are created by bots should be available the same way as we have user reports for FTEs. Work performance reports should be considered as integral part of implementation.

Governance should be given equal importance as implementation to provide a better post implementation support to the client.

Every implementation is unique and thus it has unique risks associated with it - Please mention any other risk or precautions which I would have missed in this list that could help implementation teams and customers both.