Our digital universe is rapidly growing. Because of the increasing automation of and IT support for business processes, IT systems are playing a key role in this rapid growth [2]. They are accumulating invaluable (big) data, which often records in detail which activities were executed when and by whom [9,11]. If managers extract process knowledge from the data, they can directly translate that knowledge into better process performance and decision making for process improvement initiatives [4,5,7,8].
How can we put the invaluable data to good use? Process mining provides an evidence-based approach to extract valuable insights from an organization's processes by depending on the data [8]. Through process mining, we can discover the actual 'as-is' process models depicting the way activities were performed. Process mining can verify the conformance of processes against some 'ideal' behaviours (e.g. as documented in standards, guidelines, and business policies) [6]. Moreover, it can also find performance issues in processes (such as bottleneck) and analyze the interaction between resources performing activities [10]. Process insights gained from using process mining and other analytical techniques can then help us precisely find process improvement opportunities [8].
The situation depicted in the BPI Challenge 2013 focuses on the incident and problem management processes supported by Volvo IT's VINST system. The incident and problem management logs include 7554/2306 cases and 65533/9011 events respectively. We attempted to address the given questions drawn from four major issues by using process mining and other analytical techniques. To achieve this goal, we sought to understand the data and create relevant datasets for the questions. Furthermore, we tried to clarify the issues at the log data level. Specifically, to provide evidence-based answers for the questions, we aimed to address the following issues in detail:
1. Push to front mechanism Defining push to front mechanism at the log data level Addressing the three questions 2. Ping pong behaviour Defining ping pong behaviour at the log data level Addressing the two questions 3. Wait user Understanding the given three questions Addressing the three questions 4. Process conformity per organization Defining the range of comparison in conformity Addressing the given question As noted by [1], process mining projects are typically iterative; after stakeholders provide feedback on findings, a new round of analysis is triggered. However, since we were not in contact with the stakeholders of Volvo IT, we are not able to receive any feedback on our analysis results and thus start a new round of analysis. In spite of this limitation, we believe that our answers and analysis results are plausible and thus validate the potential benefits of process mining-based analysis. We hope that our analysis results encourage an increasing number of managers to pay attention to process mining-based understanding and analysis of business processes in a big data world.
The rest of the paper is structured as follows. The next section shows which tools we used and our understanding of the data. We also explain how the two event logs were filtered and split into relevant datasets for answering the given questions. In section 3, we explain our analysis approaches and give evidence-based answers for the given questions. The final section provides the concluding remarks and the limitation of our analyses.
There are several tools used in this analysis: process mining tools (ProM and Disco), a database management system, and a spreadsheet application.
We chose ProM and an evaluation version of Disco (Version 1.3.6; Fluxicon) as process mining tools. We got a lot of help from Disco's capabilities like statistics, filtering function, and process map generator, which is shown in <Fig. 1>, to make a conclusion in many parts of the analysis with little effort. We also used ProM's innovative process mining techniques.
Although in general it could be said that Disco has excellent filtering functions, we sometimes needed more complicated and sophisticated preprocessing and data conversion features. That is the reason way we used Eclipse SDK(Version 4.2.2; Eclipse Foundation), the programming framework, and Oracle Database Express Edition (Version 11.2.0.1.0; Oracle).
Microsoft Excel, which is well known spreadsheet application, is very useful to draw charts or graph of data. We, therefore, used Microsoft Excel(Microsoft Office 2010; Microsoft Corporation) to convey conclusion effectively.
We received three datasets which consists of 16 attributes respectively. Some rough information of each dataset is displayed in <Fig. 2>.
Moreover, sub statuses are involved in one particular status and <Fig. 3> shows their correlations.
There are two problem management datasets (i.e., open and closed datasets) and this means that problem management datasets are divided into two datasets. However, the incident management dataset exists as only one which includes those two concepts (open and closed). Among 7,554 incidents, 1,980 ones still remain uncompleted.
It is possible to draw various conclusions from one analysis using different process mining techniques. For example, it could be interesting topics to analyze social networks between action owners or to figure out every pattern of incident management process. In this analysis, however, we sought to focus on the given questions with data.
Through this analysis, 'SR_Number' attribute of the given data is used for case id and 'Change_Date+Time' attribute is used for time. 'Activity' could be changed flexibly in dealing with every given question and also be combined with more than two attributes. In this case, we decided to use plus sign ('+') to distinguish each attribute value. <Fig. 4>, for instance, shows the log data of an activity which consists of status and sub status combined together.
Fig. 4. Activity combined with a status and a sub status Doing this analysis, it is necessary to extract data from all datasets meeting particular conditions. For example, supposing we should extract data of which organization attribute value is 'Org Line A2' from dataset consisting of 15 lines, in this case only 4 shaded lines, as seen in <Fig. 5>, could be extracted.
Extracting events whose organization attribute value is 'Org Line A2'
This issue deals with the Volvo IT's strategy/philosophy that most of the incidents need to be resolved by the first line support teams (mainly service desks). In general this increases work efficiency. Because the issue is only related to the incident management process, the problem management dataset was not considered for this analysis.
It could be defined that the push to front mechanism operates well when incidents are closed without any involvement of support teams which are in the second or third lines. Here, we intend to set and define operational principle of push to front mechanism at a log data level.
There are records of support teams -specially, names of support teams -on incident management datasets. <Fig. 6> shows some representative examples of names of support teams out of 649 support teams total. We supposed that the support teams which don't have any followed words like '2nd', '3rd', or '2nd 3rd' are just in the first line: for example, 'A14' in the <Fig. 6>.
When we make a judgment if push to front mechanism works well, only completed incidents are intended for the judgment first. It is because there is possibility for support teams in 2nd or 3rd lines to get involved in uncompleted incidents during its procedures even if it is not happened yet.
To judge whether push to front mechanism of the completed incidents works well, we should make clear the fact that there is no involvement of support teams in 2nd and 3rd lines during the procedures of incidents. <Fig. 7> shows one of the cases (incidents) in which push to front mechanism works very well. Meanwhile, an incident requires the approval of the support team being taken over the work when it needs to switch from the current support team to other ones. For this reason, the incident remains in standby status till the support team approves when the current support team assigns a new team which will take responsibility of an incident (in other words, the status now is to be 'Queued'). You can see 'Queued' status in the part shown in red color (see <Fig. 8>). However, you are able to figure out that the attribute value of the support team has been changed from 'U3' to 'S30 2nd', although the support team in charge has actually not been changed because it's not approved yet. In this case, it can be said that the push to front mechanism operates well because there was no actual change of a support team.
Based on the discussion about lines involved in incidents and 'Queued' status awaiting assignment mentioned above, there are some definitions at a log data level to make a judgment if push to front mechanism works or not.
An incident is closed without any involvement of 2nd or 3rd lines 'Queued' status does not include the change of support teams Thus, based on those clear definitions given at log data level and related to the operation of push to front mechanism, we sought to give answers to those following questions.
For what products is the push to front mechanism most used and where not? Where in the organization is the push to front process most implemented (field=involved organization), specifically if we compare the Org Line A2 with the Org Line C
What functions are most in line with the push to front process?
There are 704 products related to the incident management process. Among those products, only 284 are influenced by push to front mechanism. We found a list of top 10 products which had used push to front mechanism frequently among those 284 products by using the definition we have mentioned (see <Fig. 9>). Considering only absolute frequency, the product used push to front mechanism the most is 'PROD424'. However push to front mechanism was found just in 69% of all cases related to it, 'PROD424'. On the contrary, 'PROD383' has its absolute frequency 196 and at the same time 96% out of total cases related to it show the usage of push to front mechanism. (PRODUCT: product number, Push to front: cases which work with push to front mechanism well, Case Frequency: total number of cases related to an appointed product, Push to front / Case Frequency: rates of cases related to push to front mechanism among all cases of an appointed product) Fig. 9. Top 10 products using push to front mechanism a lot Out of 704 products, there are 420 which have never used push to front mechanism. We selected 10 products which have many related cases among those 420 products (see <Fig. 10>). For example, there are 70 incidents related to 'PROD607'. However, they have never adopted the push to front mechanism. Fig. 10. Products which have never used push to front mechanism at all
This time, let us look into the organizations and function divisions which work with push to front mechanism well. There are 25 organizations total -including 'Other'in the incident management process. Among those 25, there are 13 organizations working with push to front mechanism more than once. <Fig. 11> shows how the 12 organizations -not involving 'Other' -follow push to front mechanism. Although there are some organizations -like 'Org Line V8', 'Org Line G2', 'Ogr Line V10', and so on -applying push to front mechanism to every related case, it is only about less than 10 cases. Meanwhile, there is 'Org Line C' that many cases following push to front mechanism have been found and they count for 75% of all the cases. It, therefore, could be said that push to front mechanism is well followed by 'Org Line C'.
On the contrary, compared with 'Org Line C', 'Org Line A2' has fairly low percentages of push to front mechanism -only 15% -shown related to cases.
Next we analyzed 24 function divisions in a similar way. There are 9 function divisions -excluding null value -which have followed push to front mechanism more than once. <Fig. 12> compares how well those 9 function divisions follow push to front mechanism. It was found that this mechanism is well followed by function divisions dealing with many incidents. In case of 'V3_2' and 'E_5', in particular, we got surprising result that 97% and 99% of 'V3_2' and 'E_5' respectively of all cases they involved in show well fulfilled push to front mechanism.
Ideally, an incident should be resolved quickly and with minimum interference of not too many support teams. However, in reality, support teams send incidents to each other repeatedly. These phenomena are called ping pong behaviour, which definitely leads to prolonging the total life time of an incident. We can witness this behaviour in both the incident and problem management processes.
Ping pong behaviour denotes that support teams pass the buck to each other repetitively when they deal with an incident or a problem. For elaborate analysis, we need to define it more specifically and clearly at the level of log data. Discussion below describes how ping pong behaviour is specifically and clearly defined at the level of log data.
In 3.2, we already explained how data is recorded when incidents remain in standby status. A status value is 'Queued' when an incident is in standby status and the support team is changed to be recorded even if the incident is not completed yet (see <Fig. 8>). To work out these errors, we got rid of all the rows in 'Queued' status where incident management data sets and problem management data sets have.
We looked into the type of these behaviours first to define ping pong behaviour more specifically and clearly at the level of log data. Ping pong behaviour is considered clearly just in case both action owners and support teams have been changed. On the other hand, as shown in <Fig. 13>, there are some patterns that action owners have not been changed, but support teams. We will consider it ping pong behaviour because these types correspond to the definition of ping pong behaviour as described.
Fig. 13. In case that action owners have not been changed, but support teams Lastly, a difficult type to judge is in case that support teams have not been changed, but action owners (see <Fig. 14>). It cannot be disregarded that these types influence on incident/problem management processes. However, we made a decision that these types are not appropriate to ping pong behaviour, based on the definition of ping pong behaviour as described.
Based on the previous discussion, we will consider all the shaded areas Ping pong behaviour. These types reflect descriptions below at the level of log data.
Support teams have been changed. Exclude from the scenario that support teams have been changed while 'Queued' status are recorded.
Ignore whether alternations to action owners only.
We will answer the questions below based on the clear definition at the level of log data on ping pong behaviour.
What are the functions, organizations, support teams responsible for most of the ping pong?
What products are most affected by it?
We, first of all, looked into ping pong behaviours shown in support teams. <Fig. 15> shows the top 20 support teams that have passed their incident. For example, through that <Fig. 15>, we could find that 'G96' handed over its incidents far more than took over from another teams. Most cases (86.6%), however, have low impact level. There could be found different features of 'D4' to 'G96'. 'D4' takes over incidents as much as it hands over although most of those cases shown on the chart below are at medium impact level at 97.3%.
(Involved_ST: support teams, Hand over: the number of handing over incidents to other support teams, Take Over: the number of taking over incident from other support teams, Impact(Hand Over): rates of handing over incidents to other support teams by impact) It is related to 882 ping pong behaviours total. For incidents occurrence is as high as occurrence of ping pong behaviours, it could be said that one ping pong behaviour occurs once one incident does on average. Although 'PROD542' on the second of the list is related to ping pong behaviours less than 'PROD424', there could be found 6 ping pong behaviours when only one incidents are arose and most of its incidents show higher impact level.
In this part, we sought to deal with questions related to abuse of 'Wait-User' which is one of the sub statuses. Dataset of incident management process on which this sub status -'Wait-User' -is only found, therefore, becomes a target dataset. We also decided to cover status information on the analysis to be more specific. Following <Fig. 24> shows every activity found on processes when we set process activities by combining statuses with sub statuses.
As shown on <Fig. 24>, the 'Wait-User' sub status is always regarded as 'Accepted' status. 'Accepted+Wait-User' hence is supposed to be the focus of analysis.
There are following some given questions related to 'Wait-User' sub status.
Who is making most use of this sub status (action owner)? What is the behaviour per support team, function, organization etc? (mis)-usage per location? Etc.
We intend to only answer the three of the questions mentioned above excluding different possible ones. To understand these three questions, it is required to conceptualize 'the behaviour' in the second question. We understood this concept as the pattern of using 'Wait-User'. Even though there are several possible interpretations of '(mis)-usage' in the third question, moreover, we sought to keep on analyzing focusing on the abusive behaviour on 'Wait-User'. The 'Wait-User' sub status, as mentioned above, is combined with 'Accepted' status and analyzed by being substituted with ''Accepted+Wait-User'. Based on this understanding, consequently, we intend to deal with and make answers the following subjects.
Action owner using 'Accepted+Wait-User' the most frequently.
Each pattern of using 'Accepted+Wait-User' found in support team, function division, and organization.
Locations where abuse of 'Accepted+Wait-User' is found.
To get answers to these questions, we counted number of uses for 'Accepted+Wait-User' analyzed by user. We also explored the percentages of usage of 'Accepted+Wait-User', considering the total number of events occurred by users, to have more validity in analysis. We, at this point, excluded 'Siebel', not a real action owner but only used in the system, from the analysis result. Although 'Pawel' mostly uses 'Accepted+Wait-User', 'Muthu' can be also recognized to use as much as 'Pawel' when we consider its number of events. In case of 'Krzysztof', meanwhile, it shows its highly placed frequency based on the absolute numerical value, whereas it shows its outstandingly lower frequency when we consider its total number of events.
We intend to call the pattern of usage of 'Accepted+Wait-User' as a combination of activities occurred right before and after it. Based on this definition, we found that the total number of patterns of usage of 'Accepted+Wait-User' was 40 (see <Fig. 26>). Before we generate this result, the uncompleted case was removed from the dataset. <Fig. 29> shows the pattern of usage and frequency of use found in organizations 'Org Line C' and 'Org Line A2'. We could find that 'Org Line C' uses more patterns than 'Org Line A2'. 'Org Line C' uses whole patterns that were found in incident management process. Some parts of the patterns between two organizations are a little different. For example, a flow like 'Accepted+In Progress' → 'Accepted+Wait-User' → 'Accepted+Assigned' is the fourth largest in 'Org Line C', which is found on the list at 10 in case of 'Org Line A2'.
There are 22 countries total which are involved in incident management process. In this context, we found that 'Accepted+Wait-User' is used repeatedly in the same case (see <Fig. 31>).
Repetitive usage in 'Accepted+Wait-User by country <Fig. 31> shows the result which is sorted in descending order depending on the total number of cases. It is shown that there are the largest number of cases in 'se', and the smallest number in 'tr'. In this context, it is possible that the higher a country is on the list, the more 'Accepted+Wail-User' is repeated. In case of 'be', however, we could find that there are enough number of repetitions (especially there is a case repeated over 20 times) as much as 'se' and 'pl'.
Lastly, we focused on how much the incident and problem management processes arose in one organization conform to those in others.
There is an open problems management dataset, among the given problems management, composed of uncompleted problems management. Because it is hard to say that this kind of process which is a conclusion drawn from uncompleted problems management has representativeness, we excepted this open problems management dataset from analysis. The problems management dataset, therefore, is a closed problems management dataset. And the uncompleted incident management was removed from incident management dataset, either.
In Volvo IT, there are 25 organizations total including 'Org Line A2' and 'Org Line C'. As shown below, <Fig. 32> represents the number and rate of events related to each organization in incidents and the problems. As in the figure above, over 83% of all events related to incident management is about 'Org Line A2' and 'Org Line C', which comprise more than 67% of problem management events. Consequently, we decided to consider 'Org Line A2' and 'Org Line C' as organizations which have representativeness and compare and analyze process between these two organizations: 'Org Line A2' and 'Org Line C'.
To analyze processes in different angles, on the other hand, process mining analysis helps various attributes (or combination of attributes) included in event log to be set as activities. Let us suppose, for example, there are status, support team, etc among attributes which are set as activities in incident management dataset. As shown in <Fig. 33> and <Fig. 34>, we are able to find that the two types of incident management process which set status or support team as activities show different angle each. In this context, it is obvious that the processes of two organization 'Org line A2' and 'Org Line C' could also have various figures as looked from different angles.
Considering angles to compare and analyze processes of two different organizations, therefore, is making a significant attempt. However, to compare processes of two organizations, we intend to set the combination of two attributes ('status' and 'sub-status') as activities. It is because that this setting shows the most typical figure of the process.
Creating a standard of comparing conformity between two processes, we focused on the components of process model. There are differences in process model components in notations. We, therefore, chose a notation used by Disco while there are many notations of process model. This notation consists of activities representable as square boxes and flows between activities representable as arrows. Accordingly, standard to compare the processes of two organizations are supposed to be activities composing processes and flows between activities.
To compare processes of two organizations, we extracted data from 'Org Line A2' and 'Org Line C' using the standard and range we set earlier(refer to <Fig. 35,36,37,38>).
To measure the conformity of a process of one organization to a process of the other, first of all, it was planned for two organizations to be compared each other based on the extracted data (in a structural perspective). Then we sought to compare every possible inter-organizational flows between two organizations (in behavioural perspective).
<Fig. 39> shows the activities composing incident management processes for two organizations and their occurrences. We observed several activities performed by 'Org Line C' which was not found on 'Org Line A2': 'Completed+Cancelled' and 'Unmatched+Unmatched'. There are differences, moreover, in occurrence frequency. For example, 'Org Line A2' and 'Org Line C' comprise 24.06% and 14.22% each of occurrence in 'Queued+Awaiting Assignment'.
As stated above, we sought to explore and compare the every possible process of two organizations. To explore every possible flows, we used a footprint matrix, which is usually utilized for comparing the conformity between (drawn)process models and event log in conformance checking which is one of the process mining methods.
Comparing activities composing incident management processes, we found that there are two activities, Completed + Cancelled and Unmatched + Unmatched, on 'Org Line C' only. We attempted in analysis, excluding events related to those two activities, to compare two processes in behavioural perspective. We moreover used alphabetic characters like <Fig. 41> instead of using names of activities for the convenience of expression. There are three commonly used symbols on footprint matrix here: #, →, ||. By using these symbols, we could easily find the differences between behaviours drawn from two processes. For example, 'X # Y' means that there is no relation between activity X and activity Y in terms of execution order. 'X → Y' means that activity Y follows activity X and there is no inverse scenario. Lastly, 'X || Y' shows that activity X is performed in parallel with activity Y. That is, activity X is followed by activity Y and the inverse scenario is also possible. The red boxes above on the footprint matrices show the differences found by comparing two organizations. We could recognize the parts showing differences between behaviours of two processes.
Besides, there is another method of comparing two processes: counting flows in each case and comparing them. There is comparative outcome via this method on <Fig. 43>. The last method, added to this, is to calculate the average time to make flows for each process and compare the outcome. <Fig. 44> contains the result of it. To compare problem management processes between two organizations, similarly, those methods mentioned above are used. As shown on <Fig. 45>, first of all, we used alphabetic characters instead of using names of activities which compose problem management processes, giving the convenience of expression. The following comparative methods are similar with methods used for comparing incident management processes.
Real life event logs of incident and problem management processes supported by Volvo IT's VINST system were provided for the BPI Challenge 2013. The two logs include 7554/2306 cases and 65533/9011 events respectively. Furthermore, several questions derived from four main issues related to the two processes were raised. To address the questions, we tried to understand the data and create relevant datasets for the questions. Moreover, we attempted to clarify the issues at the log data level.
Although we cannot get any feedback from Volvo IT's stakeholders about our answers and analysis results, we strongly believe that the answers and analysis results are plausible because they are evidence-based. For the first issue, push to front mechanism, we clearly identified products for which the mechanism is most used. Furthermore, we found organization and function divisions that comply with the mechanism. Recall that the mechanism increases work efficiently. Therefore, based on these findings, managers are likely to find ways to improve work efficiency such as sharing best practices of push to front mechanism among organizations and function divisions.
For the ping pong behaviour issue, we found the function divisions, organizations, and support teams responsible for most of ping pong behaviour. We also identified the products which are most affected by this behaviour. These finding help managers reduce the total life time of both an incident and a problem. For example, managers may decide against purchasing products leading to severe ping pong behaviour in the future.
Volvo IT, typically, recommends its action owners not to use the 'wait user' sub status. However, action owners do not always comply with the guideline. To address this third issue, we found who are mainly breaking it and explored the pattern of using 'wait user' sub status per support team, function division, and organization. We also identified locations where abuse of the sub status is found. Based on these findings, managers may give warning to nonconforming action owners.
Finally, we addressed the final issue, process conformity per organization. After defining the range of comparison in conformity, we compared the incident and problem processes of the two organizations (i.e., 'Org Line A2' and 'Org Line C') from structural and behavioural perspectives. Based on the findings, managers may decide where they should focus on to achieve process standardization between the two organizations' processes [3]. Overall, we believe that our process insights gained from the answers and analysis results can help managers precisely identify process improvement opportunities. Therefore we strongly recommend that more managers pay attention to these process mining and other analytical techniques for better process performance and decision making for process improvement initiatives in a big data world [4,5,7,8].
The authors are grateful to Dr. Anne Rozinat and Dr. Christian Gunther (Fluxicon) for providing them with an evaluation version of Disco and an accompanying copy of the BPIC 2013 dataset. They also thank Sara Lee for her translation help. The authors also thank PMIG (Process Mining & Intelligence Group) for helping data preprocessing with its software.