I’m going to assume that before reading this article you already have some sort of idea about what Robotic Process Automation (RPA) is. I’d like to try and give you some insight into what business processes are a good fit for RPA.
Not all processes are candidates for RPA, so it’s worth putting some careful thought into your operation to try and put some criteria around what to look for. So often we find that organisations don’t allow any financial budget for RPA simply because they’re not aware of what would give them payback and what wouldn’t.
There’s no denying the significance of applying RPA to a business process fit for its use. It usually results in significant paybacks in efficiency, productivity, compliance, and cost. But ensuring that your processes are in the right zone for RPA is a must.
Engaging a credible RPA vendor to carry out an automation audit is usually a good place to start. Prior to that, the following seven criteria are relevant before you consider embarking on your Robotic Process Automation journey:
- It might seem obvious, but processes that are highly manual and repetitive by nature are necessary to get the payback of the automation. There is no point in automating a process that you might do occasionally, as the problem just isn’t big enough to solve. Processes that have high transaction volumes, and are frequent, i.e. are (at least) daily or weekly, and not monthly or yearly, and involve plenty of manual work (and are prone to human error) are good candidates for RPA.
- Processes that have a standard readable electronic input type are suitable, as RPA is not (yet) at the stage where its able to intuitively understand variations in handwriting or interpret text from images. The inputs should be in the form of readable input types like Excel, Word, XML, readable PDF’s etc. Having an OCR capture engine which can convert the document into these formats at the front end is an alternative option.
- Processes that require the process method to be changed in the short term should be avoided, as this requires additional adaptation and often a complete re-working of the solution each time something is changed. In turn, this will require additional scope and will likely affect the ROI of the project. Also ensuring that fundamental changes in the underlying technical architecture of the systems are avoided (i.e. new interface development or changes to the configuration of existing systems) is advised.
- Rules-based processes, with clear processing instructions which are template-driven, and have decision making which is based on standardised and predictive rules are the best candidates for RPA. If there are too many variations or outcomes with a process it becomes intensive to implement and may not give you payback.
- Processes that have a low exception rate are optimal. By this I mean activities with a low number of variation scenarios existing in the process (obviously leading to different handling procedures) are the best for RPA. Otherwise, you’ll end up in the same scenario as above and the system will be costly to implement.
- A good guide is to choose mature and stable processes as these are likely to be well documented and very predictable. You will also have a good hand on the operational cost of these types of processes, so it’ll be easy to measure your predicted ROI.
- And lastly, ensure that you try and pick processes that you will actually get a payback from – I know it sounds obvious but it’s still worth spelling it out. A good benchmark is to pick processes that at a minimum you have at least two FTE’s currently engaged on.
By applying the above criteria in your discovery phase you’ll be able to more clearly identify the right process(es) for RPA, and hopefully on your way to reaping the rewards of automation.