On this episode of the podcast we speak with Stine Rasmussen, Senior Manager at BDO Denmark. Stine is a leader of IT and Digitization and is allergic to dumb work. She takes a refreshingly common sense approach to automation and RPA. Stine takes us through some strategies for bridging gaps to common organizational pitfalls that RPA-projects face as well as how Excel may be the right tool for the job after all.
Interview with Stine Høiberg Rasmussen - Senior Manager at BDO Danmark
Google Play / Apple Podcasts / Spotify
Interview with Stine Høiberg Rasumussen
SPEAKERS
Mark Percival, Brent Sanders, Stine Rasmussen
Brent Sanders 00:03
On this episode of the podcast, we speak with Stine Rasmussen, Senior Manager at BDO Danmark, seen as a leader of IT in digitization and is allergic to dumb work. She takes refreshingly common sense approach to automation and RPA. Stine takes us through some strategies for bridging gaps and common organizational pitfalls that RPA projects face, as well as how Excel might be the right tool for the job after all. Thanks for listening. Stine, thank you so much for joining us on the formulated automation podcast, wanted to start by getting some information or some background about yourself? Can you tell us, you know, how did you get into automation? And maybe you could tell us your history?
Stine Rasmussen 00:46
Yes, I will. So basically, I've been working in the financial services industry since I graduated from high school, even though I'm not that old, it is still 15 plus years ago, and I started working in real estate and I moved into insurance and stuff like that. And all of these industries are the industry in total is, is an industry where you have a lot of IT. And you've actually had IT for many, many years compared to other industries because they were kind of first movers with mainframe systems and, and all the sorts of that. So I I became very interested in IT. And I also became very interested in fixing bad IT because if you're working in the black box as a mainframe system with the F17 command lines that I as a young person born after the 80s, I had no idea where is F17 on a keyboard. And I became a kind of aware of how to automate all of this. And to make a long story short, I took a master in innovation and business development from Copenhagen Business School. And I became really interested in how someone like me a business person, I don't know how to write code. And I know a bit more about IT than I might like to, to give people the benefit of knowing, but I don't know how to write code. So how could I kind of automate the work of myself and my colleagues, so we need the need to use all the stupid time pressing F17, and remembering stupid command lines. So I'm kind of allergic to stupid things. That's my motto when I work. And that's why I love this automation space, then to be very concrete. I worked in an Accenture in Denmark. And I was working on a Greenfield, IT project where we were building a front end on top of a mainframe system. It was really revolutionary 10 years ago. And then I remember an American, actually, from Accenture, he came to work to the Danish office, and he showed us RPA for the very first time, and I think that was back in 2015. And it was blue prism, back then that was the big thing. There. And I was just, Oh, my God, this is amazing. I need to work with this. In Accenture in Denmark, we didn't really work with it that much at that time. So I actually decided to leave Accenture and go to the other side, so to speak and work for the industry and I changed to a Danish bank. And then I was really fortunate that someone was willing to give the RPA project back in 16. This must have been to someone like me, a young female, I didn't on paper have the right amount of staff on my shoulders, all the experience to take on this project, but no one in the IT department wanted it because it was the evil stepson, it wasn't really IT. It wasn't really business. So I was fortunate enough to get responsibility of doing it. Back then in 16. As you might know, there were not that many that had actually started doing RPA. So we call the top Denmark. I don't know if it's a Danish insurance company. They were some of the first movers in Denmark and also Copenhagen municipality. And I know you've already had a podcast with one of their guys. Yeah. And then we were informed about the various tools available. All the banks in Denmark, they were already doing it. And they all chose blue prism. So we kind of knew that blue prism was if you don't want to get fired tool to choose. But I didn't really like it to be honest, and none of my developers liked it. And it was really expensive. They were really annoying to where to negotiate with you had to buy, I think it was back then was 10 robots was the minimum purchase. And with some simple calculation, you know that it takes a few years to fully, fully use the 10 licenses. So for at least a year or two, I would have to pay for licenses that I would never use or was a bit annoying. And we ended up choosing UiPath as the I think, third, a big company in Denmark back then when they were sitting in Romania, and they didn't have a support system, and it was a very different, different time back then. And we were very happy within, then I've haven't done anything other than work without pay since then. And now I kind of move back to the other side again. And I work in video in Denmark, and in our advisory business, and advising our auditing customers on how to get started with RPA. So that's my story. And then as you know, I've come to know of your great podcast here. From my better half at home, that I have also, he actually in your podcast, he told you guys that he was one of his colleagues, a guide. And he also makes educations with that taught him about RPA. But it was actually me. I don't know. Yeah, he doesn't want to acknowledge that. Maybe he didn't think I would want that out. But it was me. I just knew that. With Alice's background from poker and, and his background from teaching as well, then he would be the perfect RPA developer, because he's good at developing. But he's also good at explaining stuff. So he's a good, good mixer. And for me as a business person, that's the perfect RPA developer.
Brent Sanders 06:30
Yeah.
Stine Rasmussen 06:31
So I have a more business background. And I think that that would be fun to talk about with you guys today.
Brent Sanders 06:38
Yeah, yeah. We'd love to hear more about I mean, when it comes to your current practice, it sounds like you are. Would you consider yourself a in a consulting position now? Is that how you would describe it?
Stine Rasmussen 06:51
Yeah, more or less. But the only thing is I, after I moved away from the bank, I actually did some freelance work. Because I didn't want to go back to normal consulting. And because I think, a lot of consultancies, when it comes to RPA, they just still either a packaged PLC or pilot project, or whatever they call it, it's usually six weeks long. And it's very expensive. And when you end up after the six weeks, you don't really have anything, right. And on the other hand, you can buy what I call expensive temps, where you just buy a resource from a consultancy firm, and they sit down, they produce stuff for you. And I'm not a big fan of that kind of consulting. So I actually went out and did it myself, and working for the Ministry of taxation and some housing companies here in Denmark. But then I was contacted by BDO, and they actually gave me permission to do consulting the way I like to do consulting and the way they do consulting, which is more like we teach companies how to do it themselves. So we don't do anything for them, we just teach them. So we do, what, in my opinion, when I was on the other side of buying consultants, what I wanted from consultants is know how and experience and, and teach me how to do it myself. So I don't have to pay your massive bill for a longer period than I have to. And so that's how we do it and different. So I would call myself more and advisor than a consultant.
Brent Sanders 08:24
I like that I like that a lot better than I heard a lot of, you know, everything you just said, has resonated in stories that I have heard from consultants. And yeah, one of the things that I found about this industry and you know, RPA, has been around for a long time. But when I say this industry, I say, you know, this 2015, 2016 to now period where it's very frothy and hot. And it's you're reading about in trade, you know, publications that are saying this is the great ROI, you know, savior of IT. And it always seems to be framed in the sense of well, you know, how much time is a person working on a given task, you know, what percentage of their time and what is their salary? Great, that should be our budget. So, you know, looking at, you start the conversation in a very sales oriented way, that's, well, they're gonna be saving us 150,000 for this project and 300,000 for that project, and well, I guess the license fees can be as expensive as they need is, you know, we don't really care what the license fees are, as long as we get that ROI. And on those PLC projects, it's yeah credibly difficult to see something you're not, you're not around to see the benefit of it, you're kind of given a toy. And you know, you're just not going to get that sort of production level COE or whatever, you know, you need to have in place in the long term.
Stine Rasmussen 09:49
Yeah, I very much agree. And I think sometimes it's very helpful when we have these discussions with management teams and the companies that we have these dialogues with, to just ask them to replace them. If they used UiPath, or power automate or whatever to use, just replace that tool and say Excel, because who in God's name would have these discussions about Excel? Yeah, yeah, it's, it's for me, it's the same thing. It's just a tool. Yeah. And also to that I heard you just set the Center of Excellence for RPA. I'm not necessarily against it. I'm not against anything. To be honest, I'm a fairly positive person. But I don't necessarily see the point of that after a very short period of time, because it's a tool. And you don't have a center of excellence for Excel, or PowerPoint. as a consultant, their PowerPoint is my go to tool as you might think, right. But yeah, so the center of excellence is I think it's more like super users. So you have a few users in your organization that are really good at it, and are the ones that teach other people in your organization. So it becomes like a living tool in your organization. And that's our or my approach, and also where I've seen them to be most successful.
Brent Sanders 11:07
It sounds very sensible, which is, I think, kind of absent. I mean, I, you know, Mark, and I both come from a, you know, basically software engineering background, right?
Stine Rasmussen 11:17
You guys are very technical.
Brent Sanders 11:19
Yeah, we're very technical, we'll, you know, we write code. And this concept of once, I've kind of gotten into the RPA, where this that term Center of Excellence, it is a weird thing. I was like, what it means different things, I guess, to some people, but largely, it's this idea that, you know, there's this board that what it seems to be concerned with is more, so how do we talk to one another? How do we talk to one another and work with one another around automation, because IT may have to manage it, and finance is using it, and HR has to deal with it. And you know, everyone kind of has a hand. And it's like, you know, our art where we typically play is not in the big enterprises where, you know, we have to wait three weeks for a meeting in order to get the decision made around each different thing. And I'm not saying that, oh, all enterprises are but I am saying is, it does seem like a word for how do you play together around automation? Which is, it's confusing, because I don't ensure there are, you know, models that have been fleshed out already, you know, because you have to explain something from the beginning to people and say, well, there's Yeah, models of CEOs. There's a federated and, you know, different approaches to it. But what are we really talking about here? We're talking about how do we play nice with one another?
Stine Rasmussen 12:38
Exactly. I think also, one thing that's kind of interesting in this discussion is to, to some extent, also all the people that you guys have on your podcast that are from industries, these guys more or less represent a large corporation. So like bigger, really big companies, in Denmark, at least 99% of all businesses, small and medium sized companies. So they probably don't even have an IT department, they and they will certainly not have a center of excellence for automation. And so it's also a little bit, it's very if you are a large bank, so we're at the bank nucleus that I worked for, we had a department where we did all the automation, we did Excel, automation, access, automation, Ai, chatbots, RPA, we ended up doing all these things after a few years. And it makes sense when you have three and a half thousand employees in Denmark. But they're not that many companies with three and a half thousand employees. Right. So the center of excellence model is also more appropriate for the larger companies. And sometimes in this discussion, I think we forget that majority of companies out there are not large corporations, they are medium sized companies with maybe 150 employees or so. And they can very much benefit from these tools as well.
Brent Sanders 14:00
Yeah, I mean, that's, that's the opportunity. And we we talked about this from time to time, I think there's a massive opportunity for and we're seeing players entering the space from the vendor side, they're building tools for that purpose of a week could technically we could get started, you know, $100 a month or whatever, in automate painful or as you put it, you know, stupid thing. Yeah. I mean, it's, which is a great way of putting it, it's and we talked about this theme a lot. But I agree. The real opportunity, and again, it may not be the opportunity to sell licenses per se, but it's the opportunity of I think, overall industry, and, you know, just humanity in a certain respect. I don't want to get to weigh out on that. But, you know, if we're spending less time on, you know, the stupid things and that same brain power can be used for good, hopefully.
Stine Rasmussen 14:54
Yeah, exactly. And also things sometimes what people forget when they try to put this tool and these various tools on Within the big box of automation into a return on investment PowerPoint template, is that these tools can actually help you in other ways than just reduce the number of people you need to have employed. You can help you get the product to the customer actually faster. So for example, I just as we talked about, I don't remember when it was before we started recording, but I'm on maternity leave right now. So just recently started a child savings account in my bank in Denmark. I requested this account, I think, eight days ago, and I still don't have it. And I'm more or less puzzled, because it's seriously, it's just an account, right? How, how difficult can it be? And if you had to create an automated flow for that, I could just have signed it electronically, and I would have it within a few minutes. And that would have made me happy, at least as a customer in my bank. And I don't understand why we don't focus more on that. Because customer retention is as in important return on investment as saving zero point 16 FTs.
Mark Percival 16:09
Yeah, I think I think large organizations I've been Brent and I are guilty of that we had a client recently that we focused on. Oh, this would be your return for it. And they said, Well, I actually just can't handle this, this much volume. It's not the return, it's actually just I can't do it.
Stine Rasmussen 16:23
Exactly. And also, sometimes when you talk to more it people about this, they say yeah, but I could just create some code and they could fix the problem. And, of course, all the flows that we do in automation world and RPA, or whatever to use, of course, you can write code to fix the problem. It's common sense. It's, it's it so you can fix it with it. But sometimes it is just too busy. And sometimes it forget that the people that are sitting there having a problem, if they don't fix their problem, they will have to work late nights and Saturdays and Sundays. And that's also a saving, you get that actually your employees, they don't have to work on Saturday and Sunday, and they probably will be more happy, probably be less sick, and they will probably not leave you if they are not happy. So there are a lot of other great opportunities in using these tools.
Mark Percival 17:16
When you see somebody that's a smaller company or medium sized, just Yeah. How do you How would you recommend that they get started in an RPA,
Stine Rasmussen 17:24
We usually start by telling them to choose a tool that fit their purpose. So we in BDO, Denmark, because of that, we actually haven't had any partnerships in formal writing with any of the vendors, we have various people that can work in various tools. But just before I left for maternity leave, we actually chose to, to go a little bit full on board with Microsoft, since we are working a lot with Microsoft already. And, and the problem so far for the smaller companies has actually been to find a tool that fit their purpose because of the license structure. And so say UiPath, for example. And before they had, is it called the light orchestrator, I think it's called right, it's a bit cheaper. But still, if you purchase the light orchestrator and the back office, robot license and the studio license, I think it's about a quarter of a million danish kroner a year in licenses, or something like that. It's and what's that in dollars. I don't even know the dollar exchange rate, but at least we can all agree it's expensive. And the same problem, if you look at roofers and but we don't usually look at that, because it's too expensive for smaller companies, then you all of a sudden you get someone like softer motive. They were very aggressive in the Danish market, before the Microsoft acquisition. And, and they actually had a price model where smaller companies could actually get in on it. And that was kind of interesting for us. And then Microsoft bought it and it became even more interesting. But it's a matter of helping people figure out what tool is right for them and not just getting a PA, because I can tell you one thing. Usually when people come to me, I would say 50% of the cases where a client comes to me with a problem, we can fix it without an RPA tool, we can just tell their people how to use Excel in the right way. For example, Excel is a powerful tool, we can all agree that and a lot of functionality is already built in Excel. So why create a robot for something that you can fix in a tool you already have, then it doesn't really make sense. So that's usually how we talk to people. It's just what is your actual problem? Instead of looking at how can you get up here? It's not a goal itself. And that for me, it makes sense this way of looking at it because I come from a business background. So I'm not very interested in what tool can fix the problem. I'm interested in fixing the problem.
Brent Sanders 19:58
I'm curious because we do get some inbound from the podcasts of people reaching out saying, Hey, you know, we'd love to try RPA, can we talk about this? And you're already, at least for us, we're already stepping the conversation off around the solution. And it's Yeah, you have to kind of unravel that, sometimes. And there are a lot more conversations that we have that are not a fit than our, and people are obviously more excited about robots and Excel, they're more excited about, you know, this idea that the works being done for them, then, you know, learning how to use something, that it's just, you know, what is it when you're a hammer, everything is a nail? right?
Stine Rasmussen 20:34
Exactly, exactly.
Brent Sanders 20:36
Look at. It's a really, I love that insight that, obviously, you know, it's not the universal tool, it's not going to fix everything. And in fact, the thing that concerns me more from our technical backgrounds is every single line of code you write, I look at it, it's a liability, you who's going to keep that working? Who's going to keep that from, you know, who's going to understand what that means three years from now.
Stine Rasmussen 20:59
Exactly, exactly. I completely agree. And, and the thing, sometimes the problem is also that people are, I think there's a very famous anthropologist that has a theory, that's called a theory of complexity. And his example is that if you want to, he studied a group of people that had to, to build a nuclear power plant. And it was very interesting for him that all the difficult decisions they had to make, they ended up postponing. And then they started to discuss what color the chairs in the cafeteria should be for the employees and, and, and how to build the bicycle shed for the people. So bicycles when they came to work, because it's easier decisions, then how to actually build a nuclear power plant. And I think sometimes it's the same with our PA, that it's been a kind of a horse, trying to find the English word for it. But it's been taken hostage to fix problems, because it's really easy to purchase an RPA tool and then give it to a group of people and then say fix our problems. But the problems have been there for probably 510 years because your processes are really poor. So it's sometimes a little bit easy to just assume that you can fix poor processes by purchasing an RPA tool, sometimes you can just fix the process without a tool, and it's a little bit cheaper, I can tell you that. And so from a business point of view, I really love RPA. And I think most organizations can use it for something that makes sense, but they shouldn't use it for all their problems.
Mark Percival 22:38
Yeah, that makes sense. And, and looking at it from that standpoint. Um, you know, how often do you run into it where it's both right, it's it's changed the process, the process is broken, but also there's a RPA component after you change the process.
Stine Rasmussen 22:52
Most times, I would say, and usually that makes sense, I was trained from an old school lean background, that was the big thing when I graduated from schools school 10 years ago, before RPA, then we should do end to end process optimization, and Kaizen and all those things, and value stream analysis and sort of things like that. And if you kind of take that perspective, and your merchant with APA, it really becomes powerful. And that's kind of every note that I love to play in. If we look at the process together, we usually also find out that if we have a process for the cost from a customer point of view, it's always how I look at the process as it moves from the customers. They call it let's say a salesperson, they purchase a product, the product has to be produced somehow and whatever it is, and it also has to be sent a bill for the customer in our finance department. If you put these three people in a room together, you will realize that most of the problems with the process lies in the fact that they have no idea what each other is actually doing. So when you just put them in a room together, the very old lean picture is that it is all of a sudden they realize that it's an elephant that they're looking at, it's not a whatever something they find out that it's one elephant that they all have to tackle together. And then of course some of the problems can be fixed with RPA. But most of the problems are usually fixed by these three people actually talking together and figuring out okay, when I sell the product, if I just put the name of the customer or the customer number before I send it off to production, it will make my colleagues work 80% more productive. And again, if when I asked finance to send a bill, if I let them know some sort of details and the number of customers or something it will make it a lot easier for them. And, and then of usually where we see the largest potential for RPA is in the finance function and Yeah, especially in the finance function, I would say, also payroll is crazy. But we don't need to talk about examples of RPA. All your other guests have already made some great there. I agree with them. But payroll is one of the things before just before I left for bi for maternity leave, we've been doing a lot of payroll cases.
Mark Percival 25:20
But as this also, I mean, this kind of goes back to your point about IT, right, which is IT fixes their own problems a lot of times, I mean, I think this is why you see so much development in the DevOps world. But and then RPA kind of now is just taking off, but there's that it doesn't really talk to finance or doesn't really deal with roles much.
Stine Rasmussen 25:40
No, I'm usually I'm the biggest pain in the ass for an IT person. Because I don't really accept no, and I don't accept if I ask someone to fix a problem, because an employee has to work Saturdays and Sundays for the next six months to get the number of cases down to an acceptable level in terms of our SLA s. And then if it say, yeah, we can prioritize it in our agile set up in a year and a half. I don't really think that's very agile, to be honest, agile is being a little bit overused in IT world, I love agile, I think their methodology is great. But if you take a year and a half to fix a problem, it's not agile, in my humble opinion. And so that's where RPA is really powerful when you actually put it out in your organization and let it live as a tool instead of something a few people in it are allowed to use as a tool. And then of course, we can talk about all about the risks, about security, breaches, and all those things. I read now I work in an auditing company, that they are fairly interested in making sure we don't create operational risks and manage security breaches. So that's also a big part, we shouldn't allow people to think that RPA is just easy peasy.
Mark Percival 27:07
I mean, that's a big piece that we are pushed back, especially from it, right, which is, and a lot of times it does start, as you pointed out, it's the team that's dealing with the most pain. So let's say it's finance, they solve their own problem by downloading, let's say, you know, a free edition of UiPath. And then it's kind of secondary, that it kind of gets alerted to this. And then they have to deal with, you know, getting this thing into production, where you kind of see those pain points. And because that is a big issue, right security?
Stine Rasmussen 27:32
But if you do it the way you just kind of pointed out, I would say then you're doing too fair, yeah. And we'll just be silly, even in a medium sized company. Because we live in a world where cyber security and general compliance and stuff like that is really important. And it's like hacking people has been a, it was something we talked about for fun. A few years back, right. But now it's probably the biggest threat to your risks in most companies today. So it's not something you should take lightly. And so in my opinion, if you do it the way you described, you are asking to fail. Yeah, so if you don't want to involve your IT department, if you are large enough company to have an IT department, then it's completely silly. But I also think it's silly to only have it in your IT department because they don't really know your processes to, to an extent that they are able to, to create a robot, they can probably help if you have a I don't use I don't use the term citizen developer. I know everyone uses it, it's not something wrong with it. It's just very fancy PowerPoint term. And it's just an employee that has an A tool. In my opinion, I'm very good, common sense person. And if you teach someone probably it's been a someone that's really good at Excel, we see a lot of controllers and finance departments that have built over time very, very elaborate tools in Excel. It's very impressive what they've been building. But they've come to a point where they're unable to automate more with simple VBA. So macros and Excel, just because Excel has its limitations. And when we teach them how to do RPA in whatever tool we find appropriate for them. Then we have a developer that teaches them how to, to kind of review it and also how to have their IT department held review it. And so that's how we usually have if IT involves medium sized companies, reviewers.
Mark Percival 29:40
Yeah, and how do you engage the because I think one of the big issues we see with it is it becomes kind of the Department of no. So you know, they're very averse to everything. And so then obviously, that's a larger dysfunction of the company typically, but that's kind of the pushback or why people typically avoid talking to IT for as long as possible and then springing on him at the last minute.
Stine Rasmussen 29:59
You guys could make an entire podcast for 10 years going forward talking about that the fight between business and it. So I agree that's not something solely to do with RPA. That's a general problem in the world right now in corporates. But I think how to involve it. To be honest. It's very simple. Go talk to them, they are normal people don't go behind their backs. Just go talk to them. Ask them, how would you like me to do this? When we kind of implemented RPA in this very large bank in Denmark, actually one of the largest five banks in Denmark, you don't know what is very Danish or the banks. And then like, we don't have any international links. And we even went to internal audit before we went live and ask them, would you please come and audit us before we go live? Because we would like you to tell us if we are doing something we're not allowed to do before we do it. And then they were like, no one has ever asked us to do that before. And then we were like, but that's silly. Why wouldn't we ask you to come help us before we do? whatever we're not allowed to. So in general, just assuming that people are nice people, and they want to collaborate and they want to fix problems, you kind of get good further, in my opinion. I would just saying again, go talk to them, involve them. And when we have these vendor selections, we usually have the call team or whatever we could call it the people that are actually going to use the to the tool, they are sitting around the tip the desk and looking at the product demos, if I'm a vendor, and they probably also get to have a demo on their own computer, they can try to play with a bit. And then we want whoever wants to go to come into the room and sit in the back on chairs are more than happy to be allowed to be there. And usually we see someone from IT security, someone from internal audit, and someone from from it and the business just sitting there and educating themselves. And when they see these tools working on the screen, they're like, ah, is it just that is when you hear about a robot. It sounds like sci fi and it sounds like something very, very dangerous. But when you see it on the screen, you see that it's not really rocket science. It's just an IT solution, that someone was really clever in naming RPA robotic process automation. It sounds really cool, right? It sounds like something you want to have.
Mark Percival 31:18
Well, the next question would be then if with it, and with audit, how do you kind of educate them around this? Because a lot of times, they're coming at this from just very from zero, right? It's like, Whoa, wow, how does this even work, I need to learn about this. Yeah, me. That's why Brent and I got involved in this. They weren't, they weren't actually robots. And we were really disappointed. But we stuck with it.
Stine Rasmussen 32:47
Yeah, exactly. Exactly. I'm completely the same. It's like my brother who works with robots in manufacturing in biotech. And he's like, you don't make robots. But then I again, I have to come back at him until him then how does the robot arm in your physical robot work? Its software. So yeah, boom, yeah, you can't really do anything without software. Right. So. But I agree. Sometimes I think it would be really interesting to figure out who actually named RPA who was the genius?
Brent Sanders 33:23
Yeah, I would love.
Stine Rasmussen 33:25
Genius tool. I try to figure it out. But I can't figure it out.
Brent Sanders 33:28
We should have them on the podcast and talk about that. Because, you know, marketing genius, of course.
Stine Rasmussen 33:34
Exactly. It must be some consultant. That's nice to be a consultant.
Brent Sanders 33:39
Can you talk to us shifting gears slightly? Can you talk to us about, you know, your experience around managing support in RPA? Like, what are things that our listeners might be able to take away? And, you know, obviously, there's this world of IT and SLA's? And, you know, there's a whole world that's built towards ticketing and all this other stuff. But are there any? I mean, some of the tips that you've provided around you're getting a program live are already really valuable. I'm curious, how do you think about support?
Stine Rasmussen 34:13
I think that's the biggest pain point of RPA. Because RPA the more solutions you have, the more you need to use resources on actually maintaining the solutions because the world changes around you and RPAs. It's not real IT in the way and it person recorded and of course it requires maintenance. That's where my old school IT background from Accenture comes in. And that I tried to actually have people think about how to maintain this when they go live before they go live. So have we actually documented what we have been doing in a necessary kind of way. So not creating 50 pages long documentation, but in our code, for example, have we commented what is this function Doing so that someone else and yourself can actually maintain your solution. And also have we did it in a reusable way. So we don't have to build, click a Chrome, open Chrome, open Excel what every single time. So if we have to update that component, we only have to update it one time. And very annoying, old school IT practices like that. So actually just being coherent to the normal it best practice world is what kind of what gets you in a way where you can reduce your support and maintenance in a, in a way, and it's really boring. And it's very difficult to teach business people this, in my opinion, where it becomes difficult to have developers that are former business people or not IT people, they don't know it best practice, they don't know how to go to production, they don't know what testing is. They don't know what hyper carries all these are very common words in IT world is completely new for business people. So I think educating a business about what IT does best. And in my opinion, that's some of the things that they make sure if they put something in production, it doesn't break production. And so so that's that's the way that this is actually where I think agile methodology is is good for RPA is that the people that are doing development of new RPA solutions, or whatever chatbot solutions, also the people maintaining the solutions, then kind of gives you an incentive to create nice cove, a when you don't have to hand it over to someone else. And then it's their problem. And then they then you kind of take ownership of writing some proper code or configurating. A nice robot. That's my opinion, that that's how you do it. And then of course, it also becomes a question about is this actually something that's special for RPA? Isn't this a problem with all code? And that if you don't do it the right way, the first time, then it becomes more expensive in the end? Because you have to redo it all the time? And is it actually something that's special for RPA? I'm not necessarily 100%? Sure.
Brent Sanders 37:13
Oh, definitely.
Stine Rasmussen 37:15
Yeah, it's just very time consuming with RPA. Because you very fast see the benefits of your RPA solution. So if it breaks, you also very fast realize that now you actually need your robot to be fixed. Yeah, yeah. So that's sometimes the problem, you can become too dependent on your robots. And the biggest problem, in my opinion is that if you fire the people that used or put them somewhere else, or they resign, resign, if people have used to do the process manually, all of a sudden, you have a robot doing something, no one actually knows what the robot is doing. And I am very fortunate to be invited to a lot of interesting conferences around the world before Corona or COVID, or whatever you call it now. Now there's not that many, of course. And I met this guy in the UK, I think, and we were talking about the same thing that you guys asked me, he actually tried to find him on LinkedIn, because I think you guys should have a chat with him. He's really interesting. And he told me, I couldn't find him, but I will find him on something to you.
Brent Sanders 38:23
Great.
Stine Rasmussen 38:23
And they told me that they were so afraid that people would end up not knowing what they used to do and what the robots were doing. So if the robots were down, or whatever happened, and the business would not know how to where to actually get the products out of the door, so they did fire drill.
Brent Sanders 38:45
Right? So it's a great way of doing
Stine Rasmussen 38:47
I think it was incredibly it's so simple. And it's so powerful to sometimes without notice, he just shut off a robot. And then the business would call him and say, it doesn't work. And he said, Yeah, but then you just have to do your normal work, you know, what the robot is doing? You have to do it and we will fix it as fast as possible. And they would know how to do it. So he did fire drill is what he called it, I think it was a genius, simple, simple way of doing it, making sure that the business still actually know what the robot is doing.
Brent Sanders 39:18
That's brilliant. Yeah, I mean, that's a very that sounds like a healthy organization. It also sounds like potentially a great way to ensure job security. Right. It's like, yeah, you know, we're gonna shut this thing off every now and then let you know, you know, we're still there. But it's, it's a weird world. And I think that's, it's unique to its Sorry, I should rephrase. These problems aren't unique to RPA. They're unique in the sense that they're, you know, they're automation, they're taking over certain roles. And you know, that, that idea that three years go by before the bot breaks, is, I think what interested myself the most in this world of like, in the long term, there's Gonna be a difference between I use the term engineering culture a lot the difference between an engineering culture and just throwing thoughts together to patch problems. Yeah. So I see this the site, this world where three years from now, that initiative that you started in 2017, or something that, you know, you're going to replace the AP bots, or your accounts payable bots are now in place now. So they stopped working, now everybody's forgotten. And they go back to their business continuity plan, and they don't know what it means. And they're confused. And it's just that that sort of scenario, in my mind said, Oh, this is an interesting place to work, because this is where technology kind of has played normally.
Mark Percival 40:42
And as developers, it's definitely the, you know, as a developer, you want to build something that you think to yourself, I want to build something that I never have to touch again. But in reality, the most frightening thing is the three years later having to go back into code that you wrote, you haven't touched. Yeah, exactly. Like who wrote this.
Stine Rasmussen 41:01
But I completely agree. But again, it's not unique for RPA. A lot of the RPA solutions that I've been working on is kind of solutions where you take a lot of old Excel solutions that are running, automating flows in, let's say, some sort of a browser solution is generally what they are usually good at. And then you actually have to sit there with a very, very long, very not engineering culture written, set up codes and Excel, and break it down to figure out what this macro is actually doing. And we've seen examples where we do a lot of it audits for our customers. So we also audit RPA solutions, that's a very interesting arena, actually, because now people have so many solutions that we need to audit them as well. And what we actually see is that if you just want to one create a robot that replaces the Excel macro, you usually end up with a robot that creates mistakes, because usually someone has by accident or issue was not harmful. When they did it, they've have coded a value or something. So for example, we had a finance flow, which had to find the values of the exchange rate, sorry, have some sort of currency, I don't remember to watch the Danish Kroner. And it we found out that for 10 years, it was hard coded to just choose the same value. And I can tell you that there was an exchange rate that wasn't the same for 10 years. So for 10 years, the accounting in that company had been wrong, because the macro was wrong. So it's the same thing. I don't see that it's very different for RPA. It's the operational risk of that it's people creating these flows is just as big with RPA, as it is with Excel, or whatever tool.
Brent Sanders 43:00
Yeah, one thing that I do feel like is unique. And I'm really curious to get your thoughts on how you mitigate some of the risks associated with you know, this hypercare period, you're going live and there is there tends to be in generic it, you tend to have tears, right you have parody, we have a staging environment, development, environment, production environment, they're mostly the same. But in RPA, it's very specific to the industry, that there's just, it's, it tends to be impossible to create that parody, therefore creating this very bumpy release, which, you know, you can communicate and say, Hey, we expect this to go through a hypercare period, we're going to stay on hand, we're, we're going to expect it to be sort of a trial by fire, so to speak. And yeah, I'm curious.
Stine Rasmussen 43:48
I completely agree. And when you work in larger organizations, you just have to play the Emperor's New Clothes, where we all know that we are naked, but no one is, is daring enough to tell management that we're naked, that we actually tell them? Yes, we tested this completely in Dev, then we went to test, then we went to pre production and then we went to production. But the actual scenario is that we test it in production, because I have never, in my 10 years in it, seen a company that has a one to one, or at least legacy companies. And usually it's companies with legacy systems that use RPA have a one to one test environments where they have complete connection between all the tools that they have in production. So of course you can try to test it in the various environments, but when you go to production, I've never tried not to have to change it. So I usually try to ask for permission to just do hypercare or like a controlled production setting where we just run one case okay did that didn't Overall, then we do two, and then we do three, instead of using a lot of resources, testing it in all these various environments, which are kind of like a show test, because the environments are going to change every time anyway. So I completely agree. And I think that's where probably I don't have much experience with DevOps. But I think that's one of the things that they would like to automate as well right in the DevOps methodology, that the testing and from environment to environment, and it requires a different test environment setup than what I'm used to, from, from old old companies now using DevOps. So that would be really interesting to see the changes over time.
Brent Sanders 45:43
That seems like one of the big problems in the space that no one, I haven't seen any solutions, I've seen a lot of problems and a lot of maybe I wouldn't call them half measures, but their attempts at solving a problem, they may not be perfect, but that's one thing. I don't know that it's just so complex and unique if you can't really productize it, because it's unique to everyone's specific system and processes. And it does seem like you think that one of the big players is after that. But without owning everything without owning all the systems and all know the process. I just don't know what you would do?
Stine Rasmussen 46:16
No, it's the same thing. When we started doing this, I remember when we back in 16, we were sitting there and meeting with all sorts of consultants to figure out what RPA tool to choose. They were all telling us this is so easy to, it's so easy to make a robot, it's like drawing a diagram in Visio. And I was like, Okay, I'm pretty good at Visio. And then I saw how to use UiPath. Let's just use that as an example. And to be honest, I tried at home here, now I have a very skilled husband and UiPath. And I can create a very, very simple flow. If I used to record a function. When we get through to variables, and I don't even remember all the crazy things I have to set a completely give up. So it's, this is not something that anyone can just sit, I forgot your question. I'm sorry. It must be the maternity break. You don't even have to cut it out. It just shows that I'm human.
Brent Sanders 47:13
Well, I was just, it really wasn't asking question I was kind of making. It's just a statement around there. Nobody really knows how to solve this problem. It's just so unique.
Stine Rasmussen 47:22
Yeah, and I think the problem is that no one can really solve it, and think the people that are trying to solve it, and telling you that they can solve it. I don't believe them. Because it's such a big problem. As long as we have these fragmented IT worlds and IT systems where we build on top and on top and on top on top. You will never prioritize to create a perfect one to one it test environment and pre-production environment. If you are sitting on you're kind of like in from a business point of view, it just doesn't make sense to spend that much money on creating this production a cut off. And if you don't see that many problems. Yeah. So it's, I remember one time, I had a big go live when I was in Accenture. And we were celebrating the day of go live, we were celebrating because when the day was over, it was in a bank. We had no reports of default defects or anything not working. And then I remember the partner on that assignment. He came into us. And he looked at us and he said, Well, guys, you shouldn't be celebrating. And we were like, We were a lot of young people on that project. And we didn't really understand what he was saying. And then he said, but if you shouldn't be celebrating victory, because this means you spent too much time testing, he could have delivered, you could have delivered something to the to the users probably months before, and then it would have been 95% done right, then you would have found the defects and you would have fixed them in a lot faster than you have been testing. So he was like you shouldn't be celebrating, you should be knocking your head in the wall and saying, should we use too much time on testing?
Brent Sanders 49:05
Yeah, yeah, that's a very much much more like the startup mindset. It's like.
Stine Rasmussen 49:10
Exactly and if you want to be agile, this is also the way you should look at it. Agile is just getting software out there working right. And if you go live with a big robot, and you don't have any mistakes in the first day, I would say you've spent too much time testing it.
Brent Sanders 49:26
Sure. Yeah, you know, Mark, you've, you've said this to me a long time ago, you're like, you know, it resonated in a different term of like talking about technical debt, like some for some projects, some technical debt is actually healthy, just as if certain businesses you do want you don't want to have no debt on your books.
Stine Rasmussen 49:47
And also, can you actually imagine going, can you imagine a company that don't have any debt? Like how would it actually be possible, right? Always be in, always be ahead of your own decisions. You would be like it would be, it's kind of like assuming that you are as clever as God. Right? That you know what you will need tomorrow, yesterday. Yeah, exactly. So it's Yeah. So sometimes I just think we also, we all looking for that unicorn solution. And the idea of a unicorn solution is really tempting. But sometimes we just need to remember that we are all human beings. So there will be some sort of debt. And there will be some decision we made in the past that in the future, we will like to have not made that decision. And then we will have to redo it.
Brent Sanders 50:38
Fair enough. Yeah.
Stine Rasmussen 50:39
That's my point of view, at least. But I know it's something that I have very interesting discussions with senior managers, in different companies. Usually, when I say senior, I refer to age here. A cultural change, I think, within the engineering and business, kind of those two cultures, they are, they have in the past, they have been two cultures that had to work together. But now when you work with someone from a younger generation, I personally for example, I don't see the necessary evil of having an IT department and a business department. Because what business is not it? So I don't see why you have an IT department? Why don't you just have someone that are in charge of the tools in the different business areas? And then it becomes a matter of how but how do we organize this in organizational chart need to have that in PowerPoint. But again, if you work agile, it doesn't really matter where you are employed, you just have to fix the problem in the area, did you know something about right? And so you can have various different hiring managers, and you can work together in a team across departments or whatever it has to be called in your PowerPoint job. And if you really want to be agile, and I think that's where we see some of the really benefits of RPA, when it's it's actually giving the RPA team or automation team or new tech team or whatever they're called actual agile, kind of like ways of working, where they are allowed to to prioritize themselves and put in production in a very frequent manner.
Brent Sanders 52:33
Yeah, yeah, that's a good way of putting it. Mark, any other thoughts? Any questions?
Mark Percival 52:39
No, I think this is a this is this has been super informative. I mean, I think this is, this is the kind of conversation we love to get into, which is just not the not the rosy picture of like, RPA solves everything, but the realistic picture of theirs. And also the other side of it, which is you brought up a lot, which is the organizational challenges. And the way to think about things. And I think, you know, talking to IT is one that obviously is a big one that maybe people are afraid to do. But I think it's important that everybody is talking about this. Yeah. And on the same thing,
Stine Rasmussen 53:07
And we all I guess, are employed in a company with the same kind of overall goal, and that is to maximize the benefit of whoever owns the company. If it's, if it's a privately owned company, it's to shareholders or if it's in the public sector, like a lot of the RPA cases are, it's the people of the community that are paying taxes. So I assume we're all there for the same purpose, right. And that sometimes gets a little bit forgotten when you discuss it against business. And let's just figure out how to fix the problems together. And it's usually more fun to go to work like that as well. Yeah. So I have one question for you guys. I have been listening to all your podcasts, walking around the forests here and where we live in Denmark, with our little, little boy in the stroller. How come you have so many podcasts with people from Denmark? Is it your experience? Is there a reason? Are we were or I would just say, are we ahead? Okay. Yeah. Yeah,
Brent Sanders 54:18
We were just talking about this. You are ahead. No, no, it's literally a matter that it by far it has been, you know, the experts are, you know, by far it's just how the numbers have gotten. We reach out to a wide variety of people. We don't look for certain names, or you know, I actually had no idea that would be a correlation. That was not an intention, but it really does seem like you know, European, in general, European, Northern Northern European, specifically, Denmark, it seems to be the capital of RPA has really been embraced. I don't know if there's like a reason for that, you know, culturally or just, you know, technology that's been around recent survey but it's this weird thing where it's like, oh, okay, that's like, yeah, Denmark is like the is turning into the RPA capital. I mean, it is not, you know, a, you know, everybody, we've had people from all over the world, but really it has been just people, maybe people interested in talking to us, but more. So I think it's been people who actually have, the only thing that we like to see is people that actually have real world experience. So I think there are just, you know, a strong level implementation. And it's been a delightful thing I actually, you know, I not to say that I don't enjoy our US based guests, but there adds a little bit of charm that we're, you know, I'm sitting in, you know, Cleveland, Ohio, and marks in Atlanta. And it's just, it makes a little bit more fun knowing that we get to speak to people in other countries, and it makes it a little bit cooler. And like, yeah, this is what the internet's all about. We're supposed to be sharing ideas all over the world. And so,
Mark Percival 55:57
Well, it's also nice, because we both worked in, you know, and venture and that's a very Bay Area focus. And the nice part of RPA is it really is everywhere.
Stine Rasmussen 56:05
And also, I think one really nice thing about RPA is it's something that is more operational than its strategical. And so you often see that it's younger people with less stress on their shoulders that have been given a really large responsibility in an organization. And then it also becomes more operational, because that's what we know, right when we are at that stage in our career. So I completely agree. And I also think the reason why people have been so willing to share within the RPA space, which you are not used to seeing within it implementation is that the younger people working with this or not the younger people, but more digital, Native people, or whatever, we should call this, this, this, this area of people wanting to share experiences. So I agree, but I think it's really funny that you say the thing about Denmark, I didn't know that.
Brent Sanders 56:59
It's, it's hilarious. I find it to be like a fun little coincidence, but it would be fun to dive into the origin of that. Yeah, I think we will have to learn more. I mean, we'll I was saying to Mark earlier, we should probably have a Danish version of the podcast, but we probably wouldn't be on it.
Stine Rasmussen 57:19
I guess it would require you guys to learn how to pronounce my middle name. You can start with that.
Brent Sanders 57:25
Yeah, I gotta say I love languages. I've, you know, had zero experience. But I'd say over the next couple episodes will at least work on our greetings and yeah, pronunciation. Yeah, names is
Stine Rasmussen 57:38
Perfect. Yeah, but I completely agree. We actually decided to, to name our son something other than Steena. And I'm not because it's very difficult to pronounce our names. So we had to have a name that was super knowledgeable in English.
Brent Sanders 57:54
Did you go with Mark?
Stine Rasmussen 57:55
No, when we actually went with so very American. Yeah, yeah, American celebrity Danish.
Brent Sanders 58:05
Stine, thank you so much for being on the podcast has been a wonderful conversation. I think our listeners are gonna get a lot of value out of it.
Stine Rasmussen 58:12
Perfect. Thank you. And thank you for a nice podcast and look forward to to keep on listening to your guests.
Brent Sanders 58:19
Excellent. Thanks so much.
