What is Change Management? How Process Mining can help.

00:00

Jakub:

Welcome back to the Mining Your Business podcast. The show all about process mining

00:04

Patrick:

Whoa, whoa, whoa. What are you doing? Hold your horses here, buddy. We can't just change who is doing the intro, willy nilly. We have to do an impact analysis. We need to communicate the change properly. We need to make sure that everything is documented.

00:16

Jakub:

That sounds like a lot of steps.

00:19

Patrick:

Yeah, it does sound like a lot of steps. And this is called change management, a show that we're going to present to you right now. Let's get into it.

00:35

Jakub:

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's what I'm dealing 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 Celonis only and implementing process mining 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 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 where he used to work beforehand and kind of bring you closer to what change management is and how does process mining actually fit into this frame. And I'll just start with a very little, I would say example from the real world. And that's, you know, nobody really likes the change, be it in the company, be it yourself. It's very difficult. 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 people around you, but it's generally and very often pushing the whole company forward in some direction. And therefore around where change management was created, there is a whole theory, a whole 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.

02:43

Patrick:

Yeah, for sure. It's also one of the things that we haven't really spoken about before. It very much comes to the in terms of a process mining project, there is always a point where we get to when it says, ok, 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 and the question drops like, well, 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 is 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.

03:24

Jakub:

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.

03:32

Patrick:

Not being experts on something has never stopped us from speaking on something in the past.

03:38

Jakub:

That's also true. However, our experience taught us and also experience 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 with different perspective than we would probably have if we were just implementing process mining. 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.

04:20

Patrick:

Absolutely. I mean, for sure. I mean, because as we said, we're not experts and please come on the show, correct the record if we say something incredibly stupid.

04:28

Jakub:

Let's start with the definition. I hope that I don't get this one wrong because this 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 redirects or redefine the use of resources, business processes, budget allocations, or other modes of operation that significantly change company or organizations. What to add, Patrick?

05:04

Patrick:

I mean, as far as I can tell, that's a pretty good, 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. Now 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. Technologically, not at all. But everything that's involved, right? All the things that are involved in making this excel file usable, something, all have to be scoped, all have to be, you know, accounted for all these things that go along with it, could be huge. And this is, of course, what change management exactly does.

05:46

Jakub:

Yeah. Patrick, I think you have 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 with your previous employer. Can you also share with the others?

06:05

Patrick:

Yeah. Yeah, for sure. So one of the examples that I got to realize at my former employer, Airbus is, so every plane that is being built has a, you know, unique serial number, right? So back in the day, back in the early seventies and eighties, when the first programs and the visual aid designs and all these things were preprogramed, they had a certain specific allocation of how many digits they could use for the serial number. Back then it was just four. That was what they settled on. Let's just stick the forward that's how we uniquely identify our aircraft. And that was working fine until, you know, like the 9000 mark or somewhere around that area where, you know, people started getting nervous and started thinking, well, we we're 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, we need more letters. I mean, how much is this effecting? It can't be that hard, right? And so and so they did the study about, ok, from the planning, from the electrical, from the interior and all these things that need to happen. How many of these programs are affected by changing from four letters to five? Turns out almost all of them. It affected literally every part of the business and it was really just cripple. And nobody really knew what would happen if you just introduced five letters to this program, 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 Amazon five project essentially, upgrading everything iteratively piece by piece to make sure that once you know, those first models start coming in and needing those five letters, that everything would still work according to plan and that there were no big business disruptions and all these things. So it's the tiniest things of changing from four letters to five that have largest impacts that you can imagine.

08:00

Jakub:

Right? I mean, I can 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? And if it's a problem, it's not going to be me who's dealing with it anyway.

08:12

Patrick:

That'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 numbers for the year and just didn't think about, oh, well, there's a millennium coming up, this is going to be problematic. And then, you know, a huge push was then was done to actually convert all the all the old programs to fit with that.

08:32

Jakub:

Yeah. And that's basically changed management because this tiniest thing that at least to a normal person, seem like a very easy thing is a change or just a transition has 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 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 the discipline of change management and I came across terms such as ADKAR model or John Kotter's eight step process for leading 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 John Kotter's 8 step process for leading change. And 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 your vendor late or if you don't pay them at all, everything's too late. Everything is paid after the due date. You kind of have an urgency and everybody wants to fix the problem. So creating urgency here, I think it's a no brainer on how to do that.

