# Value-Driven Risk Analysis of Coordination Models

Dan Ionita, Jaap Gordijn, Ahmed Seid Yesuf, Roel Wieringa

► To cite this version:

Dan Ionita, Jaap Gordijn, Ahmed Seid Yesuf, Roel Wieringa. Value-Driven Risk Analysis of Coordination Models. 9th IFIP Working Conference on The Practice of Enterprise Modeling (PoEM), Nov 2016, Skövde, Sweden. pp.102-116, 10.1007/978-3-319-48393-1_8 . hal-01653518

HAL Id: hal-01653518

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

Submitted on 1 Dec 2017

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>
# Value-Driven Risk Analysis of Coordination Models

Dan Ionita¹, Jaap Gordijn², Ahmed Seid Yesuf³, and Roel Wieringa¹

¹ University of Twente
Services, Cybersecurity and Safety group,
Drienerlolaan 5, 7522 NB, Enschede, The Netherlands
[d.ionita,r.j.wieringa]@utwente.nl
http://scs.ewi.utwente.nl/

² Vrije Universiteit Amsterdam,
De Boelelaan 1105, 1081 HV Amsterdam, Netherlands
 gordijn@cs.vu.nl

³ Goethe University,
D-Telekom Chair of Mobile Business & Multilateral Security,
Frankfurt am Main, Germany
ahmed.yesuf@m-chair.de

**Abstract.** Coordination processes are business processes that involve independent profit-and-loss responsible business actors who collectively provide something of value to a customer. Coordination processes are meant to be profitable for the business actors that execute them. However, because business actors are independent, there is also an increased risk of fraud. To compute profitability as well as quantify the risk of fraud, we need to attach value models to coordination process models. In this paper, we propose guidelines for deriving a value model from any coordination process model. Next, we show how our approach can be used to identify possibilities of fraud offered by a coordination process, as well as quantify the financial impact of known fraudulent processes. Finally, we discuss additional applications, such as identifying commercially superfluous tasks, or missing tasks needed to achieve a financially sustainable process.

**Key words:** Risk-aware BPM; Cost-aware BPM; Process analysis and improvement

## 1 Introduction

Today, *electronic commercial* services, are an important source of revenue for many businesses. For instance, consider companies such as Netflix, Spotify, or in our case study domains, Internet service providers and telecoms. Most e-services share two common attributes: (1) they are paid, usually by a customer and (2) they are provided by a complex network of enterprises. As a result, these services are open to opportunities to commit fraud. For example, a fraudulent actor may use the telephone subscription of someone else to place expensive phone calls.
Although fraud is often performed by misusing a business or coordination
processes, its impact is actually on the business *value* level. Therefore, we need
an instrument to analyze and express its financial effects for all actors involved.
In line with previous work on value-based fraud analysis [1, 2], we use an *e<sup>3</sup>value*
model [3] for this purpose. Because a value model represents what actors ex-
change with each other in terms of *economically valuable* objects (such as prod-
ucts, services or information), it is fundamentally different from a process model.
Abstracting away from operational details, *e<sup>3</sup>value* models only show *what* is of-
fered, and not *how*.

Unfortunately, for many commercial services, information contained in a
value model only exists in the mind of stakeholders, but an explicitly stated
model is lacking. Coordination process models, however, often are available or
can be harvested from existing coordination and orchestration systems [4]. While
several approaches can be useful for designing a process model based on given
value model ([5, 6, 7, 8, 9, 10]), to the best of the authors' knowledge no previous
work exists looks at an inverse technique.

Our contribution is therefore a new set of guidelines by which an available
BPMN coordination process model can be used to derive a corresponding e³value
model (Section 3). With the resulting value model, we can use existing tools to
identify and prioritize fraud and misuse scenarios (see Section 4.1), as well as es-
timate the impact in terms of lost value, and potential gain in terms of misplaced
value for the actors involved (see Section 4.2). This assists the decision making
process by enabling quantification of risks, but is also useful for rationalizing
coordination models (see Section 5).

