Session Information:

Keeping it simple: RPA as a service

Embarking on your automation journey can be a risky and expensive undertaking. RPA-as-a-Service (RPAaaS) removes the risk, cost, and effort of starting with automation.

(1) Understand the principal risks of implementing RPA
(2) Understand how RPAaaS addresses these risks and accelerates adoption
(3) Understand how Security is protected under an RPAaaS model
(4) Understand how a fully automated future state is achieved once an RPAaaS program begins

Session Transcript:

We're talking about Christopher Denver who is coming from Chicago today to share his wisdom and expertise with RPA as a service.

So Chris, thank you for being here with us. Christopher Denver is a longtime process transformation expert, who has realized that automation is an excellent tool to assist in transforming processes. For the past five years, Chris has been assisting his clients with process and digital transformation, primarily following an RPA as a service model that he'll share with us today.

He co-leads the Global RPA as a service, proactive from Crow Intranet from Crow LLP, which is an international audit tax and consultant for him.

He is a CPA and holds an accounting degree from the Great University of Notre Dame, and an MBA from the University of Chicago. Chris, what a pleasure to have you with us. Thank you for taking the time to share your wisdom and expertise with our global audience today.

I just say thank you so much for your warm welcome in the cold city of Chicago today. And I welcome everyone to this presentation. People are still creeping in, which is wonderful. I hope you enjoyed the ... presentation earlier. I think those are great, guys. And I really enjoyed Eric's discussion. And the cool light bulb had behind his head, which I think that's a really, really awesome video trick. So I will, I'll try to steal that, which I think is the most sincere form of flattery.

But today, I wanted to talk to you about keeping it simple.

All right, so how do we, how do we implement RPA in a way that makes sense for even very small organizations.

And by way of introduction to this topic, as you know, krogh, of course, like most of the major consulting firms, has the, sort of the large, at scale, RPA implementation practice.

And that's a wonderful practice, right. And I know ... and other folks are out there and they're doing great work in that space. And so are we. But a lot of our clients would look at us and say, look, you know, I don't feel this, right. Like, I don't think we can go super scale out of the gate.

And so I kinda wanted to talk about why, that is, why they have those questions, or concerns or risks, and how we've addressed that using RPA as a service. So, I'm trying to move. four here.

I appreciate your bearing through our technical difficulties this morning.

So, today, I want to talk about sort of the principle risks of implementing RPA and then sort of why is RPA as a service good, no foil against those risks, right?

How do we de risk or D, cost an RPA implementation using RPA as a service? then? Finally, to talk about how the security is protected under RPA as a service model.

Because the first question I had to me when I started dipping into RPA, came from an internal auditor and she said this is great, but what if somebody hacks my bots, right? And so we'll talk about that.

And then we'll talk also about sort of the future state of a fully automated enterprise.

So I'm gonna go through this super quick, I assume, everybody who's on this call kinda knows what RPA is.

And those are the way we look at as you've got a technology infrastructure that supports business applications and they can support an RPA presence.

And the whole idea with having RPA as a service, you know, or RPA, excuse me, is now embedding more and more specific tools around our machine learning and artificial intelligence, excuse me, AI and ML.

And I'll go through this very quickly, To, so, this is where organizations generally struggle and find opportunities to introduce RPA, right.

So, if there's time consuming manual entries are disconnected, legacy system, we've got pain points around processes, there's risks, there's errors, it's not scalable dot resilient. It's highly people dependent, and people can be very dear these days, as we all know what the labor market being, what it is.

So, this identifies a lot of these risks. Right? So, what are the risks of automation? It costs too much, Right?

It takes too long. If we have, what if we do this and incur all this cost, time, energy, and effort, and investment, and no one uses it?

What if it doesn't work at our systems? There's no way. This is a great way. There's no way I can ask my CIO to take on one more project, right, that that person will kill me at this point. Right, Listen, I don't understand how all this really works.

Because I'm business leader, but I'm not a technologist.

So how can I manage the project after it's installed? What happens, right? Who will manage it? What does our governance structure going to look like tomorrow, next week, 10 years from now?

What if our systems change in a year rendering the bus useless, OK, well, that's part of the planning process. We'll talk about this a little bit.

