How businesses should prioritise automation opportunities

How can organisations determine which processes are best for automation and which should remain handled manually?

It’s a great question. It’s very easy to get carried away when thinking about what automation can do, but it’s a very different question to say ‘What should we automate?’ And quite often we do see initiatives get off the ground and they may not necessarily be the exact opportunities that we, at Ten10, would target. Often they’re very ambitious, they focus on strategic, significant change whereas realistically, when investing in a new technology you want to focus on simplicity whilst also maintaining as large a return on investment as you can.

So we would always say:

1. Don’t get too far ahead of yourself.
2. What can we do that proves the technology?
3. What allows us to show the benefit to the business that we can get up and running in a short period of time (for example, a month) that will then allow us to use that as a catalyst to develop more processes in the future?

So it’s very important to try and focus on those simple processes initially. With that in mind, it’s also very important to set realistic expectations for what you want to achieve with automation. Sometimes, when speaking to business users, we will go in and say ‘We need to understand how much volume we expect this bot to process and what would an acceptable exception rate be?’ One of the best answers I’ve ever had is “We need a 0% exception rate” and it’s just not feasible. So although bots are designed to follow predetermined paths and, in theory, they will have a reduced error rate in comparison to human users, we still need to make realistic expectations on what we hope to achieve with this. Because it is software. Network interference, systems going down, and other blips, can all cause issues with automation.

Something to keep in mind is that once you begin to build an automated process, it is on rails. If the process goes down for any reason, you still need to be able to pull up a backup, whether that’s a human-managed process or something else that can still be performed manually. That’s something that a lot of companies do forget about.

The final thing that I would recommend thinking about is are there any self-service changes that can be made? For example, is there a new template or a new system that’s in use within the business that, if the team were to adopt it, would improve the efficiency in which those processes are run, rather than just automating them as they are done today? That’s always something that we challenge whenever we look at building new processes and sometimes we find that there are tools and capabilities within the business that exist today which would be a more effective form of efficiency improvement compared to automation.

Let’s assume now that an organisation has determined which processes it would like to automate. Maybe it only has a handful of four or five that it is hoping could prove the technology’s viability and be rolled out wider in the future. How should it approach prioritising those opportunities?

It’s very similar to any other form of software delivery. Ultimately our developers will produce bots. We would always look to work with the business to understand if there are any strategic drivers behind particular dates or desired deliveries. Quite often within our clients, particularly legal services, we have to automate ahead of specific regulatory deadlines. Those deadlines cannot be changed. The company may be relying on temporary staff and there needs to be a strategic decision to help understand ‘Are we going to invest in automation and achieve our target dates within this period of time so that we don’t have to fall back to temporary or bank staff?’

Those kinds of things are hard and fast. We need to understand very quickly whether we can actually automate a process and commit to the dates that have been provided. If there are other processes which are ‘nice to have’ but realistically, the teams performing them are able to get on top of them and they’re not causing any kind of particular headaches, those processes, unfortunately, do quite often fall to the back.

Another important consideration that we sometimes see with our clients is their aspirations for growth. We don’t often look to replace human users with automation. Instead, we’re looking to augment those existing staff members. And automation is a fantastic way of making existing team members more effective through automated assistance. Not necessarily just through automation, but those co-pilots as bots designed to help take the heavy lifting from very repetitive processes, very manual processes, and perform those behind-the-scenes activities which take a significant amount of time. When factoring in growth targets, there can be significant pressure from the top down, particularly from the C-level executives and understanding exactly what their aspirations are for the business and where the business hopes to go, those are important factors for helping us prioritise our automation.

Typically, we would look to use a prioritisation system such as MoSCoW. We look at what the must-have processes are, what is ‘should have’, what is ‘could have’, and it’s a very easy way of looking at ‘these are all the things that we want to achieve. Here are our budgets. Here are our timelines. Where are we going to get the most value from our efforts within the time that we have a lot of to us?’

