An interview with Andy Fanning
If you’re just starting out in Intelligent Automation (IA) or Robotic Process Automation (RPA), it won’t be long before you start hearing a certain acronym banded around again and again and again.
Indeed, the RPA Centre of Excellence (CoE) retains a special importance in the IA/RPA universe.
But what exactly is a CoE?
Why should you have one?
And, more to the point, how do you go about setting one up?
Edge Tech’s US Consultant, Greg Hunt, sat down for a chat with Andy Fanning, an RPA leader/executive based out of Lake Ozark, Missouri to dig deep into this topic.
Andy, thanks so much for being here. Before we dive in, it’d be great for you to set the scene. There’s obviously a huge buzz about IA – RPA right now. Why is this?
If you think back to the second industrial revolution when electricity was replacing steam power in the factories, at what point could it have been said that the revolution started? When was the tipping point? In 2016, 1 in 25 companies were using automation and AI. Today it’s one in three. A third of companies in the enterprise today are using automation and AI to transform how they do business. This suggests to me the automation revolution has begun. So, companies are going to go to scale with automation; it’s just a matter of time. They either start now, or they start in 2 years’ time when their competitors have the jump on them.
There’s clearly an imperative to jump straight in. What would you say is the biggest ‘hurdle’ to getting started on this journey?
What companies need to be aware of going forward is that automation isn’t just about saving costs; it’s about preparing the business for the future. And one of the keys to this is data. Just like electricity underlay the second industrial revolution, data underlies this one. In order to leverage automation and AI effectively, you need a lot of good clean data. The issue is in most data is spread over multiple source systems, it’s in various formats, and it’s unclean. What I call the ‘architecture of automation’ therefore becomes very important.
Interesting. So why, where and when does the CoE come in to play?
Everybody wants to adopt RPA. Everybody wants to adopt it at scale. But it’s extremely hard to do. Only 3% of companies have managed to scale RPA, and nearly half of all RPA DX projects fail. So there’s a lot of bad statistics out there that suggest people are screwing it up. It’s not like you can just go, ‘Hey we’ve bought BluePrism so we’re good to go’. The reality is that even if you have executive buy-in for automation, and even if you’ve run some PoC’s and pilots and get some quick wins, enterprise-scale RPA is much harder to get right. The best approach we know of right now to fully leverage automation is to create a CoE. Create a CoE around how you do enterprise RPA. That’s the approach you take to be successful in this space. That’s how you manage an automation practice and create an automation factory.
So you put together a CoE and bang, away you go?
Not exactly. If I’m advising a Fortune100 client, I’ll tell them that there are three major pillars to Intelligent Automation. Strategy, Governance, and Change Management. Setting up a CoE only happens AFTER you’ve done strategy.
Why is strategy so important?
Because Automation should transform the way you do business. And if it’s going to transform the way you do business, you need a strategy around that. What do you want your business model to look like after automation? What do you want your business to be? How do you want your business to transform? Defining objectives will indicate which processes should be chosen for automation. There’re four considerations of why a client might apply automation: costs; productivity; risk; and data.
Everybody focuses on cost-savings first. RPA will either allow you to cut all these costs and achieve all this ROI. That’s how it sells. But it’s probably the shortest-lived strategy. What you need to look at next is what other things are important.
Take Productivity for example. People are good at certain things; bots are good at others. A critical piece in the strategy and execution of a CoE is to define what you want people to do. Can you define what people ought to do? What is high value inside your organisation? Is it more customer interaction? Is it making better decisions? What are those things you want people to be involved in? Rarely do we take the time to answer these questions. If it’s something you want people doing, it probably shouldn’t be automated.
Then there’s risk. Even though RPA is usually associated with cost-savings as a labour-arbitrate mechanism, risk can save costs in other ways. For example, in certain companies that hold sensitive data, they don’t want employees seeing it as people are the biggest security risk they have. Can you automate data processing to reduce risk exposure? Thinking through where you have risk, compliance issues or regulations that constantly change, those are the places maybe it’s worth putting a Bot in.
Bots are also really good at keeping data in sync. If you have customer information spread across several systems, and one of them gets updated, you can have a Bot that goes ahead and updates all the rest of them. You can have a Bot that constantly cleans data. Bots can assist in helping you get data in and out of systems until you’re ready to do a proper data integration.
Is there anything else that’s important here? For example, it’s said that RPA must be ‘Business-led, IT delivered’. Why is that?
The CoE to be effective needs executive sponsorship. You’re not able to set up a CoE inside a department with a mid-level manager. It really needs to have an executive mandate, so senior business stakeholders can drive change within the organisation, make choices around how to pursue automation at scale, and help push things when things get sticky. And it needs to be funded as a corporate initiative first. A self-funded model runs into a big problem in that nobody understands what automation or RPA is. People think of a big bot sitting at their desk and typing on heir keyboard. The CoE must show people what it can do inside the organisation. Otherwise, how do you get a HR manager to agree to pay for this brand-new initiative if there’s no proof it works? It’s a lot easier to get buy-in when you can show wins. You can transfer to a self-funded model later down the line, but you can’t do it from the beginning.
Who do you think needs to be a part of this team?
First off you need an owner of the CoE to push and run it. A person whose full-time job is it is to completely go after automation. Next, you need representation from the major groups within an organisation. You need business stakeholders on the CoE with a voice to make sure that the business is buying into the automation strategy. And you also need I.T! Although RPA vendors will suggest otherwise, they need to be at the table from the beginning.
So who owns the CoE?
I usually tell my clients ‘whoever pays for it’. It doesn’t really matter where it sits, but the stakeholders need to be the same no matter who “owns it”.
What type of personnel do companies sometimes forget to cater for?
First, security & compliance people. I’ve seen cases where Bots are created, they’re ready to go in production, and security intervene and veto because the Bots fail to meet compliance requirements and/or security standards. And so, it’s important to set out from the beginning rules and standards around how and when you use bots; what data the bots can touch; and what rule changes need to come about. Rules created with a Human Workforce in mind might need to change to enable a Digital Workforce, so it’s imperative the people at the table at the CoE are senior enough to change policies.
HR also absolutely need to be at the table, and this often gets overlooked. Having a concise plan on how you handle the HR issues is critical to making sure the CoE is successful. A big reason a lot of these initiatives are failing is because users on the ground don’t want Bots coming in and taking their jobs. If you don’t get in front of it, the rumour mill starts. You need a good change management plan to set out how you communicate changes. You also need to decide ahead of time what you’re going to do with the people after automation. Are you going to let them go? Or are you going to re-train and re-skill? Or are you just not going to hire back and let natural attrition take place?
So you’ve got a strategy and got all the right people at the table. Now what?
You need to advertise automation. This is one of the biggest steps I see missed. Eventually, over time, the people at the table of the CoE are going to run out of ideas. What you need to do is to democratise automation, which means allowing anyone involved in the wider organisation to be able to submit ideas to automate processes. They feel more bought in, and the CoE can cherry-pick the best opportunities for automation.
Then you’ll need a standard scoring model. Once you have all those automation ideas, you need a way to score them against the strategy and objectives, and devise a roadmap for triaging initiatives and prioritising what gets automated.
The CoE needs to be procuring automation technology. To achieve automation at scale nowadays, you need between 7-10 tools. With new functionality comes new automation opportunities. The CoE needs to be on the lookout for new tech and be able to adapt.
The automation factory needs a process for efficiently building automations. Speed and agility are important, so my biggest piece of advice is to create standard documentation which categorises the ‘criticality’ of different processes. Is the process ‘mission-critical’ and/or ‘customer facing’? What checkboxes need to be included? How much documentation do you need the BA to produce before it gets handed off to a developer? This will clarify whether initiatives need speed or rigour.
And you will need a dedicated support and maintenance team. As the CoE scales, you do not want to disturb the automation factory by pulling developers’ time and attention away from building new bots to support bots that are already in production. Constant monitoring of bot health should be built in, with contingency measures in place. If a bot goes down, is there a failsafe? Are the systems load-balanced in the event of a surge? How do you ensure enough capacity? Is there optimal license utilisation? This support and maintenance team is crucial for a Digital Workforce.
So now you’ve got an automation factory that’s building and supporting bots. Everyone can pack up go home and forget about it, right?
Having a clear picture of what happens after automation allows you to go in with your eyes open about what you are actually accomplishing. It’s important to perform a post-mortem audit. Is it worth continuing to spend the money on the Bot to keep it operational? Do we even need the bot anymore? When do we retire the bot?
We see a lot of different flowcharts out there on what the CoE should look like, who needs to be on it etc. Do companies need a 30 people team with Sponsors, Champions and Steering committees right from the off?
There’s a major difference between those types of structures and how these things get off the ground in reality. Companies approach RPA cautiously. They’re asking, ‘okay, how can we spend $200,000 to get a CoE up and running and pump out some bots’ instead of ‘how can we spend $2,000,000 and really go after it’. In the beginning, the CoE will borrow resources from other areas of the organisation. For example, you’ll need to borrow people from HR to set the change management strategy, but you’re not going to need them trying to create a new HR policy every day.
If an End User wanted to start an RPA journey and build a CoE at low cost, what full-time roles should the CoE hire for?
The only dedicated, full-time roles that absolutely need to be there from the start is a dedicated CoE Owner, at least 1 Business Analyst, and one or two specialised RPA developers to configure bots. Over time, you will also want to add an automation product scout to look at new tools and be able to pilot them.
A lot of people will be interested in setting up RPA consulting wings. Are there any things they should know?
The first thing to be aware of if you’re building an RPA practice is that it is a lot more technical than just having a certification. Where I see consultancies fail is that they assume they can bring in certified RPA Developers who lack deep IT chops and expect them to hit the ground running. The challenges you will run into won’t be understanding how to use the tool: it’s stuff like how to get access to certain systems, firewalls, etc. Technical problems that most certified RPA talent are not able to deal with. As a consulting organisation, you need to make sure you have some heavy hitters on your team able to solve those big problems.
The other thing I would say is it’s a much more onshore model than other traditional IT services. Because of the speed with which you’re trying to develop automations, it is much easier to move much faster if you can sit a developer with the business owner and get it out the door quickly. It’s much harder if the development team is offshore, and these time lapses kill one of the major benefits around Time to Market.
How important is it that a company wanting to build a CoE bring in an RPA Partner? Or can they just do it themselves?
If you look at Fortune 500 spend on RPA, for every $1 they spend on software, they’re spending $7-10 on services. So you need the RPA partners to help. The way Vendors have been selling into businesses so far has been to say ‘hey you can do this yourself, you don’t need IT’. Companies are beginning to realise they need more than just a license. Automation and AI are enterprise transformation vehicles; so service providers are crucial at the beginning. However, enterprises can move away from service partners down the line. And a Build – Operate – Transfer model is probably going to be the most prevalent in the industry. You need the expertise at the start to help you with avoiding the pitfalls. It’s also really hard to hire an RPA team from scratch, to get the approval for hires etc. It’s much easier to get approval to outsource to a Services Provider/System Integrator. Plus, they can come in get you quick wins, ROI and a business case, then you can look to build it out internally.
What I’ve seen is a lot of different ways to structure the RPA capability inside an organisation. For example, there are Divisional, Federated and Centralised models. Which one should companies go for?
Great question. It’s very common in this day and age for large organisations to have their IT teams spread out, to ‘embed technology in the business’. Because technology has become such a big part of how we do business, this makes sense. What doesn’t make sense is if every one of those divisions have their own RPA teams with their own tools. You miss out on economies of scale. So we’re going to see this evolution from the Wild West to consolidation. The CoE model that I prefer is an evolving one: it starts as a centralised CoE that evolves into a federated model over time. The centralised CoE sets the rules of the game, and larger sections of the business that want to pursue automation can create their own autonomous teams so long as they play by those rules. This ‘Hub and spoke’ model works best because the disadvantage of the centralised system is that it is too slow and unable to automate fast enough due to the demand. But the secret to being able to get to scale is to democratise automation. To put the tools in the hands of the people on the ground, that gives Bob from Finance the capability to automate a process by himself. The issue is a lot of the tools aren’t ready for that yet.
What role should a Council or Steering committee play?
What I’ve seen work well is the committee acting as a funding mechanism for the CoE. Once you’ve got over your initial funding, you need a mechanism for ongoing funding approval. So you can have each of your division heads on the committee, and their role is to negotiate and approve certain projects within each department.
You’ve built up a leading RPA consulting practice. What were your biggest pain points with hiring?
Talent with any RPA experience at all is hard to come by. At Genpact we had internal recruitment teams and recruitment agencies working vacancies, and it was a difficult process to find qualified candidates, particularly the Management consultant types with strong social skills and communication abilities. You end up making bad hires, and it’s a terrible process.
Other Hiring Managers I work with have said a lot of candidates embellish their skillset. Have you seen that?
Absolutely. We used to have people who had proxies on the phone during telephone interviews and Face to Face meetings. Crazy stuff. We used to have hiring days on a Friday, and for every 8 we interviewed you’d find 3 that were grossly incompetent, 4 who were iffy, and maybe 1 who’s a yes.
If you could wave a magic wand to improve the service from Recruitment agencies, what would it be?
If they hired 1 specialist to sit and perform technical interviews all day. Someone whose technical enough across automation platforms to screen candidates and rank the candidates technically, so they can weed out the and stop them wasting time.
Andy, thanks so much for your time. This has been great!
Andy Fanning is a Digital Transformation Executive specializing in Intelligent Automation and AI. He has been Vice President at Catalytic, Inc and Global Head of Automation consulting at Genpact, where he scaled the team to over 150 consultants adding over $30mm in revenue in one year. On his downtime he likes surfing.
