Nico Herzberg
email: nico.herzberg@hpi.uni-potsdam.de

Mathias Weske
email: mathias.weske@hpi.uni-potsdam.de

Hasso Plattner

Making Process Model Versions Comparable by Quantifying Changes

Keywords: Business Process Management, Business Process Models, Process Evaluation, Process Analysis, Process Versions

A central task in the business process management life cycle is the evaluation of business processes to get a solid base for process improvements. Business processes are described as process models to explicitly state the operations needed to be carried out to reach the companies' business goals. These process models evolve over time because of changing market conditions, process improvements, or legal changes, etc. and result in multiple process versions. In such circumstances, process analysis requires the comparison of several process versions, the so-called multi-version evaluation. This paper tackles this challenge and introduces a technique to identify and quantify individual influences caused by differing process versions.

Introduction

Nowadays, organizations face a competitive market environment and need to be as flexible and efficient as possible. Therefore, they are managed in a processoriented fashion to be able to react quickly on market changes. Business process management (BPM) combines concepts, methods, and techniques to support the design, administration, configuration, enactment, and analysis of these business processes in an iterative way [START_REF] Weske | Business Process Management: Concepts, Languages, Architectures[END_REF]. One corner stone of the BPM life cycle is the evaluation of business process executions to identify the weak points and potential improvements. Central to BPM are process models as they explicitly describe the operations that need to be carried out to reach the companies' business goals and are used, among others, for enactment.

For instance, changing market conditions, elimination of identified weak points by implementing business process improvements, or legal changes result in business process model changes and therewith in a variety of business process models, so-called process versions. Therefore, reliable business process analysis requires all versions of a business process taken into account to get a complete picture of the business process executions so far. Most information systems that are used for business process execution collect data about the performed activities. This data can already be analyzed in the context of business processes and their corresponding process models by using methods and techniques from the field of business process intelligence (BPI) [START_REF] Mutschler | Business Process Intelligence[END_REF][START_REF] Grigori | Business Process Intelligence[END_REF][START_REF] Azvine | Real Time Business Intelligence for the Adaptive Enterprise[END_REF]. Still, these methods and concepts are targeting on one specific process version only and are not able to handle the evolution of a process including several process versions.

In this work, we present an approach for identifying and quantifying variations of process metrics that are caused by the differences in the process versions to allow process analysis with several versions of a process. We introduce a technique to determine the actual effects of structural process model changes between process versions for a specific process metric. With the approach, we make several process versions comparable based on their common denominator. A multi-version evaluation computes a single metric, e.g., a point-to-point duration metric, using execution data from the set of all process versions or a subset of those. The studies in this work are performed using as example the point-to-point duration. This metric represents the time that elapsed between reaching a first point (A) and reaching a second point (B) during the execution of a process. In this work, we show the algorithm for determining which parts of a process model, i.e., process fragments, affect a specific point-to-point duration. These calculated process metrics can be used for process monitoring and analysis.

In the remainder, we introduce basic terms and concepts our work bases on (Section 2) followed by the description of a motivating example from health care in Section 3. In Section 4, we explain our approach in detail and present how we use newly introduced measured region models and process model structuring techniques to determine whether process model changes can be highlighted for multiple process versions analysis. In Section 5, we apply the presented approach to our motivating example and show concrete duration delta calculations. We put our work into the context concerning related work in Section 6, before we summarize and conclude the paper in Section 7.

Preliminaries

For this work, we rely on a simplified notion of process models defined as follows.

Definition 1 (Process Model).

A process model is a tuple P = (N, F, κ), where N is a finite set of nodes N and F ⊆ N × N is the control flow relation. N = A ∪ G ∪ E comprises the activity nodes A, the gateways G, and the start and end nodes E = {s, e}. κ : G → {and, xor} associates each gateway node with a type.

Activities have exactly one predecessor and one successor. Whereas gateways have either one predecessor and several successors (split) or several predecessors and one successor (join). We assume the process model to be structural sound, to ensure that the process model P has exactly one start node s and one end node e, and every node is part of a valid path from s to e. Refactoring techniques may be applied to normalize models that do not match these assumptions [START_REF] Vanhatalo | Automatic Workflow Graph Refactoring and Completion[END_REF]. We further require process models to be block-structured and their petri-net representation to be sound [START_REF] Van Der Aalst | Verification of Workflow Nets[END_REF], which ensures the absence of behavioral anomalies such as deadlocks.

The process model serves as a blueprint for the so-called process instances. A process instance is a concrete execution of the activities defined in a process model.

Process monitoring and analysis is targeting on the evaluation and comparison of process instances.

As we are interested in measuring the time it takes to execute a part of a process instance, we require measurement points that denote a particular node is reached. However, positioning of such a point on process model node level only is too coarse-grained, because it is often required to track the begin and the end of an activity for instance, e.g., to distinguish between waiting times and the time it actually requires to carry out a certain activity. Therefore, we assign a node life cycle to each node of the process model to allow a more fine-grained positioning of the measurement points based on the state transitions of those life cycles, cf. [START_REF] Herzberg | An Event Processing Platform for Business Process Management[END_REF].

Definition 2 (Node Life Cycle).

A node life cycle is a tuple L = (S, T ), where S is a finite set of node states and T ⊆ S × S is a finite set of node state transitions. Let P = (N, F, κ) be a process model. There exists a function ϕ : N → L that assigns a node life cycle to every node n ∈ N of P .

State transitions are the elementary constructs that can be leveraged to position points in the process model where measurements could be taken. A point where a measurement could be taken on a state transition of a node is called process event monitoring point (PEMP), cf. [START_REF] Herzberg | An Event Processing Platform for Business Process Management[END_REF]. The set of all node state transitions of a process model

P = (N, F, κ) is comprised by n∈N {(n, t)|t ∈ T ϕ(n) },
each of which could be potentially linked to a PEMP. T ϕ(n) ⊆ T represents all node state transitions t ∈ T returned by function ϕ(n) = (S, T ) for node n ∈ N .

Definition 3 (Process Event Monitoring Point).

A process event monitoring point is a tuple P EM P = (P, n, t), where P is the process model it is contained in, n ∈ N is the node it is created for, and t ∈ T is the state transition within the node life cycle of n it is assigned to.

Motivating Example

In our motivating example, we will look on the diagnosis of a patient's disease in a hospital, see Fig. 1a. The first activity in the initial diagnosis process version is "Withdraw Blood Samples". Afterwards the blood samples are analyzed (activity "Analyze Blood Samples") in parallel to the examination of the patient (activity "Examine Patient"). Updating the patient's records finishes the process (activity "Update Patient's Records").

For quality assurance it is essential to measure the time consumed between the point in time when the patient is introduced to the doctor (A) and the patient's data are updated according to the examination results and the blood sample analysis (B). For measuring such a point-to-point duration, we utilize PEMPs. A PEMP, cf. Definition 3, is bound to a specific state transition of a node's life cycle, cf. Definition 2 to indicate that this state transition happened by occurrence of the corresponding data in the information system landscape. Referring to Fig. 1a and Fig. 1b, we assigned to each activity of the process model the same node life cycle consisting of the states enabled, running and terminated with the corresponding state transitions (e)nable, (b)egin and (t)erminate. However, the solution allows applying individual life cycles to the nodes. In Fig. 1 the life cycles are represented by black dots and edges between them. A black dot represents a node state transition while an edge between two black dots represent the node state. In the scenario not every node state transition is observable by occurance of data from the information systems. Therefore, only PEMPs that can be observed are shown in Fig. 1. P EM P 3 in Fig. 1 indicates that activity "Examine Patient" is enabled for execution and P EM P 6 represents the end of the patient's data record update.

Due to legal changes, the hospital adjusted the diagnosis process for the patients by adding a process fragment, i.e., the activity "Perform Sonography", see Fig. 1b -shaded activity. In this second process version the termination of the sonography could be captured by P EM P 5 . Introducing a process fragment, e.g., an activity, might affect the overall run time of the diagnosis process instances and therewith the point-to-point duration between the introduction of the patient to the doctor and the completion of patient's data update. An analysis summarizing process instances of both versions, the first version without the sonography, and the second version including the sonography, is not possible, because the results would be mixed up and falsified accordingly.

With the comparability of process instances of several different process versions several questions about the quantification of effects between the single process versions arise. For instance in our case it would be interesting to answer the following: (i) What are the diagnosis durations after adding sonography activity? (ii) Are the durations for the unchanged part of the model different before and after adding sonography?

Solution

