model configuration. This demo paper introduces processpredictR, a new library for predictive process monitoring in the bupaR-ecosystem. The library provides functionalities with diferent levels of customization, from completely standard of-the-shelf models, to tools for advanced customization of preprocessing and ∗Corresponding author.
CEUR ceur-ws.org
The field of predictive business process monitoring aims to improve the execution of processes
by analyzing event logs and foreseeing future events and process outcome. Over the past
decade, much research has been done in this field, comparing diferent model architectures and
improving predictive accuracy. Implementing these state-of-the-art predictive models is often
done in an ad-hoc way, using generic tools such as TensorFlow and Keras, creating a barrier
to smooth adoption by practitioners. Notable exceptions on this front are Apromore [
processpredictR is an extension of the bupaR ecosystem for process analysis with R [
stack_layer() predict() evaluate()
In the next paragraphs, we briefly describe the main workflow, as shown in Figure Prepare examples. The first step is preparing the dataset using the 1. prepare_examples function. When preparing the examples for prediction, the user can select one of the five diferent prediction tasks: next activity, next time, remaining trace, remaining time, and outcome. The latter one, outcome, can be defined in various ways, e.g. based on the final activity, some attribute, or some other logical condition. At this point, it is also possible to specify any additional features that should be used in the prediction, next to the default ones, i.e. the activity prefix and time features. An example of the preparation step is shown in Listing 1, line 2-4.
Listing 1: Coding workflow. l i b r a r y ( p r o c e s s p r e d i c t R ) e x a m p l e s <− p r e p a r e _ e x a m p l e s ( log , t a s k = ” outcome ” , f e a t u r e s = c ( . . . , . . . ) ) s p l i t <− s p l i t _ t r a i n _ t e s t ( examples , s p l i t = 0 . 7 ) t r a i n <− s p l i t $ t r a i n _ df t e s t <− s p l i t $ t e s t _ df model <− c r e a t e _model ( t r a i n , # t r a i n i n g s e t custom = FALSE , # d e f a u l t a r c h i t e c t u r e num_ h e a d s = 4 , # number o f a t t e n t i o n h e a d s o u t p u t _dim_emb = 3 6 , # e m b e d d i n g s o u t p u t d i m e n s i o n s dim_ f f = 6 4 ) # d i m e n s i o n s o f f e e d − f o r w a r d n e t w o r k model <− c o m p i l e ( model ) h i s t <− f i t ( model , t r a i n _ data = t r a i n , e p o c h s = 1 0 ) p r e d i c t i o n s <− p r e d i c t ( model , t e s t _ data = t e s t , o u t p u t = ’ append ’ ) c o n f u s i o n _ matrix ( p r e d i c t i o n s ) p l o t ( p r e d i c t i o n s ) e v a l u a t e ( model , t e s t _ data= t e s t )
The output of this step is a datatable with examples. A case containing activity instances is turned into − 1 examples, each consisting of an activity prefix, the target variable (depending on the specified task), and any other features as specified in the call.
Split train test. The preprocessed dataset can be divided into train and test sets using the split_train_test function, simplifying dataset separation for model training and evaluation. This function takes the output of prepare_examples() and generates two data frames, as detailed in Listing 1, line 6-8.
Note that the event log is split chronologically, ensuring that all train examples precede test examples. Additionally, the split is based on case proportions rather than individual examples, preventing the division of the last case between the training and test sets, which would otherwise lead to observations scattered between both sets.
Create model. The next workflow step involves defining the model’s structure. The
create_model() function considers the task and dataset parameters (e.g. additional features,
output possibilities, case length) and initializes a default transformer architecture (based on
[
Compile. To configure the training process the model must be compiled, specifying the optimization process, loss function and evaluation metrics. This is done automatically by the compile function (see Listing 1 l.17).
Fit. The training of the model is facilitated with the provided fit method (see Listing 1 line 19). It naturally allows flexibility in selecting hyperparameters (e.g. the number of training epochs, batch size, and validation split).
Predict. Having trained the model, the predictions can be made using the provided predict method. The function can return up to three diferent types of output: raw predicted values as returned by the generic keras predict function (without argmax applied), an array of predicted values, or a data frame combining the input data with the predicted values (as illustrated in Listing 1 line 21). Additionally, for classification tasks, processpredictR allows to quickly compute and visualize the confusion matrix (Listing 1 line 23-24).
Evaluate. The evaluate function allows to quickly evaluate the performance of the model on the test set, returning the value of the loss and accuracy metrics (see Listing 1 line 26).
Aside from the default models as in the main workflow, processpredictR provides customization options. Users can include extra categorical and/or numerical features alongside examples and adjust the model’s complexity.
Additional features. Additional features to be used by the model, beyond examples (activity sequences) and default features, can be defined when using prepare_examples(). The features can be either numerical variables or categorical factors. Numerical variables will be automatically scaled using the min-max normalization. Factors will be automatically converted to hot-encoded variables.
Model complexity and custom layers. The default complexity settings for the models are
determined by the following parameters which can be adjusted by the user: the number of
attention heads ( _ℎ = 4 ), the output dimensions of the embeddings ( _ _ =
36), and the dimensions of the feed-forward network ( _ = 64 ) [
More advanced flexibility is ofered by allowing the creation of a custom model. In such a case, processpredictR will provide a partial model, containing only the input layers and the encoder block of the model, which the user can then complete with generic keras layers using the provided stack_layer method.
Advanced customization. The methods described thus far abstract from many preprocessing and configurations steps. However, one may be interested in custom preprocessing, model architecture or simply getting a more detailed interpretation and understanding of the model parameters. Hence, additional auxiliary functions are made available, which together with generic keras methods ofer even greater flexibility.
While the processpredictR library was published only in January 2023, the back-end is based
on the tried and tested functionalities of the keras library [
The library is published on CRAN1 and can be installed as a regular R-package. Usage does require a Python distribution to be installed also. More information on the installation can be found on docs.bupar.net.2 A more detailed tutorial on the workflow as well as customization options can be found there as well.3 A four minute screen-cast on processpredictR can be found here: https://tinyurl.com/processpredictR
This demo paper introduced processpredictR, an easy-to-use tool for predictive process monitoring embedded in the bupaR-ecosystem. Next to default of-the-shelf models, the library provides multiple avenues to customize predictive models within a specific context. Future eforts will be focused on improving the default model architectures used, as well as more advanced visual tools to aid the interpretability of the obtained models and predictions. 1https://cran.r-project.org/package=processpredictR 2https://bupaverse.github.io/docs/install.html#Installing_bupaR 3https://bupaverse.github.io/docs/predict_workflow.html