Improving Business Process Intelligence with Object State Transition Events

Transcription

1 Improving Business Process Intelligence with Object State Transition Events Nico Herzberg, Andreas Meyer, Oleh Khovalko, and Mathias Weske Hasso Plattner Institute at the University of Potsdam Prof.-Dr.-Helmert-Str. 2 3, D Potsdam, Germany [first name].[last name]@hpi.uni-potsdam.de Abstract. During the execution of business processes several events happen that are recorded in the company s information system. These events deliver insights into process executions so that process monitoring and analysis can be performed resulting, for instance, in prediction of upcoming process steps or the analysis of the runtime of single steps. While event capturing is trivial when a process engine with integrated logging capabilities is used, manual process execution environments do not provide automatic logging of events, so that typically external devices, like bar code scanners, have to be used. As experience shows, these manual steps are error-prone and induce additional work. Therefore, we use object state transitions as additional monitoring information, so-called object state transition events. Based on these object state transition events, we reason about the enablement and termination of activities and provide the basis for process analysis in terms of a large event log. Keywords: Business Process Management, Events, Data, Process Monitoring, BPMN 1 Introduction Nowadays, companies face a very competitive market environment. Therefore, they strive to run their value generating operations in a process-oriented way to stay competitive and to be able to react on market changes quickly. These business processes are managed by using techniques and methodologies of business process management (BPM). BPM deals with the organization, documentation, analysis, optimization, and execution of business processes [23]. One important aspect of BPM is business process intelligence (BPI) that comprises process analysis, monitoring, and mining [2,5]. BPI requires information about process behavior and events that occur during process execution. Process monitoring is used to predict upcoming events and process steps by observing the process execution and deriving the corresponding process behavior. Monitoring is usually applied on process models being enacted by a process engine - an information system that controls the process execution - because it generally provides logging capabilities such that the current process progress is easily recognizable from the observed events. The observation of such an event determines the current position in the course of process execution. In contrast, manually executed processes, as, for instance, usual in health care, lack these capabilities such that most events cannot be observed or stored, i.e., event logs are incomplete. However, recognition and prediction of process progress as well as a holistic view on the process execution shall be enabled in these domains also.

2 Introducing additional external devices and similar logging equipment is not applicable in manual processes especially in time critical ones as in health care due to extra amount of work and complexity. Therefore, event monitoring points [6] are defined to specify where in the process events are expected. Event monitoring points can be considered as milestones indicating the achievement of important business value. In this paper, we apply the concept of event monitoring points to data objects to create more expressive event logs without adding additional logging mechanism or devices such as scanners, RFID tags, or sensors. We further elaborate on the ideas about the concept of object state transition events (in short: transition events), which have been initially sketched in [7]. Thereby, we reason about activity termination (enablement) by means of events indicating the data objects to be written (read) by that activity transitioned into the respective object state and vice versa. Additionally, this technique also increases the number of events observed in enacted process models such that analysis is based on a much higher number of inputs resulting in an increased reliability of the results. The remainder of the paper is structured as follows. In Section 2, we introduce the foundations combined with the scope of our approach followed by an approach overview and detailed descriptions of its application. Section 3 and Section 4 describe the application of the introduced approach to a use case during design time (model view) and during run time (instance view). Finally, we discuss related work in Section 5 and conclude the paper in Section 6. 2 Approach In this section, we will introduce the fundamental notions for and the scope of our approach, which we will introduce high-level in Section 2.2. Afterwards, we will present details about the main components of our approach, starting with the concept of object state transitions, naming the challenges and showing solutions for that, in Section 2.3. The notion of binding is presented in Section 2.4 followed by the description of the process modeling aspects of the approach in Section Foundations and Scope Within our approach, we connect process models with object life cycles, which describe the actions and manipulations performed upon data objects. Thereby, a data object is any piece of information being processed, manipulated, or worked with during process execution. Each data object can exist in several states, which represent specific business situations of interest from the data object s point of view. The dependencies of these object states are defined by means of object life cycles. Definition 1 (Object Life Cycle). An object life cycle is a tuple L = (S, Z, i, T, γ, Σ, η), where S is a finite non-empty set of object states, Z S is a finite set final object states, i S \ Z is the initial object state, T S S is a finite set of object state transitions, function γ : S S T maps each pair of object states to the transition connecting them, if such transition exists, or the empty set otherwise, Σ is a finite set of labels (S, T, Σ are disjoint), and function η : T Σ assigns to each object state transition the corresponding label representing the action initiating that transition.

