There’s a growing consensus that robotic process automation (RPA) is an emerging technology with authentic promise of delivering significant cost, performance and scalability benefits by automating business processes. What’s less clear is how prospective customers can make the best decision in evaluating and selecting a RPA vendor. This guide is the first in a series designed to provide practical guidance for making that choice.
There are two essential evaluation areas for selecting an RPA vendor: product and company. The most important – product, is dealt with in this post. Company evaluation criteria will be addressed in an upcoming post. The product is a logical starting point for vendor selection because the best vendor in the world can’t compensate for software that’s ill-suited for a customer’s needs.
A guiding principal for product evaluation is this: robotic software should not only execute repetitive, rules-based, processes at a fraction of historical costs, it should also be capable of rapid implementation and smooth integration with other systems and applications - keeping organizational and technological disruption to a minimum.
5 Essential Features for RPA Products
Easy & Effective User Experience: users should be able to graphically create process automation with a tool set tha
t works with seamless integration, allowing business users to intuitively and graphically capture process steps without a hint of coding. The toolset should include:
Designer Screen: this is the ‘canvas’ upon which process steps are documented..
Tool Ribbon: a logical layout of tool icons around the Designer Screen.
Action Recorder: effortlessly watches & records the user’s process steps.
Drag & Drop: enabling the user to also drag and drop activities onto the designer screen.
Wizards: used for point & click deployment of ready-to-go actions and events.
Productive & Versatile Developer Experience: while the business user may able to configure automation without using code, the configuration itself is based upon code - a good robotic product is simply generating it out of the business user's sight; under the hood, so to speak. In order for a developer to extend that generated code and support complex automation possibilities, the product should provide him with these core capabilities.
Pre-build integration with major software products: for example, SAP, Siebel and SalesForce.com.
Wide range of supported input – including: email; text; xls files; scanned documents and screen-scraping.
Wide range of supported outputs – including: email; sms; xls; ppt and pdf.
Active developer community: such a community is invaluable for support, knowledge and innovation.
Scalability: after the robotic software has been configured and successfully tested for process automation, the product should support a rapid replication of the configuration across other machines. Such capability allows for quick and flexibility scalability. In certain operational situations, business units have met process volume requirements by deploying up to hundreds of robots - then going back down to dozens. A reputable product should have the capability and track record for this functionality.
Analytics: a robust RPA product must be more than robotic software that runs processes perfectly and scales almost effortlessly. It must also be designed to collect specific workflow metrics for analysis of how processes, activities and data interfaces can be optimized for even better operational performance.
Training: the product should come with a broad choice of training options, including: computer-based training (e.g. webinars, one-on-one demos, videos); classroom; online documentation (e.g. tutorials, best practices, release notes, testing guides).
When a robotic software product has features and capabilities that meet - and exceed - its time to look for the next key characteristic of a good product:
References: this essential checkpoint in the evaluation process should be done by two people in the evaluation group - one representing the business user side of product functionality and the other the technical side. Your organization will have to decide on the relative weight to place on both types of reference outcomes, but neglecting either would be a serious lapse in due diligence.
There should be also be at least three references so that the product lifecycle will be well represented: one reference should be in the process of implementation; the other within a year of implementation and an active user; the third an active user with more than a year of experience. Having this broad range of referenced product experience - from both the business and technical perspective - will go a long way towards creating the level of comfort needed for the software purchase.
The product looks good - what about the company behind it?