#8 Part 2 - Hyperautomation Centre of Excellence (CoE): What you need to know for success

Hi and welcome to the Process and Automation Podcast. This is the second part of our episode, HyperAutomation Center of Excellence: What You Need to Know for Success. If you're just joining, we recommend to also listen to part 1 of this episode so you can get the full picture on how setting up the HyperAutomation Center of Excellence in your business.

Which means that your sort of benefits will diminish. So what you want to do is use these people to promote it inside the business. The next sort of role that we need to look at is Hyperautomation Change Manager. So, Change Manager is a big important one.

Yeah.

It's really important because this is a person that needs to communicate and put out the change management plan within a business to ensure that all of these initiatives that we roll into the business across the enterprise transitions in very smoothly. And we need to look at how people's job roles will change and impact assessments on that. I think we did touch on change management quite a lot, and I think it's quite a big topic in this area.

So I guess we can't live with business analysts either. So someone needs to actually sit down with the business experts, with the process experts, sit down with the business units and just sort of interview them. What kind of processes do they want to build, how they want to want to build them out, develop the process maps, and put this all sort of in a nice manageable artifact and asset which can be passed on later on to then the solution architects and developers to work that out.

Yeah, exactly. So I think, you know, once we establish some of the initiatives with Insight, the Center of Excellence, I think when it comes to assigning a business analyst resource to it, this is the person that will delve into the deeper sort of requirements and unpick those requirements. And, you know, business analysts are subject matter experts and they know various things about various business units. And like you say, you know, they, they, the people that kind of manage the creation of these process definitions process maps and things we pass for automation, or like we want to pass for implementation of automation. And like you touch on the hyper, hyper automation solution architects, they didn't really— the, the, the, the people that oversees the architecture of hyper automation solutions, and they also kind of supervise the development and implementation of the, the solutions and They'll select the right tools and technologies and capabilities to ensure that all the solutions that we develop actually align with the enterprise guidelines in terms of architecture and sort of what the developers will use rolling out these projects.

So that means then the developers take over and work alongside the business analysts to, very typical, like in any other kind of project, to design and develop and test and later on maintain, fix any bugs and all that stuff for that solution? Or is there anything sort of different than in any other kind of, in any other project?

I think it's very similar, it's just more visual. You know, if you look at turning requirements into working solutions, you know, it's still going to involve the business analyst that gives functional direction as to what the business needs. It's still going to involve the solution architects that give architectural direction as to the tools we need to use. And it's really just then up to the developers to design and develop and roll out the solutions. And then also in an agile fashion, you know, roll out the solutions in a way that makes sense to, you know, from a time perspective, you know, what is the sort of capabilities that we want to give to the business at what time. We don't want to stagnate. We don't want to sit here 2 years later and still roll out initial version of the automation. We want to choose the right path to be able to roll out, you know, most viable product and then do subsequent releases to add more features. So, so, you know, akin to conventional development, it's still the same process, but in this world we live in, it's not going to be opening up, you know, a C++ or you know, C# or editor to develop these sort of codes. It's just going to be low-code drag-and-drop, configure as per the business analyst requirement and get it done, right?

Okay, yeah, this is actually— there's quite a lot of roles already. I think we have a few more to cover. So yeah, it's a big team, lots of responsibility, but actually It is really not that different to sort of other projects as well. So once the developer is finished, the developer sort of needs to deploy it into a system which can run that application around the new solution. So some infrastructure needs to be put together, server installations need to be done. So yeah, this is typically the role of the infrastructure engineer or technical engineers who are installing and troubleshooting the environment and work with technical solution architect to, to set up the environment so it's robust, secure, scalable. Yeah, so that's, that's, that's our typical infrastructure engineer. And yeah, I think that that person is already very much involved before the developer gets actually started because very often we put the development systems in place. So that's also done by the infrastructure engineer, the technical engineers.

Yeah, and I think it's important to realize, this is all a function of the scale of your center of excellence. So on day 1, you might have 1 or 2 people that fulfill multiple roles. The aim here is not to look at it and say, we wanna roll out a Hyperautomation Center of Excellence. We need to go out to market and now hire a business analyst, hire a solutions architect, hire a developer, infrastructure engineer, and all of these. I think that the message here is that's not needed. As you scale it out and these, the roles become a bit more distinct, and more to handle by one person, that's when you can start to differentiate between assigning one role to maybe one or multiple individuals. So if you're— if your Hyperautomation Center of Excellence is really large, you might have a business analyst for each of your business divisions. If it's really small initially, initially you might have a business analyst across your business that just look at high priority, let's say, RPA initiatives, right? So it's all something that should be elastic in a way.

