Traditional workflow automation typically automates a task in the backend using programming and application interfaces. They also use dedicated scripting tools and languages. Contrarily, robotic process automation or RPA automates tasks by watching the user perform the job in a graphical user interface.
RPA can lower the entry barrier for automation in industries that typically do not use or have application programming interfaces (APIs). Much like a human worker, RPA is a metaphor for a robotic instance with its workstation.
The advantages of RPA include cost reduction and an increase in throughput. However, while RPA sounds promising, it is not an apt fit for all processes. RPA often requires assistance from human counterparts and is not an autonomous exercise. With the advent of AI and NLP, this may change very soon.
In this three-part series we see optimal ways to approach a typical RPA project. In this post, we take a look at some of the must-ask questions for RPA qualification and to judge if RPA will yield substantial returns on a specific process.
RPA qualification for rule-based versus judgment based (cognitive) processes
In the current evolution cycle of RPA tools, rules-based processes are more apt for RPA. Software robots are not as competent as a human worker in handling unexpected situations or making judgment-based decisions.
Standard selection criteria follow the “Rule of Five” heuristic provided by Forrester,
- No more than five decisions
- At the most five applications
- No more than 500 clicks
RPA would typically deliver high returns when the process is repetitive and can be automated to free human time.
Structured or unstructured inputs to the processes
Structured inputs are highly defined, have a very low margin of variation, and exist between a range. Unstructured data is the exact opposite of this. Here data is free-ranging and does not have a defined process through which it originates.
For example, hand-written invoices, faxes, or documents have an unstructured data component that needs to be handled by humans. Additionally, if the input to the process is free-flowing text, it might be challenging for a robot to take that forward.
Processes that work with standardized structured data sets are easier to automate. Software bots are adept at reading data from text files, word documents, spreadsheets, etc. than deciphering a hand-written PDF document. Processes that are triggered by varying inputs are not ideal candidates for automation using RPA.
Integration options – UI vs. API
RPA is less useful in applications that work with data that is fed and accessed using APIs. The real value of RPA is where there is a multitude of applications (homegrown, legacy, and new) that use human workers to integrate workflows across these applications.
While RPA is not an integration technology, it often acts as a middle ground between manual processes and API-based applications.
RPA based ‘integration’ has low time-to-market, is relatively affordable and easy to maintain. On the other hand, API-driven applications are expensive to build, have a steep learning curve, but have high scalability. Each option has its own merits and demerits, and each method needs careful consideration.
Process validation
Processes that contain defined validations make great RPA candidates. For example, a payroll process worker may access systems that track attendance, leaves, overtime, employee levels, etc. based on these inputs, the worker would then use a set formula to arrive at the pay that rolls out for a specific duration. These kinds of processes have a defined validation that does not change very often and are excellent candidates for RPA.
RPA qualification based on process usage frequency
If a specific process runs very often, then RPA can significantly offer better ROI on its initial investment. Processes that have low error rates and are unchanging for long durations can dramatically benefit from RPA.
With high frequency occurring processes RPA can significantly reduce human error and offer better success rates.
Standardized vs. exception-based processes
While RPA can automate multiple use cases and rules-based exceptions, their immediate value lies in automating standard processes with little to no exception rates. More straightforward, standard processes often are quicker to develop and have a shorter time-to-ROI.
Application/process stability
RPA is most useful in a stable environment where processes and applications do not incur frequent changes. Automating a process that is changing every day is a waste of time because developers need to spend a lot of time maintaining them. RPA is not capable of automating tasks that are highly unstable & non-standardized because they cannot be easily defined. Hence stable processes are always good candidates for RPA automation.
Prioritizing
High-value RPA processes can be identified based on the following criteria,
Understand complexity factors & calculate the complexity level
- Number of screens involved in a process act as a proxy for the number of steps
- Type of applications
- Variations/scenarios within the process
- Structured and standard inputs
- Free texts
Calculate automation potential
- Manual and repetitive processes
- Rule-based processes
- Structured and standard inputs used in processes
- High volume processes
- Processes are manual and laborious tasks
- Jobs that exist out of regular working hours
- High compliance processes
Map business benefits
- Cost savings
- Productivity gains
- Customer satisfaction
- Business agility
- Error reduction
- Flexibility
Map the processes into quadrants
Processes that can be automated using RPA need to be identified carefully for their successful implementation. RPA qualification criterion helps prioritize the defined process with the highest “business value” and the lowest effort.If you like this post, here are a few more you may find interesting,
