Page 34 -
P. 34

16                                                     1  Introduction

            Table 1.3 Another event log:
            Cases 7, 8, and 10 are not  Case id         Trace
            possible according to Fig. 1.5
                                   1                     a,b,d,e,h
                                   2                     a,d,c,e,g
                                   3                     a,c,d,e,f,b,d,e,g
                                   4                     a,d,b,e,h
                                   5                     a,c,d,e,f,d,c,e,f,c,d,e,h
                                   6                     a,c,d,e,g
                                   7                     a,b,e,g
                                   8                     a,b,d,e
                                   9                     a,d,c,e,f,d,c,e,f,b,d,e,h
                                  10                     a,c,d,e,f,b,d,g



            to represent the discovered process models, because Petri nets are a succinct way
            of representing processes and have unambiguous and simple semantics. However,
            most mining techniques are independent of the desired representation. For instance,
            the discovered Petri net model shown in Fig. 1.5 can be (automatically) transformed
            into the BPMN model shown in Fig. 1.2.
              As explained in Sect. 1.3, process mining is not limited to process discovery.
            Event logs can be used to check conformance and enhance existing models. More-
            over, different perspectives may be taken into account. To illustrate this, let us first
            consider the event log shown in Table 1.3. The first six cases are as before. It is easy
            to see that Case 7 with trace  a,b,e,g  is not possible according to the model in
            Fig. 1.5. The model requires the execution of d before e,but d did not occur. This
            means that the ticket was not checked at all before making a decision and paying
            compensation. Conformance checking techniques aim at discovering such discrep-
            ancies [80]. When checking the conformance of the remainder of the event log, it
            can also be noted that Cases 8 and 10 do not conform either. Case 9 conforms al-
            though it is not identical to one of the earlier traces. Trace  a,b,d,e  (i.e., Case 8)
            has the problem that no concluding action was taken (rejection or payment). Trace
             a,c,d,e,f,b,d,g  (Case 10) has the problem that the airline paid compensation
            without making a final decision. Note that conformance can be viewed from two
            angles: (a) the model does not capture the real behavior (“the model is wrong”)
            and (b) reality deviates from the desired model (“the event log is wrong”). The first
            viewpoint is taken when the model is supposed to be descriptive, i.e., capture or pre-
            dict reality. The second viewpoint is taken when the model is normative, i.e., used
            to influence or control reality.
              The original event log shown in Table 1.1 also contains information about re-
            sources, timestamps and costs. Such information can be used to discover other per-
            spectives, check the conformance of models that are not pure control-flow models,
            and to extend models with additional information. For example, one could derive
            a social network based on the interaction patterns between individuals. The social
            network can be based on the “handover of work” metric, i.e., the more frequent in-
   29   30   31   32   33   34   35   36   37   38   39