# Behavioral and Performance Analysis of a Real-Time Case Study Event Log: A Process Mining Approach
## 4 Discovery Analysis
### In-Depth Analysis: Tracking Process Inefficiencies  
After the process discovery, the resultant process models can analyze the performance. The performance analysis phase answers questions such as 'Are there any bottlenecks in the process' and 'What is the effect of pre-processing on the optimization of the process?'. It can be used to give insights into the deviations that occur on the other level than control flow, such as delays in the process. Process mining provides a wide range of performance techniques [2]. PrOM dotted chart analysis, PrOM sequence analysis, and Disco's performance view can provide valuable insights into the deviations. In this work, the Disco performance view is used to find the time delays in the procurement process. Figure 5 shows the performance map of the data that show the mean execution time between activities. The mean time depicts the average time of execution for each activity. It can be seen in the map that there is more time consumption between the activities'requisite budget confirmation' and 'purchase requisite approved I', causing the delay in the process. After the pre-processing of procurement log data, there remained 2 variants in our log data. These two sequences are shown by mined models of the log data, as mentioned in Table 11. A variant is a specific sequence of activities, and multiple cases may follow the same sequence through the process. The two variants in our event log are:  
* Variant 1: In this variant, there are 6925 cases, and in each case, there are 4 activities involved. This variant covers 98.6% of the log, and the sequence of activities in this variant is purchase requisite generation \(\rightarrow\) requisite recommendation I \(\rightarrow\) requisite budget confirmation \(\rightarrow\) purchase requisite approved I (\(2\to 3\to 4\to 5\)). * Variant 2: In this variant, there are 98 cases, and each consists of 5 activities. This variant covers 1.4% of the log data and the sequence of activities according to their event IDs; this variant contains purchase requisite generation \(\rightarrow\) requisite recommendation I  
Figure 4: Visualization (dependency graph) for the control flow log using different algorithms. name), and generalizability issues related to activities (e.g., the presence of two activities across the same event ID 5, and the fact that the activity 'purchase requisite generation' has two IDs, 1 and 2). Three discovery algorithms were also applied to these data to generate mined models. Figure 6: (**a**) Process map of original noisy data, and (**b**) process map of data after preprocessing. Figure 6b represents the process map after the pre-processing of data. As discussed above, after pre-processing, there are only 2 variants in the log data, shown in the following process map. It shows that the procurement process can occur in two most frequent manners, which are: \(2\to 3\to 4\to 5\) and \(2\to 3\to 4\to 4\to 5\). In the map, the arrows show the dependencies and frequency of the performed activities, and the thicknesses of the arrows represent the frequency of occurrence; the more the thickness, the more common its occurrence. We can see in the process map that variant 1 (\(2\to 3\to 4\to 4\to 5\)) has a high occurrence, which means this flow is primarily followed in the procurement process. Figure 7a illustrates that the generated Petri net did not reflect the correct flow because of the limitations of the alpha algorithm. In addition to the general issue of log completeness, it cannot produce the correct model. It produces very complex models, and the frequencies are not considered in this algorithm; therefore, it is susceptible to noise and can easily misclassify a relation. As our data were extensive, it did not give reliable results. **Heuristic Miner**  
The heuristic miner algorithm [10] should be applied to real-world data that contain a limited number of distinct events. It can handle noise and convey the primary behavior, which excludes all details and exceptions and is recorded in an event log.