Introduction

Process mining aims at extracting information from events recorded by information systems, with the ultimate goal to provide insights into the executed processes based on the analysed ICPM 2024 Tool Demonstration Track, October 14-18, 2024, Kongens Lyngby, Denmark * Corresponding author. † These authors contributed equally. Envelope anti.alman@ut.ee (A. Alman); a.arleo@tue.nl (A. Arleo); i.m.beerepoot@uu.nl (I. Beerepoot); andbur@dtu.dk (A. Burattin); claudio.diciccio@uniroma1.i (C. D. Ciccio); resinas@us.es (M. Resinas) Orcid 0000-0002-5647-6249 (A. Alman); 0000-0003-2008-365 (A. Arleo); 0000-0002-6301-9329 (I. Beerepoot); 0000-0002-0837-0183 (A. Burattin); 0000-0001-5570-0475 (C. D. Ciccio); 0000-0002-0837-0183 (M. Resinas) data [1]. Event data may vary based on the process domain, and typically covers different dimensions (control flow, time, resources, object lifecycles). A critical, yet largely unaddressed, issue of process mining is the inability to navigate through distinct, and possibly domain-specific, dimensions [2]. This limitation reportedly hinders process improvement investigation [3], as it narrows the analysis scope to a partial view over an inherently complex search space, which is typical of knowledge-intensive processes [4,5]. In the discipline of visual analytics, the problem of representing complex, multi-faceted phenomena has been extensively studied [6]. This is also the type of phenomena often encountered within real-life business processes.

In previous work, we thus introduced Tiramisù [7,8], a novel conceptual framework leveraging visual analytics principles [6] to enhance process mining with an interactive investigation of data integrating process-specific and context-related information. Tiramisù is designed in a pluri-layered fashion, to equip end users with a context-aware visualization mixing classical process mining representation elements -such as workflow nets or directly-follows graphs [1]with additional diagrams and visual cues tailored for context-variable and metadata representations (e.g., timelines and calendars for time, geographical or floor maps for space).

In this demo paper, we illustrate Tiramisù's core ingredients and two variations of the recipe, i.e., prototypical implementations grounding its components into usable toolkits. In the tiramisù metaphor, the backdrop is akin to the cream that infuses all the layers of the dessert. Superimposed layers can represent both process-related and non-process-related data. We distinguish between the following two types of dimension layers: Overlay layers enhance the visualization by mapping data onto new layers that are placed over the backdrop; On-demand layers provide additional contextual information for individual elements or small groups of elements. These layers can be activated by interactions such as hovering over or clicking on elements of the backdrop or those representing the process. Layers can encapsulate the behavior of the process being studied, similar to how the coffee-soaked ladyfingers provide structure and texture to the dessert. Overlay layers explicitly anchor to the backdrop, thus contextualizing the information.

Recipe (Architecture)

For example, in case of a floor plan, the data on overlay layers would directly link to that floor, facilitating the user's understanding of how events are related within the same location.

Serving Suggestions (Functionality)

Here we describe two implementations of Tiramisù, focused on different classes of knowledgeintensive processes. Their names are inspired by variations of the tiramisù dessert: Berries, pertaining to healthcare [9]: and Banana, focusing on personal information management [10].

Berries (Behavioral Deviation Analysis in Healthcare)

Figure 2: Screenshot of Tiramisù application depicting a morning routine.

The first instance of Tiramisù has been designed to help understanding deviations from personal behavior in the context of healthcare. In this case, in particular, we can analyze whether the daily routines of a person in a nursing home are maintained over time or not (as possible symptoms of worsening of neurodegenerative diseases). Simply applying existing process mining techniques to this task might result in basic process maps where nodes represent various patient activities and arcs indicate dependencies or temporal constraints among these activities [11].

The system , which is designed to emphasize the spatial dimension of processes and activities happening in different locations, is implemented as a JavaScript application using the Vue.js framework 1 . A screenshot of it is reported in Fig. 2. It takes a URL of a JSON configuration file and a DFG file describing the process as input. The configuration file specifies the backdrop as the floor map and the placement of different activity representations on top of it.

Banana (Personal Work Process Analysis)

