Kairos is a web-based tool that uses prescriptive process monitoring techniques to provide recommendations for ongoing cases based on execution data (event logs). Upon uploading an event log and specifying the recommendation parameters, Kairos provides the users with several recommendations for ongoing cases that are aimed at achieving positive case outcomes. The target users of Kairos are process analysts, operational workers, and tactical managers of business processes. In this paper, we describe the functionality of Kairos for process analysts.
Prescriptive process monitoring is a family of techniques that recommend actions during the
execution of a case that, if followed, increase the probability of positive case outcomes [
In this paper, we present Kairos, a prescriptive monitoring tool for business processes that
provides users with recommendations for ongoing cases. In [
Kairos is a web-based tool for prescriptive process monitoring. It consists of two main layers: PrCore (the engine that generates the prescriptions) and a visualization layer for the generated prescriptions (see Figure 1).
The backend logic (VL3) in the visualization layer coordinates the connection between the database (VL4), PrCore, and the frontend (VL1). The visualization layer receives data from PrCore using API endpoints (PC1). The data is processed by the backend logic (VL1), and recorded in the database (VL4), and sent to the frontend (VL1) when requested.
The visualization layer takes the output of PrCore as input for constructing visualizations. To support the construction of visualizations (which takes place in frontend), a backend is built as a middleware that connects to PrCore and a database to receive and store all the necessary data.
Visualization layer VL1 PC1
Frontend PrCore <API>
Core VL2 <API>
VL3 Backend logic
VL4
Database PC2 PC5
Event log processor
PC3 PC4
Database
Message broker
Plugin 1 (guiding) Plugin 2 (correlation-based) Plugin 3 (causality-based)
The core application (PC2) coordinates PrCore. The core also utilizes an event log preprocessor (PC5) to preprocess the uploaded event log, and the message broker (PC4) to communicate with the three plugins that return recommendations based on diferent prescriptive techniques.
As such, plugin #1 provides guiding recommendations, i.e., it predicts the next best activity to
execute based on a KNN algorithm [
Below, we elaborate on the main functionalities of Kairos. We describe event log upload, specifying parameters, overview of completed cases, overview of ongoing cases, and a detailed view of separate cases and recommendations.
• Event Log Upload. To start using Kairos, the user must upload an event log. The accepted
ifle types are .csv, .xes, and .zip, with the file size limited to 100 Mb. The user can choose
to either upload one event log (which is then split into train and test sets) or two event
logs: one for training (that contains only completed cases), and the other for testing
(that contains not completed cases). In the first option, the data is streamed, and in the
second, it is delivered as a single response. More specifically, in the first option, we
employ an 80%-20% temporal partitioning of the log. The initial 80% is used for training
and validation of predictive models for all plugins, while the remaining 20% is reserved
for streaming data. Conversely, in the second option, streaming data can be sourced
from either temporal partitioning or user input. It is important to note that during the
operational phase, we assume that new events from ongoing cases (streamed from the
streaming data) continuously arrive, thus requiring recommendations from each plugin.
With the streaming, we simulate how new cases would be constantly appearing in real-life
scenarios. After the file upload, the user must specify data column types (e.g., case ID,
text, numerical, etc.)
• Parameters Definition. Next, the user defines the parameters required for the plugins in
PrCore. These parameters are: 1) The activity that marks the completion of a case. 2)
A condition marking the positive outcome of a case. The outcome types are extracted
from the event log by PrCore. The outcome types can be one of the columns in the event
log (such as cost, specific activity, resource) or the duration of a case. For example, if
a positive outcome is specified as equal to “duration less than or equal to 10 days”, all
cases lasting 10 or fewer days are marked to have a positive outcome, while the rest are
marked as negative. 3) An intervention for plugin #3 [
Here, three graphs are displayed. The first graph is a pie chart that shows the ratio of recommendations leading to positive or negative outcomes. The second one is a table indicating the number of positive outcomes for each recommendation type in the given process. The third graph displays the acceptance rate (by operational workers) of past recommendations, i.e., how many past recommendations were followed or rejected.
Additionally, the user is presented with a table of completed cases. • Ongoing Cases Overview. The aggregated view for ongoing cases contains two graphs: the first depicts the current distribution of the types of recommendations in all ongoing cases, and the other presents the current acceptance rate for the three types. Additionally, in the Cases Overview Table, the user can gain an overview of ongoing cases and select the one(s) they wish to inspect in detail. • Individual Ongoing Case. In this view (Figure 2), the user is presented with case-specific attributes and current case performance (w.r.t. to the target measure). The list of recommendations on the left displays information about available recommendations for the case in its current state. Each recommendation is marked with its type (guiding as “next activity”, correlation-based as “alarm”, and causality-based as “intervention”). The user can read about the diferent types by clicking on the info button above the recommendations. The recommendations of diferent types are shown when they are applicable. The recommendations are depicted on the process model to the right. The recommendation types have the same color as in the list on the left. The user can also see the past prescribed recommendations by toggling the “Show past recommendations” button. For these, it is also indicated if the recommendation was accepted or discarded by an operational worker. Last, the basic description of the machine learning models is accessible when clicking on Calculation Details.
We evaluated the performance of PrCore engine on BPIC2012 and Road Trafic Fine Management
Process event logs. For plugins #1 and #2, their accuracy scores serve as evaluation metrics (the
number of accurate predictions made by a model relative to the total predictions). We report on
the average prediction accuracy across the entire simulation for these plugins. Conversely, for
plugin #3, ground truth estimates for the causal efect are unavailable, making it impossible to
estimate model accuracy. Instead, we report the average CATE throughout the entire simulation.
Kairos utilizes a process pool for parallel processing (the dataset is partitioned based on available
CPU cores, and a process pool is employed for concurrent processing). However, the log size
influences both training and recommendation times. For instance, for BPIC2012 log, training
takes circa 10 s, while recommendation circa 20 s. Conversely, for the larger BPIC2017 log,
training and recommendation times extend to circa 35 s. On the user interface side, we evaluated
the relevancy of the content included in the tool [
Plugins Plugin #1 Plugin #2 Plugin #3 Plugin #1 Plugin #2 Plugin #3
Kairos can be accessed as a cloud service at https://kairos.cloud.ut.ee/. Examples of event logs and configurations to test with Kairos are available at https://github.com/ AutomatedProcessImprovement/kairos-frontend/blob/master/README.md. In the same github space, documentation and source code of PrCore, and frontend and backend of the visualization layer are available. A demo video of Kairos is available at https://youtu.be/51zgZw40ZzA