# Value-Chain Discovery from Business Process Models

Anis Boubaker, Dhouha Cherif, Abderrahmane Leshob, Hafedh Mili

► To cite this version:

Anis Boubaker, Dhouha Cherif, Abderrahmane Leshob, Hafedh Mili. Value-Chain Discovery from Business Process Models. 7th IFIP Working Conference on The Practice of Enterprise Modeling (PoEM), Nov 2014, Manchester, United Kingdom. pp.26-41, 10.1007/978-3-662-45501-2_3. hal-01281987

HAL Id: hal-01281987

https://inria.hal.science/hal-01281987

Submitted on 3 Mar 2016

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Value-Chain Discovery from Business Process Models

Anis Boubaker, Dhouha Cherif, Abderrahmane Leshob and Hafedh Mili

University of Quebec at Montreal - LATECE Laboratory

**Abstract.** Companies model their business processes either for documentation, analysis, re-engineering or automation purposes; usually using normalized *business process modeling* languages such as EPC or BPMN. Although these models explain *how* the processes should be performed and by *whom*, they abstract away their business rationale (i.e. *what* is offered and *why*). *Business modeling* aims to answer the latter and different frameworks have been proposed to express the process in terms of value-chains. Ensuring alignment between both of these views manually is error prone and labor intensive. In this paper, we present a novel approach to derive a value-chain - expressed in REA - from a business process model expressed in BPMN. At the heart of our approach and our main contribution lies a set of nine general business patterns we have defined and classified as structural and behavioral patterns.

## 1 Introduction

The ubiquity of business processes (BPs) in nowadays corporations raises them as first class citizens by being considered corporate assets and their need for ongoing management has been recognized. BPs are captured by business process models (BPMs) to depict the set of actions that should be carried out by a given BP, in what order they should be performed and by whom. Languages such as EPC[21] or BPMN[17] define both a set of concepts and a graphical representation convention to model business processes. Therefore the focus of a BPM is on the operational and dynamic aspects of the process (i.e. *How* are we doing it? and *Who* is doing it?). However, the business intent - expressing the *why*'s of the activities we perform - is not explicitly modeled and that is where *business modeling* comes in handy.

A business model (BM) is a conceptualization of the BP using pure business terms such as economic resources, economic agents and value adding activities and their relationships. It may take the form of a resource centric view of the process - called a *value-chain* - that exhibits the sequence of economic resource acquisitions and transformations. A value-chain let us answer questions such as (1) how is the company using up its economic resources? and (2) why are these resources consumed or relinquished? There are three main frameworks widely recognized in the literature, namely REA[14], e³value[9] and BMO[18].

Authors have argued on the necessity of not overlooking the business rationale in BPM projects (e.g. [20,10]). Indeed, business process management is
an ongoing iterative process[23] and we should ensure that the evolving business processes do not deviate from higher level business objectives. Ensuring the alignment between BMs and BPMs can be achieved in one of three ways: (1) manually, (2) by reducing both views to a common view and comparing them (e.g. see [19]), or (3) by deriving one view from the other. The latter has only been considered going from a BM to generate a BPM ([8,25,1]). The other way around had yet to be explored and this work intends to fill this gap.

Apart from business process re-engineering, business models are useful during the analysis phases of various IT projects. For example, in architectural design, the TOGAF® framework recommends the use of value-chain diagrams in its Phase A (Architecture Vision) to "quickly on-board and align stakeholders for a particular change initiative, so that all participants understand the high-level functional and organizational context of the architecture engagement"[22, pp.382]. Furthermore, in the business activity monitoring field (BAM) or business process mining, knowledge about the business rationale can be used for real-time detection or a *posteriori* diagnosis of deviances from the business strategic goals (e.g. [13]). Business models can also help in automatic BP generation approaches. In particular, our team used a value centric view of the BP in two research projects. In the first project, we used value models to perform a question based BP specialization[16]. In the second project, we focused on the automatic generation of compensation processes of a BP (i.e. reversing the effects of a running process that needs to be aborted) [4,5]. We argued that compensation is a business problem - rather than technical - and therefore must be tackled from a business standpoint[15]. Hence, we used the value-chain of the BP as an input in order to infer compensation processes.

In this work, we propose a four-steps approach that aims to generate a value-chain expressed in REA[14] from a BPM expressed in BPMN. The problem is not trivial considering the large conceptual distance between both views[10]. Hence our purpose is to infer business intensions that are not explicit in the original BPM. We tackle this by relying on a set of structural and behavioral patterns we have identified through the analysis of a sample of BP models.

