10 Barriers to Scaling your

Robotic Process Automation

(RPA) Delivery

Robotic Process Automation is great, right? Bots that complete your day to day processing instead of people. Increasing accuracy & reducing costs… who wouldn’t want that?

And yet, organisations are finding that RPA is not living up to the promise.

The fault, however, lies not with the tech, but with how people are using it. Here we’re going to break down the top 10 reasons why organisations are struggling to achieve RPA nirvana.

1. Over cautious approach (could have also called this one, ‘fear of the unknown’)

For many people, this technology is simply still too new. Maybe I’ve heard about it but I don’t understand it. What if the robot goes rogue and starts making lots of critical mistakes? What if it crashes our system? What if it sends a robot back in time to kill Sarah Connor?

These aren’t stupid questions – because people don’t know what they don’t know. So the biggest barrier is one of knowledge. People don’t need to become experts in RPA, but there needs to be growing awareness and understanding of how these things work or people will be afraid to use them. The biggest barrier then…?

Communication & Learning.

2. Rejected as a serious solution by IT

I don’t want to sound like I’m anti-IT here, because I’m not. I have my nerd badge. I’ve learned how to code. I’ve implemented IT systems. I love IT. But some Information Technology departments and their leaders don’t like the concept of Robotic Process Automation. I hear comments like “that’s not the proper way to input data into that system” or “we could create a batch process that does that” or “that reporting suite belongs in a data lake”.

The thing is – they are not wrong – but they are not right either. The point of RPA is that it provides a faster and cheaper alternative to completing something.

The question is, should they be done differently? If a data lake is 2 years and £2M away, but a series of RPA developments gets you the outcome in 6 months and £200k – that might be a better option?


100% of RPA Developments could have been done differently without RPA

3. Poor candidate processes

A favourite analogy here: If all you have in your toolbox is a hammer, everything looks like a nail.

My advice to companies is always – look at your processes. Start with your highest volume processes and start looking at how you can improve them. Watch the process in action. Understand how the customer experiences it. Look for Failure Demand and Waste in process. 

Focus on Making the Process Better instead of Looking for RPA opportunities.

I guarantee you will find opportunities to automate things using RPA.

4. Attempting process perfection

Every process has variations and exceptions. If-that-then-this. The problem is, many RPA developments try and account for as much variation and exceptions as possible – usually because that’s what the business wants. But if 80% of your process takes 20% of the development time, why would you spend a huge amount of development time for such a small incremental return?

Scope your process better than you think you’ll need to. Watch dozens or even hundreds being performed by people. Speak to expert front-line staff (avoid managers telling you what happens – they don’t know enough detail).

Agree what the bot will do and how it will handle variations. Write that down. Scope creep is a killer.

Focus on the Minimum Viable Product (MVP) that will produce the most benefit for the least effort. You can always build more complexity later (if that’s the right thing to do).

5. Lack of appropriate infrastructure

If your RPA processes are important, they are going to need a Disaster Recovery solution. And with that requirement comes additional costs and management (and testing). If they are not business-critical, they might not need one though. It’s all about managing risk.

You’re going to need virtual machines (you really don’t want a room full of physical computers on desks being operated by invisible robots).

You’re going to need servers, they need to be managed and supported. Be smart with your requirements and avoid under-servicing or over-servicing your requirements.

6. Lack of integration with IT development & support

If you’ve had a ‘business-led’ implementation of RPA (which is cool) then there’s a good chance that the RPA development team is not plugged into IT the way it needs to be. This is OK when you’ve only got 1 or 2 processes but it becomes a real problem, real quick when you have some scale.

You need to be on distribution lists. You know, the ones that say when planned outages or core systems will occur? Or the ones that tell you a planned upgrade to a core system is being released? 

Who’s going to support the developments? Who’s the first line of support? IT help desk or RPA devs? How will your coordinate effort with the Network guys if that turns out to be the issue?

You need to be working in coordination with IT – which can be a real problem if IT don’t view RPA as a serious solution (see #2).

7. Constrained investment

If you’re going to seriously deploy RPA, you need to invest in it. You’ll need to hire or train (or both) some people in whatever RPA platform you choose.

Don’t rely on consulting firms as your single source of RPA development. Consulting firms are great to help get you started, put the right things in place, set you up for success and help you provide flexible resource when your demand outstrips your internal supply. But you’ve got to have some internal capability. You’ll need this for when something goes wrong or a change is made and you need to respond quickly to alter the RPA process to get it up and running again.

Make smart choices about your costs. Doing it externally will always be more expensive than internally. But you might need 10 developers for 12 months and then 4 developers thereafter. Using a firm to help with short term demand is really, really helpful.

8. Lack of awareness

About 12 years ago, I was improving processes in an organization. I found a staff member whose job it was to report on SLA performance. To do this, they were manually counting the start date and end dates on an excel spreadsheet to work out how many days had elapsed. For 1,000’s of records, every day.

When I asked if they knew a formula could calculate this for them, they replied: “Yes, but using a formula doesn’t take into account weekends, and our SLA report is based on working days only”.

They didn’t know about the NETWORKDAYS formula in excel which can discount weekends and public holidays. 

My point is that the end-users of processes, the ones who know the processes better than anyone else are likely to have a very low awareness of RPA (or probably none at all). Same goes for first-line managers. Spend some time teaching people about RPA. Run Lunch and Learn sessions and roadshows. Get people interested and excited about what RPA can (and equally importantly what is can’t) do.

9. The unnecessarily high cost of development

Every RPA development must have a dedicated development environment, a UAT environment and a production environment. All systems it intends to access must have a development version to do the build. Test data will need to be sourced and applied to the Development and UAT environments. 

Except it doesn’t. There may be some examples when the above is appropriate – but they are not the majority and should be scoped and cost from the outset so you know what you’re getting into. 

Here’s the thing about RPA – it’s using the User Interface. This has already been exhaustively and thoroughly tested before going live. The Bot isn’t going to use the system any differently from a person. Yes, it needs to be tested – but you can often do developments and testing on the live system. There are reasons why sometimes you can’t or shouldn’t, but they are usually the exception, not the rule.

You’re NOT developing applications. Don’t take the standard App Development framework and apply it to RPA. 

If you’re taking a full App Dev approach then your costs per RPA deployment will be at last 2X the cost and can be as high as 6X the cost.

10. Governance from hell

Does something like this sound familiar?

That idea will need to go to the Centre of Excellence Governance Forum. Once you’ve spec’d it – it will need to go to the Architectural Review Board. You’ll then need special dispensation from the Digital First Steering Group. From there we go to the Product Board. Data Protection Board will need to approve and authorize the use of data. It will then need a pass from the Resilience Committee and then you’ll need the solitary tear from a Himalayan yak before Finance sign it off.

Or you can just stare at a wall for three months and be more productive.

RPA is a great technology that can help reduce shadow IT and end-user solutions (like Macros and Access databases) that many organisations use to plug process efficiency gaps. It is a really valuable tool in the toolbox of process improvement.

But it’s important to learn from the mistakes of others to make the most of your investment.

Cameron Turner – Lean Consulting