Unveiling the Robotic Operations Centre: The Powerhouse of Automation Support

Discover the backbone of post-production automation support with us, Daniel Andrews and Kieran Gilmurray, as we dissect the pivotal functions of the Robotic Operations Centre (ROC).

Our conversation peels back the layers of sustaining an automated ecosystem, emphasizing the trifecta of product, process, and platform.

Whether you're a seasoned professional or new to the field, our insights into the ROC's evolution and its role in amplifying your automation initiatives can be a game-changer for your organization.

Tune in to uncover the diverse skill sets that are the lifeblood of a ROC, ensuring the seamless operation of automated processes. We dissect the structure of a high-functioning ROC team, analyzing the nuances of support at various levels.

Daniel's wealth of expertise, gleaned from supporting automation across companies of all sizes, comes to the forefront as we traverse the landscape of intelligent automation. Get ready to elevate your understanding and support an automated infrastructure with finesse, right here on Automation Unscripted.

Visit Virtual Operations (virtual-operations.com) for more information on intelligent automation, data analytics and AI or book a chat https://calendly.com/virtualoperations.

Transcript

Speaker 1 0:04

Welcome to Automation Unscripted, an educational, frank and fun podcast dedicated to the art of business process automation. Automation Unscripted is brought to you by Virtual Operations, a leading consultancy in digital transformation with more than a decade's experience working with organisations to help them grow their return on investment in automation. In this edition, your hosts, daniel Andrews and Kieran Gilmoury, are discussing how post-production support works in an automation programme, the role of the Robotic Operations Centre and some of the learning pathways for individuals looking to support an automated infrastructure. For individuals looking to support an automated infrastructure.

Speaker 2 0:44

Welcome to our Virtual Operations podcast, where we're going to talk all things intelligent automation. Today you'll be listening to both myself, dan Andrews and Kieran Gilmoury talk about post-production support and the role an ROC, which stands for Robotic Operations Centre, plays robotic operations center plays. I think a good place to start here is looking at support itself what actually is support and then we can dive into a rock. So, for me, I split it into three key pillars. The first one you have is product, and that's the tool utilized to automate the business processes. So this could be AI, ocr, rpa let's take RPA for now and use UiPath as an example.

Speaker 2 1:30

The second pillar is process, so the business process that has been automated by, on that example, UiPath as the tool, and this is traditionally what people think of when they think of support. The second pillar, which is process, and then there's a third pillar, which is platform, which is the infrastructure that everything runs on. So, depending on your organization and setup, this could be examples like Azure, aws, or it could be on-prem or in the cloud. Do you agree with that definition, kieran?

Speaker 3 2:01

No, I really like that. It's the kind of three-legged stool that you and I have talked about lots of times. Dan, you know you need each working, working really well, otherwise something falls over. From your perspective, then, dan, because you have been doing this support at the billion company level, as well as the hundreds of millions, as well as the millions and the hundreds of thousands, are there any of those, from your or a VOP's perspective, that are actually more important than the other?

Speaker 2 2:27

Yeah, I'm not going to say any of them aren't important.

Speaker 1 2:31

Because, what I will say yeah exactly.

Speaker 2 2:35

You take one down and it will always fall over. But for me, if I looked at say I had just an example of 10 incidents historically what I see is the majority will fall into the second two pillars, which is process and platform, and the first pillar, which is product, as important as it is. We may receive only one out of 10 incidents as anything to do with the product, which is great news for the likes of ui path and blue prism. But it's still very vital to have those relationships with the product.

Speaker 3 3:05

Dan. How did a ROC come about? Why is it important? What does a ROC even stand for?

Speaker 2 3:18

For me a ROC came about. It usually comes about as organization scales within the COA, so it's a function that sits aside as part of the COE. But it comes for two reasons it comes at scale and it comes because of skill set. So the first one scale around 15, 20 processes. You need a full team in order to keep those processes live and operating. You need a dedicated team. And that comes into the second point, which is skill set. The skill set within a ROC can vary quite differently from that of within the COE and it usually at that type of scale. It's not a small team either. So having a dedicated team to focus on that production, those production live processes, is why a ROC is so vital.

Speaker 3 4:00

Interesting. And do you remember back in the day, people didn't have a COE, and that's a reason why ventures automation ventures failed. Now, as you're describing it, the rock's a key component to keep alive processes and make sure they actually execute on the value. So how is a rock actually structured then? How are the teams and the roles in there laid out?

Speaker 2 4:22

