Optimise or Automate?
“Should you optimise first before you automate a process?”
This can be a bit of a “chicken or egg first” type of question that can arouse much heated discussion, but one of my favourites from process owners (oh, and it’s the chicken by the way).
This is a very common question we hear asked and debated frequently. At the risk of answering a question with another question this early in the article, but it depends on whether and why a process is such a perfect candidate for automation in the first place. For example, if I was to ask a process performer or owner this question, the answer is usually, because they don’t wish to perform it manually any longer. Although it might be a little more complicated than this in reality, there’s really no better reason than this for automation of a process.
We Must Optimise First!…Not Automate…Right?
However, the question or the problem remain: “Don’t we need to optimise and improve the process first, there’s no point automating a bad or broken process!”
This statement often leaves the most durable process performers wondering where this zest for improvement was for the past ten years they’ve been complaining about this dreadful system and terrible process they’ve had to contend with.
But let’s bear the question out…does the optimisation question have merit? Should we optimise a process before we automate? Let’s consider the options.
What Difference Does RPA Make?
The good news is that the very nature of RPA actually lends itself to doing both…at the same time. And the two don’t necessarily have to be different outcomes with a different pathway.
In this humble writer’s 25+ years of transformation and business leadership experience, I’ve found that it’s not only possible, but the most likely scenario in practice and the one which you should be adopting within your RPA framework as standard practice!
A successful RPA programme will consistently strive to help improve existing processes and nurture a culture of continuous improvement. However, a slightly different mindset might be needed, underpinned by a simple, clearly defined framework.
What Does Optimise Really Mean?
The field of process improvement has seen its share of new initiatives over the last 20+ years, such as Lean and Six Sigma, and this article is NOT going to delve into those in any detail, but at the heart and core of these techniques is fundamentally the desire to improve and optimise. However, what is optimisation really?
Isn’t it just making the best out of the situation with the systems and resources you have available to you? Isn’t it just about maximising usefulness and value, within the constraints and confines that you’re faced with?
RPA is most beneficial when used to improve processes iteratively, whereby we begin with a limited scope of just a few steps automated first, “As-Is” to begin with. Then the scope is expanded, steps are eliminated, small tweaks are made, and new automation-only steps are incorporated until you have something that’s as close to perfection as you need to get. And this approach is so successful with RPA, because of the speed of which RPA can be developed and deployed – much faster and more agile than more traditional automation techniques.
Reasons To Automate
There are plenty of real obstacles to process optimisation techniques:
- The first and most obvious, is the time and effort that it can take, depending on the process and the approach used. If resources are constrained (and they usually are), nothing of substance happens quickly enough, and if optimising a process were that simple it would have been done already. In practice, an automation can be designed and delivered and the manual work of a process eliminated, long before the optimisation work has even finished.
- Then there’s the cost to optimise, which might be too high in comparison to the benefit. If a process is important enough, the benefit would mostly justify the expense, but the real world isn’t always this black and white. The reality is ending up with dozens of processes, all slightly sub-optimal, but too expensive to fix, that people “get used to” and “put up with”, but which cause delays and lead to poor service.
- Next issue, is that traditionally, optimisation requires the help and support of expert IT resources, who typically have a long list of other initiatives to work on and prioritise. Because a robust and scalable RPA solution can be deployed so much quicker at the User Interface level to an existing process “As-Is”, this can solve a lot of issues very effectively, and buy the operational teams time to devote to optimised thinking in the long run.
- Then there’s the change aspects of optimisation. As humans, we generally don’t respond that well to change – we find comfort in our routines and habits. Some people are going to be reluctant or resistant to change, and will be less than keen to spend several hours of their time redesigning a process that in their eyes disadvantages them, or worse still, makes part of their job redundant! Chances are that they’ve also “been here before, got the t-shirt, coffee mug and soft squeezy stress toy to prove it, and nothing has ever changed!” These are the folks who say, “If it ain’t broke, don’t fix it.”
- The next pitfall with optimisation is that, if you’ve convened a team of optimisation experts, there’s a risk of optimisation for optimisation’s sake. Not to say that this isn’t a risk with RPA too, but if automation goals and targets are simply embedded into everyone’s day-to-day routines and targets in balance with broader operational objectives, there’s a reduced chance of this.
- A common mistake is optimising a process without expert knowledge of how a “To-Be” automated solution could actually work best, or worse still, optimising a process based on how it’s performed manually, can be a total waste of time. If you’re going to optimise, make sure you include your RPA experts, so you don’t spend time designing and implementing changes that are only disregarded and disposed of when the automation design phase begins.
- And finally, there’s the question of who takes charge of the process optimisation – the business, IT, someone else? RPA is an incredible tool for democratising process optimisation for most effective results – after all, the people who spend 8-10 hours a day, 5 days a week, 52 weeks a year, are probably the best people to advise and define how it works and is automated.
Don’t Choose, Don’t Delay! Automate & Optimise
With a robust RPA Framework in place, setting out with the aim to automate a process first can be the most successful approach in practice. Either by fixing the obvious problems first and eliminating unnecessary manual effort or by redesigning the process to be optimal for automated operation (or both), you can achieve more successful results overall, although I’m sure many will disagree with this advice.
The question of whether to optimise or automate is older than RPA technology itself, and there’ll always be plenty of reasons to do one over another. Although I’m not suggesting that optimisation should never be considered, you must do so taking the a modern and effective RPA system in place and ask yourself the following question if in doubt:
- First, is there an overarching constraint that you believe makes automation non-viable, such as technical, financial, people or customer related constraints?
- If not, then estimate the time, effort and cost required to optimise and automate.
- If the latter is sufficiently faster or cheaper or derives benefit which more than compensates, then plan your automation.
However, if you decide instead that optimisation is the “right” path to follow first, please beware ending up with a list of processes that you believe must all be optimised first, or you’ll be right back to square one yet again! Remember: Perfection is an illusion!
Other Relevant Reading: