By Alex Edlich and Vik Sohoni
Over the last several months, we have witnessed the increasing chatter around one of the hottest buzzwords in the digital space: robotics. Robots are a bit like macros in Excel. They execute tasks that are often repetitive. So instead of a human typing in a password and retrieving a piece of data from a program (like someone’s salary from a W2 system), the bot will replicate that same task by running a software script that interfaces with those programs. This makes producing the end-of-month compensation report, for example, a lot easier.
A year or so ago, a lot of people around the world got very excited about this. In Europe, we even heard the term “zero FTE back office.” The McKinsey Global Institute forecasts that 30 percent of tasks in a majority of occupations can be automated, and robotics is one way to do that. For large back offices with data-entry or other repetitive, low judgment, high-error-prone or compliance-needy tasks, this seemed like a panacea. Add in Artificial Intelligence or machine learning and you could actually get bots to do even more complex tasks, like responding to a customer email inquiry by retrieving some basic data, for example.
Many companies, therefore, rushed to install bot armies, spinning up pilots to configure all sorts of processes and projecting large financial outcomes.
To be sure, there have been several localized successes; at one mining company, the finance function saved 30 human days per year worth of work by automating the journal posting process. They also saved 60 human days per year of work in the monthly financial reporting process. A larger business case suggested a double return on investments in robotics.
However, in conversations with dozens of executives, it is clear that the first act in the ‘robotics evolution’ has not been a slam dunk for many, especially when companies try to scale the localized proofs of concept. Specifically:
- Installing thousands of bots has taken a lot longer and is more complex than most had hoped it would be. It might sound simple to pull a salary statement, but what if for that worker the data is in unstructured formats? What if the worker goes on maternity leave and a different set of systems kicks in? What if … Said differently, a ‘standard process’ can often turn out to have many permutations, and programming bots to cover all of them can be confounding.
- Not unlike humans, thousands of bots need care and attention—in the form of maintenance, upgrades, and cybersecurity protocols, introducing additional costs and demanding ongoing focus for executives.
- The platforms on which the bots interact (or handshake) often change, and the necessary flexibility isn’t always configured into the bot. Installing thousands of bots introduces an additional architecture layer into the system requiring more bespoke governance and oversight by the IT organization, which is often already burdened with maintaining legacy systems.
- Changes upstream and downstream, even during bot configuration, can significantly delay bots being put into production. For example, a new regulation requiring minor changes to an application form could totally throw off months of work in the back office on a bot that’s nearing completion.
- The companies providing licenses and platforms for bots may have varying complexities and specializations that may not have been fully considered in deciding which platform to deploy for which process.
- The cultural effects of bots on operators are just being discovered. For example, asking operators to program bots that could take their jobs can understandably create real personnel and morale issues at the front line.
- The economic outcomes often aren’t as rosy as originally projected. While it may be possible to automate 30 percent of tasks for the majority of occupations, that doesn’t neatly translate into a 30 percent cost reduction. People do many different things, and bots may only address some of them. Unless the process and the organization are reconfigured, savings can prove ethereal. Also, bots treat localized pain points. Anyone who’s read The Goal (or stood in line at a cafeteria) can tell you that fixing one bottleneck may just move the problem elsewhere.
As a result, several robotics programs have been put on hold, or CIOs have flatly refused to install new bots—even those vendors have worked on for months—till solutions have been defined to scale the program effectively.
What’s the path forward?
A few companies are resetting their robotics programs. As one CIO said, “We crashed, burned and are now resurrecting!” Here’s what they are learning and doing.
- A bot is a tool in a toolkit, just like self-serve tools, work-flow tools, lean-process maps or six-sigma methodologies. Companies need to apply these tools as part of an orchestrated action, not in isolation. For example, it may be more effective to streamline or eliminate fields from an application form instead of tasking a bot with transcribing it to a system. Or it may make more sense to question why someone needs a thick financial report instead of tasking a bot to mindlessly generate one every month. Or deploying a work-flow system may simplify information flows and create more timely customer alerts resulting in a reduction in the calls a bot may have to answer further downstream.
- Taking an end-to-end view of the outcome needed and measuring that delivered output is better than applying a robotic Band-Aid to a particular pain point. That’s not to say that there aren’t some pain points that should be immediately addressed, but that, at scale, deploying thousands of bots isn’t always the best answer. Better to figure out what the desired goal is and then figure out how bots can (or cannot) help.
This often means collaboration and coordination with other silos, or creating a corporate business process management group. - Blueprinting the architectural implications before you get into installing bots is crucial. Determining, keeping track of, and updating all the different linkages between systems that bots will develop and rely on is a whole new set of responsibilities. No IT organization appreciates being saddled with responsibility for a whole new technological layer. Clarity around who will undertake this and how the bots will be managed at scale is critical before they proliferate.
- Treating employees as problem solvers and enabling them to use bots to solve their problems can be culturally very transformational. Delegating authority over the bots to those employees (versus running the bots centrally) can also be a way to ensure ‘continuous improvement’ and employee participation. This also means that employees need to understand how the bots work, perhaps even learn to configure or code them. All this is similar to some of the other initiatives firms are rolling out (such as agile development or continuous delivery) that are focused on empowering employees.
These are just some of the ways we foresee companies will have to deal with the issue of scaling the proofs of concept successfully. We expect many C-suite executives will soon go through a process of resetting the bot wave. And that delicate managerial process is not something a bot will be able to automate away.
Alex Edlich is a senior partner in our New York office; Vik Sohoni is a senior partner in our Chicago office.