Five Key Takeaways on the Challenges of Robotic Process Automation

In all my time working in technology, I’ve spent the past seven or eight years working with robotic process automation (RPA) at a few different companies. During that time, I’ve learned some key lessons in implementation and how to make the transition to automation as smooth as possible.

Of all the things I’ve learned in my time with RPA, here are my five top RPA takeaways.

1

One of the first steps to successful automation is figuring out where to start. Some people will say to follow the money when you’re looking at implementation, but I say follow the labor.

Find out where you’re spending the man-hours and that’s where you can start to define the processes that you can automate. I say this mainly because the return on investment (ROI) for RPA is more than the efficiency of headcount. 

There are lots of factors that calculate RPA ROI and many of those factors center around the labor involved. So, for the best value of automation, follow the labor.

2

A big question that I get is “what can you automate?” Generally, if you can write the instructions for a process, it can be automated.

The documentation needed to automate a process is very specific, but UiPath can train your people on how to write the documents so that your processes can be automated. Most processes that are automated are the manual, repetitive, and monotonous ones, like pulling data from reports and inputting it into spreadsheets. RPA can automate all these kinds of tasks and remove the tedious activities from your workday.

UiPath has the software, RPA training, and support to completely transform your work and let you focus on the creative stuff.

3

I’ve said it before and I’ll continue saying it: ROI is more than the efficiency of headcount. RPA ROI is made up of numerous factors, but accuracy is continually called out by our customers as the greatest value they receive from RPA.

A robot doesn’t make mistakes, which means every report is 100% accurate, on time, and done without the need for outside resources. There’s no risk of a mistake (a mistake you may have to pay a fine for), no extra bandwidth needed to complete the task, and no wiggle room needed to account for possibly incorrect calculations.

4

This is true as a general statement about all of RPA, but I’m bringing it up specifically about documentation. RPA produces two different kinds of documentation: as-is and to-be.

As-is documentation is the step by step of how to do the process manually. To-be documentation is the step by step of what the robot does to complete the process. Sometimes these two are the same and sometimes they’re slightly different if tweaks are made to the process when it’s automated.

If something goes wrong with a software robot you can always pull out the as-is documentation and know exactly how to keep the process going manually while the robot is being fixed. You should produce documentation and have an excellent support and monitoring team because if a robot fails, it shouldn’t negatively affect your business.

5

Often, organizations don’t think about support and monitoring until something goes wrong. However, when something does go wrong you want the strongest people you have to be on top of the problem so that it causes as little disturbance as possible in your process.

This is probably the most important lesson that I teach people and the major takeaway is to not think about support and monitoring last. Make automation support and monitoring your first and strongest consideration.

To learn more about RPA and UiPath, check out my #ChetChatsRPA YouTube series.