Compared to many other development tools and patterns, Robotic Process Automation (RPA) is an easier and often faster technology to implement. Because of this, many businesses are racing to get their processes automated and see returns as quickly as possible. This isn’t a bad thing, and there are many success stories out there. But it also means it can be easy to overlook some key factors, particularly when the RPA program has been kicked off outside of the IT department.
Over the last three years I’ve worked on over 10 different RPA development projects, spanning government, finance, health care, aged care, and HR, with different clients, development standards and teams. Whether I was working as the sole RPA developer or in larger teams of devs, I often saw the same mistakes when projects started to struggle, and the same missed factors when time was of the essence. Below I’ll share some of these key lessons to help ensure your RPA program can find rapid return for your business, while also protecting the quality and durability of those automation investments.
1. Talented Business Analysts are Gold
Business Analysts (BAs) are a critical part of software development, as they act as the ‘translators’ between business needs and technological solutions. Without them in the middle, developers may go down a path that doesn’t solve the original problem, and business people/subject matter experts (SMEs) can form unrealistic expectations of what technology can and should do for them. This is an even bigger challenge for RPA, where development work involves many stakeholders and occurs a lot closer to the business than in other forms of software development.
I’ve worked on some RPA projects that had fantastic BAs and some that had none at all, relying instead on developers and SMEs to bridge that gap. This isn’t entirely unachievable if you work in a smaller company and don’t have the time or resources to have an experienced BA, but it does require either your developers to build a solid understanding of process analysis and business context, or SMEs who understand logical analysis and what RPA can and can’t do. This a big ask from your staff on either side, and can distract from their primary role. Because of this, I would always advocate hiring (or even just training up) a dedicated Business Analyst to help bridge the gap.
2. Get Process Mining Right
On one of my recent projects, we were set to automate a process that involved a large number of decisions and business rules. The longer we worked on it, the more complex it became until the automation became almost unworkable, failing due to business exceptions almost every time it was run. Not only was this very frustrating for us as developers, but it was also costing the business more every day as they saw no return on their investment.
The problem here was not RPA itself, but rather it was a problem with the selection of which processes should be automated. RPA is an extremely effective tool but only in the right circumstances, and it was designed primarily to target the low-hanging fruit – simple, repetitive, unchanging digital processes. It simply can’t handle complex decision making or uncertainty without other add-on technologies, more development effort, and different sets of skills.
The good news is that there is often a huge number of low hanging fruits in many large organisations, all very automatable with RPA. The lesson here is really just to a) choose the right processes to automate by b) ensuring the people choosing processes are well informed and rigorous in their work. Accountability is crucial; having a siloed process mining team throw processes over the fence to be developed increases the likelihood of wrong-fit choices for RPA. Whereas having the process mining and development teams work together – and promoting an understanding of what RPA can and can’t do in the business – will ensure a far more successful outcome.
3. The Right Amount of Governance
Governance can sometimes be overlooked in RPA but getting it right can be even more critical in an RPA project than other kinds of software development. This is again due to the large number of stakeholders involved; when building an app, most stakeholders won’t mind too much how you go about it so long as it does its job. With RPA on the other hand, you are often working directly with SMEs and other business stakeholders on processes that are intrinsic to their daily jobs.
With so many people looking to contribute to a project (and many of them not experts in the technicalities of RPA) it can be easy to overdo or undercook governance. An RPA project needs very clear roles and expectations, and you need to set development standards, approach and patterns early. These standards might include important decisions around peer review and development lifecycle processes. Getting these aspects of governance in place early is reflected in the quality of development and the resilience of the automation.
Of course it’s also worth talking practically about the perils of too much governance – the same as any project, heavy-handed governance, too many rules or unnecessary revisions can slow down the project, increase costs and even restrict developers from doing their best work, (my colleague Simon McCabe discusses this topic a bit further here.) Finding the balance is key.
4. Understand the Whole Process
I’ve worked on a few projects where development work started before the Process Design Document (PDD) was even 90% finished. These were projects that tended to miss deadlines, go over budget and result in lower quality automations. The PDD needs to be finalised early in the process (similarly to the development standards and governance above) because it will set the plan for all the development work and be the essential guide for achieving an end product that meets requirements.
Scope creep is a major consequence of an unfinished PDD, as well as unexpected business exceptions and added complexities. When automating processes to the granular level, what looks like a simple step can actually be quite complex, so it’s important to capture the full process in the PDD before you begin development.
The way automation affects downstream processes also means even parts that occur off the computer should be taken into consideration to prevent bottlenecks. For example, a bot which creates invoices really quickly but cannot proceed without human intervention may just result in a manual backlog of human processing tasks, resulting in an automation that doesn’t deliver the desired efficiency improvements.
5. Workplace Culture will Affect Success
RPA – like all technology – doesn’t occur in a vacuum. Across the many projects I’ve worked on, the culture and people of the organisation is a consistent indicator of success. Politics, divided agendas and unclear roles and expectations can all set an RPA program back significantly, as can an uninformed workforce. SMEs need to understand what RPA is and isn’t, how it operates and how it will benefit them in their daily work (they can also contribute themselves as Citizen Developers, which we explore in another blog here). Change management makes up a large part of our work in implementation as RPA can easily feel disruptive without the buy-in from frontline workers. The key is to inform and upskill employees to encourage a positive reception of the program and help employees move into higher-value tasks as the process automation work is delivered.
Liked this content? Sign up to receive more automation insights from the Intelligent Pathways team:
