Process first or automation first?

I see myself as a process person. With a lean and six-sigma background, I have spent a career strategising around processes, building processes and fixing processes to be as efficient as possible. However, the pragmatist in me struggles with a traditional process view when it comes to automation.

In the age of RPA, process excellence teams are finding their feet on how to combine the opportunity to automate with the opportunity to reduce waste, inefficiencies and the ineffectiveness of a process. In particular, should we:

a. automate an inefficient process

b. improve the process before automation to remove the inefficiency

or

c. attempt to do both at the same time.

There is a commonly held belief in organisations that ‘process inefficiencies should be fixed prior to automation’. This needs to be challenged.

Before the introduction of Robotic Process Automation, I could understand this philosophy and have adopted it in many projects. Previously, automation initiatives were long and drawn out and there was a definite need to optimise the business case through process fixes prior to automating. It was also the right approach most of the time, as it was quicker to fix a process than to automate.

Now though, one needs to have a pragmatic view on efficiency, capacity release and automation. I would agree that if a process is not achieving the end goal, then that process certainly needs to be re-engineered prior to automation. I would also agree that if a process is generating errors, then also those errors need to be removed prior to automation - a robot is very talented in performing errors at a faster speed and at greater volumes than a human!

But that leaves a wide range of processes, that achieve the end goal, do not make any errors but include a number of steps that are not necessary or could be engineered to work better.

Take a recent example from a global oil and gas company we are working with. An inefficient Finance process had taken four days to work through manually. In the space of an eight-week sprint of robotic automation, this was reduced to forty-five minutes with minimal changes to the process.

This released the capacity of the individuals performing the work, and saved a significant amount of human effort (not to mention frustration). At the outset, we calculated that we could release another twenty percent capacity saving through further process efficiencies. However that nine minutes was not material enough to warrant the time that it would have taken to make the enhancements to the process.

Rather than blindly following a “process first approach”, if you find that the process holds the right characteristics for being automated, it is worth asking the following ‘If – Then’ questions:

Is the process generating errors?

?? If so, then go through a process improvement exercise to eliminate the errors and reasons for poor quality prior to automation.

Does the process fail to achieve the objective?

?? If so, then go through a process improvement exercise to fix the issues prior to automation.

Does the process deliver the right outcome (even if it could be more efficient?)

?? If so, then release the human capacity early through robotic process automation.

Is the process efficient and effective?

?? If so, then consider automation to generate further returns.

Be pragmatic and consider the right approach based on the process, the outcome and the time required to make improvements. On many occasions that will lead you to automate first.