How to Perform Root Cause Analysis?

This is the "Mining Your Business" podcast. I show all about process-mining data science and advanced business analytics. Back with another episode. Today, we will talk about root cause analysis. Figuring out why your process has the issues that it has can be a daunting task. If you're not, Jakub and I are here to shed some light on how we approach this topic with our clients. Jakub, are you ready to get into it? - Hell yeah. - Let's do it. (upbeat music) (upbeat music) Hello, hello, and welcome to another episode of "Mining Your Business" podcast. Today, speaking about root cause analysis. And I'm really looking forward to this episode because it's a topic that I've been dealing with in recent months quite a lot because a few of my customers are actually in this phase when they are really trying to get into the details and understanding of what exactly is happening within their processes. And I think it's an interesting topic that is actually very often omitted. And I'm sorry to see it and hear it that not everyone is targeting it in a way that probably should be done. And that's why I really want to bring this topic today in today's episode to you, Julie Sinners. Before I do so, Patrick, you have to say. - Now, I'm also looking forward to this episode because a few of my clients are going to be going through this phase sooner rather than later. So I'm also excited. - Yeah, yeah. - What I also wanted to say though, before we start is that I just actually just finished my coffee because we were talking with Patrick for quite a bit before we started and hit this record button. But I was sipping my coffee from actually a cell on his Mac and I also possess two other Macs, a process and Mac and software, a G Mac. And I want to try what is our reach of this podcast? And I want to ask if there are analysts who have their own company, Max, ideally from business process management, but who cares? I would also appreciate the Mac of some other company. If you have a Mac and you want to share your commercial, your marketing Macs with us, we would be very happy to receive some of those. So I really want to start the collection of business process management, Max. I really want one from SAP, but I would also like other ones. - You're such a dork. - Yeah, so if you want to send us a Mac, we would be very happy to get one. - Absolutely, but you always, we always are running out. We are coffee fanatics here. And I'm sure you know that since listening to the first episode or for the second episode of our podcast that we love, coffee. So the more containers out of which to drink it from, it is better. - Yeah, hell yeah. So that was our Mac introduction. The one was, I want to say this joke, like get mucked or something. - I'm sure there's a joke in there. - Yeah, it's not a good one though. Let's, let's rather get into the root cause and list. - And as I mentioned, it was a topic that really was brought to my attention through an actual ongoing project. And I even wrote a post about it on LinkedIn recently, where I was kind of thinking about what it brings and mainly highlighting that it's a lengthy exercise. And it truly, truly is. And we're gonna get to the bottom of it today and sort of explain why is it a lengthy exercise, but an important one that simply, if you want to improve your processes, shouldn't be skipped at any cost. - Yeah, it's one of those things that we look at from art and kind of services that we provide. We handle the implementation on these things, but root cause analysis. That is something that companies themselves really have to do, right? I mean, we can be there along for the right and all these things, but I mean, this is something that takes, like you said, a while and can be painful as well. - Yeah, yeah. But simply understanding the full picture of what you're doing in your process is the only way on how you can reduce waste and improve your process. And therefore, let's get into it. And before I even get to root cause analysis, you should even narrow down on what you want to focus on because it's very easy to get distracted, to get side railed when you start a new project and you see the endless opportunities on things where you can actually improve. It's, first of all, it's very good, but it's also overwhelming. And you don't want to go down the rabbit hole and looking into things that don't matter as much, that are time consuming and so on. And therefore, what I always try to guide my customers into is understanding their priorities. And I start with something we call a value pyramid where I simply in some simple workshop fill out this template where I ask the customer, ask the departments and the people involved in the projects about their strategy goals and objectives. Because this ultimately shapes the vision of the company and it helps you to focus on things that matter. And as an example, if you are an accounts payable team and I'm gonna be talking about accounts payable a lot because it's, after all, it's the topic that I have a lot of experience with and have done this many, many times before. If your target number one is, let's say, utilizing a new channel for invoices, like an electronic way to bolst and submit the invoices into the system by the vendors, then everything else should revolve around that. Even though you might have problems with some light payments or so, but you should really focus on what is the most important target for you. Now, is that, can I ask, why is it a pyramid, right? Like, what's at the top and what's on the bottom? - So on the top, you have this strategy goal and objective. There you understand what is the major like impactful and what is the major thing to focus on. Under this, under the first and under the peak of the pyramid, you have the ongoing initiatives that are hopefully trying to target this. So if you want to have a digital way of submitting invoices, then you will very likely have some scanning systems in a way, or even better, you will have an EDI interface for the vendor and you will try to run an initiative to actually get the vendors to use it. So that you are achieving your goal of getting from 50% of invoices that are posted laterally to 70%. And this 50% to 70% is one of the key metrics that forms the bottom of the pyramid that talks about the, how you actually go and measure the success of the ongoing initiatives. - Precisely, precisely. And that's where you also insert process mining because these will be the metrics that you will want to measure and understand after implementing a process that will help you to improve or achieve the goal that you set up for yourself. - Yeah, so that's basically something that, sometimes unfortunate is just not really taken into a consideration and I think it's a shame because if you don't understand your number one priority, how do you know what to focus on? And that's what you should do before you even start implementing the process. Really understanding was the biggest pain point for you and the only way you're gonna get that is by discussion with stakeholders and with all the relevant parties. - Right, so that aligns with the strategic goals of the company is like, we wanna reduce waste, we wanna pay more on time and blah, blah, blah, blah. So those are the strategic goals that you should keep in mind when developing your initiatives and your metrics. - Exactly. The reason why it's so important is because it shapes the whole project of implementation and the adoption. And as you probably know and as you've heard us talking about before, we have a few phases. We have a design phase where you really talk to stakeholders what should the project, that process capture, what are some of the use cases they want to focus on and so on. Then you go into implementation phase and you basically roll out the process in your process mining tool and then you go into adoption phase. And the adoption phase, we talked a lot about it actually and there are a lot of topics that you would be targeting in an adoption phase. One of it is get your users into using the tool, a big topic, you do it in many different ways. We talked about gamification, we talked about targeting some, or incorporating some automation, some executive dashboards and so on. A lot of ways, how to do that. And you then use the tool for reporting you to, you use it for ongoing analytics. And the ongoing analytics is also something where the root cause analysis really sticks out. And that's so important. And it's really the phase where you need to go and understand the process and deploy and empower your analytical data scientists who should target and should go in a way and get this information out. - Yeah, I mean, because the path of value, I mean, you talked about the adoption, right? And that's great, right? We build tools that are capable of analyzing a lot of things. And adoption needs to obviously be high, right? Because what's the point of building a tool that no one uses, right? So the only effective way to get a lot out of it is by people using it. But there's a million different ways you can use tools like these, right? So it's also critical to help the users have some sort of framework that they can use to one quantify, track and do all these things that they can find inside this tool and then also have a method in place on, okay, what do we do with this now, right? Like where do we go from here? We have found this thing that's causing problems, okay, great, now what do we do with it, right? And that's all set up in this adoption phase, right? - Yeah, and while software providers, process mining providers are more and more shifting towards becoming an operational tool, which is a tool that's ingrained into your daily routine into daily work and ultimately that's also a way to let a tool stick. So very legit way on how to deploy a process mining tool at a very, very core, it's still an analytical tool. There's just nowhere around that. You have your process, you have your dashboards, you have your graphs and so on. And all of these are built so that you can go into the data and get the important information about why your process is inefficient. And that's what we actually call a root cause analysis. And when I go a little back again, and when we at the beginning set up those goals and our main targets, you also build use cases around that. So if your main target is automation or on-time payment, then you probably will build a report that tells you how different parts of your organization are being automated, eventually what is the rework rate or if we are talking about on-time payments, which you will hear throughout this episode quite a bit, you will build a report that gives you the insights into on-time payments. - Right, because I mean, again, the goal is always key. It's at the top of the pyramid. So we have to build specific things that will help us tackle these goals. And it's also important to keep in mind, I mean, these goals can change over time. And with that comes new priorities and new areas to focus on throughout the development and the process mining initiative. - Yeah, ultimately, you will probably be left with a process. Again, let's say a council member process and a few use cases that are somewhat geared towards your ultimate goal and ultimate targets you're trying to reach. However, even then, you will probably still be a little, you know, your attention span will go from one use case to another and that's also not optimal. You should really go on and focus on two max three use cases. And those are the ones that will play the major role in the root cause analysis. And to even understand what to focus on, you should ask, I would say three major questions. What is the strategic relevance? So even if you're pinpoint three, four, five areas you want to focus on, you should always have the biggest, the spin point or this pinnacle of the pyramid in mind when picking up the use cases. You should think about what is the optimization potential. So, you know, if your ultimate goal is to pay on time, but you're paying on time 98% of time of, you know, of all your invoices, then well, even this incremental increase of one to two percent would probably achieve your goal. You would probably lose a lot of resources just achieve this because, you know, how they say this 80/20, the part principle, the 80/20 rule just to achieve this 20% or this 20% is much more difficult than the 80% and so on. So something to keep in mind all the time. And try to focus on the use cases where the optimization potential is just simply higher, which you can enumerate by multiple ways, by framing it, by looking into a number of cases that are affecting this use case, the number of, you know, the amount of money that you are potentially losing due to this inefficiency and so on. And the final step would be the technical feasibility, which basically tells you is it even possible to improve it if so, how much would it cost? Because that's one of the surprises for a lot of customers, for a lot of people who are applying process mining into action is that it actually triggers so much more work. Yeah, but I mean, also, that, I mean, that's a good list. And those three points are very critical, right? But it's important to also do your due diligence here, right? If we have, for example, an on-time payment rate, like you said, of 98%, and you want to get to 100, right? Looking at 98% on time rate and saying, well, yeah, whatever, not that big of a improvement we could dismiss it, careful, careful. Those two percent, what are we talking about here? Are we talking about all invoices? Is it large invoices, right? So, or tiny ones? How much of a headache are they causing, right? So those two percent might seem insignificant, but it's important to, before you do this, to really get into the weeds and kind of figure out, okay, is this a problematic two percent or is this actually one that we can dismiss, right? It's important to know that because, yeah. A lot of deep, deep wells can be found when starting to dig into that two percent. - Yeah, but this is already something that would very likely trigger quite a discussion in the team. - Oh, yeah. - I'm actually focused on it or not. I would probably be challenging you quite a bit, about two percent, that it's not significant anymore, but obviously the total amount of it pays a roll. And if those two percent of cases actually represent 30% of value, then, well, yeah, you've got a point, but this is something that you should definitely target. - Yeah, but no, that's a good list. And I mean, the number one is also very important, just how much value is really behind it. There, it's also important to have conversations about, if this is even trackable, right? And kind of write the KPIs in such a way that you can actually track how much this on-time percent, on-time payment, low payment on, or high on-time payment, is actually causing in value, because this is exactly where you're going to be metering against when you actually go to the improvement. - Yeah, and it actually leads me to the next step, which is prioritization of the use cases. And that's something where you use something we call for quadrant metrics, where basically, on one axis, you have value from low to high, and on the other axis, you have complexity also from high, so from low to high. And here an interesting take is that on complexity, you can look from two perspectives. You can look at complexity, how to implement the use case in your process planning to in the first place, to get the insights into the use case. And then the other dimension of this complexity would be how difficult you assume it would even be to tackle this problem. So if you are talking about low automation rate, would it be complex to increase it? Probably yeah, because you will need to involve other teams, you will need to involve some automation tools, or just different, or changing your process at some point, so that the invoices are going through a lean process in an automated way. So those would probably be high complexity to implement, maybe lower complexity to display in a process planning tool, but to implement the change definitely something that should be taken at part. Yeah, I mean, again, it's all to do with focusing on your ultimate goal, top of the pyramid. Like is it conducive to what you're trying to achieve? Is it super complex? And in complexity, I would always argue that it should be looked at if it's even, the complexity should be in terms of how easy it is to actually implement a solution for it, right? Because I mean, we're like code wizards, right? We can draw, wait, we can, I mean, maybe you are a butt trick. Okay, well, but you know, we can design a lot of things in process planning tools and display them, right? It might be a bit complicated and write some things that I'm near impossible, but you know, we could get it there, right? But that's great and fine, but if the solution to fixing this problem is so complicated, right, completely different metric. Yeah. If a use case or something that your targeting seems to be too big to tackle, try segregating it into smaller pieces, you know what I'm saying? How do you eat an elephant one bite at a time? And that's also the same way. That's a saying, that's an actual saying. And it's not the check thing that we were saying because we don't even have elephants here, right? So why would we say that? Maybe a boar, but not an elephant. Okay, okay. And ultimately, you can chunk it into smaller pieces, smaller use cases and then you just place all of it on this metrics so that you see what are some of the high value use cases, you know, the value that can generate for you if you tackle them and solve them or improve them at least, even 5% improvement can mean big bucks in your pocket. And what is the complexity to implement it and to even get the insights, information about the use case? And then once you have this on your chart, on your metrics, you obviously pick up those that are quick wins, that are high in value and that are ideally low in complexity. And those are the ones that you start with. - Yeah, yeah, for sure. I mean, those are the easiest ones, usually the ones early on that you focus on in the process, on your journey, right, because it's at some point, you know, going to read benefits rather quickly. And then once that has been established, you can then focus your attention on the, maybe a little bit more complex ones, but still high in that value, right? Because those are the higher priority. - Yeah. Well, and then once you're done with this exercise, you actually finally go into root calls and lists. And it's finally, yeah, finally. So we just spent 20 minutes trying to get to this point to speak about root calls and lists. Amazing. Anyway, you're still with us, which is good. So we go into root calls and lists. And I need to highlight that you shouldn't go into solutioning mode before understanding the root calls. So it's very easy to get distracted and say, let's automate something, let's find a quick fix, let's find a band-aid for this problem and automate the problem away. But if you don't understand why this is happening, you might end up with a problem. And again, my favorite use case, if it's training down your roof into your home, you might get a pump and get the water sucked out of the room, but probably would be easier, faster and smarter to fix the roof in the first place so that you don't get the water there. And that's exactly what you should do when you get to the bottom of these use cases. You highlight a few of them, let's say on-time payments and maybe automation. And then you go down analyzing what is happening. And to be precise, root calls analysis is a method to identify the root causes of problems, deviations or errors and analyze them. And again, it's used almost everywhere to understand why the thing that is happening is happening in the first place. And it helps you to get to the bottom of this problem. - Yeah, and again, it should be stated that this is a, it can be a lengthy discipline, right? It also depends on the quality of the statements that you can make afterwards, right? Because like you said with your leaky roof, why is my apartment flooded? Well, 'cause there's a hole in my ceiling. Okay, cool. Why do you have a leaky hole in your ceiling, right? So like you can go into different phases, right? Into different depths of what is causing your problem, right? Just simply pointing at a bucket and saying, well, there's a bunch of water here in it overflowed. Cool, but you need a little bit more, right? Because this problem analysis can go very, very deep. - Yeah, yeah. Unfortunately, and that's only my opinion, but it seems that sometimes even process mining solutions are getting this wrong by, and not to say that it's unhelpful, but it's just not complete. Because what we often do is that we go, I call it targeting the suspect, that we basically build down an overviews and it can be done in many ways or where you target the problematic ones. And again, let's use this example for light payments. When you do that, what you want to do is build a basic categories of what is late, what is on time and what is ahead of the time. So what is paid early. That's basic segregation. Then you probably go into understanding, okay, how late am I paying? How early am I paying? So you build another layer of complexity into the report where you start understanding, okay, what is causing it. But then, given that you're working in process mining tool, you have a lot of tools in your hands that will help you with further targeting these suspects with going even deeper into these layers of complexities, why something is happening in the first place. And those tools would be, for instance, conformance checking. A thing that is quite underused, unfortunately, but that can be specifically helpful if you are maybe talking about automation, where what you want to do is have designed a few ways, few processes for these type of invoices that are entering your system on how they should be processed. And once they start deviating, this is the problem, this is the place where you should start targeting the issue. Again, lengthy exercise because if you have 20 types of invoices that are entering the system and every have three ways of going through the system, suddenly you have what, 60 ways of how an invoice can be processed. And in order to map the conformance, you would probably have to define 60 different paths for the invoices. And that's just something that takes a lot of time and probably that's also the reason why companies are not tackling this very often. - Yeah, I mean, that's one of the great things about the process mining tool, right? You can very easily start getting down and narrowing down some of the metrics that you want to look at, right? So you look at your top 20 vendors or something that you might be interested in. And then from there, you can do the basic questions, right? Is this happening across all, is this a global issue, or is this happening in just specific companies? Is this happening in specific and different areas? Is it happening with invoices of specific like values, right? And very easily you can start seeing some patterns start to emerge, right? And from then you can kind of narrow down because you said there's, I don't know how many different ways to process an invoice, right? But if you start narrowing down and start like narrowing the focus of what you're looking at and then conformance checking on that and you'll have a much easier time sifting through all of that than usual. - Yeah, yeah. And again, it's about sort of creating a subset of your issues. And I'm gonna get to that a little later in a second because it even has a statistical label on what you're doing. But what you want to do is create different groups, different categories of the issues that are likely occurring in the process. So creating groups of segments, it's actually called clustering, but let's get into that later. But first, you need to conduct this basic analytics. Okay, highlight the vendors. Find out where maybe long delays in the process are happening. And those, let's be again, some kind of a group. You would look at costly processes. You could do also some sort of benchmarking between the vendors. Maybe you can take a vendor that is performing very, very well, exceptionally well. And compare it to the rest of them. - Yeah, what are we doing differently to the rest of my vendors to that have sped up my process where it goes through really quickly and we pay on time and everyone's happy. Like, why does that occur? And then you can benchmark that to the problematic ones. Well, why is it different? Why is this one causing me so much headache? - Yeah. And essentially, the root cause analysis, it aims to find process errors and their causes and analyze them. And basically, what you're gonna get is that you're gonna determine the proportion of errors that are found that have the same, same cause. And eventually, those same causes can be analyzed together. And if you are using some of the process mining tools, you also have these, they come up with something they call an automated root cause analysis or machine learning root cause root cause analysis. And I think it's a little problematic because it seems, it seems like this magic, you know, this magical thing that's just gonna swoosh and give you the exact root cause is behind whatever is happening. And it's not as simple as that because what it's doing, it's these reports are typically showing you some correlations between a certain outcome, a between the main denominators that are causing them. For instance, some fields in an SAP table that are associated with the highest or the most likely outcome that may be negative. And again, let's say that you focus on light payments. What this automated root cause analysis in a process mining tool typically does is that it's gonna spit out top 10 fields that are triggering this problem and you will probably see something similar as to like top 10 vendors. So maybe the first field will be a vendor and you will know that the vendor 1, 2, 3, 4, I don't know, a company incorporated is causing the issue and is probably the major impactful part that is getting you into paying for your invoices light. - I mean, that's all couldn't find, right? But I mean, that's just, again, something that you can already do with narrowing down your problems, right? So it doesn't really get to the main cause of, okay, why this specific vendor then, right? So it can highlight that this vendor is an issue but the why is still outstanding. - Yeah. However, you will not get by without analyzing these cases in details. And what you will need to do in the next step, which I would probably do if I was tasked in analyzing the root causes would be clustering. And cluster analysis or clustering is the task of grouping a set of objects in such a way that objects in the same group, that's the cluster, are more similar to each other than those in other groups. And that's exactly what you're trying to do in the previous step that we were talking about, that you're trying to create different group of vendors, maybe a different group of late early payments and you can even use some machine learning algorithms to cluster these things where you just take the whole subset of late payments or late invoices and you just run some sort of clustering algorithms and there's a bunch of those that basically, they are working in a way that they draw a line between them or they just draw some way of how these should be separated and you can create these groups even automatically. So there are multiple ways on how to do that. If you don't know what clustering is, I recommend reading up on the PDF page where it's pretty detailed and you can get some ideas on how this would be. And basically the clustering, you could do this on activities, you can do this on lead times, on fields, on many, many different things. - Yeah, and that gives you then the basis, then when you have a cluster, those entities inside that cluster will be relatively similar. So likely suffering from the same problem or at least that's the hope is that the information that you've fed to the whatever you'd use to cluster will have gathered some information that will help you at least not really narrowing down your problem but able to segment your problems into different root causes, right? So that you can tackle a lot of things one by one and then you can also see, okay, you have a bunch of potential areas or bunch of clusters, some larger than others. And then you can focus on maybe larger clusters because you'll get a bigger, bigger win with finding out what's really causing the issue. - Yeah, and interesting thing here is that you can cluster these groups in any way you wanted because it's very likely that one invoice might be part of two different clusters depending on the way or on the perspective that you're looking at it. So there's again, no magic bullet here, there's no way that you're just gonna make a draw a line and say, okay, this will be this group, the other group will be here and that's just the way it is. They are, you know, mistakes can happen and there will be overlaps, there will be things that don't fit perfectly anywhere, those there will be outliers, complete outliers. And this is just the part of the game. - Yeah, I mean, and it's just important to keep that in mind that you should spend a lot of time doing this, right? Because you can cluster everything three ways to Sunday. So it's, again, trying to figure out the keeping your goal in mind, what are you trying to achieve and is this really showing you information that you need in order to get your to uncover the inefficiency? - Yeah, and ultimately you wanna get into next step which we call sampling. And again, sampling is something known from statistics. Sampling, you know, every auditor in the world does sampling when they are checking random invoices for compliance, for issues and so on. There are many ways on how you can do it. You can simply, if you are looking at the invoices that are causing the issues that are late, you can just select 10 random cases and you will do a random sampling that you inspect deeper. You might be lucky and find that all 10 of them have the same root issue for whatever it would be. But you can be also unlucky and you would end up with 10 different cases that have 10 different issues, which should honestly also-- - It's also a alarm, also a alarm. - And it's also a red flag, for sure. - Now, one of the parts that you can do the sampling based on would be the cluster, which we mentioned and discussed a few minutes ago, where you exactly create these different groups that have different parameters from each other so that you would be more or less certain that if you analyze one from one group and the other from the other group, they would very likely, or with some likelihood, have different root cause for them ending up being paid like, right? So this is another way on how to do that. And the way on how you decide about sampling, there's really a lot of deciding that needs to go into it and that would be, for me, first and foremost, would be the resources you have. And if you have 300,000 paid late invoices, then you cannot sample them all. It's just not human impossible. And that's also the reason why you implement technology like process mining in the first place. You don't want to spend time with analyzing one by one. So the resources and the amount of time definitely place role here. - Yeah, but at the end of the day, it doesn't really stop you or it prevent you. It's more encouraging you to looking into the system, right? It can highlight and we can cluster and show some problematic ones and group them, but you still need to do the like work of actually looking into the system, figuring out what happened and trying to get to the bottom of the actual cause of this problematic invoice that were, and for accounts payable anyway. So the problematic invoice that you're attracting, right? You just need to look. - Yeah, and again, if you do the clustering, maybe you want to focus more on the sampling of the groups that are biggest insights because those would very likely have common denominator of the issue. So this is something where you want to focus your time on, rather than on this one outlier that will probably never happen again. And even with sampling, there will be a lot of issues and errors again. It's a statistical method that has its shortcomings because you will not be able to sample everything and you can even have some selection bias when you basically select cases which are not representative there. You are assuming that you are using or inspecting the correct ones. If you do the random sampling, then there will be just some random variation and you never know if you'll tackle the correct one. So again, the larger and the more statistical, you are about selecting your sample to analyze. You are probably minimizing the error, but it's never zero. - Yeah, for sure. I mean, you will never get them all. But I mean, this human component, the selection bias, can also work positively, right? Especially if you're like a subject matter expert and you've been working in the field forever, you already have some sort of inkling, some sort of idea of what, which types of invoices are causing issues, which type of payment terms, whatever, right? There's probably some intuition because in your experience, you have come across a lot of this, right? So then you can use this type of thing to actually validate what you've been thinking all along or you might actually see, okay, what I thought was an issue, only really affects like three invoices a year and this isn't actually a big problem that you've had. But the intuition, this human bias, can also lead you to getting to your answers faster, right? - Yeah, but be careful about, again, about humans and about their feelings because people are also biased. And actually, when I was researching this as episode as a part of preparation, I came over to something that's called a German tank problem. And it's a real page on Wikipedia. And it actually, it was, yeah, it was actually in World War II where the allies wanted to estimate how many tanks the Germany was creating or producing so that they would know what are they really fighting against. And there is actually statistics behind it on how they were calculating it via statistics, which they were using the production numbers of the tanks to estimate what is roughly the monthly production of these tanks and the intelligence. So those would be the people who are, you know, undercover and who are gathering information were also estimating. And just, just here an interesting number in June 1941, and I'm just, I just opened the Wikipedia page of this. The statistical estimate had 244 as a production. The intelligence was saying 1500, 50. And the actual production was 271. So the statistical estimate was just much, much closer to the actual production than what intelligence. And those are the smartest people that are, that should know the best have estimated. And again, that's just to keep it in mind that even people can be biased. And they will probably, there are so many biases that we are facing on everyday basis. You will probably, if I'm going to ask you what is the reason behind line payments and you just deal with some problem last week, you will be very likely inclined to tell me, yeah, this is the biggest problem because it cost you the biggest, the biggest. - The biggest problem I've seen, the biggest escalation. - Even called, it's even called, "treasoncy bias." And it's a real thing because just human behavior and human mind works in a mysterious way. And that's why relying on data can be, at certain times, just more reliable. - Oh, 100% agreed. I mean, this is the important step that you should check your hypotheses, right? And even if you are, everyone is biased, right? So if you say, okay, this type of invoice that I just dealt with last week, the biggest pain, I'm gonna have a look and see the impact of it actually, right? That's a great thing. You can just go and look and you can just look into the system, see, okay, and there's so and so many of these invoices every year, how much of a problem is this actually contributing to me, right? And maybe you will then find out that, okay, it's a pain, but it's actually not that big of a deal, right? Maybe to you, but not to the business, right? - Yeah, yeah. - Well, so that's basically the sampling and then you finally get into investigation. And this is the sweet part where a poor analyst, such as ourselves, is a little helpless in helping you because if we are external consultants, we can't even access the systems. We don't know the processes. We don't know the systems usually at all. And that's the place where you need to set or you need to put your people on investigation. And again, this can be a very lengthy process and I've seen in the past that even obtaining this right information in the cases that we're analyzing can be a very, very long. And in my view, that's already a symptom of a problem. If you cannot figure out why a certain, let's say, invoice, flu or float into the system the way it did, well, maybe it already somehow signals the issue. - Yeah, I mean, we also have a lot of conversations with IT, right, just to set everything up and all these things. And I mean, the amount of systems that are going on and talking with each other is in a lot of companies extremely, I mean, I'm sure from people listening, you can relate, there's probably multitudes of systems, different ways of inputting things. And there's this web, gooey and there's a whole bunch of things that are happening. And that all adds complexity, right? And sometimes having an overview of all that complexity contributes to one of these issues, right? - Yeah, yeah. Either way, investigation is a lengthy process, but there are a few tools or let's say approaches that you can utilize and have been utilized in the past in different businesses on how to get into the root goals or into the real problem of case by case. And here I want to give a shout out to Ricardo Enriquez who actually commented in the poll that I wrote on LinkedIn about how he is specifically using it with his company. And he gave me actually two ideas here and why. One is called five-wise. - And why? - Why? Because why? Did I say why? And why one more time? So it's five, there you go. - No, a five-wise is a method where you, if you have this case that you pick and you are analyzing it and trying to get to the root goals of why this case was paid late, for instance, you should ask five times why with each answer. So if I ask why is it paid late and you answer, well, the invoice was submitted late, you should again go to why because the late submission itself doesn't retell you much. It could be meaning a lot of things. So you ask why again and then maybe you say, oh, actually the baseline date for the due date calculation was wrong. So that's basically something that's set up in the system and when you have a payment term of 30 days, baseline date is a date from which the calculation actually starts. So if I have a first of June, the due date or the baseline date and have a payment term of 30 days, then I would need to pay on first of July in 30 days from now. So then the second why? - And then, guess what? We're going to be asking why again. - And then you ask why is the baseline date wrong? And maybe you say, okay, the baseline then is wrong because it was written manually because it was scanned. So that's the second answer. Why was it written manually? So you say there was an issue with an OCR system, which is optical character recognition. So basically a scanner that gives you that takes the invoice into an electronic form and fills in these fields in SAP. Then you ask, why was it scanned with an OCR system? And you say, well, because the invoice came behind an incorrect channel and should not have been scanned in the first place, right? We have scanning system only for externalities. And then you're already at five, but you will ask one more time. So it's even six wise. Why was it submitted via incorrect channel? And you say, well, because the vendor is in compliance. And there you go. - So this really shows it's not limited to why, right? To the five, right? So you can ask why until you get to the crux of the problem. - Exactly. I was very surprised how simple it actually is. - Yeah, you know that stereotype that children will constantly ask you why, why is that? Well, why is this? Why does, right, turns out they had a bright idea all along. - Ah, that's very interesting. - But anyway, I don't know any me alone. It's not my fault. - But it's really, so like one of the things here that we need to keep in mind is when we use this type of approach asking why and why did this happen and why did this? Well, it's because this person did that, right? It can start to devolve into a finger pointing exercise really quickly, right? And that's one of the things that you should definitely avoid when doing so is that it's not about blame, right? This isn't about trying to pinpoint an issue or some sort of late payment and make it the fault of somebody else, right? That's not the point of this exercise. The point is to figure out what happened, who did what, and how we can improve in future. So this situation doesn't happen, right? So when addressing these types of issues and addressing the root cause, people are sensitive, right? Or it's important to approach this in a constructive way, right? - Yeah, but it's also about your company's approach towards problems and philosophy. They, you know, issues and problems and mistakes occur. It's about how you deal with them and eventually prevent them in the future. I like having an open minded approach to this, you know, it's natural. Let's learn from this. Let's fix it and let's not look at who's fault is it because it could be anyone's. - Yeah, and in the, in the example that you provided when the last, why or the answer to the last, why question was because somebody didn't know about what correct channel they should put in. Well, then the obvious thing to do is, okay, let's ask that person who didn't know and how we can help them figure out the better channel, right? Like, is it a problem of onboarding, training, documentation, who knows what it is? But like, they can help them figure out what the problem is, why they were led astray or didn't do the right thing. And together with this person, then you can figure out how to do it better. - Yeah, yeah. You can even find out that they just were locked out of their e-account and they couldn't log in into the platform to post or submit the invoices in line. And therefore just set out screw it. I'm not going to deal with this. Just by sending them physically and they need it to be scanned. There can be so many things. - So many things. - And that's why this is a lengthy exercise. And it shouldn't be just, you shouldn't just say, oh, whatever, it's just this small subset because what you're going to find out is that you have thousands of these small subsets where these smaller issues are occurring and ultimately you want to straighten them and get them to run right. - Yeah, and I mean, this is like some of the things that, you know, where the process mining starts to lose a little bit of its potency, right? Because the actual doings of the people, you know, like you said, they were locked out of their e-account or something and they weren't able to post and all these things that are floating around around your process, around your process steps. - Well, you're not tracking that, right? And the software doesn't have access to any of that information, right? You can't just say, well, yeah, Mark forgot his thing at home and had to drive back and was late and missed the meeting. So no one tracks this, right? So the tool cannot give you access to this sort of information, right? - My dog ate the invoice. (laughing) I could have submitted it. You know, I spit on the number and now the eight looks like zero, so the scanning system, you know, it just submitted it wrong. - The amount of times I've seen a process explorer with the step dog ate invoice. It's way too many. - Yeah, way too many. But that's also the fun part, but challenging part to be honest and then between two process steps in the process is a room for a lot of things. Especially if you see that from creating the invoice until submission of the invoice, you have two months, you wouldn't even know what was happening for two months. And I've seen a customer where they were dealing with the invoices being submitted to some actual person's emails. And if the person doesn't act on an email, you know, vendor could have posted the invoice whenever they wanted it to, but that doesn't really solve the issue because the person maybe then forgot to submit it into the system. Maybe the person was on vacation. And then there is just a lot of things and then maybe the question you should ask why are the invoices submitted into their mailboxes in the first place? Why is it in the centralized way on how to collect these invoices? - Yeah, exactly. And then it becomes another one of those, okay, in order to not do that, we need to set up a new system and then talk about it. - Yeah, yeah. Nobody wants it, obviously. - Nobody wants to do that because it just triggers against so much work. And that's when they are starting questioning about how did this technology actually help us when it didn't solve our problem. And again, we get to the bottom of it. It's rather analytical tool than let's solve your problems kind of a tool. - Yeah, I mean, it's the x-ray of your business, right? And in that, you might find a lot of stuff that is concerning. It's like opening the closet and all the skeletons come tumbling out. But you probably didn't want to see those skeletons in the first place, but now they're here. And now you need to clean them up, right? And that's a pain. But people choose process money to make their processes more efficient or help them do so. And now, there's, like you said, there's no free lunch. And someone has to do the legwork and actually push this improvement. - Yeah, well, I like to skip the leg day. (laughing) No, just kidding. Another tool that can help you with tackling this problem, I'm not gonna go into the depth, but it's called Ishikava Diagram. If you wanna call it under different name, English name would be a fishbone diagram or it's very similar to five wise, except you also cluster the ways on what can impact your process into people, method, measurement, machine, environment, and materials. And then are asking a more targeted question about these areas, such as, why did our scanning machine didn't capture the zero correctly and it's candidate S8, which resulted in an issue? That's a machine problem. If you would be asking a people problem, it would be why David didn't submit the invoice when it arrived or when it was received to his email in time by the vendor. And then you are clustering these problems a bit more focused and you can really understand what causes are causing a certain effect. - Yeah, and that's, and in the email example, it doesn't just have to be a person problem. It can be a combination of a whole bunch like this could be a person, a material and equipment problem at the same time. - Exactly, exactly. - Right, and then you probably start understanding more of these problems. Here, one bigger recommendation would be to track all of it, even if it happened only once. First of all, you don't know how in, to what quality you did the clustering and sampling, so you could be just disolving this problem by not tackling it because you say, oh, I only saw it once, but it doesn't mean that it doesn't occur in the data again. So track a backlog of items and issues that you observed. And then you have to get into the solutioning mode. And I don't want to go into the solutioning mode today because again-- - You don't have time. - Yes, very practical. We don't have time to do that. But there's also so many ways on how you can go into solution mode and it can go into process redesign. It can be education, the different way of usage, certain tools or certain processes, automation, improvement of processes, just a lot of different ways that you can go from this place where you find a root cause. And it can be challenging and it can be like a thing. And the worst thing about all of this is that even if you go into solutioning mode and you fix this problem, it might even happen that it doesn't fix the issue, which can be very disheartening and it is what it is because causation or correlation doesn't mean the causation and just because there is a problem with this one part where the vendors are submitting late and you fix this issue, maybe you will not see an improvement in the data. And it's even something that it's recognized in academia and there are actually two papers that go into the topic of this. So if you are interested in reading up on this, one is called root cause analysis and process mining with probabilistic temporal logic and it's by Greg Van Hal, Denouard the Bear, Neelos Martin and Carlos Mosquerra. And the second one which I found was called even-- no, sorry. It's called root cause analysis and process mining using structural equation models by Manhas Sadat Guafare and Vilphan that asked which you probably already know. And yeah, the take from this is that even when you think you get it right, things might not improve, which again is something, it's again this whole that you might get yourself into but you have to believe that in what you're doing by trusting the process, you're actually doing it right. - Yeah, I mean, this is the systematic way of going through it and sometimes issues are kind of like whack 'em all. You fix one issue but something else pops up or that's why one of those things like tracking issues are so important that even if it happens once, when you start fixing things, that number might increase because there's different ways of doing things now and that sort of issue that you'd notice before starts sprouting up again because that's all of a sudden the new hot thing to do. So it's important, but it's important also not to get discouraged when figuring out that the thing that you've been working on doesn't actually improve or even worse makes everything worse. - You don't want that, you don't want that. - No, no, no, but it's important, you know, because at the end of the day improvement happens but it takes time. - Yeah, either way, you need to try things, you need to get into the bottom of the issues and without trying something first, you will not even fail and you simply have to do something. And then as you learn, you will start understanding the patterns, you will start getting better at this exercise and you will do it faster and faster with every iteration you do this. And I think that's itself is creating this eagerness, this process-centric mindset where you want to improve at all costs and you will do everything possible in achieving that goal and to ultimately improve. - Yeah, like the great Wayne Gretzky said, you miss a hundred percent of the shots you don't take. - True. - I hope that was Wayne Gretzky. - Yeah. - I'm just a tribute, I miss them. - Could have been anyone really. (laughing) - Yeah, either way, you know, stick with it, it's really, it can get complex, it can get lengthy, but I think the reward is really, really worth it. And, you know, know that everybody is facing the same challenges and it's just not easy because if it was easy, everybody would be efficient. Everyone's process would be perfect and that's simply not the case. And not even technology has evolved as much to instantly pinpoint one specific problem that's occurring anywhere in the process that's very often even outside of the technical scope of the system or technical interface of the system that you can't even find it in the data. And that's why you simply won't get by without a proper root cause analysis. - Yeah, as much as I wish that our process, my tools had a fixed my problem button. They, as of now, still don't. And so the work still needs to be done. - Yeah. Well, and that was our pretty long actually rambling about root cause analysis. Can't wait to go to do some root cause analysis right now, Patrick. - I know, you have a meeting coming up. - Yeah. (laughing) - Yeah. So I hope you liked the episode. If you did, and even if you didn't just leave us a review, hopefully a good one, you can all have. - If you have any thoughts about root cause analysis and would like to share them, please reach out and we'd love to talk to you. Maybe your experiences were exactly what we just said or completely different. - Yeah. - Important to let us know, we'd love to talk to you. - Yeah. And don't forget about the mugs. - Exactly the mugs. They're most important. - Yeah. - Mugs. - In order to cause analysis, who cares? - Before you talk about root cause analysis, get a mug and send it to us. - We can do it like conditionally. So we can get us a mug and then we can talk about root cause analysis. - Exactly, exactly. - I hope this is not like, was it called a bribe or something. (laughing) - Nah. - Nah. (laughing) - Well, anyway, yeah, if you have any questions, just reach out to us on LinkedIn. We are pretty active there or on our email, [email protected]. And as usual, we will be looking forward to talking to you in two weeks time with yet another episode of mining your business podcast. Patrick, thank you and everyone else. Thank you as well. Bye bye. (upbeat music) (upbeat music)