One thing I’ve been hearing a lot of the last year is Robotics, Automation and RPA. With the rise of companies like Automation Anywhere and Blue Prism the marketing machine has been hard at work trying to convince business leaders everywhere that their employees could either be more efficient or replaced altogether if they invest in automation. In the context of Data Analytics, I see it increasingly called upon to help collate data from difficult sources and in the context of Audit and Risk, to build automated testing solutions that are able to apply simple analytics to highlight exceptions and reduce the amount of manual testing that teams perform. Automation isn’t a new concept, automation as a general principle has been with us a long time, but popularized by these companies is a new form of automation that is somewhat different from traditional approaches - Robotics. Specifically, Robotic Process Automation or RPA for short.
Why is an RPA approach to automation so different? In a traditional technology process automation project, the design team may start by examining the existing process, mapping out their target process, and then identifying ways to change the underlying systems to bridge the perceived gaps. For example, you might have an exception process that flags mismatches between systems, but those exceptions still need to be reported, assigned to the right people, actioned and closed out. All of that might happen outside of the system making the management of that information very manually intensive and prone to error. If a portion of the exceptions could be automatically processed by the system or fed to another system for onward processing that could cut down the manual work portion substantially reducing the likelihood of errors and freeing up employees to perform other tasks.
One of the key principles behind RPA solutions is that you don’t need to make any changes to your underlying systems in order to automate manual tasks like this. If a process can be executed by a human right now, it can be automated using RPA techniques without uplifting the underlying technologies. This is particularly attractive in domains where there are limited opportunities to upgrade or change existing systems, for instance legacy technology platforms or external systems over which the business has little control. It also makes quantifying the benefit to the business easier as automation can be more easily expressed as a fraction of headcount. Take the time it would have taken to perform the task and the number of times it’s typically performed and multiply by the fraction of an employee’s salary you just replaced.
The rub, so to speak, is that RPA is often a tactical solution. By not updating the underlying business processes, the automation that’s put in place is more like a band-aid than a permanent solution. If the underlying process changes, that band-aid is going to come off. If you don’t have control over the underlying systems, it might rip off unexpectedly and at any moment.
So, when should you think about using RPA?
When you can’t make changes to the underlying systems, either because they are outside of your control or they are no longer being developed.
When the task does not require human reasoning in order to complete it. It may be completed by following rule based logic or there is a reliable ML model that can be used to determine course of action (true data-driven decision making!)
When tasks can be completed using applications on a single workstation - just like a human user.
When the underlying systems change infrequently. If underlying systems are updated your RPA may be brittle and require fixing each time a change is made.
If you’re not meeting at least some of these requirements, then it may be better to think about RPA as a tactical solution and start investing elsewhere. However, if you’re sinking a significant amount of human time into a standard but disjointed process, it could be worth the investment, however tactical it might be.
Outside of RPA, the world of technology also continues to reinvent itself around business processes with increasingly more focus on the users that will interact with these systems. If you’re seeing large inefficiencies in user workload, it could be time to think about how you create a more user-centric environment. Business Process Modeling is one approach to streamline user interaction with multiple systems, flowing information between systems and bringing elements of applications together into a single tool for common work tasks such as approvals, assignments and review. A key strength of this approach is the ability to centralize disjointed user tasks into a single application where users take action on smaller pieces of work and so it can be leveraged to build human-in-the-loop systems and user tasks are used to escalate work processes that require human input to proceed.
For analytics, the benefit of investing in RPA will depend on the type of challenges your business is facing, the level of investment you have to solve those problems, and perhaps the maturity of you technology stack in general. If you don’t have a robust technology stack that allows you to develop automated solutions, RPA can be a way to get your foot in the door.
As always, I’d love to hear your thoughts and the experiences you’ve had in automating your analytics solutions. Have you tried RPA? Do you have experience to share on the RPA journey, the tools chosen or the pitfalls to avoid? I’d love to hear from you.
Leave a comment below or send me a message @eageranalyst