Multidimensional process mining is an emerging approach that adopts the concept of data cubes to analyze processes from multiple views. This enables analysts to split event logs into a set of homogenous sublogs according to the case and event attributes. Each sublog is independently analyzed using process mining techniques resulting in an individual process model for each sublog. These models can be compared to identify group-related di erences between the process variants. In this paper, we derive a number of general research questions addressed for multidimensional process mining by a literature review. We analyze the requirements for its application and point out its limitations and challenges. We conduct two case studies applying multidimensional process mining in two di erent use cases to evaluate our ndings.
Process mining [
Usually, process mining techniques only consider one event log resulting in a single process model. However, analysts are often interested in particular parts of the process or particular cases (e.g., not meeting a given quality requirement).
Although it is possible to lter the event log to derive the desired view on the data, this is kind of laborious and time-consuming if done manually, especially if multiple process models should be compared. The notion of multidimensional process mining (MPM) is an emerging approach that tackles this problem by adopting the concept of data cubes from the data warehouse domain.
The basic idea of MPM is to interpret the attributes from the event log as
dimensions which form the edges of a multidimensional data cube. Each unique
combination of dimension values refers to a cell of the cube that typically
contains event data (sublog). Using OLAP (Online analytical processing) [
The objective of this paper is to analyze, for which kind of non-domainspeci c questions MPM is suited for. Based on a literature review, we specify a classi cation of dimensions that characterizes a dimension with respect to the underlying process. Furthermore, we analyze the general requirements that have to be considered to successfully apply MPM. Additionally, we identify limitations and challenges of MPM in general that are not speci c to a particular approach and which should be tackled by future research. We validate our ndings in two case studies applying MPM in di erent scenarios. 2
We reviewed of MPM-related literature to identify typical questions, dimension classes, data requirements, limitations, and challenges. Table 1 summarizes its results. Aspects that are considered in or that are relevant for the publication are marked with X, while irrelevant or unconsidered aspects are marked with . We discuss the results in the following subsections in more detail.
We have to point out that this literature analysis underlies a number of limitations. First, our analysis is based on a relatively low number of publications because MPM is an emerging part of process mining research and has not attracted that much attention so far. However, the discussed publications clearly show the upcoming demand for MPM in the process mining community. Second, the reviewed publications mainly focus on conceptual work mostly giving only little information about the questions driving their case studies, the available dimensions and the identi ed limitations. 2.1
In contrast to traditional process mining, MPM does not discover a process model from a single event log, but multiple models from a set of sublogs. Therefore, the main question of MPM is not only (1) how does the process look like?, but also (2) what are the di erences between several processes or process variants? and (3) how are these di erences determined by the dimensions representing instance or event related features? Another typical question for MPM is (4) How does the process evolve over time? Of course, the speci c questions are domain-related and depend on the process. However, there is a number of dimensions that are supposed to be of a strong interest throughout several domains. Based on the literature review, we identi ed six classes of dimensions.
Customer-related dimensions describe the features of the customer and are typically used to group similar customers in MPM. Typical examples are age and gender.
Product-related dimensions describe features of the product (or some other subject that can be considered as a "product" in the widest sense of meaning) related to the process. Typical examples are product types and variants. Provider-related dimensions characterize the environment of process execution, namely the executing organization. Typical examples are the executing department, the location of a branch o ce, or the executing organization itself if multiple organizations are compared to each other.
Execution-related dimensions describe features related to the execution of a process instance. In contrast to the previous dimensions, they do not characterize external entities but the process execution itself. Therefore, these features are determined during the execution of the process. Examples are the urgency of treatment, the type of surgical intervention, and the diagnose. Quality-related dimensions This kind of dimension characterizes the quality of the process result. In contrast to execution-related dimensions, their values are not captured throughout the execution of the process, but at the end of the execution or even shortly before it if the result is already foreseeable.
Examples are the outcome of the treatment and the reason for discharge. Time-related dimensions describe the temporal classi cation of cases and events. Even though there is only one notion of time, it may be expressed by multiple dimensions (e.g., start or end time of the process execution).
Time-related dimensions are special as they may be used to de ne chronological orders of process instances. This is necessary to answer the question of process evolution (4) which is analyzed by creating and mining sublogs according to chronologically ordered time intervals, e.g. by the year of the process execution. Comparing these process "snapshots" can reveal changes of the process over time indicating concept drifts. 2.2
Generally, the more dimensions are available in the data cube, the more multifaceted questions arise during the analysis. Therefore, all available attributes should be integrated into the data cube to avoid restricting the possible analysis space of the OLAP queries, even though the contribution of a dimension to the analysis might not be clear in advance. This enables the analyst to de ne unforeseen ad-hoc queries.
Another important data requirement in the context of MPM is the representativeness of data. To discover a meaningful process model, the event log must contain a representative number of cases. MPM partitions the event data into a set of multiple sublogs, each containing only a fraction of the original data. Therefore, MPM usually requires a multiple number of cases and events to ensure representativeness. Additionally, the data should be to some extent equally spread across the multidimensional space. Otherwise, the data distribution limits the number of meaningful models. As the distribution of data is given by the data attributes, it is not possible to enforce representativeness for all combinations of dimensions. Therefore it is mandatory, that the analysts carefully check the number of cases and events to avoid misinterpretations. However, we recommend to consider this problem during data integration by de ning categorial values for the dimensions. Non-categorial values should be mapped to meaningful classes of values to avoid sparsity and improve the representativeness. For categorial attributes with many values, we also recommend to de ne a classi cation hierarchy (e.g., introducing additional 5-year and 10-year age classes) to allow for aggregation which typically improves the representativeness of cells.
The comparison of cells seems to be the major challenge of MPM. Even with
advanced concepts like di erence views and process model consolidation [
We conducted two case studies to evaluate the ndings presented in Section 2. 3.1
The HEP data contains events related to university courses in Computer Science
collected based on a service-oriented teaching platform [
The case study revealed changes in the structure of a course held in two consecutive years. For example, the number of exercises was reduced while more feedback was given by the lecturers (cf. Fig. 1). Comparing the process variants of a particular course for the di erent nal marks also showed interesting similarities and di erences. E.g., the rst steps of the process were exactly the same for all variants, starting to diverge with the evaluation activity for the rst project phase. The process variants also clearly show that students with worse marks tend to struggle earlier during the course and that students who failed the course gave up working on the nal exercises. This is also re ected by the average number of events per case, clearly showing that good students are signi cantly more active than students who failed.
In this case study, all questions (1) to (4) were addressed (see Table 1). The considered dimensions cover all dimension classes, also the product-related dimensions (e.g. course dimension, considering the knowledge transferred to the students to be the universities "product"). Moreover, the case study con rmed that all available attributes should be considered to build up the data cube. E.g., we used the number of compiler errors and warnings recorded with the compile events in several ad-hoc queries. These attributes were integrated into the data cube, though they were initially considered to be useless for the analysis.
The case study also con rmed that the representativeness is mandatory for MPM. We were not able to pose several queries due to missing data resulting in sparsity. Furthermore, the case study showed that MPM in general still has to face a number of limitations and challenges. The main limitation was the di culty to compare the processes, even though we applied advanced concepts like the automatic creation of di erence models. The integration of data also took a signi cant higher e ort (e.g. for de ning dimensions) compared to the creation of a normal event log. This supports the identi ed limitation and emphasizes the need for a better tool support for integrating the data into the cube structure. Finally, the lack of interactivity was con rmed as ltering and similar operations cannot be triggered directly from the process model, which makes it sometimes quite cumbersome to change the view on the process. However, performance issues could not be con rmed during this case study due to the relatively small set of data. The challenge of concept drifts was not con rmed as well, because changes of the process during run-time were not expected (all process instances were performed in parallel during the semester). 3.2
This case study analyzes the data from [
We analyzed process logs from a department in emergency cases. The change analysis was well suited to examine exceptional situations which should not occur in an usual setting. For example in some cases, the termination of anesthesia was initiated before the clearance of the surgeon. We also found some process instances where additional radiological examinations occurred after the surgery { this may be a hint that something went wrong and additional tests have been required. In some cases, we found admission events after the discharge. This can happen when data acquired at the patients admission had to be corrected or complemented, e.g. due to missing health insurance information. Finally, we found some cases containing steps which hinted at another upcoming surgery.
Change mining provided interesting results, especially for detecting exceptional situations. Typically, the change trees grow in width very fast, which can be partially avoided by ltering non-relevant events which e.g. only exist to add missing data to a patient's pro le. Also the aggregation of self loops of certain events reduced the trees' depth and improved the analysis (cf. Fig. 2).
During the case study, we considered all general MPM-related questions (see
Table 1). Aspects related to data integration were not considered, because we
reused an existing data cube. For the same reason, the available dimension classes
were similar to [
The results of the case studies generally con rm the ndings of the literature analysis. Note that the issue of concept drift (beyond the general question of process evolution) was not relevant in both case studies. Due to the little number of publications, more case studies are required to demonstrate the potential of MPM and identify its limitations, providing a clear direction for future research.
Nonetheless, we were able to identify requirements, that need to be met for the successful application of MPM. An extensive data base is crucial for MPM. On the one hand, MPM requires a multiple number of cases and events compared to traditional process mining. On the other hand, it requires many (preferably all available) additional attributes that can be exploited to aggregate and lter the data. To ensure representativeness of results, the di erent dimension values should { at least to some extent { be equally distributed across the cases and events. Dimension values should not be related to only a few cases and events, which is a stricter requirement than only avoiding sparsity.
The biggest challenge remains the comparison of cells, even though there are initial approaches to tackle this problem. Another major challenge is the performance, because long processing times disrupt the explorative process analysis. The problem of missing interactivity of the process mining results (in the sense of direct interactions with the process models) has not been considered, so far. However, we believe that interactive process mining will draw more attention in the future, also in the context of traditional process mining. Minor limitations are the high initial e ort for data integration and the handling of concept drifts.
Recommendations: We recommend to use MPM if the analysis aims to compare processes or process variants or a multitude of ltering is required (even without comparing di erent models). It may also contribute to the analysis of process evolution. Furthermore, we recommend to use MPM if the processspeci c research questions are not clear in advance and should be re ned during the analysis. On the contrary, there are also situations that are not suitable for MPM. We recommend to use traditional process mining approaches if only a very limited number of cases and events or only a very few attributes are available in the event data. Traditional process mining can also be the better choice if the additional e ort for creating the dimensions etc. exceeds its utility. This may be the case if only a few and simple ltering of the event log are expected or if only a (fast) overview of the overall process is needed.