Page 38 -
P. 38

20                                                     1  Introduction

            • Extending the model with frequencies and temporal information. By replaying the
              log one can see which parts of the model are visited frequently. Replay can also be
                                                               8  9  20  21  21
              used to detect bottlenecks. Consider, for example, the trace  a ,b ,d ,e ,h
              in which the superscripts denote timestamps. By replaying the trace on top of
              Fig. 1.5 one can see that e was enabled at time 20 and occurred at time 21. The
              enabling of e was delayed by the time it took to complete d; although d was
              enabled already at time 8, it occurred only at time 20.
            • Constructing predictive models. By replaying event logs one can build predictive
              models, i.e., for the different states of the model particular predictions can be
              made. For example, a predictive model learned by replaying many cases could
              show that the expected time until completion after enabling e is eight hours.
            • Operational support. Replay is not limited to historic event data. One can also
              replay partial traces of cases still running. This can be used for detecting devia-
                                                 11
                                              8
              tions at run-time, e.g., the partial trace  a ,e   of a case that is still running will
              never fit into Fig. 1.5. Hence, an alert can be generated before the case completes.
              Similarly, it is possible to predict the remaining processing time or the likelihood
              of being rejected of a case having a partial trace, e.g., a partial executed case
                  9
                8
               a ,b   has an expected remaining processing time of 3.5 days and a 40 percent
              probability of being rejected. Such predictions can also be used to recommend
              suitable next steps to progress the case.


              Desire Lines in Process Models
              A desire line—also known as the social trail—is a path that emerges through
              erosion caused by footsteps of humans (or animals). The width and amount
              of erosion of the path indicates how frequently the path is used. Typically, the
              desire line follows the shortest or most convenient path between two points.
              Moreover, as the path emerges more people are encouraged to use it, thus
              stimulating further erosion. Dwight Eisenhower is often mentioned as one of
              the persons using this emerging group behavior. Before becoming the 34th
              president of the United States, he was the president of Columbia University.
              When he was asked how the university should arrange the sidewalks to best in-
              terconnect the campus buildings, he suggested letting the grass grow between
              buildings and delay the creation of sidewalks. After some time the desire lines
              revealed themselves. The places where the grass was most worn by people’s
              footsteps were turned into sidewalks. In the same vein, replay can be used to
              show the desire lines in processes. The paths in the process model traveled
              most can be highlighted by using brighter colors or thicker arcs (cf. ProM’s
              Fuzzy Miner [50]).
              An interesting question is how desire lines can be used to better manage busi-
              ness processes. Operational support, e.g., predictions and recommendations
              derived from historic information, can be used to reinforce successful behav-
              ior and thus create suitable “sidewalks” in processes.
   33   34   35   36   37   38   39   40   41   42   43