Scaling up Robotic Process Automation (RPA) adoption - part 1
RPA is a technology that allows anyone to configure software (robots) to emulate and integrate actions normally performed by humans interacting with digital systems to execute a business process. RPA is used to automate repetitive, routine, rule-based tasks so that individuals can focus on more critical business needs. In the last four years, approximately 10,000 companies invested in RPA. However, despite its popularity, enterprises continue to struggle in scaling up RPA adoption. A central factor relates to how automation candidates are identified and selected.
I get concerned that companies, as we all know, can automate a bad process (using ‘process’ loosely here). So, while it might be fairly easy to develop a bot for a given task, one might ask the question in the broader ‘process improvement’ sense as to whether they should even be DOING that task in the first place, and if are there some lean/other techniques that could be applied to the end to end process thus eliminating the need. Combining RPA with a solid process selection approach is the cornerstone of the RPA implementation at scale. In this blog series, we will focus on the process selection method and its importance.
The trap of top-down vs. bottom-up
There are two types of approaches in RPA, the bottom-up, and the top-down approach. In the former, the automation happens at the task level. In the latter, the automation happens at the end-to-end process level. Unfortunately, many companies have fallen into the trap of starting with one approach and sticking to it, without realizing the need for other approaches. This results in the inability to see any key benefits from using RPA at the enterprise level.
Some companies have justified this by saying that their business is unique and complicated. In reality, the “not so successful” story has nothing to do with how unique or complex a business is.
Example 1: in my recent interaction with a large insurance company, IT leadership claimed that RPA was unsuccessful because those involved did not understand their data. This is an incorrect diagnostic. The actual reason it failed is because the team focused on the task level and on technical challenges rather than looking at the entire process.
Example 2: In another example, a consultancy company's automated employee expense filing eliminated the time spent entering expense items into an ERP system. On average, it saved the “road warrior” traveling consultants 15 minutes per week. Nevertheless, while it did save time for the employees, the company did not realize the potential of automating their entire expense process (including approval), which could have resulted in reaping 4 times more benefits than they currently did. The company missed the opportunity because their approach was very task-oriented (bottom-up) instead of looking at the whole process (top-down).
To apply the top-down approach, they would have to look at the entire expense process, which would involve multiple functions (departments):
- Each employee’s department
- Back-office processing
- Payment processing.
The top-down approach is a bit challenging because there is no single process owner. It requires the collaboration of all departments (functions) to achieve its goal, especially when each department has its own priorities.
Start small — then move on
Experts recommend starting small before going big on RPA. To start small, many companies end up working on a proof of concept or proof of value. Experts also recommend starting with a very simple process, because it helps quickly achieve goals and showcase RPA's advantages to management. Most of the time, this results in picking up one of the repetitive routine tasks, which is simple but also has a decent ROI. As the POC/POV gets completed and achieves the desired outcome, the company decides to automate more processes and mostly concentrates on low-hanging fruit. With this move, however, the organization may get stuck with task-oriented automation as they realize the quick results.
Another aspect of bottom-up automation is a relatively newer concept called RPA democratizing, or the citizen model. Some RPA vendors, such as UiPath, have launched a no-code tool that can be used by any end-user (not IT) to automate their tasks by building a bot by themselves. This approach puts the power into the hands of the end-users. The outcomes of using bottom-up automation are smaller in nature and do not have a significant impact on the organization.
So which is better?
Does this mean the task-oriented approach (bottom-up) is then a bad strategy to start with RPA? Not necessarily.
Before we conclude that one of the approaches is better than other though, let’s look at both the approaches in detail in the next post.