00:00

Patrick:

Welcome back to the Mining Your Business podcast. The show all about process mining, data science, and advanced business analytics. I am Patrick and as always with me, my colleague Jakub. Hi Jakub.

00:12

Jakub:

Hey, Patrick.

00:14

Patrick:

Today's topic. P2P purchase to pay. What is it? What is the process mining side, and KPIs and use cases. All of that coming up next.

00:34

Jakub:

Well, Patrick, today we have on our agenda purchaste to pay process, which is I think, pretty exciting because myself, I have actually implemented a couple of purchase to pay processes in recent months.

00:46

Patrick:

Yeah.

00:47

Jakub:

Recently, with some of very exciting customers of ours. So where do we actually start? I think we can start as usually is with our favorite coffee bean, which we already referenced a couple of times before but probably this time we won't be looking at the coffee bean itself, but rather at the coffee bean factory. So first of all, we will probably obviously need to explain what such a purchase to pay process is.

01:14

Patrick:

Yeah, exactly. So shall we get right into it with the example of the coffee bean in mind? You are a coffee bean manufacturer. You harvest the coffee beans and send them off to your customers. So you obviously need to purchase things in order to do said job. You need to buy harvesters to harvest the coffee beans. You need to buy the packages in order to package your coffee beans. You need to get labels. You need a service to actually market your stuff. And these are all purchases that you as a company will have to do.

01:49

Jakub:

Exactly. And it doesn't really end there. There's so much more. There is fertilizer. There is probably something like, you know, you need to harvest the crop somehow. So they harvester as you mentioned, but even like security equipment for your employees so that they are safe while doing the work. So there's just so much to do. And therefore, like as every purchase to pay process, you start with a certain need in mind.

02:19

Patrick:

Yeah. So the need can arise from the actual sales order. So say if you're just buying coffee beans to then sell them in that example, but also production requirements. So like we mentioned, for example, the coffee bean harvester or the materials for your labels and things like that. Including R&D. So say somebody in your company thinks they can come up with a better way to package your coffee beans, but they need specific material to do that which isn't on the market. So you need to go find a vendor that produces that special equipment for you.

02:58

Jakub:

Exactly. Or just internally, you can have employees who work in the office do with the office job, and they just need more markers, they need more paper, they need more pens, and daily equipment and they need tables to work on. And everything like this is a simple need for a company. That company needs to buy, purchase and essentially begin its purchase, which actually leads us to the next step, which is the offer, right?

03:26

Patrick:

Yeah, exactly. So obviously the purchasing department gets the need from from its employees say we need this, we need X, we need Y, we need whatever else. So they are tasked, of course, with finding the things the company needs. So what they will do is have a list of vendors where they can go from and there they can check prices. Negotiate payment terms. And negotiate the delivery schedules when you need to be at what location. And all of those things are then agreed in the contracts.

04:02

Jakub:

Exactly. And this already gets us already to some of the first pain points of a purchase to pay process. As there are many organizations that do have a set of contracts in place, but either use them sporadically or not very well, not very efficient or even nice in some cases where a customer has a contract in place or many contracts with the same vendor actually with different payment terms. And there is what is happening is that they are using less profitable payment terms for themselves rather than using the better ones. So let's say that they would need they would appreciate having the cash on hand for a longer time. But what they do is actually they use the less efficient purchase payment term for them and that means that they have to pay earlier. So those are some of the bottlenecks that you can already see. And that's just a contract phase.

04:55

Patrick:

Yeah, for sure. For sure. Much, much improvement in this regard and I'm sure we're going to get into that later on. Next up, of course, is then once those contracts are agreed, we then move on to the actual order. The actual purchase order is created and sent to the vendor. And there we can, of course, have the acknowledgment of that the purchase order was received and then of course the dunning activities and so on and so forth.

05:24

Jakub:

Yeah, this is basically the moment when you throw the ball or leave the ball at your vendors site of the of the pitch, meaning that the moment that he receives your purchase order, he has to start working on the delivery itself. So this is somehow when your knowledge of the process is somehow blurry, because you can't really know what the vendor is doing in the meanwhile. What you can still do is that, you know, when they're actually deliver something or if it's if they are late is it on time and also obviously you can track and you can know what the quality of this delivery is. So let's say that you order I don't know, 50 or 50,000 packages for your coffee that you really want to or you really need to ship as soon as possible and you will give him 30 days to deliver. So what happens in the meanwhile he delivers after 35 days, which is the first problem. It's a late delivery for you. That can cause quite a big problem because then the whole chain reaction triggers because of this late delivery from your vendor. And then the next thing is that you received the shipment and you were looking or you're counting the number of the packages that you received and you find out oh I only have 40,000 but I requested 50,000. So basically your vendor under delivered under shipped 10,000 deliveries.

06:55

Patrick:

Yeah, that is obviously a big headache and the activities that happen in this phase are very, very crucial in determining the overall health of your purchasing and also kind of lets you gauge just how good your vendors are because if you have a vendor that constantly offends the contracts agreed beforehand, delivers late, deliveries too little or too many and doesn't send the invoices out in time. You know, these are all things that you can kind of gauge and see the health of your vendors.

07:33

Jakub:

Or maybe you actually find out that the ball is on your side of the field and you find out that you are making the mistakes, meaning that you change the PO after it has been already sent to the vendor. That means that you will realize, oh, I actually need 60,000 packages rather than 50,000, and then the vendor is confused, the message itself doesn't reach them in time and then he still delivers the original amount. So these are all the things that you can actually obtain when you successfully implement the P2P, purchase to pay process.

08:10

Patrick:

Well, once you actually have received your goods, we get to the delivery side of it. The shipment comes in to your your warehouse and now you need to actually check it, right? You need to inspect it, you need to check that the quantity is correct, that the quality is not damaged. So in our coffee bean example, if the labels came out wrong and they spelt the company name wrong for the labels that you ordered. These are obviously things that need to be checked as soon as you get your package.

08:41

Jakub:

Yeah, absolutely. And then what actually happens is that with the package, you also receive invoice. And this is another step where so much can go wrong. So first of all, the invoices can be all mixed up. You can, for instance, get goods and on the invoice, something completely different stands. You can have the quantities incorrect. You can have the material numbers incorrect and all these kind of things that are, you know, if it can happen, it will happen and such. And what you can do with process mining is actual look at the steps and compare what you actually order, what has been in the contract, what you order, with what you actually received and what you also have on paper, in print and what in terms of what you received. You can then compare it and actually see, oh, this is actually a problem or this is actually working very well. And then what happens is that you can rate the vendors in sense of how they're performing.

09:43

Patrick:

Yeah. It should also be noted that there can be another issue just based a little bit of warehouse management, that the items, the materials are in your warehouse. It's just that nobody has scanned them in yet. So that can obviously lead to you receiving an invoice for materials that are in your warehouse, but you just don't know about it. Obviously, you don't want to pay for materials that you don't have yet, so you block the invoice and that can lead to confusion, can lead to delays, can lead to lost cash discounts and what have you. So another thing to keep a mind of.

10:17

Jakub:

Yeah, as we usually say, what can happen will happen. So be ready for the worst case scenarios for sure.

10:23

Patrick:

Of course.

10:24

Jakub:

And yeah, the last step actually in this purchase to pay process is the moment when you have the invoice and when you actually put it into your accounting. Because as we know, purchase to pay can be very easily transferred into accounts payable, meaning that from the moment you actually receive the goods and you receive the invoice, you are starting looking at the accounting part of your company. So the first step is actually that you have the invoice and that you send it to accounting. That usually means that you change the identifier and everything. And there is another step for potential problems that some incorrect things are happening. So this is something that also needs to be very careful and some approval steps needs to be in place for this.

11:10

Patrick:

Yeah. I mean, and this can also add to the processing time of these invoices is critical in optimizing your cash flow. If you do take cash discounts or not, all depends on how quickly you process all this information. So how quickly you can process your three way checks and so on and so forth can determine if you obtain the cash discount or not.