10:46

Patrick:

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, they'll lose their minds. So the urgency is definitely there.

10:54

Jakub:

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.

11:04

Patrick:

Yeah. Yeah, for sure.

11:05

Jakub:

Yeah. The next step is 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 the 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 episode. Where we highlighted how important it actually is to have someone who drives this initiative all of process mining and change management is kind of like a

11:54

Patrick:

Umbrella.

11:55

Jakub:

Yeah, exactly. Thank you, Patrick. It's like shielding this whole process mining as well, and therefore building a guiding coalition is very important.

12:06

Patrick:

You listeners could not see it, but Jakub was wildly waving with his hands above his head, that's why I said umbrella. But yeah, so this guiding coalition is expound on this a little bit, if you like, in 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.

12:24

Jakub:

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-company really. And therefore, you need some people who know the company and can pull some levers when needed.

12:45

Patrick:

Please, continue.

12:47

Jakub:

Yeah, that the next step is actually to form a strategic vision and initiative. And this actually already revolves around the goals and what you're trying to achieve with your change management initiative.

12:59

Patrick:

Now with 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?

13:08

Jakub:

Well, you can also look at the different goals that you have. If you want to improve your accounts payable process and you want to improve your payments. Well, probably it's not going to be only that everything needs to be paid on time. 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 seeing, ok, this and this and this, we need to do in order to improve the overall picture and overall performance. This is something that needs to be then laid down and prioritized by this guiding coalition.

13:56

Patrick:

Ok, so having like a holistic picture of all of the things that need to change in order to achieve the overarching goal, that is to, you know, pay things more on time.

14:07

Jakub:

Yeah, the next step, the fourth step is enlist the volunteer army. And I really like this one because very often it feels like, you know, this is you and me, Patrick, the volunteer army.

14:17

Patrick:

The volunteer army.

14:18

Jakub:

Even though we are not very volunteering here.

14:21

Patrick:

We are not much of an army.

14:23

Jakub:

I mean, not much of an army, but these are the people who are actually executing the change, who are, you know, who are really putting themselves up in the frontline of implementing the changes and doing the heavy lifting.

14:40

Patrick:

So this is either the organizational change or the actual technological change if it were to be a program or things like that.

14:46

Jakub:

Exactly. So this is the force that 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 things 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 users to start using the technology, the process mining and start, you know, become an analyst. 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.

15:43

Patrick:

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, pacifically if it's 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 to grips with 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, but still doing the same amount of stuff. And it's just, I mean, from a physics point of view, I think just impossible and 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 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.

16:50

Jakub:

Exactly. Then actually let's go to the next step, which is generate short term wins and this is also a no brainer for me. Whenever I start the project of process mining, I always try to ask the the customer, the business people, what is your biggest needs? What is your biggest challenge? And we kind of create these 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 will 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 the technology.

17:54

Patrick:

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. So there's not that big involvement, that big overhead of involving everybody in calculating risk and all these things that comes along with it. It's a fairly quick win. 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 like big changes in your organization as well. And those are more on the back burner like maybe the cost that we calculate for this problem. It 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.

18:46

Jakub:

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 initially anticipated, you 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 and, you know, if the main person, the main managers who are supposed to drive this initiative lose this motivation, it can happen then that 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 just change everything and just didn't happen.

19:57

Patrick:

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 with so much with human emotion. But like enthusiasm, it's such a big thing. So losing that is critical. You know, if you can find that person that drives it, that really pushes everyone else for adoption and all these things. And regardless if there's issues or setbacks and, you know, maybe a lull 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 that drive is incredibly important.

20:33

Jakub:

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 the change to stick to be ever present in your organization. And that means a lot of things. That means allocating actual resources on continuing with using the technology or any, 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 that and on continuous basis. Also evaluate the system whether the changes that you've implement are actually getting you to the goal that you laid at the very beginning? Because if you say, ok, I want my accounts payable to be paid on time, you implement the changes and within six months you see that you actually are paying even later than that, then, well, maybe the change management wasn't such a big success, was it?

21:40

Patrick:

Yeah. Or maybe, I mean, you are paying more things on time, but it has the 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. 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. So having regular cycles where you evaluate, ok, was this a success? What do we need to change? Did we cause more problems that we now need to fix, that we need to revert, I don't know, something that is incredibly 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. Well, it seems to have been a little bit of work since this documentation was written. It's like, yeah, maybe a little bit. So 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.

