The business case for Robotic Process Automation (RPA) couldn’t be clearer: robots can be implemented in a matter of weeks, they cost a fraction of a traditional labor force, work 24x7x365 if need be, never make a “mistake” and never take a tea break or go on holiday.
What more could you want?
Intrigued by the possibilities, many organizations are at this very moment assembling a business case based on the benefits of RPA. They run a proof of concept and all the calculations jibe with projections. “Great,” says the Boardroom. “Let’s get implementing and roll this out!”
But there’s a catch. Most organizations only consider the implementation costs of hardware and software costs related to RPA. In so doing, they fail to consider additional risks and costs that can lead to underachievement of anticipated benefits. And a disappointing roll-out can ultimately derail an enterprise-wide rollout of RPA.
An effective business case for RPA must consider the TCA or “Total Cost of Automation.” Main items to include are:
- Monitoring and improving: While robots don’t require “supervision” in the traditional sense of the term, they do require oversight to make sure they are operating properly. Equally important, monitoring is necessary to measure performance and analyze data to drive further improvement.
- Support: Automation software is similar to middleware in the sense that someone needs to support and maintain the programs on an ongoing basis. By way of analogy, a SAP implementation has, in addition to its development team, a separate support team. RPA software is no different.
- Fragmentation: Because RPA is quick and easy to implement, we often see individual business units independently rushing out to automate process after process. This results in pockets of automation – each with its own automation experts – appearing throughout the enterprise. If resources and expertise aren’t shared, total costs will naturally be higher.
- Upgrades: The cost of upgrading the RPA software must be considered – specifically, of the planning, regression testing and possibly re-implementing required to take advantage of new features or changes in features.
- Testing: While agility is a key benefit of RPA, “agility” does not mean that the standards and process discipline of IT can be bypassed. RPA requires a rigorous testing regime.
- Governance: Many businesses fail to consider the time and potential costs associated with changes to operations or activities associated with the infrastructure. For example, the SLAs for a server reboot are rarely aligned with the agility of business in the RPA world. This could mean unanticipated delays and extra costs, especially at critical times of the day.
- Architecture: While businesses with embedded IT organizations involved in system design generally have this point covered, we often see clients who have all their VMs in a single physical machine, with little consideration given to business continuity planning or even general performance. This creates the potential for having a majority of critical processes automated and running on a single physical machine. Under the circumstances, an outage can have a significant business impact.
RPA clearly offers significant costs savings, improved quality and knowledge management and much more. However, the wide range of indirect and operational costs associated with RPA must be considered to set realistic and achievable expectations within business units and among the executive team. Building the right business case and support model – from the outset – is imperative.
