The organizations have evolved over the years. With them, the information systems have become in a key players for storing the amount of information generated daily. Process mining has emerged with a series of techniques to extract useful knowledge from data records stored in an event log. For W. van der Aalst [1], process mining is a relative young research discipline that sits between machine learning and data mining on the one hand and process modeling and analysis on the other hand. The idea of process mining is to discover, monitor and improve real processes by extracting knowledge from event logs readily available in today's systems.
This work shows how mining process allows support the organization Volvo Belgium IT, characterizing and analyzing the business process for managing incidents and problems. We use the event log for the "Third International Business Process Intelligence Challenge (BPIC'13)" [2]. The aim of this work is focused on delivering solutions to a number of questions that have the business owner about the incidents and problems presented, considering cases related with push to front incident management, Ping-Pong behavior, waiting user status and process conformance. In addition, we incorporate two additional analyzes as a recommendation for the process owner for a better understanding of the process and to identify possible improvements.
This section is directly related to the incident management, where the analysis center of looking at the behavior of how they are managed and resolved, mainly searching on how they are resolved in line one and not the second or third.
For this specific analysis several questions need to be answered
• For what products is the Push to front most used and for which not?
• Where in the organization is the PTF mostly used, specifically comparing the organizations Org Line A2 and Org Line C? • What functions are more in line with the PTF?
To observe the PTF and analysis was made to the original log, and then it was filtered according to the question that needed to be answered in DISCO [3].
For what products is the Push to front most used and for which not?
In this case we filter the log the following way:
1. The complete cases were filtered, this correspond to the cases where an incident begins with the initial status Accepted -In Progress and ends with one of the following final status in completed (Completed-Closed, Completed-In Call, Completed-Closed y Completed-Cancel). All this end activities were included so the original log did not reduce so much and the analysis could still be done. 2. Cases with status Unmatched were eliminated, for a total of 5 cases. 3. To have only the products where there were no second or third line support teams (ST), involved, the log was filtered with only the cases where the first line was involved.
As it can be seen in the following figure, with this filter we obtained 52 percent of the cases, only including the ones without support from the second or third level. From this log we can see that the following products are the ones with more incidents that are resolved in level one. 4. In the opposite case, to see the products where the PFT is use the least, the log was filter with those cases where at least one instance of the second or third level was used to resolve it. The following products are the one with the least use of PTF. Having the original log filtered It was seen the way the different organizations handle their incidents, we classify them in two types, those resolved with PTF (incidents resolved in first line) and those resolved without PTF (incidents resolved in second or third line). We can see both categories in figure 4 and figure 5. For this numbers, we analyzed the percentage of the total of cases that correspond to the first or second type. This way we obtain a correct comparison percentage to compare on both organizations the use of PTF. From table 1, the organization that uses the most PTF to resolve its incidents its Org line C, in contrast to the Org line A2 that uses it less.
To obtain the answer to this specific question, we did the same procedure explained before to filter the log.
The next figure shows the functions that are most associated with PTF, showing clearly that functions V3_2 and A2_1 uses it the most.
The support groups that use more PTF are the G96, the S42 and the G97 respectively.
The countries that user more frequently PTF are Sweden, Poland and Brazil.
This analysis is related to both the incidents and the problem management. It is the behavior in which the Support Team sends each other back and forth the incidents in a Ping Pong way. This is a behavior that it is not wanted and it has a direct relation between this behavior and the total time spent resolving an incident.
For this analysis we want to answer several questions:
• Which are the functions responsible for PP?
• Which are the organizations responsible for PP?
• Which are the STs responsible for PP?
• Which are the products that are more impacted by PP?
To respond these questions the original log had to be analyzed and make some specific filters. Following are a series of steps of the filter process to get the original to only have the content so we can answer the questions.
1. The first step is that when we open the original log in the Disco Tool, the resource column should correspond to the ST column, instead of the default column. 2. The complete cases were filtered, this correspond to the cases where an incident begins with the initial status Accepted -In Progress and ends with one of the following final status in completed (Completed-Closed, Completed-In Call, Completed-Closed y Completed-Cancel). All this end activities were included so the original log did not reduce so much and the analysis could still be done. 3. Cases with status Unmatched were eliminated, for a total of 5 cases. 4. The next filter corresponds to only leave the activities Queued -Awaiting Assigment, this one corresponding to the activity that precedes the traspassing an incident from one ST to another. 5. After we have these variants where we have this activity we filter the log to eliminate all those cases where we do not have cycles of PP. For this it was discovered in the log that the PP behavior it is present in the cases where the following Sequence of activities is located: Accepted-In Progress, Queued -Awaiting Assigment and then again Accepted-In Progress. The objective of this filter was to leave these activities in. 6. After this we did a manual analysis to make sure that this filter was only leaving us the cases with this behavior for our final analysis. 7. After confirming this, we discarded all the activities besides Accepted-In Progress and Queued -Awaiting Assigment, because it is in these ones where we see the PP activities. 8. Analyzing the cases in their performance behavior in DISCO, it was discovered that those where PP is present were the ones with high duration and not the ones that do not take much time in completing even if they have some kind of PP activities. From this the log was filtered leaving only the cases with duration higher tan 33 days and 5 hours (only 6% of the total cases). 9. This resulting log was exported to Prom 5 [4] for further analysis though the Handover of Work metric of the Social Mining algorithm. The results of this analysis were not correct and no relationships were discovered. The results are shown in the following figure. 10. Because of not being able to discover and see the expected behavior, this log was separated in several clusters according to the sequence of its activities, this way the analysis could be done to see if we found cycles between the two activities that will determine PP behavior.
11. For the clustering we used the Sequence Clustering algorithm in Prom 5, using as a parameter, that the log would be partitioned in 5 different clusters, for individual analysis. 12. For each of the resulting clusters further examination was done to identify correct and real PP behavior so the Handover of Work (HoW), could be applied. 13. After applying the HoW for each cluster, we analyzed the results based on two threshold values.
The first one with a value of 0.0097 and the second with a value of 0.0194. 14. After applying the two thresholds, we obtain two models per cluster and extracted for each model the components that had PP cycles. In the following table are the cycles identified for each cluster on each threshold. . Following this, this log was filter in DISCO to include only the 13 STs participants to verify in Prom 6 [5] with HoW if they really had a high presence of cycles. This resulting log was exported from DISCO to Prom 6 and the following results were obtained: As it can be seen in figure 10, a group can be identify that executes the majority of the PP behavior when resolving incidents and managing problems.
If the last results are compared with the results in table 3 we can confirm that the 6 STs with mayor execution of PP cycles are the same that were discovered when the threshold was 0.0195, having though the different tools the same result. 17. Besides from applying this analysis, it was decided to apply to the log obtained in point 3 (6365 cases), the trace alignment algorithm in Prom 6.2. It was selected that the algorithm should divide the log in 6 clusters according to the most repeated sequences. After a long execution time we had 6 different trace aligments. Each of the traces was exported so an in more detailed analysis could be done to verify which cluster included the most amounts of ping pong cycles. Of the 6 clusters, two presented PP, one very frequent and the other less frequent but still present. To confirm if the PP was present, some cases were analyzed in the log and effectively some of the STs found in point 15 were found. Next are some images of the aligments with PP. The activities highlighted in yellow and in light blue have the PP behavior, for example in figure 12 we can see the case 1-638742591, taken from the cluster shown in figure 11. With this information the answer to the following questions can be answered.
The function responsible for the PP behavior its function A2_1, with the second level STs V32 2nd and V37 2nd, that do not possess information to which function they belong to.
The organizations responsible for PP are: ! Org line V7n, which includes V32 2nd and V37 2nd ! Org line A2, which includes D4 and D8 ! Org line C, which includes D2 and D5
The STs with mayor amount of cases with PP are D8, V37 2nd, D2, D4, D5 and V32 2nd.
The products associated to mayor amount of cases with PP are PROD542, PROD236, PROD424, PROD158, PROD235 and PROD215.
Note: There could exist more STs executing PP, however from this analysis we obtained which did the most according to the activity included in the log.
Another aspect that it should be analyzed it is the incorrect use of the status Wait User. Initially this status is used when an incident or a problem is waiting for a user for an action or a response. The negative way that this status has been used in the organization it is that moving an incident or problem to this status will reduce the time being in progress for a lot of time, this is because some users may move their incidents to this status to reduce the work effort associated to it. The work effort for an incident or a problem it's calculated for the time it is in the in progress status, and it does not stop until it is changed to another one. What users do to reduce this time is when they are not able to resolve an incident or problem, they will move it to the Accepted -Wait User status, stopping the wait effort. Analyzing the log you can see that are some cases where the user changes the status to Wait User and after some time it returns to Accepted -In Progress to continue working on it, this is the incorrect way of using it. As an additional note, the correct use of this status is the one in which for the resolution of the incident or problem, there is some answer or request expected from a specific user to continue and resolve the issue.
From this point we would like to answer several questions:
• Who is using more this sub status?
• Which is the behavior per ST?
• Which is the behavior per function?
• Which is the behavior per organization?
• Which is the location where this status its most incorrectly used?
To respond each of these questions, the DISCO tool was used and the following filters were applied.
1. The complete cases were filtered, this correspond to the cases where an incident begins with the initial status Accepted -In Progress and ends with one of the following final status in completed (Completed-Closed, Completed-In Call, Completed-Closed y Completed-Cancel). All this end activities were included so the original log did not reduce so much and the analysis could still be done. 2. Cases with status Unmatched were eliminated, for a total of 5 cases. 3. The cases that do not include this status were filtered, so we would only analyze the specific ones.
After applying this filter we only have 2060 cases. 4. The cases were analyzed to determine if the user of this status was in a correct or incorrect way. 5. With the incorrect use identified, the log was filtered to only leave the incorrect use. It was discovered that 10% of the total use of the status (55570 cases), was in a wrong way. 6. After this another filter was applied to only have the users that moved incidents or problems to this status, reducing it to only 1707 cases. 7. Because the system uses this status in a correct way, the user Siebel was eliminated. 8. Based on this results and final filter, it is that all the questions can be answered. For this final analysis this status was present 1660 times in 791 cases. With the data from the last group of filters we proceed to answer the related questions:
4.1 Who is using more this sub status?
Analyzing the data obtained from the filter the next figure shows the users that use incorrectly in more cases this sub status:
Analyzing the data obtained from the filter, the next figure shows the functions that use incorrectly in more cases this sub status: To analyze this point we performed the following steps:
1. Complete cases were filtered. These are those cases in which an incident begins with the initial status of Accepted -In Progress and ends with the final status Completed-Closed. We excluded other complete like final case, as we wanted to have only complete cases. 2. Traces with Unmatched status were removed. 3. This event log generated includes the process performed by all organizations in Volvo, including organizations Org line A2 and Org line C.
5. In ProM 5.2, algorithm Heuristic Mining was selected and the result obtained was the following model. This is the base model with which to analyze the pattern of the two organizations (Org line A2 and Org line C). b. In these 11 activities, the most commonly performed activities are Accepted-In progress y Queued-Awaiting assignment that represents the 64.09% of all activities. This means that the second activity is Queued-Awaiting, waiting to be assigned. c. There are 3 activities that take 6 or more days to be completed. These activities are Accepted-waiting user, Accepted-waiting implementation and Accepted-waiting vendor. 7. With the same log obtained in the point 3, we proceed to make a filter considering all activities that include the cases performed only in the Org line A2. The resulting log was exported to perform the analysis through ProM 5.2. 8. In ProM 5.2, algorithm Heuristic Mining was selected and the result obtained was the following model. This model corresponds to the process performed only by organization Org line A2. 9. Analyzing the model corresponding to Org line A2, and the event log in DISCO tool, we obtain the following aspects: a. Have 10 activities and 628 resources. b. In these 10 activities, the most commonly performed activities are Accepted-In progress y Queued-Awaiting assignment that represents the 67.6% of all activities. This means that the second activity is Queued-Awaiting, waiting to be assigned. c. There are 3 activities that take 7.4 or more days to be completed. These activities are Accepted-waiting user and Accepted-waiting implementation. Accepted-waiting vendor.
Besides, the activity Accepted-waiting vendor takes on average 19.7 hours. d. There are 3 resources (apart from system) that are working more. They are Marcin, Olga y Krzysztof. Between them and Siebel (the system) perform the 18.34% of all activities. 10. With the same log obtained in the point 3, we proceed to make a filter considering all activities that include the cases performed only in the Org line C. The resulting log was exported to perform the analysis through ProM 5.2. 11. In ProM 5.2, algorithm Heuristic Mining was selected and the result obtained was the following model. This model corresponds to the process performed only by organization Org line C. Analyzing the above table that includes both comparisons, we can deduce that the organization that complies with the overall process more is the Org line C, performed all activities included in the original model, and performing them in a slightly more efficient, except the activity Accepted-waiting vendor, that takes just 7.8 hours in the Org line A2.
In addition to previously answered questions, is interesting to analyze the following:
a. Analyze the number of incidents by country and its duration b. Analyze in which Org Line handled only incidents are managed, or also, problem administration is performed too.
For each of these questions, the analysis discussed below.
a. Analyze the number of incidents by country and its duration • Complete cases were filtered. These are those cases in which an incident begins with the initial status of Accepted -In Progress and ends with the final status Completed-Closed. We excluded other complete like final case, as we wanted to have only complete cases. • Traces with Unmatched status were removed.
• To analyze which countries that have more incidents, we analyze the start activity Accepted-In Progress.
• We use DISCO tool to analyze the event log filtering. The result shows the three countries that generate the greatest number of incidents:
• Sweden is the country with the most incidents, 6736 cases • Poland (pl) is second one with 1266 cases • India (in), is third with 966 cases • We use DISCO tool to analyze the event log filtering. The result shows the two countries that generate the fewer number of incidents:
• Argentina with only 1 case • Austria with 3 cases
• Below is the listing of all countries and their percentage present in the start activities of incidents (note that this only serves as an indicator, and later to analyze the countries): b. What are the products that generate the highest number of incidents?
• Complete cases were filtered. These are those cases in which an incident begins with the initial status of Accepted -In Progress and ends with the final status Completed-Closed. We excluded other complete like final case, as we wanted to have only complete cases.