Why support is the missing piece in RPA and automation

From his early days selling technical workstations for Hewlett Packard, to his current role as executive director at Virtual Operations, Nick Andrews has had a finger on the pulse of innovative technology. 

With a global career that spans outsourcing, large scale negotiations, sales and more recent entrepreneurial pursuits, Andrews says it wasn’t until six years ago that he first came across automation.

“I knew immediately that [automation] was going to have a massive effect on back-office projects, back-office transformation, shared services, and even more on the whole business process outsourcing industry which, by then, was something like a $100 billion sector,” he says.

The speed, ease of implementation and cost-effectiveness of automation is a natural fit for large organizations undertaking business transformation, Andrews adds—but it requires agility to keep up.

“This is an industry where, if you want to survive and succeed, you have to morph with the industry—and it’s changing so fast, we have to change even faster—to be ahead of the curve, rather than behind it.”

We caught up with Andrews to discuss the role of support and governance in the intelligent automation process, and what businesses stand to lose if they don’t have these frameworks in place.

AIIA Network (AIIA): There is a lot of discussion across industries right now about automation technology for process excellence and cost savings. What are the other elements of the automation puzzle that organizations should be thinking about but perhaps aren’t?

Nick Andrews (NA): What happens in most IT projects is you think about the design, the build, the implementation and then the testing, and then you think about support. In automation, it’s not like that—you don’t have a year or two to think about support.

The day you start your first process, you may be five or six weeks away from needing to support it.

And when I talk about support, I’m not talking about routine maintenance nor about bug-fixes or patches, or even little tweaks that you make to the processes and therefore the coding. I’m talking about what happens when a process goes down because the robot falls over?

If support fails, the business risk can be extremely high. In addition your program will get a bad reputation and you’ll lose all the momentum. People will look around and say, “Before we automated, we had these processes running at 98 per cent, now they’re 72 per cent”.

Imagine, you’ve automated a business-critical process and it falls over—and you don’t have anyone to fix it. It does become a very highly-visible, very expensive and risky issue.

AIIA: If it’s so critical, why do so many businesses overlook or fail to grasp the magnitude of the need for support?

NA: We’ve been providing support for over three years, and we still find it really tough. It’s not so much a technical challenge, but more of a people-management issue.

Supporting automation means you’ve got to manage all of the touchpoints. It’s about ensuring that all the people involved in governance are doing what they said they’d do—and that could mean things like ensuring that a third party has service level agreements.

It’s also about making sure that those automated processes are fit for support. For that you need people who are problem-solvers, intuitive, people managers, and you need to cover 365, 24/7 which means multiple teams of people across the world who can work together to provide that support.

Read more: The real success factor in automation projects 

We’ve also found that production support for automation is a bit of a hybrid role and a bridge between the processing teams dealing with the business exceptions—intentionally configured into the automation—and the infrastructure teams dealing with IT issues. The automation production support need to be able to quickly triage and identify unusual business exceptions, problems with the automation tool itself, or issues with the supporting infrastructure.

The other challenge is that the cost of ownership for support is quite high so, in many cases, it will kill the original business case for automating a process. When faced with this a few years ago, what we decided to do was practice what we preach, and we automated the vast majority of the support process itself. That means that the rapid growth of our support service can be accommodated within the current environment as the scale comes from the automation. Now rather than monitoring, escalating, and routing problem fixing, all the level one support team is doing is monitoring the support robots.

We can scale as large as we want, just by putting more robots on, rather than adding more people. The only area we need more people is for the advanced technical challenges, and that’s where support really requires experience.

AIIA: Whose responsibility is it to ensure the correct support infrastructure is in place?

NA: It depends on the organization, but really it’s a conversation that needs to happen from day one. Because robots are pretty robust and resilient, they’ll spot most changes but they won’t spot them all—so if changes are made and the governance controls aren’t great, then the robots will fail.

Governance is a stakeholder management issue and requires involving the IT department, the process department, the infrastructure provider, the software provider and so on.

It really comes down to project management; it’s a project to manage, it’s people to manage, and it’s technologies to manage. And it gets even more complicated when you’ve got multiple technologies, which is the way the industry is going.

I’ve found most organizations are very receptive to this conversation. And those that have tried to do it themselves are even more receptive because they recognize the issues as we’re talking about them.

AIIA: Can you give an example of an instance where having support in place has meant the difference between success and failure for an automation project?

NA: There was a relatively simple issue on order fulfilment in a very competitive area for one of our clients—a high-tech, high-cost consumer product. If the order fulfilment wasn’t up and running 100 per cent when the customer asked for the product then those customers would go elsewhere. They simply weren’t going to wait two or three days.

When the robots fell over, it was flagged as an infrastructure issue but it actually wasn’t an infrastructure issue. A change had been made, so the support that we had in those days, routed it to the infrastructure provider who said it had nothing to do with them. 

We looked again and we still thought it was an infrastructure issue, argued the case, then found out it was a governance issue. A change had been made, nobody had been told about it, but it appeared to be a different problem.

Now we have checks and balances to make sure that whoever is monitoring the support process knows exactly where to route it to, and we have built in redundancy, so they can route it to one or two different routes, and say “I think it’s this, but it could be that, can you both check?”.

This meant the organization didn’t have more than an hours’ downtime—and even the most impatient of people waiting for delivery wouldn’t notice one hour in a day—but if it had gone on for a day, they would have lost a lot of orders.

You really do need to think, particularly for business-critical processes, about how you handle support.

The vast majority of our issues are down to poor governance and poor infrastructure. And poor infrastructure is normally because the organization, or their outsourcer, doesn’t want to make the investment they need in the infrastructure to support the robots, and that’s a false economy.

AIIA: As automation evolves and integrates with AI, how do you see the need for support evolving?

NA: We’re trying to stay ahead of the curve, and if you look at AI, there are very few companies that are actually implementing any of the truly cognitive products. When it comes to a combined AI-robotics, the way in which they’re configured and structured is that the AI, for the most part, is just interpreting structuring and extracting data to feed the robots, and the robots are interacting with the systems at the presentation layer.

Read more: Managing the move from tactical RPA to digital enablement

When AI becomes the core rather than the peripheral technology, we’re going to have to have more support for the AI tools, which means that we need that expertise to be able to understand as quickly what’s gone wrong as we do with the RPA tools. I don’t think there are many people in the market that are even considering that, which is why it’s such a great question.

We’re starting to see it already, and when you look to the future you’re now talking about people who are very advanced technical developers in whatever language the AI tool is built in. It’s a great thing to wrestle with, but we haven’t got much time.

Nick Andrews is executive chairman at Virtual Operations and a member of the AI & Intelligent Automation Network’s Advisory Board.