I talked about what if somebody hacks are bots and then what if we just don't make it right? If we do everything right, and it just doesn't execute well and we're left with a big price tag. So let's break those down. Oh, sorry, on, so each of these comes from a pretty legitimate place.

So these are not know, Wiener baby attitudes. These are legitimate attitudes and impressions that people have, You know, just based on what people see or hear in the RPA space is sort of around the world, Right. So if you spend any time on this stuff, you've seen implementation failures. You've seen projects that run, what do they say? 3, 2 times. two times the timeline And three times the expense is what you should plan for a major system implementation.

So, they run the cost too much, They run over budget, they take too long, The systems don't actually work when we go live, right?

So, I know, all of you have probably been, like, myself part of projects, or IT implementations, where we get to a point where I look, budgets gone times long, run out, let's just take whatever we've got however bad it is. And, flip the switch, right, and turn this thing on. And it's OK, but it's not bright, right?

So, it's not doing what we spent, that $200 million, $300 million.

Thinking about sap and Oracle implementations, right. But the kind of dollars you throw around around those, and it doesn't actually do everything that you signed off on that would do. Your IT team is like, they're not sitting around idle, they're not calling you that, hey, they have any projects for me to do. Right. So that's a legitimate concern, as well.

They have very limited bandwidth, and everyone has systems that don't interact with each other, systems that don't talk to each other.

And then, of course, security is an ongoing concern today, and it should always be right.

So we always need to take that into every recipe that we, we think about around IT issues. So how does RPA as a service solve for these particular risks?

So on the cost side, so the downside of it right, is, traditional RPA licensing models can cost 100,000, 250,000, $300,000.

Mainly because the RPA providers, I'm looking at the Blue Prism UI Path, Automation anywhere, they want you to buy the full suite of products, right.

So, they want you to go all in, of course, they do, but it requires sort of a dedicated server. Your IT department has to have the time, to load it, manage it, scale it protected, configured the whole thing. And as we discussed, they don't have the time to do this.

Now, all that said, Microsoft Power automate tool is much cheaper upfront, and it's driving some significant price changes in the marketplace, Although, power automate itself, no offense to the power automate fans is lacking some functionality.

They're a little bit behind the big three, if you weren't Blue Prism, UI Path Automation anywhere, but Microsoft is Microsoft right there, figuring this out, so they'll do it.

I assume, you know, within a number of years, we'll have a comparable product to the big three, at a much lower price point.

So you're already starting to see some of the bigger dogs kinda responding to that pricing.

But so what's the solution. As, well, RPA as a service is a great solution to this. So under this model, you rent the license from me or from another provider, right. It reduces your upfront cost.

So you're not investing a couple of hundred K to get the license, put it on a box configure and do all this. I think it's all done for you. It's already been done, right. It's already baked in cost on our side. This allows you to kinda try before you buy, test, drive the car date before you get married. However, you prefer to express this. But this way, you can see, like, look, is RPA as a service or is RPA period going to work in our company, will our people adopt to it?

And if it doesn't work out, you just cancel the contract, right?

So, you're out the cost of the bill to this point, but you don't have a multi-year licensing deal that you signed with Blue Prism. Or whoever it is that you've got OK now. No one accepts us and we've got these particular sitting here idle. And it's a big disaster that goes away. Right? And this reduces the cost. You know, luckily when you go to your CFO CIO, this kind of reduces the cost of failure, right? So, if this thing doesn't work in any way, the, the risks are tremendously reduced in terms of incurring costs that end up going nowhere.

Um.

The bottom right, I drew this little graphic.

I was just kinda for the fine points on my, my presentation last night. So, you can go from bars of gold and silver down to $350. now, these prices are not exact. So, please do not accept those as a quote for an entire project.

And it takes a long time to implement, right? So all of us have experienced some sort of an ERP implementation or integration at some point, version upgrade, whatever it is. And these can run for months and years. And things can cause just tremendous pain, Your staff gets overworked wherever you are in your organization. The IT department gets crushed, you have to hire, and these outside consultants who are super expensive. RPA as a service is a great solution to that concern, right.

So our typical RPA as a service project will run anywhere from 4 to 6 weeks, and frankly they often run much, much faster than that. When we start out, we prefer to do the first spot is something that's really, really simple, a pretty easy layout, right. Just get it in, get started on this, get your folks, your people, your culture, adapting to it.

