Skip to main content

7 key reasons why Robotic Process Automation can fail

(Image credit: Image Credit: MNBB Studio / Shutterstock)

Paul Taplin, lead consultant at Voyager Solutions, highlights the major issues that can impact on the success of a Robotic Process Automation (RPA) project.    

1. Not engaging and getting buy-in from key business stakeholders 

The greatest single factor that can lead to a new RPA initiative failing is not having awareness or support from key stakeholders – such as the CEO, or key IT personnel - at the early project stages. This is because although RPA software sits within, and is managed by a business team, it’s still governed by the IT department using existing practices. With RPA, no robot can operate without a PC, a user account, or access to an application. IT delivers the infrastructure required and applies roles and permissions to a robotic user account. This means that without support and buy-in, you may find it more challenging to get an RPA initiative up-and-running.   

2. Not communicating RPA’s benefits to the IT department 

Although RPA is quick to implement, and minimises the need for costly systems integration, these benefits are not always fully appreciated by the IT department. The net result is that RPA adoption isn’t normally driven by IT – but by business units instead. To address this trend, there’s a growing list of scenarios that should be communicated that benefit IT department’s own internal operations. These can range from initial projects in service management and transaction processing – to resource-intensive, administrative and transactional work.    

As well as the obvious cost savings and efficiency improvements, in the short term, RPA has the potential to challenge the way that processes are fulfilled in IT. RPA will also provide future benefits too - allowing IT to digitise things that currently aren’t possible and provide valuable insights into forthcoming IT challenges.    

Ultimately, RPA puts the focus back into the hands of the process experts to drive automation projects - without the need for IT enablement projects that may be costly and run the risk of delays and overruns. With value swiftly delivered - this allows the IT team to focus on areas of core competency.  

3. Not maintaining communication with the IT department throughout delivery 

Communication with IT should not be limited to getting buy-in at the outset but become an ongoing activity.  At various points in the delivery of a new RPA process, IT colleagues can provide real support to limit any operational impacts.  For example, they can provide access to test environments for the purposes of building and testing processes, support on roles and permissions within an application, and crucially, knowledge of upcoming changes - as part of IT release cycles for an application - that may impact live processes. Regular contact with IT is important to ensure delivery of a new process is smooth – so the ‘live’ process remains operational. 

4. Not having a clear strategy for the use of RPA across the business 

Ideally, any RPA project should make businesses operate more fluidly and efficiently.  However, without a clear strategy on how RPA is going to be deployed and utilised, there is a risk that it just becomes the driving force of a standalone business function. 

Having a clear vision for the use of RPA ensures that the right RPA software is chosen to meet the collective needs of the many - not the few. For example, this could include linking RPA to strategic imperatives such as ‘increasing efficiency’ or ‘increasing agility’ outlined by the Board of Directors. This also ensures that the software can fully integrate into existing IT frameworks and support mechanisms – delivering a more harmonious infrastructure. 

5. Not being aware of the hidden costs of RPA 

Whilst recent developments in the RPA market have removed some costs, there will always be some initial expenditure to get RPA up-and-running and then to keep it operational. Budget for the build phase – including the provisioning of IT infrastructure such as databases, physical / virtual machines etc., and IT resource time to get RPA up-and-running.  Also, account for additional consultancy costs from partner companies.   

Running costs are again largely time related and centre around the ongoing delivery and maintenance of processes, maintenance of underlying infrastructure and support etc.  There may be additional roles created because of RPA, which may add salary costs.  All of this needs to be factored into business cases for RPA.   

6. Not setting realistic expectations 

“RPA is a tool, not the tool.”  RPA should not be the ‘go-to’ solution for every business problem; it is one of several options available and should form part of a wider strategy on the use of technology. There is still a need for human intervention to manage exceptions.  So, taking a human user completely out of the equation through the implementation of RPA, is likely to lead to operational challenges later.  Exceptions will be thrown due to business rules not being met and / or applications not responding as expected.  Human users need to be on hand to help address these exceptions.   

7. Not selecting the correct process for automation 

RPA works best where processes are repetitive, rules-based, high volume and do not require human judgement. It becomes more challenging where processes are non-standardised and require frequent human intervention to complete – such as interacting with customers or working with process variability. Even processes that pass the obvious criteria may not ultimately be the best ‘candidates’ for automation - at least not initially.  For example, automating an inefficient process, can potentially only speed up the inefficiency.  More benefit could be gained from either making the process more efficient, prior to automating - or by redesigning the process during the design phase of delivery.

A smooth RPA implementation is more likely to result where processes have gone through a thorough selection process using personnel the Business, IT and the RPA team. Typical selection criteria could include processes where there is an increased need for regulatory compliance and auditability, processes where errors are costly, or where the ability to scale up operations whilst minimising costs is important. Establishing clear selection criteria, and having relevant approval to proceed with automation should be the best route to success. 

Paul Taplin, Founder, Voyager Solutions

Image Credit: MNBB Studio / Shutterstock

Paul Taplin
Paul founded Voyager Solutions 18 years ago, to create solutions that significantly enhance the back office operations of over 50 FTSE 100s. Previously, he held roles at Anderson and Accenture.