Alpha miner in ProM

Hi, welcome back. In this lecture, I will show you how the alpha miner can be executed in ProM and what the results are on several event logs. So we’re still in the process discovery bridge between the observed data and discovering a process model but now with the alpha miner in ProM. So in the previous lecture, I’ve shown you that this is the Petri net that we expect from the alpha miner, given that it discovers this footprint matrix given the input data. And I’ve also shown you that this process model is not sound and that it has perfect replay fitness but could be improved a little bit on precision generalization and simplicity.

So let’s see, if we give this data to the alpha miner in ProM, whether it results in the same Petri net. So let’s import the loan example with the five traces that we’ve seen before.

So let’s press the Play button and select the alpha miner, which is actually on the top of the list, and let’s start. So you have two options. One is which alpha miner version you want to use. But let’s stick with the core alpha miner for now. And if you press Finish, you get exactly the process model as we’ve seen before in the lecture. So there are three parallel branches, but the accept and reject activities only consume two out of the three tokens, hence leaving one behind, resulting in a model that’s not sound. So let’s give the alpha miner the full, loan process event log. Let’s open it. We select it and we again run the alpha miner.

Now you see a very similar process, but the accept and reject transitions actually have three incoming arrows. Hence, they consume all of the three tokens and this process model is actually sound. But let’s see how the process– but let’s see how the alpha miner does on a real event log. So let’s import the BPI challenge 2012 event log. And let’s run the alpha miner on this event log. So what you see is spaghetti. So this is what we mean with spaghetti. You see a lot of arcs crossing and you cannot really understand what the process is.

Furthermore, if you zoom in– for instance, here, you can zoom in– and you look at these activities, on the bottom on the left, you have some activities that are not connected. Since they are not depending on input tokens, they can fire whenever they want. Hence, these activities are always enabled, resulting in an imprecise process model. Also here for instance you have an activity that has many inputs. And here, you have many, many crossing arcs. So although I didn’t check, I can safely assume that this process model is not sound. It’s certainly imprecise and probably also not able to replay all the observed behavior, mainly because of many issues with the simplistic nature of the alpha miner.

So let’s clear our workspace and draw some conclusions. So we just applied the alpha miner in ProM on several event logs. And we can conclude that the alpha miner has some issues. So the first issue is, as we’ve already seen in the previous lecture, that it does not guarantee soundness. So it can produce process models that are not sound. Secondly, it includes all the behavior. It does not filter out any noise. So everything that is observed is included in the Petri net. And therefore, it’s usually not applicable to real life event logs because real life event logs always have particular traces that can be considered as noise. Thirdly, it has issues dealing with loops.

So if a particular activity repeats itself, BBB, or if you have two activities that repeated itself, B and a C, again BCB, the alpha miner has issues detecting this. As a fourth issue, it cannot discover long term dependencies. So if a choice early on in the process somehow influences choices made later on in the process, the alpha miner cannot really detect this. Therefore, other algorithms have been created that are able to discover the process model using event logs that build on the ideas of the alpha miner and we will look at some in coming lectures. So I hope to see you again soon where we discover all the process discovery algorithms.