22:51

Jakub:

What do you mean, Patrick? We're doing great. I have all the documentation in my head. Ask me anything about my work. I will tell you exactly where to find what.

22:58

Patrick:

Yeah and when you're on vacation, I'm stuck.

23:02

Jakub:

Well, I never go on vacation, so don't worry.

23:04

Patrick:

That's actually true. Documentation is an incredibly important aspect of the whole thing.

23:10

Jakub:

I've seen way too many memes about documentation in the last couple of weeks, so we might even post some as a preview for episode 44, for this one.

23:20

Patrick:

Documentation memes, I never thought I'd see it.

23:23

Jakub:

Let's have some fun. Anyway, the reasons why organizations 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 are 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 the last couple of years. And to keep up with this trend is 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 the changes.

24:11

Patrick:

I mean, 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. 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.

24:42

Jakub:

There was a running joke when Corona hit for the first time and everybody just went to work from home office. Who was the biggest reason for digitalization? And there was like a CEO a CIO or Corona virus. I mean, it's really amazing that a world wide virus has actually a bigger impact on how we work than any other initiative from, you know, within or outside of organizations that we could even imagine.

25:17

Patrick:

I mean, I 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 say, right, you're going to work from home and all of a sudden there's a need to change. It's not like they wanted this to happen.

25:29

Jakub:

True, but very often you have these external triggers that forced you to change whether you want it or not.

25:38

Patrick:

That's also true. But I guess my main point is, there's a change in the market, this can take years and all these things, you know, things 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 ok, but how do we do that now? That's like the biggest or fastest change management that I think companies have done in a while.

26:02

Jakub:

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 things that you don't even plan for, such as, I don't know, shift in laws or regulations, some new economical 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 to enable people you need to build a team around that to support other change managements that are, you know, are on different fronts. And there you have this change management everywhere and you're kind of starting to get lost.

26:46

Patrick:

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 of our automation and all these things where you could have just looked at it from a change management point of view and said, well, let's look at these structural problems, the inherent process problems that are arising to these problems and not have it be just another tool that you throw into a problem to fix it, but rather a more in-depth look and maybe fix it from a change management point of view.

27:28

Jakub:

Yeah, we have a beautiful slide for that. We were just discussing with Patrick, we don't even know who created it for our company, but I know I keep showing to everyone and we have this iceberg, which you see just a tip of it, above the above the sea level. And then there is this huge part under, you know, under water. 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 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 it's them who eventually have to translate the findings into something tangible, something valuable, something that will result in actual savings or improvements.

28:50

Patrick:

Yeah, the actual improvement part of the process, right? Highlighting the inefficiencies is good and fine, but OK, so what are you going to do about it? Right. That's, 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.

29:05

Jakub:

Yeah. So while process mining will actually 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 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're 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 in this whole ecosystem of change management.

29:54

Patrick:

You said it. It fits into the model because you can have an idea about where are your processes and that that it needs to change. 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 and where it is at its most inefficient and things like that. That what process mining is perfect for.

30:24

Jakub:

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 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 the 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.

31:24

Patrick:

Yeah, this is exactly what process lifecycle is then here to do. 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 is going to work, the goals that we achieve, the overarching aim, maybe something else happens, maybe we've added more things into the process by then. So we'll start to see new activities or things like that occur and that is to monitor 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? Can you monitor that? And is it really meeting expectations?

32:09

Jakub:

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 that into the whole process management into this category where you design the processes, but also monitor them and evaluate them and create the system around them.

32:43

Patrick:

Yeah, no kidding. I mean, for quick wins. I mean, you can get quick wins. That's totally fine. But 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 toolset.

33:04

Jakub:

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 ASAP? 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 they 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 very powerful technologies on the other side which not only show you the process mining, your 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.

34:29

Patrick:

Yeah, I mean, the impact analysis is already a massive part. I mean, you need to speak to all the people that are involved or 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 quickly, when do we implemented this? 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 it's causing a lot of issues, how do we roll back to a previous situation? So like all these things need to be planned ahead before, you know, change can just be implemented. It's probably a good idea that we do this methodically and carefully in order to not cause a massive disaster.

35:14