11:34

Jakub:

Yeah. And not to mention that you don't want to pay for something that you actually didn't order or you don't want to pay incorrect amounts and so on. Cash flow is the king.

11:47

Patrick:

Yeah, exactly. But assuming that all these things are checked and are optimal for you and you can pay, then obviously the last step of this is actually releasing the payment for this. And the invoice should be settled.

12:03

Jakub:

And then there's definitely a lot that can go in accounting, but I think we will leave it for another episode where we dig a bit deeper into the accounts payable.

12:12

Patrick:

Of course, yeah. So now that we have talked a little bit about the P2P process as a whole, I think it makes sense to now talk about P2P and process mining in that way.

12:25

Jakub:

Absolutely.

12:26

Patrick:

All right. So starting off, what's the data that we need? Jakub, You've implement these recently. What's the type of data that you do, what's the case?

12:38

Jakub:

So just to say a case in process mining terminology is a unique identifier for whatever you're following. So if we are talking about purchase to pay process, what we will be interested is the purchase order item. So you will have a document, the purchase order, and there you will have multiple different items, one or many, doesn't really matter. And for you, the unique identifier, which all the actions is tied to is the item. This could be again, explained on the coffee, on the coffee itself. So imagine that you are actually selling the coffee. So your purchase order, so the header document would be the package with the coffee itself and the item would be the single bean. The same happens in here because the items are very often treated somehow differently than the header itself. And you can also change stuff on the item level rather than only in the header level. So what we are looking here as our unique ID is the purchase order item and then all the activities and everything that happens in the process needs to be somehow tied in our terminology joint to the PO item.

13:58

Patrick:

Setting the case as the item has its advantages because it has the a more granular activity table can be built because several items in one purchase order can undergo several individual steps. And in order to actually gain insight into these individual steps the item must be taken rather than the header.

14:26

Jakub:

Of course, but if we are then talking about process mining in a higher level, then obviously we don't always have items. We can just look at some cases as a document number or something like that. So we definitely this is a very specific purchase to pay in SAP, so this probably needs to be mentioned. And so once we have the ID, what we are really looking into is whatever information we can gather from the source system in this in this case, we are really talking about the SAP, and then we are looking at different kinds of information we can pull together from that. So that would be, for instance, the changes that are happening on the purchase or item level or even purchase order header level because there can be changes too. What we are then doing is creating something called event log, meaning that we define the activities that we want to see in the first purchase to pay process, so we will be looking at a purchase requisition creation. And essentially what we are doing is that we know where the purchase requisitions are and we know what the link between the purchase order item and its requisition is. And then what we do, we just join them together. They are specific foreign key relationship, which we know and we get. We can define such an activity and we can provide it in the event log which means that eventually the end user knows and sees the activities that are really tight and bind it to this specific PO item.

16:01

Patrick:

So if we have the relationship between the purchase order and the purchase requisition, we're able to tell how long did it take, for example, when that requisition was created to when it actually turned into a purchase order item. Right.

16:17

Jakub:

Yeah. Because imagine that you have essentially two different tables. You have one table or one dataset where you have the purchase requisitions and one dataset where you have the purchase orders. What you do is that you link them together because there is a link and we know the link. But this can also be on the invoice level, it can be on the goods receipt level. And that obviously requires certain knowledge of the underlying data. But providing you have the knowledge, then you can always link it back to the original case. Which in this case is purchase order item, and you can obtain different kinds of information for that specific item that you are looking for. So in case of purchase requisitions, you know now what the purchase requisition relates to your purchase order item and you can then for instance say, oh, but there were also changes in this purchase requisition. There are also releases or refusals of the purchase requisitions, and you suddenly know that your purchase order item is influenced by these things that happen before or after.

17:21

Patrick:

Yeah. So you were saying that we can combine the purchase order of the purchase requisition and then obtain the status of the purchase requisition and tie that to the activities of the purchase order item.

17:33

Jakub:

Exactly. And this is how process mining really works.

17:37

Patrick:

So once we have, for example, the purchase requisition, are there some activities where the relationship to the purchase order item are not as clear cut?

17:48

Jakub:

Yeah, there definitely are. And sometimes this gets a little murky and tricky. So the business understanding of purchase to pay process is sometimes like end to end. So you have a purchase order or you have some need and you go all the way to accounting and you still want to see what happens on the accounting level. However, there are obviously some problems with this approach because if we are really talking about a purchase order item at certain point, what happens is that when you are also looking on the invoices, you get M to N relationship, which Patrick, I think you can explain to us.

18:30

Patrick:

Yes. So when you have a m:n relationship in one table, you will have several items referencing to an indefinite amount of items in another table and also vice versa. Hence, there will not be one purchase requisition item that links to one purchase order item, but that's for example, several purchase requisition items leads to one purchase order item and vice versa, meaning that the relationship is not 1:n or n:1, but rather m:n, meaning that you cannot define the clear link between them. This can obviously lead to some pain points in our data models and in our joints and whatnot.

19:19

Jakub:

Yeah, this typically happens in purchase to pay process in the invoices. So you remember the case I was saying that you order 50,000 cases for your coffee beans and only 40,000 are delivered. So you have an invoice for 40,000 cases, but the PO is still open because you still didn't get what you ordered and it is very likely that you either get in touch with the vendor and have it delivered later. The point is that you might actually receive a second shipment or maybe even more shipments and that every shipment you get results in new invoices. The problem is that the invoices that the vendors are creating not always need to be linked only to one invoice in your accounting because then let's say in the accounting, what you do is create invoices and in these invoices you can link multiple different vendor invoices or vendor documents. And there that is what you are saying, that then we are getting into a bit murky relationships where one PO are multiple POs can be cleared with multiple different invoices.

20:31

Patrick:

Yeah, right. So that's where the m:n relationship comes from. Multiple purchase order items can link to several invoice items, right?

20:39

Jakub:

Exactly.

20:40

Patrick:

Yeah, exactly. So following up, we have kind of spoken a little bit now about the process mining aspect. What are some of the relevant KPIs that our clients like to see when we implement this stuff for them?

20:57

Jakub:

So the classic KPIs that we always start with is like the high level accounts. So you are always interested in the overall numbers, let's say split per monthly basis or so, like how many POs you've created, how many purchase requisitions you have. And not only that, then what is the second most important, second most interesting on the high level KPI is the total amount, so that you have a clear idea that the data that you are looking at, you know what you're looking at. So that if we are working as a data scientist, the first problem or the first challenge that we usually face is to persuade our clients and make sure that the clients trust the data. And so the overall numbers and sums over certain periods usually help us give them this kind of trust and then they are comfortable working with it. So these are the first KPIs. But what next comes up to my mind is the automation rate, for instance, in Celonis as a process mining tool, it's very easy to actually see what are the automation rates for a given activity.

22:15

Patrick:

And so why are automation rates important?

22:19

Jakub:

Well, as we know, automation is coming and the better the automation the less touches you have to do in your process manually, the more time you save and the more efficient you are. Because if you have a purchase order, say that you want to have it done as quick as possible, then every manual touch necessarily leads to to some loss. It could be money, it could be manpower, it could be time, it could be really anything. So the goal of a lot of corporations is to optimize their processes in a way that most activities that can happen automatically actually are happening automatically.

23:08

Patrick:

Right. So that we all know that it'd be amazing if we had one purchase order from one purchase requisition. There are no changes. The vendor delivers on time, gives you the invoice. You can pay it with a nice cash discount, and that's the end of it. Well, we all know that isn't really what the real world in most cases looks like. So I guess the key is to find the activities that are related to the changes to the purchase order item and kind of automate them as much as possible. Is that right?

23:40

Jakub:

Yeah, exactly.

23:42

Patrick:

Okay, good. So we have our KPIs and we have our process, we have our data. And so now how does a company, when looking at the implementation in, for example, Celonis, how do they measure how well their purchasing process is working?

