Amidst the relentless robo-hype in our current era of robotic rhetoric, it’s fast-emerging that many buyers and service providers are really struggling to work together to create workable Robotic Process Automation initiatives – in many cases, neither are willing to make the necessary investments, trade-offs or sacrifices to make his work.
So let’s start with those selfish service providers unwilling to share the robotic rewards…
Some service providers want to implement RPA on themselves and avoid passing on the savings to their buyers. Having come off a great many buyer discussions about their developing Robotic Process Automation (RPA) capabilities to augment their BPO engagement productivity, I have been shocked to hear a common thread from several buyers: their service providers only want to implement RPA on themselves and insist on charging their buyers the same legacy FTE rates. Some service providers simply cannot stomach sharing gains with their buyers – some have, but the general experience, from the buyers, has been they are not really interested. And one of those service providers even boasts its own “cannibalization fund”, while refusing to do anything different with several of its biggest engagements. It’s quite mind blowing how contrary some of these service providers can be, when it comes to what they claim they are doing versus the reality of what they really up to.
Yes, amidst this talk of the leading service providers breaking away from the old model and openly exploring ways to invest in initiatives to delink headcount from revenue, it would appear that some are simply playing lip service to the industry while, in reality, they are just looking at RPA as a vehicle to drive down their own costs and improve their margins, while maintaining their legacy FTE-pricing. One buyer even mentioned to me that their service provider had the nerve to ask them if they could reduce their own staff delivery headcount using RPA, but keep charging them the same FTE rates…. no joke.
However, this isn’t just the fault of the service providers, many buyers are equally to blame for robotic restraint…
Buyers need to entrust their providers with more intimate data access. Most enterprise buyers, for security and control reasons, keep the providers at bay and force them to connect to their systems only using Citrix. This limits the effectiveness of RPA overall and encourages an “us versus them” mindset between buyer and provider, so it’s no surprise service providers do what they can on the other side of the “Citrix” firewall. Both parties cannot enjoy the full benefits of RPA and Intelligent Automation, without genuine collaborative engagement and a holistic security model that aligns the capabilities more effectively.
Greedy buyers need to stop treating RPA like legacy offshore BPO, demanding all the savings up front. I would also argue that many costs of RPA –greater testing, maintaining a fall-back agent pool and the incremental manner that robots are typically actually rolled out (versus a one time overall reduction in costs, as often asked by buyers) diminish the “greedy” aspect of this from many service providers. In addition, many buyers want royalties for advancing the automation initiatives of the sell side – there is a whole new business model evolving around access to data as well as contribution to IP, when it comes to developing effective RPA platforms.
Sadly, many buyers are often too greedy and want to get all the theoretical cost savings from a new deal up front, even before the RPA benefits have been formalized – and without realizing that RPA often drives up service provider costs in the short term for increased testing and QA. In this way, buyers are keeping the mindset used in legacy outsourcing deals, where savings driven through labor arbitrage were much more predictable and tangible. I would argue that many costs of RPA – a great deal of testing, maintaining a fall-back agent pool to mitigate transition risks, and the incremental way that robots are actually rolled out (versus a one time overall reduction in costs as often asked by buyers) put the service provider in a much riskier position to guarantee productivity benefits and cost efficiencies, than they ever were with their legacy outsourcing deals. Robots are not as easy to plug into legacy processes as offshore labor…
So clearly we are rapidly arriving at a juncture where a couple of scenarios will play out as to how buyers and service providers make RPA work…
Legacy BPO deals will continue to stagnate for some time. In most cases, deals struck several years’ ago have met their initial productivity targets through offshoring and some basic process standardization. The service provider has no incentive to do anything but maintain the same rates and same margin, and most are willing to risk their buyer trying to bring in a competitive bidding process. They know that in many cases, their business is not that attractive to other providers, and the cost of switching outweighs the benefits of “winning” the business.
Where we will see the advent of Robotic-led BPO solutions
Definition of Robotic BPO: “Applying robotics to transform legacy business process outsourcing engagements that were developed with a legacy FTE pricing and mindset. Deals are wholly or partially financed by the anticipated future headcount reduction and productivity improvements driven by the RPA, where the buyer and provider share the risks”.
It’s very rare today that RPA results in the elimination of entire job roles for staff in the BPO world (less so than with IT automation). Hence, we view an emerging focus on human-augmentation robotic solutions that combine people-driven processes with genuine RPA capability where it is cost effective and secure to implement.
We are already witnessing a serious potential for service providers to offer RPA-led offerings to streamline bloated stagnant BPO engagements, especially where there is a lot of very automatable offshore work that is efficiently run with well documented process flows. Enter R-BPO, where we will surely see the first automation-led human augmentation solutions, where the deals are largely funded by the headcount reduction over time through . We believe this will be especially relevant in F&A contracts which form the baseline of the BPO market today
Once we get passed the constraints of Citrix and the non-collaborative application and data security strategy of many enterprises there is real opportunity to reshape the market of F&A BPO contracts. In Finance and Accounting, many deals are mature and rooted in legacy models, the work is highly transactional, and buyers have been stuck with the same FTE loads for years (or decades). But the real reason why F&A is starting to deliver real potential for R-BPO is the simple lack of widely accepted enterprise F&A SaaS which can fix the dysfunction of a process, with a broad-brush implementation and hefty license fee. We are seeing it in pockets with SaaS solutions such as Workday FM, Netsuite and even FinancialForce, but it’s the ultimate failure of F&A to over-rely on legacy technology, maintain strict controls that defy collaboration, and keep bloated numbers of people to deliver legacy processes that is creating a huge potential new market for robotic-led processing and human augmentation.
The Bottom-line: Legacy BPO may be stagnating on its own, but it’s ready for R-BPO
What’s abundantly clear is that the outsourcing industry is caught in one bloody great rut: too many engagements are simply stuck in this Catch-22 where they are no longer attractive to competitive bids and the incumbent providers simply do not see the value (or have the onus) to invest in the buyer. You can’t trim the fat until you fix – and automate – the process underbelly, and today’s emerging RPA tools, such as Automation Anywhere, Blue Prism and UiPath, are increasingly providing the platform to do that. So the next phase is for R-BPO solutions to be come to market that are priced against future productivity gains through automation, not immediate cost-savings through labor arbitrage and elimination.
(Cross-posted @ Horses for Sources)