3 We represent an object life cycle as a state machine, where the object states are represented by elliptic nodes and the transitions are represented by edges connecting two states. Each edge is labeled with the action leading to the state change. Those state transitions might be represented through event objects during run time. We refer to an event object as real-world happening occurring in a particular point in time at a certain place in a certain context that is represented in the information system landscape [8]. Each event object can be correlated to any positive number of nodes or object state transitions and is stored in an IT system such that they are accessible as (semi-) structured data. In the scope of this paper, we focus on event objects, which can be correlated to object state transitions. Thereby, we assume that all expected events are recognized and stored, i.e., we exclude the discussion of missing events from this paper. By using data objects and their states in process models, these data objects are utilized during process execution. Thus, the event objects relating to the data objects life cycles are relevant for the corresponding process execution. We formally define the process model and set the scope about the process models we support with our approach. Definition 2 (Process Model). A process model is a tuple M = (N, D, R, C, F, type), where N (A G E) is a finite non-empty set of nodes, which comprises sets of activities A, gateways G, and events E. D is a finite non-empty set of data objects, R is a finite non-empty set of object states, C (A G E) (A G E) is the control flow relation, F (A (D R)) ((D R) A) is the data flow relation, and type : G {xor, and} assigns to each gateway a type. Let S d be the set of object states defined in the object life cycle for a data object d D, then the super set of object states S M = d D S d for process model M denotes the set of object states specified in the object life cycles of all data objects being associated to an activity of M. The set of object states R used in M is a subset to the super set of object states, i.e., R S M. Further, we require each process model M to fulfill basic structural requirements. First, the process model may be arbitrarily structured but it needs to be structural sound [1], i.e., M contains exactly one start and one end event and every node of M is on a path from the start to the end event. Further, each activity and event has at most one incoming and one outgoing control flow edge, while each gateway has at least three incident control flow edges with at least one incoming and at least one outgoing control flow edge. The events added to a process model only represent a small fraction of the events actually occurring during process execution such that most events are not comprised in the model but occur during process execution. The control flow semantics of the process model follows Petri net semantics [17]. The data flow semantics inherits the concept of data input and output sets from BPMN [21]. The data input set contains a positive number of sets, each specifying the data objects in specific object states required to enable the activity. If one of the sets is completely satisfied by the existing data objects, activity enablement takes place. Otherwise, process execution is paused until satisfaction is observed. The check for data object existence for a certain activity is only done, if the control flow approaches that activity. Following, we assume activity enablement requires control flow and data flow enablement at the same time. Analogously, the data output set specifies different options of which data objects in which object states exist after activity termination. The corresponding set is chosen

4 Process Level Data Object Life Cycle Level Process Model M X Data Object D init set a Model View (Design Time) [a] a Y set b [b] b set d Z set c bd c [c] Instance m of M es Instance x Instance q of init set a Instance View (Run Time) t q [a] a es Instance y set b t q [b] b es Instance z set d set c t bd c q [c] Event Level Event Type Repository Event Store IT Level IT System Landscape IT System Landscape Fig. 1. Overview of the approach at design time and run time during the execution of the respecting activity. Based on these data flow semantics, we assume that the observation of a data object write (the data object exists in the specific object state) indicates activity termination and vice versa. Finally, we also assume that the process model only utilizes object state transitions comprised in the object life cycle, i.e., the combination of process model and object life cycles fulfill the notion of weak conformance [13]. The object life cycle may contain object states and transitions not utilized in the process model. 2.2 Methodology The presented approach enables process execution analysis by utilizing the information about data objects and their life cycles. Thus, the required data objects and their life cycles need to be modeled first. In Fig. 1 Data Object Life Cycle Level, we provide an example with one data object. Assume, data object D may appear in five different states (init, a, b, c, and d), which are reached by the state transitions set a, set b, set c, and set d. For the given life cycle, the observable state transitions need to be selected; a transition to a particular object state is observable, if it can be monitored by a specific event named object state transition event (see Definition 3). In Fig. 1, we denote observable object state transitions with bold (set b) and dashed (set c) lines. Definition 3 (Object State Transition Event). An object state transition event E = (type, id, timestamp, q, s) consists of an object state transition event type referencing the corresponding data object D, a unique identifier, a timestamp indicating the point in time when the object transition occurred, the instance q of the data object, and the object state s of object reached when the event was triggered. An object state transition event E is an instance of an object state transition event type (see Definition 4) that describes the creation logic for the underlying transition events based on the corresponding data object. The information about the object state in the transition event is necessary to enable the correlation of the object state transition to the corresponding activity in the business process. The transition event holds a snapshot of the data object at the point in time a particular object state is reached. This is required to enable process analysis with respect to certain process data as, for instance, object