24:03

Jakub:

Well, this is a million dollar question really, because there are so many angles from which you can look at the purchase to pay process and honestly, every company has a bit different sets of criteria and a bit different interests and also different priorities. So usually what you can do quite straightforward with process mining in place is that you finally know how long all the action takes. So basically from the moment you create a requisition for a certain need in your company for those packages, until the moment you have received everything and you have got the invoice and that your accounting actually processes and clear the invoice, meaning that they paid by the vendor. And once you have the process mining in place, this is actually the I think for a lot of companies, this is the first time they can have a very, very clear picture on this and it doesn't end there, because sometimes different departments or different teams are interested in a different sub process of this whole purchase to pay. So imagine that the accounting probably doesn't really care about what's happening in the procurement because it's not really their job and they don't really care what happens until the moment that the vendor creates invoice and actually the invoice is entered into SAP or into the source system. And from there actually what happens that you can look at certain sub process. So you will be probably measuring a bit different throughput times between different activities than you would be measuring if you are in procurement and you're looking at the delivery times of the vendors.

25:46

Patrick:

Right, right, exactly. And then also on the other side of that, not just the procurement side, you also have the accounting side, which would then be a sub process, which we know as the accounts payable.

26:00

Jakub:

It is a good idea to split them, for sure.

26:02

Patrick:

Yeah. It depends on just how granular you want to see the process because there's a lot of activities in these, but kind of putting them all into the same process can get a little bit opaque.

26:19

Jakub:

It's absolutely true.

26:21

Patrick:

I mean, you have implemented both and what was the result?

26:25

Jakub:

Well, let's just say that it's much easier to split it than to put it all in one because then you just lose some functionality that otherwise you would have if you have it split, which is the typical example of multiple invoices for one PO and the moment you get into this point, it gets tricky.

26:41

Patrick:

Yeah, of course, because the accounting department obviously wants to follow the exact journeys of their invoices and the procurement wants to obviously know when goods were delivered. And so the point between them can get a little fuzzy in that regard in setting the relationships correctly can get a little fuzzy.

27:02

Jakub:

Exactly. Well, there are some other use cases that we actually have in purchase to pay, Patrick.

27:09

Patrick:

Oh yeah? Let's hear about them then. The first one you've already kind of touched on a little bit is a vendor delivery times, right? So just kind of knowing which vendor is delivering your stuff on time in good condition and can give you the invoice and give you accurate delivery documents. Obviously, those are signs of a good vendor that you would like to do more business with in the future.

27:34

Jakub:

Yeah, and that can be also tricky because as I think I already mentioned it, these deliveries can be changed from both parties. So imagine that you as a customer of your vendor, you change the desired the delivery date. So suddenly the vendor is not supposed to deliver on 10th of May, but you say it's okay to deliver a little later, so you suddenly change your delivery by one week and you want the delivery on 17th of May. And the same thing can also happen the other way around. So if you have a production planning, then you really need to know when your vendor is delivering whatever you ordered and if such a vendor, let's say, changes its confirmed delivery date also, then it can present some serious risks for your production, although obviously everybody's aware of that. So there usually is some storage, some things in store for things that something could go wrong. But sometimes simply you really need your vendor to be on time.

28:41

Patrick:

Yeah, for sure. Just to, to satisfy, especially in production, having your material in the specific time when the things are supposed to be produced so you can satisfy your own sales order, are very crucial. Running out of material is never a good thing that you want to discover on production day.

29:00

Jakub:

Yeah. I mean, you don't want to lose your coffee, do you.

29:04

Patrick:

No, of course not. Of course not.

29:06

Jakub:

Imagine the impact it would have on the company, haha.

29:14

Patrick:

Haha, absolutely. Productivity would fall to an all time low.

29:16

Jakub:

Yeah, totally. Totally. Right. What else we have here is actually an interesting use case called segregation of duties. So in segregation of duties also so-called SoD, what you are doing is that you are looking at different activities. So, for instance, creation of purchase requisition and approval or releasing of purchase requisition and ideally, these two things should be done by two different people, two different parties. That's hence the word, segregation of duties. Meaning that one person, one user doesn't do two things that he shouldn't be allowed to do at the same time. And again, with process mining, when you are looking at different activities, what you can do is compare the two to each other, to a set, to a specific case, in this case, a purchase order item. And you can see if and whether and how often this actually happens. So you have some strict rules and you can enforce them. But let's say somebody breaks them, violates the rules, and then you suddenly see that this risk was realized and you can essentially immediately interfere or first find out and then actually interfere with when this happens and prevent them in the future.

30:43

Patrick:

So what you're saying is that with process mining, we can see these activities taking place in real time. And then before the purchase orders then carried out, say, the segregation of duties was not adhered to, so that you can actively get email notifications or put automatic purchase order item blocks on these things so that this actually doesn't get realized.

31:08

Jakub:

Well, the real time will be a wishful thinking with at least most customers. We are at best dealing with it like a couple of times a day. So that means that there are definitely certain technical limitations in place. That means that you cannot simply or we are still not there to have a real time data from SAP. You still have to somehow extract the data to the cloud that we are using with most of our customers. And then eventually also run your logic and your queries. Then that all requires the time. And although there is certain improvement in place happening as we speak, it's still more on like a daily basis. But it's still very it's still usually sufficient because especially when we are looking at about the beginning of purchase order, the odds are that not all the action happens within the same day. So if you see that on the on the yesterday, someone who created the purchase requisition also approved it himself or herself and is actually violating your policies, then you can instantly have a notification from within Celonis that, we have basically two scenarios, either you notify a responsible person who can look into this case and either cancel it or block it, or you can even create an action that this action, the blockage of such purchase requisition happen on itself.

32:40

Patrick:

Oh wow, that's immensely useful. Especially if you want to dial back on these on these bad activities and bad behaviour.

32:48

Jakub:

Yeah, Because those can easily result in fraud, in the worst case scenario.

32:55

Patrick:

Yeah. I guess if we're talking about bad behavior, we should also mention maverick buying.

33:02

Jakub:

Yep.

33:04

Patrick:

Maverick buying in itself is when the buying behavior of your company doesn't adhere to predefined contracts with your vendors. So say you have a vendor of laptops and you have a contract with them with the payment terms, the delivery schedules and so on and so forth. And then somebody or some department buys some laptops in some other condition that are actually worse than you already negotiated with that vendor. Obviously, this is not very good because you lose out on savings and deliveries and what have you. So Maverick buying is when some user, some department doesn't adhere to the predefined purchasing guidelines. What we can do with process mining is see these little characteristics of a purchase order item that don't seem like they adhered to the guidelines because the material or the payment terms for this aren't right, there was no purchase requisition and things like that. And with that one, before it gets even approved, we can then send a notification with the action engine that you mentioned beforehand, right?

34:18

Jakub:

Yeah, exactly. Basically, an action engine is a feature that Celonis as a process mining tool enables us to use, that what you do is define when something clearly happens and then you define activity that should happen when such a thing occurs. So as you were saying, Patrick, when maverick buying is detected, then you can send an email to a user with a list of such maverick buying. You can also write back to SAP to actually prevent such action, but then it should be taken with care and it should be very well back tested because writing back into the source system is always tricky and needs to be handled with care, but it just gives you such a big power in your hands because you can use it for so many things. You can use it for, let's say not only when something happens, but if something doesn't happen. So imagine our classic scenario would be in purchasing to process when you have to pay your vendor. Right. So you have the payment terms and you already have the invoice in your system and the invoice is open, which means that you have not cleared it yet, which means that you haven't paid it yet. So what can happen is that since you have the payment term and you roughly know or you will actually not roughly, but you know exactly when you should pay it, let's say that you know that the day of payment is today and in process mining and Celonis itself. What you can really do is that you can essentially send a list of all the invoices that need to be paid that day to whoever is responsible for this. So this can then result in a lower rate of late payments, it can also result in a better vendor relationship because you pay the vendor in time, which is always a desired behavior. And most of all, it also results to, you know, that you could miss some open items that should be cleared manually or something. Somebody forgot to do that. And then those items could just hang in there forever, for ages.