## 2 Background

### 2.1 Business process modelling

Business process models describe sequences of activities in business units or or-
ganizations. There exist a large variety of techniques to document processes,
ranging from flowcharts to Gantt charts and from Data Flow Diagrams to UML.
For coordination process modelling, two established notations currently stand
out: The *Business Process Model and Notation (BPMN)* and the *Business Pro-
cess Execution language (BPEL)*. The BPMN notation [11], is designed to appeal
to technical users while being understandable to business users as well. BPEL
[12], on the other hand, is mainly targeted at web service developers and lacks a
standard graphical notation. Several approaches for translating between BPMN
and BPEL have been proposed [13, 14, 15], but they have mainly served to
expose fundamental differences between BPMN and BPEL [16, 17].

Given the difference between BMNP and BPEL, we decide to use BPMN in
this paper because of its standardized notation and because its audience and
scope are closer to that of value models.
## 2.2 Value modelling

The purpose of value modelling is to aid in business development, namely to explore, develop, and evaluate the value proposition of an enterprise, or a con-stellation of these. There are three important approaches: (1) the Business Model Ontology/Canvas (BMO/BMC) [18], (2) the Resource / Event / Agent (REA) ontology [19], and (3) the *e<sup>3</sup>value* ontology [3].

The BMO approach takes one enterprise as point of departure, and considers its customers, suppliers, and other surrounding actors. However, since for fraud analysis we are mainly interested in *networks* of enterprises rather than just one, the BMO/BMC is less suitable for our purposes. The REA ontology is based on accounting theory, more specifically double entry bookkeeping. For our goal, it adds unnecessary complexity by requiring that each business transaction has four actions, namely increasing the amount of money and decreasing the stock at the seller's side, and decreasing the amount of money and increasing possession (of the delivered good) at the customer's side. Additionally, REA does not explicitly support multi (> 2) transfer transactions. Therefore, in this paper, we utilize the *e<sup>3</sup>value* approach, which recognizes the importance of the *network* of actors, and the idea of economic reciprocity in multi-transfer transactions.

In *e<sup>3</sup>value*, there are a number of modelling constructs available to express a value proposition [3], which we discuss below. Figure 3b shows a very simple *e<sup>3</sup>value* model. Enterprises and customers are represented as *actors*, and a set of actors of the same type (e.g. customers) is represented as a *market segment*. These actors are economically independent actors that intend to make a profit (in case of companies), to play break-even (in case of non-for-profit organizations), or to increase economic utility (in case of end users). Actors exchange *objects of value* with others, by *value transfers*. Some value transfers belong to each other, as they are reciprocal. For instance, a good may be transferred in return for the transfer of money. Such transfers have a mutually opposite direction; money is paid to the seller by the customer, and the good is transferred from the seller to the customer. Actors have *value interfaces*, consisting of *value ports*. These interfaces model economic reciprocity, as each interface has at least one *ongoing port* (e.g. a payment), and one *outgoing port* (e.g. delivery of a good). Actors may have a customer *need*, which results in value transfers (e.g. obtaining a product in return for a payment). Similarly, enterprises may express relations between value interfaces, denoting that in order to sell a product, other product(s) must be obtained. The dependencies among transactions needed to sell a product, are represented by a *dependency path*. *Boundary elements* express that we do not consider additional transfers anymore, and as such represent system boundaries.

It is important to understand that the *e<sup>3</sup>value* approach is different from what is usually done in process models [20]. The most important differences are: (1) *e<sup>3</sup>value* recognizes explicitly the notion of *economic value*, (2) *e<sup>3</sup>value* has a modelling construct for the notion of *economic reciprocity*, and (3) *e<sup>3</sup>value* only has dependency constructs and therefore can not represent *time-ordering* and control flows as used in process models. This corresponds to the goal of e3value,
which is to understand financial effects in a network of enterprises, and to do
business development.

## 2.3 Relating value models and process models

