Supercharging Your Process Mining with Python

Welcome back to the "Mining Your Business" podcast, show all about process mining data science and advanced business analytics. Today, we will be talking about Python. And if you're a snake enthusiast, I will have to disappoint you. It is unfortunately not about the Burmese or a reticulated Python, but about the programming language Python. Jakub, how are you and how are your Python skills? - I'm good, Patrick, but my Python skills are pretty bad. - Good to know. We will focus today on how we can leverage Python to enhance our process mining implementations and produce deeper and more informed analytics for the end users. Let's get into it. (upbeat music) - I will start this episode with a disclaimer. We will be talking about programming language Python. However, please take with us because it's not going to be technical. It's really going to be about how we are utilizing Python as a programming language in our line of work in relationship with process mining. So we will talk about a lot of interesting use cases and a lot of real life application in our daily line of work. So stick with us, I think it's going to be fun. And to put this episode into a context, Patrick's already laughing. - You made it sound so dry. - Well, I hope you're still listening, but I will probably get even drier right now because I'll start with some numbers. And Python is getting really popular. And it's actually in 2022, both in Europe and US, the most in-demand programming language, at least has been in 2022. I can probably see that this trend is not going to change in 2023. And out of all the programming scripting and markup languages, it's actually number four behind JavaScript HTML and SQL. So something that's really useful, a really in-demand, and we can confirm that working with Python is finding way even in our work. And I mean, Patrick can probably tell you more than anyone that I know what Python is. - Hi, praise, hi, praise Jacob. Yeah, so I guess we should start off with the basic question. What is Python, right? Because people throw it around, don't really know what it is. So let's talk about what Python really is at its core. It is a high-level interpretive programming language. The use cases for it are insanely vast. Python has a vast array of built-in libraries that basically cover the most basic functions like making requests to something, or any type of file format that you have, Python hasn't covered. So it finds its way in a lot of different sectors of IT, really, in scientific computing, in web development. That's a big one. And probably the most important one for us. And also what it's mostly used for data analysis, right? Credibly easy to get started with some really basic tools to start analyzing quite a big load of data very easily. So that's usually why it's where it's deployed, especially in our industries. Would you agree that if you had someone to choose a programming language to begin with, let's say that you are at a high school and you want to start coding, maybe even earlier, would Python, at least from your perspective, be the language of choice? It kind of depends. So it kind of depends on what this person should be able to do by the end. Python in itself is, I wouldn't say, awkward or quirky in how it's written, it's just vastly different from a lot of more standard programming languages like Java. Java is more object-oriented, right? You make objects that have dedicated types and all these things. And you need to tell the programming language what exactly it needs to be where. But Python is a little bit more loose. It doesn't really care that much. The only thing you really need to care about is if you indent properly. And that it's fairly open. So-- Yeah, well, the only thing I care about is not to lose the person in this hunt for learning a coding language because a lot of people is just complaining how difficult it is and how incomprehensible this can get. And well, honestly, when I was studying in university, the first coding language, well, actually even before university, I think I worked with Delphi, which was horrible, honestly. And it didn't get better when I went to university and we started with Java. I really, really disliked that because you had to compile everything. And those error messages are still hunting me. I mean, that's very true. I mean, the barrier to entry for Python is very low compared to other programming languages, which is really good to see because it allows people that don't come from an IT background to get their footing and write basic functions and loops and all these things really, really quickly, which is good because a lot of people are getting into it and maybe finding that it is what they like. And the more people that are knowledgeable on programming languages and how to program stuff efficiently, the better everyone is. So from my point of view, I do take-- or I regard you as a very good coder, especially when it comes to Python. And I was wondering, where did you learn it? Honestly, this is something that I'm mostly self-taught. I mean, I basically went through some standard utiny courses or something just to figure out how the language worked. But the most of what I know is just tackling problems one after the other, having an issue and seeing if you can fix it with Python. I did this basically at every job. Can I use some sort of Python functionality to tackle this problem that I'm currently facing? And with this constant barrage of challenging myself with these things, that's basically how I built up my entire knowledge. So I would assume that if somebody asked you about where can I learn Python? And what should I do? Your answer would, therefore, be, find a problem that you really, really want to solve and just go do. Yeah, and the most important part is that you fail doing it. Because I mean, with the utiny courses and all these things, that's good and fine. But it's very much your own rails. You basically have a problem. This is how you solve it. And then you go to the next problem. But if you have your own problem that you create and that you want would like to solve, there are no rails. There is no predetermined instructions on how to get this done. Are basically left to your own devices and you need to go and figure it out. And then you go scour the web. You Google is your best friend. You Google literally everything you can. And then you will write code. It will break. It will fail. You're going to be frustrated. And then you're going to figure out why it doesn't work. And figuring out why things don't work is even better than figuring out why things work, right? To me, this is really a beauty of coding because it is sort of an art. You have no-- you mentioned rails. And that's so true because you can develop things in a way you want. You can be efficient, but you can also write a very, very shitty code that just doesn't run at all. Depending on your experience and your skills and also on the way that you want the code to run in the first place. So it's very, very flexible. And that's not only Python, obviously. It's almost any coding in how you design things to run. And I think it's beautiful. However, I said that this will be more focused on the use cases. And I'm sure that you are really excited to hear where we as a process are actually using Python. And well, you probably know it. We work a lot with the tools, Salonis. Surprise, surprise, right? We only talk about it almost in every episode. And so Patrick, can you tell us, where do we utilize Python in Salonis and in process planning in general? That's a big question, right? So I guess I will leave this in two places. One is more of the data analytics side. And one is really tackling manual jobs for us in our day to day that we use Python for it. Now, Salonis is a very good API. I would say that we can-- What is what is API? I'm glad you asked. An API is an application programming interface. I looked that up before and because I keep getting that going and running, but it's essentially a set of tools that you can use. Think of like a car, right? And when you step on the gas pedal, do you really care about the fuel intakes and how the pistons work back? And blah, no, you don't, right? So that logic of how the engine works and produces the wheels turning and all these things is abstracted to basically a gas pedal, right? So you, the user, all your interface, quote unquote, with this car is the pedal, the brake, and the steering wheel. That's basically your interface with the car. And you don't really need to care about the inner workings and all these things. So that's basically what you should think about when we talk about APIs with programming languages. It's like you can send an instruction to an API. And how it does whatever it needs to do is of none of your concern, right? Which is very nice for us because then we can have open APIs where applications can talk to each other usually on some sort of predetermined protocol or best practices, some standards, like rest APIs and things like that. So that applications can communicate efficiently with each other. So what you're saying, it means that we can actually use any Python integration. And by coding some handshake, basically, between the Python tool we have and cellonist, we can basically utilize the tool in any way that this cellonist API allows us to. Yeah, exactly. If you think about-- if you open up an application, for example, cellonist, and you click on any button, and that itself sends off some sort of request to an API. For example, you click on the data model button, and then it gives you a list of data models. Well, the server needed to figure out that you wanted to do that. So you pressing that button triggers the server or the application to give you a list of all those data models back. We can basically do the same thing with Python. We can trigger the same requests, and we will get the same response. We will say, give me a list of data models, and we'll return with some list of data models, except instead of visualizing it in the front end, we just have it somewhere in code. Yeah. So you basically have something like a unique ID of these objects that you're trying to tackle. And by coding this unique ID, which can be just a long string of numbers and letters, is referring exactly to this button that you want to press. And then you just say, OK, Python, please press this button. But since we want to automate some task, do also this and that in this order because it will save me 20 minutes of work. Exactly. So think about if you have some sort of transformation in the backend, you have some sort of table, for example, invoices or something, and you would like to now add a column to your extractions and put it into the analysis because some user wanted an extra column or an extra information in their analysis. Well, instead of going in and changing all your data sources and changing all your transformations and all these things, you can just write the instructions in Python, send it to every single one of your objects, where these things need to change. And then you can basically, if you program it well, hopefully, you can guarantee that there is no error-prone mistake that you left one of the source systems out or you that you misspelled one of the columns in one transformation or something. And it will automate all these things perfectly for you. So saving you a bunch of manual work and a lot of time. Would you have a few examples for us and for the listeners? What can we actually, and now let's be very seldom specific, what we can actually use it for? Yeah, so for example, one of the big things that we do is reducing the amount of columns in our implementation. A lot of the times, you know, we do have limited space in this application. We can't just pump in years and years of data without restrictions, because you know, there is some sort of space limit a lot of the times. And now, at some point, you know, that's how it starts. We load one year of data. We don't really care about what columns we use. And we just kind of load everything. But as you know, over time, this amount of data can keep growing, keeps growing, keeps growing. Until at some point, oops, we've reached our limit and we need to reduce. And the best question is, OK, how do we reduce? How do we best reduce, but still get the most value out of our analyses? Well, then we can come in with Python. Search through every single object that we can find inside the solenoid application, whether that be an analysis, whether that be an execution, like an action flow or skill, anything like that. Check for any type of reference to a column that we may be using, right, and saving that. And every single column that we're not using, we get rid of, right? So that way, we can ensure that we're reducing all the unnecessary columns that we're never, ever going to use in neither analysis nor anything else. And thereby saving a lot of space and maintaining. Basically, nothing will change for the front end user at all. We just have a lot more space. In the best case, the transformations even run faster because are tables that we're loading. Right, right. So you're basically optimizing the whole environment by just making some best practices and reducing the data sets and so on, which I think is great. And that actually also implies another usage, which I've also witnessed. And that's leveraging this technology and the coding in maintaining and growing large, or maintaining large platforms in general. Because once you start dealing with complex systems, and I'm talking about dozens of source systems and hundreds or maybe even thousands of transformations and reports, it's becoming darn difficult or plainly impossible to do it by a human being. Yeah, I mean, simple changes across multiple systems can take quite a while, right? Obviously, there's things like templates and all these things that will enable you to change things easier. However, there's still a lot of things that we just cannot automate or cannot solve with templates. So we have to use things like Python to do it for us. And yeah, also it will help you, I mean, with these growing environments, a lot of the stuff just gets left behind, right? A lot of the stuff is test code or something like that that gets run once and it's just left there, right? But you'll just overlook it at some point. The implementation will get so large, they will just accumulate a lot of trash that you then have to clean up and knowing what to clean up and that whatever you clean up won't break anything. That's where Python becomes really interesting. It actually brings me to the application side because what you were saying is something that we have done also for a couple of our implementations. And that's, by having these traces, by being able to kind of mine the tool with the data that it contains and be it about usage, be it about reports, you can combine these things and build something that I actually called a user adoption monitoring or actually a utilization of the tool in general. Because what you can then do, you can combine the locks about the usage, who logged into the system, what they did with it, what report they accessed, and you can basically pinpoint the most used reports, the least used reports, you can use to drive the adoption because then if you're running a center of excellence and somebody's in charge, you try to maximize the value of every use case, right? And by having this overview, you can see maybe two out of five teams are using these reports and getting incredible results, but three out of five are still not using it. Why is that the case? And this adoption view can really, really spark things. - Oh yeah, I mean, and that's exactly what the Python will be used for, right? It's getting that data, that usage data out of the tool and then transforming it into some sort of format that you can then analyze, right? And it will obviously show you some of the, like I guess things that you didn't really consider, maybe there's an analysis that you spent, I don't know, two weeks on building, but no one's using it, you know, that's a real shame, you know, because maybe the enablements are missing or maybe there's something else in the other reports that kind of does what you didn't hear and then you kind of need to reconcile these things with your user, right? So it can give you a lot of insight as to how your users are using the tools that you built. - Exactly, and this is becoming increasingly important with large implementations, once you start having multiple teams, or by the way, if you're a thing that, you know, you can always anonymize these things, you don't, you know, to be GDPR compliant, you don't have to see or point who is doing what, or rather the general overview of the usage of the tool. Another case we've had here and that's again, a little more technical is utilizing Python for building an extractor. And Patrick, since you did it a couple of times, can you tell us what it is? - Yeah, so like I was talking about with APIs, right? So applications and they will post some sort of, or will have some sort of API integrated, not all the time, but a lot of them do, which means we can get data in and out of them fairly easily. So, and one of the things that, you know, so loneliness and most other process mining tools like to do is ingest data from a lot of different multiple sources, right? Or any cloud solution as it is. - Oh yeah, absolutely, right? So that's true. So what we can do is we can build some sort of extraction mechanism that will then query some data, whether that be a rest API or any other type of API. Usually with a lot of, there are some open APIs, like the rest API that I was talking about, but there's also some pre-made APIs that are proprietary. Maybe some company has their own API, how you interact with it and they can then define it. Odds are that Python will support some sort of library that has that integrated or the company itself will release this library for you so you can use their tools with Python, which is, you know, the ubiquitousness of Python is one of the best parts about it. It's so highly adopted that a lot of companies are releasing libraries that make it easier to interact with their tools, right? So what we can do is extract data out of these tools and then transform it and put it in the right format and then use Solon as its own API to push that data into Solon as itself, right? - Yeah, yeah, so those are the use cases which you can leverage or, you know, the use cases that you can leverage when you work with the tool to make your work easier or to enhance the connectivity and basically solve a data pipeline problem or an automation or scaling issue, correct? And I think it's amazing. On the other side, and that's the core where Python really is the king, is the data analytical part, which basically means in Python, there's a lot of libraries you probably, you may be heard of something like pandas or numpy and so on, which help you work with large data sets and do all sorts of statistical, you know, tech-related for statistical perspective, you can run some algorithms on it, check it with some machine learning exercises and so on and do really, really cool with the data. And I'm very happy to say that we have developed a very advanced use case on this and by we, I mean, especially our advanced analytics team of Oksana Kostya, who's the head, or I mean, I would say, the main mastermind behind this and she did amazing works and almost, I think we've been developing it for over two years now. - Yeah, it's been a little thing in the making, yeah. - Yeah, so great job, Oksana, if you're listening to this, you did an amazing thing here and also got some support from Daniel Ashkoda, who helped at a time as well to bring it to the new level. Also, the team from Nikolas Milo and Alexander Terkic, who were supporting with the development and now also Kamar and Gelato, who's taking over some of these responsibilities. And this is our advanced analytics team and we've built something we called invoice duplicate checker. So what it really is is that in almost, well, in every organization, especially of the sizes that we work with where we are talking about the hundreds of thousands or even millions of invoices per year that are being processed and that you as an organization need to pay, there is a decent chance by some resources or by some investigations, it could be even up to point one of percentage of all the invoices that can be duplicates, that means that they can be paid twice or more than twice, which is a huge number because if you look at it from the value perspective, if you pay 10 billion euros and then what is it, a hundred million of this would be a duplicate payment that's ridiculous amount of money. - That is quite a chunk of money. Let's talk about a little bit why the, I mean, systems usually won't allow a duplicate invoice, right? Why is it such a big problem for machines or ERPs to detect these in the first place? - That's a great question. And if you look at the main ERP, which is SAP, what it does, it actually does have some basic incorporated duplicate payment prevention system, which means that it's scanning through a standard parameters and for invoices these parameters would be the vendor number, it would be the reference on the invoice, it could be the date, the amount and so on. And what it does is that it puts two invoices that are in the system and they are scanning for exact matches. That means that if you have an invoice for vendor 1, 2, 3, that's worth 20 euros and has the exact same reference, maybe your name, the system, the SAP will highlight it and says this invoice is here twice, they will block it and somebody a human being has to check it and eventually reverse it or cancel the invoice. And that's perfectly fine. And this is how things used to be executed up till now. However, now with the smart brains from process end, what you can do is, or what can happen is that you have these two invoices, but on one of these invoices the reference says Patrick Bogner and on the other invoices the reference is Patrick Bogner. So there's basically missing a K at the end. And what happens in this standard system is that for the system these are two different references, which are just lacking one letter in it. And it's basically impossible for it to pinpoint or to highlight it, to find these weird from this system perspective scenarios and therefore would allow this invoice to be posted. And if we are speaking about these huge quantities of invoices per year would eventually get paid as well. - Oh yeah, I mean, it should also be noted that a lot of these invoices are scanned via some sort of OCR or optical character recognition software where the invoice is just put in through some sort of scanner and this software will read the letters of what's actually printed on there. And if you think about it like a lowercase L and an uppercase I depending on the font will look exactly the same, right? So it can be a little bit tricky for these things to really determine what is being written here. We know the context of a lot of the names and so it will be easier for us to demonstrate or at least guess what letters being used but for a lot of these software, this is just something that they can oversee, right? And that's when these duplicates can also occur because you can scan the same thing twice and the software will basically determine these are two different documents. - Yeah, and there is even a few more of these cases, one of them or a few of them, I will name them, is for instance, you can have two invoices, both of them are posted on different vendor while this vendor is technically the same because you can have a mess in your master data and you will have a vendor called, I don't know, Škoda and then a vendor called Škoda Auto, basically the same company but you will have two same invoices that are basically posted twice. Another example, you will have some currency conversions. So you might have one invoice that's posted in euro and the other invoice that's posted in Swiss franc, the same invoice but with different amounts and again, the usual system will not catch it but with our solution you could say that by converting this into the same unit and then comparing the values and having there some buffer for error, let's say you have a percent of 1% which can be some currency conversion error, you can then highlight these invoices that are otherwise exactly the same and bring them together and identify them as potential applicants. - So Kim, can we talk about a little bit about why this is such a big problem for businesses? Why, like paying an invoice twice or sometimes even three times so that can happen? Why that is such a big problem? - Well, let me ask you Patrick this question. If your landlord sent you, oh, I'm not saying that landlords are sending invoices but if they did and they sent you three invoices for month of April, which is the month when we are recording and releasing this episode worth, I don't know, 1,000 euros. Would you be happy? - Absolutely not, of course not. - Of course not. You would be like, "Why the hell am I paying this for third time already? I already paid for it twice." And do you as an organization should have the exact same attitude? Why the hell should you pay for some goods twice or even more, especially if we are not talking about 1,000 euros but we can be talking about hundreds, maybe even millions of euros. And truth to be told, we have already implemented this use case with a few of our customers and the results we are getting from recovery, recovering these invoices and we can look at them historically, but we can also look at them, look at them before they get even paid because once the invoice is posted in the system, we can include it in the data sets that we are working with, basically cross checking it with every other invoice that has ever been posted, at least in the scope that we are working with. And we can even proactively alert the users that there is a high probability that with this invoice, this could be a duplicate payment, police act or inspect. And that's why we are doing this, really. - Yeah, because the amount of loss capital that you lose over the course of how many invoices that you've paid twice is huge, right? And so you can obviously get your money back from the vendor that you've sent the money to or at least they're supposed to send back money. So that's already huge, but preventing these things and this administration of getting all this money back is also a huge cost that you can reduce. So the benefits of detecting these as early as possible is crucial, which is why we have some sort of workflow attached to that that can illustrate kind of exactly what you pointed out that these are going to be problematic if you don't tackle this in the future. That's why getting this information to you quickly can be the difference between, okay, we have a two month headache now on our hands. - Yeah, and you can imagine that we are doing a lot of this with Python and there are some cavities to this as well, which make it even more interesting. For instance, what you can also see that some companies already have some sort of extra layer of checking for these problems. And obviously it makes total sense. It also depends when where these solutions developed and how accurate they are. And I've seen one example where a customer actually had a solution in place which was working just probably, I would say, pretty fine. I was compared to this. We had like 30% higher accuracy rate, which is good, but it's probably nothing that, you know, you would blown your heads off from. But there was this interesting finding which we had and that the odd solution has generated 10 to 15 times more potential-dapplicated groups than ours, which basically means that if you are the user and if you have per day have to come, you know, check 15 possible duplicates compared to one duplicate with the same, well, with basically the same overlap, meaning that we would capture all of these duplicates as well as the other tool, but with 15 times less work, it's incredible how much time you can even save by, you know, leveraging this other approach. - Yeah, I mean, that should be noted, right? So the performance of these algorithms is not just measured in how well does it identify duplicates, but how well, how good is it also in identifying or not identifying duplicates that aren't actually duplicates, that makes sense, right? So because you wouldn't want to say, "Hey, these two are duplicates." When they're actually not duplicates at all, right? - So it's basically measured with something we call a success ratio and well, so far. And it's amazing to see that we are somewhere between 5 and 20% of success, which is, if you have 20% success, that means that out of five recommendation, we give you for an invoice that should be checked for possible duplication, one actually is a duplication, which is great. And obviously, here's also a note you cannot be 100% accurate because there are no exceptions, which you can obviously code into the solution, but there are also things that just appear to be duplicate and no machine in the world could ever tell is this really duplicate or not. So you can get pretty high with these estimates, you can get pretty good with the success rate, but you can never get 100%. - Yeah, no, that's basically possible. I wish that were the case, that'd be great. However, I mean, the complex set of rules of the languages that we use, all the different variables that could be changing are so vast in the system that any type of progress we get to make from 20 to 21% that's already huge. - Let me rephrase, you can actually get 100%, but you have very strong rules, meaning that you might be checking for exactly only these exact matches. And then you have a tool that is checking for this, and it says, I have 100% accuracy, and then you have our tool, it says it's 20% accuracy, but what our does is it brings you way, way more true positives, which is, I think, really, really worth it. And based on this experience, we thought, you know, it's what you are doing. You are actually feeding this data into Python, and you are doing some clean-text matches, meaning that you are trying to get rid of these lower uppercases and spaces and so on. Try to compare text one against each other. You are then also teaching the data model, and that's actually the implication or implementation of machine learning in the back, because what you do have is that you have a knowledge model behind all of this, where you are training, let's say, a mirror model, where you are giving it the knowledge about what invoices are actually duplicated and whatnot, and then you can even improve the estimation that you make over time. And, you know, while we deployed all of this, we thought where else could we actually utilize it? And we are currently almost at the end to have development of something we call the master data checker, which works very similarly, except of invoices and payments. We are looking at what are you keeping in your master data tables? And that would be vendors, partners, customers. And we are, again, searching for potential duplicates by looking and screening through the addresses, by looking at the text numbers. And these type of information where you might find out that you have unnecessarily, or you are unnecessarily maintaining multiple vendors in the system, which can ultimately lead among other things to duplicate payments. - Oh, okay, yeah, I mean, that's true. I mean, we can also look at differences in payment terms, for example. So we have separate customers or whatever, and, or the same customer just in the system five times, because people have added it at different spellings, or they thought it was under a different company name, or something like that. And then once it goes to, okay, this customer wants to buy something, which customer do we pick? And then that the credit limit for that customer is super out data, the payment terms are super out data and all these things. So you could be using very outdated and not very, let's say suitable payment terms and things like that for this specific order. And until you catch it and change it and all these things, again, a lot of administration and overhead, and can also lead to a delay for the customer until you figure this out. - Yeah. Well, ultimately, once we basically brought this use case into a very good shape, and now, you know, it's really, really well established. We wanted to approach these invoices in accounts payable also from other perspective. And we developed another tool, and again, that's another utilization of Python here, and that's something we call anomaly detection. In a very, very easy way and in nutshell, what anomaly detection means is that we take a large amount of invoices, and we are looking for deviations. Because deviations can be, you know, harmless, but they can also be harmful because what could be happening is that there is some sort of fraud. There is an OCR or manual error while you are posting, or you simply have incorrect or incomplete invoices in the system. Either way, it's something that if you are an advanced organization, and you want to be a data driven organization, it's something that you might want to be checking. The goal for this is, again, to reduce some risk of cash loss, but you can also improve the transparency, because if you are doing something that's maybe not compliant, you want to be aware of it, and even probably support your audit, internal audit, or external audit with some cross-check of your system. - Yeah, and it should also be noted, it's good to know these things in hindsight, right? That, okay, we had this in this much fraud, and this in this much loss, blah, blah, blah. But it's even better to detect it as it's happening, right? And that's exactly what these models are great for, where they will look at a specific invoice, and look at all the attributes associated with it, like vendors posting hours and all these things, and can basically, through the machine learning model, we'll be able to say this is going to be an anomaly, and you should have a look at it. And we can do it as soon as the invoice is posted into the system, right? So that's when we can grab the data, use the model to look at this invoice and all the associated documents, and detect if this is an anomaly or not. - Yeah, and if I rip it up to the Python perspective again, what we really do is that we push a lot of invoices into Python environment, where we can work with these large data sets, and we deploy some standard, I would say, cleaning of the text so that they are as standardized as possible. And then we are checking for, let's say, rare combinations by applying very standard statistical methods, such as looking at some interquartile distribution or range, or applying on normal distributions, which is something that everyone who studies statistics probably know of and is aware of, and is relatively simple, but bringing such a vast amount of data from these ERP systems is not as simple as just applying a standard distribution, right? - Of course, and that's the beauty of the solutions that we make, is that we pull things out of the system really quickly, we analyze them and push them right back so that the user, who, I mean, having things in Python and having an output in Python is good and fine, but of course you want somebody with the background and the authority to actually be able to do something about it, and the way you give it to them is the same tool where they can read about all the other invoices in the press money context, right? So that's the great thing about working in the machine learning workbench, in as alone as or any type of really workbench with Python, is that you can take data out, transform it, and push it back, very easily into whatever tool you want, and illustrate it to the end user, right? - Exactly. - So in an essence, what we do, we basically extract the data, we run it through some algorithms, through some checks, through some statistics, and push it back to users with added value that they wouldn't have without it, and to be specific with these anomaly checks, what we, for instance, do is that we are looking for unusually high amount postings per user or per company code, and example, if you have a user that should be only able to post invoices worth maximum, let's say, 5,000 euros, but suddenly there is an anomaly of posting of 500,000 euros. You probably wouldn't notice this or find this if you weren't specifically targeting this. However, with this sort of approach of looking at it from this perspective and doing this normal distribution, you could instantly visualize it for basically any user in the system, and then we can calculate the probability of something being really an alarming anomaly, and something being just something unusual, but not really a problem. And by, again, learning or teaching the data model that performs these checks, you can then enhance it over time and create even better success rate with these approaches. And I think it's just, it's just amazing. Yeah, that is really quite the beauty of using these machine learning models is that the more you use them, and basically, for example, the duplicate and check or write, if you mark things as this is a duplicate, this is not a duplicate, this is a duplicate, and so on and so forth, all this information is being then fed back into the model to train it further, so it can more accurately depending on the selections that you've made and not recommend you these duplicates in the future if they weren't any more focus on the ones that you did identify as duplicates, right? - First one. - We have another use case, which we again utilize a machine learning algorithm, I can't even pronounce it, I can't damn it. It is a tough word. - Yeah, machine learning is this. - Yeah, machine learning algorithm, thank you. So again, when we say machine learning, we always have a Python behind that, because you have to execute it somewhere. And what we do and what the use case is called, it's a delivery-delete predictions. In a very simple words, what it means is that we look at the historical data of your deliveries in your supply chain. So when you, for instance, order something, you want to know when it's going to be delivered, because based on the delivery, you either you have your goods that you want it, but you can also order goods that you need for production, or maybe you are some sort of redistribution partner and you then are selling the goods forward. So you need to know when the stuff that you ordered is going to be delivered. Obviously, vendors are going to give you some data or some estimations. And if you are knowledgeable of SAP, you always have these fields that are called estimated time of revival, you have the predicted delivery rate, you have something called statistical delivery date, and so on so forth. These fields tend to change quite a bit, especially when vendors are not very accurate with giving predictions in the first place, which is, I guess, especially in this time of age of interrupted supply chains and global issues, be it war, be it coronavirus, is a problem. But you are an organization and you still need to sell stuff to earn money and to function. So by having constantly changing estimated time of arrival of your goods by the vendor will probably cost you quite a headache. So what we do is that we take this information, look at all these historical data that we have in the system and basically have an algorithm, a gradient boosting, which is, I'm not going to get into it because I don't even understand it that well, that it's basically taking all these inputs and creating a self-learning model that is giving, I would say, more accurate prediction, which were collected based on the historical reality of, how did this vendor, for instance, perform over time, especially compared to actual delivery and estimated delivery, which is a big thing? Yeah, and also, I mean, it takes all the other context into account, the time of year, or the quantities that you're buying from this vendor, and all other tiny little attributes, some that you may not think matter in this process can actually really determine when you're actually going to get your goods. And for you is, of course, as you said, incredibly important, because if you have a bottleneck because one of your vendors didn't send you your screws on time and your production lines are down, waiting for something, you know, that's horrible, that's a worse case scenario, right? Yeah. So having some sort of more accurate, rather than just vendor saying, yeah, I'm going to give it to you then, you can then use this model to give you a more accurate, or maybe a more true to life number. You know, it should be said that we can't predict things like the one of the ships stuck in the Suez Canal, right? So, you know, I thought we can. Yeah, unfortunately, it's not like a glass ball and can determine everything in the world, but at least in how do we put this in such turbulent times, like a standard of operating type of, you know, like you said, without coronavirus and when war and things like that, you should give you a more accurate number in the end. What I specifically like about this use case, though, is that you don't truly need to interact with it. You can use it strictly for analytical purposes, but because what you do is that you have it run as a standard report and what you get is you get the analytics on how the machine learning model predicted these deliveries and how is it predicting for the future? And you can see the statistics, the success rate historically. So you can sort of build up the trust for this algorithm over time. And when you see that it has 98 or 99% of accuracy while the vendors that are giving you these estimates have 70% of accuracy, then you would be a fool not trying to incorporate these estimates at least to an extent for the most problematic vendors into your daily line of work. Yeah, because I mean, what a lot of these ERP systems will do is it will look at some of these markers like the planned delivery days or like the time it takes to get a specific material, right? There's there will be markers that will tell you in days, hours or whatever, how long it's going to get you to get these goods. However, these can be changed, depending on whoever put this in, right? So what can happen is that when you plan to build something and the machine system looks through the entire data to figure out when you can potentially start production of some sort, it will look at these inputs, for example, material A requires one day of delivery. And it will say, okay, well, based on that, I can start production tomorrow because I'll have it by tomorrow. However, if we actually look at the historical data, it actually takes more like three days, right? So it's crucial that your system is fed with as accurate as information as possible so that when you do the planning, it's based on more real data and more real estimates so that you can plan better, right? If you actually knew that it took three days instead of one, your planning will probably look a little bit different. Yeah. So that has to do with the replenish times, right? Both, actually. Both. Yeah. Yeah. Well, so there you see it. Patrick, you have any other idea where we could actually go and use this capability that Python provides you with. And again, we didn't mention Python thorough, this discussion a lot, but none of these things would be possible to do in an Excel or in simple SQL, which is, you know, the language that you use to command in a database because what you need to do, you need to actually apply a mathematical models or some statistical approaches in order to operationalize these ideas that are behind this. And only Python may be R, which is similar language to Python could do that. Yeah. And that is one of the great things about Python is, like I've said before, there's a lot of input, a third party libraries and packages that you can install that will get you most of the way there, right? So most machine learning libraries like PyTorch and TensorFlow and all these things are pre-built, right? Because a lot of smart people have already written a lot of the theoretical and actual real functions that that will generate these outputs that we can use, right? So we don't have to reinvent the wheel every single time we want to implement one of these algorithms. We just have to use the right package, the right library, use it in the right way, train it in the right way. So that's where the knowledge comes in, right? But a lot of this stuff is already pre-written. And that's only because Python is such a vibrant language with a lot of contributions and ever updating packages getting smarter and better. And that's why we can do what we can do. You might even be asking, how does this, what does it have to do with process mining? And to an extent, you would be asking a right question because some of these things could co-exist next to a process mining initiative as a sole or standalone analytical platform. You can analyze invoices even without looking into processes. However, what I always say and counter this question is with the mindset of looking into process is slightly different. And if you already have the process related data, such as you can see when an invoice was reversed or if there was something suspicious already at the beginning of the process, with the delivery times, you are not only taking the data about the estimations. You may also be looking at some distribution over purchase orders and so on. So you are really looking back and forth. So at the end of the process, also at the beginning of the process. And these are all the data points that you can enrich your data sets with and ultimately come with a slightly better prediction. And slightly better prediction in these volumes can mean hundreds or millions of euros. Yeah, exactly. So if we talk about a concrete example that I've seen is let's look at a manufacturer that we have a customer order to fulfill some sort of material. However, we noticed through the process, okay, we've missed the delivery time to our customer. Right? And then we can go back, well, why is that? Okay, well, production was moved around a few times or was replanted a bunch of times. Then we can ask, well, why is that? And it could be because all the inputted materials that we need to actually do the production through the bill of materials and every subsequent half material that we need to produce this product. We can, for example, have a look at this delayed delivery. It could be that the, what we thought would be delivered shortly was actually has a very, very different actual delivery time that we can predict with our with our late delivery. And this can be like for 10% of all the materials that we need as input, these deliveries are late, right? So that can point you to, okay, well, this input or this difference, this discrepancy and how long this takes can probably lead to that we planted wrong or by when we thought we had the materials, they weren't there. So we needed to replant the production, right? So these can help you identify the root causes of what is slowing down your process. Yeah. Well, when I was planning this episode, I was thinking, well, let's go for 30 minutes, let's see how it goes. We are almost at an hour again, which by the way, I love. You could probably feel how excited we got. And just by recording this episode, I got a few more ideas. Yeah, same. Let's talk after this, okay? However, I also wanted to ask you, dear listeners, if you have any ideas or any applications where you on your process mining or you know, business process management, or even data analytical journey have applied these methods are leveraged by them to your, to your advantage. I would be really curious to hear that because what we just did here, we gave out a lot of ideas, which will eventually you can even approach us to discuss with us or you can try and implement their own. Good luck with that. I'm sure a lot of you can do that. I'm sure. There's a lot of smart cookies listening to this podcast. I tell you that. We are just excited and proud that we have managed to do this and a lot of people, especially students, are very often asking questions. Why am I learning these things? And what is the use case for it? Where am I ever going to use it? And well, here, we just told you a few examples where you would find a perfect utilization of this because everybody wants to do machine learning and AI, but it's such a vague term that imagining where you apply this can be very, very tricky. Yeah, absolutely. So this is one of those things, like we said, when you want to learn something, having a course and all these things on machine learning, everyone's super eager. I want to do this. I want to use a deep neural net to figure out. But until you're faced with an actual problem, and I mean a lot of the problems that you will at least get to know in learning about these things have somewhat of a use case, but they've been done so often that doesn't really make sense. So being faced with an actual problem that isn't pre-written for you and needing to figure out all the tools that are available in Python and just generally machine learning and all these things, and using them accurately to tackle the problem in the best way. That's the real challenge, right? And that's where the learning curve dramatically increases. And we're not even talking about then putting different tools next to each other where you can just use a little bit of analytical approach, then you just use Python and then create an automation with an RPA to tackle this. And then you're just putting these things together, and it's just beautiful. Either way, Patrick, thank you for a very pleasant talk and discussion on Python. I would have never thought that I would enjoy talking about coding as much as I did. Well, I didn't mention Lambda Functions, so consider yourself sticky. I'll just keep this for yourself. Nobody wants to hear that. Yeah, I know. I know. I tried. Do you, dear listeners, I thank because it's very amazing to see how many of you are listening to this and how much interesting responses we are getting to it. And I'm also very happy to see that it's bringing you value, be it from us talking about comparing BI and process mining based on our still short experience in the field or talking about Python, or just bringing some of the very entertaining and knowledgeable guests, be it representatives of companies or researchers. I'm just genuinely happy that we can help you on this journey and that you can feel that you're not on your own on this. So if you have anything that you would like us to cover in the future and a topic and recommendations, just reach out to us on mining your business podcast at gmail.com or just contact us directly via LinkedIn. Patrick and last words. I know. I'm just happy that I finally got to talk a little bit about the Python and all the cool things that we do. So maybe not Lambda Functions, but maybe one day. Maybe one day. Let's do it the hundredth episode. And I'm special from Patrick, Lambda Functions. Like, let's go for an hour. Oh, yeah. No, no, three hours minimum. Three hours minimum. All right. So thank you very much and we will be looking forward to talking to you in two weeks time with another episode of mining your business. And it will be a good one because we will play a bit. Bye bye.