All right, And we'll talk a little bit more about that in a few minutes aside, the cultural revolution around this stuff.

But, you know, once you get the, the easy one in, get it done, build up the IT infrastructure around it that was required to support the bots life, then it's easier to go and do. a second. one is a little more complex, a third one that's much more complex and affordable, and that's super complex. Whatever it is, right, But the point here is getting in small, easy, fast, achieve wins, you know, have those winds recognized by the organization and start to scale?

So, again, we've done it very simply, so we expect a minimal impact on the organization during this period. So people are like, OK, that didn't really hurt, right? And here's this, we've already got an automation up and running.

So what if no one uses it, right?

And so I throw an example of some terrible person named Chris, who might or might not be myself, who, some years ago, downloaded the Weight Watchers After Lose Weight during coven.

And you started off, he, the person who may or may not be, may use it every single day, but then after about six months, this terrible person stopped using it, but still pays the monthly fee even now.

And so this terrible person named Chris is now paying for something he doesn't even use, OK.

So you hate to be in that situation where you've purchased robotics implemented in your organization, and people just ignore it. Right? one of the things I love to say is that, you know, in the movies The, bots always kill the humans. But, in real life, humans kill bots dozens of times, every day. And I tell people that. I guarantee you, you've killed a bot, or two, or three, even this week, or even this morning, and they look at me funny And I said, Well, if you ever logged on to, like, United Airlines, and you get the phone tree, and it's like, Hi, I recognize your phone number, and then you're like, you know, just take me to the age and just take me to the age.

Right? Well, you're killing that Bob. You defeating what that spots purpose is, is to route your call, and you're just, you're skipping it, right? So things like that. Pop-ups on websites, things like robots. And so killing those, exiting them out, you know, that's killing it, right? So what if we do all this? Do all this work, spend all this money, and no one uses our stuff.

Well, proper change management is the right solution And this is not an RPA as a service idea. This is universal to everything that you do, right. So it can be an in-house, or an external effort. But you have to use experienced people, right.

And this is going to include experienced people, I mean, by people who've done this before, right, you definitely want, you don't want to miss on the first couple of bots after that, It'll sort of self sustain, what's your culture reflects us to adopt that. People recognize that this is not a job killer. It's really pain relief, as I've mentioned down below, right. So overcoming that cultural resistance. Everybody's read those LinkedIn articles about how the bots are going to replace you and, you know, you're going to be destitute and some bots going to have your job. So overcoming that cultural resistance is a key thing, particularly in the early days of a project, it's terrible if you implement.

And I've heard some stories where companies have spent five, $6 million to implement 38 botts at one time, and then seven months later, two of those bots are still running.

And the reason is because people kill them, people just refuse to interact with them. And if the box sitting there and it's doing its thing, and nobody's picking of its outputs are giving your inputs, it's a waste of time and money. So there should be a lot of communication. You should have celebrations of successes. You know, early days, broadcast them broadly. Market throughout your organization. Hey, look, we've got the Spot, and it's really kicking **** over here. And it's saving Steve all this time and it's a wonderful thing, right, And then have Steve get up there and say, yeah, this is awesome. Doesn't didn't kill my job. I'm actually elevated to a higher and better use, right.

All the menial tasks are off my plate and now I can really use my with full wattage of my brain to help the organization.

But, user training and ongoing support, a critical, right. So, we did have, and I'll tell you, a horror story here, we had an implementation of a bot that would download invoices from a client And they had an Oracle Cloud instance. And, so, the, the bot was built, tested, moved into production, and the first person who decided to run this bot submitted a download request over 2500 invoices.

Well, the Bob starts running and it ran for 2.5 days, right? So, even though it's moving much faster than our person could do when you load 2500, pull down 2500 PDFs and stick them in a shared directory type of a message to the. But, it's just gonna spin for awhile, right? And so, other people were ... amendment, request and bought and nothing was happening with their requests, and so, they were like, well, this isn't, it's not working. Right? So, having user training, so they know, Hey, look, if you're going to load in a 2500 item request, put it towards a part of the month when nobody's using this. This is a good point. And also, how do you support that?

So having, no shame on me for making this failure, but we should have had an outgoing communication to those people who were subsequently submitted requests and say, Hey, look.

Need your wait for a few minutes, because this other request has been submitted.