Value models and coordination models have different goals and thus represent different types of information. At the same time, they are also related because they express different aspects of the same artifact, namely a set of enterprises and customers aiming to make a profit or to increase their economic value.

When designing a new e-business network, the designer starts with the development of a value model, often as a result of a series of business development workshops. The primary goal is to arrive at a shared understanding amongst the participating enterprises about what they offer each other of economic value, *without* considering *how* these value propositions are executed in terms of operational business processes. This allows identification of potentially profitable e-business models from a management point of view. If a profitable e-business network has been designed, the next step is to assess operational feasibility, which includes assessing and mitigating risks of fraud. This requires a coordination process model. Schuster et al discuss the design of UMM models from *e³value* /REA models [6, 7]. The design of a process model from a value model can be also based on a consideration of trust issues [1, 8] or on the distinction between ownership and possession of value objects [9, 10].

In this paper we consider the case where businesses are already cooperating, but they want to assess the business value of this cooperation, for example in order to assess if the cooperation is still profitable, to assess the economic necessity of all parts of the coordination process, or to assess the potential for fraud, as we do in this paper. In the real world, many business processes and coordination processes evolve without regular consideration of the underlying value model, and it has been observed earlier that identification of the value proposition of a business process is a key concern of practitioners [21].

In the next section we show how to derive a value model from an existing process model, in Section 4 we show how to use the resulting pair of models in fraud analysis and in Section 5 we discuss further applications.

# 3 From coordination process model to value model

As the value model represents different information about a value web than a coordination process model does, deriving a value model from a process model cannot be fully automated: information needs to be added to as well as deleted from a process model. Moreover, to add this information, value design decisions need to be made, such as which step in a process actually adds value for which actor, how much value is added, and which dependencies exist among economic transactions. These informal decisions - underlined in Figure 2 - cannot be automated, and which of these decisions need to be made differs per process model
and depends on the intended value model. The rest of this section elaborates
on the derivation process proposed in Figure 2 and gives guidelines for these
decisions.

As a *running example* we take the simple process of setting up a new home Internet connection which requires network credentials. This applies to some telephony connections and/or ADSL connections where each user is authenticated to the provider via a username and password that are not linked to the equipment used to enable logical access to the provider’s network (e.g. modem).

<figure><img src="image_2.png" /><figcaption>**Fig. 1.** Ideal coordination model for setting up a new home Internet connection</figcaption></figure>

The normal (i.e. ideal, from the perspective of the provider) process by which a new subscriber requests and receives access to the network is shown in Figure 1. When a customer places an order for a new Internet connection, it triggers the generation of new access credentials. While the user pays for the first month of service, the credentials are sent to him by mail. A technician is scheduled a week or two later to install the necessary equipment (usually a modem). Once the equipment is installed, the credentials can be used to obtain access to the Internet. Note that, for simplicity and didactical reasons, we assume the provider does not wait for the payment to be received before proceeding with setting up the connection. Since modelling physical objects (such as money) as a message is only necessary if their arrival acts as a message event or is expected as input for some activity [22, Section 5.2] we omit modelling the payment as a cross-border message flow.

**3.1 Mapping process elements to value elements**

Several BPMN concepts do have corresponding concepts in e³value. Elements
such as BPMN pools, swimlanes, start points and flows share semantic simi-
larities e³value actors, sub-actors, needs and value transfers. We propose the
following mapping:

**Pools to actors:** instantiate every BPMN pool as an *e<sup>3</sup>value* actor and every
BPMN swimlane as a *e<sup>3</sup>value* sub-actor.
<figure><img src="image_3.png" /><figcaption>**Fig. 2.** Proposed derivation approach: solid boxes can be fully automated; dotted boxes require human decisions (underlined).</figcaption></figure>

*Running example:* BPMN Swimlanes *End-user* and *Provider* are instantiated as *e³value* Actors with the same name.

**Start events to needs** Select the BPMN Start Event(s) that correspond(s) to consumer need(s). Instantiate as corresponding *e³value* need(s), located at the same actor as the selected start event.

