Look at any sales or marketing pitch around Robotic Process Automation and you’ll see these statements repeated in some form or other.

• 50-80% reduction in cost.
• It’s easy to get started. No special skills needed. Even the process executive can ‘train’ the bot
• By extension, this is not coding and doesn’t need formal processes/change management
• RPA can automate (almost) any manual process

However the truth is not as rosy as projected. Yes, there are cases where RPA has delivered huge savings in record times, but there are several more cases of failed RPA initiative. Failure could be on multiple fronts:

• Not realizing the ROI. This is typically because 30% effort reduction does not translate into 30% cost saves.
• Robots leave out corner cases and automate only the ‘happy path’. These results in several exceptions that the process executives need to handle.
• The pilot was successful but the bots aren’t able to scale. When deployed at large, there’s chaos.
• The technical truth that some apps are easier to automate than others.

Delivering the Hype

The harsh reality is that RPA is no magic bullet. Like any technology advancement full benefits can be achieved only by fully understanding the technology and adapting to it.

Some of the ways to achieve successful RPA adoption are:

• Don’t lose sight of the end goal. The project is not about implementing RPA but delivering value. This often means collaboration and coordination with all related units and having the right governance to facilitate this collaboration.
• RPA is just a tool in the toolkit. Don’t make it the only tool. Even where RPA is adopted, look at streamlining, simplifying and documenting the processes and the exceptions.
• Get the IT organization onboard before starting the RPA journey. After all they will ultimately be responsible for a whole new technological layer, not just the bots, but the associated VMs and servers, the support, audit and security implications. Proper processes around these should be in place before the bots are deployed at scale.
• Similarly get the process executives and people who support them on board. Their ownership of the RPA initiative will be the difference between success and failure. They are the ones who know every corner case and every trick in the book to get things done. They are the ones who would need to step in if the bots fails, and they should look at bots as their children who they will train better to ensure they don’t fail in the future, rather than looking at bots as a nuisance.
• To ensure that the employees are firmly onboard the initiative, have open communication with them. Ensure that their fears are addressed and they see bots as software assistants that will help them with mundane tasks while they focus on delivering value. Make them owners of the initiative.
• And finally have a plan to effectively translate the effort reduction to cost reduction. Look at ways of using the spare capacity for higher value work, to reduce external consultants, to expand business, to offer services to other businesses. In short, look at ways of transforming the business.

I’m trying to take a balanced view here. While I am upbeat on the possiblities, I see the challenges as well. In the next post, I’ll write about the good, bad and ugly of proof of concepts.