Now that we know the robots are coming, what makes a process a good first candidate for automation?
In this post we will outline the key areas that should be considered to try and answer this question.
Manual Steps
The process you want to automate should require a number of manual steps done by a person. If a process already has a high volume of automation, the potential gains from RPA will be limited.
Repetitive & Frequent
The process you want to automate should be frequent and repetitive, taking up a measurable portion of a person’s time. If, for example, the process runs once a year and takes a couple of hours for a person to complete, or takes a couple of minutes each week, the time taken to implement RPA will likely exceed any time savings from automation.
Reliable Inputs
Inputs and Outputs to different stages of the current process must be reliable, such as a consistent PDF document, email, or spreadsheet. If inputs vary and are not structured like ad-hoc Skype For Business messages, phone calls, or Post-it® notes left on your monitor, automation will be difficult.
Stable Systems
Systems that are part of the process should be stable. If, in the short term, you are looking at moving from Oracle HFM to FCCS, automating a process that primarily focuses on HFM and that will have to be updated once FCCS has gone live would be better left until after the move to FCCS has been completed.
In addition to the systems remaining stable, the process itself should be stable and not marked to be updated in the short term due to any non-technical business changes in an organisation.
Clear Rules
The process should be clearly defined, with clear rules that can be followed. While simple logic and flows can form part of an RPA solution, the more complicated these are, the more scope there is for exceptions with each run and updates to the RPA solution being required over time.
It is not uncommon for parts of a process’s decision-making to be in someone’s head. For example, many years of experience might tell you that certain Accounts are an exception and should be treated in a different way. If this decision-making cannot be translated into a set of rules, the RPA solution will be more challenging.
Low Exception Rate
For a fully autonomous process, there should be a low number of exceptions. These are not technical exceptions like a system being unavailable, but business exceptions. For example, if users often request an account to be updated, but the account does not exist (for whatever reason), then the RPA solution will not save much time as a person will most likely have to go through a large percentage of the workload to process all the transactions.
A final point on the above: although a process might not tick all of the boxes, consideration can be given to whether the process could be changed, for example if certain accounts are to be treated as exceptions and that knowledge sits in someone’s head, could they be stored in a lookup file which can be updated? If the input to a process is not well defined, how difficult would it be to put some structure around it?
As with many questions the answer is not often black or white, but shades of grey.
So for your first EPM RPA project, start easy and pick a manageable process which is repetitive, see what is involved and how the RPA system works. This will trigger your imagination to see what is possible and understand how you can then expand into more complex workflows in your following projects.
