RPA: Look Before You Leap

RPA projects fail more often than one would expect. In fact, a report from EY found 30% to 50% of initial RPA projects failed. The ease with which RPA tools allow workflows to get designed and implemented makes it easy to avoid building a strong foundation for the work being done.

Déjà vu. Memories of bad software projects past come rushing back as I work with members converting their manual tasks into automated pipelines or robotics-driven processes. The need for speedy development aligned with the ease with which software could be written and considered production-ready introduced us to technical debt. Badly designed code, inefficient algorithms, hastily modeled databases, and bloated JavaScript files – these had become typical for many codebases. Fortunately, the rise of “continuous everything” has exposed the bad habits technologists were burying under the “we just had to get it done” excuse. Accumulating technical debt is one of the worst development habits, and now it’s time to settle this debt or else drown in interest payments in perpetuity.

Organizations using RPA might end up trudging along the same path

I get it. RPA tools are easy to use. They have interactive workflows and drag-and-drop widgets. Playing around with these features to spin up the next flagship product for your company is a wildly charming idea, but (and there is always a but just when the sky seems to be the limit) don’t let your eagerness push planning to the wayside.

Planning? In the age of Agile?

Agile doesn’t ask you to skydive without checking that your parachute will deploy. Similarly, trying to push your RPA solutions without having done some preplanning can lead to failure. Rather, establish a minimal prework checklist that must satisfy a criterion for quality.

A basic set of checks before embarking on an RPA implementation would include:

1. Brainstorming what needs to be done. Include as many of the impacted stakeholders as you can. Don’t ignore security, privacy, data management, and other important considerations.
2. Identifying processes to automate.
   1. What’s repetitive?
   2. What consumes a lot of people’s time?
   3. Which ones produce a net loss (or negative value)?
3. Going through lessons learned from previous automation exercises.
4. Documenting the effect of automation on existing resources.
5. Discussing the possibility of setting up a workshop for ideation, cost-benefit analysis, teaching RPA to those who are still untrained, and understanding changes to daily work.

Is RPA a one-size-fits-all solution? What processes should we automate?

No, it’s not. Not everything that can be automated should be automated. Before deciding which processes to automate, it’s important to analyze your business and operations ecosystem. Take a holistic view of the value-generating procedural workflows, including existing legacy processes that may not be automated but may still be impacted by bots.

In general, processes that fall into any of the categories below are viable candidates for automation:

• Repetitive processes that change rarely
• Processes that are used more frequently
• Rules-based processes that can be converted into workflows
• Processes that require a high level of consistency, like data entry, data validation, etc.
• Clearly defined processes
• High-volume processes
• Data migration processes where different teams exchange data on a continual basis

Our Take

Adapting your organization for RPA is like any other important project you will undertake. Without getting mired in tedious planning activities, some groundwork still needs to be completed for success to be a certainty.

RPA platforms like Blue Prism, Automation Anywhere, UIPath, and Microsoft Automate are generally well-developed tools, and failed RPA projects are likely due to lack of preparedness rather than any deficiency in the tools.

---

Want to know more?

Connect with one of our analysts to understand how your organization can benefit from:

• Robotic process automation
• Low-code/No-code development