RPA: re-engineer first, really?

A question that clients ask often is “should we re-engineer our processes before we implement RPA or automate the processes “as-is” if they exhibit sufficient potential?” It is fair to say that most consultants extol the virtue of some re-engineering while most clients initially ignore it and rush into finding the “low hanging fruit” to show early successes to their internal stakeholders.

Vargha Moayed, Chief Strategy Officer UiPath

Indeed, early successes and low hanging fruit are often the price to pay in large organizations to be able to continue “playing” and obtaining the greenlight to further fund an RPA program. So, in that sense the “automate as-is” school of thought serves a purpose. However, there is no doubt that RPA is the ideal technology to embark on the “last mile” of process re-engineering for those who have already implemented some lean/six sigma program. For those who have not it provides a great opportunity to perform process re-engineering.

Despite years of lean practice, most clients have not fully harmonized or optimized their processes. Consider the case of a client that had created a global shared service center for back office functions with the help of consultants. When the RPA project started, the head of the center was convinced that their processes were standardized (e.g. the same process for order-to-cash regardless of the location served) optimized and, of course, well documented.

To his surprise they discovered that at the keystroke level the processes were far from being harmonized. Literally almost every country served by the center was processing order-to-cash somewhat differently. Further, the processes were not necessarily optimized, and as expected the documentation (if up to date) was largely going only to level 3 or 4 (processes can be documented from the highest level – 1 to the most detailed level – level 5 to 6). 

This client case is not unusual. Organizations spanning multiple geographic zones often divide processes into geographic subregions. Sometimes regionally splitting up processes is done for good reasons, whereas other times it is done for the wrong reasons. An example of a good reason to divide the process is when various countries have different legislations or requirements that make the division necessary.

On the other hand, segregating processes because it has always been done this way doesn’t withstand sound evaluation. Furthermore, clients sometimes fail to optimize their processes because they don’t fully understand the impact that the technology will have. Finally documenting processes beyond level 3 or 4 is a painful task that has had until now no real return on investment.

For the above mentioned reasons it’s important to involve experienced process consultants when embarking upon an RPA project. Launching an RPA project provides a great opportunity to truly re-engineer a process. It requires an intimate knowledge of a process at the keystroke level. By not involving experienced process consultants during the RPA project clients desiring to automate might miss the forest for the trees. One may fail to realize how the process connects with the bigger picture when they choose to automate in detail a sub-process or task “as-is”.

RPA can trigger indeed several levels of process re-engineering. At the simplest level it can drive forward the standardization of a process. Let’s take for example the order-to-cash process mentioned above. For an unstandardized process you might have employees working for one country’s process doing additional steps than employees working on a different country’s process. While doing an additional step may seem counterintuitive it can also add value to the process. A person may be reluctant to doing a new step for the sake of standardization, but a robot will do it, essentially standardizing the processes.

Beyond standardization, a first level of optimization can also be performed as some steps are no longer necessary with automation; for instance the “four eye principle” simply doesn’t need to be performed, because robots do not make human errors!

RPA can also sometimes allow for a second level of optimization. Often a larger process has been split between departments because of confidentiality or segregation of duty reasons, or between countries for cost optimization purposes.

RPA allows us to rethink these processes in a more holistic way. For instance, the on-boarding process of new employees is often choppy and sliced between multiple departments each of them with sub-processes. This has been historically the case in part due to the confidentiality of some personal data that could be accessed by HR professionals only. Hence other departments involved in the on-boarding of an employee (e.g. IT, security) had to wait for the HR department to create first an employee ID before proceeding further. But because robots are not capable of gossip, the entire process can be viewed as one. A 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.

Similarly, to optimize cost many global companies have moved some of their back-office processes offshore. But, doing so, they have sometimes split a process between on-premise and offshore locations based on skills or compliance guidelines. Moving to an RPA-driven automation some of these separations may be no longer necessary, because a robot cannot be unduly influenced and is more cost effective even than an offshore location.

As we can see with these examples above, it is important to simultaneously understand how to rethink a process as well as to know the capabilities offered by an RPA tool. Returning to our initial question of whether to re-engineer a process first or not, my advice is to actually do it simultaneously.

It is equally inefficient to re-engineer a process not knowing the possibilities offered by RPA as 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 re-engineering and then automating. Whereas in the second case, by automating “as-is” one misses the opportunity to drive efficiency further, potentially leading 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 as this is a new tool that will allow them to take their trade to the next level.

A new era has arrived, let us call it “Lean RPA.” 

You can connect with Vargha Moayed on LinkedIn.