As disruptive technologies continue to explode across the corporate technology landscape, a natural inclination from both business personnel and attorneys may be to draw parallels between these innovation tools and more established technologies and practices.  Robotics and process automation (“RPA”), a hotbed of exponential growth in recent years, is no different.  Increasingly, the benefits and risks of RPA have been compared to those ones associated with traditional outsourcing or managed services (“BPO”).  And while a considerable amount of overlap undoubtedly exists, the critical differences between RPA and BPO are even more striking. 

RPA and BPO: Similarities…With Distinct Differences

RPA is an umbrella term used to characterize machine-based solutions which previously required human thinking and/or oversight.  Organizations may implement RPA for any number of reasons, from something as simple as automating workflows to navigate corporate contract approvals, to conducting deep-dive data analytics for the purposes of making diagnoses in medicine.  Many of the underlying rationales for RPA use are similar to those reasons frequently cited as the basis for BPO: 1) RPA is less expensive; 2) RPA saves time; 3) RPA allows higher value resources to devote their time to higher value tasks.  The expectation is that, over time, the machine/code in the case of RPA, and the human(s) in the case of outsourcing, will become more efficient at a discrete set of tasks, thereby creating opportunities for gainsharing and improved efficiencies.

To be sure, a subset of the risks related to RPA overlap with outsourcing. Both people and systems incumbent to an organization may be displaced or eliminated altogether by the influx of RPA or BPO.  In both cases, the following issues may arise:

1. If there is a critical outage or uncertainty as to the origin of an issue, what is the recourse if employees who were subject matter experts have departed and systems have been de-commissioned?  In most cases, the very purpose of RPA and outsourcing is to reduce costs related to people and systems.  Often, putting the genie back into the bottle is a impractical, if not impossible task.    
2. When the reigns of an entire process of a business area are turned over to RPA or a BPO partner, organizations risk losing their competitive advantage to a vendor eager to share its “learnings” with other customers.  After all, one of the initial tasks in both cases is to deluge the target “worker” (in the case of RPA, the rules engine; in the case of outsourcing, the BPO partner) with as much information, institutional knowledge and underlying rationale as possible. 
3. What additional regulatory requirements emerge as a result of employing RPA and BPO?  Are there aspects involving data that will change the risk profile?  If a process is customer-facing, what are the ramifications for failure?    

In the case of BPO, organizations typically overcome the first issue by having both the internal resources and the BPO vendor staff work together on the front end to clearly define requirements and an end to end process.  While this type of business analysis may also occur in the RPA context, RPA firms are typically more agile in their staffing and resources, and securing a seasoned business analyst who will carefully and meticulously document business requirements and processes can be problematic.

In the case of competitive advantage, an argument can be made that the same contractual safeguards leveraged in BPO deals (confidentiality, trade secrets, intellectual property rights, etc.) may leveraged similarly in RPA deals.  However, the niche leaders in the RPA space are primarily startup organizations funded by venture capital firms who may have little or no tolerance for accepting contractual terms which would in effect limit the RPA organization’s ability to both learn from prior engagements and mass market those learnings to other customers. 

The issue of regulatory compliance also poses materially different risks for consumers of RPA, the most obvious one being, “How does use of RPA vary my organization’s compliance obligations?”  An additional concern is whether RPA vendors will assume the risk of compliance with such regulations.  Considering the lack of appetite from venture capital firms for assumption of risks associated with RPA, it is likely that this will be an area in which RPA vendors demand a less balanced risk allocation, even when large organizations are sitting across the negotiation table. 

RPA’s Unique Risks

Unfortunately, the risks set forth above are not the only ones presented in the RPA space.  Consider the following:

• Run, Then Sprint: While BPO tends to be “walk, then run” in term of its escalation and adoption within an organization, the dive into RPA generally tends to be a “run, then sprint” activity.  RPA vendors have become very savvy marketers, the basis of which is to introduce a user-friendly proof of concept or pilot solution which clearly shows the power and functionality of the RPA solution and ensures a “straight to production” roadmap.  In essence, the RPA provider uses the pilot period not only to demonstrate its base product, but also to perform any customizations required to make the RPA product production-ready for a customer. Furthermore, the contracts related to such pilots frequently are very brief in nature, but harsh in consequences.  It is not unusual, for example, for a license included in the pilot to automatically “kick in” after the expiration of a pilot period (unless the customer provides a written notice of termination prior to the expiration of the pilot period).  Equally, it is commonplace for such contracts to specify that the RPA vendor owns all customizations to the base code, creating great potential for the RPA vendor to freely re-market code solutions to a current customer’s competitors.  In that these marketing campaigns are launched directly to the business side of an organization, resources in legal, information security, data privacy and procurement may be left to rehabilitate the license and related agreements once the business intends to launch the solution into production. 
• Scaled Down Dollars, Resources and Track Records: Thus far, RPA solutions have tended to be quite economical.  BPO deals, on the other hand, tend to be large in scope and dollar value—the buyer stands to save a great deal of money, while the provider stands to make a tidy profit. These incentives motivate both buyer and provider to approach the negotiation table with “A” players (from a legal and business perspective) who have an eye towards measured compromise in areas other than those ones which their respective organizations have sacred positions.  Given the small scope of many RPA deals and the scaled-down staffing model for many RPA vendors, it is quite possible that legal support from the RPA vendor may be lacking or even non-existent.  A related issue is that startups, by their nature, tend to have less of a track record in terms of performance, finances and overall stability, presenting critical issues for a sourcing organization who may evaluate such innovation vendors through the same lens as more established BPO vendors.  [Recent strategic partnerships, however, may be a harbinger of things to come: in January, Accenture teamed with Blue Prism for the express purpose of providing RPA solutions to a wide range of industries.]        
• Publicity as a Double-Edged Sword.  BPO and RPA also diverge quite significantly on the issue of publicity.  While many organizations are less transparent about efforts to outsource processes (whether due to customer perceptions regarding data security, possible employee layoffs or an overall sensitivity to the politics of outsourcing), those same organizations may be more eager to publicize their exploits on the RPA front.  In the case of more conservative industries, use of RPA may, indeed, be a selling point for potential customers and an important indication that their providers are embracing cutting edge technologies, thus enabling the customer to remain competitive in its own industry.  Unfortunately, such publicity efforts may be a double-edged sword, in that service failures and/or data breaches become more high-profile when there is a publicity blitz on the front end.      

Even though RPA does present materially different risks than prior process innovations, oddly the approach to managing such risks may be a familiar one.  As a former colleague astutely noted during the early days of public cloud implementations, “things have to go wrong to go right.”   In most cases, internal resources from legal, data privacy, information security, risk management and business operations will race to assess and scrutinize exactly what was purchased, what risks it will present and what may have already gone wrong (and ways to mitigate those unforeseen risks). These actions will allow corporate teams to create a veritable “lessons learned” for future RPA deals as corporate brakes are applied to restore operational stability…until the next “disruptor du jour” arrives.