Waiting times often occur in business processes when a case transitions from one activity to another. Accordingly, analyzing the causes of waiting times in activity transitions can aid analysts in identifying opportunities for reducing process cycle time. To solve this task, we propose Kronos - a web-based tool that decomposes waiting times in activity transitions into their causes and analyzes their impact on the cycle time eficiency of the process. Thus, Kronos targets process analysts interested in optimizing the temporal eficiency of business processes.
CEUR ceur-ws.org
Waiting time is a common source of waste in business processes [
Process mining techniques enable analysis of data generated by business process executions,
a.k.a. event logs, and, in particular, to discover waiting times [
In this paper, we present Kronos, an open-source web-based tool that discovers the causes of waiting times in activity transitions. Kronos also assesses the impact each cause of waiting time has on the process’s cycle time eficiency (CTE). This can aid analysts in identifying improvement opportunities related to waiting times that, when addressed, can increase the temporal eficiency of the process.
The rest of the paper is structured as follows. Sec. 2 describes Kronos’s functionality and components. Sec. 3 presents the maturity and availability of Kronos. Sec. 4 concludes the paper. CEUR Workshop Proceedings
Kronos takes an event log as input, identifies transitions, calculates their durations (waiting times), discovers and quantifies the causes of the waiting times, measures their impact on the process CTE and, finally, visualizes the results. Figure 1 gives an overview of Kronos’s components. Below, we summarize the functionality of each component of Kronos.
As input, Kronos takes an event log (CSV format) with at least a unique case identifier, activity name, resource, start and end timestamps. These attributes are required. When the log is uploaded, the user maps the columns to their respective attributes, and Kronos validates that all mandatory attributes are included in the log. If so, Kronos proceeds to the activity transition discovery.
In this component, Kronos identifies activity transitions, i.e., pairs of activities – composed
of a source and a target activity, where the source activity enables the execution of the target
activity – between which cases are transferred. With this purpose, Kronos first discovers
the concurrency relations between the process activities (using the concurrency oracle of the
Flexible Heuristics Miner [
Once the activity transitions and their waiting times are discovered, Kronos discovers the
causes of waiting times. The waiting time within a given transition instance may stem from
one or multiple causes. If there are multiple causes, Kronos decomposes the waiting time into
non-overlapping time intervals and attributes each interval to one cause. Kronos identifies five
causes of waiting time in the following order:
• Waiting time due to batching occurs when an activity instance waits for another activity
instance to be enabled in order to be processed together as a batch. To identify batch
processing, Kronos uses the technique proposed in [
The order by which waiting time causes are identified in a given activity transition is determined by the dominance relations between these causes. Batching dominates resource contention, prioritization, and unavailability, because regardless of the availability status of any given resource, an activity instance that is part of a batch is not ready to be assigned (and started) until the batch is ready. Resource contention and prioritization dominate resource availability, because if a resource has a work queue, they cannot start an activity instance until the latter reaches the front of the queue, or until this activity instance has the highest priority in the queue, regardless of the resource’s availability status. Extraneous factors are dominated by all other causes, as they act as a “catch-all” cause for any waiting time that cannot be attributed to other causes.
In this component, Kronos analyzes how much each cause of waiting time contributes to the temporal performance of the process (i.e., the percentage of time each cause induces in the process) and their impact on the CTE. The impact of each cause of waiting time is calculated as the diference between the original process CTE and the CTE if the waiting time is eliminated. In this way, Kronos measures (1) the impact each waiting time cause has on the process CTE, (2) the impact each transition has on the process CTE, and (3) the impact each waiting time cause has in each transition. These metrics can indicate the potential CTE improvement if a particular cause of waiting time is eliminated.
Finally, Kronos visualizes the analysis results in its user interface that has 3 tabs: (1) Overview tab presents the key statistics of the process (e.g., number of cases, activities, and transitions), total waiting time of the process, and how much each cause induces; (2) Transitions tab shows the waiting time causes per transition; (3) CTE impact tab depicts potential CTE improvement if the waiting time causes are eliminated in the whole process and per activity transition. Figure 2 illustrates an example of a real-life production process, where the graph shows waiting time causes per activity transition. The analysis results can be downloaded in CSV and JSON formats.
Kronos has been empirically evaluated with synthetic event logs where the causes of waiting
time were known [
Kronos is developed as a React web application, publicly available at http://kronos.cloud.ut.ee. The current server deployment accepts event logs with sizes up to 30 MB. A set of event logs for testing is available at Owncloud1. The implementation of Kronos’s logic is available in a GitHub repository2, along with instructions for its installation and command-line usage. A screencast that describes the tool is available on YouTube3.
In its current form, Kronos has several limitations in terms of method and implementation:
• Method limitations. First, the method considers only waiting times in transitions between
activity instances. Yet waiting times may also arise in at least two other settings: (i)
between case creation and the start of the first activity instance; and (ii) within an activity
instance due to interruptions (e.g., the resource interrupts their work and resumes it later).
The first of these waiting times could be analyzed by applying methods that estimate
the inter-arrival time of each case [
Kronos discovers five causes of waiting times (batching, resource contention, prioritization, resource unavailability, and extraneous factors) from event logs, assesses their impact on process CTE, and visualizes the analysis results. With Kronos, process analysts can identify improvement opportunities related to increasing temporal eficiency by reducing waiting times. In the future, we plan to address the method limitations, in particular, add a simulation-based analysis, allowing analysts to experiment with redesign options.
Work funded by the European Research Council (PIX project).