A short guide to RPA: Identifying the right processes to automate
How to approach RPA?
Robotic Process Automation, or RPA for short, is still a relatively new thing, though it is getting more well know all the time. The name can be slightly misleading: RPA does not mean hosts of robots are coming to take over and cause massive layoffs. But in its unintended allusions to science fiction, RPA has sparked fear and resistance – as all change does.
There are steps you can take to try to determine for yourself whether RPA would be beneficial for your company. You can take them alone or with your team, quite independently from outside consultants, so the cost is fairly low and there’s no need to feel unduly committed or pressured to anything while doing your investigations.
So why not investigate, just in case? Even if you decide against RPA, going through these steps will be worth the time put into them.
Choose potential processes for automation
It’s very important to start with small and simple processes.
If you’ve never defined processes, you will be in for a surprise. No matter how small a process is, defining it with all its exceptions and edge cases makes it much bigger than it appears at first glance.
Even if you have defined processes before, it’s important to start small when considering automation for the first time. The more logical and easier to define the process is, the faster it is to implement and less prone to errors it is.
That said, you do want the processes to be worth automating. Pick processes which are annoying – they take up a lot of time every day, they are those necessary evils everyone would rather do without, but just need to be done. If they end up being automated, people will thank you for it.
Notice how I said “if”. There are many reasons why a process might not be suitable for automation despite seeming so at first glance. There might be too many cases where a person needs to decide what to do next or the process is very complex and would take a lot of time to build. You may also find ways to improve the process so that the automated part would only be run few times a month. These, and other reasons, could determine the investment not being worthwhile. This is why it is important to pursue multiple potential processes early on.
Define the processes
This is the obvious step after selecting potential processes. After all, you can’t automate a process if you haven’t defined it in the first place.
To start off, get the people who know the processes, aptly named the Subject Matter Experts aka SMEs, in the same room and get them to help you to define the process.
It is important to first define the start and end of the process. For example, the recruitment process can start when the need for a new employee is realized, the position is advertised, or the first interview starts. Similarly, it can end when the last interview ends, the decision to extend an offer is made, an offer is accepted, a new employee starts their first day at the office, or they are considered a productive member of the team. Defining the start and end points early help focus the conversation.
Let’s say the recruitment process ends up only looking at the interviews: the process starts when the first interview starts and ends when the last interview ends. There are a lot of things left out of the scope which will not be looked at at all. This might sound harsh, but it helps the team focus their time and efforts on what they deemed to be the core of the process – all other things are outside of the scope and not considered.
At the end of this part there should be a detailed process map document written down.
Observe the process in action
Go back and observe people follow the process. Amend the document where needed. This is crucial. Very often there are two processes in place: the official one people say they follow, and the unofficial one they actually follow. You want to make decisions based on the actual process in place, not the official process, which might not be followed. The practical process is the one actually affecting people’s everyday life, not the unused one.
Improve the process
Next take what you’ve seen and heard and see if you could make it better. Identify bottlenecks and problem areas. Streamline the process where possible. Identify parts which can be speeded up or performed congruently instead of linearly. Define time standards for how long to wait for responses and reactions, for example when chasing a new sale, and escalation triggers for when to pass responsibility on to a higher up, for example in customer support cases. Identify whether the process or any part of it could be automated.
Iterate with the Subject Matter Experts
Get back together with the SMEs and introduce the improved process map to them. Get feedback and reiterate it together with them to make it better.
Have the SMEs write the final version of the document as a standard operation procedure document, which can be used when training new people in the future.
If any part of the process is to be automated, start the automation process.
In the end, even if the process ends up not being automated at all, it is now defined better, people do it the same way, and thus it is most likely more efficient and pleasant for the people working it. You also have a better idea about what kind of processes are fit for automation and what aren’t.