I want to end by asking you about some of the common challenges that organisations face when implementing automation solutions and you touched on a little bit of those in your previous answer, certainly regulatory deadlines – that’s a hard stop right there on. If something needs to be compliant within a certain date that’s going to accelerate it. But outside of that what are some common challenges that listeners might be facing? And how can, as much as possible, those challenges be addressed?

There are two main resistance areas that we see. The first one is that the staff on the ground can quite often fear automation as a concept. It’s a very scary thought to think that ‘bots are here. They’re going to be doing the processes that I do and effectively they will replace me.’ We don’t look at automation as a form of replacement – rather as a form of augmentation. Microsoft is doing very well at the moment with their co-pilot terms. You have GitHub Copilot which assists developers. Their investments through ChatGPT are looking to introduce CoPilot to Word, PowerPoint, etc. It’s all about allowing those individuals who leverage automation, not necessarily to wholesale replace them and we see bots and RPA as something very similar to that. It’s an augmentation, not a replacement.

One of the ways that we look to address that, the first challenge is that if we have these individuals whose work is going to be directly impacted by automation, we look to ask them: “How would you feel if I could give you a personal assistant that will respond to your emails 24/7, even on Christmas, and would take a process which you give them and perform it as per your instructions?” And quite often people would love that kind of assistant. We’re not providing a person, we’re instead providing a bot and that personification of automation is a really good way to bring home that this is something that is here to help. It’s not here to replace.

Now, the other challenge area that we see is within the business and that often comes from very unrealistic expectations as to what automation can bring. We always need some kind of backup process and what needs to be factored in is who is going to own the process following automation. Is it going to transfer over to the remit of the IT team (which of course would then necessitate a higher headcount and increased budget for technology to continue investing in these services from a developer and technology standpoint)? And what if the process goes wrong? What if the platform goes down? If it’s regulatory compliance automation, then we still need a way for those processes to complete. Quite often it’s making sure that there is something robust in place to say the bots are down for whatever reason and we need the people to pick the tools back up and do it the old-fashioned way. Obviously, we look to build as much resilience into those processes as possible, but it is a fact of life that software is infallible and sometimes there are areas or errors that need a backup plan. That’s something that we always look to implement.

We also need to be mindful that despite marketing efforts, robotics aren’t infallible. A bot is only as good as its program to be. As a result, touching on some of those unrealistic expectations about a 100% success rate, ensuring that bots never fail, bots don’t make mistakes – these are untrue. It is very possible for a coding error to result in a bot misclicking or mistyping or doing something that it shouldn’t do. It’s part of why we have such a robust testing process and one of the reasons that building bots should be considered more akin to traditional software development, as opposed to simply sitting a developer down with an end user and getting them to automate the process as it exists. There are lots of complications, lots of overlapping scenarios, because we need these bots to be robust. We need them to be efficient.

The final point I would like to make is that bots do require maintenance. Applications, particularly ones that aren’t owned by the organisation (for example, if you are automating on a third-party website, a very common example that we see is submitting documents to government portals), those applications can change and that can very quickly cause massive problems for your automation. It may not be possible for your development teams to respond in time to fix those issues. Of course, we would always encourage organisations to be in very close communication with their partners to ensure that they are making it very clear that they will be automating parts of the process. Because that then also opens up opportunities to introduce things like APIs, as opposed to using bots which sit on top of applications and perform the activities that way. So many ways to automate a process but RPA traditionally does involve that front-end automation.

It’s also very important to consider that even if you do own the applications internally, once you have robotics running on those applications, it does become very difficult to change them. RPA can be considered akin to layering concrete over your existing apps. Once they’re there, it’s not just the code changes to the applications themselves that you need to factor in. You then need to factor in rework to the bots as well. For example, if a button changes colour and you’re using image-based recognition, the bot may not be able to recognise that button anymore. As a result, you need to make two sets of changes: one to the application and another to the bot process itself.