How can a process model capture “reality” from event log? There is a strong relationship between process model and event log, and to describe this, we use the term by David Harel, Play in, Play out, and Replay.
Play out is the classical use of process models, which is generating behaviors according to a given Petri net. After “playing a token game” numbers of times, it generates something looking like the table below.
The goal of Play out is to act out an operational processes using executable model (given Petri net). For example, from below Petri net, we know <a, f, h> is inexecutable. Workflow engine is one of the “Play-out engines” that controls the flow only allowed by the model.
Simulation tools also use Play-out model in order to conduct experiment and collect statistics and confidence intervals. Simulation engine is very similar to workflow engine; the difference is that simulation engine interacts with the modeled environment whereas a workflow engine deals with a real environment.
Play-In is a complete opposite of Play-Out, often referred to as Inference. Instead of taking process model and generating an event log, it examines and takes behaviors as an input and construct a process model. By using Play-In, the above Petri net can be generated from the event log above.
One of the example of Play-In techniques are α-algorithm, which I will explain later in another post.
Most data mining techniques use Play-In, however, traditional data mining does not concern about process models. Their typical examples of models are Decision Trees and Association Rules. It is not possible to use standard data mining techniques for Play-In model in Process Mining, and it is only recent that we were able to use event logs to discover process models.
Replay literally re-plays the event log on top of the process model, using both an event log and a process model as input. There are difference purposes why process model is replayed.
- Conformance Checking:
- to detect discrepancies between between the event log and the process model.
- Extending the Model with Frequencies and Temporal Information:
- discover bottlenecks by seeing which parts of the model were visited frequently. For an example, in an event log <a2, b4, c60, d61>, we know that c was enabled at time 4 and executed at time 60. Therefore, enabling c was the bottleneck in this example.
- Constructive Predictive Models:
- one can build predictive models by replaying event logs multiple times
- Operational Support:
- replay is not only limited to historic event data but also traces of cases still running.
- if it detects deviations at run time that doesn’t fit to the process model, the alert can be generated before the task is completed.
- similarly, it’s also possible to detect the remaining time for the process or likelihood of the case being rejected.
study resource: Process Mining by Wil M.P. van der Aalst
Process Mining 