Our approach targets on the determinability of effects caused by process changes. We will show the concept of our approach using the example of the point-to-point duration process metric. The point-to-point duration is a measure for the elapsed time it takes to traverse the sub-graph of a process model that is spanned by an activity indicating the start (A) and an activity indicating the end (B), see Fig. 1a and Fig. 1b. We assume that both activities can be measured by a PEMP. We use the existing process model, the defined point-to-point duration metric, the change log to the process model that captures all the changes applied to the model, and the defined PEMPs to apply our four-step approach.

First of all, a measured region model is derived from the source process model (version 1) based on the point-to-point duration metric. A node of the process model is part of the measured region model if its duration influences the point-topoint duration. The resulting connected sub-graph contains all such influencing nodes and builds the basis for our approach (see Section 4.1). A measured region model is a process model according to Definition 1. Secondly, the measured region model is enriched by the changes applied to the source process model contained in the change log (see Section 4.2). Afterwards the enriched measured region model is transformed to a component tree by utilizing the technique of the refined process structure tree (RPST) [START_REF] Vanhatalo | The Refined Process Structure Tree[END_REF]. The resulting component tree is enriched with the information of defined PEMPs and an event monitoring model is built in a third step (see Section 4.3). In the fourth step, based on this event monitoring model it is determined whether the effects of the process model changes can be identified and quantified for more accurate process analysis (see Section 4.4).

Transformation to a Measured Region Model

The measured region model is the basis for determining, which structural changes might affect the point-to-point duration metric, as it contains the relevant process nodes only; see the processes shown in Fig. 2 for an example. The left side shows the original process model and the right shows the measured region model for the given point-to-point duration metric. Per definition, all elements not contained in the measured region model can be removed from the process model without affecting the given point-to-point duration metric.

Fig. 2a shows that every node on a path from node A to node B (including both nodes) is contained in the measured region model. However, this is not the

(a)$ Original$Process$Model$ Measured$Region$Model$ cycleA=first$ (b)$ (c)$ A D B E C A D B E A D B E C A D B E C B D A B D A C B D A B D A C A B D A B D C A B D A B D Fig. 2:
A selection of measured region models for a point-to-point duration metric influenced by (a) an exclusive process fragment, (b) a parallel process fragment, and (c) a loop process fragment. In (c) a start event is added to assures that there is always a single entry and single exit point in the measured region model.

case with parallel and inclusive join gateways as they represent synchronization points in a process, which wait for the completion of all incoming branches. If node A is contained in such a branch, then the other branches are not on a path from node A to node B, but they might still influence the point-to-point duration because of the synchronizing behavior of the joining gateway, see Fig. 2b. This does not apply to exclusive conditional join gateways, as they trigger immediately when a single branch is completed. When considering cycles, the start point, end point, or both of the duration metric might be part of the cycle. Thus, the relating activities can be executed several times and therewith, multiple activity instances exist. Therefore, we need to consider user input to know whether the first or last activity instance is relevant for the point-to-point duration. We describe these inputs in the metric parameters cycleA, cycleB = {first, last}. It depends largely on the parameters of the metric, whether the corresponding cycle is part of the region or not, see Fig. 2c. If only node A (and not node B) is part of a cycle and cycleA = first, then that cycle needs to be part of the region. If cycleA = last, then the cycle is not part of the region, as it was not executed again after the last triggering of A. The parameter cycleB has a corresponding effect on the inclusion of a cycle containing node B.

The algorithm to create a measured region model starts with the search of all relevant paths from A to B by using a traversal of the succeeding nodes starting with node A. If node B is encountered, then the current path is saved as a relevant path and that path is not traversed further. Traversal can also be stopped, if a node has no unvisited successors or node A is encountered. In the latter case, the path is also marked as relevant, if A is in a cycle and cycleA = first. If B is in a cycle and cycleB = last we also need to find all paths from node B to itself. This case can be handled by starting a second traversal of succeeding nodes in the process model, this time starting from node B. As in the first traversal, paths to node A or node B are added depending on the mentioned parameters.

Once the set of relevant paths has been determined, each path is traversed in order and a new node is added to the measured region model for each node in the path, if the node does not exists in the model already. Further, we have to consider the case of encountering synchronizing gateways, whose start gateway is outside of all relevant paths. While traversing each path, we keep two counters, one for splitting and another for joining parallel and conditional gateways. If both counters are equal and such a joining gateway is encountered, then we know that this gateway does not have a splitting counterpart in the measured region model yet. Thus, the next step is to add all its incoming branches to the measured region model together with the splitting gateway to ensure structural soundness. The original process model is traversed backwards using the predecessors of nodes to find the first splitting gateway that is common to all branches that is then used as split in the measured region model. This backward tracing starts from the joining gateway.

To connect all the nodes, a directed edge is added from each node to it's successor in the path. Eventually, an explicit start node s or end node e is added when the measured region model includes cycles. This assures that there is always a single entry and single exit (SESE) point in the measured region model. As the final step, gateways with a single predecessor and a single successor are removed from the measured region model as they do not affect the duration and are not allowed in a process model per definition.

With this, the creation of the measured region model is complete. The measured region model contains the elements of a process model that affect a specific point-to-point duration from activity (A) to another activity (B). In the following, we will enrich this measured region model with information from the process model change log.

Enriching Measured Region Models with Change Information

In a second step, the changes to the source process model as described in the change log are applied to the measured region model created in the previous step. In this work, we assume that the change log contains only change patterns as described by Weber et. al [START_REF] Weber | Change Patterns and Change Support Features in Process-Aware Information Systems[END_REF]. The change patterns describe the process model change relating a particular part in the process model, the so-called process fragment. These change patterns do not contain atomic or complex activities only, but also sub-graphs that need to have a SESE. The change operations are rather "simulated" in the measured region model, as the changes are marked in the model only, e.g., a removal operation applied to a measured region model's process fragment is marking that corresponding fragment only, e.g., the removal of an activity. Same holds for adding process fragments. This is necessary to keep the previous positions of the nodes for further evaluation.

For instance, the change log for our source process model shown in

Build the Event Monitoring Model

For parsing the structure of the measured region model, we apply the approach of the RPST introduced by Vanhatalo et. al [START_REF] Vanhatalo | The Refined Process Structure Tree[END_REF]. The RPST represents the process model structured as a tree with the root symbolizing the whole graph, the nodes representing canonical elements of the parent element, and the leaves denoting the edges of the graph.

As we are interested in the nodes of the process graph, the RPST has to be transformed into a component tree. The component tree consists of the canonical fragments of the RPST as process components, i.e., the component tree nodes, and the measured region model nodes itself as the component tree leaves. During the transformation, canonical fragments of the RPST are transformed into process components that subsume the process elements that are contained in the corresponding canonical fragment of the RPST. From the children of the canonical fragments of the RPST, the original measured region model nodes got extracted and attached to the corresponding process component as a child. For instance, the measured region model with the applied changes from the previous step, see Fig. 3, is structured in a component tree as shown in Fig. 4a. Note that during the transformation of the RPST into a component tree, measured region model nodes may get duplicated in different process components of the component tree. However, this will not be an issue for our approach. The marking of the applied changes are still contained in the component tree.

To the component tree leaves, the corresponding life cycles are attached by ϕ : N → L to every node n ∈ N of the measured region model P . With that step, every component tree leaf gets new children indicating the state transitions of the corresponding life cycle as shown in Fig. 4b. For simplicity reasons, every node gets the state transitions (e)nable, (b)egin and (t)erminate assigned. Afterwards, the defined PEMPs are connected according their definition P EM P = (P, n, t) to the component tree containing the measured region model nodes and the assigned state transitions. P is the indicator for the initial process model and the resulting measured region model, n the measured region model node the PEMP belongs to, and t the exact state transition that could be observed by the PEMP. In Fig. 4b, the enablement of node A, the termination of node B as well as the enablement and termination of the newly introduced node F can be observed by a PEMP.

With the consolidation of measured region model information and PEMP definitions the event monitoring model is created. Based on that, several algorithms can be run to analyze which information can be derived out of the spread PEMPs. For instance, it is possible to indicate whether the effects of a process model change can be identified and quantified to enable process analysis on multi-version processes.

Determining the Evaluation of Process Model Change Effects

Based on the event monitoring model, it is possible to determine if and how process changes influence a particular point-to-point duration metric. We categorize the determinability of effects caused by a process change to a process metric into the following four groups:

• Unchanged-the process model changes do not effect on the process metric.

• Indeterminable-the effects of process model changes cannot be identified nor quantified for any process instance. • Determinable-the effects of process model changes can be identified and quantified for all process instances. • Partly Determinable-the effects of changes can be identified and quantified only for some process instances.