Jakub:

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 and in accounts payable processes. What maybe a businessperson 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's some mismatches between PO and between the invoice or something, be it non delivered goods receipts or goods or things like that. And while you can technically solve the problem by implementing some relatively straightforward automation, you should probably first ask, is this a good idea? Yes or no? And if no, then or if both actually say 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.

36:29

Patrick:

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 missed that point. What happened to me recently at a client where I said, hey, ok, we want to write back into our ERP system and just have this thing done automatically through this process mining tool. And I said, ok, sure. And then I tried to shoot it off. And, you know, that's seen in Lord of the Rings where Pippen 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 say, ok, what's the need? Why are you doing this? What's the purpose? Blah, blah, blah. And I was all of a sudden, you know, there's a big thing that's happening here. It's not just as simple as, ok, I can technologically do it, but all of a sudden everyone's wondering why I'm doing it. What's the what's the reason? Was the business purpose, right?

37:22

Jakub:

Yeah, I feel like when you go down this road, it almost feels like, imagine that you're sitting on your couch in your house and there's just water dripping from the top. You look at that and then you look down and you find out that you already have like ten centimeters of water in your room and you're like, dammit, I should probably solve this problem. So you basically decide because you're lazy and you bought this very cool pump recently. You say, ok, I'm just going to suck out all the water out in the sink or something. And you put the pump there and, you know, 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 kind of fix it with your pump, probably if it happens five, ten times, your carpets are 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 occurring? 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 the one while 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.

39:04

Patrick:

Yeah, I mean, identifying a problem and then I think you could ask like a hundred people and they'd all come up with a different solution. I mean, probably some are more obvious than others, but if you see a hole in your roof, you know, the solution should be, hey, fix the hole rather than pump out all the water that's coming in or, you know, anything like that. So figuring out the best solution, even if it is more cumbersome, is exactly that that hurdle. It costs more energy. You need more resources. You need to plan more and it's not as quick. It's not that quick win that you were looking for. You can just set up the pump right away and the problem will be solved. But it doesn't solve the inherent issue and that can be tricky to overcome. Nobody likes expending extra energy. I mean, specific for a business, 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.

39:55

Jakub:

Yeah. But again, process mining will help you with identifying this. Imagine that you create this process, rain to pump or something.

40:06

Patrick:

This analogy is getting off.

40:07

Jakub:

Yeah, whatever. If you created this, then 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, ok, it rains, let's see what happens before there and you will see this water goes down the roof and it always starts with this part. So you already have this guidance that is created through mapping your processes, and you can act upon that. And that's the ultimate root cause analysis that you should aim for and strive for when rolling the process mining technology out.

40:49

Patrick:

So we've highlighted a lot of the change management aspects, but I think it's also important to realize that, you know, not everything is successful, right? And organizations fail and change all the time. It's nothing uncommon that happens, especially in bigger organizations. Change takes time. It's hard. Things fail.

41:05

Jakub:

I even saw the statistics that according to McKinsey, they have this research on transformation programs. And they said in their study that 70% of transformation programs fail. That's just insane.

41:18

Patrick:

That is a lot. And I mean, looking back at some of the examples that I've seen at Airbus, there was one example that was like a program for electrics. It was fairly outdated. It couldn't do a lot of the functions that they wanted it to do. So there were a whole bunch of fixes and extra features that were programed and all this stuff, but you know, the ending was nigh for that program. It needed to be replaced, needed to be integrated. And so there was always this constant cycle of, hey, we have a new plan on how we want to change this and the deadline is one and a half years. 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 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, 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 more stuff and deadline comes around, budget's way over and well, 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. So it's inherent that some of these things just don't go according to plan and the problems are bigger than you think. 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, transformations fail. But again, we can highlight a few of them. One of those is jumping to a solution to the problem, it's something that we mentioned before, you know, seeing the hole and just jumping to the solution of, ok, let's just pump it out. Just getting that quick fix, getting that quick win before you really establish the proper solution that would inherently fix it for a long term. So just immediately jumping the gun.

43:15

Jakub:

Yeah. One of the other issues that you probably just discussed was this underestimating the problem in the first place.

43:24

Patrick:

Severely underestimating it.

43:26

Jakub:

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 point B and say 1.5 years, €500,000 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, so forth. And you just realize, oh, emmm, ok, nice.

43:52

Patrick:

Yeah exactly, maybe not. You know, it's also 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, ok, well, if I if I don't get this done in one half years with the budget then, you know, I'm going to have to look somewhere else for the job, right? So it's like these types of goals, right? And realistic goal setting is one of them. So knowing what you're getting into, right? So not underestimating the problem and also having realistic goals of when these things should be done and by what time. So and having the elasticity in your planning to say, ok, 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, there needs to be some sort of flexibility.

44:45

Jakub:

Yeah and once you have the budget and the time frame just multiplied by two, that's my three recommendation.

44:54

Patrick:

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, but a lot of the problems that you find, you don't know until you start. Now, you can budget for these but specifically when you're doing impact analysis and specifically the problem. You're doing an analysis on to see how it would impact the other business. You don't know until you do it.

45:21

Jakub:

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 around these predictive models on how a certain change in the process may actually result or what it may actually result in. So these are some interesting topics that I would love to actually cover in some of the future episodes.

45:45

Patrick:

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? You know, that's one of the impact analysis 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 that have to be accounted for. You can't just take out everything and just hope for the best. I mean, you can, but it probably won't go that well for you.

46:09

Jakub:

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 false, 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 rolled out and nothing works anymore. And you're like, ok, 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.

46:55

Patrick:

So I was sitting next to the person that was in charge of companywide emails or specific emails that were sent to specific groups about how to communicate and all the things that are involved, like, ok, 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, then a week before, hey, just reminder, this is going to happen, blah, blah, and organizing all the communication is a huge, huge part of it. And even then, even if you do your best on communicating, if you staple it onto people's desk and say, hey, this is going to change, people are still not going to know that this is changing, right? I mean, you can't force people to read stuff, unfortunately.

47:29

Jakub:

We all know how it works when you get a companies newsletter, it's usually end up somewhere in the spam folder in the first place. And if it doesn't, you just assign it to low priority, put it as to do later.

47:42

Patrick:

And never read it again.

47:44

Jakub:

Yeah and a week later, you find out that your account is disabled because you didn't update your system or something.

47:50

Patrick:

Yeah, I'm guilty of this. I'm so guilty of it.

47:52

Jakub:

Yeah and then you're just call in your support like, hey, guys, so listen, I really wanted to do that, but I kind of forgot.

48:02

Patrick:

Yeah, exactly. It's a tone of just, you didn't read it, did you? Yeah, I'm sorry, I didn't.

48:11

Jakub:

Read the manual, right? Ultimately, what I found fascinating is how much this whole discipline of change management is a peoples 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, you know, behind the curtains of your process. And therefore, you should organize your processes as if you are organizing people and be aware that ultimately it's also the people who can be the bottlenecks and handle it with a lot of care and a lot of patience as well.

49:04

Patrick:

Absolutely. 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 business and it's something as stupid as hey, this one plant does it better than the other plant and so they don't want to give up their way of doing it because they think there's this better than the other ones. But in terms of them, you know, making sort of 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 are thinking, no, no, we everyone else should do what we do because we do it best. Right? And there's like this inherent ego that comes with them you know, you thinking you're the emperor of everything and you do everything perfectly. And so everyone should do what you think is best. But, you know, there's a more overarching, this umbrella thing that you were raving about before, this umbrella vision that you need to have to make sure that, you know, what's best for the company. And what's not best for like 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.

50:14

Jakub:

Shut up and listen.

50:16

Patrick:

Yeah, unfortunately, that's the case. And I mean, from what I've seen, this ego is deep with a lot of people and they can hold a lot of things up.

50:27

Jakub:

Now, I know it's deep with me, I like doing things my way. So what if we have scripts to make it faster?

50:36

Patrick:

What? all of a sudden I have to document the stuff I do? No way!

50:41

Jakub:

This change management topic is huge. And we didn't even talk about everything. We completely skipped a chapter about overcoming resistance to 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 of sectors of process changes and of managing 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 presentation from Celonis 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 really looking forward to is this 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 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 the wind or something because it just feels like it's going anywhere but where you want it to go. So just text off on email miningyourbusinesspodcast@gmail.com. We are also very active on LinkedIn, so feel free to reach out.

52:45

Patrick:

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.

52:54

Jakub:

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 Your Business Podcast. Thank you very much, Patrick. Have a nice day. And for everyone else. Bye bye.