The remainder of this paper is organized as follows. In Section 2, we briefly present business modeling and the REA ontology. In Section 3 we review some existing related works then we give a high-level overview of our approach in Section 4. Sections 5 and 6 focus on the inference of REA concepts and REA economic processes based on five structural and three behavioral patterns we will introduce. The validation of our approach will be presented and discussed in Section 7, before concluding in Section 8.

## 2 Business Modeling - The REA ontology

A business model is an abstraction of the BP focusing on the business rationale, specifically on how the company intends to create added value through it's *value-chain*. Different ontologies have been proposed to perform value-chain modeling ([18,9,14]). In this paper, we chose arbitrarily the Resource-Event-Agent (REA) that was introduced by McCarthy in an early work and has been getting wider attention recently from the community [14]. However, our approach could be
applied to any of the above mentioned ontologies as the concepts used in our approach are shared among them [2].

<figure><img src="image_2.png" /><figcaption>Fig. 1. REA metamodel</figcaption></figure>

McCarthy proposed the REA framework as a way of capturing the economic phenomena that needed to be accounted, from an *accounting* perspective. In REA, an enterprise can increase or decrease the value of its resources through either *exchanges* or *conversions* [11]. An *exchange* is a process in which an enterprise receives economic resources from external economic agents, and provides other resources in return. A *conversion* is a process in which an enterprise uses or consumes resources in order to produce new or modified resources.

