How can I select the right processes for Robotic Process Automation (RPA)?

Identifying the right processes is critical to the success of any RPA project.  According automation market, the poor choice of a process for the initial pilot is the number one cause of implementation failures. In this article, we will provide guidance and advice to ensure your robotics process automation (RPA) journey is successful.

What types of processes should I choose?

RPA is best suited to highly manual and repetitive activities. Typical task examples include: data entry, reconciliation, data transfer, report generation, data processing, archiving, and data mapping. Within financial services specifically, everyday use cases include: client onboarding, mortgage approvals, invoice processing, loan processing, account opening and closing, trade execution.

Focus your attention in the following areas:

• Rule-based decisions: no human judgment/decision making. Decisions are rule-based and logical, thus able to be depicted on a decision tree.
• Digital data inputs: printed, scanned, PDF, handwritten or paper documents are unsuitable as these are non-digital inputs (however such processes are compatible with more advanced intelligent automation technologies such as machine learning, OCR, etc.)
• Structured data: contains structured data and structured inputs such as templates and stable databases
• Highly repetitive and stable: based on a standardized, repeatable process)

The following is a list of areas to consider when evaluating RPA opportunities:

• Invoice Processing
• Sales Order
• Accounting Reconciliation
• ERP Data Entry
• System Queries
• Payroll / Human Resources
• Employee Onboarding
• User Termination

Once you have selected your candidates, the next decision point is how to shortlist and prioritize them.

Because RPA technology isn’t suited for all processes, candidates must be evaluated against attributes that showcase RPA’s key strengths. A quick and simple way to create a robust process pipeline is to utilize a scoring mechanism that objectively rates how well each process candidate fits the attribute.  (consider a candidate rating system using the range of 1-5.   One being the least likely for automation and five being most suitable for automation)

• Rule-Based: Tasks that have clear instructions for how they are processed and that use clearly identified and predictive business rules are great candidates for automation. Those that do not conform to this attribute likely require more human judgment and greater use of exception scenarios, making them not ideal for RPA technology. For processes that are mixed or heavily judgment-based, consider applying other improvement methods first (LEAN, Six Sigma) before applying RPA.
• Structured, Readable Input:  Processes that pull standardized and structured electronic data sets are more straightforward to automate than those that don’t. Bots have a much easier time reading from Excel spreadsheets, Word documents, emails, presentations, and PDF files than from scanned documents or even manually inputted documents. Not only are electronic inputs preferred, but they also should be standardized. Processes that are triggered by inputs that vary are not ideal candidates.
• Standardized, Low Exception: Tasks that have clear instructions for how they are processed and that use clearly identified and predictive business rules are great candidates for automation. Those that do not conform to this attribute likely require more human judgment and greater use of exception scenarios, making them not ideal for RPA technology.
• High volume: Processes that have a high frequency of occurrence, as well as high-transaction volumes, are ideal candidates for RPA as the technology will significantly reduce (or, in most cases, eliminate) human error involved with manually processing the sheer volume. Reducing error also reduces risk.
• High Error Rates: High-volume, manual processes are prone to high error rates, usually resulting in rework that could be reduced or eliminated with RPA technology.
• Manual Re-keying:  Processes that require the re-keying of data across multiple systems are ideal candidates for RPA technology.
• Unchanging Processing Methods: Processes whose methods will change in the short term (or frequently) are not good candidates for RPA technology. Instead, look for processes that remain stable and consistent in their methodology, architecture, and inputs.
• Low Process Adherence:  While processes may be standard on paper, resources may not always adhere to them as closely as intended. Processes that are not followed, especially those involving internal or external controls, make great RPA candidates.
• System Changes:  Due to the cost involved, if automating a process would result in significant system changes, it may not be as a good a candidate as one that requires fewer system changes or integrations.
• Customer Satisfaction:  Processes that more greatly affect customer satisfaction are better candidates than those that have little or no impact.

Once processes have been assessed, they can be ranked by total score, with those scoring the highest put at the top of the list for automation, resulting in a backlog of process candidates for the RPA-development team. While the above is an extensive list of attributes to consider, each organization may add it’s own based on the nature of its business and strategic imperatives. Once a process has been selected, a business case should be built that more accurately reflects the potential benefits of its automation.

It’s important to note that automating a process generally requires it to be optimized for automation.

A business analyst may need to re-engineer the process to take advantage of the technology’s capabilities, as doing so may uncover other potential RPA pitfalls that must first be addressed before the process can be fully automated.

One of the biggest lessons learned from RPA implementations is to start small and build gradually. Before embarking on a large-scale program, start with a proof of concept (POC) or pilot. When selecting a pilot, it is crucial to begin with a small, low complexity process. That is often a sub-part of a more extensive procedure, therefore drastically increasing your chances of success. Successful delivery of a POC or pilot will prove the viability of the technology and help to secure buy-in from the organization.