36:28

Patrick:

Yeah. And it's also it goes also further than that. It's not just the open items that need to be paid, but we can also analyze payments based on the history of the purchasing behavior of your company, knowing that even if you have five days to pay this this invoice based on the material, the amount and things like that, you need to pay within two days. Otherwise, historically, you will miss it by the deadline. So you can kind of already analyze your past behavior and kind of adjust the payment behavior, how you want to pay in future so that these things don't even happen.

37:05

Jakub:

And this is where the big buzzwords actually come into play. And that's actually the usage of data science and actually machine learning, because you can then really look and compare the data from very different angles and with a certain probability predict some occurrences for some scenarios for the users. So this is really, really cool. And very exciting actually.

37:32

Patrick:

Yeah, exactly. In terms of use cases, what other things are important?

37:42

Jakub:

Three way match, I think. We already mentioned three way match to a certain degree. So in three way match, what you want is to have a match between your purchase order, between the goods receipt and between the invoice receipt. Obviously, we can also look at four way match or even at I think even a five way match where you can also add into the combination, the purchase requisition and then eventually even the accounting document. And then you just compare those five activities and look whether all the, let's say, item that you ordered and all the amounts are actually matching to your order.

38:18

Patrick:

The things you pay for, right?

38:19

Jakub:

Yeah. Good. I think we covered the use cases quite well. I don't, I don't have anything else that we could at this moment mention.

38:32

Patrick:

There's a few more I'm sure that we could talk about, but, you know, we'd be here all day.

38:36

Jakub:

So true. True. Since we are again running out of time, which meant I think we're going to have to go a bit longer with our podcast in the future because those 45 minutes seems to run past so quickly.

38:49

Patrick:

Yeah, they do. They really do. So let's just kind of run through what we see as typical bottlenecks in a P2P.

38:58

Jakub:

Yeah, I couldn't start with anything else than with changes. Like anything that changes in the process is usually undesired. Although, I'm saying usually because sometimes a change is desired. Meaning that, for instance, when you order something and your salesperson is able to get you a better price, then you change the price to lower. That's actually probably a desired behavior. But usually, generally speaking, changes result in slower processing times and in longer throughput times. So generally it's this desire to get rid of at least all the manual changes and set the rules. And set the process in a way that it's as automated as possible.

39:49

Patrick:

Are there some types of changes in this P2P process that are worse than others?

39:55

Jakub:

Well, it really depends from what perspective you're looking at it. So if I start at the beginning, when you actually send the PO to your vendor, anything that happens after you send the PO to the vendor is usually a bad change because you don't have the PO within your company anymore. You already released it and it can result in poor performance in both terms of delivery and also the invoices.

40:26

Patrick:

So that the vendor actually refuses your purchase order, right?

40:30

Jakub:

Could be, definitely.

40:33

Patrick:

Because they don't have the materials anymore. It was outdated and things like that, right?

40:37

Jakub:

Yeah, of course. Of course. So, I mean, it's still good to change a PO before you send it out. It doesn't hurt the vendor at all. But after you send out the PO, it's really not a good practice to change anything. So in process mining, you can directly see if you define a change activity that are not desired, you can look if something is actually happening after certain steps. So let's say, you know, when you send a bill to vendor and then you, you just look at the cases and the PO items when the PO was sent to the vendor and after that it was changed and you I think you could find quite interesting cases or quite interesting overview of the poor performance compared to when this doesn't occur.

41:26

Patrick:

So you're saying so there's a direct relationship between them?

41:30

Jakub:

Oh, I'm not saying it, I think it could be. It doesn't always need to be, but I think it is expected that you would do these changes, of course. And this is a question that well implemented process should actually answer.

41:46

Patrick:

