Working in the emerging and growing field of Robotic Process Automation is fascinating daily. Seeing an increasing spectrum of innovative solutions to process pain points is one of the joys of the work. Just when you think you have a solid handle on the ways RPA could be employed, someone suggests another application that had never occurred to you before.
Unfortunately, the opposite is also true. Many discussions within organisations starting out on their RPA journey involve a version of the following discussion:
RPA Analyst: “So I’m here to understand Process X, which I understand takes up a lot of your time and is quite tedious to complete.”
Process Owner: “That’s nice of you – but my process can’t be automated. I know you can automate the big, simple tasks, but not this work”.
RPA Analyst: “Um… alright, can I suggest we review the process so I have an understanding of how it all works”.
Process Owner: “Well, if you want to, but this very complicated… it takes me hours to do it. There’s lots of rules.”
This discussion is fascinating to me. To be clear, I do not view this as a Process Owner’s failure. This is likely a process that absorbs much of their work effort. They have dedicated time and mounting experience to ensure it is executed correctly. What’s amazing is that describing a process as time consuming and governed by sets of rules are two of the three main metrics for a valuable automation. Why is this so?
I consider myself lucky to have arrived at the right time in the maturity of RPA. I have no extensive IT background, beyond being relatively well informed in the tech and digital industry as a user. I cannot code but I am a skilled RPA Developer. The tools have matured to a point that solutions need not be coded freeing the process owner and the RPA developer to have a conversation about the business need. When I describe this to people I compare it to the jump from command prompt interfaces to the Graphical User Interfaces of modern operating systems. You can likely use Windows or its equivalent, but you can’t code it. You can create and move files, but you didn’t ‘code’ them into existence. To me, the RPA industry has reached a similar state of access and useability that opens up the conversations about RPA to larger number of people.
In terms of the “automation revolution”, this level of access and proliferation has another historic parallel. Industrial automation – using mechanical devices to automate manual labour – generated similar discussions. Imagine I am not an RPA Developer, but in fact an emerging Mechanical Engineer in the 1800s. Instead of trying to understand a digital task in order to make an automation to undertake the work, I am assessing a physical task in order to make a mechanical automation.
Mechanical Engineer: “So I’m here to understand Process X, which I understand takes up a lot of your time and is quite tedious to complete.”
Process Owner: “That’s nice of you – but my work can’t be automated. I know you can automate the big, simple machines, but not this work.”
Mechanical Engineer: “Um… alright, can I suggest we review the process so I have an understanding of how it all works.”
Process Owner: “Well, if you want to, but this is very detailed… it takes me hours to do it. There’s lots of very fine tools involved.”
From our vantage point in history, this conversation appears naïve but understandable. Of course, we can review the ever-increasing fine motor skill abilities of machines, from early industrialisation through to modern day robotics. How difficult it must have been for those undertaking those detailed physical tasks to possibly image that detailed work being performed as an automation.
What I find striking is that despite having this historic lesson we take a similar stance now regarding digital tasks. These are the early days of digital automation but despite this the tools at our disposal are immensely powerful. I can confidently advise any organisation that we can implement an RPA solution within their applications, before knowing that those applications are. The solutions can be taught to use virtually any software and are modular to the point that tasks can be assembled in any order.
For this reason, the question most often is not ‘can this be automated’. In most cases, yes, it can. The primary questions are: Is there sufficient volume in the task to justify creating the automation, and are the rules clear enough to guide how the automation will work. Notice, there was no mention of how many rules the automation must follow. As long as the rules are clear, how many there are is almost irrelevant when the work is being conducted at machine speed.
As our workforces come to terms with the inclusion of Digital Workers undertaking automated tasks on our behalf, the scope of RPA solutions will be more easily identified. But for now, if faced with the question of ‘can it be automated?’, the answer is very likely ‘yes’. Should it be automated now is a question for another time.
Scott Stephens, RPA Developer