We consider not only the process versions but the single process instances for categorization as we would like to provide a detailed indication on the determinability of the quantification of process changes. If there are changes whose effects can not be determined exactly, the algorithm determines whether this indeterminability holds for all process instances. To give an example, an indeterminable change in a sequence of process fragments will cause the effect of the whole sequence to be indeterminable. In the contrary, an indeterminable change in a branch of an XOR causes only those process instances that executed that particular branch to be indeterminable, thus, the effects are partly determinable.

Changes can be quantified, if their effects can be measured by PEMPs. This is the case when the beginning and the end of the added, removed or changed process fragment, e.g., the insertion of an activity, can be measured by a PEMP. As shown in Fig. 4b, for the added activity F the enablement and termination can be measured. Thus, additional time spend during process execution that may result from the activity F can be identified and quantified to allow a comparison between the initial process version and the changed one containing activity F.

The process model changes may not be measurable directly. One can think of only measuring the enablement or the termination of F or nothing. In this case, the predecessor resp. successor activities may provide some more insights with respect to the timestamps of the newly introduced process fragment. If we assume that two activities are in sequence and between the termination of the first activity and the enablement of the second activity no time is consumed, then we can use the rule, that the measured termination of the first activity is also the time of the unmeasured enablement of the second activity and vice versa.

With the categorization of the determinability of effects caused by a process change to a process metric, it is stated whether algorithms that quantify the changes, e.g., by calculating the duration influence, could be applied or not. Such calculations are not in scope of this paper, however, we will give an example in our case study where we validate the approach based on the motivating example.

The presented approach was illustrated along the point-to-point duration metric. However, the approach can be adapted to other metrics as well, e.g., point-to-point cost metric, the probability to reach a certain point in the process, or the number of iterations in a process. As long as the metric has a defined start and end point the approach can be applied as described with (i) transforming the process model into a measured region model based on the start and end points, (ii) enriching the measured region model with change information, (iii) build the event monitoring model, and (iv) evaluate the effects to the metric cased by process model changes if possible.

Case Study

In the following, we will apply the presented approach to our motivating example shown in Section 3. As shown in Fig. 1, we have a source process model (process version 1), on which the insertion of a process fragment, i.e., the insertion of the activity "Perform Sonography" is performed. This change is logged in the corresponding process model change log and described as Insert(Perform Sonography after Examine Patient). This indicates that the additional activity needs to be inserted after activity "Examine Patient". As already stated in Section 3, the required point-to-point duration metrics reaches from the enablement of the activity "Examine Patient" until the completion of patient's data updates. Furthermore, in the two process versions six different PEMPs are defined. P EM P 1 and P EM P 2 representing the start and the end of the activity "Analyze Blood Samples". P EM P 3 and P EM P 4 providing time measures for the enablement resp. termination of activity "Examine Patient", P EM P 5 indicating the termination of the sonography, and P EM P 6 providing information about the termination of the activity "Update Patient's Records". Based on this information, we will evaluate if the effect of adding the sonography to the diagnosis process can be identified and quantified.

Therefore, the point-to-point duration metrics and the process model, see Fig. 1a is used to create a measured region model, as it can be seen in see Fig. 5a. The specialty with the process model in our example is that we need to consider the upper branch of the AND split as well, although the beginning of the point-to-point duration metrics is specified just in lower branch. However, the upper branch will influence the duration in cases when "Analyzing blood samples" will take more time than the patient examination (process version 1) resp. patient examination and sonography (process version 2).

Afterwards, the changes contained in the change log are applied to the measured region model. In the change log only the insertion of activity "Perform Sonography" is recorded. Marking the corresponding process fragment in the measured region model simulates this change, see Fig. 5a -shaded activity.

Using the measured region model as a basis, the event monitoring model is build by constructing a component tree first, see Fig. 5b. The component tree is then enhanced by the life cycle information for each node. In the example, the same life cycle consisting of state transactions enable, begin and terminate and the corresonding states enabled, running and terminated is used for all activities. To these state transitions the corresponding PEMPs are assigned and therewith the event monitoring model is complete. Having the event monitoring model, we can determine, that we can quantify the effects caused by the insertion of activity "Perform Sonography". The evaluation could happen due to the fact that we can measure the completion of the sonography, i.e., by P EM P 5 . Further, we can determine the enablement of the sonography by utilizing P EM P 4 that is assigned to the termination of activity "Examine Patient", the predescessor of the inserted activity. Since we assume that during control flow no time is consumed this assumption holds.

In the following, we execute the approach to the motivating example for calculating the overall effect of all changes related to a particular point-to-point duration. We call these effects duration delta. Each structural change can be broken down to the addition or removal of process fragments. The local duration delta of such a change is thus equal to the duration of the added or removed process fragments. Once all local duration deltas are determined, we need to compute their effects on the overall duration. This can be done by applying techniques that are very similar to the aggregation of quality of service properties for process models, as described in [START_REF] Jaeger | QoS Aggregation for Web Service Composition using Workflow Patterns[END_REF] or [START_REF] Cardoso | Quality of Service for Workflows and Web Service Processes[END_REF]. These techniques determine the value of properties like execution time or cost for a whole process model, given the corresponding property values for each atomic process element. We can aggregate all local duration deltas to compute the duration delta for the whole process instance. We use a recursive calculation of duration deltas, which starts with the root fragment and terminates when a node is reached. When the recursion reaches a node, we determine the local duration delta for all its instances (remember that loops may be involved). The local duration deltas are then aggregated by the parent fragments according to their types during the roll-up of the recursion until a single value is determined by the root fragment.

For several instances of the diagnosis process, measures are captured by the PEMPs, see Table 1. Therewith, the requested point-to-point duration as well as the effect to the duration caused by the insertion of the sonography can be quantified. Patient 1 needs for the diagnosis after his blood was taken 82 minutes, patient 2 118 minutes, and patient 3 85 minutes. From this data, we can say that a patient needs in average 95 minutes (process version 1). The following patients where treated including the sonography. Patient 4 needs 132 minutes, patient 5 103 minutes, and patient 6 122, in average 119 minutes (process version 2). These results are not easy to compare adequately. For example, if we calculate the average of all patient diagnoses, we will get 107 minutes. That will lower the good results of the processing time of the first versions and increase the result of the second process version. More comparable results would be achieved by hiding the results of the sonography for the multi-version process analysis. In that case, the durations of the first three patients will remain, but the results for patient 4 will change to 69 minutes, and for patient 6 to 86 minutes. For patient 5 103 minutes will remain as well, be cause in her case the blood analysis was on the critical path. With these results we will get an average of 90,5 minutes, which is more meaningful instead of comparing process versions without considering the effects of process changes.

With these numbers, the questions raised in Section 3 can be answered. (i) What are the diagnosis durations after adding sonography activity? This can be answered by comparing the average durations of process version 1 (95 minutes) and process version 2 (119 minutes). The sonography extends the diagnosis duration by 24 minutes in average. (ii) Are the durations for the unchanged part of the model different before and after adding sonography? The answer is yes, as we can see if we hide the sonography durations, the overall run time got slightly better. Process version 1 took 95 minutes in average; if we compare all process instances (process version 1 and 2) then the average is 4,5 minutes faster.

Multi-version process monitoring and analysis is enabled by these measures and the ability to quantify process model changes. It brings huge benefits to the evaluation phase of the BPM life cycle and therewith allows better improvements on business processes.

Related Work

The presented work builds on process versions and their process model changes. However, we abstract from actual details of version management methods and assume that the implemented version management method provide two essential functionalities: (1) retrieving a specific process version and (2) retrieving the set of change operations that transform one process version into another. The version management methods [START_REF] Bae | A Version Management of Business Process Models in BPMS[END_REF] and [START_REF] Ekanayake | Fragmentbased Version Management for Repositories of Business Process Models[END_REF] meet these assumptions. [START_REF] Bae | A Version Management of Business Process Models in BPMS[END_REF] proposes a method for version control of process models based on change operations. The initial version of a process is stored as a whole, while all succeeding versions are only stored as the set of basic change operations. [START_REF] Ekanayake | Fragmentbased Version Management for Repositories of Business Process Models[END_REF] decomposes process models into process fragments using SESE components, which then are used as the primary entities of a versioning system for process models.

One of the inputs for our approach is the process model change log. These changes can be described by change patterns that are investigated in multiple works. In [START_REF] Hallerbach | Configuration and Management of Process Variants[END_REF] change patterns on arbitrary process fragments are used to model, store and retrieve process variants resp. versions by utilizing the concept of adjustment points. [START_REF] Küster | Detecting and Resolving Process Model Differences in the Absence of a Change Log[END_REF] defines a set of change patterns on canonical SESE components in a RPST. Based on these patterns, the authors are able to determine all changes needed to transform one process model into another. This technique could be used to determine the set of change operations between two process versions, if the version management method cannot provide them. Weber et. al [START_REF] Weber | Change Patterns and Change Support Features in Process-Aware Information Systems[END_REF] define an extensive and detailed classification of changes to process models into so-called adoption patterns. We used these adaption patterns in our approach, because they provide the right level of abstraction by being detailed enough to unambiguously define their effects on a process model, while still carrying enough semantic information to determine the intention behind the changes.