We hear you, but it's just not quite there. So any moving missing. Any of these steps can really be challenging to your successful implementation and can even turn it into a complete failure.

So how compatible or the systems, right. And we've seen it before we implement a new system, refused to work with one or more legacy systems, and it creates chaos and RPA as a service, or RPA in general, even. All these ... are generally compatible with nearly any system via an API connection.

So we build bots that are compatible with us for hundreds and sort of mainframe type systems, as long as those mainframes are connected somehow. Right. So we did have a client who had asked for 100 box that sat by itself in its own little room. It wasn't connected to the internet, or the company's network, or anything.

And then they became angry with us when it couldn't connect. We couldn't build a bot to connect to it. That's come on, guys. It's literally completely isolated, Right. So they didn't become angry, but they understood the problem. So RPA can be a great tool to sort of bridge gaps between systems, without doing massive API integrations and hiring really expensive people to build those integrations for you, or junking your systems, and upgrading to something that's newer. And flashier RPA can really kind of helps sustain, say this, but can sustain some of your legacy systems longer. Keep them operating functionally for a longer period of time.

Chicken, defer, Perhaps those system implementation costs.

How do you collaborate with IT? Well, OK, this might be difficult, and I'm sorry for all the IT people on the call. I'm not, I'm an accountant and not an IT person, right? But collaborating with IT is critical in all this stuff. And I don't mean to say that they're unreasonable Box who want to tangle their horns together. I'm more saying. It can be challenging because they have their own set of things that they're super concerned about. Right? So their calendars are almost always fully booked. It's almost exclusively mission, critical stuff, right? Oh, we got to prevent this hack who got a Trojan.

Whatever It is, know, DDS attacks and all that sort of thing. So, saying, hey, guys. We want you to slap one more thing on your daily calendar and, you know, cause cause. You can cause some problems. And challenges, Right. Particularly, if IT feels that, you're going around them, are going behind their, back to, implement RPA. Using the RPA as a service model where they're not as heavily invested in the day-to-day building of it. Right. So, the solution with the RPS model.

It requires the least effort from IT. However, we always include IT at every step that they wish to be involved in. Right, so, we follow whatever your system development life cycle protocols are, we follow all your change management protocols that the IT departments develop. We prefer to have them sort of sit in a governance role, which is a better use of their time, I think, than having them sit down and get their hands dirty with all the coding. It will do that, right. But have them sort of sit and make sure that whatever we're doing is compatible with their overall protocols, with all their other systems and so forth. right. As I mentioned, that, you know, RPA is very compatible.

But you need to make sure that they feel like, at the end of the day, if they're hit by an auditor or by their management team and they say, hey, look. Show me how you guys perfected governance over this tool. They've got to be able to answer that, right. And we've got to be able to help them answer that question, because hanging people out is not what this is about, this, is about, you know? building automation and scaling, without an organization having really great client experience.

So, So, that's the sales on the slide.

Yeah, so we only involve them, really, if there's critical tasks that require their input, their oversight, right? Provisioning us access to servers and systems and things like that. The clients that I have, I have an IT rep or 2 or 3 on every single status call. Sometimes, they attend. Sometimes, they don't. But we keep them fully informed at every step as to where we're at, what's happening, what systems we're using, how we're using them, and so forth, so that they can answer those, those governance questions when the dashboard.

So, then, project management becomes critical, so, like, OK, I've heard a lot about automation. But our IT department of swamp the PMO offices both to 20 25, even if we decided to do this, is no way we have the resources. OK, so, outside of outside provider assistance under RPS model is an awesome solution for this, right. And I love this graphic are searched around and found this kind of different balancing thing, right. So the way we try to run our accrual, we run this RPA as a service model is.

We integrate imbalance with all the pre existing, uh, departments, and governance models within our client organizations.

So we're very sensitive to keeping them in line, making sure that they can move their processes through smoothly. They can check all the boxes that can maintain their governance, or whatever, their managerial skills, whatever they need to be able to do, to prove to their bosses that they're doing their jobs. We're gonna cook, comply with that and make sure that they shine in the eyes of the higher ups, right? So, it's a we've we oftentimes take over the PMO. Sometimes, we split it.

I have a client that we're splitting it with an existing PMO office that they have that has, you know, one person, 4 or 5 hours a week that they can give to this project.

