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^{3}\) value model [3] for this purpose. Because a value model represents what actors exchange with each other in terms of economically valuable objects (such as products, services or information), it is fundamentally different from a process model. Abstracting away from operational details, \(e^{3}\) value models only show what is offered, 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–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^{3}\) value model (Sect. 3). With the resulting value model, we can use existing tools to identify and prioritize fraud and misuse scenarios (see Sect. 4.1), as well as estimate the impact in terms of lost value, and potential gain in terms of misplaced value for the actors involved (see Sect. 4.2). This assists the decision making process by enabling quantification of risks, but is also useful for rationalizing coordination models (see Sect. 5).

2 Background

2.1 Business Process Modelling

Business process models describe sequences of activities in business units or organizations. 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 Process 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–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 constellation 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^{3}\) 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^{3}\) value approach, which recognizes the importance of the network of actors, and the idea of economic reciprocity in multi-transfer transactions.

In \(e^{3}\) 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^{3}\) 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 ingoing 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^{3}\) value approach is different from what is usually done in process models [20]. The most important differences are: (1) \(e^{3}\) value recognizes explicitly the notion of economic value, (2) \(e^{3}\) value has a modelling construct for the notion of economic reciprocity, and (3) \(e^{3}\) 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 \(e^{3}\) value, 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 asses 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^{3}\) 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 Sect. 4 we show how to use the resulting pair of models in fraud analysis and in Sect. 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 Fig. 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 Fig. 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).

Fig. 1.
figure 1

Ideal coordination model for setting up a new home Internet connection

Full size image

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 Fig. 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, Sect. 5.2] we omit modelling the payment as a cross-border message flow.

Fig. 2.
figure 2

Proposed derivation approach: solid boxes can be fully automated; dotted boxes require human decisions (underlined).

Full size image

3.1 Mapping Process Elements to Value Elements

Several BPMN concepts do have corresponding concepts in \(e^{3}\) value. Elements such as BPMN pools, swimlanes, start points and flows share semantic similarities \(e^{3}\) value actors, sub-actors, needs and value transfers. We propose the following mapping:

Pools to Actors: Instantiate every BPMN pool as an \({{\textsf {\textit{e}}}}^{3}\) value actor and every BPMN swimlane as a \({{\textsf {\textit{e}}}}^{3}\) value sub-actor.

Running Example: BPMN Swimlanes End-user and Provider are instantiated as \(e^{3}\) 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 \({{\textsf {\textit{e}}}}^{3}\) 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^{3}\) 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^{3}\) 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^{3}\) 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^{3}\) 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^{3}\) 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 Fig. 3a.

Fig. 3.
figure 3

Evolution of the derived value model for setting up a new home Internet connection

Full size image

3.2 Enriching the Value Model

Group Transfers: Per actor, reciprocal transfers which always occur together should be grouped as part of a single \({{\textsf {\textit{e}}}}^{3}\) 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 on-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^{3}\) 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 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^{3}\) 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^{3}\) 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 \({{\textsf {\textit{e}}}}^{3}\) 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^{3}\) 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 Fig. 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 \(e^{3}\) fraud [2]. Or, if we started out with a coordination model which includes fraudulent activities, we can do impact estimation using \(e^{3}\) value [3].

4.1 Fraud Assessment of an Ideal Coordination Process

In this section, we apply the \(e^{3}\) 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^{3}\) fraud toolFootnote 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.

Fig. 4.
figure 4

Highest ranked sub-ideal model generated by the \(e^{3}\) fraud tool from the model in Fig. 3b

Full size image

For instance, if we load the derived value model of our simple running example (Fig. 3b) into the \(e^{3}\) fraud tool, breaking transactionality by bypassing the only payment is – quite obviously – identified as the most damaging scenarios. Figure 4 shows the corresponding \(e^{3}\) fraud model, as generated by the \(e^{3}\) 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^{3}\) 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.

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 Sect. 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 Fig. 5.

Fig. 5.
figure 5

Manually created sub-ideal process model of setting up a new home Internet connection

Full size image
Fig. 6.
figure 6

Value model derived from the model in Fig. 5

Full size image

By applying the proposed model transformation steps, we end up with a corresponding value model of the fraud, as shown in Fig. 6. We can now evaluate this value model using the established \(e^{3}\) value profitability analysis [3] to estimate the profit made by the fraudster as well as the associated costs for the internet provider. Furthermore, we can apply extensions of \(e^{3}\) value aimed at analyzing sub-ideal value models – such as \(e^{3}\) 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 and demonstrate how it can be used to asses the potential for fraud in an existing non-fraudulent process as well as to estimate 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 Fig. 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.

Fig. 7.
figure 7

Ideal process model - roaming service

Full size image

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

Fig. 8.
figure 8

Ideal value model - roaming service

Full size image

Non-reciprocal Transfers: In the value model shown in Fig. 8, obtained by applying the proposed derivation method to the process model shown in Fig. 7, there is a transaction consisting of a single, non-reciprocal transfer: the Call[SERVICE].

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 Fig. 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 IMSIFootnote 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.

Superfluous Activities: Another result of the derivation of a value model from the process model in Fig. 7, is that one of the tasks - namely, Save call records was not identified as being part of a value transfer. Similarly, in Sect. 3.1 we did not map the Place order activity of Fig. 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 Fig. 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.