The second tool we have developed following the Tiramisù recipe has been built to provide insights about personal work processes. For instance, for an academic, her personal work processes performed during her daily work might involve writing a paper, preparing a course, reviewing research papers, or supervising a PhD student, among many other processes. As can be observed by these examples, depending on the characteristics of the work, personal work processes can be knowledge-intensive and significantly unstructured, which means they are well-suited to benefit from the characteristics of the Tiramisù architecture [8].

To analyze personal work processes, the tool must be provided with collected personal information in the form of an event log that can be analyzed using process mining techniques. There are several techniques that can be used to collect personal information such as timesheet techniques or screen recordings, each with their own advantages and disadvantages [12]. Our tool supports two types of data, namely: Active Window Tracking data and calendar data.

Active Window Tracking data [13] can be seen as an event log that records the active window in a computer at any moment in time. Each event includes the title of the active window, the name of the corresponding app, and the timestamps when the window became active and stopped being active. There are several different tools that record this information. One of them is Tockler, 2 which is open source and stores all data locally, avoiding privacy concerns. We also assume that the user has labelled each event in the log with information about (i) the activity that was being done at that moment, e.g., conducting research, preparing lectures, etc., and (ii) the case the activity belongs to, e.g., the ICPM Tiramisù demo paper. The Worktagger tool3 can be used to support the user in the labelling task. We have chosen this type of data because it has proven to be very useful to obtain insights [13,14] from personal work processes. Calendar data can be obtained from any calendar management application and it involves the events scheduled in one's calendar including the start and end time, and the title of the event.

Since the intention of the tool is to give the user insights into a working day and how it develops, we have chosen the calendar as the backdrop. A calendar is a very intuitive visualization for every type of user, which is another reason why it is a good choice as a backdrop. Against this backdrop, both the Active Window Tracking data and the Calendar data are visualized as different layers. At this moment, the tool shows Active Window Tracking data all the time, while allows the user to show or hide Calendar data. In many cases, for instance, when a person multitasks or when there are frequent interruptions in the environment, the duration of activities can be very short, e.g., around two or three minutes. Instead, calendars work best with a granularity of at most 15 minutes. Therefore, representing those fine-grained activities would make the calendar too cluttered, and it would negatively impact the quality of the visualization. For this reason, we abstract the activities obtained from the Active Window Tracking data to 15-minute time slots. Specifically, we assign each 15-minute time slot to the activity that has been performed for the longest time in that period as long as it is above a certain threshold. Otherwise, the 15-minute time slot is assigned to a "misc" activity or to no activity if the user has been inactive for the majority of the time slot.

Besides the overview provided by the calendar backdrop and the layers of information on top of it, the tool is designed to work following the details-on-demand principle. Specifically, when the user clicks in any of the intervals in the calendar, a full set of details and metrics regarding that interval appears, as shown in the right-hand side of Fig. 3. The information provided includes (i) the details of the activities performed in the interval that were abstracted away in the calendar; (ii) some metrics about interruptions, effectiveness, and other activities performed in the same interval, and (iii) the details of the events and windows active in the interval. Similarly, by clicking in Case details the user can find details of the case performed in the interval selected. For both, the interval and the case details the metrics computed are based on those proposed in [14] to analyze the interruptions during scientific research collaborations.

Storage Tips and Shelf Life (Maturity and Availability)

In our earlier work [8], the original implementations of the healthcare and personal information management have undergone an extensive evaluation in the form of semi-structured interviews with end users. The healthcare tool was considered intuitive and fulfilled the defined needs. As such, only cosmetic changes were made to the tool.

The Banana implementation, on the other hand, is a much evolved version of the initial proof-of-concept that was detailed in [8]. In that proof-of-concept, the Active Window Tracking data was simply pre-processed, before a calendar was generated that was then integrated into Google Calendar. The biggest limitation of that approach was that this generic tool did not allow for providing further details on the data. Instead, the tool we are presenting here is a dedicated tool that provides many details on demand, which was one of the most requested features we gathered from the evaluation of the original proof-of-concept.

Both implementations follow the same core concepts of the Tiramisù framework. Differences in the use cases, visual design, and the technology stack are deliberate, intended to showcase the versatility of the framework for developing process mining tools for practical use cases.