Real Challenges to RPA Success
My previous blog post demonstrates that Robotic Process Automation (RPA) can be a real game-changer in terms of cost reduction for an organization. The benefits are clear and tangible, and it is relatively easy to put together a business case, but challenges remain…
If RPA is looked at in relation to one of the hottest problems in the financial services industry, legacy modernization/replacement, then on the surface it can seem like an attractive proposition. Why undertake the sometimes difficult and risky process of transforming a legacy environment, when it seems an obvious and simple solution to simply install a layer of RPA over those legacy systems to produce the facsimile of a modern and efficient IT environment? RPA is seemingly cheaper and quicker than full legacy modernization…
This will work in a small number of cases. A financial services organization, looking to install best practice processes, with no legacy hangover (a greenfield site), can almost certainly reap the benefits of an RPA program instantly. But very few financial services organizations, and only a minuscule percentage of insurers, can truly say that they have no legacy.
Once the complications of legacy environments, the frequently misunderstood behavior of end customers, the uncertainty of future change, the rigidity of robots and the caprice of regulation are taken into consideration, the picture is not so clear.
The first and obvious point of caution is that labor arbitrage should not be measured just on the savings that it offers in the short term, which will always be substantial, but rather on the potential costs that it defers to future years. These costs can be summarized into two types: the cost of attrition-based erosion of savings, and the growing cost of organizational technical debt.
Attrition is the enemy of all legacy systems, as simply put, the less business you have on a system, the more the unit cost of that business. It’s a simple inversion of the economies of scale. On the surface, labor arbitrage through a traditional “lift and shift” model (legacy systems administered by a third-party administrator with no technical transformation, for example) offers a way of deferring that cost. This happens through cheaper operational cost, as a result of reduced labor costs. But it is self-evident that once the volume of that business attritions to a certain point, the cost of managing it exceeds the revenue generated by it. And as legacy systems proliferate, the cost to the labor arbitrager is increased as more low-volume processes need to be supported.
RPA does not resolve this problem. RPA is, in the simplest terms, a different form of labor. RPA that supports a small enclave of perhaps a hundred policies requires support and possible change (from regulation, for example). It incurs a fixed cost that no amount of arbitrage can remove.
Technical debt is a second cost aspect of the legacy environment that is not fully resolved by the implementation of an RPA program. Technical debt, as described by Ward Cunningham, results from the “cumulative consequences of corners being cut throughout a software project’s design and development.” For companies with legacy technical debt going back fifty years, the interest on that debt is massive.
An RPA program will resolve some of the challenges caused by the technical debt. In theory, RPA exposes the rules and structures that define a process in a more manageable way than is possible with the legacy system. But RPA does not replace the legacy code, and therefore there will always be times when that code requires change (adding additional data items, for instance). Adding a layer of RPA without transforming the underlying legacy code simply defers problems until tomorrow, increasing the technical debt.
To learn about four additional challenges, please check out my white paper: Maximizing RPA for Financial Services Transformations.