Companies considering RPA installations as part of a digital transformation will not simply take a leap of faith on such a huge potential investment–nor should they. Running a proof of concept within your environment as a test of its effectiveness might be even more important for RPA than other technology because there will be so many more unknowns.
For a company making its first foray into RPA (or automation in general), questions about an RPA tool’s ease of use, on what processes it will be most effective, its performance and accuracy or a provider’s approach to best practices around documentation, configuration management, security, etc. can possibly be answered by engaging in a proof of concept (PoC).
Lay the Proper Foundation
But, designing a PoC that answers the questions your company needs answered to move on to a full-blown RPA project (to say nothing of choosing the provider you want to conduct the PoC with) requires some homework going in. To ensure a PoC truly reflects how RPA will work in your business environment, executive leadership must have clear answers to several questions. Why do you want to implement RPA? What do you want a PoC to demonstrate? Do you need to engage a consultant? Have you identified the right process? What resources do you need for the PoC and for any subsequent scaling? RPA can have significant returns if implemented properly. Having clear goals beforehand can result in a PoC that accurately reflects the benefits of RPA.
Humble Beginnings
Perhaps the most critical aspect of getting a proof of concept right for your business is identifying the right test case. Know the process you want to start with intimately: volume, complexity, maturity, documentation, risk, level of variation, availability of structured data, systems involved can help you qualify a process that is right for RPA. Simple processes with high transactional volume and good available measurements are optimal places to start.
[um_loggedin]
Another critical facet of designing a proof of concept is deciding whether or not to engage with a third party. Do you have the internal capabilities to test the technology. Newcomers to RPA should consider hiring someone with experience–both with the technology itself and with implementing it in other companies. The right consultant or partner can not only help initiate a proof of concept, but also can frame the other elements you will need to scale up, as well as build your internal capability through training and coaching. A technology agnostic partner can help you objectively assess RPA vendors and use cases.
Building it Out
If the planning has been comprehensive, you have identified a process that you and your team understands and can articulate from beginning to end. You have identified the subject matter experts within the organization and should be able to gather the requirements for an RPA test case quickly.
Now it’s time to choose the software. When initiating the assessment, consider the complexity of your IT environment, your application portfolio and the combination of legacy and new systems the bots will need to communicate with. Also consider if the interface is simple to use, whether the bots can be trained by non-IT employees and final cost of ownership.
Monitoring the Test and Interpreting Results
The point of the PoC is to put the results of the test in an apples-to-apples comparison with the process as it is. This is where the work you put in identifying the right process to test pays off. You should be testing PoC cases that have existing, complete data, the quality of which can be easily measured.
In most cases, the execution or actual development of the PoC takes 1-2 business days. Be sure to record the automation once the development of the PoC is complete so others can watch it as needed.
One of the greatest benefits of a PoC is that, once it is finished, you have a ready-made tool to show stakeholders how automation works in your environment. It is a way to build confidence and excitement for an enterprise-wide automation program with little investment.
[/um_loggedin]
[um_loggedout]
[/um_loggedout]