The approach presented in this paper aims to enable business process intelligence (BPI) in multi-version process execution environments. The capability to monitor, visualize, and evaluate business process execution is one core topic of BPI [START_REF] Mutschler | Business Process Intelligence[END_REF], which addresses "managing process execution quality by providing several features, such as analysis, prediction, monitoring, control, and optimization" [START_REF] Grigori | Business Process Intelligence[END_REF]. Bringing awareness about process changes that influence process metrics can be seen as one of that features of BPI. In [START_REF] Mutschler | Business Process Intelligence[END_REF], the authors argue that process monitoring and analysis are vital to BPI and propose, based on the specific requirements of BPI, a reference architecture, composed of an integration layer, a functional layer, and a visualization layer. The approach presented in this paper targets at the functional layer, i.e., enabling the comparability of process execution measurements from several process versions.

Del-Río-Ortega et al. [START_REF] Del-Río-Ortega | Defining Process Performance Indicators: An Ontological Approach[END_REF] introduced the concept of process performance indicators (PPI), the process related form of key performance indicators, to enable process evaluation. PPIs target on process measurements, e.g., time, costs, and occurrences. Our presented approach could support the measurements from several process versions and can ensure the comparability of the PPIs.

Conclusion

In this paper, we presented an approach to determine whether the effects of process model changes influences a particular process metric, i.e., a point-to-point duration metric. We further investigate if the influences can be quantified so that a multi-version process analysis is applicable. Therefore, we reduce the original process model to a measured region model based on the given point-to-point duration metric to identify the metric influencing process model elements. Based on the measured region model, we apply the corresponding process model changes recorded in the change log and structure the resulting model via a component tree. The component tree is enriched by the life cycle information for every node and the corresponding process event monitoring points are attached to it. This enriched component tree form the event monitoring model that could be used for determining whether the process model changes could be identified and quantified to ensure a reliable multi-version process analysis. Motivated by an example from a German hospital, we show the whole technique for a diagnosis process.

In this paper, we used the point-to-point duration process metric as example. The effects on other specific process metrics can be determined with the event monitoring model as well, which we will prove in future work. Our approach does not consider indirect dependencies between process elements nor non-structural properties of process elements. We disregard sub-process relations as such process models could be flattened. The approach does not support process models with nested loops, multi-instance nodes and loop nodes.

With the approach multi-version process analysis is possible. Effects of process model changes may can be identified and quantified and hide for several process analysis tasks. The approach applies also to process monitoring and process simulation. It is possible to simulate process model changes and evaluate the behavior of the surrounding nodes with respect to the given process metric.

Fig. 1 :

 1 Fig. 1: Evolved process model of a diagnosis process for a patient. (a) shows process version 1 with the activities "Withdraw Blood Samples", "Analyze Blood Samples", "Examine Patient", and "Update Patient's Records". (b) shows process version 2 with the additionally inserted activity "Perform Sonography".

Fig. 3 :

 3 Fig. 3: Applying change operations contained in the process model change log to the measured region model. activity F after activity E in the lower branch of the process model, e.g., stated by the change operation Insert(F after E). This operation is applied to the measured region model and F is marked as inserted, see Fig. 3 -shaded activity.A specialty in this processing step is the application of change patterns to the start and end point of the point-to-point duration metrics, i.e., to node A and B of the shown example. Changes involving node A or node B need to be handled separately, as they change the basis on which the measured region model is defined. Once the measured region model is enriched by the change information, the structure of the resulting model needs to be parsed to attach the defined PEMPs and to determine the effects of the change in the next steps.

Fig. 4 :

 4 Fig. 4: (a) shows the measured region model enriched by changes structured in a component tree. To this component tree the corresponding life cycles of the process nodes are attached by ϕ(n) and the defined PEMP are assigned (b).

Fig. 5 :

 5 Fig. 5: (a) shows the measured region model enriched by changes from the process change log that is then transformed in an event monitoring model (b).

Table 1 :

 1 Measures during patient diagnosis process correlated to PEMPs. The ID of the patient identifies process instances.

	patientID	P EM P1	P EM P2	P EM P3	P EM P4	P EM P5	P EM P6
	1	08:32	08:58	08:32	09:35		09:54
	2	09:05	10:40	09:55	10:10		11:03
	3	09:43	10:46	09:43	10:55		11:08
	4	10:02	10:10	10:02	10:55	11:58	12:14
	5	13:30	14:52	13:30	14:05	14:49	15:13
	6	13:42	13:56	13:42	15:00	15:36	15:44

Acknowledgment. Many thanks to the former student Philipp Maschke for the related initial work done during his master thesis, and the many fruitful discussions about the topic, its challenges, and the possible solutions.


Soroosh Nalchigar
email: soroosh@cs.toronto.edu

Eric Yu

From Business Intelligence Insights to Actions: A Methodology for Closing the Sense-and-Respond Loop in the Adaptive Enterprise

Keywords: Business Intelligence, Data Analytics, Adaptive Enterprise, Sense-and-Respond, Modeling framework

Business Intelligence (BI) and analytics play a critical role in modern businesses by assisting them to gain insights about internal operations and the external environment and to make timely data-driven decisions. Actions resulting from these insights often require changes to various parts of the enterprise. A significant challenge in these contexts is to systematically connect and coordinate the BI-driven insights with consequent enterprise decisions and actions. This paper proposes a methodology for closing the gap between what an enterprise senses from BI-driven insights and its response actions and changes. This methodology adopts and synthesizes existing modeling frameworks, mainly i * and the Business Intelligence Model (BIM), to provide a coherent step-bystep way of connecting the sensed signals of the enterprise to subsequent responses, and hence to make BI and analytics more actionable and understandable. Applicability of the proposed methodology is illustrated in a case scenario.

Introduction

Business Intelligence (BI) and analytics have gained a great deal of attention from both academic and business communities over past two decades [START_REF] Chen | Business intelligence and analytics: from big data to big impact[END_REF]. These systems serve as sensing mechanisms of the enterprises by providing insights about their strategic goals, operations, performance, as well as the external environment, and assist them to respond to critical situations and take advantage of emerging opportunities. However, a critical challenge to the adoption of these systems is the lack of understanding of how to use analytics and the insights resulting from them to improve the business [START_REF] Lavalle | Analytics: The new path to value. how the smartest organizations are embedding analytics to transform insights into action[END_REF][START_REF] Yu | Enterprise architecture for the adaptive enterprise-a vision paper[END_REF]. In other words, a leading challenge in using insights from BI is to connect them to business operations and hence shorten the latency. Latency is defined as the time taken from something happening within or around the enterprise to the moment when it reacts to it [START_REF] Panian | Just-in-time business intelligence and real-time decisioning[END_REF]. BI-driven insights can stimulate corrective actions and changes within various layers and different parts of an enterprise [START_REF] Yu | Enterprise architecture for the adaptive enterprise-a vision paper[END_REF]. For example, a manufacturing company that uses BI solutions may find an increasing trend in the production costs. To reduce the costs, this company may change the manufacturing layout or may decide to modify the inventory ordering policies. A hospital which uses analytics may see a long waiting time in the reception room and decides to increase the number of physicians and/or change their work schedules. A bank whose web analytics show a decreasing trend in number of online banking users and transactions, may decide to change the interface and the web-page design to make it more user-friendly and increase its ease of use. In all of these contexts, in order to trigger new changes across the enterprise and to take action at the right time, BI-driven insights must be easy to interpret, linked to business strategy, and embedded into organizational processes [START_REF] Lavalle | Analytics: The new path to value. how the smartest organizations are embedding analytics to transform insights into action[END_REF].

To tackle this problem, we propose a model-based methodology for closing the gap between what an enterprises senses from the BI insights and their response actions and changes. The proposed methodology adopts and synthesize several requirements engineering modeling frameworks, including i * [START_REF] Yu | Modelling strategic relationships for process reengineering[END_REF][START_REF] Yu | Towards modelling and reasoning support for early-phase requirements engineering[END_REF][START_REF] Yu | Social modeling for requirements engineering[END_REF] and Business Intelligence Model (BIM) [START_REF] Jiang | The business intelligence model: Strategic modelling[END_REF][START_REF] Barone | Enterprise modeling for business intelligence[END_REF][START_REF] Barone | Towards model-based support for managing organizational transformation[END_REF][START_REF] Horkoff | Strategic business modeling: representation and reasoning[END_REF], to provide a systematic and coherent way of connecting the BI-driven insights to the consequent business action and changes. Our methodology assists business users to conceptualize strategic goals and to design the sensing mechanisms for monitoring those goals. It helps them generate and analyze the alternative response actions, to make trade-offs between them, and to find the most suitable next action. Finally, the methodology aids analysts to obtain new requirements to adapt the BI system to the new enterprise context resulting from the sense-and-respond loop.

