The monitoring of business processes represents a pivotal component of contemporary management practices to ensure the eficiency and efectiveness of company processes. Object-centric business process monitoring is a concept that involves the continuous observation and analysis of object instances to identify deviations from defined standards and initiate prompt measures for optimisation. The utilisation of specific technologies, such as Object Instance Monitoring, empowers companies to acquire valuable insights that facilitate the enhancement of performance and the augmentation of customer satisfaction. The ability to identify risks at an early stage, optimise the use of resources, and increase the company's agility are key to long-term success in an increasingly dynamic business world. The objective of this paper is twofold. Firstly, it seeks to define process metrics (i.e., the global status and duration of instances). Secondly, it discusses visualisation techniques for object instance monitoring. The purpose of these two objectives is to facilitate resource and risk management.
duration monitoring is defined in Section 4. Section 5 provides a detailed exposition of the visualisation techniques that have been developed for object instance monitoring. Related work is discussed in Section 6. Section 7 concludes the paper.
In the object-centric process management paradigm PHILharmonicFlows, a business process is
described in terms of interacting business objects that correspond to real-world entities. The interactions
between the objects, as well as their relations, including their cardinalities, hierarchical structure, and
semantic relations, are manifested in the Relational Process Structure (RPS) (cf. Fig. 1)[
The runtime behaviour of these business objects is defined in terms of object lifecycles (lifecycle for
short) [
A coordination process (cf. Fig. 3) controls the interactions between the lifecycles of multiple objects
and defines the sequence of states between multiple lifecycle states. A coordination step is defined as a
reference to the lifecycle state of an object. Moreover, a coordination process is generally represented
by a graph, in which the vertices correspond to the coordination steps and the edges correspond to the
coordination transitions. The coordination process graph is defined as a directed, acyclic and connected
graph. This implies that it does not permit backwards transitions or loops to preceding coordination
steps [
This section provides an overview of the various statuses that can be assigned to an instance.
Running Instance: A running instance is defined as an instance with an activated state that is not the end state. In Fig. 4, the start state Preparation is the active state. Data collection is done using forms. The form can be automatically generated from the process elements. Typically, in activity-centric processes, forms must be designed manually for each activity. However, since PHILharmonicFlows is data-centric, form generation is built in. The operational semantics control the dynamic aspects of the form, such as the next value that is required. The active state of the process (cf. Fig. 4) gives rise to the current form sheet Preparation, incorporating the designated input fields, which include Title, Description, Category, Tasks, and Qualifications. Input fields designated Title and Description are iflled in with data, whereas a value for Category is required, indicated by the marking Enabled on the Category step (cf. Fig. 4). The input fields designated Tasks and Qualifications have been marked as ready. Nevertheless, the operational semantics have been designed to allow for flexibility. It is not obligatory for a user to complete the form in the correct order. However, they are at liberty to deviate from this by filling in the Qualifications field first and the Tasks field afterwards. This provides the end user with a certain degree of flexibility. Provided that a lifecycle instance is active (not marking the end state as active), it is considered to be running.
Terminated Instance: Terminated instances are defined as instances that have reached one of their end states (end state marked as activated). As demonstrated in Fig. 2 and 4, the end states comprise precisely one step. This step is devoid of any reference to a business attribute and is consequently designated as an empty step. It is important to note that an end state does not generate a form sheet or input fields. The primary purpose of end states is to enable the monitoring or collection of terminated instances without the need to delete or eliminate these instances. Multiple end states can characterise a lifecycle. The various potential end states of each instance (e.g., the state of a position being either vacant or filled) can be leveraged to demonstrate their diferent outcomes. Generally, these instances (a) No outgoing Backwards transition from an end (b) Backwards transition from an end state to a previstate. ous state.
Figure 5: Diference between completely terminated instances and temporarily terminated instances. do not necessitate further work. End states can exhibit backwards transitions to one of their previous states. It is incumbent upon the modeller to define such transitions explicitly. In the event of such a backwards transition, a terminated instance may be reactivated. This enables the distinction between instances that have been fully and non-fully terminated.
Fully Terminated Instance: A fully terminated instance is defined as an instance that has reached its end state, and there is no backwards transition to reactivate the instance again. Fig. 5a shows an intermediate state with one step and a transition to the empty end state. An instance that can be fully terminated is the default way of modelling a lifecycle process.
Non-Fully Terminated Instance: A non-fully terminated instance is defined as an instance that has reached its end state, and there is at least one backwards transition to a previous state modelled to reactivate the instance. Fig. 5b shows the same constellation as in Fig. 5a with an additional backwards transition. This case is used when an instance that has reached an end state and is normally terminated can be considered again. Considering the recruitment process used in Section 2 as a running example, one use case is the rejection of applications because the vacancy is filled (cf. Fig. 2). However, the candidate who has been ofered the job rejects it. In this case, the rejected application is reconsidered and the instance to find the most suitable candidate is reactivated. Furthermore, a lifecycle can have two types of end states: one with the possibility of reactivating an instance and another with no reactivation option. This eliminates the need for complex special-case modelling.
Expected Instance: Expected instances are defined as those which are yet to be created, but whose existence is already anticipated. The purpose of these instances is to facilitate resource management calculations and planning.
• Minimum Cardinality: Within the paradigm of the data model, the cardinality between two
objects that are related can be defined. By default, a 1 : n cardinality is established, and the
n : m relation’s placeholders n and m can be defined by the modeller as follows: minimum (e.g.,
4..m), maximum (e.g., 1..8), or range (e.g., 3..5). In the event of a minimum being specified, it can
be used to calculate the expected instances. To illustrate this, consider the recruitment process
illustrated in Fig. 1. This process stipulates that for each application, between three and five
instances of reviews must be created.
• Event Log: Utilising an event log facilitates the calculation of the expected number of instances
by leveraging the average number of instances generated by completed business process instances.
However, it should be noted that this variation can be subject to inaccuracy. Nevertheless, it can
assist in approximating the anticipated expense. For example, the number of applications can be
estimated during the recruitment process. Consequently, the anticipated quantity of application
instances can be calculated, thereby facilitating the estimation of the number of review instances.
• Machine Learning: The utilisation of supervised machine learning (i.e., neural networks [
Deleted Instances: The PHILharmonicFlows framework facilitates the direct deletion of running instances by end users, contingent upon the possession of the requisite permissions. For instance, an applicant has the option to withdraw their application by deleting it. An employee can not remove an application without the necessary permissions.
The maximum processing time (i.e., the time span in which the instance must be completed) and the proceeding time (i.e., the time taken to complete the work of an instance) can be used to monitor risk management. For each lifecycle, a modeller (or process owner) can specify the amount of time for an instance, as well as each of its states, to be completed. For example, after an application has been received, a reviewer has two weeks to complete the review. Additionally, the maximum processing duration of one lifecycle state (i.e., one form sheet) can be defined. For example, if a candidate is successful in the assessments, they will be invited for an interview (i.e., state Preparation Interview). In this case, a recruiter has five days to send the candidate an interview date. Each running instance can be categorised into one of the following modes:
On Risk: This status is defined for instances or states where the proceeding time is nearly over. The determination of the point at which an instance or state is deemed to be at risk is made by a key performance indicator (KPI). By default, the value On Risk is set to 80% of the maximum processing time. Consequently, when 80% of the defined proceeding time has elapsed, an instance or state is flagged as being at risk. If an instance or state reaches a risk status, an alert is to be dispatched to the employees responsible for editing the instance or state. Furthermore, in the event of a reported absence (e.g., illness, holiday), the alert is to be forwarded to a colleague. However, this is only possible if the employee has designated a colleague in the system.
On Time: The definition applies to instances or states in which the proceeding time is on time, i.e., the proceeding time falls within the first 80% of the maximum processing time span. It is possible to adapt the KPI of the value On Risk. Consequently, the temporal span within which an instance or state is considered to be on time is also subject to adaptation.
Overdue: This is defined for instances or states where the defined processing time has elapsed. In such a scenario, an escalation message will be transmitted to a diferent employee. The identification of the employee concerned is specified within the runtime engine. Typically, the escalation message is sent to a colleague the first time, or to a manager if the deadline is missed more often.
In the context of object-centric business processes, the PHILHarmonicFlows monitoring framework has been developed to facilitate the monitoring of instances created within its runtime engine. The monitoring framework enables users to define bespoke monitoring components and charts, thereby empowering them to track and analyse process metrics meticulously. The primary objective of the monitoring framework is to facilitate a collaborative process that enables users to construct their own monitoring framework through a straightforward click-and-build interface. This will allow users
Lisa Arnold: Business Instance Monitoring to create bespoke monitoring dashboards in accordance with their respective permissions, specific task area and individual interests. The monitoring framework provides a range of options for data visualisation, including pie charts, doughnut charts, and bar charts. These visualisation charts can be employed to represent the instance duration (i.e., On Time, On Risk, or Overdue) or status (i.e., running, terminated, or expected) of a single instance. Furthermore, the framework provides options for data visualisation at the level of a collection of instances (e.g., all application instances related to the same job ofer), all instances of the same object type, or the lifecycle state of an instance.
The use of rudimentary diagrams (e.g., bar charts) is optimal for monitoring individual instances
(i.e., single review instances) or instances of the same type (i.e., all review instances). The utilisation
of sophisticated diagram types is imperative for the comprehensive monitoring of business processes.
The sunburst chart [
Heat maps [
The field of Business Activity Monitoring (BAM) has already been established as a subject of research,
with a considerable number of academic papers [
The objective of this paper is to examine the application of object instance monitoring (OIM) in the context of object-centric business processes. The paper establishes and delineates a comprehensive categorisation of the statuses (e.g., running or terminated) that an instance may achieve during the execution of a business process. Furthermore, it establishes a duration concept for running instances, and specifies metrics On Time, On Risk, and Overdue. Finally, the utilisation of visualisation techniques (i.e., rudimentary diagrams, sunburst charts, and heat maps) adapted to object-centric business processes is explained, with a focus on illustrating OIM constituents. Further work is currently underway to develop personalised dashboards, the functionality of which will enable each user to create their own bespoke dashboard by selecting a combination of monitoring functions and visualisation types from a curated list.
This work is part of the ProcMape project, funded by the KMU Innovativ Program of the Federal Ministry of Education and Research, Germany (F.No. 01IS23045B).
During the preparation of this work, the author used Grammarly in order to: Grammar and spelling check. After using this tool, the author reviewed and edited the content as needed and takes full responsibility for the publication’s content.