So we've integrated them into our PMO team. And we have an e-mail exchanges and everything before weekly status updates. We make sure we get everything pulled together. So, making sure that we just overall achieve a happy and successful project is a key part of this. And the Outsource PMO Model should integrate seamlessly, right? But if you're using a provider and it's not, I would challenge your provider and say, hey, look. You know, we're not, we're not, we're not working. We're pulling bores in different directions, right? How do we fix this problem? Because it is a problem, and it will eventually lead to some sort of an issue. With the implementation.

So, governance, right, after we go live, what happens to the bot, You know, hey, on the client, here, on this, potentially, small company, I don't have this loss of IT team with me, with all the skills. So, we don't have the knowledge. And I'm gonna have the resources to manage and monitor automations, right? And I've got a client, that's specifically, you said this to me, it's like, look, I need you guys to stick around.

So, the solution there is to migrate from an RPA as a service model, which, you know, where, we're kind of, client, sort of outsource this to us, all the building, the scoping, the build, the design, the build, the test, and then the move to Live Implementation. And then, at that point, the co E as a Service Model, Center of Excellence as a Service can take over and maintain those bots for the client into the future.

So, insurance coverage, you know the helpdesk, right? So, when things go screwy or somebody that, and frankly all the bonds that we build. If the buck fails on overall, or fails on processing a particular item, it kicks out, an error message sensitive, in an e-mail, starts to help ServiceNow ticket right, for us, and, that way, you know, pops into my inbox for my developers inbox, or wherever it is. And, that way, we know, almost, before the client does, or probably, even before the client, is aware, that, there's been an issue with the bot, and, we start working and processing a solution. So, we can meet our SLAs.

All the software, maintenance, configuration, upgrades, all this sort of thing, that has to come along the line now. I principally use UI path myself. There's, I've no problems at all. We do have a client where we're building power, automate with a client. Where were, several classes were building blue, prism, and many, many clients were doing automation anywhere and so I don't have any problems with any of the major for and Even some of the second tier account. Power automate, is made before. I don't know. They do. Anyway, different discussion.

But, you know, none of these, I don't really have any problems with. any of the major systems are out there from, from an RPA standpoint.

But, maintaining our software, doing only configuration, doing all the upgrades, and, because UI path pushes patches a lot, and, and we gotta make sure that when the patch gets pushed, it doesn't disable a bot That, we've got functioning it, for a client under this RPA as a service model. So the key is responsible for, that, they're responsible for seeing, you know, about the nurses are patches, and making sure that there's gonna be fine, and then reporting is key, and it's all, I've only got one word on this sharp.

Probably should've put an entire slide, when you have a bot up and running under C O E, or, sorry, under RPA as a service or any other model.

If it runs effectively, it's like nothing's happening in the background. Right. So it's very justifiable for the leadership of the company and say, hey, look, you know, we spend this money. We incurred this time and energy, got these spots in place and I don't see anything.

So, one of the things that we do, and I recommend this as a best practice, is to implement some sort of a dashboard. program. Using Power BI or Tableau or whatever you've got that's already available to you and, and do reporting on your bot, right. Have your bot fill up operating statistics. How many times did it run. How many items that are process. If I ran, How long does each runtime Basic core statistics like that that demonstrate that the bot is running? And I was producing, it's actually being productive.

And capturing also how many errors, right, So how many errors is the bot encountering? And if that number starts ticking up, picking up, picking up, maybe you need to do a rebuild or maybe you need to reconsider.

Second bot to handle this different new process is coming through, the continues to fail, the first bot.

So, reporting is critical to our operations and our long term success with our clients. And finally, scaling automations in the future. And I'm gonna talk a little bit more about the future state.

But, uh, everything that I'm talking about with RPA as a service model is done with the idea that we're going to do one bought today.

Tomorrow, we're going to do another one. You're gonna love that, You're going to ask for a third one, we're going to do that. You're going to ask for fourth one, we're going to do that, and then sooner or later, work sort of off to the races. And we're automating an enterprise towards that vision of a fully automated enterprise for the future, and I'll talk a little bit more about that.

one of the things that's critical about ... service model, that integrates with an existing ... at our clients as well. So, if they already have a code that handles their people, soft implementation, or whatever it is, and we can integrate with their skills, and resources, and their team, as well. And make sure that we're collaborating together for a successful outcome, for everyone.