Yeah, yeah, so I guess I like splitting everything into three. I'm not going to call these pillars, but let's go with three levels. So standard levels for me would be L1, l2, l3. Now, there are lots of variations of this depending on your organization that you're setting up a rock for, but I'll go with the most basic one, which is L1 would be a mixture of tooling and a 24-7 offshore onshore team, whatever that might look like. L2 would be experienced management, both technical and non-technical, with developers and maybe a platform team in there, depending on how that's set up. And then L3 is the service lead or lead. So that is the orchestrator of the rock, and for me this is an individual, because all rocks are set up different. This is an individual who can go into any organization and they can assess the landscape and they can decide where the need is for the client in order to gain the production process success that they are looking for, and that's the main skill set of l3 why do you deem a rock so important?

Speaker 3 5:37

because you've done this at the hundred million and a couple of billion dollar level. But, in essence, why is a rock there? Why what's its most key function?

Speaker 2 5:47

well, it goes back to what we said before right the, if you have an automation program as a company to realize that value, you need to keep your processes live and you need to keep them running to realize that value. If you don't have a team dedicated to that, it's very likely that all those things fall at the wayside and then all the processes that are coming in are not meaningless, but the whole automation program is now at risk because you're not getting that value you said you would. Your stakeholders are now unhappy, thinking why are we adding more processes in when the ones we've got running aren't even realizing the value? So I think they're really crucial to the whole program. A rock is essential towards that and it was real difficult to actually get organizations to understand that about a decade ago. It was really just seen as an additional cost and not a necessity. But I think, as organizations are now a reasonable scale and a lot of them everyone is, or most organizations are realizing how important this function is, yeah.

Speaker 3 6:51

I kind of like that because back in the day we didn't realize how important the COE is and this is the actual extension in my head of a very stable platform and skill set to get people moving and realizing value from automation, which is the absolutely key component three that actually sounds like there's quite interesting career paths for those who work in the rock. It's not a case of just throwing code across the fence. But you were talking about l1 skill sets. You were talking about infrastructure and environment and some big scale support centers. What are the development pathways for people in a rock?

Speaker 2 7:31

yeah. So I think at the same issue as before for me. When I put out a job post, I try and avoid words like support, because people don't really understand the extent of how involved you get in the automation program. If you are part of a rock, support control tower, whatever we're calling it people and I've seen this in multiple members of my team once people actually join the rock and start getting involved, you realize how many parts of the process life cycle that you touch. You gain a huge amount of knowledge.

Speaker 2 8:01

You look at best practices, you look at process logging levels. You look at consistent error messages to why processes are breaking. You develop relationship with stakeholders, developers like it does encapsulate everything and sometimes, to, I guess, my detriment. With the team, you get to realize what area of an automation program you enjoy and I've lost many individuals who decide to go out and explore those areas in more depth. Right, but that does show the opportunities that are there. You get involved in so many different aspects as part of the rock and you really develop a knowledge of the industry, um, and how an automation program works. So I think it's great for someone developing or who who's already developed and want to go into that management or lead role I love that.

Speaker 3 8:50

It's really interesting, isn't it? Because back in the day, the support role wasn't the one that you wanted to go into, because the front end kind of threw code over, made a mess of it and went. I've done my creative part. What about AI within a rock, dan? Because we're hearing about artificial intelligence everywhere. Is it accountable for AI, or is that COE or somewhere else?

Speaker 2 9:11

A hundred percent. And that's back to where I said learning pathways for individuals. That's something my team finds extremely interesting. We've utilized over the last three or four years a bunch of different monitoring tools that involve AI not just for monitoring, that's for monitoring process investigation and there's a load of them out there. Yeah, I think you could spend months delving into each individual tool and that's one of the things that's interesting about the team or the team's learning pathways. But we really have started utilizing AI and those monitoring tools a lot over the past three or four years and they're incredibly important. I look at L1, I said there's a mixture of 24-7 team and tooling. It used to be the case that if you wanted to monitor processes 24-7, you used to have to just throw individuals at it consistently as you scale. But when the monitoring tools came into place, it meant that now you can have an individual team maybe managing 50 to 100 processes that they're monitoring instead of, say, 20 or 25. So we're seeing the realization of those benefits.

Speaker 3 10:14

Dan, that sounds like a topic we should have for our next podcast.

Speaker 2 10:18

Perfect, that's exactly what we'll talk about. Let's go over quickly what we summarized today and then we're going to be talking about next week. So we talked about defining support, what it is, and then what is a ROC Robotic Operations Center, why a ROC is, important roles within a ROC, and then some of those learning pathways for individuals who might want to join a team, like the one we discussed. And then next week we're going to be discussing ai and rpa. There's a lot of buzz at the moment about ai, and there has been for the last two or so years, so we're going to be delving into case studies where the two actually work in parallel rather than being siloed as part of a process. Fantastic, I can't wait for that one. Thanks for listening today, everyone, and we will catch you next week. See you next week.