For the Third International Business Process Intelligence Challenge (BPIC'13), a collection of real-life event logs from Volvo IT Belgium is analyzed. The provided logs contain events from an incident and problem handling system which is called VINST. This report presents results related to the following investigations. First, an openminded exploratory analysis of the given event logs and second, answering the four specic questions posed by the process owner. To do so, we utilize both already existing as well as dedicated developed tools, and heavily combine traditional data analysis tools and process-oriented techniques; we indicate the existence of a gap between these two categories of tools and as such emphasize the importance of a hybrid approach in a process intelligence context throughout the report.
1.1 Overview This report presents the results we have uncovered related to the analysis of the Volvo IT data set in the context of the Third International Business Process Intelligence Challenge (BPIC’13). The data set consists of three real-life event logs from an incident and problem handling system called VINST.
The report is structured as follows. First, a high level overview of the data set
and the VINST system is provided in Section 2, to familiarize readers with the
provided material. Next, in Section 3, we perform an open-minded exploratory
analysis using ProM1 [
Vice versa, tools which are specically geared towards the analysis of process based data are often lacking in terms of ltering or descriptive statistics. Consider ProM, for example, which contains a plethora of plugins for the discovery of process models alone, but does not provide strong methods to lter or explore the data set at hand. In ProM 6, only two helpful ltering plugins are provided by default: Filter Log using Simple Heuristics, which allows to discard events based on their classication and traces based on their start/ending/contained events; Filter Log by Attributes, which is able to lter on traces containing events with a specic attribute-value pair. Advanced ltering options (e.g. value greater than x) are not provided.
The same can be said for plugins providing descriptive statics. Information about events per case, number of cases and events and other simple counts are easily retrieved, but no robust options are provided to derive other, more complex event data.
Due to the mismatch described above, practitioners and researchers currently
often nd themselves using an abundance of tools to perform their analysis tasks.
While this is not an insurmountable problem, of course, the fact remains that
available tooling towards the analysis of event logs can be improved. In fact,
this is one of the challenges also listed in the process mining manifesto [
As a summary, Table 1 provides an overview of the dierences between traditional data analysis tools and process oriented techniques. The main dierences arise due to a dierent starting viewpoint on the data at hand. Traditional tools work with at data tables containing record lines, whereas process oriented techniques are aware of the hierarchical nature between cases and events.
Other than the plethora of tools already available for (statistical) data
analysis and process mining, it should be mentioned that some work has also been
undertaken in order to add some process awareness or, more precisely, sequence
awareness to data analysis tools. TraMineR, for instance, is an R package [
The BPIC’13 data set is obtained from Volvo IT Belgium and contains events pertaining to an internally developed Siebel-based incident and problem management system called VINST. Three log les are provided: one for incidents, one for open problems and one for closed problems 3.
The incident management process aims to restore normal service operations after the occurrence of a specic incident within SLA dened boundaries. Incident cases are rst handled by a rst line desk (the service desk and help desks) and escalated to second line and third line teams when the rst line workers are not able to resolve the incident. Incident cases are assigned a priority level, which is calculated based on the impact (major, high, medium or low) and urgency (high, medium, low) of the issue, see Table 2. 3 DOI identiers for the data sets are: doi:10.4121/500573e6-accc-4b0c9576-aa5468b10cee, doi:10.4121/3537c19d-6c64-4b1d-815d-915ab0e479da and doi:10.4121/c2c3b154-ab26-4b31-a0e8-8f2350ddac11.
The problem management process tries to uncover the root causes behind incidents and implement xes to prevent the occurrence of further incidents in IT-services operated by Volvo IT and includes activities to update internal knowledge bases with discovered ndings. This process is primarily handled by second and third line teams. Contrary to the incident management process, there is no push to front system implemented for the problem management process which escalates cases among dierent service lines. The problem management and incident management processes thus work in parallel, where incidents are resolved as quickly as possibly in a reactive manner while the underlying root cause is xed by a problem management case. These two workows are supported by the Volvo IT VINST tool. The tool also supports other workow processes such as handle questions and major incident procedure , but these are not incorporated in the BPI challenge data set.
The data set lists the following attributes for each logged event line: Next section describes an exploratory analysis of the three event logs.
3.1 Descriptive Statistics Using ProM and Disco, we perform some initial analysis on the given three event logs. Some rudimentary, process based descriptive statistics are listed in Table 3. We use the default classier as stored in the event logs to classify events to a set of activities, namely the combination of Status and Sub Status attribute elds. For each event log, the total number of cases and events is listed, together with the number of distinct cases (the dierent variants). Next, the total number of event classes found in the event log, together with how many of these appear as the rst or last activity in the traces contained in the event log is shown. Finally, Table 3 also lists the minimum, average and maximum case length (i.e. number of events).
Especially for the incidents event log, the numbers indicate a large amount of variability. As shown by Fig. 1, a large number of trace variants exist which occur only once in the event log, leading to a skewed distribution in the number of cases for each variant. Next, table 4 shows an overview of the dierent attributes (described above) with their number of values and mean of frequencies of the values for the three event logs.
Let us now take a look at some performance related characteristics for the given event logs. When we plot the mean duration for the cases represented by a variant against the number of cases itself, a relation can be observed between the rarity of a trace variant and its running time, as depicted by Fig. 2a. One is free to remove these peculiar traces from the data set before continuing on with further analysis, we but choose to leave these exceptional cases alone for now. A similar observation can be made when plotting the case duration for all cases, for example as shown in Fig. 2b for the incidents log. Observe that a small number of cases exists which run for a high amount of time, with the longest trace taking 2.11 years.
Variants
Next, Fig. 3 inspects the relationship between a case’s duration and the involved product or impact level of the case. We observe that there exists a strong correlation between the product a case relates to and the required running time for that case. Indeed, this is to be expected, as is seems reasonable to 0 0 8 l) e trcaS 400 q S , (sayD 200 n o ti raunD 50 eaM 01 0 l)ace 600 S g o (sseL 400 a C f .roN 200 0 0 8 0 0 500
1000 Nr. of Cases
1500 (a) Scatter plot showing the mean duration in days for each variant against its number of occurrences. Many exceptional variants also exhibit a long duration.
Variants (b) Case durations (shown in days) for all cases included in the event log. assume that some products (such as PROD507, PROD34 and PROD681 highlighted in Fig. 3) lead to incidents which are harder to resolve, due for example to the complexity of the product. Concerning impact levels, the box plots shown in Fig. 3 do not immediately reveal a great dierence in duration medians, although there does exist a signicant dierence between the mean durations over the impact levels (which are 9.7, 13.7. 16.2 and 8.3 days for Low, Medium, High and Major impact respectively).
We can also derive performance related statistics for the support team member (Owner First Name) and countries (Owner Country). However, contrary to products, support teams and member are event-attributes, and can thus vary within a case. When we would group traces as done above (e.g. a trace belongs to the group associated to Sam when one of its events was executed by Sam), this would lead to a skewed distribution as perhaps only one event in a long trace was executed by a certain support team member. We are thus interested in knowing the duration of certain tasks executed by the various support team members, rather than the duration of the whole case.
Sadly, the provided event logs do not contain starting and stopping times for each activity. Instead, activities are logged as atomic events, i.e. only with a single time stamp, and are assumed to have a duration of zero (instant completion). Still, when relating task durations to support team members, we nevertheless would like to have some idea about how long the case was being handled by a certain person before moving on to the next activity (and, perhaps, some other support team member). Therefore, we apply a simple pre-processing step where we assign a completion time to each event equal to the (starting) time stamp 0 0 3 )sy 250 a (noD 200 it rauD 150 n eeaM 100 saC 05
(b) Box plots depicting case duration statistics per impact level. Although no strong dierence among the medians (shown by the box plots) becomes apparent, the variance decreases for higher impact levels. The means of the dierent impact levels also signicantly dier at the 95% condence level. of the event following directly after in the same trace. If there is no such event, we just set the completion time equal to the starting time and assume this nal event was instantly completed. This allows us to derive how long a particular case stayed with a particular activity, and hence, support team member 4. Once done, we can easily extract various sorts of information for the support team members and countries. Table 5 provides an overview of mean activity durations for activities, support team members and support team countries, as well as a task-originator matrix for the support team members.
As always, these initial exploratory results must be carefully interpreted to avoid reaching to erroneous conclusions. The common warning given when dealing with performance-originator oriented statistics indeed states that the fact that someone is taking longer to do their job might simply be because this worker commonly deals with harder jobs which take longer to resolve. Additionally, using the mean duration may lead to misleading results under skewed distributions; for example, the median duration for Anne Claire’s activities is a just a few seconds. The standard deviation for the workers with high mean 4 Note that we assume the time stamp present in the logs to denote the starting time of a particular activity. Only when this activity is completed does the next event start. shown.
activities for the incidents event log.
(a) Mean activity durations for all activities based on derived completion times. Again, Status plus Sub Status is used as a classier to construct activities.
Activity Accepted/Wait - Vendor Accepted/Wait - Implementation Accepted/Wait - Customer Completed/Resolved Accepted/Wait - User Accepted/Wait Accepted/Assigned Queued/Awaiting Assignment Accepted/In Progress Completed/In Call Completed/Closed Unmatched/Unmatched Completed/Cancelled
Mean Duration (Hours) members are shown, sorted by the number of activities executed (summed last row). Queued/Awaiting Assignment Accepted/Assigned Accepted/In Progress Accepted/Wait Accepted/Wait - Implementation Accepted/Wait - User Accepted/Wait - Vendor Accepted/Wait - Customer Completed/Cancelled Completed/Resolved Completed/In Call Completed/Closed Unmatched/Unmatched Sum durations is high, caused by a few (or even just one) activities taking a long time to be passed forward. This is evidenced by Fig. 4, which shows a small number of activities with a very high duration (i.e. more than one year). The process owner can inspect these activities and the cases they belong to in order to verify if further action should be undertaken. Furthermore, keep in mind that we have derived activity durations based on a single time stamp present in the log les, which might dier from the actual work time.
Activities
We limit the statistical description to the overview provided above, as not
to consume too much space. Nevertheless, this section illustrates the power of
using simple, at data oriented tools already widely available to get a rst,
solid introspection in the performance and characteristics of running processes.
However, since these tools lack a process oriented perspective, it is dicult to
derive statistical information at the trace level (a grouping of events) rather
than at the event level, as was already encountered in this section. This already
emphasizes the need for a hybrid approach. Therefore, we also briey explore
the data set using process specic tools, namely ProM and Disco.
3.2 Process Mining
Mining the incidents event log using HeuristicsMiner [
Broucke et
al. (a) use the
Mo del mined with HeuristicsMiner in a custom created plugin which allows graph annotations).
ProM (we to provide 12 2 120 3 1 90 5704
Complet d/Closed 5716
5 Unmatched5/Unmatched (c) The same mo del mined with a custom built pro cess discovery to ol, which runs on top of Pandas (another statistical data analysis to ol; see http://pandas.pydata.org) and extracts pro cess ows together with summarizing metrics from a at event table. This is then exp orted to a pro cess graph (using Graphviz). This illustrates that the integration of pro cess-oriented p ersp ectives within traditional statistical to ols is indeed p ossible.
Let us see whether we can derive a straight-through process, a simple process map explaining the multitude of behavior found in the event log. Filtering on the frequent variants provides a solid means to do so. Fig. 6 shows the process map derived from the ve most frequent variants, accounting for 41% of all traces in the incident log.
300 2828 Accepted/In Progress
6511 555 855
203 Queued/Awaiting Assignment 855
Accepted/Wait - User 203 2828 1176 203
When we just use the Status attribute as a classier, the resulting process model becomes even simpler, and just shows all transitions between the Accepted, Queued, Completed and Unmatched statuses, see Fig. 7.
Since the process described a ticket based issue handling system, and since the event logs do not contain start and ending times by itself (unless approximated with a pre-processing step as done above), we can assume that the process does not contain any parallel behavior, i.e. process case is passed on from one activity to the next, without an activity create two or more concurrent ows of work. That said, it is thus possible to view the process as a Markov chain, i.e. as shown in Fig. 8 (once more using both Status and Sub Status elds), similar Accepted 40117
21713 to the process maps obtained by Disco, the depicted graph is also able to quickly highlight the most important ows from one activity to the next.
We can also easily show some initial performance focused process maps. Fig. 9 depicts the maximum and mean waiting times between activity occurrences. Note the discrepancy between the mean duration and the maximum duration, also indicating the presence of low-frequent exceptional cases which run far longer.
Queued/Awaiting Assignment instant
Queued/Awaiting Assignment
instant 8.3 hrs 67.7 mins
One can continue to apply various other lters and views in order to extract additional process maps. Fig. 10, for instance, shows the process map obtained for the incidents log after ltering on performance (keep only quickest 95% of cases, i.e. taking less than about one month), endpoints (cases should start with either a Accepted or Queued activity and end with Completed), time frame (rst of January 2012 onwards), and variation (use only cases whose sequence of activities is shared by at least two cases). The process map is quite readable and easy to interpret, but does not help further towards gaining more insights, which requires rst stating the goals and questions one wants to investigate. We will do so in the following section.
This section explores the questions posed by the process owner in the context of the BPI challenge. Four broad questions were outlined, which will be dealt with accordingly in the following subsections. 4.1 Question 1: Push to Front This question only applies to the incidents event log. In this process, a strategy is put in place which states that most of the incidents should be resolved by the rst line support teams. The process owner is interested in knowing how many (and which) cases escalate to a second or third team.
The provided case description is somewhat ambiguous concerning which criteria exactly determine whether an event was executed by a rst line team. It is stated that The second line could be a support team within Org line C or a support team working with Org line A2. This might lead one to believe that all teams not belonging to either Org line C or Org line A2 are the rst line teams. However, inspecting the Involved ST eld in the data set includes names such as V5 3rd and V13 2nd 3rd, which leads us to believe that the level assignment is included in this moniker. Therefore, we will add an extra eld to the data set. Support team names including the strings 2nd or 3rd will be regarded as an above rst level team (second, third or both). Names not including such string shall be regarded as rst level teams.
Next, we import the data set in Disco, but specify the Involved ST as the activity and derive the following case counts: 7554 cases in total, creating an unstructured model. 4782 cases exist (63%) which did not require intervention from a second or third line support team. This is obtained by applying an attribute lter. 2772 cases (the others) did pass through a higher level team. 704 of these cases even immediately start in a higher level. 556 cases start and stay within higher level teams during their complete life cycle. This is a peculiar result. Fig. 11 shows the three most involved support teams (all paths shown) where this happens.
For what products is the push to front mechanism most used? We export the cases found with Disco and turn to R to answer the posed subquestions. After some straightforward operations, we derive for each product the number of times the product got involved in a case passing through a higher level support team. Fig. 12 shows a scatter plot showing the number of cases each product was involved in for which the case did not go through second or third level support teams (blue color) or did escalate to second or third level 2 5 1 1 5 l a C n I p m o C /ed 941 t le 1 3 3 4 5 7 0 3 5 2 2 7 2 1 6 r e s U it a 8 /W 72 d 1 e t p e c c A 0 7 7 3 d e v l o s e e l p m o C /R 8 ted 363 7 6 8 1 d e s o l C / 2 d 6 te 5 le 3 p m o C 5 3 frame, performance and variants. Activities with an absolute frequency less than a thousand are ltered out as well. All paths are retained. support teams (red color). We can indeed notice some products being escalated frequently to higher levels. Table 6 shows the twenty products with the highest number of cases with second or third level support team involvement, together with the number of cases without escalation.
What is the impact of incident escalation on performance? We did not nd a clear relationship between mean duration for all cases relating to a certain product and the number of times the product was involved in a case escalated to second or third level support teams (or not involved). However, there is a signicant dierence in means of case durations for products which were never involved in an escalated case and product which were (8.6 versus 16.5 days). There also exists a signicant dierence in means of case durations for cases pushed to second/third level teams and cases that did not, i.e.: an average case duration of 20.5 days versus 7.2 days. Avoiding higher level escalation is thus indeed an important goal to be maintained.
We have also inspected the impact of escalated incident cases on the duration of problem handling cases, as the case states that cases ending up in second or third line support teams disturbs them from doing their core activity (which is generally not support) and that handling problem cases are primarily the responsibility of 2nd and 3rd line support teams. It might thus be interesting to see if we can nd a correlation between the performance of second and third line teams in the problem handling process (one of their main tasks) and the number of active escalated incident cases (which disturb them). Fig. 13 shows the resulting outcome. The thick lines represent the number of cases over time (all incident cases, escalated incident cases and problem cases both open and closes), whereas the dotted lines show the mean and median duration of problem cases active in the same time window. No signicant correlation can be derived. This might be due to the data set (incident cases arrive neatly over time but s se 0 a 0 fC 3 o r eb 00 m 2 u N 0 0 5 0 0 4 0 0 1 0 Product
Products almost always keep running until the middle of 2012). Also, in our analysis, cases are seen as escalated even when they are not yet escalated at a specic point in time (note however that this does not impact the median duration of problem cases, which stays stable over time anyway). More data is needed to perform a more rigorous analysis, or it might simply be that there exists no correlation between these two specic properties.
)sed )sy rd a un (D
n (H io s t
a sea ru 0 6 0 5 0 4 0 3 0 1 0
Active Incidents over Time Active Excalated Incidents over Time Active Problems over Time (Open and Closed) Mean Duration of Problem Cases (Open and Closed) Median Duration of Problem Cases (Open and Closed) 2010 2011 Time 2012 Fig. 13: Impact on number of escalated incident cases on duration of problem cases over time.
Where in the organization is the push to front process most implemented, specically if we compare the Org line A2 with the Org line C? What functions are most in line with the push to front process? Finding out which organizational lines (or support teams or functional divisions) were best able to deal with incidents without escalating them is non-trivial, as these are event-related attributes and do not necessarily remain constant over a complete case, so that deriving event based counts (e.g. with Disco) leads to skewed distributions when cases contain varying number of events.
For the organization lines A2 and C, we can apply an attribute lter to retrieve the number of cases. Of the 2772 cases which were escalated to higher level teams, 1298 of them were handled by Org line A2 at some point, whereas 1950 cases were handled by Org line C.
For the involved support teams (and functional divisions), it is bothersome to re-apply a lter for each dierent support team. Hence, we switch once more to R. We aggregate all escalated and non-escalated cases by support team and use the length of the unique list of Case IDs (SR Number) as the aggregation function to get, for each support team, the number of cases the team was involved in (for at least one activity) (only taking cases into account which escalated or did not escalate to a higher level team). We then order the teams based on their relative frequency dierence between escalated and non escalated cases to account for the dierent number of cases. Table 7 shows the resulting overviews. An overview for organization lines was included once more. Note the absence of Org line C is this listing: although this line handled 1950 cases which were escalated, the organization also handled 4176 cases which were not escalated, so that this organization is dropped after deriving the relative frequency dierence. 4.2 Question 2: Ping Pong Behavior The case description states: It occurs that support teams start to send incidents to each other again and again (ping pong) which of course is an unwanted situation. The business owner is interested in nding out about such cases. First, we have to be clear about what exactly is meant with ping pong behavior: The attribute of interest is the involved support team; Ping pong is dened as a case starting with support team A, moving then to another support team B (ping) and nally coming back to A later on (pong). For example, we will consider the following support team trajectory as being acceptable: hA; B; C; Di, although many support teams are involved, while the following is not: hA; B; C; A; Di.
No information about status requirements are given. Note that it is however possible to perform an additional check here, e.g. also require that the Queued/Awaiting Assignment status is revisited again when switching support teams.
Let us start with investigating the incidents log. We rst lter out all cases which stay with the same activity (here: the involved support team), by using a Follower lter in Disco which allows any activity succession but requires dierent values for each matched pair. This leaves us with 50% of the ping cases (3820 cases). Next, we want to get the pong behavior (returning to a previous support team). This is less easy to retrieve with Disco, as the follower lter cannot be applied here. As such, we search for tandem repeats using R and the following aggregation. We aggregate by Case ID (SR Number) and apply a custom function to signpost cases containing tandem repeats. The method we apply is a bit involved and further detailed in Listing 1. We nd 1258 cases with ping pong behavior.
We can then export these cases to Disco again for visual validation and analysis. Fig. 14 shows a simplied process map containing the ping pong cases with some support teams hidden but all paths shown. Back-and-forth ping pong behavior is indeed clearly visible.
(a) Organization lines.
Second or Third (%) Level Involvement 1298 46.83% 408 14.72% 318 11.47% 85 3.07% 50 1.80% 37 1.33% 23 0.83% 13 0.47% 15 0.54% 5 0.18%
First Level (%) Involvement Only 501 10.48% 219 4.58% 242 5.06% 41 0.86% 4 0.08% 32 0.67% 14 0.29% 4 0.08% 16 0.33% 4 0.08% (b) Involved support team.
Listing 1: Finding ping pong behavior.
# Assume the following trace with ping pong behavior
# ( return to b):
> trace <- c(’a ’, ’a ’, ’b ’, ’c ’, ’b ’, ’d ’)
# " Match " all elements equaling b:
> match (c( trace ) , ’b ’, nomatch =0)
[
226 16 58 G96 817 14 61 V51972nd D4 1100 47 653 57
572 92 96 123 D5 1408
Is there a correlation between the ping pong behavior and the total life time of an incident? Fig. 15 shows a scatter plot with case durations separated by cases with (colored red) and without ping pong behavior (colored blue). Contrary to the statement made in the case description, no signicant correlation becomes apparent. A Welch Two Sample t-test conrms that the means of 1.47 (ping pong) days and 1.35 days (no ping pong) are not signicantly dierent at the 95% condence level.
Table 8 summarizes the ndings of ping pong behavior for the three event logs. Since the problem processes do not contain separate elds for the involved support team and support team functional division, we have only used the latter for these logs. We note that the relation between duration and ping pong behavior is not so clear as it may appear at rst sight. For instance, we nd that closed problems which do exhibit ping pong behavior are closed faster than those which do not. One might suggest to inspect the correlation between case duration and the number of ping pongs performed, but we did not nd any particular pattern when doing so for the incidents log (using the number of support teams which ping ponged out of the total support teams involved in the case). What are the functions, organizations, support teams responsible for most of the ping pong? What products are most aected by it? Due to space limitations, we only include the results for the incidents log. The same approach can be applied to the other logs. Again, we aggregate at the trace level, rather than the event level to account for skewed results. Table 9 lists the ten highest products, support teams, functional divisions and organization lines for the cases containing ping pong behavior.
) s y a D ( n o i t a r u D 0 0 5 0 0 4 0 0 3 0 0 2 0 0 1 0
with with
Cases
No (p-value: 0.10) No (p-value: 0.31) Yes (p-value: 0.00), 22 versus 3 days 4.3 Question 3: Wait User Abuse The challenge case states: People try to nd workarounds that stop the clock from ticking. One way of doing this is manually giving an incident the sub status ’wait user’. Although there are guidelines not to use this sub status, some people are breaking this guideline.
We again use the incidents log to inspect this behavior. We’re interested in the Sub Status Wait - User, which only occurs together with the Accepted main status. We can thus lter on this activity which results in 33% of the cases containing the Accepted/Wait - User activity.
Who is making most use of this sub status (action owner)? What is the behavior per support team, function, organization etc? To delve deeper into this behavior, we inspect how long cases stay within the Accepted/Wait - User state before another state becomes active, and will correlate this with other properties. Table 11 provides an overview of the ten support team members having spent most time in the Wait - User state, ranked by the median to account for exceptional outliers. Again, one should take care not to derive conclusions too quickly. We could, for example, lter out owners such as Susanne whose minimum duration does not exceed a certain threshold. Alternatively and perhaps a better approach since we do not possess starting and completions times of activities, we could also check for the absolute number of times someone activated the Wait - User state, instead of inspecting the duration. This provides the following list: Siebel, Pawel, Muthu, Brecht, Marcin, Fredrik, Andreas, Katia, Krzysztof, Emil. Just as for the previous questions, this count can also be aggregated at the case level. Follow-up questions by the process owner can thus quickly result in more ne-tuned analysis.
We close this question with Table 11, which provides an overview of the ten highest support teams, functional divisions, organization lines, countries and owners making most use of the Wait - User status, ordered by the number of times the associated actor executed a Wait - User status transition. 4.4 Question 4: Process Conformity per Organization This question pertains to Org line A2 and Org line C: In general the Volvo IT organization is spread in two organizations: Org line A2 and Org line C. It would be interesting to see how conform or how much in line every organization is with the incident and problem management processes.
This is an open-ended question for which more domain knowledge must be gathered before it can be answered in a satisfactory way. The main question is what is meant with in line. One particular perspective was already focused upon when dealing with the rst question: which of these two organization lines perform most case escalations to higher level support teams?
When being in line is related to case duration, we can derive the mean case durations for Org line A2 and Org line C respectively: 21 days versus 10 days (for the incidents log). When SLA’s are set on total running time of case, the outcome might, however, be dierent. Consider for example an SLA determining that incident handling cases may take at most 7 days (one week). Now Org line A2 violates this 1494 while Org line C performs worse: 3529.
Finally, it is also possible to view in line conformance in terms of a prescriptive process already in place. Ticketing based systems such as this one, however, are not often subjected to such designed processes, as is also evidenced by the unstructured nature of the full process map with no ltering applied. As a proof of concept, however, let us assume a designed process as shown in Fig. 16. We will only make use of Status transitions to allow for enough freedom for the sake of this example. We assume that cases must start with an Accepted or Queued status. Both these statuses can repeat, and it is possible to go from one state to another as well. Finally, cases must be ended with a Completed state following Accepted.
Completed Accepted
Queued
Fig. 16: An example designed prescriptive to-be process model.
We load this model into ProM in order to perform control-ow based conformance analysis. We use the alignment based conformance checking plugin by Adriansyah et al. [1315]. Fig. 17 shows the results of the conformance analysis. Inspecting the trace tness distributions (a measure of being in line with the prescribed process), we can derive that Org line A2 is less conform (relatively) than Org line C. Keep in mind, of course, that we have used an example model. By comparing the as-is situation with the to-be model, it becomes possible to implement changes in order to try to x problem areas.
This report presented the results we uncovered related to the analysis of the Volvo IT data set for the Third International Business Process Intelligence Challenge (BPIC’13). An open-minded exploratory surveyance of the data set was performed, followed with a deeper analysis towards answering the specic questions posed by the process owner.
To do so, we have applied both traditional data analysis tools and
processoriented techniques. As evidenced by this report, there exists a gap between
these two categories of tools, causing diculties when ltering, querying,
exploring and analyzing event based data sets, as is also put forward as one of the
challenges listed in the process mining manifesto [
(c) Aggregated overview highlighting conformance issues.
Fig. 17: Conformance analysis results for Org line A2 on example process model.
We would like to thank the KU Leuven research council for nancial support under grand OT/10/010 and the Flemish Research Council for nancial support under Odysseus grant B.0915.09. We thank VØronique Van Vlasselaer for her insights regarding R.