Yeah, that makes sense.

Yeah.

And this follows what we say all the time, isn't it? So start small and then—

Exactly.

And measure and then scale.

Yeah. And I think it's important to look at this and realize that the goal should obviously be to push any automation initiative through your center of excellence for prioritization, for management, governance, implementation, all of those important things. So it doesn't— we always say, well, start small, grow big. But there's a critical mass that automation does reach where you still have to put these guardrails in place to ensure that you, you know, roll out these automation initiatives to provide maximum benefit without creating more problems with inside your business. Because if you're gonna start automating things but you're gonna create security problems, well, you know, you're just shifting problems around the business, right?

Yeah, definitely. Yeah. So this is why we definitely need also support. And some business unit can't just deploy things on their own because at some point these solutions, they require support. And usually everyone who's using that system at some point will not call that person in the business unit. They will definitely call the switchboard, the IT switchboard, to get help, isn't it? So that's This is why we have a good first line of assistance and first line of support available. Otherwise, yeah, these things will go wrong very quickly.

Yeah, and I think again, in a very, very small scale, the support engineer might be the person that is the developer. So, you know, don't see this as going out to recruit a support team, but I think again, as you as you scale this, you need to just differentiate between the roles. And also, one of the things that you need to do is to establish a performance framework. Because if you have got, let's say, a larger scale center of excellence team, and this is from obviously your sponsor, your champions that promotes it, the change manager looks after changes, the business analyst we spoke to, solutions architect, the developers that builds it, infrastructure engineer, the HyperSupport supervisor to make sure that, you know, we constantly improve operational performance. You touched on the support, the service support engineer. You know, the performance framework is really to ensure that this operating team delivers maximum value. And, you know, this framework determines and measures and monitors key performance indicators of your hyper, Automation Center of Excellence. And they the kind of people that hold these regular operational governance review meetings and involve all of these stakeholders and document the lessons learned. How can we do things better? And I think all of this will help you to really build a—

With growing pressure on organizations to operate at digital speed, low-code development has emerged as an opportunity to more quickly transform. How do you know if it's right for you? So if you're forced to accelerate operations, improve the customer experience due to continually evolving expectations, visit our website, theautomationguys.net, and download our low-code guide and learn all about the secret of low-code success.

Very scalable and agile hyperautomation. Roadmap for your enterprise. So again, if we go through sort of everything from governance to actually procuring software and looking at skills, I think once you've got this in place, that's when you're ready to really unleash this and launch it.

Yeah, and indeed. So once everything has been set up, like you mentioned, so the center of excellence, yeah, can really fly. And yeah, so then the team, on the team should now focus on making strategic expectations. So all the expectations in the business are met, the roadmap is really clearly developed, and yeah, so on the the hyperautomation knowledge and expertise is really pushed throughout the enterprise. And yeah, over time the emphasis will transition from achieving the rapid efficiency gains to creating these business outcomes everyone really wants. So hyperautomation yeah, will lead to automate any process that can be automated.

Yes, exactly. And I think, you know, once this is launched, your hyper automations, so you've got the roles in place, you've got your software in place, you've got your governance in place. It's really then a question of if it's your first initiative. Now, bearing in mind the Hyper Automation Center of Excellence can be something really small on day one. And it could literally be 1 or 2 people that covers all of these disciplines. But when it comes to implementation and it's the first implementation, you know, let's start with a pilot, you know, and it's really essential for the operational team and IT to, you know, to work together to solve these problems and drive the business improvements, you know, rather than just going out and, you know, applying these technologies, these progressive technologies to existing bad processes. So pilot is a very, very, very good way to, you know, execute something very simple, you know, with inside a business unit where all of these stakeholders can come together, they can embrace it because they are testing and learning the approach. We are gaining quick wins that helps in these areas. We're building confidence in the technologies we apply. And also, I guess, at the whole hyperautomation approach as a whole, because, you know, we are establishing this process. It's something that we are putting a lot of effort into. So what we want to do is we want to build confidence that this machine is actually working right. And we wanna take those wins and those successes and encourage buying from multiple other stakeholders across the business. And as this Hyperautomation Center of Excellence matures, we can then refine the scale and the implementation of the sort of the use cases that we wanna go after. And again, I think a pilot or multiple pilots, depending on the size of the organization, is the way to go. To sort that out. And like I say, test and learn, that's really important.

