Mastering Application Management in Robotic Operations Centers

Navigating the labyrinth of application management within a Robotic Operations Center just got a whole lot clearer. We're peeling back the curtain on the strategies and tips to steer clear of the potential snags and hitches that automated processes might face.

Armed with a matrix to track process-application interactions and a keen understanding of uncontrollable versus controllable applications, we guide you through the critical steps to avoid unexpected disruptions. Our discussion zeroes in on the necessity of forging strong alliances with application owners; these relationships are your frontline defence against updates that could throw a wrench into your well-oiled automation machine.

Ramp up your game as we explore the nuances of integrating automation tools like bots with applications, capturing the essence of collaboration with application owners. Hint: it's not just about sending emails back and forth! We underscore the shift from basic tools to high-tech systems designed for keeping tabs on your applications as you scale up.

As a bonus, we reveal insights on how to kick-start these partnerships with application teams, fostering a climate of cooperation essential for the smooth sailing of your automation endeavours.

It's an intricate dance of communication, anticipation, and mutual understanding, and we're here to lead you through every step.

Join us and learn how to master the art of application management, ensuring that your automated systems run like clockwork.

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

Chapters

• 0:05 Effective Application Management Strategies
• 7:44 Managing Application Relationships and Impact

Transcript

Speaker 1: 0:05

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 organizations to help them grow their return on investment in automation. In this edition, your hosts, daniel Andrews and Kieran Gill-Murray, are discussing the critical role of application management in automation operations and the need for proactive strategies to address challenges and ensure the smooth functioning of automated processes.

Speaker 2: 0:43

Welcome back to another episode of Automation, unscripted. Today we're going to be focusing on managing applications within the COE, or ROC, robotic Operations Center. So this is a pretty important topic. I'll be honest with you, it's not the world's most interesting or sexy topic, but it's definitely, definitely crucial to be part of the COE or a rock, and this can be tackled in many ways, and Kieran and I are going to discuss sort of our experience on the subject and how we've gone about it. How are you doing, kieran?

Speaker 3: 1:19

Yeah, really good, really good, and I'm laughing here when you described it as sexy or not sexy, because I would put this forward as your mastermind topic and I think you would be scoring pretty highly on this one, dan.

Speaker 2: 1:30

Yeah, I think I probably agree there. But you do have moments within this topic, especially if you join a client that's already at scale and hasn't got this sort of architecture in place. I put it that way you really do get a holy shit moment when you realize the work and the effort that's going to go into it. So let me provide a little bit of context on the sort of situations that I'm talking about. So let's take the example of we're using an RPA tool, we're using UiPath.

Speaker 2: 2:00

Let's say the client has 10 processes that are all in live operate production and we're covering, say, 20 applications. So out of those 10 processes, in total they interact with 20 or so applications. Now most of these applications will have updates and releases, if not all of them. That may or may not impact your processes. So if you have those processes live in production and no one's monitoring those 20 applications, in my head you have 20 risk points there. Each application would count as a risk point and they could impact one or all your processes. So what the Rock needs to do is they need to know when each of those 20 applications is having releases or updates. That's effectively the problem that you can have if you're not ahead of it. You have risk points everywhere.

Speaker 3: 2:55

And you would be amazed how many people are actually not in control of the risk points and how many people forever get surprised when something does change. How many people forever get surprised when something does change. And those surprises, dan, are something that we want to do away with in any intelligent automation center any it center, for that matter, as well. So what have you done, dan, then, to solve this?

Speaker 2: 3:15

because you have done this at scale yeah, I've done this a couple ways, but I'll I'll go through the most more simplistic way that we've managed. And don't get me wrong, right, once I get through these steps and everything's implemented, I can guarantee you that they will still be application releases or changes that impact your processes. But the goal is to get it to a degree 95 plus percent where you're covered and you can then look back on an issue that's happened and say look, we had this in place. How could we improve this? That's the world that you want to be in. So I'll start with just the basic setup. So the first thing you want to do is you want to stand what you want to understand what processes interact with which applications. Sort of build a matrix x, y axis here are my applications, here are my processes, what touches what, and then you want to understand how they interact. So there's different ways that a process can interact with an application. I'll give you two examples. Either API calls I won't go into that, I'll assume everyone understands that A more stable version, really, for this topic. And then you've got UI, which is the user interface, which is a method that rpa tools utilize. They use the same interface as a human would so imagine. On a screen you have buttons. They will select certain areas within that screen and that's the ui. So that's step one.

Speaker 2: 4:39

Step two is understanding what applications you can control and which ones you can't. Now this is a little more difficult. So what I mean by that is some applications let's take the 20, for example. You might have six or seven applications that you control as a business. That means you can release their updates when you need to, or as and when you need to. That means that those are much easier to handle because you can go through set testing and UAT cycles Brilliant. Now the problem that you run into is the ones you can't control, and this is where, really, where this work comes in. The ones you can't control, where releases can happen at any point. Those are the ones you need to be ahead of. So, step one, step two, step two understanding what you can and can't control.

