We have a 98% success rate for automation. Here’s why.

In recent times, there has been much press about the high failure rates for RPA projects - as high as 50% (according to EY). Having automated 500+ processes over the last decade, with a success rate of ~98%, I wanted to share three simple tips to help avoid failure with your automation projects:

1. Be prepared to say “no” as often as you say “yes” to automating a process.
2. Take the time to understand the business behind the process.
3. Minimise your technology footprint

Each of these three points are described in detail below.

Why should you care (and read this post)?

While automation is not hard, it isn’t easy. No matter what people might tell you. Automation will require an investment of your money and attention. It will also lean on your staff to devote some of their own time - as staff often play the critical role of “subject matter experts”, helping the Process Designers develop the automation.

10 years ago, we needed to convince people about the merits of automation. The idea of whether or not you should automate was up-for-debate. Times have changed. Everyone gets it now - automation is a no-brainer. However, the decision to automate can be nerve-racking for Finance leaders. Commentary about high RPA failure rates doesn’t help. You can forgive companies for chasing comfort and safety, either by not automating at all or by attempting to shift accountability to your IT department (more on this in a future post). But it’s only in spite of fear (rather than the absence of fear) where true and meaningful transformation can take place.

To press forward in this sometimes chaotic automation environment, here are three simple rules to consider.

Rule 1: Be prepared to say “no, we shouldn’t automate that process”

Automation software vendors and the services eco-system have an incentive to say “yes” to everything. The problem with this approach is that it inflates expectations and leads to failure. The hype around automation at the moment is such that many people want to believe that “bots” can easily and effortlessly automate massive amounts of work across their company. A desire that sales reps are more-than-happy to take advantage of. Terms like “Intelligent Automation” only help to fan the flames.

Successful automation only happens when you have considered not just the technology but also the process and your people:

Selecting a process that is amenable to automation is an obvious first step. We use a simple, acronym, R.E.A.D.Y. (learn more), which asks if your process is:

• Repeated - Is the process done on a regular basis, following largely the same steps?
• Expensive. Does the process consume lots of staff time or having a high cost of error?
• Action-based. Do staff follow a series of actions that can be distilled down into a list and repeated by a machine (or computer program)?
• Dependent. Is the process dependent on the humans that currently do it?
• Yes. Then you should consider automating.

A process being r.e.a.d.y is not enough, however, you also need to ask yourself:

1 - Do your people actually understand the process?

Staff often inherit processes when starting their role. Be wary of processes where staff are simply cranking the handle. Particularly when staff don’t have a real appreciation of what value the process is delivering to your company.

If your people don’t understand the meaning behind their work, what are you automating? How will you know what outcomes drive value for your company? Remember that time savings, while an obvious benefit, are only a small facet of the outcomes that companies derive from automation (learn more here).

2 - Is the environment around your process likely to disrupt your automation efforts?

Are there things outside of your control that are likely to disrupt any attempt at automating the process? Are you changing your GL? Are you about to do a massive restructure that is going to entirely change how you segment and consolidate reporting? Take an objective look at what changes could truly disrupt your automation initiative.

Form a risk matrix that alerts you to any high impact and high likelihood risks. Mitigate against these risks (otherwise risk automation failure).

3 - Should you replicate or re-engineer the process?

Just about every processes we’ve ever seen automated has had at least some re-engineering applied. Re-engineering often manifests itself in two ways. You add “features” to an existing process or add error handling capabilities. Naturally, re-engineering needs balance. It is very easy to increase the scope of an automation project by adding more and more “nice-to-haves”. Eventually, to the point where delivery fails to meet time or budget.

Whenever a company approaches us to automate a process, we always consider the points above. Most importantly, we are prepared to say “no” or “not until you do XYZ” - where “XYZ” could include, taking the time to properly understand the process.

Rule 2 - Take the time to understand the business behind the process

People can easily forget “Business” in “Business Process”. When collecting information about a process from subject matter experts, simply writing a checklist of the “steps” in their process is important but not enough. You need to ask questions like:

Why does the process exist? Why does it matter to the business?

The aim of this question is to determine the precise value that the process gives to the business. This is important because it tells you at a minimum, the value that the automated process needs to deliver. However, this also helps uncover new “features” you can bring to the table that will add even more value to the company.

Who are ALL of the stakeholders?

Think beyond the person who does the work and perhaps their boss. Who is responsible for data that flows into the process? Who uses information and outputs generated by the process? What value does this process give to each of these stakeholders?

What happens when things go wrong in the process?

Try to uncover several examples of when the process was not completed “to script”. This is really important as it will highlight “exceptions” as opposed to the rule - exceptions that you can then build for in your automated solution.

Communicate your understanding of the process back to stakeholders in a language they will understand. This is not an opportunity to show off your amazing knowledge of UML and BPMN. Create diagrams that are simple enough for anyone in the business to understand, using language that is relevant to the SMEs.

Minimise your technology footprint

The final rule for success is to minimise the amount of heavy lifting needed by customers in regards to technology. All too often, we see companies, when trying to automate, having to:

• Purchase and set up servers (such as virtual machines) and allocate IT staff to perform ongoing maintenance.
• Purchase, install and maintain data storage capabilities like a SQL Server database or a data warehouse.
• Install the software on end-user machines.

This challenge with this approach is it increases the time and cost for automation dramatically. For many companies, the outcome is that many processes simply don’t present a high enough ROI to automate. One of our banking clients once told us that they needed a 20 FTE cost saving before they would even consider automating a process using RPA! The problem with this approach is that there are thousands of processes in large companies that do not take up massive amounts of resources. These processes, however, are often responsible for producing information that goes to regulators, customers and the market. Requiring an IT project to automate sadly means that many of these processes remain manual.

Our approach for the last decade has been to automate via a simple, cloud platform. The benefit of this approach is that our customers are up and running in minutes. They require no IT project. They don’t need to buy and set up servers. They don’t need to purchase SQL Server and hire database administrators to manage their database. This allows companies to focus entirely on the automation itself and start experiencing the benefits from automating much faster. It also allows companies to automate many more processes (due to the lower ROI that is needed to automate).

Conclusion

Automation can be scary. Recent news about high RPA failure rates doesn’t help. But it doesn’t need to be. Automating 500+ processes, with a 98% success rate has been a result of three simple rules:

1. Being prepared to say “no” as often as you might say “yes” to automating a process.
2. Taking the time to understand the business behind the process.
3. Minimising the technology footprint needed to automate.

You can learn more at solvexia.com