*Running example:* BPMN Start Event *Need for new Internet connection* becomes an *e³value* *Need* associated with *End-user*.

**Activities and/or flows to Value Transfers:** Per activity and per flow, state if they deliver value and to which actor. Then, create a corresponding transfer in the value model.

*Guideline:* A BPMN activity maps to an *e³value* activity if and only if the BPMN activity results in a potential profit. In many situations, this is not the case; many BPMN activities are generating costs. Therefore, the mapping from BPMN activities to *e³value* activities is non-trivial. To find such a mapping, the modeler should ask himself: which BPMN activities and flows relate logically, such that together, they create a profit.

*Running example:*

- BPMN activity *Pay for order* provides (monetary) value to the *Provider*. Therefore, it is mapped to an *e³value* transfer of type *MONEY* which we name *Payment*.
- BPMN activities *Generate credentials*, *Receive credentials* and *Install equipment*, as well as the flows connecting them to each other and to the other components of the process model together provide (service) value to the *End-user*, in the form of Internet access. Therefore, they are grouped into an *e<sup>3</sup> value* transfer of type *SERVICE* which we name *Internet access*.

- BPMN activity *Place order* and the corresponding message flow only serve as a coordination mechanism and do not provide any value to any of the actors. Therefore, they do not have a corresponding transfer in the value model.

The value model after this first step is shown in Figure 3a.

<figure><img src="image_4.png" /><figcaption>**Fig. 3.** Evolution of the derived value model for setting up a new home Internet connection</figcaption></figure>

## 3.2 Enriching the value model

**Group transfers:** Per actor, reciprocal transfers which always occur together should be grouped as part of a single *e<sup>3</sup> value* interface.

*Guideline:* For each actor, two transfers he is engaged in are reciprocal (and therefore part of the same interface) if that actor considers that the outgoing transfer provides adequate compensation for what he offers [23]. Note that this does not have to be a one-to-one mapping: an interface may contain any number of incoming and outgoing transfers. While BPMN does not contain sufficient information to decide when two transfers are reciprocal, the execution semantics of BPMN can help ruling out transfers which are not. Specifically, exclusive gateways, event gateways and multiple start events give birth to *alternative paths* [24]. Depending on the conditions of the split or which start event is triggered, activities belonging to one of the alternative paths might not be executed. Conversely, a process model with a single start node and no OR or XOR splits will always terminate, and all activities will be executed [25]. Two *e<sup>3</sup> value* transfers between the same two actors, can be grouped if and only if all BPMN activities that were mapped to these transfers in the previous step are part of the same
path. Conversely, if any two activities required for the realization of any of the
two transfers are located on alternative paths, then the two transfers should not
be part of the same interface.

*Running example:* The two transfers (*Payment* and *Access*) are reciprocal and part of the same path and can therefore be grouped.

**Add dependency paths:** Following the sequence and message flow of the original BPMN model from the start, add corresponding dependency paths between the elements of the value model.

*Guideline:* Since *e<sup>3</sup>value* models lack procedural information such as timing, the goal of this step is not to accurately represent the order in which the transactions take place but rather the causal dependencies between these transaction. Therefore, care must be again given to *alternatives paths*. As a guideline, map parallel gateways to AND nodes and exclusive gateways and event-based gateways to OR nodes. *e<sup>3</sup>value* OR node are annotated with *fractions*. These fractions should reflect the relative likelihood of the condition-events (in case of event-based gateways) or of the conditions (in case of exclusive gateways).

*Running example:* we just need to connect the Need to the only transaction.

**Add ends:** Add *e<sup>3</sup>value* ends as needed to any transactions without a connection to a dependency path.

*Running example:* we are left with one transaction which has no outgoing dependency paths so we add an end point and connect it to this transaction.

**Add value estimates:** Quantify the value being generated or transfered by the activities in the process model and attach these values to the corresponding transfers.