So let's talk just a moment about security. Right.

So what if somebody hacks by bots, as much goodness of automation can do quickly, kind of hack causes to do even something that's really, really bad. Even faster, right. And of course, the answer is, Well, yeah, right.

So if you have carelessly, put your banking information into your bot and have it go out and pull down bank.

reports from you and you've got your account and you got your logins. You got all that sort of residents, but. And somebody hacks the bot, you've got a problem. Right, so now, your information is out.

So, our under RPS service bottle, we ensure that it's highly, highly secure, and I'm sure even are under a non as a service model.

It should be highly secure as well, so isolating your environments, this way you can find good internal controls. Right, you have a desktop dev environment test for production. Restricting access to each one of those sort of as an IT general control, if any viewer, socks, clients or sox companies, this is a critical thing that you need to be able to perfect and demonstrate, obviously.

RPA as a service includes code reviews as each stage, so as we move from sort of really designed to dev and dev, to test and test prod, generally have an IT auditor, or no CSO or somebody from their team sitting in their monitoring, the code migration, validating that There's been nothing added or taken away. That isn't well known and circulated and approved by the leadership team following IT audiences: development, life cycle: control, protocols, and controls mentioned that a little bit earlier enabling audit trails and all the relevant systems is critical.

Nothing should be tracked. Everything should be very transparent. Right? Nothing should be happening behind the curtains.

And as you know, just in the security itself, this is UI path specific, but there's a S, 2, 56, 365, and encryption, sorry, I think it's 256. I think a flip flop, this bit encryption that passwords are all protected and CyberArk. So we've, you know, the major bot providers, or they're all taking this very seriously, and they are ensuring that they've got top notch tools, right. And as a final thing, you know, we also set up multi tenancy with all the robots.

So if by chance, someone were to hack one of the bots they couldn't hack another bought, either with, from your organization, or from another organization, right? So we've, we've secure this.

Now a motivated hacker with a bajillion dollars to spend will find a way, as we all know.

But this is all about reducing risk to a reasonable level, and when we believe we've got our, our clients there, most of our CSOs, our clients he says are very happy with this, including prose, C So which is pretty amazing if you know it.

So what does this future state look like in a fully automated enterprise?

So I've got a little rainbow graphic here, right? And part of the, the idea around that, is it, no matter how much you chase it, it's always a little further off. So you're never there, right. There is no destination of a fully automated enterprise, because things are changing constantly, as we know in the IT landscape. And so there's always more new features and functions that come out all the time. But, you know, as I mentioned earlier, the RPA as a service model, we build one another. And the more we try to scale this, right?

And eventually, if you've got enough Boston your operation, a client, or approach us, though. We haven't been running long enough for this to happen yet, but you'll come to us, or will come to you, and say, Hey, look, what payment a lot of money every month, as part of this maintenance fee, that includes crows payment of a license.

Only make more sense for the client to buy their own licenses. Was sure. And we'll help facilitate that transaction. And you can use our discount, right?

So it's a great solution to eventually, you know, if you want to be a fully automated enterprise, if you want to earn your own licenses, this is how use RPA as a service to test, drive it. And if you'll love it, when you buy the car at some point down the road, right, and handle your own financing, et cetera. Under the ... as a service model, we provide assistance to our client series. So we kinda stand them up until they're ready to run on their own right. So we, we give them all the skills of bandwidth and things that they need to run their own ... around RPA and then as they build skills around this, as they build their own competencies.

And they feel confident do it, we can hurt it over to them, right. So, now you're, back governance, ongoing is yours. Thank you very much. And, you know the fully active ..., whether it's in as a service or its internal to the company, It should managerial sourcing the privatization of new automation opportunities, which she should lead to even more accelerated growth of bots in your problem.

And one thing to always keep in mind, and this is a good rule of thumb, regardless of systems is, when do these things get sunset? And when do we decommission?

Right? Nobody's going to last forever. So let's begin with that end in mind to borrow from Stephen Covey and say, hey, look.

What does this sunsetting look like? What's our estimates of this? How long will this run? What will we do when it dies, or we have to pull the plug on the bot?

So, making sure that you've got some plans in place, So there are no surprises at any point during the life cycle of these bots. And then fully automated status, right. You've got bots running and all, or nearly all your departments are.

