Chapter 2 INDUSTRIAL APPLICATION OF PROCESS MINING
2.2. Case study
2.2.6. Compliance verification
Compliance verification in process mining is a set of methods that allow comparing a business process model with the event log of the same process model. The goal of compliance verification is to investigate whether the actual execution of a business process,
49
i.e., the event log and the modeled business process are in compliance with each other. To do so, the fitness metric; which measures how much the process model can reproduce the traces recorded in the event log; is measured. One way to find the fitness is to reply the log in Petri net (Van der Aalst et al., 1998). Log replay is operated such that if there are missing tokens to fire the transitions in question, they are created artificially to continue the reply. Token-based fitness metric f computes the amount of missing and remaining tokens during the log replay.
If the log could be replayed correctly the value of f is equal to 1.
Compliance verification allows identifying differences and deviations between the modeled behavior (the standard model) and the observed behavior (the event log). Two types of differences can be detected: (i) a behavior observed in the event log, while it is not allowed by the model, and (ii) a behavior allowed in the model but never captured in the log. These discrepancies could be determined by one of the following techniques: replay (Rozinat et al., 2008), trace alignment (Adriansyah, 2014), and behavioral alignment (Goedertier et al., 2009). In this study, trace alignment method is selected because it can handle complex control-flows that contain invisible tasks in a Petri net (Van der Aalst et al., 1998). An alignment between a recorded process execution (i.e., a process instance) and a process model is a pairwise comparison between the executed tasks and the tasks allowed by the model. This pairwise comparison can generate three results: (i) perfect alignment step, i.e., the log is replayed correctly on the process model; (ii) missing events, i.e., the process model forces a task that is not recorded in the event log to be executed; (iii) wrong events, i.e., the process model does not allow a task recorded in the log to be executed.
In this step, we aim to answer the following questions: Is and how much the actual process of customer order fulfillment as recorded in the event log conforms to the standard process model designed by the company? In case there are discrepancies in the customer order fulfillment process where are they located? To answer these questions, first, we converted the standard model of customer order fulfillment process into a Petri net model.
Then we computed the fitness metric by running “Conformance Checker” plugin in ProM.
After that, we run the plugin “Conformance Checking of DPN (Xlog)” to locate discrepancies based on trace alignment. The value of fitness obtained is 0.945 which indicates that 94.5%
of the recorded events are correctly replayed by the event log. This means 5.5% of the recorded events deviate from the standard model. The capture screen of trace alignment generated using the “Conformance Checking of DPN (Xlog)” plugin is depicted in Figure 2.5. Perfect alignments are illustrated in green color, missing events in purple color, and
50 wrong events in yellow color.
The result of the alignment is summarized in Table 2.4. As can be seen, from 1653 replayed cases, there are 1460 cases where the event log and the process model are synchronized, i.e., 88.32% of the total executed cases followed exactly the standard process model designed by the company. This value is high; however, the existence of some missing and wrong events illustrates the presence of some deviations. According to the result obtained in Table 2.4, the activity N0160 has been allowed by the process model to be executed 154 times when it was not recorded in the event log. This can be seen as a skipped activity and indicates that 9.32% of the received customer orders skipped the post-processing painting and plating. Moreover, Table 2.4 shows that the activity N0180 has been executed 39 times while it was not allowed to be executed in the process model. This indicates that in 2.36% of total cases, the task operating on product delivery was performed several times in the same case.
This might be explained by the fact that the task related to product delivery faced some issues and the task sent back to solve the problem occurred. This can be classified as a normal behavior. However, the fact that the post-processing painting and plating of the products has been skipped 154 times generates the following question. Are there special products that do not require the post-processing of painting and plating? If the answer to this question is ‘NO’, then an investigation about this observed negative behavior is required. A product, which necessitates painting and plating operations after quality inspection, skips this post- processing, might engender issues related to customer satisfaction. Nevertheless, if the answer to the above question is ‘YES’, then the standard process model requires an improvement. The process model discovered in the previous section can be guidance for the improvement of the standard process model. Excepting the question related to the post- processing task, we can say that in overall the customer order fulfillment process is well managed by the company.
Table 2.4. Result of an alignment between the executed activities and the activities allowed by the standard model
Alignment Result Number of traces Model Event log Deviating tasks % From total cases
Perfect alignment 1460 √ √ - 88.32%
Missing Events 154 √ - N0160 9.32%
Wong Events 39 - √ N0180 2.36%
51
Figure 2.5. Captured screen of trace alignments illustrating perfect alignment, missing events and wrong events