What is Change Management? How Process Mining can help.

Welcome back to the minding your business podcast. The show, what about processing? Whoa, whoa, whoa, what are you doing? Hold your horses here, buddy. We can't just change who is doing the intro, willing, nilly. We have to do an impact analysis. We need to communicate the change properly. We need to make sure that it's everything is documented. That sounds like a lot of steps. Yeah, it does sound like a lot of steps. And this is called change management. The show that we're going to present to you right now, let's get into it. Hello dear listeners. So today we actually are going to talk about change management, which is interesting topic, which I have to be honest. We are still learning together with Patrick. However, you know, things and that what I'm dealing with with one of my customers actually brought me to this topic very recently. And what we are doing there is that we go a little beyond implementing cell on its own and implementing process planning technology. And we are very much waiting in on what we can actually achieve with this technology. And we are starting to realize how difficult things are. And due to the various circumstances that we have there, we also have some very capable people who already have experience with processes, implementing changes, and just this general suite of change management. We thought it would be very cool to actually share our experiences here, what we've been dealing with our customers. And also, I think Patrick will mention some of his previous experience with some where we were used to work before and kind of bring you closer to what change management is and how this process mining actually fit into this frame. And I'll just start with a very little, I would say example from a real word and that, you know, nobody really likes to change, be it in the company, be it yourself. It's very difficult. It's very, you have to swallow a lot of pride. You have to do things differently and changes are difficult. And you know, implementing changes in an organization that's just a whole different level because it's not only pushing yourself and, you know, people around you, but it's generally and very often pushing the whole company forward in some direction. And therefore, our own change management was created as a whole theory, it is a whole, you know, discipline which looks into ways on how to formalize changes and how to actually execute them so that your organization stays at the top of the game and is agile and able to change. Yeah, for sure. It's also one of the things that we haven't really spoken about before, right? It very much comes to the, in terms of a process mining project. There's always a point where we get to when it says, okay, we can highlight all the inefficiencies, you know, we can give some suggestions on how these things could be improved. And then, you know, obviously the question drops, okay, well, how do we, how do we go about doing that? And then it's usually, well, you know, we need to think about change management here because these problems are fairly deep, they're fairly inherent. And you know, this is not just a quick thing that we can just snap out of our fingers and say, well, your organization has now changed and it's no longer inefficient. No, no, this requires change management. Why? Well, we're going to highlight why that is and why it's so important in this episode. Yeah. I guess what we can start with is a definition. And as I said, I will highlight it once again here. We are not change management experts, but we did not being experts on something has never stopped us from speaking on something in the past. So that's also true. However, our experience taught us and also experienced with the people we had the privilege to interview in our podcast actually brought us here, brought us to this topic and pushes us into thinking about it in a different, with the different perspectives than we would probably have if we were just implementing process mining, right? So while being aware of this larger picture, we try to shed some light on it. And obviously, if you feel like you are actually a change management expert and could bring some more experience, some more knowledge into our show, then please reach out. We would be so happy to talk to you. Absolutely. I mean, for sure. I mean, as we said, we're not experts and please come on the show, correct the record. If we say something incredibly stupid. Let's start with the definition. I hope that I don't get this one wrong because this is from Wikipedia. However, change management is a collective term for all approaches to prepare, support, and help individuals, teams and organizations in making organizational change. It includes methods that redirect or redefine the use of resources, business processes, budget allocations, or other modes of operation that significantly change company or organizations. What's to add, Patrick? I mean, as far as I can tell, that's a pretty good description. I think sometimes it's hard to kind of visualize just how much, how many resources and how much is involved in doing like the simplest change, right? Yeah. If you think about very simple changes and if you think about maybe just swapping out an Excel file from this version to this version, that can't be that hard, right? Technologically, not at all, but everything that's involved, right? All the things that are involved in making this, that use this X file or something, all have to be scoped, all have to be, you know, accounted for in all these things that go along with it could be huge, right? And this is, of course, what change management exactly does. Yeah. Patrick, I think you have an experience with, you mentioned swapping Excel files and as a part of preparation, we were discussing different points. You actually introduced me to what you've been dealing with in your, with your previous employer. Can you also share with the others? Yeah. Yeah, for sure. So one of the, one of the examples that I got to, got to realize at my former employer Airbus is, and so every plane that is being built has a, you know, a unique serial number, right? Back in the day, back in the early '70s and '80s when the first programs and visual aid designs and all these things were, were programmed and, you know, they, they had a certain specific allocation of how many digits they could use for the serial number. Back then it was just four. That's just what they settled on. Let's just stick to four. That's how we uniquely identify our, our aircrafts. And that was working fine until, you know, like the 9,000 marker or somewhere around that area where, you know, people started getting nervous and started thinking, we were running out of digits here. We need five digits to really uniquely identify all of our aircraft now because we're getting to 10,000. And then there was this big Y2K moment in what we need more letters. I mean, how much is this affecting if you can't be that hard, right? And so, and so they did the study about, okay, from the planning, from the electrical, from the, from the interior and all these things that need to happen, how many of these programs are affected by changing from four letters to, to five? It turns out almost all of them, right, it affected literally every part of the business. And it would have severely just crippled. And nobody really knew what would happen if you just introduced five letters to this program. Fail, the interface would fail, the connection, the data interchange between these programs would fail. No one knew. So there was this huge program launched internally, the MSN 5 project, essentially upgrading everything iteratively piece by piece to make sure that ones, you know, those first models start coming in and needing those five letters that everything would still work according to the plan and that there were no big business disruptions and all these things, right? So it's the, the tiniest things of changing from four letters to five that have the largest impact that you can imagine. Right. I mean, can you imagine that the person who was developing the system and was thinking, hmm, let's just use four letters, how big of a problem could it be, right? Yeah, exactly. And if it's a problem, it's not going to be me who's dealing with it anyway. It's not going to be my problem, exactly. I mean, that's the same thing we saw in Y2K when, you know, people were using two, two numbers for the year and just didn't think about, oh, well, there's a millennium coming up. Maybe this is going to be problematic. And then, you know, a huge push was done to actually convert all the, all the old programs to, right? To fit with that. Yeah. And that's basically change management because these tiniest thing that, at least to a normal person seem like a very easy thing, easy change or just a transition, have major implications for all kinds of people, all kinds of parts of organization. And you know, rolling out new technology or changing your internal business processes is difficult and it takes time. And what we kind of want to highlight in this episode that, you know, talk a bit about this change management topic and discuss the different phases and how we can actually apply it for maybe business processes that we are usually working with, then just speak about how process mining can help us with that and what it actually cannot help us with. And finally, just again, shed a light on how we can build a process driven culture. And I guess first, every change management comes in different phases. And this already comes into the planning and, you know, while preparing for this episode, I came across a couple of different methodologies that are really studying this discipline of change management. And I came across terms such as adk, a R model, or June cutters, eight step process for reading change, which essentially lays down the foundation on how the process, how the change management should be executed. And I thought it would be interesting to actually introduce these steps on a process that we and obviously you also know quite well, because we talked about it in our last episode, which is accounts payable. And therefore, let's actually jump into this June cutters, eight step process for leading change. The first step there is a creative search, a sense of urgency when applying a change management method. You know, when you have an accounts payable process, creating a sense of urgency is probably pretty easy. If you're paying care of end or slate, or if you don't pay them at all, everything is too late, everything is paid after the due date. You kind of have an urgency and everybody wants to fix the problem. So creating an urgency here, I think it's a no brainer how to do that. Yeah, I mean, if you tell any finance person, hey, we're losing so and so much money just because we're not doing things on time, lose their minds. So the urgency is definitely there. Also probably one of the reasons why AP process is usually the one that companies are working on first when it comes to implementing process mining technology. Yeah, for sure. Yeah, the next step is I'll build a guiding coalition. So guiding coalition is, you know, the management and the project team that is kind of organizing, orchestrating how things should be executed. So it's from defining the goals to providing the budget, to creating actual project team who will work on different topics. And it also goes back to creating this center of excellence, which we discussed with another guest of ours in one of the previous episodes, where we highlighted how important this actually is to have someone who drives this initiative of process mining. And change management is like a hire or is, you know, a umbrella. Yeah, exactly. Thank you, Patrick. It's like a shielding this whole process mining as well. And therefore, but building a guiding coalition is very important. Yeah, you listeners could not see it, but Jakob was wildly waving with his hands above his head. That's why I said umbrella. Oh, yeah. So this guiding coalition is expound on this a little bit. If you like the stakeholders or just essentially the people that are there to drive the change and figure out who's involved and who to get together and how to plan things, right? Exactly, especially because as we mentioned, some of the changes are, you know, they don't stay within one team within one department, but are cross cross company, really. And therefore you need some people who know the company and can pull some levers when needed. Right. So please continue. Yeah. The next step is actually a former strategic vision and initiative. And this actually already revolves around the goals and what you're trying to achieve with your change management initiative. Now would that always be the same, right? If we talk about, hey, this is at the end of the day, we want to implement this change, right? What else is involved in this initiative? Well, you can also look at different goals that you have. If you want to improve your account's travel process and you want to improve your payments, well, probably it's not going to be only everything to be paid on time, but you also need to go a little up the stream of the process and start looking into how the invoices are digested and processed, approved and so on. Because this ultimately impacts everything down the stream. And for that reason, having this not only the high level vision, which would be we need to pay on time, but actually cutting it into pieces and see, okay, this and this and this, we need to do in order to improve the overall picture and the overall performance. This is something that needs to be then laid down and prioritized by this guiding coalition. Okay. So having like a holistic picture of all the things that need to change in order to achieve the overarching goal that is to, you know, pay things more on time. Yeah. Yeah. The first step is endless the volume tear army and I really like this one because very often it feels like, you know, this is this is you and me Patrick, the volume tear army. The volume tear army. Even though we are not very volume tearing here, we are not much of an army, not much of an army, but these are the people who are actually executing the change, who are, you know, in who are really putting themselves up in the in the front line of implementing the changes and doing the heavily think. So this is either the organizational change or the actual technological change, if it were it be a program or things like that. Exactly. So that's the first step. The fifth step is enable action by removing barriers and in my opinion, this is something that you simply enable your people to perform first of all the technical tasks that they need to do, but also allow them to actually focus on it with their time and with their dedication. This is something that I'm facing very often with my customers. When we want to change something, we want to improve it. We want the users to start using the technology, the process mining and start, you know, become an analyst really. However, it's always on top of their current tasks that they have to do. And this is just not really doable because well, nobody wants to work 140% each week. And therefore, you have to create a scenario where people actually have time to focus on their problems. Yeah. This topic is a big one because like you said, we see this all the time. And it's not just that in order for you to focus on these new tasks specifically, if it's a change management or adopting a new tool like process mining or anything like that, you need to dedicate a good amount of time to really get the grips of what you're looking at and really adopting it, usefully and effectively, and with that comes that expectation of you need time to do this. And if somebody says, yeah, we have this new tool, you're going to use it now and it's going to take up 50% of your time. But on top of that, please keep doing what you're already doing. So free up half your calendar while still doing the same amount of stuff. And it's just, I mean, from a physics point of view, I think just impossible, right? Just squeezing all that into time. I think that's just not possible. So I think also one of those things that needs to be accounted for resources, right? And this comes from this coalition. If you put it to make sure that the required people, the people in the front lines do get that time and do get that the support they need to actually go ahead and do this and not have it be a side project that gets left on the side of the road. Exactly. Then I'm actually going to go to the next step, which is generate short-term wins. And this is also a no-brainer for me whenever I start a project of process mining, I always try to ask the customer, the business people, what is your biggest need, what is your biggest change? And we kind of create this metrics where we are putting like a low effort, big impact implementations, then also the high effort, low impact, and we kind of create this metrics of what should be prioritized and what not based on how we feel about what kind of impact would it eventually have and how difficult for us it would be to implement. And the sole purpose of this exercise is to kind of pinpoint the areas where we can in a little amount of time, with a little amount of effort, create some big wins for the organization. And it's important because once you have this big wins, they can actually justify the further and continuous investment into their technology. Oh yeah. I mean, this is also a big thing. The cost that it takes to actually get that win, like you said, quick wins are great. It also doesn't really require change management in a lot of cases, right? So there's not that big involvement, that big overhead of involving everybody and calculating risk and all these things that comes along with it is a fairly quick win. Yeah. Now, there are, of course, other things that you identify, you can identify them fairly quickly that where we can see that if you want to change this, then this is going to require big changes in your organization as well, right? And those are more on the back burner, maybe the cost that we calculate for this problem doesn't really justify the cost of actually changing your organization to that degree. So that, you know, this problem would be solved, right? So there's a bit of like a cost benefit type of calculation that you also need to take into account. Exactly. The seventh step is sustain acceleration. Again, it's very easy to come into a project and have a lot of excitement and a lot of energy and like be very, I would say, just going to do things. But you know, once you have first obstacles, once you start seeing that it actually requires more work than initial anticipated, you'll start seeing first problems, first issues. It's very easy to lose this enthusiasm. And therefore, a system must be in place to mitigate this risk because if people lose their enthusiasm and if, you know, if the main person, the main managers who are supposed to drive this initiative, lose this motivation, it can happen then that the project is not successful just because, you know, you were hoping for quick wins, you were hoping for implementing a solution that will just with a magic wish of, you know, just change everything and just didn't happen. So this is also a big point that I can't believe like a lot of these aspects that we're talking about have to do so much with human emotion, but like the enthusiasm is such a big thing right. And so losing that is critical, you know, if you can, if you find that person that drives it that really pushes everyone else and to adopt to for adoption and all these things, in regardless if there's issues or setbacks and you know, maybe a law in the project, maybe vacation time, you know, how it is and people come back and completely forgot what they were doing, you know, someone that keeps that motivation up and that drive is incredibly important. Yeah. Yeah. And the last step is actually to institute the change and if you already went all this effort and all this hustle to get all the way here, you kind of want to change to stick to be ever present in an organization and that means a lot of things, that means allocating actual resources on continuing with using the technology or any other process change that you might have made. It also means that you should document the changes, right, that you should create a system about how these changes should be used going forward and create the whole system around it. And on continuous basis, also evaluate the system whether the changes that you've implement are actually getting you to the goal that you are laid at the very beginning because if you say, okay, I want my accounts payable to be paid off time, you implement the changes and within six months, you see that you are actually paying even later than that then well, maybe the change management wasn't such a big success, was it? Yeah. Or maybe, I mean, you are paying more things on time, but it has a corollary effect somewhere else down the road. Maybe some other department is now affected by the different way of how the AP department is now doing things, right, so it's like pushing in one direction can lead to things falling off on some other part of the business, right, and that needs to be evaluated, right, so having regular cycles where you evaluate, okay, what's the success? What do we need to change? Do we cause more problems that we now need to fix? Do we need to revert? I don't know, you know, something like that isn't currently important, but what I also think that you're mentioning documentation is huge. I mean, you and I both know this about how we talk technical details with a lot of people and saying, yeah, this was done like two years ago, here's the documentation, and the documentation looks nothing like what we're looking at and it's like, well, it seems to have been a little bit of work since this documentation was written. It's like, yeah, maybe a little bit, right, okay, like documentation about how your process works, the steps involved, who's involved, and all the pitfalls and all these things, incredibly important. And I think, to my knowledge, there's not a single company that I know of or that I've worked with that does it well. I mean, we don't even do it well. What do you mean, Patrick, you're doing great. I have all the documentation in my head. Oh, yeah. Ask me anything about my work. I will tell you exactly where to find what. Yeah, yeah. And when you're invocation, I'm stuck. Well, I never go invocation, so that's actually true. So this documentation is incredibly important aspect of the whole of the whole thing. I've seen way too many memes about documentation in the last couple of weeks, so we might even post some in as a preview for our episode for this one. Yeah. Documentation memes. I've never thought I'd see it. Let's have some fun. Anyway, the reasons why organization want to change is, I think, already pretty obvious. As, you know, we are living in a world where what we were using a year ago is not the same what we were using today. And it's changing continuously very fast. And if you think about how organizations worked 15 years ago and how they work now, it's a very big change, very big shift, a lot of new technologies were introduced in just last couple of years. And to keep up with these changes, to stay competitive, you simply need to adapt or you are out of the game. And having organized an efficient change management in place is vital to keep up with changes. This is a big thing where, you know, we have new technologies that are introduced to the market, you know, that's one aspect, but also the market itself is changing, right? So the demand for things is changing over the years. And you need to adapt or need to have some flexibility in your organization to be able to adapt to those changes because the competitors are, right? So being on the back foot of change or at least being aware of the things that are going on needs to be vital. And that's why change is always good. There was a running joke when Corona hit for the first time when everybody just went to work from home office, who was the biggest reason for digitalization. And there was like a CEO, a CIO, or coronavirus. Yeah. Everyone. I mean, it's really amazing that the worldwide virus has actually a bigger impact on how we work than any other initiative from within or outside of organizations that we could even imagine. Yeah. I mean, I'll kind of disagree. I mean, it's more of the forced way to change, right? The companies really didn't have a choice in the state, right? You need to work from home and all of a sudden, there's a need to change. It's not like they wanted this to happen, right? True, but very often, you don't, you always are very often. You do have these external triggers that force you to change whether you want or not. That's also true. But I guess my main point is that it was not like from, I mean, there's a change in the market. It can take years and all these things, you know, things are ties are changing. But all of a sudden, from yesterday to today, that it just completely changed and everyone now needs to just work from home and everyone's just thinking, okay, but how do we, how do we do that now? Like the biggest or fastest change management that I think companies have done in a while? Right. And it's probably here to last. Anyway, many reasons why organizations would want to change, as I said, start with these external factors, but it can be also as things that you don't even plan for, such as, I don't know, shift in laws or regulations, some new economic trends, new competitors, and even introduction of new technology, because process mining, while it's a supportive tool for change management, is a change management in itself, because you are introducing new technology and you need to enable people. You need to build a team around that to support other change management that are on different fronts. And there you have this change management everywhere and you're kind of starting to get lost. Yeah. And I think this is also a big point where we have to really look at the need of business users and the reason for process mining, and I think a lot of the times it's the idea that hey, we can apply this tool and this will just kind of fix the problem and we'll be able to execute and do all our automation and all these things where you could have just looked at it from a change management point of view and said, okay, let's look at the structural problems, the inherent process problems that are arising to these problems and not have it be a, and just another tool that you throw on to a problem to fix it, but rather a more in depth look and maybe fix it from a change management point of view. Yeah. We have a beautiful slide for that. We were just discussing with Patrick. We don't even know who created it from our company, but I know I keep coming into everyone and we have this iceberg, which you see just a tip of it above the sea level and then there is this huge part under, you know, underwater. At the top of the iceberg is process mining technology, you know, and it's what you think you need to facilitate the change to improve your processes to just become a process-centric organization. However, what you actually need is everything else below the sea level, which are things around the team, you know, the executive buying. It's also the enablement of the users. It's user adoption. It's the governance model. It's also value monitoring and there's just so many things that you have to think of when you start with implementing process mining while everybody thinks that it's just a technology that's going to point into the problems you have in process. You know, good insights do not guarantee that the change would be made and that's where people step in again and that it's them who eventually have to translate the findings into something tangible, something valuable, something that will result in actual savings or improvements. Yeah. The actual improvement part of the process, right, highlighting the inefficiencies is good and fine, but okay, so what are you going to do about it? That's the question. Well, I guess we have to do this and this and this and that involves, again, change management in most cases. Yeah. So while process mining, actually, it will allow you to do many things. It will allow you to begin with, right, to make a precise diagnosis in almost real time of your processes and it can be by, by, it can be global, it can be by unit, it can be a lot of different dimensions and it just this does this x-ray into your processes, into your business processes and help you understand what is it that you are actually doing there, including all the bottlenecks, including all the reworks, anomalies. However, this is still just the data that has to be ingested by you, by your organization and eventually be in a certain way leveraged into, in this, in this whole ecosystem of change management. Right, and you said it, I mean, there's, it fits into the model because you can have an idea about where your process is and that it needs to change, right, and everyone's complaining, these things aren't working, you know, we're not adapting, there can be a whole lot of things wrong. And process mining is, like you said, the x-ray in figuring out where these bottlenecks are, where they're the most severe, what are costing you the most money, where it's at its most inefficient and things like that, right, that's what process mining is, is perfect for. Yeah. It also helps you evaluate the conformity and what I mean by that, again, I'm just going to do a little side note here that we talked about conformance checking in one of our previous episodes. So if you want to know more, just go check, check it out. But what you do there is that you check whether your processes are executed as they are designed and that especially is valuable once you implement the changes because when you implement the changes, you assume that you either pay in time or you have some other process steps that don't even occur or are executed in a specific sequence. And by creating this conformance checking, you can actually say whether your change be it in the way that people are using the system or that you actually design it or by some improvements are translated into reality and whether you are really, really harvesting on what you set out to do. Yeah, this is exactly what process life cycle is then here to do, right, it's a cycle. So we have to continuously evaluate the efficiency of it and continuously monitoring with process mining the way that we think it's going to work. The goals that we achieve, the overarching aim, maybe something else happened. Maybe we've added more things into the process by then. So you will start to see new activities or things like that occur. And that is to monitor, right, and check the conformance. Is it now in your head are all the swim lanes being occupied in the way that your BPMN model is saying that they should, right, and can you monitor that and is it really meeting expectations? Yeah, and with that, I'm realizing more and more how important process mining is in the bigger scheme of things that I start to really resonate with some of the ideas that our previous guest had that it just cannot coexist as a segregated, separate initiative. But it should be, or it's highly recommended to integrate it into the whole process management into this category where you design the processes, but also monitor them and evaluate them and create this around them. Yeah, no kidding. I mean, it's for quick wins. I mean, you can get quick wins. That's totally fine. At some point, you're going to need to change on a deeper level, right? And process mining is still one of the best tools for analyzing processes, right? So it makes total sense to be able to integrate that into the already existing change management tool, tool set, right? And why I'm saying that is because very often we actually see that this is not always the case. And I don't blame anyone who jumps into quick conclusions because it's usually very easy. And there's always this balance between, do I really want to mitigate the problem and fix it a step? Or do I actually want to really go back into the system and figure out what is going on and why is it going wrong? Because these can take very, very long time. If you worked in corporations before, you know how slow there can be. Sometimes you are just pulling your hair out of your head and thinking, how can it take so long to approve this one little thing to change in the system since I already opened it four months ago. What is taking so long? What's taking so long is that the change is actually being probably being evaluated and to consider them, you know, you need to see what kind of impact it would have. And while having this on one side, you have the very powerful technologies on the other side, which not only show you the process mining, the processes, your business processes how they are, but they also give you pretty strong tools in your hands on how to basically make the problems go away. Yeah. I mean, the impact analysis is already a massive part. I mean, you need to speak to all the people that involved all the programs and the technical people behind those. It could be that it needs some sort of mitigation, right? So before and after, like how to quickly, when do we implement it? So at the time, because it can be dependent on other changes. So making sure that the scheduling is right and also having that contingency, you know, if this change actually is inherently bad and is causing a lot of issues, how do we roll back to a previous situation, right? So like all these things need to be planned ahead before, you know, change can just be implemented. Check it out. It's probably a good idea that we do this methodically and carefully in order to not cause a massive disaster. Yeah. And I've been asked a couple of times already to automate some problems away using technology. And while you have access to it and things can be done, I'm always very, very hesitant in making something like that happen. Because if I think about it, let's say that you have some payment blocks that are occurring in your purchase to pay an account's payable processes. What maybe a business person would want is just to remove the payment blocks automatically because well, they decided that it's probably best so that they can pay in time. But the payment block occurs probably for some reason, be it some mismatches between PO and between the invoice or something, be it a non-delivered good receipt or goods or things like that, right? And while you can technically solve the problem by implementing some relativist straightforward automation, you should probably first ask, is this a good idea, yes or no? And if know then or if both actually if yes or no, why is it a good idea? And really try to first go backwards before actually implementing anything because it can have big implications for everyone. Yeah, exactly. And I think a lot of the people that are adopting this new strategy of hey, we can automate, we can execute, we can push things back into systems and stuff, often kind of miss that point. What happened to me recently at a client where it said, hey, okay, we want to write back into our ERP system and just have this thing done automatically through from this process mining tool. And I said, okay, I'm sure. And then I tried to shoot it off. And you know that scene in "Lord of the Rings" where Pippin accidentally like throws that bucket down the well and it makes a whole bunch of noise and all the orcs come rushing in. That's essentially what I was dealing with because all of a sudden I was getting emails from everybody in that organization and it's like, okay, what's the need, why are you doing this? Well, what's the purpose, blah, blah, blah. And I was out of all of a sudden, you know, there's a big thing that's happening here. It's not just as simple as, okay, I can technically do it. But all of a sudden everyone's wondering why I'm doing it. What's the reason? What's the business purpose? Right? Yeah. It's like when you go down this road, it almost feels like I imagine that you're sitting on your couch and you're in your house and there's just water dripping from the top. You like look at that and then you look down and you find out that actually I already have like 10 centimeters of water in your room and you're like, damn it, I should probably solve this problem. So you basically decide because you're lazy and you bought this very cool pump recently, you say, okay, I'm just going to suck out all the water. Just out down the sink or something and you put the pump there and you think problem-solved. However, whenever it rains, you still end up with having a lot of water on your floor, which is not an ideal situation. And while you fix it with your pump, probably if it happens 5-10 times, your carpet's going to be kind of smelly and you might have some organisms living in your walls. And you probably don't want that. What you could do instead is think about why is the problem cost? Why is it actually raining and pouring down the ceiling into your room? And you might find out, oh, I actually have a hole in the roof. So what you probably do instead is fix the hole in the roof so that it doesn't rain there in the first place. So two different approaches, both of them seemingly fix the problem. But one, while it might be actually a bit more cumbersome because you need to make more efforts to fix a hole in the roof is probably the right solution in this specific case. Yeah. I mean, identifying a problem and then I think you could ask like 100 people and then I'll come up with a different solution. I mean, probably some are more obvious than others. But if you see a hole in your roof, the solution should be, hey, fix the hole rather than pump out all the water that's coming in or anything like that. So figuring out the best solution, even if it is more cumbersome is exactly that hurdle, right? It costs more energy. You need more resources. You need to plan more. And it's not as quick, right? It's not that quick win that you're looking for. Yes, you can just set up the pump right away and it'll just problem will be solved. But it doesn't solve the inherent issue. And that could be tricky to overcome, right? Nobody likes expending extra energy. I mean, specific for business, hey, cost more money. It takes a little bit longer to implement changes, stalling, things like that. That's more uncomfortable, but it's the better solution for that particular problem. Yeah, but again, process mining will help you with identifying this. Imagine that you create this process, rain to pump or something. The knowledge is getting off there. Yeah, it's, yeah, whatever. If you created this and you would find out that whenever it rains, you have to use the pump, right? So you already have this clear correlation. And when you think, okay, it rains, let's see what happens before there. And you will see this water goons down the roof. And it always starts with this part. So you already have this guidance that is created through mapping or processes. And you can act upon that. And that's the ultimate root cost analysis that you shoot aim for and strive for when rolling the process mining technology out. So we've highlighted a lot of the change management aspects, but I think it's also important to realize that not everything is successful, right? Organizations fail and change all the time. It's nothing uncommon. That happens especially in bigger organizations, right? Change takes time. It's hard. Things fail. I even saw the statistics that, according to McKinsey, there have this research on transformation programs. And they set in their study that 70% of transformation programs fail just insane. That is a lot. And I mean, looking back at some of the examples that I've seen and Airbus, it was, yeah, there was one example. That was like a program for electrics, right? It's fairly, it was fairly outdated. It couldn't do a lot of the functions that they wanted it to do. There were a whole bunch of fixes and extra features that were programmed and all the stuff, but you know, the ending was nigh for that program. It needed to be replaced, needed to be integrated, right? And so there was always this constant cycle of, hey, we have a new plan on how we want to change this. And deadline is one and a half years, we're going to, we're going to change it out and it's going to be done. And we're going to have this new program. It's going to work just just in how we want one and a half year deadline. And this is the proposed budget. Get it done. What ended up happening is, of course, they were trying the, these people are doing their best, trying to really evaluate all these things and all of a sudden coming up with more problems, more problems. Why this is a big risk and we need more time, we need more budget, we need their stuff. And deadline comes around, budgets way over and, well, no, maybe we'll find somebody else to do this job. And again, let's go. One and a half years, this budget, let's go, do your thing and it didn't work out, right? So it's inherent that some of these things just don't go according to plan. The problems are bigger than you think, right? And so we should definitely talk about like, why these organizations fail. And there's a ton of reasons and a lot of these can be organizational specific, why some projects, why transformations fail. But again, we can highlight a few of them. One of those is jumping to a solution to the problem, right? It's something that we mentioned before, you know, highlight seeing this bucket, seeing the whole and just jumping to the solution of, okay, let's just pump it out, right? Just getting that quick fix, getting that quick win before you really establish the proper solution to, that would inherently fix it for a long term, right? So just immediately jumping the gun. Yeah. One of the other issues that you probably just discussed was this underestimating the problem in the first place, you know, just just purely underestimating it, you know. Just because you want to change something and it seems easy on the paper, you know, you just draw an arrow from point A to pain B and 1.5 years, 500,000 euros of budget, let's fix it. You start having these all other arrows that go from point A to point C and, you know, back to point A and so on and so forth. And you just realize, oh, okay, nice. Maybe not. Yeah, exactly. Maybe not. It's also one of those morale things that we spoke about, you know, there's a deadline and the person that's in charge of it knows, okay, well, if I don't get this done in one and a half years and with the budget, then, you know, I'm the look somewhere else for to find job rights. So it's, it's like these types of goals, right, and realistic goal setting is one of them. Right. So knowing what you're getting into, right, so not underestimating the problem and also having realistic goals when these things should be done and by one time, right. So and having the elasticity in your planning to say, okay, maybe I just found out this is really difficult. We need to reorganize. We need to restructure. Maybe rethink. We have come up with these problems now that we didn't think about before. Now, let's reprioritize and make new schedules, right. So adapting it, not sending these hard goals, specifically when it comes to something inherently difficult to change, you know, you, there needs to be some sort of flexibility. Yeah. And once you have the budget and the time frame just multiplied by two, that's my recommendation. It's one of those things where, of course, you need to be wary of budget. There's not infinite supply of money. And of course, you need to make sure that this is used responsibly and, but a lot of the problems that you find, you don't know until you start, right, and you just, no, you can budget for these, but you specifically when you're doing impact analyses, specifically the problem, right. You're doing an analysis on to see how it would impact the other business. You don't know until you do it, right. So although I must again say that there are some interesting ways, especially in process mining and business processes, how you can kind of predict the future and run these predictive models on how a certain change in the process might actually result or what it might actually result in. So these are some interesting topics that I would love to actually cover in some of the future episodes. Yeah. I mean, impact analysis can be anything from, hey, we have this extra process step to, hey, I'm going to pull up this cable on this server. What's going to happen? That's one of the impact analyses that you have to do specifically when it comes to infrastructure change or technological change that often involves hardware and all these things. All these things have to be accounted for. You can't just take out everything and just hope for the best. I mean, you can, but it's probably not going to go that well for you. And for that reason, exactly I believe you need to have a very strong governance in place and be watchful for all those little things that can occur for the dependencies and force also orchestrating the whole organization around the change that you're doing. Because one thing is to execute the change, but the other is then tell everyone who is involved somehow in the process of this change, what they should do. The last thing that you want to do is change your system, don't tell the users, and then they come to work at one day after the weekend when the change was allowed and nothing works anymore. You're like, okay, maybe I should probably give them access and tell them how to use the tool first before rolling it out and telling them this is now the new way of working. Yeah. So I was sitting next to the person that was in charge of company-wide emails or specific emails and sent to specific groups about how to communicate and all the things that are involved. Like, okay, this is what's going to happen in like a month, be prepared. This is what's going to look like. This is what we're doing. When we speak before, hey, you just remind her, this is going to happen, blah, blah, blah. And organizing all the audience communication is a huge, huge part of it, right? And even then, even if you do your best on communicating, if you staple it onto people's desk and say, hey, people are still not going to know what that is changing, right? So, I mean, it's, you can't force people to read stuff, unfortunately. Yeah. We all know how it works when you get a company's newsletter. It's usually end up somewhere in the spam folder in the first place, and if it doesn't, you just assign it low priority, put it as to do later and- Never leave it again. Yeah. And the week later, you'll find out that your account is disabled because you didn't update your system or something. Yeah. I'm guilty of this. I'm so guilty of this. Yeah. And then you're just calling your support like, hey, guys, so listen, I really wanted to do that, but I kind of forgot. Yeah. And be kind with so much. Yeah. Exactly. It's a tone of just, you didn't read it, did you? Yeah, I did. I'm sorry. Yeah. Yeah. Read the damn manual, right? Yeah. Yeah. But ultimately, what I found fascinating is how much this whole discipline of change management is a people's game because processes are people. And even though you execute something in the system, you have ERP and you are planning and so on, ultimately, it's still people who are doing this action, be it the interaction with the system or the actual work behind what is going behind the curtains of your process. And therefore, you should organize your processes as if you were organizing a people and be aware that ultimately it's also the people who can be the bottlenecks and end it with a lot of care and a lot of patience as well. Absolutely. Yeah. I mean, you bring up a super good point, the focus on the people because you'd be surprised. I mean, probably not the people listening. There's a lot of ego going around in a lot of this, in a lot of business, right? And it's something it's as stupid as, hey, this one plant does it better than another plant. And right. And so they don't want to give up their way of doing it because they think there's this is better than the other one's right, but in terms of making coalescing something together into one process, everyone's like, well, no, we should do it our way. And they should do what we do. And they're thinking, no, no, everyone else should do what we do because we do it best. And there's this inherent ego that comes with you thinking you're emperor of everything and you do everything perfectly. And so everyone should do what you think is best. But there's a more overarching, this umbrella thing that you were even about before, this umbrella vision that you need to have to make sure that, you know, what's best for the company, right? And not best for one specific way. And sometimes you just need to put your foot down and say, everyone, shut up, we're just going to do it this way because that's what's best. And everyone just needs to get with the program, right? Shut up, I'm a son. Yeah. So that's the case. And I mean, well, from what I've seen, this, this, this ego is, is deep with a lot of people and they can hold a lot of things up. Yeah, I know it's deep with me. I like doing things my way. So what we have scripts to my to make it faster. Yeah. But all of a sudden, I have to document no way. Yeah. This change management topic is huge and we didn't even talk about everything. We completely skipped a chapter about overcoming resistance change, which I think we can actually make a whole episode out of because it's again fascinating and it goes a lot into this human factors of process changes and of managing these, these changes overall. So this is something that we might get into later on. And as I mentioned at the beginning, one of the reasons why we created this episode in the first place is that I was actually invited to give a little, a little presentation from Salonis about how to orchestrate the changes around implementation of process mining. So I'm really excited to do this. It will be actually at the day of release of this episode in Copenhagen, I've never been to the city. So one of the reasons I'm looking forward to it is just very, very, you know, I'm just going to go somewhere I've never been before, which is always cool. And this actually served as a little preparation for myself so that I can organize my thoughts and create a more probably digestible and shorter version on how you can go about implementing your process mining efforts into daily use and actually use it what it was designed for, which is, you know, utilizing it and leveraging the process management and actually also change management. So if you have any other recommendations or ideas or you just want to share some of your burden that you have on your shoulders with change management, then trust me. I know what you feel like sometimes it just feels like you're fighting these, the wind or something because it just feels like it's going anywhere but where you want it to go. So just text us on email mining or business podcast at gmail.com. We are also very active on LinkedIn. So feel free to reach out to all the people, to all the change management people that are screaming right now at us saying, you didn't mention this and you got this wrong. Please come on the show, correct the record and tell us all about it. Right. We will be happy to give you some spotlight. Anyway, to everyone else, thank you for listening. I hope that this also taught you something because it really, really taught us something for sure. And we will be looking forward to talking to you again with the next episode of mining or business podcast. Thank you very much. Patrick, have a nice day and for everyone else. Bye-bye. [BLANK_AUDIO]