We are often asked how to identify processes that are right for automation. For some companies, simply knowing where to start is the first roadblock to their automation journey . When asked, we often share a simply acronym, R.E.A.D.Y to help identify if a process may be suitable for automation.
In this post, we will share the R.E.A.D.Y approach for identifying process automation readiness. Beyond readiness however, there are some additional factors to consider pre-automation, which we will also discuss in the article.
So you’ve identified a process that you want to automate. Great! The first thing to ask yourself; is the process:
If so, then Yes, you should consider automating this process!
The primary benefit of this approach is that it helps you identify processes that can be automated and are worth automating. On a technical level, the fact that a process is repeatable and action based means that a machine can be configured to carry out the work. Automation will require an investment (albeit a small one) to implement, thus processes that are repeated more often, expensive to perform and those that carry a high degree of dependency on key staff will be more attractive to automate from an ROI perspective.
One thing to keep in mind is that many processes while exhibiting many of the R.EA.D.Y indicators may have parts (of the process) not suitable for automation. For example, a reconciliation process might have 90% of data matching that is easy to automate while the remaining 10% may require staff to perform thorough investigations and have conversations with the business:
In the example scenario above, it is perfectly reasonable to focus on automating the 90% of the process that is suitable for a machine - while also building in controls and hand-off to staff to perform the remaining 10% of the process manually. By doing so, you:
The key message here is pragmatism. Automation doesn’t need to be all-or-nothing. It’s perfectly reasonable (and common) to partially automate processes - and build in the human intervention where needed. For example, we often see automated processes split into parts:
In the example above, an automated process (1) generates an output (e.g. an Excel report) and emails the report to staff who review the file and make adjustments. Staff then load the amended data into a second process (2) which generates the final report (e.g. a Word document).
A process being R.E.A.D.Y to automate should be the qualifying criteria for any process you are considering for an automation project (think: automation checklist). You should then consider three additional factors before making a final decision to automate.
1 - Do you actually understand the process?
Many processes are inherited - staff are often given a spreadsheet or an operating procedure document when starting their role. The nature of Finance processes is that it can be all too easy for staff to simply crank the handle - that is, simply follow a checklist without any real appreciation for the work that is being done.
An example of a red flag is when staff prepare worksheets that don’t seem to add any value to the report that they are producing. Another good example is when staff can’t explain why they select certain options when running an extract from the GL (where those options don’t seem to have any material impact to the data that is required).
Staff that truely understand their process can answer fundamental questions around “why” a process exists. They know exactly who the stakeholders are and the value that the process (e.g. report) provides to each. They should also exhibit a passion or at least interest in improving the process - having ideas of their own for how they can make the process more valuable to its stakeholders.
If you lack a proper understanding of the process, you need to take a step back - as you don’t yet have an automation problem, you have a process issue.
2 - Is the environment around your process likely to disrupt your automation efforts?
Are there things outside of your control that are likely to disrupt any attempt at automating the process? Are you changing your GL? Are you about to do a massive restructure that is going to entirely change how you segment and consolidate reporting?
The important thing here is to identify anything that will effectively move the goal posts that you are aiming for while automating. That said, you also need to take care and not go overboard. In most organisations, change is a fact of life. Therefore, it can be easy to tell yourself that you can’t automate until things stop changing. The problem with this approach is that, because the change never stops, you simply never actually get to automate.
The practical approach to take is one of risk management (see our guide to creating a risk assessment matrix). Your role is to be aware of the various risks that can derail your automation and mitigate the ones that are actually likely to have an impact on your work.
3 - Should you replicate or re-engineer the process?
Finally, you need to consider the level of re-engineering necessary for the automation to meet your needs. This is important. Just about every processes we’ve ever seen automated has had at least some re-engineering applied. This is because human beings don’t think and act like machines. When a process is performed manually, we can pause and interpret information and introduce entirely new and ad-hoc steps into the process. Machines (and programs) don’t operate this way, which is where re-engineering comes in.
Re-engineering often manifests itself in two ways, adding “features” (or functionality) to an existing process or adding error handling capabilities. A good way to draw out information about a process that can highlight the need for re-engineering is to ask process owners open-ended questions like “tell me about a time where the process took way longer to complete than it normally does?”. The “exceptions” that people highlight in their work often help identify the areas where an automated solution may need some re-engineering.
Similar to the previous point, re-engineering needs to be balanced. It is very easy to increase the scope of an automation project by adding more and more “nice-to-haves” to the point where the project is not able to be delivered on time or budget.
In summary, you should always consider the suitability of a process for automation. An easy way to do this is to use the R.E.A.D.Y acronym to check if the process is:
Beyond the process-readiness, you should also consider the level of knowledge that your staff have about the process, mitigate any high-risk issues likely to impact your automation and consider (but also balance) your need to re-engineer.