*Guideline:* *e<sup>3</sup>value* provides two ways of attaching monetary values to transfers: if the object being transferred has the same value for both the actors involved, then this value is attached to the transfer itself; otherwise, each individual valuation is attached to the corresponding end of the transfer.

*Running example:* We add the value of the payment to the “Payment [MONEY]” transfer. We may also add the valuation by any or both of the actors of the “Access [SERVICE]” to the model.

The final value model is shown in Figure 3b.

# 4 Applications to fraud analysis

Once we derive a value model from an *ideal* coordination model, we can leverage previous work on value models in order to run various value-based analyses on it, such as fraud assessment using e3fraud[2]. Or, if we started out with a coordination model which includes fraudulent activities, we can do impact estimation using e3value[3].
## 4.1 Fraud assessment of an ideal coordination process

In this section, we apply the e³fraud methodology for automated identification and prioritization of business risks in e-service networks [2] to a derived value model and discuss the implications of the results on the initial process model. The associated e³fraud tool<fnref n="1" /> can generate possible fraudulent variations, in terms of (1) transactions that might not occur as agreed, (2) transactions that were not expected to occur and (3) collusion, where two or more actors thought to be independent act together against the interests of the provider. It also orders these sub-ideal scenarios based on potential gain for the fraudster, impact for the service provider, or both.

For instance, if we load the derived value model of our simple running example (Figure 3b) into the e³fraud tool, breaking transactionality by bypassing the only payment is – quite obviously – identified as the most damaging scenarios. Figure 4 shows the corresponding e³fraud model, as generated by the e³fraud tool. The Payment transfer is marked as dashed to highlight the fact that it does not occur.

Leveraging the decisions made during the derivation process, we can now extend the

e³fraud analysis by mapping a fraudulent scenario back to the original process model, adding mitigations to this process model, and assessing the impact of those mitigations on the profitability as well as the fraud risks of the value model. This too is a partly automated and partly manual process, and could be a topic for further investigation.

<figure><img src="image_5.png" /><figcaption>Fig. 4. Highest ranked sub-ideal model generated by the e³fraud tool from the model in Figure 3b</figcaption></figure>

## 4.2 Impact estimation of a sub-ideal coordination process

The above approach allows us to find fraud using a process model and a corresponding value model of the ideal, non-fraudulent way of doing business. In many economic sectors, there are however known process models of fraud. For these process models, our approach can help estimating the economic impact of the fraud by constructing the corresponding value model of the fraud.

For instance, a known vulnerability of the process of setting up a new Internet connection – as described in Section 3 – involves exploiting the time delay between receiving the credentials and the physical installation of the equipment by a technician. A BPMN model of this fraudulent process is shown in Figure 5.

By applying the proposed model transformation steps, we end up with a corresponding value model of the fraud, as shown in Figure 6. We can now evaluate this value model using the established e³value profitability analysis ([3]) to estimate the profit made by the fraudster as well as the associated costs for

<footnote n="1">¹ https://github.com/danionita/e3fraud</footnote>
<figure><img src="image_6.png" /><figcaption>**Fig. 5.** Manually created sub-ideal process model of setting up a new home Internet connection</figcaption></figure>

<figure><img src="image_7.png" /><figcaption>**Fig. 6.** Value model derived from the model in Figure 5</figcaption></figure>

the internet provider. Furthermore, we can apply extensions of *e*<sup>3</sup>*value* aimed at analyzing sub-ideal value models – such as *e*<sup>3</sup>*control* [26] – in order to help implement preventive measures.

**5 Case study: the roaming service**

In the previous sections we used a simple, didactic example to introduce our
proposed derivation approach and to demonstrate how it can be used to assess
the potential for fraud in an existing non-fraudulent process as well as to esti-
mate the financial impact of a fraudulent process. Next, we test our approach
on a realistic business model obtained from a telecom service provider in order
to discuss alternative applications which were not visible in the first example. Specifically, we investigate if we can leverage the process-to-value mapping created as part of the derivation process to identify potential risks related to the commercial feasibility of a coordination process. To this end, we obtained and analyzed a coordination model of the process of calling from abroad, also known as roaming. This is a telephony service which involves multiple providers (both the home and the visited provider need to collaborate to provide the service) and several payments (between providers and between providers and the user).