The rest of this paper is structured as follows. Section 2 reviews related work and highlights the need for the proposed methodology. Section 3 provides an example to illustrate and motivate the research problem. Section 4 presents the proposed methodology and illustrates its applicability on the motivating example. The paper ends with concluding remarks and future work directions in Section 5.

Related Work

In this section we review related works and published papers and clarify the position of this paper within previous works.

Managing change and facilitating adaptiveness has been a continuous theme in enterprise architecture [START_REF] Yu | Enterprise architecture for the adaptive enterprise-a vision paper[END_REF]. In 1995, Stephan Haeckel proposed a sense-andrespond model of adaptive enterprise as a new management tool for achieving competitive advantage in dynamic business environment [START_REF] Stephen | Adaptive enterprise design: the sense-and-respond model[END_REF]. An adaptive enterprise has the ability to sense environmental signals sufficiently and to translate them quickly into meaning and subsequent actions [START_REF] Stephan | Adaptive enterprise: Creating and leading sense-and-respond organizations[END_REF]. Haeckel described the transformation from make-and-sell enterprise, characterized by high-volume/low cost mass production, to sense-and-respond enterprise which is modular, fluid, and effectively responds to dynamic and non-linear changes. He emphasized to design adaptive enterprise based on sense, interpret, decide, and act loops [START_REF] Stephen | Adaptive enterprise design: the sense-and-respond model[END_REF][START_REF] Stephan | Adaptive enterprise: Creating and leading sense-and-respond organizations[END_REF][START_REF] Stephan | Peripheral vision: Sensing and acting on weak signals: Making meaning out of apparent noise: The need for a new managerial framework[END_REF]. Inspired by Haeckel's works, Buckley et al. [START_REF] Buckley | Sense and respond business performance management[END_REF] and Kapoor et al. [START_REF] Kapoor | A technical framework for sense-and-respond business management[END_REF] proposed a technical framework for sense and respond business and performance management. Their framework utilizes and integrates optimization and analytics models to enable proactive management and control of business resources. They implemented prototypes and showed applicability of the proposed framework for adaptive inventory management and demand/supply conditioning in two pilot projects in IBM divisions. This line of research was continued by Chowdhary et al. [START_REF] Chowdhary | Model driven development for business performance management[END_REF], where they applied model-driven techniques to IBM Business Performance Management (BPM) solution and illustrated their framework in a scenario of a pilot project. Also, Kapoor et al. [START_REF] Kapoor | Sense-and-respond supply chain using model-driven techniques[END_REF] proposed a model-driven development framework for a sense-and-respond supply chain.

Nguyen et al. [START_REF] Tho Manh Nguyen | Sense & response service architecture (saresa): an approach towards a real-time business intelligence solution and its use for a fraud detection application[END_REF] proposed a real time service-oriented BI architecture (called SARESA) that covers sense and respond loop and thereby aims to decrease the reaction time. They implemented and illustrated their approach in a mobile phone fraud detection application which analyzes the phone calls and issues relevant alarms in fraud cases. Panian [START_REF] Panian | Just-in-time business intelligence and real-time decisioning[END_REF] discussed the notion of real-time decisioning as an analytic approach that allows enterprise to automate the "next best action" based on performance goals. He proposed six general steps which needs to be accomplished in order to make real-time decisioning work. In another work, Panian [START_REF] Panian | Actionable business intelligence: how to make it available through service-oriented architectures[END_REF] discussed the characteristics and benefits of Service-oriented Architecture (SOA) and suggested to use BI solutions as Web services in an SOA environment.

Although these works contribute to the field and aim to increase enterprise adaptiveness, the proposed solutions are either in the form of technical architectures for specific settings or in terms of a set of general managerial principles and guidelines. Indeed, there is a lack of enterprise models that allow for analysis of adaptiveness as well as a systematic step-by-step way of closing the sense-andrespond loop in business contexts. Yu et al. [START_REF] Yu | Enterprise architecture for the adaptive enterprise-a vision paper[END_REF] discussed various research challenges and directions about adaptive enterprise architecture. They mention the lack of a framework that includes collection of modeling constructs from various frameworks (e.g., goal modeling [START_REF] Chung | Non-functional requirements in software engineering[END_REF], social modeling [START_REF] Yu | Social modeling for requirements engineering[END_REF], system dynamics, and BIM framework) in order to model and analyze the change and adaptiveness of the enterprise.

Recent efforts have attempted to introduce business-level modeling to provide a higher level abstraction for BI. The BIM framework [START_REF] Barone | Enterprise modeling for business intelligence[END_REF] conceptualizes the business operations, strategies, situations and performance indicators in a way that can assist exploiting the huge amounts of data collected by enterprise. An empirical evaluation of the BIM in a Toronto hospital reported that BIM models enhance communication between technical and business stakeholders and support implementation in BI projects [START_REF] Barone | Business intelligence modeling in action: A hospital case study[END_REF]. Horkoff et al. [START_REF] Horkoff | Strategic business modeling: representation and reasoning[END_REF] proposed a detailed and precise definition of BIM concepts and a methodology for development of these models. It reviewed and extended BIM reasoning techniques with composite and incomplete indicators, summarized information requirements and connected them to the proposed methodology. Horkoff et al. [START_REF] Horkoff | Making data meaningful: The business intelligence model and its formal semantics in description logics[END_REF] used OWL Description Logic (DL) to provide a formal semantics for BIM language. The semantics serves as a connection to DL reasoners in order to assist various "what-if?" analyzes, to detect inconsistencies, and to automatically classify defined concepts relative to existing concepts.

While the BIM modeling framework assists enterprises to utilize their data and provides them a better understanding of business, its connection to the action side has not been elaborated. In other words, BIM framework can help business users to sense and partially interpret how well they are doing with regarding to strategic goals, but it does not address the decide-and-act side of the sense-and-respond loop. We believe that business analysts need a more complete modeling framework which can assist them to achieve enterprise adaptiveness by closing the sense-and-respond loop thus making BI and analytics more actionable. The main contribution of this paper is to fill this gap by adopting and synthesizing the BIM framework with other frameworks in order to bridge the gap between BI-driven insights and consequent enterprise actions.

Motivating Example

In this section we consider a hypothetical example of a North American company, TVStars Inc., in the market of electronics, whose main products are TV and Home Theatre. The company has the vision of becoming a prestigious market leader recognized for its high performance products. The CEO and other senior managers of the company understand that the current business market in which they are operating is highly competitive, dynamic, and rapidly changing. To survive and thrive in this environment, they believe the company must be able to sense and adapt to changing market needs, to predict and cope with emerging threats, and still be able to monitor and satisfy stakeholder needs.

To monitor business performance and to enable managers to make datadriven and fact-based decisions, the company has recently deployed a BI solution. In this system, the performance of the business is made visible to responsible managerial positions and analysts by using monitoring dashboards and graphical display functions in the user interface. Using the BI system, the company has found a downward trend in the number of new and loyal customers. Moreover, the analytics show that the manufacturing costs of the company are above the planned targets. Having these insights, the managers and other BI users aim to improve the business performance. In this condition, they have faced a critical challenge which is lack of understanding how to use the output of BI system to improve business performance. They find it challenging to derive suitable corrective actions from the insights provided by the BI system. They want to know: What are the possible business actions (enterprise responses) to deal with the current bad performance in the indicators? Is it a good idea to target a new market in Europe and to sell our products there? Should the company change the product packaging policies from outsourcing to insourcing and hence reduce the manufacturing costs? Which of these is the most suitable business actions in this situation? After following/implementing it, how can we monitor the improvements? What are the new requirements for the current BI system? How changes and enhancements to the BI system should be included as part of the response action? The main contribution of this paper is to propose a modeling framework that assist such organizations to facilitate coping with these challenges.

Proposed Method

In this section, we present the proposed methodology and show its application on the hypothetical example described in Section 3. Figure 1 shows an overview of the methodology and the inputs and outputs of the steps.

Step 1: Design the sensing based on the BIM model. In this phase, the first activity is to construct a business schema to support modeling and analysis of the enterprise and its performance. For this purpose, we use the BIM framework because it assists business users to utilize and make sense of huge amounts of data about the enterprise and its external environment. This framework provides business analysts with a modeling and query language to reason about business objectives, strategies, situations, tasks and performance indicators and hence to realize how well they are doing with respect to strategic goals and objectives. BIM draws upon well-known business concepts which makes it business-friendly and understandable for users. A methodology for constructing BIM models has been proposed in [START_REF] Horkoff | Strategic business modeling: representation and reasoning[END_REF].