5 attributes. Assume a stakeholder is interested in the costs of activities executed in the course of process model M, see Fig. 1, and data object contains an attribute in which execution costs are summed up. For a specific process model instance m of M and therefore a specific data object instance q of, the required process analysis would be about the costs recorded at every step in the data object instance q. Another analysis targeting execution times allows identifying bottlenecks in the process model and both mentioned analyses may visualize room for process improvements. The object state transition event aligns to structured events as defined by Herzberg et al. [8] with the event content from their definition being represented by the snapshot of the data object q and data state s reached through the respecting transition. Referring to this work, we define an object state transition event type ET for each data object that is managed in an event type repository, Fig. 1 Event Level. Definition 4 (Object State Transition Event Type). An object state transition event type is a tuple ET = (, B), where D is the corresponding data object and B is a set of bindings that are required to access the information about the state transitions of the particular data object. The event type refers to the data object affected by a state transition represented by an object state transition event. Additionally, the object state transition event type holds information about the set of all bindings available for the particular data object. A binding links an object state transition of a specific object life cycle with an information system allowing the identification of the respecting state change information, because information about the transition of a data object to a new object state is represented in the information system landscape as shown in Fig. 1 IT Level. Such state change information may be, for instance, the insertion or update of an entry with a specific identifier in a database. An object state transition is observable if and only if there exists a binding for that transition. During process modeling, data objects may be associated with several process models. In our example, see Fig. 1 Process Level, data object is associated with process model M and is read and written in different states (a, b, and c) by particular activities, which are in sequence X, Y, Z surrounded by a start and an end event. An activity reads a data object in a certain state, creates a data object in a certain state, or transfers a data object from one state into another one. For instance, activity Z transfers from state b to state c only although the object life cycle would also allow a transition to state d. Altogether, the given process model conforms to the given object life cycle [13]. During the process execution (run time) the object state transition events are created according their specification described by the object state transition event type. The event store (Event Level in the Instance View in Fig. 1) comprises all transition events generated and persists them for further usage. Information about process execution can be gathered from the assignment of data objects to activities and the transition events. We assume that an activity is enabled if the activity could be executed with respect to the control flow specification and if all required input data objects are available in the corresponding object states as specified in the data object input set. Analogously, we assume that an activity is terminated once the data objects are present in the respective object states as specified in the data object output set. A data object input respectively output set specifies for each activity the input respectively output data objects including their object states and their required combination.

