Mikkel has an interesting background. He came from the world of hardware, working in physical robotics. It isn't a mystery that lessons in the physical space carried over to the software space.
We went into what RPA looks like in the public sector. What platform they selected and why and understood where RPA plays best. We also heard about a blossoming citizen-developer program. An interesting approach to a difficult space of non-technical user adoption.
Mikkel told us more about the robust environment surrounding over 40 bots across 9 VMs. The business units that leverage the bots ultimately control the bots but Mikkel and his team take great care to build and maintain a set of common libraries. This approach requires diligent effort is paying dividends to avoid downstream headaches and reduce bot breakage.
Google Play / Apple Podcasts / Spotify
Interview with Mikkel Rønde Jensen from the City of Copenhagen
SPEAKERS
Mark Percival, Mikkel Jensen, Brent Sanders
Brent Sanders 00:01
Today we have our special guest from Copenhagen, Mikkel Jensen, who is applying RPA in the public sector, Mikkel, would love to hear about your background and maybe can tell our audience, you know, where you're coming from and in how you're working with RPA.
Mikkel Jensen 00:20
Okay. My name is Mikkel, and I work in the municipality of Copenhagen, applying robotics to processes throughout the organization. My background is, I'm a robotics engineer, that what I do in Denmark, and after college, I was offered a job or university, I was offered a job working with software robots, and a company that already had established that in for 2014. So I started out tending to already running super successful software setup with robots, and did that for like, almost two years. And I switched to the municipality because they had, like, they have a lot of processes, and they have a lot of willpower behind it. So it was an easy step for me to learn how to progress the whole setup. And, and there, I've been for almost four years now. Making a lot of robots. That's kind of the background.
Brent Sanders 01:27
Okay. And I'm gonna just gonna mention, the potentially obvious question when you got out of university was your experience working with hardware robots are always software robot?
Mikkel Jensen 01:38
Oh, it was, like, two legs. Primarily, physical robots. In my bachelor party project was a robot arm grab stuff. And my master thesis was the regulation and fault detection in wind turbines. So it's like regulation and control and robotics, like physical robotics. So, but I think the basic principles can apply as well. The robustness translates great into both genres of physical and non physical robots.
Brent Sanders 02:19
Oh, that's fascinating. That's really fascinating. So realistically, you have like, largely electrical engineering background. Yeah. I mean, you. Yeah. Okay. So that's really wild. I'd love to dive into that. And what are the similarities? What are the dissimilarities? When you look at software versus hardware?
Mikkel Jensen 02:36
The programming language primarily because the environment the changing environment, of both. Both techniques are similar. But the languages are completely different. Most of hardware robots are the way I've been taught. It is low level programming. You code assembler code C, can its basic languages on microprocessors. And it takes a lot of hard work getting this hardware to work, enabling you to actually do what do you want to do with your roadmap. It's like if you have to program we use UiPath. In my workplace. It's like, if you had to code all the UiPath functions from scratch, so you have up brings a lot of
Mark Percival 03:28
And it only had 32K of memory.
Mikkel Jensen 03:30
Exactly. But, but it was, for me, during the first jump from hardware to software, it was in the already established scenario that at the company, they used ..., which is a SAP testing tool. And SAP testing tool could be was VB script based. So it was a super simple scripting language that I had to like, manufacture functions from scratch and up, which was what I was taught to do. So the jump was natural, but jumping into UiPath. That was like hitting warp speed. I'm not saying how about this perfect, but it's a great tool for simple automation.
Brent Sanders 04:21
That's great. That's really interesting. So jumping into UI pen, how did you make that selection? Were you part of selecting that software? Was that already kind of selected for you? How did it come down?
Mikkel Jensen 04:34
It was selected like they had they did a proof of concept in UiPath. And it came out all right. They did a preliminary like evaluation of tools at the time before I started and when I started they just made the choice of UiPath being the cheapest and best at the time. of choice, so to speak.
Brent Sanders 05:03
Yeah. And you sound like you're pretty happy with that situation, right? I mean, it sounds like they're the activities, and you're not having to write everything from scratch, and, you know, build your own drivers for everything. So it seems like you're able to start from a level of abstraction in which, you know, you're, you're effective, and you can kind of coordinate things. So I'm curious what, what types of what's the typical type of automation that you see, in the municipality or in the public sector.
Mikkel Jensen 05:31
We have a lot of legacy systems, a lot of like, I think we have more than 1400, separate IT systems running. So there's a lot of integration projects, where you just take data from one system and plug it into a new one. We have, of course, there's a lot of small ones that sparsely used, or used by few, but there's a lot, and there's a selected few, like, we have like eight or 10 main systems, that likes signals down on whatever part of the municipalities main call services. And, and those the interactions between these major systems and the small subsystems, is mainly where we do stuff because we have an integration platform that integrates around the big ones, mainly. And then the small ones, just, it's not a cost benefit worth doing. Like it's bad business case, making an integration hole into a system that 10 people use. So you use a robot to enter the system, retrieve the data, plug it into the big platform, and further on into the big systems. So we have this sewed SoTL integration with robots, that's our prime. And then we've had, like two more types. The second one is like, when we've designed applications deriving. We've designed applications that mainly just solve simple, simple tasks, or critical business tasks. And we use the robots around that system to make it work. So it's part of the entire design process process where we, we assist a team of mine develops the application, and we just like with the arms and the legs of everything that happens. So they can just make the rules and do it in an eye on a nice server in C sharp, and everything's just running smoothly. And we supply all the data from all the legacy systems. And the last type are kind of like using the phrase, citizen developer. The last type of robot is yes, it's basically citizen developers. Where we, they it's a front end robot, they, they operate themselves. And we just supply the infrastructure and the technical support of this, the DCOE. And they they operated whenever they want to, that's a big mismatch, because it's one of the critical issues is when do you execute your robot, if it's critical that it's right now you execute it, when you have the time and time slot and space, you should, you should activate it yourself, because we have like a major setup with 40 plus robots running and on nine virtual machines. So just punching a hole into the time schedule is kind of a tricky quest for us right now. So we've Yeah, like extended level capability for the business to like, run their own robots, at their own pace, so to speak. And there's like a sub level of that, that some processes are not standalone robotics, so you need to apply human help. So it's kind of like assisted automation. So they start a robot, the robot goes, I need this, I've seen I can get for the data points I need, you need to get this data point. And the user said the robot stop prompts the user, the user goes and gets the data peroxidative types it into the robot and then sends the robot along. And then the robot comes back 10 minutes later, say I've done this, you should do that. So we have like, like processes where the user is actively supplying data to the robot.
Brent Sanders 09:40
Sure, yeah. This is your I think you're the first individual not not the first you're the second individual we've talked to that. is seeing citizen developers actively work in their organization. And so I'd love to dive into this because you're quite the diamond in the rough of hearing about your program. So number one, how did you was the process in place before you started? Or is this something that started in your tenure? And if so, how did you train?
Mikkel Jensen 10:09
Well, you know, the journey for us, I've been on the RPA journey. And then as a penalty from the start almost, we started out with securing our center of excellence, and climbing, in climbing, what the blades are called the mountain of ignorance. So we, we, we spend a lot of resources and time making, like picking the really low fruit routes, but using a lot of time learning, and making code guidelines and developing the concept of how we should do robots. And then, and then we've like, with, because security was really tight about how we should do it. So we got a security clearance across the entire company, which is, we see it as a company. And, and then we kind of, like streamlined it. So we said, well, we have the say and how to make robots. So we're gonna make these guidelines for you. And we're gonna help you do it. But it should go through us because we know much more about robots than you do. So the citizen developers more became clients. But recently, we've been losing that we made some educational classes where people can just from all over the organization can sign up and say, I want to know more about robotics, and more about how to analyze them. But also we've made a developer course, it just got postponed because due to Corona but elsewhere, we will, educating people on a fairly simple level. Like we tell them to take UiPath Academy or similar courses. And then we pick up from that and do like a two day workshop with them. Talking about what's good, what's good robot, what's simple process, how to make this work. If there's a lot of when you do robotics, there's a lot of knowledge about not about what your process should do and how to automate it. But all of the small things surrounding it, how do you make it robust? How do you make fair fefe, error handling and stuff like that basic engineering or programming skills that's not accessible or common when talking to personnel across the organization? So.
Brent Sanders 12:36
right, we think of this as like we call it engineering culture, right is like how do you roll out in engineering culture in, you know, an accounting department or a finance department? It's not trivial. So it sounds like this is a massive undertaking to me. So I'm curious. How many, how many bots have been developed by citizen developers? And it sounds like they run in, largely attended fashion, right? So they kick them off from their machines?
Mikkel Jensen 13:02
Yeah, I'm currently I think we have five, but because everything just got bogged down in February. But, but like this, we've had 30 people sign up for the course of becoming a citizen developer in quotation marks. And so that's kind of like the basic level, I think we're gonna have a look into like 50 or 100 people who's in the organization who can make it a side note, we're 45,000 employees. So it's not like a huge part of the organization. But it's an, and it's quite a huge number compared to like, we like 10, eight developers in my department.
Brent Sanders 13:50
That's massive, I mean, in thinking about, you know, even five bucks, or just even having 40 people or 30 people or whatever number that's going to, it should be a force multiplier, right. So it's like they can do their job some multiple, faster and right. So I think that's really exciting to hear. To go back, though, you talked about an early part of rolling out this COE, was getting security clearance. And we don't need to get into details around the security. But I'm curious. How did that process go? What did you find successful there? Like, how did you get that push through? Because I think that's a big roadblock that a lot of organizations lead with. I'm curious.
Mikkel Jensen 14:30
I'm not sure I can answer that completely. Because I didn't work. I wasn't assigned to my current job. My job alone has been like a lead developer. So I've been as I've been assisting that process with making code guidelines and making General Security Settings around how do we how to the office straightaway, where it was placed, how to who has access to the robots Is this a security feature that we have that if you push it out to you uses, for instance, one of our is you can't just you need an orchestrator access. So we've supplied and our front end orchestrator that all of our citizen developers, like citizen developers, but just the robots, not in our RPA setup, but in a RDA setup, desktop, robots front end style, so that the front end people have a monitor environment for them to run in. So we get, we get to see the locks, we do code reviews. And we do like a peer system, that if I develop a robot, another guy has to look at it. So so we have this contingency of a minimum of a 4 eyes principle, during the development process, and and, and we like to, and the reason why we're pushing it towards people in other parts of the business is that we can push this principle with them, we can we educate them in how, on a fairly simple scale? How does these software engineering principles work? And when should you think of done, we will help you finish the software principles of proper robots?
Mark Percival 16:19
I would imagine for the citizen developers, this takes also the form of more like mentorship. Yeah, where you have the four eyes and you have the code reviews, but it's also there for them to kind of learn as well as to validate.
Mikkel Jensen 16:31
Yeah, we were setting up like, TA is teacher's assistant hours where we can, where were they just like, an hour week, they can just talk to us. We set aside one or two developers one hour week, it's the print is the principle of the concept. And they can just ask questions about anything they've got going in the robotics, so. So they get like a tutoring hand, so to speak.
Mark Percival 16:59
Yeah, that's interesting. I'd love to know, what's what is the one area you see developers or new developers to this kind of struggle with?
Mikkel Jensen 17:06
Hmm, Well, first off the results we've seen so far as people just mainly concentrating on doing the process, like making a sequence from top to bottom that does exactly what you want to. So they're not not looking into scalability, they're not used to looking into reusability, they're not looking into any form of error handling, or locking that that might help them later. So that's the baby steps we're at, we're at right now that we need, we need them to like, throw in some hours and become better at just making the process, doing the easy stuff of finding a selector, which is sometimes not easy. And, and doing like the simple flow, and then we will help them build like the entire software framework on top of that.
Mark Percival 17:58
That makes sense. And I'm sure that's also that must make it much easier for me your perspective of coming at it with this knowledge of seeing them build that process, though, kind of explains to you what they're trying to do. So you're coming in as a business expert, and then you're getting to come on board and say, Well, here's how you can make it better. But you also get to see how it's what they're looking to do.
Mikkel Jensen 18:14
Hmm, exactly. We've assigned a specific role and our team for that as well. We've like made an RDA architect, so he's like in charge of everything kind of process related on a robotic scale. If that makes sense. Yeah, that makes sense. He has the say and the knowledge about how to do proper robotics on a front end scale for instance. So we run these workshops internally and externally as well. So we are aligned when we have these questions for asking. From the
Brent Sanders 19:27
Exactly.
Mark Percival 19:40
You're based out of Chicago, you should let her know that.
Brent Sanders 19:51
Did you look at the government as a slow moving you know not I don't want to say blanket statement but at least in a lot of governance. If you see bureaucracy, you see slow moving, you see a lot of holding on to the past. And I'm curious, like, is this a trend in Europe that you're seeing? Or is this a trend in Copenhagen? Is this a trend in the country? What is enabling this? Because I'm really impressed.
Mikkel Jensen 20:16
I think it's a question about resources. Personally, I think that we've had, like major networks with other public sector companies and other municipalities. And it's a, at least in Denmark, it's a trend that there are resources for doing better public management, that it's a focus point that people should be getting better service. So we invest in technologies like robotics and NIC systems. Not being said, we don't do not have a lot of legacy systems, but we have, we keep up with time and our major development now major systems, so most of the systems, I look into SAP recently updated or, like newer systems, so so I'm not, yeah, it I think it is a different picture, at least where I'm looking at it.
Brent Sanders 21:13
Yeah, we had one of our initial conversations was at the start of the pandemic is, as you're looking at the news, with the state of New Jersey was struggling with, you know, finding cobalt developers, which, there's nothing wrong with that, right. cobalt works, it has its place, and its value in it, right. And it worked. So I'm not diminishing that either. But, you know, obviously, tech that has laid upon and laid upon it can only process so many records per hour per minute. And so looking back at, you know, you said 1400 different systems, you know, of the legacy pieces. The decision to use the bots, as I'm interpreting from what you're saying is, you know, does it make sense to not break open some system that really doesn't need to work, the possibility to build an API or some other closer integration is really a frightful undertaking? And so in looking at these legacy systems, how far how far back? do they go? How old are they? And do they? Do they still have ownership? Or is it just a matter of, you know, it would just be easier to deal with with a bot?
Mikkel Jensen 22:20
Well, the oldest system, I think I've seen, like one or two terminal systems, but they are like being out faced, and have been so for some time, most of the processes that we do from the old old systems. It's mainly like, we need this data out of the system. So we can, like move it into a new system, because we're, we're transitioning into proper software, so to speak. And so I haven't seen it that much.
Mark Percival 22:50
That's interesting. I was thinking about this as a question of, you know, migrate versus automate, without with legacy. But it sounds like you're actually part of the migration process.
Mikkel Jensen 23:02
Exactly. Yeah. We are. Well, one of our major projects lately was also we went from CRM, as case operating system to ServiceNow. In our, which is one of our main systems in like, the service part of the administration of the of the municipality, like, all the internal processes, hook, HR, salary, economics and stuff, they they change their major system, and we played into the entire, like, we had a lot of processes with these business areas, because we are located together and in the same like house, but also we we have a lot of work with them, because they they do great process work. So we ended up having a lot of things in common and did a lot robot. So when they like, they updated their system, we were thought into the process from the get go, we had a close connection to them. And we work together towards making like from day one we had we started making robots in the system. I know, it's not a good thing to say. But if you have a system that needs like, fairly different, difficult process flows that can't just be done via integration and API's, you should think robotic processing into the entire system update. Because of course you can do it properly. But when you look into like a thousand different IT system probably is going to be really hard. So robotics helps a lot with that. Let's step it steppingstone of making a new system doing robotics while you do it. helps a lot.
Mark Percival 24:54
That makes sense but definitely something that you as you said, taking that into the processes Critical versus coming at it after the fact.
Mikkel Jensen 25:03
Exactly. So they just like they, they almost skipped some of the processes when they did the entire update, because they just outsourced it to a robotic process. So they have like a key person looking out for that specific process in the system, like they have a queue and all the cases go there. And there's a caseworker fixing all the difficult ones and the robot doing all the easy ones, so to speak. So the entire process was thought into the update of the system, which we've seen great results with.
Brent Sanders 25:36
Yeah, I bet. I mean, what are the moving away from the sort of citizen developer initiative and into what your team looks like? And what types of automations that you've seen? I'm curious to know, in the read in your recent memory, has there been an opportunity to automate that you've said no to, you know, things that have come across your desk from business units or, and this assumes that other parts of the organization are coming to you saying, hey, we'd like to automate this process? I'm curious if that as that is the case? And then be it? What's something you've said? No to and why?
Mikkel Jensen 26:15
You had a Christian start as well, what was that?
Brent Sanders 26:19
It was what have you said no to?
Mikkel Jensen 26:20
Oh, is that, um, we had a process lately that we had to also from like, they wanted a back end robot, RPA, to run and fetch data from banking accounts and like, public sites that you needed personalized logins to, which was a no go, because, because it's like a, it's not legal for robots to access data data that way in Denmark, so we had to change the whole basic of the robots. We didn't say, No, we just altered the process. To be a robot, they started and they had to do all the logins or supply all the data. So we also the manual process a lot and then basically made a robot who could do all the Excel compilations, because it was like 100, may emails, two, three, I think of the three, Excel x. And you need to compile it into like four different nuarx sheets. It's called sheets in English. So we did that as a major rework, because they just wanted it to be fully automated, but now they have to have an operate on the system. I haven't.
Brent Sanders 27:43
That makes sense.
Mikkel Jensen 27:45
We've done some processes along site, like when, when people have, we have some of the newest systems that have these subtle integrations with like, if you push this button, the system will open up Excel, and you can type into Excel and to stuff. And we had to like, shut it down. Because it was way too way too many. s a synchronous calls into the system that updated at different times, and the robot just couldn't keep up with everything's happening while you typed and stuff.
Brent Sanders 28:22
Yeah, yeah, I could imagine. What are your thoughts on, you know, monitoring, the longer running bots that you've had? What are your thoughts around monitoring and decommissioning, bots that, you know, stopped delivering value? Whether they, it what I've heard from you is 40, bots, nine VMs. Number one, I think there's gonna be a lot of pressure on license utilization. And I'm curious, like, how do you guys keep track of, you know, that many bots in the limited number of machines? How do you keep track of all that, right? And how do you monitor what's going on? And what point do you decide, hey, this, this needs to be either rewritten, redone, or just turned off?
Mikkel Jensen 29:07
Well, most of these decisions are, like, based not in our department, but in the people who wanted the bots because they own the bot. And, and they, they get to decide if they want to continue having a bot running or if they, they think it should be disabled. So we don't make these calls. We just supply the infrastructure and we supply the robots, so to speak, so it's if you as a business, do not see the benefits of having a robot, you should not have one. So it's up to the people feeling the consequences of the robot to make it a good business case. And it's it we also push some of this, most of it into their hands. So we as a center of excellence, monitor the robots and have a A superficial first level control of what's going on. But we are not capable, as we're not caseworkers in a specific part of the business. So they need to monitor their own robots. As we the robot runs, it supplies the status of or in, they can see in a queue in their own system what has happened overnight, and they can monitor what is going on with the robot. And therefore they have signed people to the process that monitors it on a daily basis or on a weekly basis basis, depending on the robot. So they, they themselves, keep an eye on their own robots, which makes it a lot more easier. Because they have like, they have much more process knowledge about what's going on and why it's going on than we do. So debugging is kind of easier. Once did this the subject matter? expert, the SME comes with an explanation, in my point of view.
Brent Sanders 31:06
And then when it comes to, you know, exceptions, or outages, is there anything that you've learned in the process of, you know, any tips that you would have for our listeners, and that are, you know, looking to roll out their own CV? Any tips for you know how, when working in a dynamic like you have where, which I think a lot of organizations tend to, you know, balance that in a similar way, where it's like, the business unit that requests is there, the owner? They're not technical, usually, they are monitoring the output. They're monitoring their data, they're monitoring certain metrics. But if there's an outage or about, for lack of a better term breaks, how do you? How do you recommend people work through that with, you know, in partnership with a sort of non tech.
Mikkel Jensen 31:55
I think you, you coined it really great in your 12 steps of robotics. In the first episode, that you need to like, communicate, you need to, to, I think we have a rule of thumb, if the robot breaks, and you can fix it within, within a normal running cycle. If you have a robot that runs every night, and you can fix it during the day, then you should probably just mention it at the next status meeting with the spark. But if it breaks, and it has consequences, like you won't be getting a report next tomorrow, because the system updated. You should tell them as soon as possible, because they should have contingency plans set in place. If this if the robot does not work today, we should have a backup of fail safe fault for it. So it's a process thing, I think and it's business thing that they should be able to cope with the robot not running. Does that make sense?
Brent Sanders 32:57
Yeah, that's perfect. So we usually call that a business continuity plan or whatever, it's never fun to for that to happen, especially to break that news that, hey, you have to do this manually. But it is, you know, central to the process is you have to have it because the bots are going to break.
Mark Percival 33:15
You know, I think that's valid. I think the question is always as the bot kind of ages. It's it's the reliance always goes up, right? It's this sort of like database. It's sort of like well, backups in general, right? You get the backup process working one day, and it works great. And then you don't test it for a year. And then you actually need it turns out like it's not there. But I think that's the danger with business continuity planning is you figure it out the first day, but then, you know, three weeks later, four weeks later, then all sudden, eight months later, and something breaks. And it just it falls apart.
Mikkel Jensen 33:42
Exactly the RPA projects tend to track. Like once you've made the robot and put it into like, we have a like a test period where we run production data in a production system, like everything's normal. But we're not officially done with the process. Because it's always when you go live, everything just collapses. The deploy is a tricky case with the robotics and data is just so data and systems are so brittle, making them so brittle at least. So we have like a long hypercare period. And it's at the end of that process. We need to like, we need to pick everyone up and say this is how we do it. This is what is happening and you should have a contingency for this.
Mark Percival 34:36
That makes sense. Yeah, I think that's something that's difficult coming from a developer standpoint, which is uncertainty when you watch these programs. So you just kind of have to get comfortable with it and understand that you the term you use hypercare you have to that's a great term because that's really, it's really about that first launch and figuring out what's gonna break and just being comfortable with that knowing that you're going to go back and change these and get them working.
Mikkel Jensen 34:57
And then like reiterate the whole Documentation process because because you need to, like, once you go live, a lot of thing changes normally, and a lot of like dark data about the process of the system surfaces, because they go, Well, we have these 30 cases, and once it can handle all these 30 different kinds, everything's fine and you go live, and there's 50 cases, because you get 10 times the amount of data 100 templates, the amount of data and, and that you cannot, you cannot like, we have two roles and we have develop us and then we have analysts and the analysts cannot, they cannot make a perfect line out of how the process is because it's, there's so much of the process that's hidden from normal, from normal process description. because everything's a bit more murky, once you get real data into it.
Brent Sanders 35:49
I always call this like emergent requirements, right? The requirements sort of emerge as you build and it's in my experience has been the way software is built, like you have your best laid plans and you've done the work. But, you know, there comes a point when it you need to just start building and get this thing live. And it's always pretty, but you know, how do you respond to it? And so that's actually a space mark, and I've been thinking a lot about is like, you know, post launch? It's like, what is the life of about, like 369 months down the line, and we're not, we haven't nailed that down. But we're always interested in hearing from people that have bot in, you know, in production that long in trying to understand it. And again, Mark points out the, you know, the most scary situation, well, we thought the backups were happening, and you really don't find out until something goes wrong. And so how do you guys come back to I obviously, it's a business unit's responsibility to maintain sort of the hygiene of their processes and their bot, do you do a monthly, you know, quarterly audit on long running processes, anything that you do special to avoid issues?
Mikkel Jensen 37:03
We have a great focus when developing upon reusability. So we extract a lot of functionality. As a main focus, when I do robots, I take the business logic and put it in robot. And then all the robotics work should be as a rule of thumb in functions separated from the main project. So whenever the robot needs to interact with the system, it shouldn't be in the robot, because the robot is for business logic. And whenever I have a function for system, it can be reused. So to minimize workloads like system update, we keep almost all of our robot processes separated as widely as possible from our robotics work. Does that make sense? So in case of major system updates, we focus on the functions, and much less on the robots. So we separate process and robotics to make maintenance a lot easier. If a robot fails, making cases in the system, it should fail upon all the robots in that system making cases. And that makes it easier to pinpoint and easier to maintain. I think last time, we had a major system update, we had to maintain 13 functions, and it almost went smoothly.
Brent Sanders 38:41
Almost almost Yes, exactly. That's good. No, that's, again, I what I'm hearing is a strong engineering culture, adding municipality and taking on. You know, it sounds like because of that approach, none of the bots are sort of gathering cobwebs or, you know, getting out of date, right? You don't have one business units, functions that are languishing, they're sitting in, you know, some central repository and then being imported into the bot or whatever you know, actual implementation is and our list. It's a great approach.
Mikkel Jensen 39:15
Yeah, because most of the problems the hardest robots we have running are those who run once a month, because they have not been up to date with what's going on in the system environment for 30 days when they run. So having them use functions that other robots run every day makes it so much easier to not you do not get caught up in in local errors on that robot because once they get hit every day with from other robots, so So the point is the longer time a robot pot has not been running, the more brittle it becomes. So you need to like refresh the runs constantly to make sure no changes were deployed overnight. They'll supply off the IT. Does that make sense?
Brent Sanders 40:03
It sounds like yeah, what I'm hearing is it reminds you it's just discipline, right? It's like, yeah, it's almost like exercising, it's like, if you do it every day, your health is going to be fine. But if then, you know, you do it all, you know, like training for a marathon, if you do it all the week or two before, it's gonna be incredibly painful and probably not going to work out very well. Yeah. Right. So a little bit of pain every day to keep the functions up to date and dealing with the issues as they come. I mean, I think it's a very sensible approach. And so I think this is, this has been great, we really haven't heard a lot of developer perspectives, and especially to the scale at which you are at I mean, this is really valuable to hear. And I think, eye opening for me to hear, it sounds like you guys have embraced robotics embraced the citizen developer and created a COE, he spent the time put the investment in, in are reaping the benefits from it. And then again, the wildest part to me, that is, you know, it isn't a private company, this is a municipality that's in, you know, seeing real gains from it. So that's a very rosy, happy picture that I'm, I'm hearing.
Mikkel Jensen 41:11
Yeah and it's, it's also, because it's some public service, we have a great focus on doing things correctly, not just doing things, because it's a good case. Does that make sense? There's a good focus on service. So that is an also we have some standards about service that gives the robots a lot of value. You can minimize risk, you can standardize generalization, and free up working hours for the caseworkers towards so they can use that time with citizens instead of what processes and nobody's ever been wiser of doing a thousand generalizations.
Brent Sanders 41:57
Yeah, yes. Yeah. You know, one last question that I had in Mark, if you have anything else we can get to that. But I was curious, what you're seeing more on the developer side, you know, are in terms of the evolution of tools for, you know, things like extracting structured data from images or PDFs or, and I don't want to use the term, you know, AI and machine learning just yet. But, you know, the sort of next generation of tools, have you started adopting them? Have you had some cases where, hey, we'd be great if we could turn these scan documents into structured data and put them in Excel sheet? Are you doing that? Have you seen that the tools are working? Or do you stay away from that generally.
Mikkel Jensen 42:41
Well, locally, in my team, we focus on robots, we focus on we have the integration platform, and we have software, we have chat bots, and both voice bots. But our sister team is a machine learning team. They sit just opposite the whole. And they we do co labs with them. But mainly base is, we are the arms and legs, we fetch data, we put it into the database, we supply data, we put it on drive with a thousand files for them, because we can do that fairly quickly. And they supply like they have the brain so we deliver the robots, we should we have a focus on isolating simple robotic processes. And that is sort of part of our success is that the robots should do robot work, they should not like evolve into something else. They can supply data for machine learning. But it's basic division of labor. The machine learning guys and girls are great at what they do. So let them do that. Let them make the scripts for that. And we can just supply data if they need it. And that I think is critical when you do robotics, do not think it's a great tool for everything use it for what it is. It can do. It's great for interacting with the old interfaces in IT systems, because it's built for that, but it's not built for AI, at least not yet. And, and in my opinion, I've had fairly bad experiences with like, image recognition and stuff like that. I think the whole the whole market is changing. And it's like you if you have the newest artwork, you sell more licenses. And to be fair, you should not make a multi tool, you should make a specific tool for what you need. At the end of the day, that makes more value. If you have a tool that you need to use for that specific case. In my opinion.
Brent Sanders 44:46
Yeah, know that I appreciate the perspective and I think it makes a ton of sense to I mean, keep it simple. I mean, it's sort of what is Auckland's razor a Jewish? The most obvious answer is the answer right. It's like don't don't over-complicate It. Mark, did you have any questions? Any thoughts that you wanted to kind of closing thoughts?
Mark Percival 45:05
Now, I think I think the last one was pretty much what I was gonna ask you some more on the future of RPA. But I think that pretty much sums it up.
Mikkel Jensen 45:12
I'm not saying it shouldn't take a leap towards machine learning. I'm just saying, maybe it's a good idea for now to keep it spread out a little bit. So you can, so you can make great robotics because it's, it's not an old technology, people are not seasoned. I've done this for almost six years. And I'm not that great at it, in my own opinion. Because people who do software in I see them, they've been doing software for 30 years. They're really good at it. And it's a young technology still, so maybe we should focus on making it better before making it different. An old colleague of mine once said, it's better to have bad processes, you know, well and do good, then have new processes that are good, that you're bad at. Sometimes it's better to specialize in what you do then should just try something new.
Brent Sanders 46:12
Yeah, that's a great perspective. Mikkel, anything else you wanted to add before we wrap up?
Mikkel Jensen 46:18
No, no, not really. I think it went wrong.
Brent Sanders 46:22
Yeah, thank you very much. This has been a one of my favorite podcasts thus far. I mean, I think just hearing about your expertise, I think people are gonna get a ton of value out of it. I think. I'm really excited to get the word out about what you've been up to. So thank you very much.