The ideal process by which roaming services are provided and charged is shown in Figure 7. The process is triggered when the subscriber receives or initiated a call. Calling is a looping activity that triggers a technical sub-process (mobile subscriber identification, network routing, and so on). When a call is ended, a record of that call is saved. At fixed intervals, call records are billed and these bills are sent to the respective home providers. In turn, the home provider performs a corresponding payment and adds these costs to the subscriber's monthly bill.

<figure><img src="image_8.png" /><figcaption>Fig. 7. Ideal process model - roaming service</figcaption></figure>

We derive a value model from the process model shown in Figure 7 above by applying the transformation steps described in Section 3. The resulting value model is shown in Figure 8. Note that the transfer *Call* has no reciprocal transfer. This unusual result is discussed next.

**Non-reciprocal transfers** In the value model shown in Figure 8, obtained by applying the proposed derivation method to the process model shown in Figure 7, there is a transaction consisting of a single, non-reciprocal transfer: the *Call[SERVICE]*.
<figure><img src="image_9.png" /><figcaption>**Fig. 8.** Ideal value model - roaming service</figcaption></figure>

A non-reciprocal transfer implies that something realizing the reciprocal value transfer, is missing from the initial process model. Such duality problems in value models created with our approach can have one of two causes: either (1) there is a problem in the process or (2) there is a problem in the model of the process. The former is indicative of a financially unfeasible process, which means the process is either altruistic or fraudulent. The latter means that the activities or flows realizing the reciprocal transfer are intentionally left out (i.e. are out of scope of the model) or unintentionally omitted (as a result of improper modelling or poor data quality). Deciding which cause applies in a certain case is important as it might trigger a re-design of the process or an update of the model. Checking the process model against consistency rules, such as realizability [27], local enforceability [28] and desynchronizability [29] might help identify which of the three situations described above we are in and why, but this is subject of further research.

In the example of Figure 8, the process model is incomplete: it lacks information with regard to what is provided by the customer whenever he wishes to make a call, namely an identifier (commonly referred to as an IMSI<fnref n="2" /> in telecom) which acts as proof that the subscriber has the right to perform roaming calls. This right was obtained when the SIM card was first purchased or is included in the monthly subscription fee.

The fact that reciprocal value-producing tasks missing from the process model will result in incomplete or incorrect value models when transformed using our approach suggests that we can also use the approach proposed in this paper to rationalize and validate coordination models and processes in terms of their financial sustainability.

<footnote n="2">² International Mobile Subscriber Identity, used to identify the user of a cellular network and is a unique identification associated with all cellular networks. [30]</footnote>
**Superfluous activities** Another result of the derivation of a value model from the process model in Figure 7, is that one of the tasks - namely, *Save call records* was not identified as being part of a value transfer. Similarly, in Section 3.1 we did not map the *Place order activity* of Figure 1 to a value transfer. This indicates that these tasks do not have a commercial purpose. Therefore, from a commercial point of view, the process can be streamlined by eliminating the task. But perhaps from another point of view, e.g. auditing, the task may still have to be included. Whichever the case, but observations such as these could provide a starting point for process optimization activities.

# 6 Conclusions and future work

Our derivation approach can be used to construct a value model from a multi-actor BPMN process model, which in turn allows profitability analysis of the original process model, the generation of fraudulent variations of the process model, and the analysis of the financial effects of changes (fraudulent or not) in the process model. By starting with a fraudulent instead of an ideal process model, we can also use it to estimate to impact of fraud and of fraud-mitigating measures.

The derivation approach proposed is feasible: it was applied by two authors independently to two case studies and was found to produce very similar results. Of course, further real-world validation is needed to get a better idea as to how difficult and error-prone the derivation process is.