6 As aforementioned, process execution can be monitored for those activities that consume respectively provide data objects in certain object states, where the corresponding object state transitions can be observed by events. In Fig. 1, the object state transition set b is observable because of an existing binding and event type. If a corresponding event appears in the event store, we can reason about activity termination for the corresponding process instance. The object state transition set a cannot be observed such that it is not possible to derive information about the termination of activity X through data object information. Knowing about the existence of output data objects and the termination of the corresponding activity allows to derive the enablement of the directly succeeding activity from that information, if the succeeding activity requires a subset of the output data objects from the preceding activity. In Fig. 1, observing a transition event correlating to the transition set b, we consider activity Y of the respecting process instance to be terminated and activity Z gets enabled, because it uses exactly the output of Y as input. In the figure, we denote this insight by the bent arrow from t to e between both activities in the instance view. Furthermore, an event correlating to transition set c is not yet being observed although it is expected to happen at some point in time. This, we indicate with a dashed bold line between object states b and c in the object life cycle. 2.3 Object State Transitions Object state transitions highly influence activity enablement and termination that are closely coupled with data object input and output sets respectively, which are specified for each activity. Both sets are comprised by further sets with each set containing a positive number of data objects in specific object states. Fig. 2 represents a process model fragment and an object life cycle comprising the state manipulations done by the activities. A and B are executed in interleaving order; the actual execution order is not enforced by data dependencies due to the extensive data object input and output alternatives and therefore relies on control flow only. In Fig. 2a, the input set {{(, b)}, {(, x)}} of activity A comprises two sets each containing one entry stating that data object is required for enablement either in state b or in state x. In case the input set comprises multiple sets, they will be checked one by one for [x] X [b] [a] x [x] [x] A B (a) a b (b) [a] [b] ab [ab] [ab] [ab] C Fig. 2. Process fragment (a) and corresponding object life cycle (b) satisfaction and the first one satisfied by currently existing data objects is utilized to enable the corresponding activity. As already mentioned above, only state transitions with a respecting binding are observable. Referring to Fig. 2b, only the transitions corresponding to activity A in Fig. 2a are observable. Following, execution of activity B cannot be captured by means of object state transition analysis such that we cannot easily reason about enablement of activity C. In fact, between termination of activity X and termination of activity C, we cannot identify the exact current state of the process, i.e., which activity is currently enabled.

7 But, combining the approach presented in this paper with control flow monitoring approaches, the execution of B might be detected through a positioned event monitoring point, preferably to monitor termination of B. Then, we can easily reason about the execution of both interleaving activities and following about enablement of C. Knowing about the existence of output data objects (here: from B) and based on that control flow information, we can derive that a state transition corresponding to activity B must have been occurred. If the event monitoring point is related to another happening of B, e.g., enablement or begin, above mentioned reasoning only leads to success if B is executed before A. Assuming the life cycle from Fig. 2b with state ab being independent from states a and b and an activity Z having state x as input and state ab as output, two state transitions are comprised by that activity. If both transitions to state ab can be observed, we can reason about termination of Z. Otherwise, control flow information needs to be considered (see above). In case only one transition to ab is observable but a previous transition on the other path is also observable (as notated in Fig. 2b), we can derive at run time whether reasoning about termination of Z is possible from object information. If the transition to state x is not observable and therefore enablement of Z cannot be implied, observing of state a allows to reason about the start of Z. 2.4 Binding Organizations, which follow a model driven execution of business processes, collect the information about the execution of their processes in information systems. In our approach, we assume that information about events is extracted from existing legacy data stores. All data processed during the process execution is stored in the IT systems including process context data, processed data objects, and occurred events. In this section, we discuss how the object state transitions represented within a Data Object Life Cycle Level can be mapped to the corresponding data state representations at the IT Level (see Fig. 1). For this purpose, we define the binding of a specific object state transition of a data object to the corresponding object state representation as follows: Definition 5 (Binding). A binding is a mapping function bind : D T I, where D is a a finite non-empty set of data objects, T is a finite set of object state transitions modeled within a data object life cycle, and I is the set of implementations, i.e., rules and methods, specifying how to extract event information from different data sources within the information system landscape. The defined binding-function can be applied for various data sources within an IT systems landscape, e.g., for querying databases, processing Web service invocations, analyzing structured datasets, stream processing filters, or reading a log entry. Assuming, for instance, that event information is stored within a relational database, the techniques of schema summarization [24] combined with schema matching techniques [22] and matching approaches based on linguistic comparison [22] can be applied to map the object state transitions to the corresponding data representation and to realize the binding in this particular example to columns and rows of a relational database. Thus, the bind function is used at design time to identify the mappings, which are then stored within the binding repository.

