However, I think there are some practical aspects of managing ‘robots’ that haven’t had the attention they deserve. The result could be that we underestimate the total cost of ownership and complexity involved in managing our new robot workforces.
At Capgemini we already provide robot workers – Robotic Process Automation (RPA) apps that carry out repetitive tasks. They can streamline supply chains or improve the efficiency of Finance departments but, as our robot colleagues grow in number, we will have to consider the issues arising from their ‘employment’.
Considering how best to approach the deployment of a new robot workforce, I have turned to the seven levers of the Global Enterprise Model
that we apply to every programme we deliver. This provides the framework to what Isaac Asimov, were he writing today, might call the Seven Laws of Workplace Robotics.
The right team structure is important to the success of any enterprise and that is no less true for robot team members. You need to consider the robot’s level of sophistication and how different robots might function together. Some will have high levels of artificial intelligence and perform complex tasks. Others will be designed for straightforward jobs. Getting the right robot for the job is key.
A software robot doesn’t have an office. However, just as the physical location of data stored in ‘the cloud’ can be important for legal and regulatory reasons, so we will need to define where the robot works. It is not an easy question. Does the robot ‘work’ in a delivery centre or on client systems? Is it behind the firewall or outside it? Similar questions can be asked about the data it handles.
The competency model is a significant factor in getting things like Grade Mix and Location right. What are the key capabilities required? Will it work with any ERP? Does it just replace human key strokes or does it do more? There is also a question here about the competencies required in the humans who will be specifying the requirement for the robots: have we trained people adequately for this new job?
People often think of robots replacing humans to deliver a process more quickly, reliably or cost effectively. However, that is only accurate on a fairly simplistic level. There are more significant considerations we should apply. A robot might be able to do work more quickly, which can have an effect on the rest of the process. The increased speed of that part of the process might cause a bottleneck elsewhere. Robots can also carry out tasks that are impossible for humans, or at least impossible for humans to complete in a reasonable amount of time with reasonable consistency. That might create opportunities to introduce greater complexity or more decision points into your processes than a human would be able to manage.
Since we are talking about robots, every step in this process concerns technology. In this case, however, we are talking about the technology itself, rather than how it is being used. Who owns the IP for the robot? Who is responsible for its performance? Is it fair to hold the CFO responsible for a poorly performing robot in the accounts payable process that was developed and installed by IT? Probably not, however neither is it always explicit that IT should be responsible for the robot’s performance. This raises other questions that need to be addressed under the Governance lever.
The question of ownership is also central to pricing. Who owns the robot, ultimately? Do you own it outright or rent it? Just like human workers, robots will need ‘training’ to improve their performance. If you rent your robot then those upgrades should be part of the package but if you own it then you need to allow for those costs. There’s an interesting question here of whether people are thinking fully about the total cost of ownership for robots.
The robot needs to be accounted for in service level agreements. What issues might that create? To continue the accounts payable example, a task carried out by humans can probably be maintained even if several staff members are unavailable. Others can be brought in and trained-up relatively quickly. A problem with a robot process, such as a bug in the code that needs to be ironed out, can’t be circumvented so quickly. Similar concerns apply to the OLA that underpins the SLA. Furthermore, a human worker has a system ID but how do we treat a robot? If it has its own ID, who is responsible for tracking what it does? Once again, is it a responsibility for the IT department, who deployed the robot, or for the department it works in?
The above questions sound like a particularly philosophical piece of science fiction. However, they are more important than that. As our robot workforce expands, our answers to these questions will determine the cost of owning robot workers.