We envision supporting the process by means of a software tool. Such a tool would implement the algorithmic part of Figure 2, and guide the user through the non-automatable decisions he/she has to make. Another related topic which merits further investigation is whether a similar tool could use these decisions to maintain dynamic consistency between the two models, thereby supporting a wider range of applications, such as sensitivity analyses.

We believe that associating value models to coordination process models empowers the organization by promoting an understanding of the value creation activities inside the process and allowing usage of value analysis tools, such as income/cost estimations and fraud assessment.

**Acknowledgments.** The authors would like to thank Manfred Jeusfeld (University of Skovde) for his valuable input. The research leading to these results has received funding from the European Union Seventh Framework Programme (FP7/2007-2013) under grant agreements SEC-261696 (SESAME) and ICT-318003 (TREsPASS). This publication reflects only the authors views and the Union is not liable for any use that may be made of the information contained herein.
References

1. Ionita, D., Wieringa, R.J., Wolos, L., Gordijn, J., Pieters, W.: Using value models for business risk analysis in e-service networks. In Ralyt, J., Espaa, S., Pastor, s., eds.: The Practice of Enterprise Modeling. Lecture Notes in Business Information Processing. Springer International Publishing (2015) 239–253

2. Ionita, D., Wieringa, R.J., Gordijn, J.: Automated identification and prioritization of business risks in e-service networks. In: Exploring Services Science: 7th International Conference, IESS 2016. Proceedings, Springer International Publishing (May 2016)

3. Gordijn, J., Akkermans, H.: Designing and evaluating e-business models. IEEE Intelligent Systems 16(4) (July 2001) 11–17

4. Aalst, W.M.P.v.d.: Discovering coordination patterns using process mining. In Bocchi, L., Ciancarini, P., eds.: Proceedings of the First International Workshop on Petri Nets and Coordination. PNC04, CNR PISA, Italy, STAR (Servizio Ti-pografico Area della Ricerca) (2004) 49–64

5. Fatemi, H., van Sinderen, M., Wieringa, R. In: E3value to BPMN Model Transformation. Springer Berlin Heidelberg, Berlin, Heidelberg (2011) 333–340

6. Schuster, R., Motal, T., Huemer, C., Werthner, H.: From Economic Drivers to B2B Process Models: A Mapping from REA to UMM. In Abramowicz, W., Tolksdorf, R., eds.: Business Information Systems, 13th International Conference, BIS 2010, Berlin, Germany, May 3-5, 2010. Proceedings. Volume 47 of Lecture Notes in Business Information Processing., Springer (2010) 119–131

7. Schuster, R., Motal, T.: From e3-value to REA: Modeling Multi-party E-business Collaborations. In: Proceedings of the 2009 IEEE Conference on Commerce and Enterprise Computing. CEC '09, Washington, DC, USA, IEEE Computer Society (2009) 202–208

8. Kartseva, V., Gordijn, J., Tan, Y.H. In: Designing Value-based Inter-organizational Controls Using Patterns. Volume 14 of LNBIP. Springer Verlag (2009)

9. Weigand, H., Johannesson, P., Andersson, B., Bergholtz, M., Edirisuriya, A., Ilayperuma, T.: Value modeling and the transformation from value model to process mode. In Doumeingts, G., Mller, J., Morel, G., Vallespir, B., eds.: Enterprise Interoperability: New Challenges and Approaches, London, UK, Springer-Verlag (2007) 1–10

10. Pijpers, V., Gordijn, J.: Bridging business value models and process models in aviation value webs via possession rights. In: System Sciences, 2007. HICSS 2007. 40th Annual Hawaii International Conference on, IEEE (2007) 175a–175a

11. Weske, M.: Business process management: concepts, languages, architectures. Springer Science & Business Media (2012)

12. Juric, M.B.: Business Process Execution Language for Web Services BPEL and BPEL4WS 2Nd Edition. Packt Publishing (2006)

13. Ouyang, C., van der Aalst, W.M.P., Dumas, M., Arthur: Translating BPMN to BPEL. Technical Report BPM-06-02, BPM Center (2006)

