Five Things Vendors Won’t Tell You About Robotic Process Automation

Robotic Process Automation may not be the silver bullet vendors would like you to believe, but it certainly is a piece that you want in your holster.

Many years ago, “screen scraping” was the answer to all our automation woes. We could spend hours creating the automation to pull down a few fields from screens just to cut and paste that information onto our workstation so we could then do some manual follow-up.

Years later, we began to develop Application Program Interfaces (APIs) so that we could integrate with existing systems to once again “scrape” data but also have some logic behind it to perform a higher level of integration, including the real-time update of those integrated systems.

Once again, though, it took time to create those APIs, if they were unavailable as part of the application package. And with it arose issues on testing, application availability, rapid changes to the integration app. The list goes on.

That brings us to today and the use of Robotic Process Automation (RPA). It seems that you cannot pick up a trade publication (yes, I am old, and I still like to hold a magazine in my hand) without hearing about RPA, artificial intelligence (AI) or machine learning (ML).

It is the “be all and end all” of the automation journey. Or so they would have you think.

Don’t get me wrong. Whether in the workplace, at school, or at home, automation is transforming our lives. After all, isn’t that what all technology sets out to do – or at least tries to do? But it may not be the “silver bullet” that many vendors would lead you to believe.

Robotic Process Automation Issues

There are several issues that I see taking place with RPA implementations that the tool vendors may not or will not share with you. I’ve also seen several issues that arise during development that are not found during discovery:

1. It is so easy. Anyone can do it.

I don’t think I have seen nor heard any one of the vendors say just the opposite, and I would have to strongly disagree with them. You will hear that it is just “drag and drop” and does not require an extensive skill set so your “typical” business user can create a bot.

Don’t be fooled. This is technical work and requires design experience and technical acumen.

Does this mean that a business user could not do the work? No, but someone who has development and design experience will deliver a more robust product than someone who does not have the skill set.

2. That’s how I run through the process each and every day.

You may hear this from your users and for the most part, it is an accurate statement. What they don’t share with you is the nuances that they encounter as they run through their process and the “shortcuts” they may take to complete their work.

You must remember that as you build your bots, they are like a “new hire,” if you will, performing the same role as someone sitting at a desk. The bot needs to know as much as it can about the process and even the little nuances encountered by the users. Will you get every little piece? Absolutely not.

But going into your process discovery sessions with the user, knowing that you need to “dig a little deeper,” will help to uncover most of those items that can fall outside of the rules-based mentality of robotic process automation.

3. It’s slower than I expected. What’s up with that?

Just because a bot is now executing your process, it does not necessarily mean that it will always run faster than a human.

About 99.9 percent of the time it will but there will be those occasions where it seems to run slower. That is normal. Once again, remember that the bot is executing steps just like a human would and just like a human, there are issues outside of their control – such as a website that is down, internal outages, system upgrades and more.

What a bot can do for you though in those situations, is continually check to see when services are available so they can continue to process again.

In most cases, human operators end up doing other things and it could be hours before they came back to complete their work while a robot may have completed that same work hours ago.

4. Let’s throw another bot at the process to improve the performance!

I like to use the analogy that you cannot take nine women and have a baby in one month. That’s not how it works. Same thing with a bot. Just because you throw another bot at a process does not necessarily mean it will run faster.

But, if you design your automation correctly, you can have bots call other bots to perform other pieces of the process, in essence, providing a certain level of parallelism that you might need for your automation to be more successful.

5. The bot isn’t working. It looks like someone made changes to the application we are integrating to.

Communication, communication, communication! There tends to be little communication at the outset of an RPA initiative, but that quickly becomes an issue when the bots are no longer running as expected or at all.

There needs to be a great deal of communication between the teams building the bots and the teams who maintain and update the applications, websites, and directories that the bot is using to integrate with.

The RPA team cannot manage things in a silo or can the application and infrastructure teams. They must work as a cohesive unit.

Final Thoughts on RPA

There are several comments, suggestions and complaints that you will hear as you begin to roll out your RPA initiative. (Doesn’t that usually hold true for almost all technology initiatives?)

But do not let that discourage you from moving forward. RPA plays an important role in your organization’s automation maturity and in your overall process excellence initiatives.

Make sure that you do your research and that you clearly engage staff from across the enterprise to help move automation forward. Don’t allow the naysayers and those who may be directly impacted by automation slow down your progress.

Get them on board. Bring them into the process early on so that they can become more educated on why RPA is good for them and their company.

Give them enough ammunition so that they can effectively champion your RPA efforts and help to increase revenues, improve data and process quality, and enrich customer and employee experience.

RPA may not be the “silver bullet” of technology solutions, but it certainly is a piece that you want in your holster. If designed for long-term growth, can have you shooting for the stars.