Monitoring business processes during their execution is one important aspect of business process management. Process monitoring requires observed events, which are recorded in information systems, to reason about, amongst others, process progress. Especially in manual executing process environments, the observed events are most likely sparse. Therefore, we introduce an approach increasing the number of observed events by capturing data state transition events, which occur after successfully writing a data object during process execution.
In the eld of business process management, monitoring is used to observe process
behavior and probably to react upon events as well as to predict upcoming process
steps during process execution. Processes automated by information systems, i.e.,
process engines, can be monitored very well because the system usually provides
logging capabilities and therefore, the progress is easily recognizable. In contrast,
in environments with processes to be mainly executed manually, such as in health
care, many occurring events are not captured. Thus, event information about such
processes is incomplete and exact proposition about progress, e.g., by applying
the concept of event monitoring points [
Nevertheless, progress recognition of the complete process and an holistic view
on the process are goals in manual executing process environments also.
Introducing additional documentation and logging activities during process execution
can be a solution, however, this is not intended, because it creates additional
e ort to the process participants, e.g., the doctors and nurses. Therefore, we will
introduce an approach utilizing events from data object creation or modi cation
to increase the number of observable events used for process monitoring and
prediction of process progress. We call them data state transition events. After
the write of a data object in a speci c data state, we can assume this data
object to be existent. Besides arguing about process progress, the registration of
events helps in deciding about future process execution and the chance of proper
completion of a process or the reachability of a speci c activity. Additionally, the
approach can be utilized to identify incorrect behavior similarly to what is done
in the eld of data conformance, e.g., [
The presented approach enables insights into process execution based on
information about a data object. Data objects and their life cycles are the basis for this
approach. A data object life cycle (OLC) is represented by a Petri net, where a
place describes a data state and a transition represents a data state change from
the preceding to the succeeding one. An OLC speci es all allowed data state
changes of the corresponding data object. As an example, we refer to an Invoice
with data states created, sent and paid, whereat these states can be reached in
that order only, see Fig. 1 { Data Object Life Cycle Level. Based on this OLC,
those transitions are selected that can be monitored with events. We refer to an
event as a happening in a particular point in time at a certain place in a certain
context that is represented in the IT system landscape, see Fig. 1 { IT Level.
The observable data state transitions of the OLC have to be linked to the events
that provide the information about the triggering of the transitions. This link is
provided by a binding, see Fig. 1 { Event Level, of the particular transition of
the OLC to an implementation that extracts the necessary information about
the events from a data source including the correlation to a speci c data object
instance during runtime. For the binding, we use the same technique as presented
in our earlier work [
Instance View (Run Time) [cInrevaoticeed] I[nsveonitc]e
Invoice [paid] Mail Invoice
Check
Payment eb t eb t set set sent sent paid paid Event Store
IT System Landscape Process Level Data Object Life Cycle Level Event Level IT Level During the design of several process models, the data objects can be assigned to particular activities, whereas the activities either read a data object in a certain data state, create a data object in a certain data state, or transfer a data object from one data state to another. We assume that the usage of the data object in a process correlates correctly to the OLC, i.e., the process only uses the speci ed data states and their transitions as shown in Fig. 1 { Process Model View (Design Time) [cInrevaoticeed] I[nsveonitc]e
Mail Invoice Bindings sseentt sent psaeitd paid
IT System
Landscape Create Invoice
Create
Invoice Ininvoitice cresaetted actreed
Check Payment
Invoice [paid]
Create Invoice(1)
Create
Invoice eb t Ininviotice(1) cresaetted actreedLevel. Nevertheless, not every possible data object state in the OLC needs to be re ected in the process model.
Based on the assignment of the data objects to the activities, it is possible to provide information about the process execution during runtime. We assume that an activity is enabled if the activity could be executed because of the control ow speci cation and if the input data object is available in the required data state. Furthermore, we assume that an activity is terminated as soon as the output data object is present in a certain data state. Information about process execution can be provided for activities, which consume or provide data objects in certain data states whose state transition is observable.
Referring to our example, the termination of activity Create Invoice and the
enablement of Mail Invoice cannot be monitored with information about the data
object Invoice only, whereas the completion of the second activity as well as the
enablement of the third activity of the process model can be tracked on IT Level.
This is visualized by the edges to the Bindings database in Fig. 1 (left part). At
design time, the data state transitions to sent and paid are marked as observable
(bold outline). This maps to the aforementioned monitoring capabilities at run
time. At run time, the progressing in the process can be recognized by data state
transition events occurring in the event store. In Fig. 1 (right part), an event for
sending Invoice(1) (data object with corresponding instance id) is observed in the
event store (solid edge), but there is no event available for the payment although
it is expected to happen some time (dashed line). For monitoring process details
not observable by the means of data manipulation, the introduced approach can
be combined with other approaches, e.g., [
For simplicity reasons, we described the approach assuming at most one input data object and at most one output data object per activity. However, the approach is also valid for many input and output data objects. 3
In [
The presented approach uses information about data objects and their data states resp. data state transitions from process models to enable process monitoring. The observable data about the transition of a data object from one data state to another provides further insights about the process execution. Thus, a more detailed process monitoring can be assured.