7 mistakes to avoid when developing RPAs

Automating business processes can take the drudgery out of repeating steps, improve productivity, and reduce the number of human errors. Automations include filling out forms, transforming data between different tools, and looping through tasks with a data list. Beyond workflows and integrations, automations can help extract information from public websites, SaaS, and enterprise applications. They can run on a schedule, be triggered based on business rules, or be run manually as needed.

Robotic process automation (RPA) platforms are used to automate business processes. They provide business stakeholders and technologists with tools to develop, test, deploy, and monitor bots.

Many RPA platforms include process mining capabilities for mapping end-to-end business processes, discovery tools for capturing the steps when using different applications, development tools to improve a bot’s capabilities, and operational environments to run and monitor production bots. Top RPA platforms include Automation Anywhere, Blue Prism, Microsoft Power Automate, and UiPath.

Raman Sapra, president and global chief growth officer at Mastek, says, “Automating with RPAs offers immense potential for efficiency gains, but success hinges on learning from common mistakes such as neglecting proper process analysis, underestimating change management, or overcomplicating workflows.”

Like all technology, robotic process automation exists on a spectrum of hype, reality, and best practices. There are many questions and hard-learned lessons about the types of problems automation platforms can solve and the risks and downsides of using them. To get at these issues, let’s look at seven common mistakes when developing RPAs.

Overpromising what RPAs can deliver

RPA provides significant opportunities, but the hype might lead you to believe that bots can fully automate and fix any broken process, integration, or data capture. I avoid calling it automation because there’s a perception that bots imply humanless, fully automated processes, which don’t require ongoing maintenance and improvements.

When developing RPA solutions, setting reasonable expectations with business stakeholders is essential. I remind stakeholders that bots aren’t magic workflow simplification pills, and developing a bot still involves code, data, and test capabilities, even when the platform provides machine learning, visual development tools, and testing capabilities. Supporting bots in production often requires making fixes and improvements. Lastly, most bots still require people to review exceptions and evaluate when they need improvements. 

Developing bots without defined priorities

Developing RPAs has one common characteristic with other development activities—there’s often more business demand than the developer talent required to support everyone’s priorities. Even when the RPA platform supports citizen development, creating a prioritization and governance process helps organizations avoid creating bots to fulfill low-value business functions.

Gregory Whiteside, CEO at HumanFirst, recommends reviewing customer data as a primary tool for prioritizing bot development. “One common mistake we see is not leveraging the voice of the customer (VoC) data available across different customer experience channels, such as call center data, live chat logs, and support tickets to inform on automation priorities and roadmaps,” he says. “VoC contains highly valuable quantitative and qualitative information that can inform what needs prioritization and what edge cases need to be handled successfully by RPA.”

Automating highly complex business processes

Let’s say you find an area where you believe RPA will deliver significant business impact. Before building a bot, how do you evaluate the feasibility and complexity of the project?

One easy way is to document a flow diagram and count the number of people, integrations, and steps involved. Automating a flow for a few people, one or two integrations, and several steps is more feasible and closer to a business task. Complex business processes involving many people, roles, and integrations may require capabilities beyond what RPA can do. In this case, you will likely need people to perform some of the steps in a semi-automated process. 

“The biggest mistake when using RPA is to fall into the trap of thinking it can automate processes, and in reality, RPA is more accurately robotic task automation (RTA),” says Aali Qureshi, SVP of Sales for the Americas at Kissflow. “RPA bots are great for automating individual, repetitive vertical tasks, but if you want to create and automate more complex horizontal processes that span an entire enterprise, you need a low-code or no-code automation tool that allows you to automate tasks and processes in order to skip hand-coding.”

As an example, say you’re automating an invoice processing workflow that requires scanning PDF documents, pulling data from an ERP, validating the data, and supporting an approval workflow. Many RPAs can automate the first three steps, but you’ll often need a separate capability to develop the approval workflow, such as a low-code or no-code platform.

Qureshi recommends, “For creating connected processes that rely on one another and can change based on certain rules or exceptions, low-code or no-code automation tools are the better option when compared to RPA.”

Automating evolving business processes

Let’s consider that you’re developing a bot for an important, high-value business task that requires only two integrations and a few steps. Does that imply that the business task can be automated easily?

Not so fast, says Esko Hannula, senior vice president of product management at Copado. “One mistake is automating a volatile process, and RPA is best used for automating the stable business processes on legacy systems that no longer change,” he says. “If the underlying systems or anything affecting their behavior is still evolving, RPA may not survive those changes and [could] cause interruptions in operations.”

Here are some examples of a volatile process:

• The business rules are evolving or have many exceptions.
• The SaaS platforms or websites being integrated change their user interfaces frequently.
• Many data or document formats aren’t consistent, and structures change frequently.
• The underlying systems are unreliable.
• Regulations around the process and data are evolving.

Automating a bot against volatile and inconsistent source conditions and requirements can be challenging. Even if a bot is constructed, it will likely require higher maintenance to support the changes.

Hannula shared another complexity factor: “If the business process is prone to exceptions that require human involvement, RPA may fail to deliver the desired return on investment,” he says.

Deploying a bot without error detection

It’s not only exceptions that can be problematic, especially when deploying bots to support critical business processes. The next mistake to avoid is deploying bots to production without data validation, error detection, monitoring, and alerting.

“RPA is relatively easy as long as one can assume it works correctly, or if it doesn’t, no damage will be done. But malfunctioning RPA can make a huge number of errors in a very short time,” says Hannula.

One best practice is centralizing bot monitoring and alerting with the devops or IT ops teams responsible for monitoring applications and infrastructure. When there are issues, their operational playbooks should account for support for bots as if they were just another application, integration, or data pipeline.

A second best practice is to educate citizen developers on how to make their bots observable by implementing error detection and logging process steps, applying naming conventions, and documenting the implementation. 

No plan for ongoing support

Bots are software, and software requires ongoing maintenance. Actually, bots may require more frequent fixes than applications do, especially if the underlying systems they connect to change frequently.

Consider a bot that extracts data from a website using CSS identifiers or other weak methods to select data from the DOM. These bots are error-prone, especially when the underlying website updates pages frequently.

Another issue is when bots coordinate flows across many integration points. One small change in a SaaS tool’s inputs or payloads means the bot will likely require support to address the changes.

“RPAs may be the right approach for older systems without APIs, but they require constant manual updating,” says Harrison Hersch, director of product at Quickbase. “The majority of businesses today use a variety of SaaS solutions, and you can’t rely on RPAs to automate, streamline, and stitch together that complex portfolio in a scalable way.”

Hersch recommends mapping out the full business process and the required integrations. “Use RPAs sparingly, if at all, despite the rise in AI-based self-healing RPAs. Instead of RPAs, consider an iPaaS strategy; it’s a proven future-proof way to solve these issues.”

Hersch mentions iPaaS or integration platforms as a service, an option for businesses that want to integrate many SaaS and enterprise solutions into robust business processes.

Treating bots as the endgame

Several years ago, I was at a conference moderating a panel on the benefits and risks of large-scale RPA deployments. I’ve forgotten who said it, but his words stuck with me: “Remember that bots are band-aids covering up legacy platforms and business processes. They’re code on top of code. Eventually, you will have to invest in app and business process modernization.”

I believe bots can provide significant business value, especially for organizations that avoid the common mistakes in this article. Bots can help reduce costs and improve quality—essentially buying time and saving money that can be applied to reducing technical debt and sunsetting legacy systems. RPAs at their best offer a high ROI. But digital trailblazers recognize they’re best deployed as part of an overall modernization and digital transformation strategy—and not as the endgame for legacy systems.