So with with our dashboards, we can look at these, these KPIs and say in the times when the purchase order item was changed, after it was sent to the vendor, we had a lost cash discount of this and this much. Right. Those things don't seem related, but it is shown in your KPIs. So that is obviously kind of a smell test of an offending process.

42:15

Jakub:

Totally. I think that should more or less cover what we've actually wanted to talk about. And this is a well implemented purchase to pay process from end to end. And as you can see, there is so much so many directions you could go with this. And obviously the more you use than the process mining tool for such a process, the more possibilities you'll see. You also usually don't end up with only purchase to pay process because suddenly you also see that you could implement the quotation process, which for some companies is also quite vital and they want to have a bigger clarity on the process, on the process itself. And that means that at some point you will start adding different modules and different intermediate steps of what is happening. Right. And this again gets you deeper and deeper into the process and the deeper and deeper you get the better understanding you actually have on the high level, but also on the lower level of what is actually happening. And this is this is amazing. Really.

43:24

Patrick:

I'm sure that the clients that you've implemented this with have a lot of ideas about where do you want to go in and future with these analyses.

43:32

Jakub:

Oh, yeah. Oh, yeah.

43:34

Patrick:

So does it make sense to still touch on action engines a little bit?

43:48

Jakub:

Well, I think we kind of structured already. So as we said, so with each tangible action that you can take or you think you could take from a finding in the process, it is very likely that you would be able to create a certain action engine. Patrick, can you explain us what an action engine is?

44:00

Patrick:

Yes. So what you can do is define yourself an activity, a flow of activities, undesired behaviour in your process. And then determine that to be undesirable, then take out the source data and kind of give an idea of these invoices. For example, these purchase order items, these purchase requisitions have the defined undesired behaviour and somebody should check if this is true, why is why this is the case, if it should be blocked, if the purchase order should be redone properly and so on and so forth. You can kind of have some tangible action behind the analysis that you have. So say you have some defined KPI of like these maverick characteristics of what my what my company defines as maverick buying. They don't have the right payment terms or so on and so forth. And from that in the data, we can see, hey these are the ones that this applies to. These can then be sent as an action signal to the relevant users who can then go check and say, Yes, this is right, this is an instance of maverick buying and we should not be doing this, and there you can kind of not just have the analysis of the maverick buying, but also have some tangible action associated with it, which delivers a lot of real time benefits in that way.

45:32

Jakub:

Yeah. And it takes in a completely new level because suddenly you are not just reactive looking at the reports and trying to with some explorative approach, find further use cases yourself, but you already have defined what you are really, really interested in and what they really should be improved. And then you just have the reports deliver the data to you on the time you actually want them to. So actually, when you implement these notifications you kind of make Celonis as this process mining tool, some kind of addictive social media platform just like Facebook or something, because you keep getting this push notifications every morning before you even start working. And you were already angry with the people who cause these problems for you and you are starting to send an angry email, so take it easy, but you see that there is some potential for this.

46:27

Patrick:

Oh yeah. Obviously these are just pain points that instead of seeing on some report that says that 10% of our purchase orders were a result of Maverick buying. You can actually do something about it. Dealing with these instances of Maverick buying, which can be a pain but also necessary and wanting to produce them efficiently.

46:47

Jakub:

You know, the change always hurts, but it's better to change and adapt, rather than not to change at all.

46:52

Patrick:

Exactly.

46:54

Jakub:

Okay. Patrick, is it a wrap for today then?

46:56

Patrick:

I think it is, yes.

46:59

Jakub:

All right.

47:00

Patrick:

Do you want to mention your blog post? I think you wrote a blog post about exactly this topic.

47:04

Jakub:

I did. Admittedly, it's not as deep as today's conversation, so you can still go on our website and in our blog section, you can find a purchase to pay process article. But admittedly, I think you will be better off listening to this. But either way, we are very grateful for your time and decision that you made time to listen to our podcast today and Patrick, I'll be looking forward to the next episode together.

47:32

Patrick:

Yeah, absolutely. Until then, Jakub, bye bye.