Published: May 12, 2021 – Author: Minh Chau
Years ago, when RPA entered into process owners’ consciousness,
business leaders were enticed with the promise of a constant stream of value. They were told the true potential of their processes was waiting to be unlocked with simple, low-code automations. These solutions could be released into the production environment and never cared for again, infinitely generating returns.
As the initial rush of adopters found out, RPA processes require more than good intentions to keep them running in top shape. In addition to following best practices and development standardization, any suite of process automations requires constant monitoring and optimization. Automation support is far more disruptive than the majority of practitioners expected.
Most organizations prepared to have the resources on-hand for RPA support, budgeting what they thought was necessary to cover the operations requirement. However, months and years into their automation journey, their automation programs fell stagnant, with only a handful of high-maintenance RPA processes and diminishing returns to show for it. What happened?
The True Cost of Support
Opportunity cost. At its most innocuous, it is a bogeyman, floating around the periphery of our minds, reminding us of what could have been. At worst, it brings even the best-laid plans to a slow and strangled halt. Within the context of automation support, the burden of opportunity cost is most often manifested in the dev/ops cycle.
A budding CoE or RPA group might dip their toes into the waters of automation, often hiring or re-assigning just one or two developers to explore RPA opportunities and build initial solutions. While this can be a very effective start if managed effectively, the problem occurs when organizations begin to add additional “micro-roles” and responsibilities to their developers’ workload.
Whether it’s a lack of institutional RPA knowledge or budget constraints, growing RPA programs tend to lump all of the automation tasks onto that small handful of initial RPA practitioners. If you are the best developer resource available (and you would be by default), you are also the best monitoring resource or best automation troubleshooting resource. The scarcity of RPA resources in the market leads to undersized teams of developers wearing too many hats, albeit necessarily.
Unfortunately, when developers are stretched too thin between dev/ops responsibilities, one side will suffer. With limited resources, it is often new process development that is slowed. After all, once a process has reached production status, you don’t have a choice whether or not to support it. If it breaks, and your business units are reliant upon the automation to process work, you must fix it quickly, leading new development to fall by the wayside.
Inevitably, the developer group ends up spending the majority of their time in support roles while the pipeline sits on the back burner. One of the unforeseen consequences of this is the loss of goodwill from business stakeholders toward the automation program. Once they see development progress slow or stop, interest in the automation program as a whole declines as well. This stall point can lead to the early death of RPA groups, as confidence wanes throughout the organization.
How to Break Out of the Spiral
Another problem with how the current approach to operations support lies in tier 2 services. Consisting of process optimization, re-configuration, and repair work, tier 2 support requires an expanded array of capabilities from its practitioners that is not easily filled by a small development team already tasked with development efforts.
Usually best addressed by a variety of skill sets, organizations are increasingly turning to outside partners for their tier 2 support needs. What they are finding is a landscape where this support is often offered only in the form of full-time developer resources that are underutilized and too expensive when compared to its value. Since tier 2 needs aren’t a constant draw in small, mid-sized, and even larger RPA programs, a flexible plan that allows resources — and their associated costs — to be used as-needed makes the most sense.
RPA leaders should approach their support solution with specific needs in mind to find the right solution that fits those needs. We now have a more realistic picture of RPA that depends on quality resources scaling up with the organization’s automation growth, rather than running ahead of or behind it.
With the lack of available RPA resources, business leaders are challenged to find a partner that has sufficient support knowledge as well as a desire to scale to the customer’s program requirements. The alternative is reduced value returned due to expensive support contracts, or at worst, automation program collapse due to stalled development.
Instead, as you move forward in your automation journey, take the time to identify how much effort is being diverted from your own resources for monitoring and process support. Look at the skill sets that are actively used to solve the problem. The value margin is not as wide as we once thought. There isn’t room to cannibalize the real value generated by RPA programs in pursuit of phantom requirements. Your support solution should reflect that.