A BIM schema provides a picture of the goals structure of the enterprise along with the corresponding indicators and shows how well they are met. The BIM modeling concepts are adopted and synthesized from business and management literature and also requirements engineering sources, e.g. Balanced Scorecard and Strategy Maps [START_REF] Robert S Kaplan | The balanced scorecard: translating strategy into action[END_REF][START_REF] Robert S Kaplan | Strategy maps: Converting intangible assets into tangible outcomes[END_REF], SWOT analysis (strengths, weaknesses, opportunities, and threats) [START_REF] Richard | Dynamic SWOT Analysis: Developer's Guide[END_REF], and goal-oriented requirements engineering [START_REF] Yu | Towards modelling and reasoning support for early-phase requirements engineering[END_REF][START_REF] Dardenne | Goal-directed requirements acquisition[END_REF]. Reference [START_REF] Jiang | The business intelligence model: Strategic modelling[END_REF] presents a full list of the concepts, definitions and examples of BIM.

Figure 2 shows part of the BIM schema of TVStars Inc. company, where the goal, influences and relationships, indicators (red on top, yellow on middle, green on bottom), and situations are modelled. The top level goal of the company is shareholder value increased. To achieve this goal, the company looks to meet the goals to reduce costs and to increase revenue. Moreover, to control the performance, the company have defined indicator(s) for each goal, e.g., number of loyal customers and number of new customers for the goal to attract and retain best customers. It shows how the organizational goals are refined into alternative actions that are means toward achieving those goals, e.g., a possible way to attract and retain best customers is to offer promotions for loyal customers. In addition, this model shows the external situations that are affecting the company's goals, e.g., ineffective distribution channel of the company, negatively affects the goal to increase product sales.

After constructing the BIM model, the next activity in the proposed methodology is to analyze the indicators and select those for which the current perfor-mance is not excellent (red and yellow zones). This activity results in a set of indicators for which improvements and corrective actions (i.e., enterprise response) are needed. Analyzing the indicators in the BIM model is part of the sensing step of adaptive enterprise loop and assists business people to understand how well they are doing with regarding to their strategic goals and what/where are the possible areas of improvements.

At the current time, using the BIM model in Figure 2, the TVStars Inc. senses that it has an average performance (yellow zone) in meeting its top goal. Moreover, the company realizes that the current performance with regarding to the goals to increase revenue and to attract and retain best customers are deficient, since the corresponding indicators are red. Also, the business analysts find that the total costs indicator is below the threshold and hence the corresponding indicator is in green zone, i.e., satisfactory level of costs. Having this model, and considering the competitive dynamic business market, the TVStars Inc. decides to undergo changes and take new course of actions in order to adapt and improve performance in the red/yellow indicators, e.g., number of product sold, number of new customers, and total revenue.

The main output of this phase, is an AS-IS BIM model of the enterprise along with a set of selected indicators for which the users want to improve the performance.

Step 2: Develop alternative responses. In this step, a set of alternative business actions are developed to deal with the poor performance in the indicators from previous step. These actions are potential future responses of the enterprise to what it has sensed. They could be in various business layers, involve different actors, and require different time, resources, and skills to be completed. The analyst adds these alternatives as new goals to the AS-IS BIM model from previous step.

After adding new alternatives, the next activity is to examine how each alternative is going to influence the other strategic goals of the enterprise. In particular, in order to model and consider the side-effects of the each alternative response, the analyst should examine how each alternative will impact the goals for which the current performance is excellent (green zone indicators). New influence links should be added to the BIM model to represents the possible effects of each alternative to other goals. These links facilitate the trade-off and decision making process among alternatives. At this step, the analysts can use the existing reasoning techniques on the BIM models to examine and answer a variety of strategic and analysis questions about effects of alternatives on the top goals of the enterprise. They can perform reasoning on the hierarchy of goals in order to evaluate different strategies for the satisfaction of top goals (forward reasoning), to evaluate the optimal input values leading to achievement of desired top goals (backward reasoning), as well as to perform analysis on goals inconsistencies and conflicts. Methods and techniques for reasoning with BIM models have been presented in [START_REF] Barone | Towards model-based support for managing organizational transformation[END_REF][START_REF] Horkoff | Strategic business modeling: representation and reasoning[END_REF][START_REF] Barone | Enterprise modeling for business intelligence[END_REF][START_REF] Barone | Business intelligence modeling in action: A hospital case study[END_REF].

Figure 3 shows part of the new BIM schema for TVStars Inc. company. To generate this model, the BI analysts and the board of directors of the company Fig. 3. BIM schema including the alternatives and their influence links examine and investigate the red and yellow zone indicators from previous step and after few meetings and discussions, they generate two alternative solutions that they believe could improve the indicators. Their first option is to penetrate to a new market in Europe. They believe that in this way they can increase number of new and loyal customers and hence increase the total revenue. Their second option is to change from outsourcing the package production to insource strategy, in which the company will design and produce the packages on its own. The analysts believe by insourcing the packaging of products, they will reduce the total costs of the company. Figure 3 also includes the new influence links of the alternative, showing that how these alternative will affect other strategic goals, e.g. penetrating to Europe market negatively affects the goal to reduce distribution costs.

The main output of this step is a BIM model which includes the alternatives along with their influence links to strategic goals.

Step 3: Select the most suitable alternative(s). In this step, the decision among alternative responses of the enterprise is made and the best action(s) is chosen to be implemented. To facilitate the organizational decision making process, i * modeling framework is used to analyze each of the alternative responses. i * models assist the analyst to provide a detailed picture of how the corresponding organizational setting would look like when the given alternative is chosen and implemented. In other words, these models are snapshots of the enterprise once the response action is adopted and help the enterprise users to know how the alternative will change the settings, e.g., new actors in the system, new dependencies and the potential TO-BE socio-technical context.

i * models show the goal structure of social actors involved in the system and depict how the actors depend on each other to achieve their goals. Reference [START_REF] Yu | Practical applications of i* in industry: The state of the art (mini-tutorial)[END_REF] reviews the recent applications of this modeling framework in practical industrial and business settings. Figure 4 shows the i * model constructed for the first response alternative for TVStars. Using this model, the decision makers realize that if they decide to sell the products in Europe, a new actor Europe distributor would be part of the system. The Marketing department depends on this distributor to have a great exposure in the market which helps to achieve the softgoal availability of products and hence sale growth. The model shows them that the distributor depends on the marketing department to provide high margins, so he can achieve his internal softgoal high sharevalues. Also, the marketing department has a resource dependency to the Europe distributor to provide market data and feedbacks from European customers. Moreover, the analysts find that the Europe distributor will depend on the logistics department of the company to provide the products. In addition to external dependencies, the i * model shows them internal goals of each actor and indicates decompositions and various ways of achieving those goals.

Figure 5 shows the i * model constructed for the second alternative. It indicates that if the company follows the second alternative, the insource packaging task would be done as an internal task within the authority of Manufacturing manager. Also, it shows different productions strategies and their influences on the softgoals of manufacturing department.

After developing these models, the next activity of the proposed methodology is to decide about the new indicators that the enterprise needs to measure after implementing each alternative. This will assist enterprises to monitor, after implementation of an alternative, how well it is working and allows them to adapt again if the performance is not satisfactory. These indicators are added to the i * models since these models are already showing the details of each alternative and can facilitate deciding about new indicators. The "measures" and "evaluates" links from the BIM meta model are used to connect the new indicators to the goals, tasks or the dependency links in the i * model. Now, by having the new indicators in the i * model, the analysts can examine if an indicator is accessible/computable or not. To facilitate that, the analyst connects each of the new indicators to the related existing data sources (as resources in the i * model). The connection between indicators and data sources elements are made using mapping elements from the Conceptual Integration Modeling (CIM) framework [START_REF] Rizzolo | The conceptual integration modeling framework: Abstracting from the multidimensional model[END_REF]. Another way of making this connection is to use the traceability links (e.g., satisfiability) proposed in [START_REF] Maté | A trace metamodel proposal based on the model driven architecture framework for the traceability of user requirements in data warehouses[END_REF][START_REF] Maté | Incorporating traceability in conceptual models for data warehouses by using mda[END_REF] to connect each new indicator to the data warehouse schema of the enterprise. The accessibility/computability of indicators are used as a decision criteria while trying to find the most suitable alternative. If an analyst finds that there is not available data for measuring an indicator, this could result in removing the corresponding alternative from possible choices.

