This week we talk with Lasse Rindom about how he manages RPA in a large organization.
Lasse Rindom is a Technology Manager, Automation Europe for ISS, one of the world’s leading facility services companies. Lasse has cross-country responsibility for automation for the Europe region in ISS and global responsibility for RPA platform and RPA framework.
Google Play / Apple Podcasts / Spotify
Interview with Lasse Rindom
SPEAKERS
Lasse Rindom, Mark Percival, Brent Sanders
Mark Percival 00:10
Hi, welcome to another It's automic podcast, we're joined by Lasse Rindom, along with myself, Mark Percival and Brent Sanders. He's a manager at ISS specializing in automation. And absolutely let him give a bit more background because he's obviously more versed in it.
Lasse Rindom 00:26
Sure, I'd be happy to. And thank you for the opportunity mark to join in on this podcast, I am Lasse Rindom. I am the technology manager for automation at ISS worldwide. So I have the global product ownership of the RPA tool, as well as for the framework and the contract with our vendor DXC technologies. My background is that I am actually a master in history. So I have a slightly different way into this space than most others. But besides that, I do think that I got into the space of RPA, in a very common way, I started having a lot of manual work that I hated doing. Basically, I think that laziness is very good if you're also able to understand IT. So I taught myself a lot of VBA, and a lot of Excel and then some SQL. And then RPA sort of just opened up when we got a little bit harder. So I moved into that space as soon as possible. And the rest is sort of history. That way around.
Mark Percival 01:26
Basically a start of every software developer is laziness.
Lasse Rindom 01:28
Yes. Up into you, I said that I'm Lazy at the job interview, and I got the job.Because you know, that's the way it is, if you're, if you're lazy, you're good at math, right? Because you find the easiest way to the goal. PA and what RPA should do on should not do and I I'd like to say that I've come over the mount stupid, and I'm moving up up the slope of enlightenment on on where to apply and how to apply RPA. And I like to just share some of that with you.
Mark Percival 02:05
Yeah, They'd be great, I think I think what we're looking for is obviously that that experience of actually putting RPA into place is very valuable, because I think there is a lot of hype around RPA. Right now, there's a lot of a lot of BS around the, you know, from the consultants and from people kind of selling a product. But ultimately, when you start putting it into practice that things quickly change. And I think it becomes, you know, like in any kind of software, its scalability is a real issue. And when you start putting it into a large organization, at least from my experience, and on the software side, it really changes the way you have to develop.
Lasse Rindom 02:36
Yeah, it's a funny thing, right to the as I said that also, when we had the little chalk talk just before the podcast, the funny thing is that there's a very little historical view of what RPA actually is. Right. And, and, and the consultancy business tend to have a while, you know, also consultants are also always ready to just jump on what's new immediately, even though they might not even know what it's all about that there is a tendency in the market for that as well. Right. And, and and the problem is with RPA, that then the the, the impression became that, that RPA was given to Moses on Mount Sinai, right? And that's not really the case is it rather that say that this RPA is sort of like an integrated platform for a lot of the old dirty code that you used to apply to processes before like, like, you do PowerShell commands, you do VBA, you do all these things in the RPA tool, it actually has a lot of old technologies in it. The key point, though, was and that's what actually made blue prism blue prism in the beginning and why they coined the term RPA was that they made this compliant and they made an audit trail functionality around it. Right. So and I think people tend to forget that. So when they implement RPA, you shouldn't really focus on the how easy it is. That's, that's a good side effect of it. But the real effect is that now you can do all of your dirty code in one platform, and you can do it compliant. Hey, that's something isn't it?
Brent Sanders 04:01
Yeah, no, that's a fantastic feature. And a great way of looking at is almost like it's okay. You know, we had an earlier conversation about messy or dirty solutions. And it's like, you know, if it gets the job done, and it lives on, it's hard to use that word isn't necessarily a bad thing, like, quick and dirty isn't always a bad thing. quick and dirty can be good. It's when it becomes something that you can't change or something that's brittle or something that you know, you can't pass on to the next person. Maybe that that's a bad connotation, but sometimes dirty within the right container or context can be a good thing.
Lasse Rindom 04:43
But that's exactly the point within the right context or container, but you need to have a it's not the right context and contain if you don't have the audit trail around it. So what if I don't know if my code is actually doing what I asked it to do? So five years on, my code is still running, but I have no way of controlling what it's doing because it didn't build in this kind of arbitrary functionality, just logging, and not analyzing the locks if it produces any logs. And that's where the RPA space actually opens up this opportunity to do this. And I think that's, that is, if you focus the RPA tool, only on usability and a nice looks and everything and you forget this aspect, you're actually undermining the reason it's called RPA, and then you just becoming some kind of some old test tool, you know, where it all grew from back in the 90s. You know, there's no news to automating that's always been with us, we've always been able to do it. Come on, guys. Okay, I'm just going to say this. Who ever thinks it's magic that you can automate IT with? IT? doesn't understand IT? Random story, right? Really? That's the core of it, it's programmed, right? Of course, you can program into it. Right? It's, it should be fairly simple. I'd say. So. So when I'm saying that I'm also giving, I'm also saying that the problem is that most of these consultancies that come out, are emphasizing how easy it is to get going, let's just get started. Let's do a PLC. Now let's really, let's implement this the right way, let's make sure we do the right controls on what we're doing. Because that's, that's, that's what's good about RPA. Right. And at the same time, also saying that, and this is a shout out to both automation anywhere that we're using, but also to UiPath. Not that much to blueprints, but to those two tools, who have the most marketing powers at the moment in the market, saying that they shouldn't really be focusing that much on, everyone should have a bot. I understand that's good for licensed sales, right. But really, if we wanted everyone to have a bot we just, we would have just made them super useless in our ERP system from the beginning, right? We really don't want them to mess around with that kind of speed in our ERP or our core operation system, because that's why we gave them limited roles. Right? Come on.
Mark Percival 06:52
Yeah, I think that's Yeah, I, we see that a lot, especially when you start hearing about the marketing terms, like low code platform, or no code platform. And that really is driven by the idea that everybody is going to be building a bot. But I think the difficulty is, when you're working with these processes, I'd love to get your opinion on this. The hard part is really, it's it's how do you build those in a way that is sustainable and auditable? And a lot of times that doesn't come? And I think the average user doesn't have that mindset going into it. So if you take an average user has Excel, for example, and they automate something, they're not looking forward and saying, you know, how, what's this gonna look like? When it's running at the organization level? What's it gonna look like? How do I audit it? They're looking at it, like, how do I solve this problem immediately for me now.
Lasse Rindom 07:34
But that's also because of the terminology. Right? We call it a robot, right? So it's a robot and people think robot. Okay, that's like, that's like almost Whitesnake, we can just tell him what to do. And he'll do it right. But it's not a robot. It's a code, right? So yes, that actually, they are giving the power to the people giving it in the hands of the people, because they think it's kind of like AI, right? And then you have all these other things on LinkedIn, I'm always very offended by it almost, that when people say AI has become cheap, what do you mean AIs become cheap? So I can just go down to, you know, my nearest electronics store and find singularities next to hi fi and stereos? No, that's not going to happen. It's not there, you know, we won't experience when AI happens, because it will just do everything. Just on the topic of AI, Do people really think that there will be a development of your normal earpiece systems and other systems going on? And then besides that, in a secret room, someone is developing the singularity, and then all of a sudden, it comes out and there it is, you know, you get my point? There I think a lot Oh, SAP didn't see that. NAD didn't see that. Oh, no, where that gets the singularity? No, they're gonna grow into these two systems. Okay, so we don't see it just like with Google Maps, right? It's telling you where to go. And you don't really realize if it has, if it if it's if it's assisting you or it's become the agent, right? You don't really know. Because it's just growing on you. And that's the beauty of AI, you will know that it hit you until it's just there. And you won't even be able to differentiate between yesterday and today. Right? Yeah, But people tend to think that RPA is this because it's called a robot but it's not it's not something you can tell what to do. It's not even case specific, like the AI we will probably see you know, your peace systems and in Google Maps and everywhere have their case specific, that's why they work. RPA is something that can actually destroy a lot of things to do a lot of crazy stuff. But it's also something that's very difficult to code. They're very difficult to make Exception Handling on. It's a program as work right. So saying robot means everyone gets it everyone here is a robot for you. But really they don't get it they don't understand it. But so there is this kind of marketing mismatch between what is the tool, what is what good can it do and what isn't it but what's it been sold as you know, the marketing saying. This can learn from you it learns what you're doing and then it just replicates it. I've never seen an RPA will do that ever.
Brent Sanders 09:59
Right? and you're talking about in the cases of like process mining software, and putting up my .... but some way of recording some repeatable process and immediately being able to write a script to replace that.
Lasse Rindom 10:11
That I have. I know that a lot of tools on that I haven't actually been able, they've coming out with that in the last couple of months, I haven't been, I haven't had the time to assess those tools yet. I'm sorry about that I should have. But I have a tendency to be very skeptical, very skeptical. Because you know, you know, recorders. I've tried the macro recorder, you probably have to it mix. It's just basically producing crappy code that you need to debug. And I've heard that from everyone, except, of course, from the software vendors that their recorders is just crappy code, you have to debug afterwards anyway. And sometimes it's much easier to build it step by step. It's linear coding, by the way, RPA tools linear, very linear with a loop in the middle, right? It's much easier to build a step by step and record it all, and then find out Oh, where's the buck? What's wrong? What's going on? Where is it? Oh, it keeps failing? I don't know what, you know. I've never used a recorder and I hate recorders.
Brent Sanders 11:08
I'm curious on that subject. or near that subject? I'm curious, have you? Have you seen just taking existing process? I guess to rephrase another way, it seems like when you're getting to the point where you're creating a solution, right, you're putting an automation in place, whether it's using RPA or otherwise, it seems like a great, great opportunity to rethink the process and reevaluate, okay, we've been doing this for x amount of years. Could we do it this way? Could we do it that way? And then let's implement it versus as you mentioned, just recording What's going on? It's probably not an optimal solution. I'm curious if you've seen that to be true, or what your experience has been around improving process, right before implementing a RPA solution or automation solution.
Lasse Rindom 11:55
Well, taken to the x, right, you you never automate a process as is, you always redesign it, because you need to make a trigger for the robot and the human is a trigger that's, you know, I take a cup of coffee, then I go open the program, then I say hello to Lucy over there and then start working, the robot wouldn't do that you need a trigger for the robot, right? You're right. And the trigger in itself is redesigned, even if it's just a small redesign, also the output, you know, so but you got this, you got this static input output thing, but you have to decide how you get to those two points. And what do you do afterwards, you know, so the redesign is always there. And I always do redesign every process, just a little bit of redesign, at least, we always take a, you always take it in, in you know, on box, or you say, Okay, we have these 10 cases of documents that need to be produced. Okay, but let's start with the one type that we have the most of right, and then moving on to the next ones afterwards. So that's also that's not a redesign, but that's just biding it up because that's what the robot needs. So the redesign is always there, because you're translating everything into linear code. So is that I think that answers it a little bit. Yeah. I also think that there is a too heavy emphasize from the consultants assisting companies on the process redesign thing that they think this is going to be really big, they have to look end to end on everything. And I see that, of course, that's a great opportunity to get some kind of like activity for your process analysis. Right. But I think that's also overdoing it. Right? And what we're basically doing most of the time is it's a simple integration using RPA. Right and that's also why one of my and I like to get back to that because now I've just been criticizing the market I've been criticizing the software I've been criticizing RPA basically. And I'd like to redeem myself Yeah, I'd like to to get back to why announcing, And Moses would probably also have some RPA with you I don't think you were Anyway, I'm not gonna I'm not gonna talk about Moses. Sorry about that. And should I just get to that point?
Brent Sanders 14:02
Yeah, you can feel free to extrapolate as much as you want. I mean, we can edit things back.
Lasse Rindom 14:07
Okay, good. I like to speak a lot.
Brent Sanders 14:12
I'd rather you speak more than less
Lasse Rindom 14:15
Yeah I get that I would say some introvert you know, sitting I'm happy with the corona just sitting at home you know, that's no but where I see the point for RPA is that you have to not necessarily link it to your to your line or your six six. Matt, I heard you talk about that in the earlier podcast. That's what people usually do. They say oh, we have to link it to the process analysis. Yeah, no, no, but that's because people are thinking this is not IT and I have no clue who told them that. I really still wondering whoever told people that this is not IT. This is IT. This is very, very much IT. So what do you need to do to make real Surefire cases that will always work for you? Is and that will not be a bad RPA either and that your IT department will love you for, is to look at the enterprise architectural landscape and lot of people don't know about this but you have to have a list of the applications you're working with. Basically just looking at the applications you have in your company. The applications you have to work in in the different departments then you can distinguish, okay, which of these are old, which of these are a core new, you know the RPS systems, which of these are actually external systems, and then you can decide where to put your RPA where show you basically hunt the system first, and then you hunt the process behind the system. Because every system that's legacy will have will have RPA processes attached to it possible RPA processes attached to it. And this is my favorite one, actually, every system, that's what I call an external or an alien system, or we could also call it the cross company architecture systems, right? Those who are governmental systems, you have to integrate with for salary be run. So for audit, stuff, whatever, right? or customer systems you have to work in, we have a lot of those vices like you have no clue. So maybe those systems, they are ripe for automation, they are just waiting for RPA. And if you do that you do it right. From the beginning, that also means that RPA is not going to have a big impact on companies like Spotify. I don't know if Spotify is doing RPA by the way. But you know, they're born digital, they're still very digital to the core. I don't think that they will, they will need we also have some a company in Denmark called NAMELY, that springing out groceries, they were also born on the web, you know, upon digital, and and they will probably not need that much RPA either, except maybe for something they have to put some compliance processes up against government systems. But do you understand what I'm getting at here?
Brent Sanders 16:49
Yeah, I mean, the first, you know, first time that that RPA becomes useful for those companies is when they start to make acquisitions, right, they start to pick up, you know, some of these legacy, pen and paper putting on my Quote scan, but, you know, older legacy companies. But it does make sense. I'm curious, you know, it sounds like, you know, we look at RPA running in two ways, sort of a federated model. And a centralized model, it sounds like your experiences is centralized in the sense that there's an RPA practice that you're a part of, and it's kind of built into IT. I'm curious, as I have always been, is that right? What's the evolution of that and within just your experience.
Lasse Rindom 17:36
Well, at ISS, we started off with, there was a lot of different initiatives going around the world. And then we sort of set up this for a centralized perspective, because we could benefit from both the contractual having one big vendor with the right setup, and having one strong tool. So we could also share some of the ideas between us, right, and ISIS. So there was some benefits to that. And that's why we set up the central solution. First of all, first off, it was just for Northern Europe, but then no one really wants to be left outside. So it sort of grew to everyone, and it's an offer for everyone in ISS to use the tool today. And the setup that we set up how we did it, though, is that ISS is a fetter is a federated that the way that we have a lot of all the different countries actually, more or less owned on their own, they have, they have the right to choose for themselves, to some extent, to some extent, right. So we had to make a good selling point as well. So I actually have a very hybrid model on this is not centralized COE, I'm in the COE, meaning that I own the contract, I own the tool, I call them those things. But I'm not, I'm not saying no to that process or that process, but I'm giving guidelines to it. And I'm, I'm giving we made a together with the year we made a feasibility assessment tool, basically, where you sort of put in some, some characteristics from your process, then you get a guesstimation, as we call it on the fee. And then you get an opex capex calculation, then the end and the business case calculation. This is all four sheets, currently in an Excel workbook. But it gives you an end to end perspective from the business side of getting an idea. And then you can basically write your business case, get it approved, and then DXC will start developing it. So it's very flexible. We have security built around it. So we have the questions for security. And then we put all the complexity on the vendor and on me. So we take that they make the operations handbooks and the PDDs SDDs. They make all those documents that we need to document the process, and also for them to operate it. And this is, and this is where I think we actually hit the nail on this is that everyone is able to do it in the way they want. They weren't able to do the RPA projects, they want, they able to, to attack it from so many different angles, put it in IT, put it in business, whatever they want to do with different countries, but they to use my setup, our setup, they have to put the processes into what I call runtime management with DXC afterwards. So my contract with them is based on operations. I think I'm not sure about this. But I have this feeling when I talk in the market listen to Danish market that we're one of the first companies to actually make a contract that is purely on primarily Paramount, primarily focused on runtime management or RPA operation. And only secondarily focused on development. Because basically, we have in the contract that ever we could, we could hire Deloitte, or wherever we wanted to do our development, just as long as the process ends up in runtime management and operation with the axiom, we fill out the documentation for the process.
Brent Sanders 20:34
That's, that's fantastic. That's really I'm curious to know.
Lasse Rindom 20:38
The evolution is super scalable, we're looking at 100 processes in a year.
Brent Sanders 20:43
That's excellent. I'm curious to know how that, you know, how that evolved was that I mean, it couldn't have been overnight. Evolution. I mean, most organizations that we see, it's like, starts with somebody in accounting or finance, they take a stab at a bot, they run a pilot, they see some good things, and they start to workshop, they start to uncover, you know, these potentials for cost saving opportunities. And that's where things start to get a little foggy. And we see, you know, the IT department doesn't really know anything about it. But the CFO is saying, you know, the boss, the boss, or going live, and we need you to support them.
Lasse Rindom 21:19
It's always my mouth, at the CFO or the CFO area, usually very often born out of the CFO area. And I think also, that's, that's, I think, for different reasons that, that is that is the easy way easy places base to get into without pa to the CFO and the financial area. But it's usually the wrong area, actually, because they have any pieces. And that's a core system, often also an assistant, they invest heavily, and they really, you really don't want to put RPA on top of your core system that you want to keep up to date. So that's not legacy, and it's not external, it shouldn't be legacy you're up, then you need to think about what you're doing, because this is the heart of your business. But instead, let's get close to operations. That's where you have a lot of goal and a lot of stuff that actually matters and, and hurts, right. but I think what we did is there was a lot of this small, I sense its huge, right? I don't know if you know that much about us but we are 500,000 employees worldwide and quite huge. I mean that there was a lot of these cases of RPA around the world and some of them larger, some of them small and just ...... and I came from RPA consultancy before where I did some consultancy on a Foxtrot tool thats not very known tool but very usable tool, very I think it has actually still the nices interface of all the outage tools. So that's good, for it. it lacks a little bit of technology side but I came from that and I saw a bots breaking down and that's all that becoming a feature that kept on happening, you know that that became sort of led. That's just what happens RPA doesn't own the systems. It's built on top of systems. It's not part of it. It is not your NAV, it is on top of your NAV, so you actually have two piles of code that has to be updated every time, right? So when I came to ISS, I said, Okay, if we do this, and if I go to you and I join you, we have to focus on the runtime management, the operations, we have to get a partner where we get a flat fee per process. And then they fix all the things that happens to the process, almost everything that happens except if the input output changes, and the whole system is different, right? So basically saying that, let's make a documentation template and say if the documentation is still understandable, and you can still see what the process is supposed to do, fix it. And that's the contract resign. That's why we're able to now get something really huge and get it all stabilized and operationalized as well.
Brent Sanders 23:46
That's great. That's great. That's super helpful for us. I mean, this is exactly what we want to dive into is like how do you, you know, what's an ideal state in actual sort of case studies? And how do you get there, and I think a lot of people are striving to get where you currently are.
Lasse Rindom 24:04
Yeah, but we still we, we had, we're still striving to get, we need to get this running. We have a lot of processes lined up right now. And then we are going to explode on the development now. And it's going to work. We have that where I'm very, very confident on that. But the problem is that we took the time that no, the thing that we did is we took the time to make a framework for how we wanted to work with RPA that includes both a way of thinking of it, a way of working with it and a way of executing it. So we have all these really three layers in our framework. So people can understand the concept of RPA for us and also know what documentation they need to produce for this. So we took the time to think this through before we just said okay, now we have that in place. We also made some very slick tools the business case to where told you about before, meaning that we can actually scale this extremely quickly. But it took some time. And it also took some effort to do that. And I'd say that it's also based on the acknowledgement that I had that box break. Yes, basically saying that you have to get over the, the, the amount stupid, you know, where you're just talking about things you don't know anything about. And then also, and it was painful for me personally, to drag myself very quickly through the valley of despair was like, Okay, how do we do this? But I had to move very fast because we had to set this up and then into Okay, this is where it makes sense. And that's why I'm actually talking this, you know, the make it on alien systems, as I said, or, you know, cross company architecture making a legacy and and make it on episode one. I can't remember that. Right? I should. Yeah, there are three, I have written it in an article on LinkedIn. So but getting to that point. took a little bit of time, not that much. But it was based on having the experience and being willing to, to admit it as well. A lot of people are making careers and saying that everything's fine. Who wasn't talked to. I talked to someone who wants it? Yeah, I talked to someone in Europe, we have these organizations in Denmark, where we have that supports different parts of the industry. So sort of lobbying organizations, with a lot of partners, a lot of companies being what do you call it? member companies in this in these lobbying organizations? And I talked to someone from there about who was doing a thing about RPA for small SMBs. Right. And is that what we call it in English as well? As in? Yeah, small and medium sized? small and midsize business? Yeah. SMBs. Okay. We call this SMBs in Denmark, because b is businesses. Okay. Oh, that's sorry.
Brent Sanders 26:59
No worries.
Mark Percival 26:59
No worries.
Lasse Rindom 27:00
It's actually my, my kids phone just a moment, he's just gonna get his phone. So he said that he talked to so many different companies in this SMB market, who did RPA and also some larger companies done RPA, and not one of them had anything bad to say. So this is just you know, it's career making as well. Right? It's, it's like corporate bullshit. Bingo all around right consultants saying this is the best thing ever. And, and the people implementing companies say this is so great. I'm just living forever on the good business case they made once or twice, that's good. The one or two good business cases that you can live on that. And that's, that's justifiable as well. Right. But really, you've maybe you could have made tenfold that if you had a realistic approach to it, and had a conceptual understanding of how to implement this and took it out of IT in your enterprise architecture landscape, maybe you could just upscaled it like crazy with the right contract and the right setup, right. That's just what I'm saying it because there's so much for RPA here. That is, it's too easy to have five good business cases, you should have 100.
Brent Sanders 28:13
Yeah, interesting. I feel like Mark and I have spent a lot of time talking both, you know, on the podcast and offline. And I keep thinking we're just these crotchety old men or something. But it's, it's very much of like, Oh, my God, the way this is headed. It looks very rosy. Now, you know, where is RPA going to be in three to five years when, you know, as you said, we have an underlying belief that these bots are brittle. They don't own the system. So I'm curious, where do you see? What do you see the industry going in the next couple of years? I mean, with, it seems to me, bots run really well, the first year. And then the context is lost on a lot of implementations, because the work is automated away. And they really sort of memory of operations, a lot of the operations that are automated, live on and documents and that's it, and people start to lose that context. I'm curious what your thoughts are on the future.
Lasse Rindom 29:10
I think the RPA market will always have a space, I think that the intern perspective that people are trying to implement our RPA on right now will change and it's already changing. You see? Oh, you know, we're at the top of some kind of tech evolution here. But But in my LinkedIn feed, I'm always behind anyway, so whenever I talk to you know, normal people, they're like, Oh, your high tech stuff you're working with and I'm like, Yeah, but on LinkedIn, I'm like a dinosaur right? So it's because you have this echo chamber of people being like, Oh RPA so last year I need to do and then they moved around the letter so now it's Intelligent Automation said of artificial intelligence, right. So it's now as IA instead of AI I love that, that's brilliant, but well thought, right? So, no but I see, I actually agree with that. I think that what we're gonna see is more of these workflow tools instead, and more of these engine's can actually move things with real API's between systems, but you're still going to have those systems that you cannot do that with. So that's where the RPA becomes, you know, the extended arm, you know, like, don't go gadget RPA in the end of those workflow tools to reach the things that they cannot reach. And I think that's, that's a real space for RPA in the future. And that's also why you need to look at your enterprise architecture for finding the right cases for RPA. Because if you implement RPA, and something that's not supposed to be RPA, like on your ..., your knew your new NAV, and you put RPA on it, right, then you've done wrong, you just done you just messed up your up your NAV, and you've done bad as RPA and now you're going to defend your RPA against the better solution that will be to develop this in NAV right. And you don't want to defend your RPA that the RPA should defend itself. That's my point. And that's why you need to find the right cases for it. So if I build these, in the end, right, have a process and then I later on implement ServiceNow or whatever engine workful engine in the middle of this and it would still work in the same way because the RPA would just still be the extended armor of the work tool as to where before the extended armor of the human employee you know.
Brent Sanders 31:00
Great.
Lasse Rindom 31:14
And I think it's very interesting with the process mining tools. I really like those and I think also that's what we, in my team, is gonna focus on after RPA because it is really interesting to learn from data. I really like that. I am not a big fan of the concept of AI and machine learning like I said before. I don't think AI is getting cheaper, I don't think there is something you can call AI in the market. I think whatever people is calling AI is just some dirty python codes sending you a data to Google or Microsoft. And that's not what you really want, right? That's not, basically, as I've said before, the cool thing about RPA is that it has auditory, it has strict compliance well that Did that answer the question about worse? Yeah, it was great insight, great insight. And it's super helpful. One thing I'd be interested in go over, and you kind of talked about this earlier, but you know how this exists in the IT space. And I think, you know, we see a lot of it being kicked off by the CFO group or by an operations team. And that's why I think it kind of falls out of the IT bucket is it that's looked at as this other tool. But what we also see is that when IT gets pushed onto them, it's usually after the fact, maybe there's already been some movement in the RPA space. And now they're kind of being the voice that onto them. How do you kind of get that in your org? It sounds like you basically have said, we're not going to do the development, we're going to basically provide the contract. How do you kind of get buy in from those IT teams? Well, how do you start that process? We are at ISS, we're a facility management company. So first of all, we're not an IT company. That means we don't we don't have to hire developers. So that's the reason we did an outsourcing right instead found someone who's experts in this, who willing to take a risk. And you know, there's liabilities and contracts and stuff like that, and and say they could do this very good and very stable for us. And that's where we found the xe technologies also with some great recommendations. So that's why we went with them in general. That's why we're not hiring developers on our team. ISS doesn't need to have developers on the payroll. And then we need to Oh, yeah. Oh, and then you need to see RPA. And I think the reason as I said before, my background is from history. So I've been thinking a lot about that actually being someone who comes from a very different place. Actually. My master thesis was about what's about what's a comparison about the early modern French and Ottoman courts rights. It's quite a different thing. But I came into this and I sort of positioned myself as a bridge between business and IT, I understand IT, mainly because I also did a lot of LAN parties back in the day so I understand a little bit more about that. The best stuff I played my fair amount of Starcraft and, and I also understand the business side, because I want some of my first jobs were seen in payroll, which is very business and also a little bit conservative, it's a conservative department because they have these cycles, this monthly cycles, they just need to work, and they're very afraid. If you ruin something, then it will be really ruined. And they hate that they really, really, if anyone, if any department hates that, that's payroll. So I came from that and had to understand that to be able to help it and optimize it from the I was the process of processing improvement officer kind of thing at a bigger payroll outsourcing company. So I had to understand the payroll needs to be able to provide them with the right optimization tools, and then coming into IT and the other side where I'm sitting in IT today, actually out of IT. And then and then taking the other perspective saying, Okay, what is the requirement for my team to make this work. So this is a bridge RPA is a bridge to, I'll say, to the business, I'd say, you have to remember this is it and you have to consider operations and Lifecycle Management, I'm sorry, and you have to look at not necessarily your lien department as the first off, but look at your enterprise architect, for the best cases. First off, okay, I said that, but then to IT, I have to say as well, that you have to look at this as like development, this is like coding, I've, I've talked to people from the medical industry, and they they're being put under, you know, normal development test cycles. So just hear this out, okay, they do development of the RPA robot in a test environment, okay. And then they conduct I think, 1011 test cycles for that. So then they get that approved. And then they move it into a production environment. And then when they do that, they have to go through the 10 or 11, test cycles, again, in actually a test environment again, and it's not possible, they can't get into production, because the treated just like normal. IT development and in reality, a lot of the times for because when you move your RPA product, that's what I miss to say, when you move your RPA script into production, you often have to change it, it doesn't work, you know, test, test target applications are not the same from an RPA perspective, as production target applications, they're just not the same. Meaning that you have to redevelop, then retest, then redevelop, then retest that they keep on going like that, because they're, they're treated like every other normal SAP coding, right, or NAV coding, and it's not the same, do you have to look at this as light, light coding, right. And it's something that you say, okay, we agree to this, but we can also control it because we can run it in very limited test cases also in production. So my point is saying that IT you have to be a little bit more lenient on this and the business, you have to be a little bit more IT on this. And then they have to find each other on the bridge, you know, and give a big Hawk and everything's.
Brent Sanders 37:54
That's a really, that's a pretty large gap to cover, we're fine. I mean, we talk to, when I talk to people that have successful experiences, you know, shepherding RPA, into an organization, they say the secret is, if they're coming from outside of the IT organization, or the IT unit, it's find somebody in IT that you can have sort of a special bond with that can provision machines that can get you credentials, like getting compliant, right? That means that find the guy who can do things on compliant that just wants to be your friend, because you give him cokes in the canteen. Don't find that guy that's wrong. That's just just as I'm not, I'm not proposing that you do it under the table I proposed. What I'm hearing is having somebody that you can have a conversation with, and yeah, get them on board and really have them champion to champion it through IT. But you have to be willing to go head on with the challenges and accept what I'm saying and say, okay, head on, don't be afraid of it. There is a good reason for a RPA and you must trust that they can understand this.
Lasse Rindom 38:59
But I'm not saying this is this easy to bridge this. I think that in the IT market in general, right now, the people that can bridge it in business are the most sought after people right now. And they also have a very large strategic overview of a lot of things actually. So they're not cheap, and they're not easy to find. Whereas, you know, developers, you can find those outsourced wherever, right, and then the business analyst that you can also, you know, take a lean course, and you can do that. I'm not saying that. I said that. But I don't mean it that way. I don't mean it that way. I guess it is actually very difficult and different. But they're the people that understand both sides of this and can take the direct bridge, not just take one side communicated to another guy because everyone's saying at john, I want to do it. I want to agile, but everything always ends up waterfall, because you have the guy from business who doesn't understand IT, communicating to IT, IT takes it all looks at it, right? something completely wrong back because it didn't understand crap. He doesn't understand that crap and he goes back again. Then you have these blocks of waterfalls and you end up with a crappy product, right? I don't know if you have that experience.
Brent Sanders 40:00
Yes, yeah, of course, I mean, the other experience that I've heard tons and I don't know of a way to fix it other than what you were proposing, but, you know, having sort of this test development production parody of environments, you know, in a, in the context of RPA, I don't know, you know, of a good way to deal with it, other than setting expectations to IT, saying, Hey, we're gonna release, but this isn't a, we're just gonna push it over the cliff, it's, it's a cycle
Lasse Rindom 40:29
No but quite easy to do, right, because it's not a code in SAP, it's something that works on top of the interface. And you can put it to work slower, and you can make test cases, you can make different kinds of production test cases in production, you'll make some invoices that are not real, and then delete them again, it's actually possible to do this in a controlled way. And, and you just have to accept that it's difficult for IT to accept that. And, and thinking about it right now, just nine on top of my mind, I'd also say that yeah, it is difficult for IT is always most of the modern, strategic IT departments are trying to understand business needs, it's difficult when you're a specialist, because IT people have to be specialists, it's really difficult actually, to get out of that specialist, nerdy space and become business guy, all of a sudden, it's really difficult. But I'd say that if you have an Enterprise Architect at your company, then the lean guys are very capable of understanding his Enterprise Architecture landscape. So it's not that difficult to understand that way around. I'm just saying that then if you want to drive it out of the business side, which is sometimes a good thing, you should align yourself first of all, which Enterprise Architect not with just the IT supporter who wants to give you virtual machines, right?
Mark Percival 41:40
Yeah. That makes sense. Yeah.
Lasse Rindom 41:42
Yeah. Because you can understand that part of it. Because the enterprise architects are like the philosophers of IT, right? The weird guys in the tower, but they also talk in a language, the talking drawings and stuff that you can actually understand. You don't have to go to understand it necessarily. To go to them, they'll have their master traceability matrix and stuff like that, that you can, you can understand after a workshop with them, and they will give you tons of great opportunities for RPA.
Mark Percival 42:08
Want to talk about scale? Yeah, I think that would be useful. We can go into that. You know, I think you kind of touched on it with the small business? Well, I think in general, we see sort of the scalability of RPA becoming kind of an issue, as organizations grow into it from 1 to 100. Obviously, you mentioned you're going to large set of processes this year, how have you actually seen that, that transition take place and the difficulties there.
Lasse Rindom 42:41
I'll put that on my vendor. Meaning that they are responsible for running the robots, and they're also responsible for, they're allowed to optimize them to make them stable, so it's easier for them to run them, just as long as they follow the documentation. And that is where I have secured my scalability because that means that in automation anywhere language that they will be developing meta bots, for, for reusability and be improving them. So we get the scale, basically, because we have an operations team. So everyone can just go gung ho with RPA in ss, but if we have this with and they ever had the case where they were doing the same login sequence, over and over for it for a couple of different countries, and then I said, well, you're completely as per contract allowed to just put, make one better bot for that. And that is that is the core of scalability is that you don't redevelop over and over, but you have someone who's actually able to say, Oh, we can make this smarter now, because we already have a piece of it. So and that's where that's also the reason why we chose automation anywhere because this is actually this way of making reusability based on separating the object from the logic, it's actually the core of blue prism. And UiPath is very much more like the object and logic is one is, is in one step in the flow down the road, right? It's like, I call that more task focused, where I say, blue prism is very process focused and reusability focused, I tend to say that an automation anywhere gave you the option to do both. But it has both the possibility just to step by step by step where everything in it and then also make the separation of the object and the logic so that if the object changes, you can actually update that and Lucia logic in the same instance. Right. I think that's interesting.
Mark Percival 44:37
Yeah, absolutely. And I mean, I think it's a good point to point out, you know, this really is the role of the RPA developer and a lot of cases to kind of go in and understand these and I think that's, that's some of the critical pieces you see and a lot of failures in RPA land is just the the developers are actually not up to speed on how to do this correctly.
Lasse Rindom 44:56
And scalability is also about people do not want to hire their own guy sitting there maintaining the robots, right, and then you lose your scalability because those guys were supposed to hunt the opportunities. And now you're sitting there pressing play, and yeah, rewind. And they're not even developers, they're basically coming out of some kind of business space. And now they want to do RPA because it's cool. And they're just sitting there wasting their time. And we basically just put that out to them and say, Look, I say, we focus on ideas, we focus on getting the opportunities in place, and then you take care of developing and running it. And that's, that's the easiest way to do it.
Brent Sanders 45:47
Yeah, do you have any tips for our listeners on you know, once bots are in production, any tips on how to generate useful reports on, you know, how they're continuing to benefit the organization, if they're, you, it sounds like you have a great way of evaluating the prospects up front in a good structure in place to know that it's not going to kind of shift under your feet. But as the months and years go on, any tips on how to report back on how the bots are doing?
Lasse Rindom 46:18
Well, you always have the reporting from it that you get out of it from the tool itself. But basically, the business case is owned by those that come up with the idea. So I tend to just trust that they know that this is something they will keep on performing. I'm not. I'm not I'm not really questioning that I'm of course, I'm questioning asking them some, some qualitative questions. So to the business case, but I'm not Christian, if this is in the corfit a good idea to do better or smarter. What I usually say is that in the business case calculator that we developed in the framework, we it has a line that says when do you have your breakeven, so your fixed cost and your OPEX cost together? When will it break even for the first year, and I tend to say that we should get something that's below 12 months and below six months is even better. And a lot of the processes are, luckily, between zero and three months on breakeven. And then you have a good case no matter what. Yeah, yeah, that's super helpful. And it also includes, and people tend to forget that your own internal employees, they also cost money. So you have to put their time into the business case as well, that they probably you have an SME who will be spending 40 hours advising the RPA consultants on this. And then you have to price that into your capex as well, because it's a cost. And if you do that is if you do that. But if you do that, you can just go to the CFO and say, hey, look, I did this. Oh, did you? Did you factor this in this yesterday, it's all there. And it's actually very simple, super simple math. When put in some license cost, put in some third party license costs, you know, usap license also cost something, you office 365 license costs something for the Excel sheet, Excel as well, your virtual machine cost something, put those things into your business case, right. And then put the someone to operate the robot into it, as well as an external vendor, or the guy that you hired or the Student Help that you hired. And if you hire Student Help, but he's only there three days a week, then you have to tell business, Well, listen, if it breaks down, we can only fix it Monday, Wednesday, and Friday. Make sure to set the scene or sceneries around it right, you have to make the scenarios, then you'll be fine. But if you don't think about these things, they're just mentioned, right virtual machine, third party license cost, automation, automation lexicon and operation costs, then you will fail this, it's a simple capex OPEX calculation.
Mark Percival 48:37
Yeah, one of the thing we've heard though, is that, you know, this calculation and the beginning, you get a lot of easy wins. And then as you start doing more and more RPA, there's sort of a desire to continue to find more of these things to run through the RPA process, and you start to see less and less return, obviously, because you're no longer hitting the low hanging.
Lasse Rindom 48:57
I've seen the opposite Actually, I've seen the crappy processes and first a lot of places because people tend to be like, Oh, look, it's running something on the screen. It's automated IT you know, yeah. And that's where I get back to you know, of course you can automate IT with IT. First thing you have to tell people this is not magic, okay? This, this was I'm not gonna say the Moses thing again, but it didn't come on Mount Sinai is not developed there. You know, UiPath is from Romania. And ultimately dinnerware is from India. And then you have UK right, just not not a lot of, winner is also on the radar of every CEO and every CFO. So if they get our pa while we're doing away we doing automation, oh, then a success. And then they get to speak at different conferences, right? Everyone's going, everyone's like, is lowering the calf right? Oh, we're just having a feast, have a feast on this, right. And then you start at the same very, you know, skinny calf 13 times, and there's not a lot of meat back left on it, but no one really cares. And then they move on to something else. That's not what I want to do it for, I really don't want to do it. For that reason, I want to do this because it makes sense. I want to be enlightened. That's what I said, the slope of enlightenment, that's where I want to be. I don't want to be stupid, just bragging about something that didn't really make sense. But everyone's saying, and you will only hear that, that this is going great. You don't get anyone, or you get very few who's actually criticizing the RPA space. I see some people on LinkedIn doing that. But they're usually because they're from vendors who were trying to sell the alternative to RPA today. Right? So they have it done not that trustworthy either. Right? So find someone who actually says this is not the truth. But this is actually the opportunity we are looking at. I think it's difficult to find those people. And when you find them, you should hold on to them. At least follow them on LinkedIn. Right. But those good business case beginning they also based on doing something you're Core ERP, Are you just doing something they should have written differently? Baba Baba, all these questions, you know, no one's really been asking those until now. And I think it is, it is a moment of truth for RPA. Because you have this extremely high growth market. And you're still only seeing like 4% of companies getting to scale and getting some real benefits from this in the long run. Right. Getting more than just Have you seen Monty Python? Yeah, of course. Yeah. You seen the one in the hospital, right? Where they have the machine that goes beep custom 1 million quit, right? And it's just saying beep. Right. And I don't want RPA to be that. I always say that. I don't want it to be a machine that goes beep, I want it to be the machine that helps with the woman right giving labor? I that's the point. Yeah. So I tend to distrust what people say when they say the good stories about RPA. Not everyone, of course, but I have skepticism. Because we still need to see on the other side, we need to see in five years, is it still a good idea? Are you still working with RPA? in five years? Are you just working with an app? Because it's top of the top?
Brent Sanders 52:40
Right? Or because it's creating short term cost savings? Now? I think that open question is one thing that we're trying to work on, try to figure out. It makes sense.
Lasse Rindom 52:51
definitely a thing, that you'll have a lot of processes. But that's as I said, often because you build it on systems that you really didn't want to build a PA on top of. But you want to do it smarter than take that cost and build it smarter if you want. If you have a system, if you've invested half a billion Danish kroners in SAP, then don't put a bot on top of it. Okay, just just spent the next million on it as well. Right. That's just, that's my point here. And then again, look at the alien systems and the legacy systems specifically for your RPA processes.
Brent Sanders 53:27
It's great, great insight.
Lasse Rindom 53:29
It's when you have new applications, when you're getting new applications into your organization. If you're implementing a new way up system, for instance, then you would always always find some things that it doesn't do yet. Right. And that's where you can also apply RPA as sort of a band aid, but then it's abandoned short term band aid. But sometimes you also willing to take a bad business case on short term band aid, but people tend to not want to do a band aid because you know, you want tell the story about the great business case for RPA. But sometimes it's about the great use case. It's a bigger picture than RPA. That's a picture of, you know, its companies, its financial transactions. It's more than RPA. Right? And if you can become a good use case, actually doing something great when you're implementing and half a billion up system, then you've done well as well. I have one of my best cases. It's not a good business case. But it's risk avoidance because we're doing things smarter than we're doing it today. And just saying that it was some one of the best cases I think we have in ISS is the risk avoidance case. Not not the save money case.
Brent Sanders 54:35
Do you want to expand on that?
Lasse Rindom 54:36
Well, I can't talk too much about it. But it's basically about that we update some things in the system, so that we make sure it's done real time. Whereas before it was a human person updating it and that actually made us and gave us some problems. With some liabilities and some contracts, stuff like that, where when we do it with a robot, we we will make sure that it's always updated in the system, where I'm building an API to It so, so the robot is fixing a problem that's avoiding a lot of cost a lot of risk for us and a lot a lot of, you know, a negative, an angry client, you know, we don't want angry clients. So if we can fix that with a robot, that's a good robot, the robot is not generating revenue, it's not saving money, but it's giving us a happy customer. Right. And sometimes you're willing to pay for that. Well, those are Yeah, those are the interesting RPA cases where they're, they're a bit tougher to price though, right? Because you don't have you don't have the immediate that it's a little bit harder to price that return on investment that depends on how you approach it, right. So if you're in your business case, justification template, also put you have a business case template, we also put this is this about risk avoidance. Yes, it is. Okay, you know, every CFO CEO today will understand that, because, you know, that's. How do I say this? I talked earlier about the mega did the usability of RPA. But that IPA is actually born out of compliance. And I think that people tend to think that the mega trend in IT is that everyone becomes a citizen developer. I'm just gonna say, Not everyone's gonna become citizen developers. It's not gonna happen. I've taught RPA simple, the super simple tools, people still tend not to understand. Okay, just now said that as well. But what was I getting at? I was getting at that megatrend. And IT is more compliance, not less compliance. That means that actually making RPA that avoids risk is on the high end of the agenda for both CEOs and CFOs. Today, it's not something small, it's not something insignificant. It's not just all about cost saving and generating revenue. It's also about avoiding risk, because there's a lot of risk. There's just really a lot of risk out there. And it's about being compliant. You know, GDPR, and Europe it that's huge. Right. And, and you have so much ransomware stories going around everywhere today as well. You want to do things the right way. You want to do it the smart way?
Mark Percival 56:54
No, I think it's a good point. I think also going back to your point around compliance I do think you are seeing exactly that in the industry, which is more and more have heavily focus on is it auditable? Is it something I can, you know, I have a solid understanding of the process around the business continuity that didn't exist in IT, you know, what did exist, but it didn't exist and the large side of the market that you saw, that would have, especially in the small business space, to medium sized especially.
Lasse Rindom 57:20
Yeah, but the case about the risk of anxiety, the pitch that directly to to see if I was going to say and I assess and they were like it no one, no one was saying, Oh, well, we want to make money, we want to save money. It was like, yeah, this is a brilliant case, let's do that. Because that's maybe that's generating revenue in the long term, or avoiding cost in the long term, maybe, but it's important to do. So you know, it's those cases that you see as well. And you will find that you also find things and things where the RPA can control things that you cannot control in other ways. If you don't get a lot from a system there, RPA can just do the controlling for you, if you need controls on it, that could avoid risk as well. Right. I also did it, I did an RPA robot once for some auditors, where it took some numbers on the tax return forms and input into the other there are the system, this was normally done manually. So they took numbers, and then they just typed it in another system, it basically just move them. And what we found out during the test runs was that we were testing on last year's cases, right? And, and the robot made some typos, they thought until they found out that they had made the typos last year. And that's risk avoidance for an auditor you were really not happy to see that because they had to go back to the client and say, Oh, we made a typo in the, you know, the six digit year ago. Sorry about that you paid 100,000 too much in tax, we're just going to fix that. That's not a good story. Right?
Brent Sanders 58:45
No, that is just not what it's just not what people are good humans are not good at data entry. The robots are phenomenal at that, that type of thing. And there is just an error rate that we can expect even for the sharpest, most organized human, they're still human.
Lasse Rindom 59:03
And you know, what a robot also does it moves through the interface that's already very secure, probably because the patient juicer rights, right. And at the same time, you know, it doesn't click any stupid links, they get, right, there's no risk. There's no ransomware Yeah, and you know, what more when they get Corona, they're not sent home without a PC. So that's a good case right now, right? But just saying that there is a lot of security in the RPA, as well a lot of risk avoidance there. And of course, it is also IT and IT tends to break and if you have a major incident, you will also not have your RPA.
Mark Percival 59:39
I think it's a really good point when you've actually I think you hear a lot about security and sort of the issues with RPA. And people say oh, you know, there's there's all these things, we're breaking policy with IT around credentials, and how are we going to do this but there's the other side of this which is which is very much the side of there's more security here when you start layering on these automated processes, but cuz you don't have those other issues, you have, you know, less human mistakes, you have more a better ability to control what the agents gonna do. I mean, you have a bot that's gonna do exactly what you're telling. And so if you can overcome those initial IT hurdles around, you know, getting this built in a way to secure and as built properly, I think then you do you get a lot of extra security that I don't think people talk about that very much.
Lasse Rindom 59:40
But no one but it also depends on you know, how much decision making do you have in your process, right? Because if you have a lot of decision making, you have to, and if you have to have a personal skip skepticism, then a robot is maybe not the right thing to do, right? Yeah, for a lot of other cases, it has a higher level of security and reliance if it can do the job. And I think that's interesting as well for the RPA space, like you just said. So, I think that, as I said before, the mega trend is towards more security and more compliance, you need to think about how you can make your RPA project so that it complies and actually strengthens this agenda. Not so that it goes against it, if you may get rogue rogue RPA out of the business side where you don't have IT on board. That's a dead end. Just sorry to say this gonna die because people are investing tons of money in IT security, and they're not gonna let your RPA project ruined. So, so citizen developers, I don't believe in it. I just I just I don't see why we should give people that those kinds of tools.
Mark Percival 1:01:23
Unless you're rogue RPA process becomes a sentient singularity.
Lasse Rindom 1:01:29
Yeah, exactly. Unless we make RPA bots that are more use case specific, I saw you up as doing something like that, where they may actually a tool? Was it the studio x where it's very use case focused, actually. And I like that I like that idea. Getting closer to that actually taking, taking some of the customization of the power out of RPA and then giving them a not a light but you know, a super light, you know, a decaf light RPA tool, right, then that would work that you could give that to them, right?
Mark Percival 1:02:01
That falls more into like the old standard. I mean, that's it's like an easier version of like, other autohotkey all the old automation tools from Windows 5.
Brent Sanders 1:02:08
Oh yeah auto hotkeys and stuff. dangerous because there's click on the screen. You know, I did a lot of that once. It's like, Oh, this is crazy. Oh, that was on the wrong screen. This is clearly good. Right? I follow XKCD. Just so you know, I'm on it. I'm definitely on it. You know that one? The XKCD? One? Yeah. Have you seen you have obviously also seen the automation? One, he did write the XKCD automation, just Google and you'll find it you know that one, right? Where the theory and reality if you don't, if you don't if you haven't seen that comic before, you should definitely immediately Google XKCD automation. Okay. And then when you do that, then you can do it right now. Right? Oh, yes. Yes. Yes. This is basically the entire thesis of its atomic. Yeah, but we're not done yet. Because you're going to this comic, and then you hold your mouse over the comic. And I like to make this My, my, maybe my final statement today is that automation automating comes from the roots auto meaning self. And mating meaning screwing. This is so great. I love that I had no idea that I did not know. Yeah, I appreciate that, like dedication to accessibility. That's beautiful.
Lasse Rindom 1:03:16
It's on every one of his comics, but this is the most brilliant. I love it.
Brent Sanders 1:03:21
Let's say on that note, I think I think we should wrap it up. That is a great way to end.
Lasse Rindom 1:03:27
So don't don't don't automate yourself.
Mark Percival 1:03:36
This is great. Thanks. Thanks again for joining us.
Lasse Rindom 1:03:39
Yeah, thank you for having me. I was really pleasant talk and be nice to get to know you and know your podcast. Pretty happy with this and I think it's a great format that you're building here.
