Contracting for RPA – The opportunities and pitfalls
Robotic process automation (RPA) is at a pivotal moment, firmly hitting the mainstream when it comes to digital transformation and more traditional BPO procurements.
Organisations have, of course, been dabbling with RPA for a number of years. However, a combination of maturing technologies from specialist providers, a concerted focus on RPA by more traditional players and changing workforces, have pushed RPA to the fore.
There are many real world benefits to RPA deployment. RPA can offer accuracy, scalability, inherent monitoring and data management capabilities amongst other benefits.
RPA deployments forming part of wider outsourcing arrangements, can present increased risk to the customer organisation, intensifying traditional hazards that should be considered in any contract for RPA. Below we focus on three key areas; implementation, maintenance and change control, and vendor lock-in.
Implementation risk
RPA deployments are often highly bespoke and the approach to design and implementation is often specific to individual business lines and processes. This presents unique challenges for deployment at scale:
• Project scope and phasing: Is the customer locked-in to a wider roll-out from the outset? Many projects will include an initial pilot or proof of concept phase. However, successful roll out to one set of processes or a particular business line does not guarantee success in other areas. It is important to document the circumstances under which a customer can walk away or source the RPA elements from an alternative vendor, not just following an initial pilot phase, but as the wider roll-out progresses.
• Acceptance testing: The contract should include robust acceptance testing procedures, both vendor testing and end user testing, to ensure the deployed robots function as expected. Acceptance criteria are often left to be determined post-contract or documented in vague terms that lead to disputes as implementation progresses. It is important for the procurement and business functions to work together to document what ‘success’ looks like in an objective, quantifiable manner.
• Price impacts: The contract should also address price impacts of failed or delayed roll-outs, particularly where the provider has baked-in assumptions based on RPA deployments. Which party takes the financial risk of failed deployment will depend on a number of factors, but should not be left as an ‘agreement to agree’. Common issues include the reason for failure (something that can be surprisingly difficult to determine and is often the result of a complex web of circumstance), whether the RPA solution was sourced direct by the customer or the vendor, whether the customer ‘imposed’ its preferred solution on the vendor and the degree to which the vendor has been granted ‘free reign’ to deploy RPA.
Maintenance and change control
Responsibility for ongoing maintenance of RPA tools is an issue that sets RPA apart from other types of system deployment. RPA tools are often highly sensitive to underlying system and software changes. The issue to
• Ongoing maintenance: Which party will be responsible for ongoing maintenance? Will the vendor be providing an ongoing, managed service, or will a third party vendor or the customer itself be responsible? In a multi-sourced environment, who has overall responsibility for planning and coordination? If a third party vendor is to establish a ‘centre of excellence’ or equivalent team, will that team be employed by the vendor or the customer?
• Change control: Which party will be responsible for the provision and cost of change and maintenance resulting from changes to the customer’s wider IT environment? This might include changes to hardware, software (including version upgrades), changes to data feeds and structures, all of which can have significant impacts on the functioning of the RPA solution. Again, this should not be left to be dealt with through the contract’s change control procedure as these are key operational issues that will arise on a regular basis.
Avoiding vendor ‘lock-in’
Vendor and technology lock-ins are a key risk in any RPA deployment. A key consideration for any customer will be whether to source their chosen RPA technology direct or through their outsourced service provider. In either case, the contract should address whether the customer will be permitted to use the solution on exit and migration to an alternative solution.
• IP ownership: Who will own bespoke developments and scripts relating to the RPA deployment?
• Exit: If the RPA solution is being provided through an outsourced provider, will the customer have a right to purchase its own licence on exit?
RPA deployment as part of digital transformation and outsourcing projects must be given special consideration in the vendor contract to the possibility of undoing the real world benefits that RPA deployment can deliver to the customer organisation.
By partners Mike Pierides and Simon Lightman at global law firm, Morgan Lewis
Mike advises on matters relating to new technologies such as blockchain and artificial intelligence following major outsourcings, strategic restructurings, and technology-specific transactions such as licensing and “as a service” arrangements. Email: mike.pierides@morganlewis.com, Phone: +44.20.3201.5686
Simon advises on a broad range of commercial, technology, and data transactions, particularly in the context of robotic process automation. He advises on complex outsourcings and procurements, software licensing, and cloud and other “as a service” arrangements. Email: simon.lightman@morganlewis.com, Phone: +44.20.3201.5625
