- 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.
- 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.
- 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.
- 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.
- 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.