8 In the second step, the object state transition events are generated based on the IT Level representation at run time, using the mapping information, which is defined by the binding function. Each discovered event will then be stored within an event store using the structure defined in Definition Enable Object State Transition Events by Process and Data Modeling For our approach, we allow independent modeling of data objects and their life cycles and of business processes. However, data objects are required to be modeled in the process model as well to enable more detailed views on the business processes [14] and to allow the application of the approach introduced in this section. The independent modeling allows reusing data objects and their object life cycles such that they may be modeled once with all applicable manipulations for each object and then reused by coupling them to multiple process models using a subset of the specified manipulations, i.e., state transition. Thereby, a process model must only use a set of transitions of the corresponding object life cycle for single activities, i.e., each process model has to satisfy the notion of weak conformance with respect to all data objects used in that model [13]. Summarizing, the presented approach to improve business process intelligence consists of several steps: (i) the definition of an object life cycle for each data object using a state machine, (ii) the specification of the observable object state transitions in the object life cycle via the binding function, which maps such transition into an information system and (iii) the model of the business process and the assignment of data objects to the corresponding activities. Utilizing this setup, processes can be partly monitored by analyzing the data object states of activities input respectively output sets to predict the enablement respectively termination of those events. In the next section, we will apply the approach to an order process. 3 Model View Application by Use Case We apply the presented approach to a product order process. A product is requested from the customer by an order. This request could be a normal one or an urgent one that requires express shipping. The orders are fulfilled with products in stock; however, sometimes the products need to be produced by machines first. Thus, we find four different data objects in this example case: (a) the order, (b) the product, (c) machines in Order i created received accepted confirmed shipped invoiced paid rejected archived (a) in stock i not in stock purchased shipped received Machines set up i maintenance in operation retired Type of Shipment i express regular (b) Fig. 3. Life cycles of data objects (a) Order, (b), (c) Machines, and (d) Type of Shipment used in the process model in Fig. 4. The transition labels are omitted due to space requirements. (c) (d)