14. White, S.A.: Using bpmn to model a bpel process (2005)

15. Ouyang, C., Dumas, M., ter Hofstede, A.H., van der Aalst, W.M.: Pattern-based translation of bpmn process models to bpel web services. International Journal of Web Services Research (JWSR) 5(1) (2007) 42–62

16. Weidlich, M., Decker, G., Großkopf, A., Weske, M.: BPEL to BPMN: The Myth of a Straight-Forward Mapping. In: On the Move to Meaningful Internet Systems: OTM 2008: OTM 2008 Confederated International Conferences, CoopIS, DOA, GADA,
IS, and ODBASE 2008, Monterrey, Mexico, November 9-14, 2008, Proceedings, Part I. Springer Berlin Heidelberg (2008) 265–282

17. Recker, J.C., Mendling, J.: On the translation between bpmn and bpel: Conceptual mismatch between process modeling languages. In Latour, T., Petit, M., eds.: 18th International Conference on Advanced Information Systems Engineering. Proceedings of Workshops and Doctoral Consortiums, Namur University Press (2006) 521–532

18. Osterwalder, A., Pigneur, Y.: An ebusiness model ontology for modeling ebusiness. BLED 2002 Proceedings (2002) 2

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

20. Gordijn, J., Akkermans, H., Vliet, H.: Business Modelling Is Not Process Modelling. In: Conceptual Modeling for E-Business and the Web: ER 2000 Workshops on Conceptual Modeling Approaches for E-Business and The World Wide Web and Conceptual Modeling Salt Lake City, Utah, USA, October 9–12, 2000 Proceedings. Springer Berlin Heidelberg (2000) 40–51

21. Indulska, M., Recker, J., Rosemann, M., Green, P.: Advanced Information Systems Engineering: 21st International Conference (CAiSE 2009), Springer Berlin Heidelberg (2009) 501–514

22. Object Management Group (OMG): BPMN 2.0 by Example. Technical Report dtc/2010-06-02 (June 2010)

23. Gordijn, J.: 5. In: E-business value modelling using the e3-value ontology. Elsevies Butterworth-Heinemann, Oxford, UK (2004) 98–127 Preprint available.

24. Onoda, S., Ikkai, Y., Kobayashi, T., Komoda, N.: Definition of deadlock patterns for business processes workflow models. In: HICSS 1999: Proceedings of the Thirty-second Annual Hawaii International Conference on System Sciences, Washington, DC, USA. Volume 5. (Jan 1999) 55–65

25. Awad, A., Puhlmann, F.: Structural Detection of Deadlocks in Business Process Models. In: Business Information Systems: 11th International Conference, BIS 2008, Innsbruck, Austria, May 5-7, 2008. Proceedings. Springer Berlin Heidelberg (2008) 239–250

26. Kartseva, V., Gordijn, J., Tan, Y.H. In: Designing Value-Based Inter-organizational Controls Using Patterns. Springer Berlin Heidelberg (2009) 276–301

27. Fu, X., Bultan, T., Su, J. In: Conversation Protocols: A Formalism for Specification and Verification of Reactive Electronic Services. Springer Berlin Heidelberg (2003) 188–200

28. Decker, G., Weske, M.: Local enforceability in interaction petri nets. In Alonso, G., Dadam, P., Rosemann, M., eds.: Business Process Management: 5th International Conference, BPM 2007, Brisbane, Australia, September 24-28, 2007. Proceedings. Springer Berlin Heidelberg (2007) 305–319

29. Decker, G., Barros, A., Kraft, F.M., Lohmann, N.: Non-desynchronizable service choreographies. In Bouguettaya, A., Krueger, I., Margaria, T., eds.: Service-Oriented Computing – ICSOC 2008: 6th International Conference, Sydney, Australia, December 1-5, 2008. Proceedings. Springer Berlin Heidelberg (2008) 331–346

30. Scourias, J.: Overview of the global system for mobile communications. Technical report (1995)