Performing a whole variety of tasks, really, really energizing your company and allowing your, people move at a higher and better use.

So, some of my final thoughts. You know, what is RPA as a service, right? It's simple, it's flexible. It's easy to get started, now. Very quick results. It's pretty low cost compared to the full load model. And like I said, you can see very, very fast results and get the benefits right away.

I want to thank everybody for your time today. I really appreciate your attention!

And, of course, my favorite line is, if you hate it, automate it.

That's fantastic, because there you go, if you hate it, Automated Christopher? We have a number of questions that have come up appear as, you're speaking several questions around the concept of the Center of Excellence.

So, let me, let me bring my camera back on, and the latins start with that.

You know, the Center of excellence, sir, as a service.

William Fuller makes a comment here that it's not easy to get departments and functions, to be live in, or accept the advice of an internal Center of Excellence.

Yeah. How does a third party, external group gets credibility in the Center of Excellence?

Just curious about some of your best practices that I think people are going to be listening to actively because they may want to be incorporated that internally because centers of excellence often struggle to get their ideas implemented internally.

Boy, what a great call out, right. So that's, that's a proof in the pudding question, which I love. So thank you, William, for that question. No?

Couple of things I would say about that is that we have a lot of experience operating under the coe as a service model, that I feel allows us to.

It's built our muscles in the space of doing this internal convincing, right. So part of our overall change management philosophy around RPA and RPA as a service is that we want to come in.

And we want to market these successes, these early successes, broadly, across your organization.

And those are generally occurring before we've established in sort of formal ..., whether it's formal CW or formal seal use a service. So we want to bring those wins through a lot of internal marketing, and branding, right? So I've got a great client who, you know, we had some bots, so we did, I don't know, I think they went live in August, September, for them. And then, you know, by January, February, the CFO came to me and said, hey, look, we kinda rebrand these and research. Collate them because he had sort of hitch is star to this whole RPA as a service idea.

And so he wanted to make sure that his bought a few days, right, we're ....

And so, sure.

So, we sat down with their marketing team, and we kinda came up with an internal marketing scheme to kind of blast, you know, targeted e-mails around, sort of stuff on the company, SharePoint.

Talked about the great successes of this. So, there's many, many ways to, unfortunately skin this cat, and I'm going to give you the consultant's answer.

It depends William, but, you know, working with your organization, understanding their culture. And these are some things that we do very well. So, we try, you know, we do our best. Or We always successful will know, right. So, I'll be very transparent. Would always work, but it works a lot of the time, Right, and we're able to kind of leverage what we understand about culture and cultural resistance to, to try to achieve broader acceptance of these things, right.

From my perspective, I generally find that people tend to pull harder on the oars when they've had a chance to chart the course of the ship.

All right, so we want to take, if there's some areas of ... in transit areas that are pushing back within your company, We want to go after those people head on, and bring them into the planning process, and say, well, how can we make this work for you? And try to open it so, totally understand what you're saying. It depends on, really, what your culture and your personalities of the people involved are. And it doesn't not always work. I'll be, I'll be brief.

What I said, I do, they've famous quote on, if you want to get people engaged in implementation, you must engage them at the point of creation and the and the and the well said there, that's a complex question and answer.

As a matter of fact, we're going to have in mind for the last session today, is going to focus exclusively on this cultural aspect of automation, because it's such a such an important concept, and, but it's a very challenging concept with a bit more tactical.

Another question is, related to a comment you made that, that the bots, they get rejected by the end users, You know, after some time. And the question is, more about the user acceptance test. And the, and the person who provided this question is saying, maybe, I'm old school, you know, we used to do user acceptance testing. Is that not a thing in the land of RPA nowadays? Is unique to traditional implementations? There is also a feature in a no low code environment as well. The question is about, just a little bit of Contact, Shawn You saying that the users may reject it? Is user acceptance testing Is, do a thing on the RPA Implementation or not?

Absolutely. So what a great question.

And another, another hole in my presentation. So I appreciate you're calling it out now. So user acceptance testing is absolutely part of our overall process.

What we find though, is it when you're implementing RPA, you're changing the underlying process, right. You're, it's a digital transformation of a formerly manual process. So if you think about it, there's a progression of manual tasks to wear a bot starts. And then a bot ends and then hands it back to people.

Right.