Figure 1 shows the basic REA metamodel. *Economic resources* are objects that are scarce, have utility, and are under the control of an enterprise[14]. In an exchange, a resource is perceived as a set of *rights* (e.g.: ownership, usage, etc.) being exchanged whereas, in a conversion, it is defined by the set of *properties* (i.e. features contributing to resource's overall value) being altered. *Economic events* are defined as “a class of phenomena which reflect changes in scarce means resulting from production, exchange, consumption, and distribution”[26]. An *economic event* represents either an *increment* or a *decrement* in the value of economic resources. An *Economic Agent* is an individual or an organization capable of having control over economic resources, and transferring or receiving that control to or from other individuals or organizations [11]. The *duality relationship* links increment events to decrement events. The set of events related by a duality relationship form a so-called *REA process*<fnref n="1" />.

In the remainder of this paper, we will use an abbreviated graphical modeling notation of REA processes. Figure 2 shows the legend of our notation.

## 3 Related Works

Generally speaking, our work lies within the scope of model transformations, and more specifically, in reverse-engineering model transformations[6]. Reverse engineering is defined as "the process of analyzing a subject system to (i) identify the system's components and their interrelationships and (ii) create representations of the system in another form or at a higher level of abstraction"[7]. Indeed, our work seeks to transform an operational representation of a BP into a business view of the same BP. Although to the best of our knowledge this particular

<footnote n="1">¹ Note that the term "process" here do not necessarily mean the entire business process. In fact, a given business process may be decomposed into several REA processes.</footnote>
<figure><img src="image_3.png" /><figcaption>Fig. 2. REA abbreviated notation</figcaption></figure>

problem did not draw authors attention yet, some works were interested in BPM
and BM transformations that we can classify into two classes.

The first focused on transforming BMs into BPMs. Generally, the proposed approaches followed a common transformation schema by (1) extending the BM with business process operational aspects and (2) inferring concrete business process activities and orchestration relying on a pattern library. They varied on the choice of abstraction to extend the BM and their automation degree. Andersson et al. focused on making explicit in the BM the transfers of resource custodies and evidence documents [1]. Wieringa et al. tackled the same problem by relying on what they call *physical delivery models* [25]. Their claim is that while value models depict value streams between BP actors, the actual delivery of the value objects does not necessarily follow the same path. More recently, Fatemi et al. analyzed the interactions between the business actors to generate a BPMN model from an e³value model[8]. They proposed a taxonomy of interactions that include six classes and involve the analyst to classify the interactions and to specify who initiates each interaction. Our approach globally follows the same schema but varies (1) in the direction of the transformation (i.e. BPM into BM) and thus the information needed to extend the model, (2) in the generality of our patterns and (3) in the degree of automation and analyst involvement required.

The second class is about ensuring the alignment of BMs and BPMs. Pijpers
et al. [19] proposed a method based on a reduction of both models to a common
metamodel with two main concepts: *business units* and so-called *common value
objects*. They model the relationship between these concepts as a set of transfers
of common value objects to/from business units. Although this approach can
give an approximation of the alignment between both views (as mentioned by
the authors, false negatives could be observed), we cannot use this approach
to derive a value model from a BPM. Indeed, the reduced model disregards the
relationships between value transfers (i.e. dualities in REA) that we believe is the
core concept of a value model expressing the intents behind these transfers. Other
approaches to ensure view alignment that do not involve model transformation
(e.g. [3]) were not reviewed. In the next section, we provide a high level view of
our approach.

4 Approach Overview

Going from a dynamic view of the BP (i.e. BPMN) to infer a value centric view
conforming to the REA ontology raises three main questions: (1) how to iden-
tify REA concepts (i.e. Resources, Events, and Agents) from a BPMN process
<figure><img src="image_4.png" /><figcaption>Fig. 3. Global view of our approach</figcaption></figure>

model?, (2) how to determine and/or infer relationships between these identi-
fied concepts? and (3) once we have determined a set of *REA Processes*, how to
connect them in order to build a global value-chain of the BP? This paper will
focus on answering the first two questions.

Answering the first question involves matching between REA concepts and
BPMN constructs. This constitutes the first two steps of our approach and will
be discussed in Section 5. Once we have identified the concepts, we need to deter-
mine and infer the relationships between them to form a set of REA Economic
Processes. Some of these relations are explicit from the BPM while others, such
as dualities, need to be inferred. In Section 6 we explain how we tackle this
problem using a set of structural and behavioral patterns we have identified.

In the last step of our approach, we construct the value-chain by connecting
the obtained REA processes relying on a partial order over the set of occurrences
of each BP resource. We derive this order from the partial order over BPM
activities and the traceability links between the activities and REA economic
events. Space limitation prevents us from going into further details about this
step in this paper. We illustrate the global view of our approach in fig. 3.

In order to perform preliminary validations of our work and prove its fea-
sibility, we implemented the three last steps by defining our patterns as rules
in JBoss Drools rule engine. The rules implemented the transformations from
the BPMN2.0 metamodel<fnref n="2" /> into our REA metamodel[4] defined using the Eclipse
Modeling Framework.

Before going into the details of our approach, in the following subsections we
present the hypothesis and assumptions on which we will base our approach. We
also present a simple sale-and-delivery example of an e-retailer that we will use
as a running example to illustrate our approach.

**4.1 Modeling Assumptions and Hypothesis**

First, we assume that the BP collaboration is modeled from the perspective of
the entity under study (e.g. a company). Therefore, the BPM must include the
private process of the so-called entity whereas only public processes of collaborat-
ing partners are needed. We also assume that the provided BPMN model is valid
both syntactically and semantically. Syntactic validity refers to the conformance

<footnote n="2">² http://www.eclipse.org/bpmn2-modeler/. Last accessed: March 3rd 2014.</footnote>
to BPMN specifications[17] and observed best practices [24] while semantic validity means that the model makes general operational and business sense for the entity under study.

Under these assumptions we make two hypothesis on our approach. First our approach will discover at least 80% of the REA processes that could be discovered from the input process (H1). Hence, we want to generate REA value-chains at the lowest granularity level. As we will see in the remainder of this paper, our approach will generate REA processes that are syntactically correct by construction. However we want to ensure semantic correctness and make the hypothesis that these generated REA processes are relevant and consistent with the business process under study with a precision rate of 80% or more (H2). A given REA process is relevant if it describes an economic phenomenon involving economic resources and agents that could be observed in the business process. A relevant REA process is also consistent if it describes correctly the type of phenomenon (i.e. exchange vs conversion) and shows all the economic resources that should be involved from what could be gathered from the BP.

## 4.2 ABCInc Sale-and-Delivery Example

We will use through this paper a simplified sale-and-delivery BP used by an e-retailer (ABCInc) that we have depicted in fig. 4 in BPMN notation. The process starts when a *Customer* gets online and orders books. Then ABCInc starts preparing the order by enclosing the products in a box and sticking a label with the shipping address. At the same time, ABCInc's *Bank* debits customer's credit account and ABCInc's account is credited the transaction amount.

Once both of these parallel operations are performed, the products are shipped to the customer by a *Shipping company* who provides ABCInc with a tracking number after picking-up the parcel. ABCInc will in turn send the tracking number to his *Customer*. Once the *Shipping company* delivers the parcel to the *Customer*, it sends ABCInc the delivery confirmation (i.e. customer's signature) and the process ends with a successful result.

# 5 Identification of REA Concepts

We presented in section 2 the REA ontology and explained its three core concepts: *Resources*, *Events* and *Agents*. In this section, we explain how we identify each of these concepts from a BPMN process model.

## 5.1 Economic Agents

REA Agents are modeled explicitly in a BPMN collaboration as *Participants*. Indeed, BPMN defines participants as "...specific PartnerEntity (e.g., a company) and/or a more general PartnerRole (e.g., a buyer, seller, or manufacturer) that are Participants in a Collaboration..."[17]. External participants are modeled as process *pools* whereas internal participants (e.g. economic units) are represented as *swimlanes* within the pool of the entity under study. In our ABCInc example, ABCInc is the company under study having two internal agents: the *sales department* and the *warehouse*. The *customer*, the *shipping company* and the *bank* are three external agents.
<figure><img src="image_5.png" /><figcaption>Fig. 4. ABCInc sale-and-delivery simplified (and fictive) example</figcaption></figure>

## 5.2 Economic Resources

Economic resources involved in the BP can be explicitly modeled as objects, called in BPMN terms *Item Aware Elements* and defined as elements that "are subject to store or convey items during process execution"[17]. Item Aware Elements could be either informational or physical and specialize as Data Objects, Data Object Inputs, Data Object Outputs and Data Object References. Hence, this appears to be an appropriate construct to represent economic resources. However, not all Data Objects<fnref n="3" /> involved in the BP are economic resources. For example, an order document usually appears in BP models but does not answer the scarcity property of economic resources’ definition (see Section 2). Therefore, Data Objects representing economic resources must be clearly distinguished from non economic objects and we propose to stereotype them as "Economic".

We do this as the first step of our approach (Step 1, fig. 3). We conjecture that all *Physical Data Objects* should be considered as economic resources and will be stereotyped as such automatically. However, we cannot infer systematically the economic nature of informational *Data Objects*. Therefore, we involve the analyst who is asked to manually stereotype all non-automatically identified economic resources. In fig. 4, we have stereotyped all relevant economic resources.

## 5.3 Economic Events

As seen in Section 2, economic events are actions producing changes in the economic resources (their rights or properties). Thus, we relate economic events to BPMN activities but we still need to determine, from the set of BPM’s activities, which should be considered as economic events. We can intuitively filter out those activities that are not related to an economic resource (i.e. as input or

<footnote n="3">³ in the remainder of this paper, we will use the terms DataObject and ItemAwareElement interchangeably.</footnote>
output). However, this is not sufficient as some of the remaining activities may
not be economic events. Let's imagine that in our ABCInc BP we wanted to
weight the package before shipping. This activity would take the package as an
input but will not produce any change neither in package's properties nor rights.

There are two types of economic events: the ones that transfer some resource rights and the ones that alter some resource properties. We infer the first class of events from message sending/receiving activities<fnref n="4" /> in the BPMN model (e.g. "Send Process Payment Request" from fig. 4). As BPMN only allows communications between participants through messages, the economic resource sent (resp. received) by a sending (resp. receiving) activity will be its output (resp. input) economic Data Object (see [17, pp.48]). The second category of events implies activities producing some new resource(s) or a modified version of its input(s). Therefore an economic event will be related to *each* input and *each* output resource of the activity. From our example in fig. 4, we will derive three economic events from the "Prepare order" activity.

## 6 BPMN to REA Patterns

As seen in the previous section, identifying REA concepts is a straight forward process applying simple rules. However, we cannot determine all concept instances relying solely on these rules. In our example, the "Products" leave ABCInc at some point and end-up being in the possession of the customer. We cannot determine using our rules how the Products' location got changed. There must be an economic event in charge of altering the *location property* but how to determine it? Intuitively we think of the shipping company being responsible of doing the transportation but does it involve any other resource? Another question we might ask is how are these REA concept instances associated? Some associations are explicit in the model as the provider/receiver relationships between agents and economic events or the associations between economic events and resources. But what about associations between economic events (i.e. dualities)?

We believe the answer to these question could be inferred as - through the analysis of a set BP collaborations - there seem to be a handful of business collaboration scenarios that we could codify as patterns. In this section we present these patterns classified into two categories: *structural* and *behavioral* patterns. Structural patterns give us a one to one mapping between a portion of the BPMN model and an REA process (or a set thereof). Behavioral patterns, on the other hand, exploit execution semantics of the BPMN model in order to *refine* the inferred REA processes.

Before detecting the patterns, we perform a preliminary step that replaces messages exchanged between *external* participants by two messages: one from the original sender to the company under study, and one from the company to the original receiver. Indeed, as mentioned in 4.1 the BPM should reflect the BP of the company under study and we assume that communications between external participants should be done on behalf of the company.

<footnote n="4">⁴ These activities need to have an input or output economic resource as we ruled out those that do not.</footnote>
In the following, we present the structural and behavioral patterns in turn. We illustrate each pattern in its simplest form in fig. 5. However, the reader should note that each pattern may be declined into an infinite set (e.g. involving more resources, different order of activities, etc.).

**6.1 Structural patterns**

**Conversion pattern** From our ABCInc example, the "Prepare Order" activity encloses the ordered products in a box on which a shipping label is sticked. Thus we went from a pile of products to a box containing the products that is proper for shipping. This activity along with its input and output economic resources (elements on a black background in fig. 4) constitute what we call a *conversion pattern*. A conversion patterns occurs when an activity creates an added value by consuming and/or using some input economic resources and produces some output resources that are either new resources or an enhanced version of the inputs. In the former the created resource does not appear as an inflow resource whereas in the latter it is part of the input set. A conversion pattern will naturally be translated into an REA conversion process where input economic resources will form the *inflows* of the process and the output resources will form the *outflows*. This pattern is illustrated in fig. 5(a).

**Exchange pattern** ABCInc sends some products to his customer for which it gets a money payment. This "sale" is a typical example of an *exchange pattern*, i.e. one of the participants provides some economic resources in order to gain some other (*different*) economic resources in exchange. An exchange pattern is converted into an REA exchange process having the business events associated to the provided resources as inflows events and the business events related to the economic resources received by the company as outflows. We illustrate this pattern in fig. 5(b).

**Outsourcing and Insourcing patterns** It happens that a company wants to delegate part of its production workflow to an external company. For example, in our ABCInc case, the company relies on a banking institution to transfer the money from customer's bank account into its own. We define an outsourcing as the delegation by a company of part of the value adding process to an external partner. A resource (or a set thereof) is provided to the partner in order to be transformed and received back once done. The partner does the work for a "fee" thus we expect another (different) resource being provided by the company as a payment.

An outsourcing pattern will be transformed into two REA economic processes: an REA conversion process and an REA exchange process [11, pp. 316-318]. In the conversion process the resource is transformed by the partner. The conversion will also consume an intermediate resource we'll call a "Service" resource. This service resource is acquired with the economic resource provided as a payment, thus forming the REA economic exchange. We illustrate the pattern and its corresponding REA transformation in fig. 5(c).

We call the reciprocal the *insourcing pattern* in which the company alter some resource(s) for the benefit of a partner. However, the corresponding REA transformation will only contain the exchange as, in this case, the private process is known and the resource alteration will be matched as a conversion pattern.
<figure><img src="image_6.png" /><figcaption>**Fig. 5.** Four structural patterns: (a) conversion, (b) exchange, (c) outsourcing and (d) renting pattern. (A→B: A must precede B; A...B: the order is irrelevant)</figcaption></figure>

**The renting pattern** Say we are a car renting company and rent cars to individuals. During the rent period, we lose the *usage* (right) on the rented car and receive a money payment (*ownership*). The payment we receive covers for both our inability to rent the car to someone else as well as the wear-and-tear sustained by the car. Modeling this in REA terms would involve an REA exchange process where the car's usage right is exchanged for the money, and a conversion process expressing the alteration of the car. This is what we call the *renting* pattern (see fig. 5d).

Generally speaking, we assume that when a resource is relinquished and leaves company's control, it will sustain alterations. However, we can envision
<figure><img src="image_7.png" /><figcaption>Fig. 6. Final result of our approach applied on the ABCInc example from fig. 4.</figcaption></figure>

cases where this is not true, specifically when the lent resource is non-tangible. Consider for example a loan process: the money lent and recovered will not sustain any alteration. In such cases, the REA conversion in the transformation model on fig. 5(d) will have no effect.

## 6.2 Behavioral Patterns

The patterns presented above showed how to translate portions of a BPMN model into a set of REA processes relying solely on structural aspects. Conversely, behavioral patterns exploit execution semantics in order to *refine* the REA processes obtained from the structural patterns. Therefore, behavioral patterns are not self sufficient and must be combined with a structural pattern.

For example, consider the case where a customer provides the company with the raw material in order to perform some production and the money payment for the service and, once done, the company gives back the finished good. In such a scenario, our *Exchange Pattern* will be matched (money and raw material exchanged for finished goods). However, the raw material should not be part of the exchange as the company do not acquire the ownership on the raw material, but will be consumed by the conversion process that produces the finished good. This is what we call the *resource provisioning pattern*. We have identified three more behavioral patterns: *independent branches*, *internal responsibility* and *resource dependency*. Due to space limitations, these patterns will be presented more thoroughly in an extended version of this paper.

## 6.3 Patterns detection and transformation

As we mentioned, behavioral patterns are meant to be combined with structural patterns. Therefore structural patterns along with different allowed combinations of structural patterns and behavioral patterns form an extended set of self-sustaining patterns, each with a corresponding REA transformation. This extended set forms a rule base in which each rule have the BPMN pattern as its left-hand side and the corresponding REA transformation as its right-hand side.
However, in order to perform the transformation in a rule-based system, we first need to address two problems.

The first problem concerns the non-confluence of our rules[12]. We can easily see that our rules are not confluent if we consider, for example, the exchange and the outsourcing patterns. In a sense, the outsourcing patterns "embeds" an exchange. Thus, both rules could fire, each producing a different transformation. To address this problem, we elected to define the order in which the rules should be fired. We conjecture that more specific rules should have precedence over less specific rules. A rule *A* is more specific than a rule *B* if (1) matching *A* implies matching *B* (i.e. *A* embeds *B*), or if (2) both are the same structural pattern but *A* has more combined dynamic patterns.

The second issue is the partial matches of the BPMN patterns. The dark greyed portion of fig. 4 concerns the handling of *Money* transfer by the *Bank* and should match an outsourcing pattern, but a resource given by *ABCInc* to the *Bank* is missing in the BP (i.e. the service fees). Indeed, a given BP does not live in isolation and paying *Bank*'s fees could be handled by a separate account-receivable BP. However, we still need to account for the missing resource as it is part of the value-chain that supports the BP. Our solution to this problem is based on a heuristic that extends the original BPMN model by adding an anonymous resource flowing to/from the company to/from each of the participants. Then the rules are fired and the extension that produces the more specific pattern match is selected. If two equally specific rules are matched, we ask the analyst to resolve the conflict.

We present in fig. 6 the resulting REA model generated by our implementation after applying our approach on the *ABCInc* case.

# 7 Validation

We performed an experiment on a population of eight (8) graduate students from our laboratory with a research focus on electronic commerce. While all of our participants knew how to read and interpret either a BPMN model or an UML activity diagram, none of them knew about business modeling.

The experiment was divided into two phases. The first was a two hours session where the experimenter presented the REA ontology to the participants, its objectives and modeling syntax. Following the presentation, participants were asked, as an exercise, to model the REA transformation of the *ABCInc* example presented in fig. 4. The session was concluded by presenting to the participants three BPMN models on which the experiment will be performed: a software engineering process (P1), a travel booking process (P2) and a manufacturing process (P3). At the end of the session, we asked each participant to annotate the three models by identifying economic resources from *Data Objects*. In between the two sessions, participants were asked to model the REA transformations of each of the three BPMN models relying on their intuition and understanding of the process. They were given two instructions: (1) to respect the REA modeling syntax, and (2) to model to the lowest granularity level permitted by the provided BPMN model (i.e. including as much REA processes as possible).

The second session took place a week later as one-on-one interviews. They were presented with the automatically generated transformations, with respect
<table><caption>Table 1. Experimental results</caption><thead><tr><th rowspan="3">Process</th><th colspan="10">Automatic Transformation</th><th colspan="2">Manual Transformation</th></tr><tr><th colspan="4">Original annotations</th><th colspan="4">Revised annotations</th><th colspan="2">Man</th><th>P</th><th>R</th></tr><tr><th>Gen</th><th>Q1</th><th>Q2</th><th>Q3</th><th>Gen</th><th>Q1</th><th>Q2</th><th>Q3</th><th>Q4</th><th></th><th></th></tr></thead><tbody><tr><td>P1</td><td>12.00</td><td>11.87</td><td>11.62</td><td>10.12</td><td>12.62</td><td>12.62</td><td>12.25</td><td>12.62</td><td>8.25</td><td>7.81</td><td>0.97</td><td>0.95</td></tr><tr><td>P2</td><td>3.12</td><td>3.00</td><td>2.75</td><td>2.50</td><td>4.50</td><td>4.37</td><td>4.37</td><td>4.37</td><td>4.00</td><td>3.37</td><td>0.97</td><td>0.84</td></tr><tr><td>P3</td><td>5.37</td><td>5.37</td><td>5.00</td><td>4.75</td><td>5.87</td><td>5.87</td><td>5.37</td><td>5.87</td><td>4.37</td><td>4.00</td><td>0.91</td><td>0.91</td></tr><tr><td>All</td><td>6.83</td><td>6.75</td><td>6.46</td><td>5.79</td><td>7.66</td><td>7.62</td><td>7.33</td><td>7.62</td><td>5.54</td><td>5.06</td><td>0.96</td><td>0.91</td></tr></tbody></table>

to their provided annotations, and were asked to answer the following questions for each REA process from the generated value models:

- (Q1) Relevancy: Should the REA process be part of the value-chain?

- (Q2) Consistency: If relevant, does the REA process contains any semantic inconsistencies with respect to the BP?

- (Q3) Global consistency: If relevant, is the REA process' placement within the value-chain and its relationships with other REA processes coherent?

Then they were given the opportunity to modify their annotations (e.g. by adding an economic resource they overlooked in the first session). We generated a new REA transformation according to the new annotated model and the participants were asked, for each REA process from the new generated model, to answer the previous questions, as well as:

- (Q4) Could you match the REA process to an REA process from your manual transformation?

## 7.1 Results

Table 1 presents the compiled results for each BPMN model of our experiment (P1, P2 and P3). The table is divided into three sections. The first two sections are related to the generated value-chains (1) from the original annotations and (2) after the annotations were revised. In each section, we compiled the average count of the answers to each of the questions presented in the previous subsection.

The third section shows the average number of REA processes obtained from participants' manual transformations (#Man). Column Q4 shows the average REA processes from the manual transformations that were matched to an REA process in the generated model. The last line of the table gives the average values per process and per participant.

From these results we computed the precision (P) and recall (R) of automatic transformations after annotations were revised as $P = \frac{Q2}{Gen}$ and $R = \frac{Q4}{Man}$.

## 7.2 Validity Threats

The major threat to the validity of our experiment lies in the limited expertise of our subjects that we mitigated by providing a two hours lecture on business modeling and divided the experiment into two sessions, giving them a hands-on experience in-between sessions. We also recognize that the small number of BPs on which we tested our approach threatens its generalizability. While we believe that the results provide a weight of evidence in support to our hypothesis, a more extensive validation involving more business processes has still to be done.
## 7.3 Discussion

As presented in table 1, our approach permitted to recall 91% of the REA processes identified by our study participants. Furthermore, we generated a total of 183 REA processes deemed relevant out of 133 discovered manually. This supports our hypothesis of discovering all the REA processes that could be detected from the given annotated BPM (H1). Our results also show that 96% of the discovered REA processes were judged by our participants to be relevant and consistent, thus supporting our second hypothesis (H2).

From a pragmatic standpoint, the results and interviews with participants reflected the ways in which our approach could help analysts in designing value models of business processes. First, the experiment showed that we generated 38% more relevant REA processes as compared to manual transformations. Furthermore, comparing results before and after annotations were revised allowed us to see how participants were able to refine their results. Indeed, our approach makes it easy to spot missing or erroneous annotations, enabling iterative refinements until getting a sensible value-chain. Finally, during one-on-one interviews, participants unanimously acknowledged that producing REA processes through our approach much more efficient than the manual approach.

The experiment results also helped to highlight some problems with our approach. Indeed, 7 REA processes out of 184 were deemed inconsistent. The main inconsistency that surfaced through our analysis is related to the outsourcing pattern when the participant involved is the customer of the company under study. Indeed, the customer may be involved in a given conversion process, but our participants advised that the "service" he provides should not be accounted for in the conversion. We believe this is a subjective opinion that is more related to modeling decisions and compromises made by the analyst than to the existence of the consumed service *per se*. We can account for such compromises by relying on a classification of process participants (i.e. customer vs. providers).

## 8 Conclusion

A business process model (BPM) cannot capture all aspects of the business process it supports as it is only one of the many viewpoints from which the process could be considered. In fact, a BPM depicts *how* the process should be performed and by *whom*. In particular, it abstracts away from questions like *what* is involved and *why*? This is answered by the business model (BM) of the process. Keeping the BPM and the BM in sync is important in order to ensure that business process execution is aligned with strategic decisions and goals.

In this work, we propose a semi-automatic systematic approach to generate a BM from a BPM and, more specifically, to transition from a BPMN model into an REA value-chain. The first step is partly manual and requires an analyst to identify economic resources from data objects in the BPMN model. The next step maps REA concepts to BPMN concepts. The third step relies on a set of structural and dynamic patterns to infer the relationships between the identified REA concept instances and obtain so-called REA processes. Finally, we construct the overall value-chain by linking the REA processes.

We applied our approach on a case study we used as a running example and performed a preliminary validation that showed a precision rate of 96% and a
recall of 91%. Our major contribution lies in the definition of the set of generic business patterns that are at the heart of our approach. Our preliminary validation provides a weight of evidence in support of our approach and a thorougher validation has still to be performed.

## References

1. B Andersson et al. From Business to Process Models: a Chaining Methodology. In *BUSITAL'06*, Luxembourg, 2006.

2. B Andersson et al. Towards a Reference Ontology for Business Models. In *ICCM'06*, pages 482–496. Springer Berlin / Heidelberg, 2006.

3. L Bodenstaff, A Wombacher, R Wieringa, and M Reichert. An approach for maintaining models of an ecommerce collaboration. In *CEC/EEE*, pages 239–246, 2008.

4. A Boubaker, H Mili, Y Charif, and A Leshob. Methodology and Tool for Business Process Compensation Design. In *EDOC'13 Workshops*, Vancouver, Canada, 2013.

5. A Boubaker, H Mili, Y Charif, and A Leshob. Towards a Framework for Modeling Business Compensation Processes. In *BPMDS'13*, Valancia (Spain), 2013.

6. K Czarnecki and S Helsen. Classification of model transformation approaches. In *Gen Techniques in the Context of Model-Driven Architecture*, pages 1–17, 2003.

7. S Demeyer, S Ducasse, and O Nierstrasz. *Object-oriented reengineering patterns*. Elsevier, 2002.

8. H Fatemi, M van Sinderen, and R Wieringa. Value-oriented coordination process modeling. In *BPM2010*, pages 162–177. Springer, 2010.

9. J Gordijn. *Value-based Requirements Engineering*. PhD thesis, Vrije Universiteit Amsterdam, 2002.

10. J Gordijn, H Akkermans, and H van Vliet. Business Modelling is not Process Modelling. In *Conceptual Modeling Approaches for e-Business*, pages 40–51, 2000.

11. Pavel Hruby. *Model-Driven Design Using Business Patterns*. Springer, 2006.

12. J M Küster and M Abd-El-Razik. Validation of model transformations: first experiences using a white box approach. In *MODELS'06*. Springer, October 2006.

13. F M Maggi, C Di Francescomarino, M Dumas, and C Ghidini. Predictive Monitoring of Business Processes. *arXiv.org*, December 2013.

14. W E McCarthy. The REA Accounting Model: A Generalized Framework for Accounting Systems in a Shared Data Environment. *The Accounting Review*, 57(3):554–578, 1982.

15. H Mili, R Godin, G Tremblay, and W Dorfeuille. Towards a Methodology for Designing Compensation Processes in Long-Running Business Transactions. In *MCETECH'2006*, pages 137–148, Montreal, Canada, 2006.

16. H Mili, A Leshob, E Lefebvre, and G Lévesque. Towards a Methodology for Representing and Classifying Business Processes. In *MCETECH'09*, pages 196–211, Ottawa, Canada, 2009. Springer.

17. OMG. Business Process Model and Notation (BPMN). OMG, January 2011.

18. A Osterwalder. *The Business Model Ontology*. PhD thesis, Université de Lausanne École des Hautes Études Commerciales, 2004.

19. V Pijpers and J Gordijn. Consistency checking between value models and process models: A best-of-breed approach. In *BUSITAL*, pages 58–72, Montpellier, 2008.

20. J Pitschke. Integrating Business Process Models and Business Logic: BPMN and The Decision Model. In *BPMN2011*, pages 148–153, 2011.

21. A-W Scheer, O Thomas, and O Adam. Process modeling using event-driven process chains. *Process-Aware Information Systems*, pages 119–146, 2005.

22. The Open Group. TOGAF. The Open Group, 2011.

23. W M P Van Der Aalst. Business Process Management: A Comprehensive Survey. *ISRN Software Engineering*, 2013(1):1–37, 2013.

24. M Weske. *Business Process Management: Concepts, Languages, Architectures*. Springer, 2nd edition, 2012.

25. R Wieringa, V Pijpers, L Bodenstaff, and J Gordijn. Value-driven coordination process design using physical delivery model. In *ER*, pages 216–31, Barcelona, 2008.

26. S. C. Yu. *The Structure of Accounting Theory*. The Uni Press of Florida, 1976.