The last activity in this step is to select the most suitable alternative. As a set of criteria for this decision making, analysts and business actors consider the influence links that were developed in the second step of the methodology, the i * models, and finally the feasibility of measuring the corresponding indicator(s) for each alternative.

Following the scenario of TVStars Inc. company, the analysts add two new indicators to the model in Figure 4, number of customers in Europe and shipping costs to Europe believing that these indicators are necessary for measuring the performance of this alternative. The analyst finds that the first alternative could be calculated from the European distributor's database and the second one could be computed from the company's warehouse database which is already operating in the logistics department. Hence, he marks these indicators as satisfied in the model. Regarding the second alternative, the analysts realize that at the current stage, the databases of the company does not provide the required data for computing the indicator number of defective packages. Hence, he marks this indicator as denied (See Figure 5). Having this analysis and also by considering the estimated influences of the alternatives on the other strategic goals (See Figure 3), the analysts conclude that first alternative is more suitable for the current situation of TVStars Inc. company. Hence, they decide to follow the first alternative as the next most suitable action (i.e., the response to what they had sensed).

The main output of this step is the chosen alternative, its corresponding i * model including new indicators, and connections to the data warehouse schema.

Step 4: Implement and monitor the response. The last step of the methodology includes the implementation of the chosen alternative, which is the enterprise's response to what it had sensed in the first step. The i * models developed in previous step could be used to assist in the implementation. Besides, the enterprise can use the change management guidelines and principles existing in the literature. This step of the methodology also includes modifying the BI system to the new settings (i.e., chosen alternative) so the enterprise keeps track of how well it is doing with regard to its response(s). The analysts construct the TO-BE BIM model which includes the selected alternative from previous step and its associated indicators. This BIM model includes the new requirements for the BI system of the enterprise.

In the last step, the TVStars Inc. company penetrates to the Europe market and starts selling the products there. The company also modifies the BI system to include the new requirements, i.e., measuring the indicators related to the first alternative. After implementing the alternative and updating the BI system, the TVStars Inc. company has completed an iteration of the sense-and-respond loop.

To summarize, this methodology adopts and synthesizes a set of modeling frameworks to provide a systematic way of closing the sense-and-response loops of an adaptive enterprise. The methodology includes conceptualizing and modeling the strategic goals and objectives of the enterprise and thereby sensing how well the current performance is w.r.t. each of them. This is covered in the first step of the methodology (see Figure 2). The proposed methodology models various response alternatives to a given output of BIM model, as well as their associated indicators (see Figure 3). Our methodology includes modeling the social interaction and dependencies between various actors in an adaptive enterprise context. It aids business users to make trade-off between these alternatives, and finally to decide about the most suitable one (see Figures 4 and5). Besides, it serves as a way to model the new requirements and adapt the BI system in a changing dynamic environment (see the last step of the methodology). By connecting the sensed signals of the enterprise to subsequent responses, we believe the proposed methodology can make BI and analytics more actionable and understandable for business users.

Summary and Future Research

BI platforms and data analytics techniques are widespread in businesses, where they assist users to sense and interpret the performance of the enterprise as well as its environment and facilitate decision making. In this context, there exist a gap between the insights resulting from these systems and the action(s) that the enterprise take to respond to the conditions. This paper proposed a methodology to fill this gap and to facilitate enterprise adaptiveness. The methodology synthesizes several existing modeling frameworks to provide a step-by-step coherent way of closing the loop between sense and response in an adaptive enterprise. Applicability of this methodology is illustrated in a hypothetical business setting.

The recent industry trend in "embedded BI" demonstrates increasing recognition of the benefits of adopting a closed-loop sense-and-respond paradigm. However, current solutions are typically limited to a single software application and aim at business process optimization and do not offer strategic enterprise modeling. The current proposal incorporates high level business modeling to support reasoning about alternative actions. The response actions include new sensing mechanisms (BI requirements) in the ongoing evolution of the sense-andrespond loops. The approach is not limited to a single application or business process, but it is intended to be enterprise-wide in scope, to be applied at all levels of business responsibility and performance management.

This research is part of a broader research agenda whose goal is to develop an adaptive enterprise architecture framework. This framework would include modeling, analysis and design tools and techniques to address adaptive enterprise requirements. Future research include implementing and evaluating the proposed methodology in a real case study. Further investigations on the understandability and communicability of the modeling concepts in proposed methodology should be made in future studies. Also, it should be examined how the proposed methodology increases the speed of reaction in the enterprise. In this paper, we showed the application of the methodology for closing closing a sense-andrespond loop at one particular level of iterative design cycles. In a complex organization, design and execution occur at many levels of time scales and scopes, as illustrated in [START_REF] Yu | Adapting to uncertain and evolving enterprise requirements[END_REF]. Future works can address this. Moreover, we anticipate that there would be model libraries for various industries that could be reused as best practices for other market players. In future, the proposed methodology could be extended to include industry specific model libraries and hence to leverage the domain knowledge and existing experiences. Besides the BIM framework could be extended to include additional business level concepts, e.g., concepts from the Business Model Canvas [START_REF] Osterwalder | Business model generation: a handbook for visionaries, game changers, and challengers[END_REF], and hence to increase its expressiveness for modeling sense-and-respond loops of the enterprise. Finally, we are planning to extend the proposed methodology with a comprehensive catalog of applications of data mining and analytics techniques in business context. We aim to provide model-based support for assisting users to select the proper data mining and analytics techniques based on their business requirements. This catalog along with the modeling support will address the need of business users community for understandable ways of using data mining in an adaptive enterprise context. We leave these extensions to future work.

Fig. 1 .

 1 Fig. 1. Overview of the proposed methodology.

Fig. 2 .

 2 Fig. 2. Part of the TVStars BIM schema.

Fig. 4 .

 4 Fig. 4. i * model representing the first alternative.

Fig. 5 .

 5 Fig. 5. i * model representing the second alternative (See Figure 4 for legend).


Baiba Apine
email: baiba.apine@lv.pwc.com

A New Contract between Business and Business Analysts

Keywords: Business process, business process modelling, optimisation

Since the advent of business processes management it has been recognized that its main objective is optimization of enterprise's performance. However, the focus of business analysis has changed significantly over the years. Initially business analysts focused on discovery and modelling of business processes. They aimed to identify opportunities for application of information technologies in business process automation and to determine resources needed for business process execution. More recently, the attention has shifted towards business process monitoring and optimization, while the current trends concern with business process intelligence for agile decisionmaking. Businesses expect that the business analysts will identify opportunities for continuous business process improvement by providing contextualized, high quality and secure information. In the light of these new business expectations, the keynote speech identifies today's challenges faced by the business analysts and describes the current practice in dealing with these challenges.

Introduction

Business process modelling is a very interesting discipline. It does not provide business value per se, however it serves as a backbone for many complex projects and it is a critical factor for completing these projects successfully. Business process reengineering, information system implementation, reorganisation of the company etc. are samples of the projects involving business process modelling as a significant component. The demand for projects involving business process modelling has always been high and will remain so in the future as well. For instance, 64% of CEOs working for financial institutions have undergone a review and redesign of their organization in the last 12 months [START_REF]How Financial Services companies can execute the right people strategy[END_REF].

This article summarizes the ten years business modelling experience in Latvia, highlights the major challenges and discusses the latest tendencies faced by the business analysts.

The major challenges faced during the modelling of the business processes are: 1) keeping the model as simple as possible for it to serve as a communication tool among business analyst, technology provider and business; 2) finding balance between excellence of the model and cost effectiveness of the modelling process; and 3) dealing with issues of completeness and quality of the model.

While the challenges remain the same, the expectations from business analysts have changed significantly over the years. A decade ago business analysts mostly focused on discovery and modelling of processes aiming to identify opportunities for application of information technologies for process automation and to determine resources needed for business process execution. More recently, the attention has shifted towards business process optimization and business process intelligence for agile decision-making. Businesses expect that the business analysts will identify opportunities for continuous business process improvement by providing contextualized, high quality and secure information as well as have ready-made world class best practices of organizational structures and process templates.

Empirical Data

The conclusions made in this paper are based on consulting practice at the PricewatehouseCoopers Ltd, Latvia. The company has been involved in the modelling of the business processes for different purposes. The team of 3 -4 business analysts has been constantly working in different projects involving the description of the business processes for 10 years (2004 -2013). Totally 90 projects for more than 70 different companies/public sector institutions have been analysed to come up with the conclusions summarized in this article. The split per industries is given in Figure 1. Modified BPMN notation [START_REF]Object Management Group, Business Process Model and Notation[END_REF] was used for the description of the processes. The average length of the projects was 4 -7 months. All projects were done for companies/public institutions operating in Latvia. Approximately 70% of the projects involved the description of the 'as-is' processes and 'to-be' processes, while 30% involved the description of the 'to-be' processes only. For the purposes of the analysis the projects were classified in three groups by the objectives of the business process modelling (see Figure 2).