Speaker 2: 5:29

Step three is probably the most arduous step and the one that is great, but it's not the sexy part of automation, put it that way and that's building relationships with the application owners. And, as I pointed out there, that's just an example of 20 applications, right? So you, you likely you and your team are sitting down with 20 different sets of individuals and the goal here is to understand what their application does in a little bit more detail. Understand, hey, when does this application get updated? When do the releases go in? Are they planned, are they unplanned? There's a lot of parameters there. And when are your low environments updated? Ie, where are the release notes? How can I get hold of this? And that's step three. So you're really starting to build out a map of how your landscape looks.

Speaker 2: 6:18

And then the fourth one is figuring out, on an application by application basis, how you prepare for those updates and releases. So that's sitting down with the app owners. And not all applications are created equal. So you're sitting down with those app owners and you're saying, right, here are your releases, here's your update schedule, here's all the planned ones. Tell me about, when is this released in your lower environment? Can we do testing X, y and Z? So that really, for me, is the fundamental. If I had to boil it down, four steps how to set it up.

Speaker 3: 6:51

Yeah, and that sounds. It doesn't sound easy that, Dan, and even for the application owners themselves. That's tough because you mentioned something a moment ago themselves. That's tough because you mentioned something a moment ago the known and then the unknowns. Because very often application owners themselves I hope they read the release notes. Very often they don't and therefore they're surprised. And let's be honest with the odd manufacturer of software applications, they may themselves forget to actually tell you what's happening or tell the product owner what's happening as well, and it doesn't really matter how good your change management is, but those things happen. That, as you said, is the 5%, not the 95%. So, Dan, how do you go about building those relationships with application owners, and are there any tools or ways of getting this to work and making it a heck of a lot easier than tripping up and down the virtual carpeted floors of a large international organization?

Speaker 2: 7:44

Yeah. So I find the same, as not all applications are created equal, not all application owners are created equal. So in an ideal state, you get on the phone with someone, you get on a meeting and they're very interested, very intrigued to how these tools work, happy to help X, y and Z. On the other hand, you sometimes get application owners who jump on. They have no idea that your process is interacting with their application and they're almost throwing a fit saying how is this working? Why have you got a bot touching my application? So there's a lot of avenues you need to navigate there right, and I'll go with the simple one. Let's say the application owner is thrilled to be working with you.

Speaker 2: 8:24

The ideal scenario when you're working with an application team is, in my head at least, is to get them to understand how your processes interact with their application. So let's say we're working with ServiceNow and the application team needs information on how each process interacts with ServiceNow. I'll provide them with this click-by-click level right. What pages are we? Let's assume we're using the UI layer. What pages are we looking at? What buttons are we selecting? It's then their job. From that, once they have an understanding of how your process works, it's then their job, if a release is coming, to determine the impact of their application change.

Speaker 2: 9:05

Now, I always do stipulate that it's not 100% accurate. Let's say 90%. I'm not going to hold them to the sword if we have an issue and they've said, yeah, we're fine, we're just trying to get it to a high degree of accuracy. That would be my ideal scenario getting them to determine the impact, because, let's be honest, 20 applications is a small amount in the terms of automation and when it's really at scale, imagine 100, 200. You're never going to have a team that understands 200 applications and can read through and understand the release notes of each application. It's just an impossible task.

Speaker 2: 9:40

So, getting the application owners to understand that, because they're the experts, and then determine impact, that's the way I would go about it. In terms of your second point, tooling, there are tools out there, but you really need a whole lot of buy-in from every application owner. So, yes, there are tools, but my advice would be start off without tools to understand the landscape. Just start off mapping off the area and maybe utilize a general tool to help you manage said applications, a general tool that can help you track and maintain, get away from excel and move into tooling on that aspect so we need tooling and we can't burn people at the stake.

Speaker 3: 10:22

So it sounds like relationship building is key. Could you technically ignore the infrastructure and applications and ignore having conversations with these people like how important is it to have application management and the relationships and the understanding of the actual environment itself?

Speaker 2: 10:42

could you yeah sure, you could 100 ignore everything, but if you, if you were running a rock or as part of the coe, ignoring those application changes would be detrimental to what you're trying to achieve.

Speaker 2: 10:58

So you're trying to achieve the value from your processes ultimately, and if you're constantly needing to modify processes, to retrospectively change, deal with application updates, it's impossible. And this, and it will also be very, I guess, arduous. So I head up a couple rocks, right, I really wouldn't want to be waking up every morning thinking what application problems are we going to be facing this morning? So I know, with the setup that we've produced with multiple clients, and if I wake up and yes, or I hear that, hey, we've had some application issues, we've got this process down, I know that we have everything in place. So it's just, hey, what went wrong here? Unlikely to be on our side, but if it is, we'll improve it. So for me, it's vital to have the rock and the coe doing this type of work, because you actually can't function without it and as you scale it gets worse and worse. So ideally you have it from day one.

