RPA – Why Proof of Value (PoV) scores over Proof of Concept (PoC)

For any technology adoption, a proof of concept is the usual approach to evaluate the usefulness and effectiveness of the technology. However, RPA is a different ball game altogether. The conventional proof of concept approach does not work because in most cases it is not even clear what needs to be proved.
The unknowns in any RPA roll-out

• Ease of use of the RPA tool?
• Does this tool work with the applications that need to be automated? RPA tools are very finicky, and sometimes even the most straightforward looking automation needs are hard to accomplish.
• What’s the performance and accuracy?
• Is it enterprise grade? What’s the approach to technology best practices around documentation, version control, peer reviews, testing, release and configuration management, security, auditing, etc.?
• Will it work in the environment where it needs to be deployed?
• Will it scale?
• Will it seamlessly fit in the company’s processes – release, change management, deployment, support? What changes are needed to the processes?
• Are the company’s processes standardized enough to start RPA journey?
• What do the employees feel about automation of their tasks?

Of the many questions posed here, a typical RPA PoC only addresses only the first question. An irrelevant question that usually gets an incorrect answer as well. At the end of all these PoCs, the bot created is nothing more than a demoware, which fades from the memory quickly.

A case for proof of value in RPA
Organizations must ask a question like whether there is a business case for automation and will it deliver the scale of improvements the company wants to achieve and can that be accomplished with a PoC? Organizations embarking on RPA journey should also look at the proof of value rather than just PoC.
Proof of Value tries takes a holistic look while evaluating RPA. It tries to answer questions such as:

1. Organization readiness for change; the impact of RPA and how to deal with it?
2. Would the business processes need to be re-engineered before the introduction of RPA?
3. What governance structure and controls that needs to be put in place to ensure the success of the initial deployment and how to scale the roll-out.
4. And of course, is the technology giving the promised ROI, it’s strengths and weaknesses.

A well-done PoV will help build a strategy to get support from top management for prioritizing this transformation for successful RPA adoption.

How to perform an RPA PoV?
The prove the value of RPA, we need to choose a real-life business process which has just enough technology and organizational complexity that provides an ideal test bed. But not enough to kill the project even before it gets started.
A process involving a complex technology stack. If the process is suitable for considering RPA, then RPA should be able to work with all the technical stacks involved. Starting small and identifying the right cases is critical in making effective RPA business case.
Some characteristics of a good PoV process:

• Business processes which are well understood and documented.
• The process should involve multiple business units to check the organizational dynamics.
• The process should have a good number of business rules and data quality issue.
• Processes where test data and the environment is available.
• The process could be performance sensitive which is noncritical and has – either high volumes or substantial effort. It’s important to be able to take the bot live without much risk.

During the entire development, deployment and production phase make copious notes of what went right and what did not meet expectations. It’s better to have a realistic picture and understanding of what are the limitations of the organization, process, technology, and governance now. This will help plan for the large-scale adoption of RPA.

Hitesh Sarda-Vice President – Banking and Financial Services@YASH Technologies

• Delivering RPA Pilot
• POC
• proof of concept robotic proc