So there's these two transition points or more where you've got people and bots interacting, and making sure you manage those transition points is this. That's the secret sauce, right? Like, that's what makes this work, or fail, frankly.

So, yes, user acceptance testing helps, but, you've asked somebody in many cases, right? So, I'm just gonna pick on random people who don't exist, OK? So, Sallied has been doing the same task for 25 years in your company and her whole value and sense of self worth is tied up in manually producing this report. And all of a sudden you automated that report.

Well, what's salih going to do?

Right, so unless you've got a good change management program, looks like, hey, Sallie, look, we're going to train you up because you got all this institutional knowledge. We don't want to lose you, right? So we're taking away the majority of what you do.

And I've got some great war stories, I probably don't have time to share about this, right, where we're able to kind of scale people up and get them to reform a higher and better use than this manual reporting stuff.

But if you don't do that, right, if you don't take that time, to work with Sally, what is she going to do?

She's like, OK, well, I can lose my job, or I can kill this bot, right, I'll kill this bot.

And so, that's what I'm really talking about. Specifically. There's culture and people kill box. As I mentioned, every single day, dozens of times a day, it's the easiest thing in the world to do is kill these things.

So, working on that. Change Management Protocol, Yes. Do user acceptance testing. Absolutely, right. We'd follow all the best practices on the life cycle changes, and all that.

Absolutely, Definitely U.a.t. is part of it and making sure, though, that we're managing this process well, and we're interfacing with all the people who are impacted by these bots is critical.

And we're almost out of time here. Christopher Asana. I want to make hit a point that you made very well. First of all, you're talking about some very unique things, very important, things like governance. And that, we have not discussed in the previous session, but specifically in our, in our previous session. There's a lot of questions about, hey, listen, I'm not a fortune 500 company. I am a smaller business pool.

Maybe thinking can use RPA, but maybe it's too expensive. I think you're just you talked about this. But I want to emphasize RP as a service the way you're discussing here. It's a great way for maybe smaller businesses. Or people. Who want to experiment with RPA to get started. Is that right?

Yeah, exactly, right. Thank you. So absolutely, this is a great way to kind of get started. Dip your toe in the water, for fairly low cost, right? So I would say our average RPA as a service bot is in the $20,000 range.

But we try to do the first one out of the gate, like I said. Keep it simple, right?

Keep it very, very high level, Bob, it's usually down around 10 to 12,000, right? Exact quotes. I can't give you that, right? It'll vary by the instance in our complex. The bot is and how tough your systems are to work with, right? IT infrastructure is a killer killer. So that's another thing we have to worry about and work with our clients on a lot, is to get their IT infrastructure tuned up to support.

But, yes, this is a very easy, fast, low cost way, low risk way to get yourself automated a little bit.

Test it out, test, drive it, see if it works data while you love it, Marriott, if you don't.

No harm no foul right? We just, we break up, we swipe left or whatever it is that the kids do these days. And we're everything's good. And you've tried it right, and you know that it doesn't work in your company for whatever reason.

But at least, give it a try.

Terrific, What a great presentation. Thank you for introducing RPA as a service. Incredibly helpful perspectives. Appreciate your thought leadership, and on behalf of our global community. Again, thanks for taking the time to be here with us.

Thank you so much. It has been a wonderful presentation, I wish everyone a wonderful rest of your day.

Thank you. Ladies and gentlemen. That's Christopher Denver, with Crow and wonderful presentation and introduction to all of us on RPA Now as a service. We're going to be shifting gears. I'm going to stop the session now. We're going to be shifting gears into the top of the hour. We're going to be bringing the Vice President of Engineering at Brasilia melodic, Milano, which, and he is going to be talking about their RPA program on a global scale and why RPA programs fail and how you can prevented again for our leader and practitioner perspective. So do not miss this session at the top of the hour. I'm going to be taking a break now, If you have additional questions. You know, find out what's going on. What other, what the speakers, and other participants are.

Saying, Go on to my name on there, shows that there is a LinkedIn, and you're gonna see there is a posting that I have put it there. On this conference, RPA and intelligent automation. You can post additional comments or questions there, connect with the speakers directly. Because they're all hyperlinked in that post and we can keep the conversation going that way as well. So, for now, enjoy your break, I'll see you back with ..., Milan of each at the top of the hour.