9 Table 1. Example of representation of the object instances in a relational database. product id... in stock not in stock purchased received shipped : : : :13 null :34 null null null : :55 null null null null the production line, and (d) the type of shipment. These data objects are described by object life cycles, see Fig. 3. Based on these object life cycles the state transitions are selected that can be observed in the information systems and the bindings are defined that allow the access to this data. For orders it is possible to observe the data state transitions to states accepted, rejected, confirmed, shipped and paid. In case of the product, every state transition can be tracked in the information systems, whereas for the machines none of the state transitions are tracked. For the data object type of shipment the state transition to the state express is observable. Consider the representation of the data object depicted exemplarily in Table 1. The presented table shows excerpt-wise a table of a relational database, which stores the states of the object. We omit some columns for space reasons. Each row of the table represents an instance of the object in a certain state in accordance with its defined life cycle, introduced in Fig. 3. The stored objects evolve over time changing their state by changing the records within the depicted table. The mapping of a state transition defined in the object life cycle to the implementation of the data extraction from the data source is established by a binding function. The implementation identifies the location of the timestamps of transition occurrence for each object at the model level. As in our case the data source is realized by a relational database, a database query stencil using, e.g, SL as a query language, will describe the implementation. Listing 1.1 shows an example of a binding for an object state transition of the object from state received to state in stock. bind ( ( P r o d u c t, ( r e c e i v e d, i n s t o c k ) ) = { SELECT i n s t o c k FROM P r o d u c t WHERE P r o d u c t. p r o d u c t i d = <p r o d u c t i d> AND P r o d u c t. r e c e i v e d!= n u l l AND P r o d u c t. s h i p p e d!= n u l l ;} Listing 1.1. Definition of binding for an object state transition of the object from state received to state in stock For the order process, the company designed a process model, see Fig. 4, consisting of an initial activity Analyze order that uses an received order as input and transfers the Order to the state confirmed and may produce a data object Type of shipment in state express if express shipment is required. After an order has been confirmed it is checked, whether the product request is in stock or not by the activity Check stock creating the data object either in state in stock or not in stock. Based on this outcome, a decision is made whether the product needs to be produced or products in stock fulfill the order. In case the product is not available, the raw material for the production is purchased (activity Purchase raw material) and the production plan is made (activity Make production plan). The activity Purchase raw material utilizes the data object and sets the state purchased to it once the required raw material is ordered. Make production plan has the data object as well and outputs the machines setup (data object Machines

10 Order [received] Analyze order Order [confirmed] Type of Shipment [express] [not in stock] Check stock [not in stock] [not in stock] Type of Shipment [express] Purchase raw material Make production plan Ship product [shipped] [purchased] Receive purchased material Order [shipped] [received] Manufacture product Machines [set up] Fig. 4. Order process in state setup). Once the purchased material is received, the is manufactured (activity Manufacture product) ending with the products being in stock again (data object in state in stock). When the produced order is in stock, the activity Ship product can be executed. This activity has a data object input set consisting of two elements requiring either the data object in state in stock or the data object in state in stock and the data object Type of shipment in state express. Once the activity is executed, the state shipped will be set to data object as well as to data object Order. With the usage of the data objects in the process model described above, the information about the observed data state transitions can be used for process monitoring and progress prediction. How this is achieved will be discussed in the following section by application of our approach at the instance view. 4 Instance View Application by Use Case In this section, we show the application of the introduced approach at the instance level using the order process defined in the previous section as example. First, we show how the identified bindings can be used for extraction of object state transition events from data sources at the IT Level. Afterwards, we discuss how they can be utilized to predict the behavior of the concrete process instance. In the first step, we use the binding example introduced for the object in Listing 1.1 as a foundation for the definition of transition events. This binding defines exemplary the SL stencil, which describes the access to the data set, reflecting the object state transition from state received to state in stock. This binding is part of the set of bindings, which describes object state transitions of the object : bind(p roduct, (received, in stock)) B P roduct. At the instance level, the defined binding can be used to access the data, which indicates the state transition of the instance of object with product id = 856 described in Table 1. For this purpose, the SL query stencil can be used replacing the placeholder < product id > with the object s instance data Further, the transition events can be extracted from the data sources using the object state transition event type ET P roduct = (P roduct, B P roduct ) under consideration of the appropriate bindings as described in the example above. One object state transition event for the state transition towards in stock may look as follows: E 1 = (ET P roduct ; 0001; :02; (856,..., :02, :40,

11 10:51, :13, null); in stock). The event follows the structure introduced in the object state transition event definition (cf. Definition 3). The object is a record of the database at the point of time, when the event has occurred. The event id is generated. Additionally, we observed the following object state transition events in sequence for the product 856. An event indicating the state not in stock was reached and from there the state purchased was reached. Another event indicates that the data object product was received. There is no event recognized for the shipping of the product yet, see Fig. 5. Analogously, we observed the state confirmed for the data object instance order 411. In the information system, there is no information available about the type of shipment. For machines, we cannot observe any state transition at all. With the existing events, we can predict the progress of the order process instance for order 411. The techniques for correlation between instances of the order and the product data objects and the process instance are not part of this paper; they can be established by using approaches as presented in [15]. Because we cannot observe the state received of data object order, it is not possible to predict the enablement of activity Analyze order. However, we can monitor the state accepted, which is between the object states received and confirmed expected in the output set, but not modeled in the process model. Nonetheless, we can derive from that information, when the activity Analyze order began. The observation of the transition event of order 411 to state confirmed fulfills one of two sets of the output set ({{(Order, conf irmed)}, {(Order, conf irmed), (T ype of Shipment, express)}}) of activity Analyze order, thus the activity is finished. Afterwards, we recognized a instance 856 i in stock not in stock purchased (a) shipped received Process instance for order instance 411 Order [received] Analyze order Order [confirmed] Type of Shipment [express] [not in stock] Check stock [not in stock] [not in stock] Type of Shipment [express] (b) Purchase raw material Make production plan Ship product [shipped] [purchased] Receive purchased material Order [shipped] [received] Manufacture product Machines [set up] Fig. 5. Instance view of (a) the object life cycle for data object with id 856 and (b) the process instance for object Order with id 411. (a) shows for the product instance the current state as well as the historic ones based on the object state transition events generated from the information existing in the information systems. The specific product is currently in state in stock and reached it via states not in stock, purchased, and received (black arrows). It is expected to transition to state shipped some time in the future (dashed arrow). (b) shows the actual progress of the process instance of order 411 with activity Ship product being currently enabled. Thereby, all object state transition events relevant for this order are illustrated using the corresponding data objects: white colored data objects were observed in the respective state, gray colored data objects were not observed in the respective state yet, and gray bordered data objects cannot be observed in the respective state. Ticks visualize successful termination of activities, whereas the watch symbolizes an activity that is enabled respectively currently running.

12 transition event for reaching the state not in stock of product 856. Since this is one valid output of activity Check stock, this activity is terminated as well. Based on the state of data object, the decision is made for producing the product. By observing the transition event to state purchased of instance 856 of data object product, it can be predicted that activity Purchase raw material is terminated. Analogously, this holds true for activity Manufacture product by recognizing the transition event for reaching the state in stock for product 856. However, we cannot predict the termination of the activity Make production plan from the available event information only. The control flow of the process model needs to be taken into account as well, so that it can be assumed that once the activity Manufacture product is enabled, by observing object state transition event for product 856 and state received, the activity Make production plan must be finished before. With the transition event for product 856 and state in stock, the enablement of activity Ship product is denoted, because one set of the input set ({{(P roduct, instock)}, {(P roduct, instock), (T ype of Shipment, express)}}) of the activity is met. The activity is not finished so far since the output set is not fulfilled, e.g., {{(P roduct, shipped), (Order, shipped)}}. Both object state transition events are not observed yet. Even if one of those were already recorded, the activity cannot be set as terminated as the output set requires that both data objects, and Order are in state shipped. Thus, activity Ship product is enabled respectively running, indicated by the watch in Fig. 5. Showing that the prediction of a process instance s progress, e.g., process instance for order 411, can be achieved by utilizing information about the state transitions of data objects illustrates the importance of the existence of object state transition events. 5 Related Work In this section, we discuss the state of the art for process monitoring and analysis, event recognition, data modeling in business processes, and the correlation between process modeling artifacts and information systems. As motivated, the presented approach targets on the enhancement of the event basis for business process intelligence (BPI). BPI aims to enable quality management for process executions by utilizing features like monitoring and analysis, prediction, control, and optimization [5]. A lot of literature discusses business process execution data capturing and storage [3, 5], however, most of them assume that every process step is observable and thus, the recorded event log is complete. [18] proposes a reference architecture for BPI, consisting of three layers, i.e., integration, function, and visualization. The presented approach targets in particular on the integration and the combination of information about data objects and the process execution. One application of BPI is process mining [2] that benefits from the presented approach, because more data about the process execution is made available. The events about the data object state transitions can be composed with the process execution events already existing to form a more fine-grained event log to enable existing process mining techniques. The approach targets on the same vein as our previous works do where we present approaches for event recognition in especially manual executing process environments. In [6], an approach is presented that shows how event information out of information systems can be assigned to particular activities of a business process. [8] discusses how the recognition of events could be improved by utilizing process knowledge and external

13 context data data that exists independently of the business processes and their execution. The authors deal with correlation of events to each other but also the correlation to a process instance as well by applying common correlation techniques, like the algorithms for the determination of correlation sets based on event attributes introduced in [16]. Modeling data in the context of business processes received much attention such that most current process modeling notations support the modeling of data information [14] especially for enacting process models. In this regard, requirements on data modeling capabilities are determined [9, 15]. Currently, the activity-centric (current standard way of modeling [15, 21]) and the object-centric modeling (cf., for instance, business artifacts [19] and the PHILharmomicFlows project [9]) paradigm are distinguished. Our approach introduced in this paper generally works with both paradigms, but several adjustments need to be undertaken to migrate it from one to the other paradigm. In this paper, we focused on activity-centric modeling because it is the current standard way of modeling and therefore the most used one such that our approach achieves highest impact. Furthermore, we assume the correlation of data object instances to process instances exists or can be ensured by the modeling approach [15]. Additionally, to support the design time part of approach, one may use a process model describing all actions and manipulations performed on data objects and synthesize the object life cycles from that model [4, 11]. The other way round, the complete process model can be extracted from object life cycles [10] potentially considering given compliance rules [12] to allow monitoring and analysis on all allowed aspects of a process. Data objects and their object life cycles to be used in process models may also be extracted from structured data sources as, for instance, ERP systems [20]. If the process model gets specified independently from the object life cycle, a conformance check can be applied to ensure that the process model only requests data manipulations allowed from the object life cycles of the data objects utilized in the process model [10, 13]. Various techniques from the area of information retrieval can be used to support automatic binding identification. We argue that in cases where data sources at the IT Level can be represented in form of an XML schema, e.g., relational databases, Web service requests and responses, structured event logs etc., approaches from the area of schema summarization [22] can be used to identify the relevant data structures, which represents the object state transition in the object life cycle. Additionally, schema matching techniques surveyed in [22] can be used to propose the matching of the object state transitions to the appropriate parts of the schema. 6 Conclusion In this paper, we presented an approach to utilize object state transition events for reasoning about process progress and the enablement respectively termination of activities. Thereby, the transitions are linked to activities of the process model and contain, if they are observable, a binding, which links them into information systems, which hold information to recognize state changes for the observable transitions. If such state change is recognized for an object instance, a corresponding object state transition event is generated and then utilized for the mentioned reasoning. Combined with control flow based event recognition, this approach increases the number of events and therefore the log quality to be used in the field of business process intelligence for mining, monitoring,

14 and analysis. In future work, we plan to also extract events from resource information to further improve the quality of the event log used for business process intelligence. References 1. van der Aalst, W.M.P.: The Application of Petri Nets to Workflow Management. Circuits Systems and Computers 8, (1998) 2. van der Aalst, W.M.P.: Process mining: Overview and Opportunities. ACM Transactions on Management Information Systems (TMIS) 3(2), 7:1-7:17 (2012) 3. Azvine, B., Cui, Z., Nauck, D., Majeed, B.: Real Time Business Intelligence for the Adaptive Enterprise. In: CEC/EEE. p. 29. IEEE (2006) 4. Eshuis, R., Van Gorp, P.: Synthesizing Object Life Cycles from Business Process Models. In: Conceptual Modeling. pp Springer (2012) 5. Grigori, D., Casati, F., Castellanos, M., Dayal, U., Sayal, M., Shan, M.: Business Process Intelligence. Computers in Industry 53(3), (April 2004) 6. Herzberg, N., Kunze, M., Rogge-Solti, A.: Towards Process Evaluation in Non-automated Process Execution Environments. In: ZEUS. pp (2012) 7. Herzberg, N., Meyer, A.: Improving Process Monitoring and Progress Prediction with Data State Transition Events. In: ZEUS (2013) 8. Herzberg, N., Meyer, A., Weske, M.: An Event Processing Platform for Business Process Management. In: EDOC. IEEE (2013), accepted for publication 9. Künzle, V., Reichert, M.: PHILharmonicFlows: Towards a Framework for Object-aware Process Management. Journal of Software Maintenance 23(4), (2011) 10. Küster, J., Ryndina, K., Gall, H.: Generation of Business Process Models for Object Life Cycle Compliance. In: Business Process Management. pp Springer (2007) 11. Liu, R., Wu, F.Y., Kumaran, S.: Transforming -Centric Business Process Models into Information-Centric Models for SOA Solutions. J. Database Manag. 21(4), (2010) 12. Lohmann, N.: Compliance by design for artifact-centric business processes. In: Business Process Management. pp Springer (2011) 13. Meyer, A., Polyvyanyy, A., Weske, M.: Weak Conformance of Process Models with respect to Data Objects. In: ZEUS. pp (2012) 14. Meyer, A., Smirnov, S., Weske, M.: Data in Business Processes. EMISA Forum 31(3), 5 31 (2011) 15. Meyer, A., Pufahl, L., Fahland, D., Weske, M.: Modeling and Enacting Complex Data Dependencies in Business Processes. In: BPM. Springer (2013), accepted for publication 16. Motahari-Nezhad, H.R., Saint-Paul, R., Casati, F., Benatallah, B.: Event correlation for process discovery from web service interaction logs. VLDB Journal 20(3), (2011) 17. Murata, T.: Petri nets: Properties, Analysis and Applications. Proceedings of the IEEE 77(4), (1989) 18. Mutschler, B., Bumiller, J., Reichert, M.: An Approach to uantify the Costs of Business Process Intelligence. In: EMISA. pp (2005) 19. Nigam, A., Caswell, N.S.: Business artifacts: An approach to operational specification. IBM Systems Journal 42(3), (2003) 20. Nooijen, E.H.J., Dongen, B.F., Fahland, D.: Automatic Discovery of Data-Centric and Artifact- Centric Processes. In: BPM Workshops, pp Springer (2013) 21. OMG: Business Process Model and Notation (BPMN), Version 2.0 (2011) 22. Rahm, E., Bernstein, P.A.: A survey of approaches to automatic schema matching. VLDB Journal 10, 2001 (2001) 23. Weske, M.: Business Process Management: Concepts, Languages, Architectures. Second Edition. Springer (2012) 24. Yang, X., Procopiuc, C.M., Srivastava, D.: Summarizing Relational Databases. VLDB Endowment 2(1), (Aug 2009)