Speaker 3: 11:55

If you don't have it from day one, start doing it um, where's your sense of adventure, uh, so so how important is it?

Speaker 2: 12:06

yeah, it's. For me, it's vital, um, there's no way around it. Wherever it sits, it might not sit within the rock or the sea, are we right?

Speaker 3: 12:13

it could sit elsewhere, um, but this type of work needs to be looked at, it needs to be done, and you need to be ahead of these type of things so what's some of the challenges that you have faced and, dan, to get this up and running, because in the main, it sounds reasonably simple, like you identify the processes, you identify the applications, you go and have an adult conversation with the owner of those and everything works smoothly, or not.

Speaker 2: 12:40

Yeah, there's a couple. I said a moment ago that it's good to start at the beginning, when you've got less than 10 processes. If a client comes to you with over 50 so processes touching a huge amount of applications to set this up, they will have things in place for some of the applications. But to set this up is a huge challenge and just to keep up because you're you're massively on the back foot. So that would be the first one, right? Not starting early. The second one I think I mentioned earlier as well not all application owners are created equal.

Speaker 2: 13:13

It's a difficult challenge trying to bring everyone together as sort of one team when you're talking about 20 or 30 different application teams.

Speaker 2: 13:21

You've got to educate the teams and then you've got to sort of onboard them and make them interested in what you're trying to achieve, because if you don't have that, it can be a real problem.

Speaker 2: 13:30

And you can guarantee if you're dealing with 20 applications, two or three of them are going to have really difficult teams around them. And you can guarantee if you're dealing with 20 applications, two or three of them are going to have really difficult teams around them and it's not necessarily a bad thing, but it's just going to happen. Right, if you just did a percentage of the number of applications you're looking at, that's number two, and number three is then, once you have those good relationships with the application owners, it's convincing them to determine the impact and why you as a team shouldn't determine the impact, because a lot of teams will just think, hey, he's trying to throw this one over the fence, right, make us do all the work. But it's about getting them to understand that that's not the case. It's just it's impossible for us to understand your application the same way you do. So for me, it has to be on the application owners, and that's a tricky part. If you can nail that down, you're on the right road.

Speaker 3: 14:25

Gold star time then. So how often do you have your conversations with these application owners, Dan? Or do they initiate it? Is it a cycle? Is it ordered, not ordered?

Speaker 2: 14:31

To start with, you'll obviously have your intros, get them up to speed. Let's assume all that's gone well and you've got an application team who is excited and willing to help you. Then you've got to figure out what their cadence is of their releases. Let's say they have a standard monthly release. It's then your job to proactively reach out to that team prior to release, whenever you've agreed you will. To then say, hey, there's a release upcoming.

Speaker 2: 14:57

I see it's on what's today's date, the 2nd, right 2nd of May. To then say, right, I see your release is coming on the 17th of May. Is there a lower environment we can test on? Do you perceive any impact? So we really have a cadence that's pre-agreed with them, where you're consistently asking, reaching out to them, saying calls if you need ideally you don't to gauge impact, gauge the lower environments and really make sure that you are covered for that release. And it works the other way as well. You then say to the application teams if there's any unplanned releases, here's our distribution list, email us, ping us. So you have a two-way street you'll proactively reach out for all planned updates and they will reach out to you if there's any unplanned ones, which is worst case scenario it was unplanned releases.

Speaker 3: 15:46

They never normally go well, yeah the morning, of the adventure which is every morning. Well, it sounds sensible, as I would say. You need a coe. We've discovered that. Maybe talk about that a little bit more in some of our podcasts. You need a rock, otherwise, if you're not managing the processes, then you're leaving yourself open to chance and the business value in the business impact, unnegotiated, unregulated and on everything else, just won't work.

Speaker 3: 16:13

And then again, as you say, everybody has to shake hands to get everything to work at the same time and when all those things happen, you're pretty much maybe not 100, but 95 plus guaranteed that things will work, and that's about 95 more than most rpa or automation environments that I have visited at some stage. So it can't not be a good thing.

Speaker 2: 16:35

You can sleep well at 95%. Anything below that's a challenge.

Speaker 3: 16:43

Unlike our readers, I do need my sleep or our listeners. I should say we want them awake.

Speaker 2: 16:51

Yeah, I think that's a good summary and a good place to end, so let me go over a couple of things we covered. We covered the problem statement, actually what the issue is, why you need to solve it. We talked about what I would consider the standard approach to how to deal with it. We discussed how important it is and then we went over some of the challenges that we faced. All in all, I think we covered the topic pretty well, I guess. Closing, I would just say that it really is and I stressed it before it really is vital to have this in place, whether it's within the rock or outside it. Without it, you will really struggle to keep up with a dynamically changing environment. Thanks everyone. See you next time.