Vargha Moayed is Chief Strategy Officer at UiPath.
“Should we reengineer our processes before we implement Robotic Process Automation (RPA) or automate the processes ‘as-is’ if they have enough potential?”
That is a common question I hear from clients.
It is fair to say that most consultants extol the virtue of some reengineering. Most clients, at first, ignore their advice and rush into finding the low-hanging fruit to show early RPA successes to their internal stakeholders.
Indeed, early successes and low-hanging fruit are often the ‘price’ to pay in large organizations to be able to get the green light to further fund an RPA program. So, in that sense the ‘automate as-is’ school of thought serves a purpose.
But there is no doubt that RPA is the ideal technology to embark on the ‘last mile’ of process reengineering. Particularly for those who have already implemented some Lean Six Sigma methodology. And it is a great opportunity to perform process engineering for those who have not.
Despite years of lean practice, most clients have not fully harmonized or optimized their processes.
Consider the case of a client that created a global shared service center for back-office functions with the help of consultants. At the start of the RPA project, the head of the center was convinced their processes were:
- Standardized (e.g. the same process for order-to-cash regardless of the location served)
- Optimized
- Well documented
To his surprise, we discovered that (at the keystroke level) their processes were far from standardized. Almost every country served by the center was processing order-to-cash somewhat differently). We also discovered their processes were not necessarily optimized and, there was room for improvements to the documentation as well.
This client case is not unusual. Processes are often different for different regions. Sometimes the differences are for good reasons (e.g. because of different legislation in different countries) and sometimes for the wrong reasons (e.g. “we have always done it this way in our country”). Furthermore, the processes weren’t optimized. Finally, documenting the different processes beyond level three or four was a painful task that, previously, had no real return on investment.
Launching an RPA project provides a great opportunity to truly reengineer a process. RPA requires an intimate knowledge of a process as mentioned earlier at the key stroke level. There is a danger, however, in not involving experienced process consultants during the RPA project. The danger is that you’ll ‘miss the forest for the trees’ and automate a sub-process detail ‘as-is’ without realizing how it connects to the ‘bigger picture.’
RPA can trigger several levels of process reengineering. At the simplest level, RPA can push for the standardization of a process.
Unlike a human, a software robot doesn’t mind performing an ‘unnecessary’ step in the order-to-cash process just because the step exist when the same process is performed in another country.
Beyond process standardization, a first level of optimization can be performed as some steps are no longer necessary with automation.
RPA can also sometimes allow for a second level of optimization. Often a larger process has been split between departments due to confidentiality, segregation of duty reasons, or between countries for cost optimization purposes.
RPA allows organizations to rethink processes in a more holistic way. For instance, the process of onboarding new employees is often ‘choppy’ and split between multiple departments (each with their own process tasks). This has been historically the case due, in part, to the confidentiality of some personal data that could be only accessed by human resources (HR) professionals. So, other departments (such as IT and security) involved in the onboarding of a new employee had to wait for the HR department to first create an employee ID before proceeding further. When automating parts of the onboarding process, a software robot can tap into the HR database, and IT and security systems seamlessly. By doing so, the process becomes much more efficient and less error prone.
Related read: Using Downtime to Reimagine Your Recruiting and Onboarding Processes
Similarly, to optimize cost savings, many global companies have some of their back-office processes offshore. But, in doing so, they may end up splitting a process between on-premises and offshore locations (based on skills or compliance guidelines). By moving to an RPA-driven automation some of these separations may no longer be necessary because a robot cannot be unduly ‘influenced.’ And a software robot is often more cost effective than outsourcing processes to an offshore location.
As we can see with the examples above, it is important to simultaneously understand how to rethink a process and to know the capabilities offered by an RPA tool.
Simultaneously reengineer processes and deploy RPA
So, let’s go back to the question at the very beginning of this article and whether to reengineer a process first or not: my advice is to reengineer processes and deploy RPA simultaneously.
It is equally inefficient to reengineer a process while not knowing the possibilities offered by RPA as it is to automate a process ‘as-is.’ In the first instance, one might miss all the opportunities that automation offers and make the project unnecessarily lengthy by first reengineering and then automating. Whereas in the second case, by automating a process ‘as-is,’ one misses the opportunity to drive efficiency further. Missing that opportunity can lead to unnecessarily complex automation scripts that would have to be revisited down the road.
Consequently, it is paramount today that all Lean Six Sigma practitioners become RPA conversant because RPA is a newer tool that will allow them to take their trade to the next level.
A new era has arrived. Perhaps practitioners should call this new era ‘lean RPA.’
