Trends in Automation (CompTIA Volley)
Carolyn APril: Hey everybody. Welcome to the latest edition of Volley. I'm Carolyn April. And as always, I'm looking for my good buddy Seth Robinson, Seth. Hey, it's good to see you again. You were out all last week on vacation. How was that? Like, it was lovely. Thank you very much. It was a nice, nice vacation
after channel con. up in Maine, the coast where I go every summer, had good weather. Saw a bunch of family. It was nice. I seem to have brought home a little head cold with me. Unfortunately, that goes with the territory of my I have cousins who have little, little creatures that you and I don't have anymore in the child world, but they tend to be a little germy. But otherwise, I had a great time as fun.
Yeah, that's good. Yeah, yeah. No, no fun to come back with something. But better than having it while you were there. I guess. I was very healthy. Yeah, it's hard to come back to it. Now. I'm surviving fine. It was it was a nice break. So thanks a lot.
We barely come together while you were gone. But we managed to do it. So I know. Very difficult task. Without me, I'm sure. So today, we have a
guest though, I'm really excited because we have a guest who used to work at CompTIA, too. So it's like old home day for us. That's right. That's right. This is the first time having a CompTIA alum as a guest. And we are really excited to welcome
Corey Simpson, who is now the COO of the international legal Technology Association. I get that right, Cory? Yeah, that's it's a mouthful. That's why we are welcome to the to the show, we wanted to have you on we want to talk about automation a little bit, I think we've talked about it, here and there on Bali, but we've never really focused on it. And, and so as the CEO, or you have it working for you, but you also oversee a lot of operational stuff. So you see both the technical side of the house and a lot of the business process, right? Yeah, that's correct. In fact, when I first came to Ulta, I was the chief technology officer, and then have worked my way into a little bit more responsibility. But my heart is definitely near
and dear to the technology side of things. Oh, very cool. So why don't we jump into it? at a really high level talking about automation? I think there's automation on the IT side. And I think more and more companies are looking at automation on the business side or automation of their workflows. So how do you see those two things playing out? Do
you see them both happening, you know, quite a bit in your organization or other organizations? And, you know, how are they kind of the same? How are they different? You know, what's the situation there? Yeah, that's an interesting question. Because what it really comes down to is like, a standard cost benefit analysis of doing the task to automate. So whether you're automating it processes, or you're doing business workflows, depends upon your business, like what what is the what is the high volume task that you do, that it has the value for automating? Because some people think you can just sort of like, turn it on and turn on a bot and things are gonna work. And that's not exactly how it goes. So I'll give you a couple of examples. Like, if you're an IT managed service provider, you might automate the provisioning of new users, because that's the thing that happens every day with your clients going out. But if you're if your organization like ilta, you know, we only bring on a few new people every year, and so automating that task wouldn't be worth it for us. Or like a community banks and other
example, you may not bring in a lot of new people. But you've probably process a lot of loans. And so automating that task is where you get the value. So that's, it's really how much
volume you have, and kind of what's the level of effort to deliver that volume that really determines whether you're gonna do an IT process or a business process. I like I like that. One of the questions I wanted to ask you was about what you don't automate, because I think when people talk about automation, employees can get nervous, obviously, about what that means for them, and their and their jobs. But also, to your point, not everything is ripe for
automation. And it really does go down to whether it's something that's a high volume activity that you do or a process that you do within your organization. How do you figure that out, though? I'm curious if you can speak from your experience at your association? Do you just sort of sit down and sort of weigh like, Okay, this is a this is a high volume activity, this isn't D bubble that up from the employees that come to you and say, Hey, this is something that we do repeatedly, every single day, we could maybe automate it. How
does that work? Exactly? Yeah, the equation really comes down to what is the volume of the task you're doing and what is the cost to that task to an employee doing that task. There's some very niche cases where you have a really high value activity that needs to occur and then you could automate that and make for example, in the stock market environment, you know, it's is not RPA in its true sense, but but back in the day traders used to use spreadsheets and they said, when this number hit here and this number hit here execute this trade. So that's a high volume most of the time for and for most of the organizations we see, it's round. Okay, how many? Like how many environments do we have where we've got a lot of staff doing the same high volume, low value activity, and where we maybe see transcription errors and data entry errors? And then let's go ahead and automate that. So that's kind of like, if you remember, rolling
this out is a software development project. And so you have to balance out that cost against okay, what are your savings? Were your cost savings against that? Yeah, yeah, that's, that's interesting. I, as you're talking, Cory, it's making me think of the way that we've started talking about emerging technology is that most of them are not an end unto themselves. I don't think a lot of companies
are saying, let's get some IoT in here. Let's get some artificial intelligence in here. I think that they're looking at it from a broader perspective, and kind of saying, Okay, this this overall process, it can be helped by Internet of Things, devices, or artificial intelligence, or whatever. And I'm kind of feeling like automation is the same way that, you know, in your experience, do you feel like you would typically, you know, be proactively saying, Let's do automation? Or are you looking at processes? And you're always trying to say, how are we defining processes? How are we getting the job done? And then sometimes automation becomes the way that you do that it's kind of a tool in the toolbox, rather than, like I said, an end unto itself. Yeah, I think that's right. And I think there's a general theme
around emerging technology that you have to consider, I mean, the way technology is just continuing to advance more and more presents all these emerging technologies that are going to take over the world. And you have to decide well, which ones do you are going to be the most value for your your business? And that really starts with, what problems are you trying to solve with your business, and then which piece of emerging technology is going to help you do that? If you you know, if we're sitting here, and I'm saying, I'm in the legal technology space, and so blockchain smart contracts, you know, there's the talk about them taking over the world. But there's still a lot of business going on. And if we went all in
on blockchain, you would miss out on a lot of business opportunities to improve. So I think when it comes to rpa, I wouldn't look at RPA and say, Okay, how can I apply this to my business more than look at RPA? Get that one page or cliffnotes, of understanding the value. And then as you're going through your business, and you're saying, hey, you know, we have a ton of costs associated with processing this high volume activity, or we have 50 people on a call center doing this task? Is there a way that we can automate that task so that those people can then do something that's more higher value, right, that's more fulfilling for their job? Because there's nothing from a knowledge worker perspective, more more demotivating than having to do the same task, right, like pushing the little button every day, it just doesn't, it's not satisfying. Yeah, I think you make a good point about knowledge workers and just workers in general. And I think we can't really talk
about the topic of automation without discussing the impact that that may have, or the impetus for doing it might be to reduce your headcount within your organization. And from what I'm hearing from you, Cory, is that isn't the way that you're that you're approaching it in that automation is more a way to free employees to be able to do a do more strategic type activities and not work on the lower level, high volume things. But can you talk a little bit about how an organization though, that is going to introduce some automation features, sort of helps the staff not freak out? That would be like, the most blunt way to put it? And? And what's the messaging there? Yeah, that's a good point. I think a lot of people think when it comes to rpa, you're just gonna buy a bot plug, turn it on, and then all of a sudden, all these tasks gonna go go away. But in the end, it is a technology project, and you have all the stages associated with the technology project. So you have to, at the very beginning, define what you're going to do.
And then you have to design it, build it, and then there's that whole rollout piece, right. And back in my Accenture days, that rollout piece was like 50%, of where projects that failed, that's where they failed. So you have to appropriately plan with your staff. Okay, what what are we doing? What are the changes we're making, and then craft the message and the changes in the organization so that they see the value for themselves, right? Like the what's in it for me sort of position. I mean, if I
was if I was sitting on a call center, and I was doing the repetitive tasks for 40 hours a week, and they said, Look, we're going to go through this change, and it's going to take care of these provisioning user tasks all the way through. And so your job when you get one of these requests is to can we put this in and keep touch with the customer have softer relationships, softer skills, keeping that conversation going and show for them? How this is going to benefit them as well? Then you You find yourself in the position where you're you're rolling out the RPA. And you're making your employees a lot, a lot happier, a lot more engaged with the work they're doing. They're seeing the opportunity and the growth associated with that.
When it comes to that rollout that you talked about, where so many projects tend to fail, what are some of the specific challenges that that companies hit there, I'm guessing that there's some technical challenges. And then there's probably some challenges within the processes themselves, maybe kind of recognizing that they're not quite as perfectly repeatable as somebody thought they were, or that there are some corner cases that are really difficult to put into code or whatever it might be. So what are some of those specific things that cause companies to stumble a little bit when they actually get around to trying to implement automated automation? Yeah, you know, I put those problems into sort of three categories. The first one kind of being the functional and the change management aspect, one, the second one being sort of the technical and the process problems. And then the third one being how unintended business model changes are coming in. So with that first part, like any technology projects, you have to do your due diligence with the change management. And as you
see, it rolls, more and more specialty rolls are coming out in change management, to help with that delivery, because that is where projects fail. So you have to think through, okay, what is this changing my business process? What is this doing to the data itself? What is this doing to my staff, and then plan for all those activities and over communicate that rollout because if you try to roll out something in a in a big fatal swoop without beta testing it, or if you try to roll out something, and people wake up one day with their job changed, not knowing what's going on, it's just going to be very disruptive and changes always disruptive. So you want to you want to like give people that sort of heads up, tell them what's going to change, change it, tell them what changed afterwards and go through that whole bit. So that's the big
part on the change management side, on the technical side of things, you could have the standard problems of just poor delivery of it. And that just kind of is what it is. But I think the best phrase I heard around this was, if you have a bad process, and you automate it, then you've just accelerated the bad process activity, or if something doesn't work, and you're like, hey, let's make it more efficient at not working, then that's all you're doing when you automate a bad process. So you, you can improve a process as you're going through this effort. But you're just increasing the scope and the rest of the project, you're much better off having a process that you've gone through a million times with staff and saying, Yeah, this is the cleanest way to do it. All I need you to do from a developer's perspective, is get the computer get the bot to do it rather than rather than a person doing it. And then the
third category, this is interesting, this is kind of new, new popping up is a lot of these systems in the ecosystem are in a SAS environment, and you're paying by a per user license. And so, Caroline, you mentioned that the staff savings side of things, well, the SAS vendors are seeing a reduction in the licenses that they're selling for these activities. So the same amount of work is getting done. However, they're only selling one integration license, rather than, you know, 2550 staff licenses. So they're trying to figure out, okay,
well, how do we how do we compensate for that, because we still got to stay in business. And we're still doing all these things. And, and some of them have done things like increase the price of the integration license costs, which is fine. I mean, that's an easy thing to do, and, and accounts for the loss and user licenses. But some of them are starting to say Okay, forget the license bit, let's see how many transactions you do. So now, if you had 2050, people doing, you know, a
million transactions and their cost, while I'm just going to charge you for the million transactions, or you may find yourself paying more money for that activity, because you automated it, because you have this system doing it. So you have to be really close with your vendor and seeing kind of what changes that they're making to there. Otherwise, your total cost of ownership could increase.
Yeah, we see that a lot with all of the SAS vendors. And with MSPs. As you probably remember, it just had a price. And it changes all the time because the technology and automation and things like that change all the time. So if you priced per
device, for instance, in the MSP world, that may not be how you're going to make the most money today, it might be per user might be a combination of the two or in this case for you. When it comes to automation, you've got fewer people to be charging, so fewer licenses on individuals, but the transactions themselves can be hit up. So I think it's going to be one of those like Rubik's cubes that they're constantly trying to solve is how to how to make money off that. I think we had one other thing we wanted to talk about something correct me if I'm wrong, but that was beyond some of the the technical automation that we're talking about here. That is certainly
the domain of the IT department. It would be more about general workflow and how to automate that and I don't know if this is in your wheelhouse quarry or not, but as we acknowledge workers and just workers in general how we all work from getting you know, this piece of the task from point A to point B and what we Do and it isn't really an IT thing necessarily might be moving a piece of paper. I don't know what it is. But that general workflow, does that fall into the types of considerations you make when you're thinking about automation projects as a whole? Yeah, I mean, I think when you're, when you're trying to work through the project, there's a lot of different groups that you could have involved in people and all this.
And I think if you just go back to the very basics of software development lifecycle is that you've got three roles that you need to account for, you need the business process owner, so the just the business side of things, and somebody knows who how it really works, right? This me in this situation, you need the functional person who can be in there and help out with coordinating the activities. So they're kind of project manager there, their requirements gather, or they might do the business process mapping activity. And then you need the technical person who's the developer who's, who's actually going to build it out. So if you're, if you're automating a process, that's very simple, or you have an incredibly skilled developer, you know, maybe that functional role can be combined with the developer and you just have, you know, the business person, or if you have a business person who's also functional in nature as pm work, you know, maybe they can cover that aspect, aspect. But I think those those three components are what you have to consider for any process that you're automating. And then you also have to keep in mind, the bigger the process, the more systems that you touch, the more people that are involved. And the more changes that you make within the
process just increases the risk associated with the scope of the change that you're making. And so, you know, bigger projects require more planning, more effort, more testing, to make sure that they work. And so you want to keep that in mind as you're trying to decide what what processes to roll out. I mean, the one, the one tip I would give on that, and this is with with just over my experience with systems integration is that the smaller change that you can make at a time and incrementally move forward on that, the less disruption you're going to have. And with robotic process
automation, you're not, you're not doing a a transformation of your environment. So you don't need to have this big major rollout, where you're saying, we're no longer using the system and doing these things, we're going to totally do this, you're just trying to optimize the environment you have in place, like rpa, doesn't change any of the systems you have, and it doesn't even change the data, it just changes who's doing the work. So that makes it pretty easy. It makes it one of the best candidates for doing beta changes, small changes, rolling out a little thing at a time and moving that forward. And that'll help to with with your point earlier about the staff and change management aspect of it and making make sure people don't feel like they're losing their job, because this is this is being rolled out. Yeah, the general sense I'm getting as you've talked to all of these things is that automation, like so many other things, I think, tends to get viewed as this Kyril, like, you know, a company who's thinking, Okay, I'm going to automate, and then maybe I can reduce some staff, or maybe everything will be simpler. And I think everything that you've talked about, definitely makes it sound like you can reduce certain problems, you can, you know, take away some of that repetitive nature, you can reduce some errors that might come from, you know, human data input or something like that.
But you're introducing a lot of issues as well, whether that's the complexity of the system that you're building, or actually tying together the technology with business process, are moving into a cloud environment, and understanding the new cost models. They're like, everything's everything's changing, right. And it's not clear that the overall picture has become less complex of a problem to solve. You've just you've solved certain problems. And you've introduced, you know,
some new things that you have to think about. And I think that it just continues to drive home the point that we're going to need a lot of technical expertise, that technical expertise is going to need to be even more integrated with the business. And people aren't just going to keep saving money. You know, this isn't the old IP model where you can just keep driving costs down, like, you can definitely achieve great things. But there will have to be investment there. And you'll have to do the calculation of return on investment. So it's really powerful tool, but it
doesn't come for free. That's yeah, you know, that I'm getting so I kind of get the last word on all of this. Yeah, I would just add to that comment that, you know, if you automate a process, you can't change the process, or you have to change the automation, right. So you know, if you I mentioned
loan documents earlier, like if that process isn't changing very much, then great automated move on with life. But if you want to change things, like let's say you need to start adding a new field, something really basic, you've broken the process, right? Because that fields not included in there. So if you when you roll out these things, and you make these massive savings, and you have this big celebration party, just remember that if you change that anything in that environment, the data, the platform, the system, the location of the platform, if you're in the cloud, or how you know, however you're hitting The API, any that stuff changes that has to change the changes the process too. And so that's just just definitely something to
consider. So, you know, I think the final word I would say on it is, first of all, robotic process automation is a terrible name for it. So we need to figure out something better, like just robots. I mean, let's ruins your thinking about a little arm picking up a tire and putting it on the car. Like that doesn't work. But having said that, the value of RPA is definitely here to stay. And
people are figuring out all sorts of fancy new ways to plug it in. And the nice thing about it is that you don't have to have a master's degree in technology, you don't have to have this big background. You can look at the one pager on RPA to get the understanding of where the value is, and then figure out how to apply it to your business. If there are
areas that makes sense. I think that's a great stopping point for us. I want to thank you, Cory, for joining us today. It's been nice to catch up with you again, like I settled home day, your former formerly were with us. We're still here. Glad to see that. You've that you've flown flown high here. And that's great. Seth, any final
words? I don't think so. Yeah, I really enjoyed the conversation. I think this was insightful. I think this definitely builds on a lot of the things that we've been talking about with automation. So really appreciate you joining us and want to say thanks as always to our producer Andrew McMillan, and I'll see you next time on Boeing. Sounds good. Thanks.
2022-08-22 08:51
