The use of robotics in existing IT delivery models is fast becoming a whole new sector within the IT services industry. Known as Robotic Process Automation or RPA, this new technology is being seen as the next wave of innovation and improvement across many existing IT service areas.
This has come to recent prominence in relation to application development, off shoring, outsourcing and systems integration whereby robotic processes (or digital workers) are being used to replace human involvement and full time equivalents or FTEs (the unit of measurement commonly used to calculate cost for the use of individuals in providing services).
The effect of this is that robotic processes are being seen as a new way within which cost can be driven out of some of these IT service delivery models. It makes sense that, given the removal of FTEs, costs should decrease and the method of delivery change to be ‘product’ based rather than service based.
Indeed, in a study in 2013, McKinsey & Company estimated that if the use of robotic processes grows at the rate expected, then by 2025, as many as 110 to 140 million FTEs will be replaced by automated tools and software.
This has obvious advantages for suppliers and customers alike – but the impact for the offshoring industry, where its growth has been underpinned by the wage arbitrage effect, could be vast. No longer cheaper, it will have to adapt.
What types of services will be affected and how?
Services which are most likely to reap the benefits that RPA promises to deliver are those that are based upon repetitive, rules-based processes which are high- frequency in nature.
There are many examples of these across a wide variety of industry sectors but most commentators believe that the banking and insurance industries, healthcare and logistics will be the areas where uptake is likely to be at its greatest. Specific examples within the banking sector would include:
- Account analysis;
- Payment processing;
- Credit checking;
- New product marketing campaigns; and
- Client detail updates.
For insurance, examples would include:
- Payment protections claims;
- Automation of administration;
- Reinsurance processes; and
- Data collection, cleansing and analysis.
For healthcare, one could look at:
- Patient database changes;
- Appointment changes;
- Drug administration; and
- Facilities management administration.
Every customer that adopts RPA as a new technology would look to obtain certain benefits from doing so. Cost savings would certainly be one – if not the most important – of the considerations but there are others.
As RPA integrates with existing legacy systems, one additional advantage would be the ability to obtain ‘better’ data and feed it into related applications. This would mean that the likelihood of data errors being compounded by human error would be reduced, allowing the enterprise to make better decisions.
Technology in this area is advancing rapidly and the use of cognitive computers and augmented systems (more commonly, and incorrectly in the author’s view, termed Artificial Intelligence or “AI”) allows for unstructured data to be collected and analysed far faster than humans are capable of. This is adding to the list of advantages that RPA is presenting organisations because they now have access to data within a time frame and in a form that is far more useful than previously imagined.
It is not all bad news for the FTE, however, as increased productivity; higher levels of customer satisfaction and removing repetitive tasks from the human workforce should increase levels of worker satisfaction as well as release them to perform higher value tasks.
What will be the impact on commercial contracts in the IT services industry and beyond?
Pricing:
As RPA is providing a different solution to end user customers and is delivered differently by suppliers, existing contract models may have to be adapted to provide for this change.
If we take the example of an insurance application and premium administration service, which is currently outsourced by a customer to an offshore based company, this service is normally provided by the supplier subject to the terms of a service agreement and priced, mainly, with reference to FTEs.
The software and support that sits behind the process is usually invisible to the customer but the scope of the services, the level of services and the cost of the same is transparent and is managed via the terms of the agreement between the parties. Therefore, any required interaction between applications will form part of the services scope and will be performed by FTEs and priced accordingly.
An RPA solution which adapts how a supplier provides its services to its customer may not necessarily be required to be spelt out via a contract change because the customer still sees the same service being provided to it.
However, if there are specific reasons why a customer would need to understand how the service is provided, for example because of regulatory compliance reasons or because the customer has a risk/ reward agreement with the supplier for any cost savings, then the nature of the RPA may need to be fully described and added as a variation to the existing agreement.
The implications, therefore, of systems automatically making decisions in regulated areas without human involvement may be quite serious and this may result in some of these RPA solutions attracting the interest of relevant regulators if, for example, these systems are providing financial advice to end users.
Intellectual Property:
There may be intellectual property (“IP”) considerations to be taken into account when looking at the nature of the delivery model. Suppliers tend to contract on the basis that they will own their own IP that is used to provide
the services and any other IP is either licensed from a third party or provided by the customer. The ownership of any IP developed during the course of the agreement is usually the subject of debate between the parties but more often than not, if it is bespoke development for the customer, then the customer will own the IP in such development.
Such IP is usually created by the FTEs and assigned to the customer via an agreement – but what happens with any IP or database created by the robotic process software/hardware itself?
Most likely, such generated work will take the form of a software program and would therefore be copyrightable under English law and made subject to the terms of the Copyright, Designs and Patents Act 1988 (the “CDPA”).
The CDPA already makes provision for works created by machines and defines ‘computer generated’ works as works generated by a computer in circumstances such that there is no human author of the work. It is not sufficient for a work to be carried out via a computer – that would not satisfy this definition – but rather the computer itself must create the work according to a programme without a human having been involved in the creation.
Regarding ownership of copyright, the normal rule is that the author who creates the work is the owner.
Where a work is seen as being computer generated, the author is the person by whom the arrangements necessary for the creation of the work are undertaken.
In Nova Productions v Mazooma Games, the question was who owned the individual frames that were shown on the screen when playing a computer game. Was it the player or someone else? The Court held that the player of the game was not the author of the copyrightable work because they had not contributed any artistic skill or labour. Rather, the author was the person who had devised the rules and the logic used to create the frames.
It should be noted, however, that between computer assisted creations (where the author uses a computer to assist the creation
of the work, for example using a word processor application to write a book) and computer generated works (discussed above) there is a third category termed ‘intermediate works’ that may be applicable where a person becomes the author as a result of that person’s skill and effort using a computer.
For RPA generated works, it would seem that the Section 9(3) CDPA position, as more fully explained in the Nova Productions case, would appear to be the most likely position from which to start when determining who the author is – namely the author of the RPA algorithm software itself. However, as robotic software and hardware becomes more ‘cognitive’ and learns and adapts from data inputs, the works created may have no relationship to the original author’s software and so other factors may well come into play.
Contract Formation:
Robotic processes that feed into information loops – for example whereby the RPA will gather data from one application and apply its ‘learning’ to update inventory procurement from suppliers to an enterprise – create additional contractual issues to be dealt with.
Can a software program bind one company into an effective contractual relationship with another for the purchase of
goods and/or services?
It is universally accepted that a robotic system does not have a legal personality and therefore is a ‘mere tool’ the legal responsibility for which lies with its human/ corporate controller. Further, in relation to products, it is the producer of the product who bears liability for it pursuant to the terms of the Product Liability Directive 85/374/EEC of July 1985.
Inasmuch as the current law states that the ‘owner’ of computer programs (and in all likelihood the licensee who uses such programs in an automated procurement system) will be bound by the agreements that such systems enter into, it is when the machines themselves start to decide who to contract with rather than with pre-programmed suppliers, that such issues of robotic legal personalities will become more important.
Representations and Warranties:
When dealing with representations and warranties from customers and suppliers alike, do they take into account the activities of an RPA? Do suppliers really want to warrant that an RPA will use skill and care when performing the services – or is this merely a functionality issue that can be dealt with by warranting that software and RPA software in particular, will meet its level of functional specification and that is it?
Similarly, is a supplier happy to enter into agreements on the basis that the output of the RPA will meet a customer’s specific business purpose? If the process is sold as ‘being automatic, without the need for human intervention and thus it will increase productivity by 25%’ – is this something that customers will expect to see reflected in their bottom line price, or will suppliers point to the functionality point again and say that the software ‘just does this’ and no further warranties will be made?
The approach to be taken by suppliers is particularly interesting because while they may be trumpeting the advantages of new systems and processes, what will they actually take responsibility to provide? Making fraudulent representations under English law relieves the supplier of the benefit of certain contractual exclusions that suppliers like to maintain and so salespeople will have to be careful when making exaggerated claims about benefits knowing that such benefits are not going to, or are very unlikely to, happen.
Summary and conclusion
Certainly, RPA will have a large impact upon those areas of IT services performed by humans who are engaged in low-value, repetitive, high-frequency tasks and businesses that have grown up based upon such activities being performed by low paid workers may well see these being replaced by softbots or digital workers.
It is certainly not outside the realms of possibility to expect customers of this technology to be asking for contracts to be priced according to their own increases in profitability or revenue as a result of being sold ‘intelligent and cognitive’ systems that learn on the job and replace FTEs.
Price is but one element of the equation, however, and so increased efficiency, fewer (if any) mistakes, 24/7 availability, speed, data analysis and being part of an end-to-end IT system will undoubtedly also appeal to customers.
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
