Page 30 -

12 1 Introduction

to the handling of requests for compensation. Each line presents one event. Note
that events are already grouped per case. Case 1 has five associated events. The first
event of Case 1 is the execution of activity register request by Pete on December
30th, 2010. Table 1.1 also shows a unique id for this event: 35654423. This is merely
used for the identification of the event, e.g., to distinguish it from event 35654483
that also corresponds to the execution of activity register request (first event of sec-
ond case). Table 1.1 shows a date and a timestamp for each event. In some event
logs, this information is more coarse-grained and only a date or partial ordering of
events is given. In other logs, there may be more elaborate timing information also
showing when the activity was started, when it was completed, and sometimes even
when it was offered to the resource. The times shown in Table 1.1 should be inter-
preted as completion times. In this particular event log, activities are considered to
be atomic and the table does not reveal the duration of activities. In the table, each
event is associated to a resource. In some event logs, this information will be miss-
ing. In other logs, more detailed information about resources may be stored, e.g., the
role a resource has or elaborate authorization data. The table also shows the costs as-
sociated to events. This is an example of a data attribute. There may be many other
data attributes. For example, in this particular example it would be interesting to
record the outcome of the different types of examinations and checks. Another data
element that could be useful for analysis is the amount of compensation requested.
This could be an attribute of the whole case or stored as an attribute of the register
request event.
Table 1.1 illustrates the typical information present in an event log. Depending
on the process mining technique used and the questions at hand, only part of this in-
formation is used. The minimal requirements for process mining are that any event
can be related to both a case and an activity and that events within a case are or-
dered. Hence, the “case id” and “activity” columns in Table 1.1 represent the bare
minimum for process mining. By projecting the information in these two columns,
we obtain the more compact representation shown in Table 1.2. In this table, each
case is represented by a sequence of activities also referred to as trace. For clarity,
the activity names have been transformed into single-letter labels, e.g., a denotes
activity register request.
Process mining algorithms for process discovery can transform the information
showninTable 1.2 into process models. For instance, the basic α-algorithm [103]
discovers the Petri net described earlier when providing it with the input data in
Table 1.2. Figure 1.5 shows the resulting model with the compact labels just intro-
duced. It is easy to check that all six traces in Table 1.2 are possible in the model.
Let us replay the trace of the first case— a,b,d,e,h —to show that the trace “fits”
(i.e., conforms to) the model. In the initial marking shown in Fig. 1.5, a is indeed
enabled because of the token in start. After firing a places c1 and c2 are marked,
i.e., both places contain a token. b is enabled at this marking and its execution re-
sults in the marking with tokens in c2 and c3. Now we have executed a,b and
the sequence d,e,h remains. The next event d is indeed enabled and its execution
results in the marking enabling e (tokens in places c3 and c4). Firing e results in the
marking with one token in c5. This marking enables the final event h in the trace.