Indeed. And we touched on this earlier. So once things are in life and in production, we need our support teams to make sure everything runs smoothly. So a big, big part is the production, the maintenance, and the support of what we have put in place in the different pilots. And yeah, at some point, Yeah, these processes are ideally producing lots of value and are very sort of business critical. So based on the priority of the process, it becomes more and more important to monitor what's going on in that solution, to really monitor so that we're not automating really bad things quite in crazy times. So So yeah, so the key focus is on monitoring these solutions and ideally proactively identify what's going on and to very quickly adapt to any issues which come up. So that's, yeah, quite important to manage that. So, and yeah, and then the other part is not just the support, it's obviously maintaining these solutions, changing these solutions, and It needs to be very clear who's responsible for making these changes. These changes might result from something that's going wrong in the processes. So, but yeah, you need to have clear responsibilities. Who can make these changes, or when do we make these changes? When we do updates on the whole technology, when do we install upgrades, new software? Versions come up, servers need to be moved, all that stuff needs to be managed. And yeah, so it needs, it needs that really strong, capable team in IT to, to make sure the infrastructure is right, the infrastructure is running smooth. If something comes up, we deal with it very quickly. So I think that's, that's a big part why we, why we definitely need the IT team to be on our side.

Yes, exactly, because I think that it underpins a lot of this. You know, let's not forget that in order to keep the lights on in all of this, you know, we do need that monitoring. We do need to ensure that if we change things, it's done in an orderly way. You know, if we run these processes, we need to monitor them, right? and we need to look at it from more from a centralized perspective so that it's not silos. We don't have all of these operational silos where each of the business units are responsible for looking after their own sort of monitoring their own processes. We want to bring it into sort of a centralized model and in the orbit of IT. So that we can have a very, from a start, a very smooth rollout, but also very smooth support and accountability. And I think this is where governance is really important, because if we're going to go outside the boundaries of IT, that's the easiest way to lose a partner in all of this. I think that's very important to keep IT engaged because again, you know, they're the people that would take this on and they're the people that needs to support this. And, you know, we need them to do so in order to minimize outages, you know, on the ground where operations are using these solutions and keep it stable. I think that's really important.

Yeah, absolutely. So yeah, so I think this is nearly— yeah, I think this should be nearly everything what we can say about setting up a Hyperautomation of Excellence. So yeah, so setting up a center of excellence enables the whole organization to share valuable ideas, access the expertise and competencies and the technology to really harness the power of Hyperautomation and everything what's part of it. At the same time, with the Center of Excellence, we can make sure make sure we can deliver solutions in a predictable time scale. This is also quite important. So everything becomes more predictable with these frameworks and governance in place. We make sure things are delivered towards our quality standards. And yeah, so really make sure our stakeholders are happy and and we become more excellent in what we do.

Yeah, no, that, that's a good, good summary. So if, if I might just— may just recap, um, it's really not that hard. I think, um, there's only 6 points, and bearing in mind, you know, when you establish a Hyperautomation Center of Excellence, just think about governance day one. You know, how do you want this thing to run? Waste accountability, you know, how do we roll this out in a very controlled fashion. Step 2, software. Software selection is really important, you know, reach out to companies like Velocity or Conveyor, you know, we're the type of people that can look at your problems and recommend which software to procure. And then it's all about skills, you know, we touched on various skills, you know, from the sponsor down to, you know, the person that actually supports your automation software. Launching— we've got everything in line, we're going to launch now, we're going to roll out our first pilot, and then it's all just about productionization, maintenance, support. And then from there on, it's scale, you know, look for these opportunities with inside your business. Look for opportunities that you could put forward to your center of excellence in doing such a fashion that it's very clear of the benefits that it will provide to business in terms of hours saved, money saved, all of these sort of things, and really just grow, scale, you know, just push it forward.

Yeah, great. Thank you very much, Arno.

Thank you.

Unfortunately, that's it again with this episode of the Process and Automation Podcast. If you like this episode, please give us a 5-star rating and don't forget to subscribe to this podcast so you don't miss any upcoming episode. We hope you will tune in next time, and until then, let's automate it! [MUSIC] [MUSIC]