In previous posts I spoke of three killer use cases for back and front office RPA Processes. Based on my experience those are some of the most commonly created processes to automate. As RPA grows in adoption, the list of killer use cases will expand. It is vital that these automations be carefully selected and focus on existing processes that are “high value”.
When evaluating any process to automate using RPA there are two rules to go by:
1. Focus on “high value processes”, particularly ones that are mature and well defined.
2. New and undefined processes should be avoided.
The focus on “high value processes” is often repeated but seldom understood.
Like all purchases an organization makes to grow, there must be a ROI for it to be a worthy undertaking. RPA projects can be very expensive. To properly assess, develop and support a relatively complex RPA process it will require quite a bit of investment. That’s not mention the costs of the software and hosting of the server component. Bottom line, these costs can add up.
This is why proper identification of a “slam dunk” processes are imperative. These processes should be ones that have been done for years and are easily automated. It helps if they require quite a bit of labor and are prone to error. With these types of processes, one can easily surmise that an organization is saving money in not having someone do this task and is also increasing operational excellence when reducing errors. Both of these outcomes can directly influence the bottom line. This is a simple example, but a relatively good guide to follow. We are still in the early stages of RPA, but every organization has some “low hanging fruit” processes that can be automated and provide the perfect appetizer to start any RPA initiative.
The second rule, ”new and undefined processes should be avoided” is one of my most commonly repeated phrases when speaking to RPA Partners.
A typical RPA project that follows the first rule can begin to achieve ROI within the first 6 months. If an organization decides to attempt a new/undefined process, ROI may never be achieved. The reason for this is, if you have a new process and are trying to automate it you are effectively introducing two points of failure. The simplified explanation is that if you need to adjust the new process you will need to change the RPA Process each time the new process is altered. This can lead to excessive re-work, frustration and a lack of definition of what the RPA Process is supposed to do. Therefore, these are all factors that lead to a failed RPA project.
Whenever we engage with an RPA Partner, we insist on using a Process Design Document (PDD) as a point of understanding. Gathering this data is a way to ensure that process is defined and it’s a warning sign if the document needs to be frequently changed even after the RPA Partner has signed off. It’s also beneficial to document the process so it can easily be reworked if changes are needed.
In conclusion, having a document and clear idea of which processes to automate are instrumental to the success of any RPA initiative. These rules are simple but are highly beneficial in attempting to bring clarity to which RPA processes should be automated.
Peter S Camp is the CTO and Founder of CampTek Software. He has been developing RPA Applications for over 15 years. For further questions, discussion or inquiry about CampTek Software Services, contact info@campteksoftware.com