Fig. 2. Purposes of the business process modelling (number of projects)

Business process descriptions for business requirements definition for IS implementation are used (1) to define the requirements for IS implementation; (2) as a source of information about business process for system provider; and (3) to evaluate system providers' proposals for IS implementation; (4) building testing scenarios for IS testing.

Business process description for process optimisation serves (1) for communication of the existing processes among all parties involved in the optimisation and ( 2) as a source of information for optimisation opportunities for business analysts. Usually these process descriptions include also quantitative information about number of transactions, goods produced, etc.

The business process description for the optimisation of control environment involves

(1) identification of control weaknesses against standard/directive/framework and (2) strengthening the control environment. However, it is important to keep the business process as effective as possible.

The demand on the business process modelling remains stable since 2004 (~9 projects annually) with fall in 2008 to 4 engagements due to financial crisis in Latvia (see Figure 3). Business process modelling for information system requirements definition is the most frequent purpose of such projects.

Fig. 3. Number of business process modelling projects per year for information system requirements definition

Number of projects involving business process modelling for improvement of control environment is constantly decreasing (from 9 in 2006 to 3 in 2012). The main reason is the cost/benefit from such projects -the cost of building the model is too high to ensure the compliance with regulations only.

Number of projects involving business process description for business process optimisation purposes stays constant as well. However, the number increased during the financial crisis in Latvia (2008 -2010), when companies were looking for inefficiencies and cost cutting opportunities (see Figure 4).

Fig. 4. Number of business process modelling projects per year for optimisation of the business processes 3 Challenges

Regardless the overall objective of the projects, the business process modelling is significant part of the whole project. It is one of the most time and resource consuming activities. It is the most complex one and challenging as well. At the same time, the result of the modelling is critical to the success of the project. The team involved in the business process modelling has matured, modelling tools used have changed over the last ten years, however, the challenges faced during the modelling have remained the same.

Regardless the purpose of the business process description, it has to serve as a communication tool among business analyst, business people and sometimes system providers. Hence, the descriptions should be understandable and kept as simple as possible. It is very easy to produce large business models attempting to describe almost all processes in the company. This is the most common mistake for inexperienced business analysts' teams paying much attention to the detail and sometimes losing the 'big picture'. Large business models, especially describing existing processes, are very comfortable for business people involved in the processes as they can argue, that processes are too complex to be changed. At the same time it is practically impossible to ensure consistency and understandability of the process descriptions. The descriptions lose their role of the communication tool and the success of the whole project can be at risk.

The following actions are found to be helpful to produce business process description serving as a communication tool: 1. Structured approach to the description of the processes is essential, limited amount of time, discussions devoted to the single process description. Limited time frame and structured approach are identified as significant influencing factors in the creation of understandable business process model in the theoretical research [START_REF] Claes | Tying Process Model Quality to the Modeling Process: The Impact of Structuring, Movement, and Speed[END_REF]. 2. Very clear criteria should be kept in mind to select the business processes to be described to avoid the description of the 100% of cases. The most frequently practically used criteria might be different for different projects. For the purposes of process optimisation the criteria should be: (1) the most resource, time consuming processes, (2) the highest number of quality issues requiring resources for rework etc. For the IS implementation purposes the criteria should be: (1) the business processes, where the automation and new technologies will bring the most value for the business; (2) the most intensive 6 -7 information flows out of 10 etc. The actions mentioned above should be planned and monitored continuously by the manager of the business analysts' team or senior business analyst. The drawbacks from limiting business process modelling scope, schedule and discussions around the model are (1) the risk of building incomplete model; (2) limited use of automated tools for business process analysis, for instance, described in [START_REF] Accorsi | Automatic Information Flow Analysis of Business Process Models[END_REF] and [START_REF] Ramezani | Where Did I Misbehave? Diagnostic Information in Compliance Checking[END_REF].

Business process modelling as a part of the project doesn't add any value for the business directly, i.e. the result is not implemented change, an automated information flow or any other tangible result. However, business process modelling is time and resource consuming phenomena. Business analysts often face pressure from the businesses to skip the description of the 'as-is' processes and concentrate on the 'tobe' processes only to cut costs for the analysis and produce the tangible results faster. In addition, the description of the 'as-is' processes is more time consuming and complex as the knowledge stays with the business people primary and not with the business analysts (for 'to-be' processes the situation is vice versa). In our practice, the projects skipping the 'as-is' processes description do not bring the results faster. The time and analysts' resources saved are used later by the analysts' team or business management to argue the feasibility of the changes proposed, e.g., to discuss 'it cannot be done like this' arguments from the people involved in the existing processes. Hence, the task of the manager of the business analysts' team is to insist on the description of the existing business processes at the beginning always.

The third challenge is to find the right business analysts' team for the particular project. The team is essential, because the ability to identify the right level of detail of the process description, obtaining the right information from business people involved in the process depends on the soft skills of the team and every individual analyst. The team must know the notation used, the tool and the principles of the modelling. However, the successful team should have business (industry) specific knowledge, information management techniques, pros and cons of technologies for accessing information (mobile technologies, clouds etc.). The requirements from the business towards the business analysts have changed significantly over the years.

Changing Paradigm

Regardless the primary objective of the project involving process modelling, companies are always looking at the optimisation opportunities to improve the overall company's performance. The most of the companies from our practice have done business process modelling more than once during the 10 years period, they are optimising business processes continuously as well. The optimisation opportunities originating from business processes have decreased, because (1) business people are more connected with other professionals, the knowledge about industry specific issues/solutions is more accessible; (2) off-shelf operational templates are available together with proven implementation approaches, [START_REF] Buchmann | From Calls to Events: Architecting Future BPM Systems[END_REF]; (3) the best industry practices are built into ERP systems; (4) more and more tools are produced and available on the Internet providing search engines in unstructured data, hence, the businesses can skip sophisticated changes in their processes producing structured data for decision making.

The process optimisation has become one minor part of the improvement of the overall company's performance. According to my experience, the components of overall company's performance improvement are given in the Figure 5. The five components are closely interrelated and should be considered together. For example, to redefine business processes and technologies, an organization should consider which talent requirements are necessary to implement new processes or systems.

Fig. 5. Sources of company's performance optimisation

Business capabilities refer to company's core capabilities like relationship management, product design, data analytics required to execute the business. Noncore capabilities can be sourced from external service providers in line with strategic business requirements. Decision rights refer to the codification of business decisions and the accountable decision-making groups/individuals. The organization model includes two elements (1) service delivery that determines choices of location, the organization of the service delivery and (2) the functional groupings, reporting structure, target headcount, and functional responsibilities for each function. Talent strategy includes effective management of the overall talent lifecycle, such as workforce planning, recruitment, on-boarding, development, and performance management.

At the same time business process modelling serves as a backbone, where all the weak performance issues come up and the team of business analysts should be able to propose the most convenient and effective options to the business regardless the area of performance optimisation. This new role requires the wide range of new knowledge for business analysts. Now the good business analyst should be able to ensure the process, where information lands in the hands of the decision maker at the point of the decision. Hence, the methodological knowledge about business process management is not enough. He/she should understand (1) the opportunities provided by mobile technologies, cloud computing for timely information delivery; (2) best practices of the organisation structures and business processes for accounting, IT management, sales etc.; (3) best practices of keeping balance between in-house and outsource functions; (4) best practices of building effective control environment; (5) frameworks of obtaining information for decision making from social networks or other unstructured sources, for instance described in the [START_REF] Scekik | Modeling Rewards and Incentive Mechanisms for Social BPM[END_REF], [9] etc. The new business analyst should be able to put the practices mentioned above in the context of the business and convince the business representatives about the benefits.

The demand from the business for business process modelling has been high and stable for years. It will remain so in the future as well, because the business is changing continuously due to availability of new technologies.

The key challenges in the business process modelling are (1) keeping the model understandable and complete; (2) finding the right business analysts' team suiting the best the objectives of the modelling. The solutions for the abovementioned challenges lay primarily in the management of the projects, ensuring continuous dialog with the business rather than in using advanced modelling tools and techniques.

The objectives and nature of the modelling process has changed significantly over the last ten years. Initially business analysts were expected to identify the company's performance optimisation opportunities by use of information technologies. Now the business analysts are expected to advise on the benefits of the wide range of information technologies as well as on the best practices of organisation structures, business capabilities, talent management etc. All these areas should be put in the context of the company's business to produce the process, where information lands in the hands of the decision maker at the point of the decision.

Fig. 1 .

 1 Fig. 1. Business process modelling split per industries (number of projects)