An 8 Point Guide to deciding which processes to give to your robot
So many organisations are looking at, or have started to implement Robotic Process Automation, but not all robots are created equal, and not all processes are ideal to be replaced. So how do you know which tools to use, and what processes to use them on?
Firstly, ask yourself a very simple question …
Who in our organisation is responsible for rolling out spreadsheets?
Yes, you read that right, Spreadsheets. The answer is of course the person responsible for building a spreadsheet is the person who needs it.
If spreadsheets were sold on the basis of needing a production virtual machine to run in, a development one to build it in, and a team of consultants on site charging a daily rate, then I believe the humble spreadsheet wouldn’t be the success it is.
Yet this is often exactly how some organisations buy and roll out robots. They then wonder why so few processes have been automated and are stuck in the proof of concept stage. It is crazy.
When I look for a tool to provide robots, I want one that the users can build their own processes in. This means ones with no code, no virtual machines, or costs per robot forcing you to value everything you might need to automate to see if it is worth it first.
Our chosen tool has customers that have built tens of thousands of robots. Yes, you read that right. Tens of thousands of robots. Almost all the other tools out there would make this scalability impossible due to the sheer cost and effort required. So, make sure your chosen platform can scale and find out how many robots have been built by other users in say a three-month period. If is less than 10 this should ring serious alarm bells.
However, when looking at your processes it can be helpful to go through a simple 8-point test to see how effective the robot will be.
1. Rules based and repetitive
A simple test, but does the task you want the software assistant to replace have a definable set of rules, and is it a task that needs doing on a regular basis? Having said this, we have built clever robots that can read incoming tasks (see the next point), and some robots that are intended to perform a simple migration task that once performed will no longer be needed. On the whole, the best robotic processes to initially look at are the ones that follow logical rules and need to be repeated.
2. Structured input data
Robots, like Mr Spock, like being logical. They also like to receive structured input. A second simple test is to check if the data that initiates or is used by a robot is indeed structured and logical.
Is data in a back-end system, a spreadsheet, web page or database? Then chances are it is a perfect candidate for a robot. Of course, I have spent the last 10 years of my life working with technologies that turn unstructured and semi structured input into a logical and understandable format. For example, one of our customers has tens of thousands of emails a day coming in and we can read them and the attachments and pass them as structured and understood data to robots or back end systems. To read more about your new Digital Workforce check out this infographic.
3. Mid to high volume or time
Linking to number 7 (the business case) on this list, one test is to make sure your processes have a mid to high volume to make the build worthwhile.
Before you build a robot to automate a process, ask, is this process something that needs doing a lot? This test of course feeds the business case, but you should also consider the time and human effort impact. So, a task that is only performed a few times a day but may take someone hours to complete is just as valid.
4. Peaks and troughs
Often, we see a perfect candidate for robots where seasonality is at play. If your processes have significant peaks and throughs this can make it very hard to scale your business or have the correct number of people. Robots work 24/7 and don’t care how many tasks they have, and you can scale them easily. If your work volume quadruples, just fire up a few more digital assistants rather than the huge effort of recruiting, training and motivating lots of new employees.
5. Out of hours processing
As said many times by me before, robots are happy to work every hour of every day. If your process can run, unattended “out of hours” (who has the luxury of being out of hours in today’s economy?) then it again is a perfect candidate for automation.
6. Prone to human error
It is estimated that humans make 5 to 10 mistakes for every 100 things that they do. I hope I copied that figure correctly! Obviously, the type of task and the inbuilt error checks will affect the typical error rates. These errors are a known factor in manufacturing, and a reason that physical robots were brought in to replace humans.
This is often not even considered in other manual tasks. Most organisations can tell you how longs things take and how much effort is required, but there just isn’t the metric available for how many times the financial accountant miss copied across a bank balance for example. But, if you know that your tasks are prone to errors, then they are a perfect candidate to give to robot. Robots never make a mistake.
7. Business case
This is the $64K question or should it be the $1m question? I guess it depends. One of the key constraints we are seeing with robots is that the business costs aren’t stacking up.
This is a crazy situation, most often created by the choice of technology used to provide the robots.
If you are charged for each robot, and you need one in production, one in test, two new fully licensed virtual environments to run them in, along with a team of people to program the robot, de bug it, test it, validate it and promote into production, then you will be very selective about what processes you will choose to automate.
Of course, if you chose the right robotic tools that don’t limit you on the number of robots, don’t need virtual machines, and don’t need teams of specialised consultants, then the number of tasks that can be automated explodes exponentially.
Having said this, I do think every organisation should have a centre of excellence or governance over the deployment of robots to make sure they are happy with what is being done. This is just basic common sense.
8. Stable process
My final test to see if a robot is suitable is to check the stability of the task. If what needs to be done is constantly changing or being honed or refined, then this can have a limiting factor on its efficacy.
Of course, again, if the tool you use to build robots is agile, quick to use, and easy to learn so you can make rapid changes, then you can accept that a robot will need to be updated and modified, and therefore not have to miss out on the benefits just because something is due to change.
This concludes a very simplified overview of my thoughts on ideal processes to automate with software robots (I didn’t think I would ever write that sentence either).
If you are interested in this topic and want to discuss it in more detail, I would be delighted to help if I can. Many, of our customers have done just that, they have come up with a few process problems and we have built a robot in front of them. Then, and most importantly, we have also shown them how they can build their own robots which means they are free, like with a spreadsheet, to solve their own problems. I am hearing that old adage in my head “give a person a fish (robot) and you feed them for a day, teach them how to build a robot and you have revolutionised their business and allowed them to compete in the modern world”. I think that was how it went!
Digital Transformation expert