# Designing an Ecosystem Value Model Based on a Process Model – An Empirical Approach

Isaac Torres, Jaap Gordijn, Marcelo Fantinato, Joao Vieira

► To cite this version:

Isaac Torres, Jaap Gordijn, Marcelo Fantinato, Joao Vieira. Designing an Ecosystem Value Model Based on a Process Model – An Empirical Approach. 13th IFIP WG 8.1 Working Conference on the Practice of Enterprise Modeling (PoEM 2020), Nov 2020, Riga, Latvia. pp.293-303, 10.1007/978-3-030-63479-7_20. hal-03434655

HAL Id: hal-03434655

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

Submitted on 18 Nov 2021

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
# Designing an Ecosystem Value Model Based on a Process Model – An Empirical Approach

Isaac da Silva Torres¹³, Jaap Gordijn¹, Marcelo Fantinato², and João Francisco da Fountoura Vieira³

¹ Vrije Universiteit, Amsterdam 1081 HV, Netherlands
{i.dasilvatorres,j.gordijn}@vu.nl

² Universidade de São Paulo, 03828-000, São Paulo, SP, Brazil
m.fantinato@usp.br

³ Universidade Federal do Rio Grande do Sul, 90040-060, Porto Alegre, RS, Brazil
joao.francisco@ufrgs.br

**Abstract.** Ecosystems have both inter-organizational process models and corresponding business value models. Whereas process models show *how* actors interact in terms of message flows and the time-ordering of activities, business value models present *what* is exchanged of economic value and abstract away from operational activities and their control flows. As organizations usually have process models but not explicit value models, we propose to derive a value model from a process model. We hypothesize on how these two models conceptually correspond to each other. We employ a real-world case to verify our hypotheses and learn about the applicability of the proposed design.

**Keywords:** Ecosystems · Value model · Process model.

## 1 Introduction

An ecosystem is ‘a collection of companies that work cooperatively and competitively to satisfy customer needs’ [6]. We argue that at least two model perspectives are needed to develop such ecosystems: (1) the value model, and (2) the inter-organizational process model. The value model shows how entities earn money (in the case of companies) or increase their economic utility (in the case of end-users). The focus is on the creation, distribution of things of economic value such as products or service outcomes. An example of a value modeling language is *e³value*. The inter-organizational process model shows the sequence of interactions between parties, e.g., in terms of message flows. Usually, these interactions have an operational flavor, such as message flows in the Business Process Modeling Notation (BPMN).

Although *e³value* and BPMN models represent the same ecosystem, their semantics differ significantly. For example, an *e³value* model shows economic reciprocity (e.g., what is offered by someone of economic value to its environment and what is requested in return), whereas such reciprocity in a BPMN
model can at best only be seen by carefully analyzing the control flow. Moreover, an *e<sup>3</sup>value* model has no explicit time-ordering, whereas a BPMN model has extensive constructs for this.

As *e<sup>3</sup>value* and BPMN models are related somehow, in the past, research was done to elicit a BPMN model given an *e<sup>3</sup>value* model. Previous research was based on the idea that first, an *e<sup>3</sup>value* model is designed and thereafter, a BPMN model. In situations where a new ecosystem has to be designed, this is often the case. However, in many cases, the ecosystem already exists (sometimes for a very long time), and there is a need to understand, redesign, or analyze that ecosystem. Usually, the *e<sup>3</sup>value* model was never made explicit (as a conceptual model), but in quite some cases, there is a BPMN model.

In this paper, we explore if we can use an existing BPMN model to design the corresponding *e<sup>3</sup>value* model. For that purpose, exploratory technical action research is undertaken (Sec. 2). First, we set some qualitative hypotheses to be explored (Sec. 2.2). We work with a Brazilian centennial institution, which provided us with real-life BPMN models of one of its main processes (Sec. 2.3). By refining these BPMN models with a few rounds, we tried to derive its corresponding *e<sup>3</sup>value* model and present our lessons learned (Sec. 2.4). Finally, we present our discussion and future work (Sec. 3).

## 2 Technical Action Research: A Research Instrument for Design Science

Design Science is a research activity where the interest lies in artifacts that improve a given problem in terms of a (partial) solution (e.g., finding a suitable *e<sup>3</sup>value* model when a BPMN model is given) [3, 8, 9]. In our case, this concerns how to develop an *e<sup>3</sup>value* model from a BPMN model.

Wieringa and Morali [9] propose the technical action research (TAR) method in which researchers learn in practice about a specific technique. TAR mainly focuses on the artifacts (developing an *e<sup>3</sup>value* model using a BPMN model, and each model individually). In this paper, we use a case from a Government Institution (GI) in Brazil, which has, in the past decade, changed its management to a process-oriented view. We choose this case because the BPMN models are known and available, but an *e<sup>3</sup>value* model is lacking. In this particular case, we focus on the process of Research Project Contracts. We extend TAR with the notion of ‘exploration’ and call this ‘E-TAR’. Although there is a body of work how to relate value models and process models, we do not know very well yet on how to design an *e<sup>3</sup>value* model given a BPMN model. We use exploration to understand the problem of how to come from a BPMN model to an *e<sup>3</sup>value* model better. The TAR cycle consists of the problem statement (1), to be answered by treatment, the treatment design (2), the experimentation of the treatment in a real-life context (3), and the evaluation and improvement of the treatment (4). This section, therefore, is organized as these four steps.

We assume that the designer of the *e<sup>3</sup>value* model based on the BPMN model is familiar with both BPMN and *e<sup>3</sup>value* models; i.e., our approach is not a
recipe for understanding or developing either of the conceptual models. In fact, the approach refers to on how to come from a BPMN model to an *e³value* model.

## 2.1 Problem Statement

The *e³value* model represents actors exchanging things (*what*) of economic value (products, service outcomes and money) with each other, i.e., the concerns are financial sustainability of each individual actor [4]. In contrast, the BPMN model shows *how* the *e³value* model is put into operation, in terms of activities, their time order, and how information is exchanged, i.e., the concern here is the *message flow* of tasks [2]. This flow of information throughout operations transforms inputs into outputs delivering *how* the process behaves. Note that in *e³value*, the notion of ‘time’ is completely absent, except the idea of ‘contract period’, which states that an *e³value* model is valid for a particular time period. There are many more differences between *e³value* and BPMN models in general, many of them are highlighted in [2].

We argue that creating an *e³value* model based on a BPMN model should not be seen as a mere translation or (mechanical) modeling problem between both models. The semantic differences between models are too significant to allow for a straight-forward modeling approach. Consequently, we consider the process of coming from the BPMN model to an *e³value* model as a *conceptual design process* during which many design decisions need to be taken. Although a sort of compiler that translates *automatically* a BPMN model into an *e³value* model would be desirable by many, we do not expect that this is feasible. In sum, the problem to be solved can be phrased as follows: ‘how to *design* an *e³value* model based on a given BPMN model’.

## 2.2 Treatment Design: From Value Model to Process Model

We suppose a BPMN model as a starting point. Therefore, the BPMN modeling step itself is outside the scope of our work. In contrast, our research provides steps on how to build an *e³value* model from a given BPMN model. We have formulated a set of hypotheses in Table 1 that might be useful to find an *e³value* model given a BPMN model, which are inspired by [1].

<table><caption>**Table 1.** BPMN model and *e³value* model correspondences.</caption><thead><tr><td>ID</td><td>Hypothesis description</td></tr></thead><tbody><tr><td>H1</td><td>Pools and lanes may correspond to actors and market segments</td></tr><tr><td>H2</td><td>Message flows may correspond to value transfers.</td></tr><tr><td>H3</td><td>Start, intermediate, and end events may correspond to consumer needs, value objects, and boundary elements, respectively.</td></tr><tr><td>H4</td><td>Tasks/Activities and sub-processes may correspond to value activities.</td></tr><tr><td>H5</td><td>Gateways may correspond to dependency elements value interfaces, and value ports.</td></tr></tbody></table>
Note that we phrase our hypotheses in terms of ‘may correspond’. This is because we expect that in some cases the correspondence is there, but sometimes not. This is caused by the different semantics of these constructs in *e<sup>3</sup>value* and BPMN models. Moreover, the correspondence not necessarily is one-to-one. It might be very well the case that e.g., a *set* of message flows corresponds to one value transfer. The hypotheses are as follows.

H1 *Pools and lanes are candidates for actor and market.* Sometimes, a pool/lane element in a BPMN model may be designed as a source of profit – an actor/market – in an *e<sup>3</sup>value* model. Changing the perspective of *how* things are done to *what* value is being exchanged is challenging when designing an *e<sup>3</sup>value* model from a BPMN model. A BPMN model often does not explicitly externalize *what* exactly is being traded between two or more actors (e.g., it often shows only one side of the economic trade). Its job is to show *how* the operation is done. For example, the resource pools/lanes in a BPMN model are indicated for purposes such as resource allocation and scheduling. However, in an *e<sup>3</sup>value* model, we distinguish actors to facilitate reasoning about adding economic value and profitability. Therefore, actors are not individual resources performing activities, but cost-effective and legal entities that engage in business transactions. The question that arises is how exactly they relate, i.e., does every pool/lane result in an actor, does one pool/lane result to precisely one actor, or may one pool/lane have *multiple* instances in terms of *e<sup>3</sup>value* model actors and thus should be a market segment?

H2 *Message flows may correspond to value transfers.* Value transfer is a concept inside *e<sup>3</sup>value* modeling in which actors/entities exchange something of economic value. In BPMN models, the only way that two different entities can communicate is via message flows. This element is responsible for carrying the inputs (information, resource, objects, etc.) from one pool to another. However, differently than in the *e<sup>3</sup>value* model technique, in BPMN models, a pool needs to *possess* the resource to fire the corresponding message flow. However, *possession* is different from *ownership* (see e.g., [7]). For example, a logistic party may possess a resource for a while but never owns it. However, communication about a change in ownership can be modelled with a BPMN model, e.g., by means of a message flow. This is because BPMN models map how the information is delivered, i.e., inputs are consumed and exchanged as the process is being executed. Since there can be *many* message flow connectors in a BPMN model, when designing a corresponding *e<sup>3</sup>value* model, it is important to find which message flow(s) represent the actual transfer of value between actors, i.e., this is often not a one-to-one relation.

H3 *Start, intermediate, and end events may correspond to consumer needs, value objects, and boundary elements, respectively.* The event element allows representing a state transition that was consumed or transformed by the activities and takes place instantly in a process, i.e., without duration. Events elements are the starting point for discovering in an *e<sup>3</sup>value* model what the consumer needs are, how many value objects are transferred between actors/markets, and whether the transfers do (not) result in other transfers. Although events
need to yield value to someone to be considered as a value object, this guide-
line relates to **H2** since message flows can only be exchanged between pools
(actors/entities) and their respective message events and tasks.

H4 *Tasks/Activities and sub-processes may correspond to value activities.* While BPMN models’ tasks/activities and sub-processes describe an operation as how to produce outputs given some inputs and resources (timed and sometimes with no intrinsic business value), a value activity is only distinguished if they are profitable for the performing actor/market segment. The main reason for this is that in an *e³value* model we want to address the important design decision which adds value (and hence can make a profit) by performing which value adding activity. For example, whether to outsource activity or not is such a decision; outsourcing is only possible if someone else can perform that activity in an economically sustainable way.

H5 *Gateways may correspond to dependency elements, value interfaces, and value ports.* Gateways in BPMN models are used to show deviations on the process sequence flow. In *e³value* models, there are similar constructs, namely AND, OR, cardinality dependency elements, and value interfaces. These elements can only be used inside an actor, market segment, or value activity, to represent how customer needs, or value transfers with one party, can result into transfers with other parties. One factor that complicates matters here is the notion of ‘economic reciprocity’ (“one good turn deserves another”), which is fundamental for each *e³value* model. The ‘value interface’ represents economic reciprocity: it should contain at least two opposite directed transfers, and both transfers should happen, or none at all. This notion of economic reciprocity is one of the reasons why an *e³value* model is so different from a BPMN model.

**2.3 Treatment: The Real-World Case Scenario**

Our case is a Brazilian centenary institution. They operate in an ecosystem whose goal is to consume and produce knowledge. In Fig. 1, the Research Project Contracts process is detailed in a BPMN model, and various areas of the model were marked and labeled with hypotheses identifiers. This is to keep track of where precisely the hypotheses were confirmed or not. Please note that mainly the centenary institution is modeled in detail; the rest is modeled only with the purpose to provide information for the institution’s point of view. We acknowledge that it would be better to have all the information from all actors, which is a subject for further research.

The process refers to the signing of agreements between the GI (university), a Research Finance Support Agency, and an external Research Partner (company) to develop a research project. The research partner is the project contractor; the GI executes the project through its researchers (e.g., professionals, students, etc.); and the support agency acts on the financial part of the agreement.

The process is then divided into three stages: initial processing (signing of
the agreement), execution, and accountability. The signing of the contract cov-
ers all steps, from the opening of the project by the coordinator (researcher)
<figure><img src="image_2.png" /><figcaption>Fig. 1. BPMN model of the case with applied hypotheses identifiers</figcaption></figure>
until the legal instrument that settles the agreement, including all instances of
approval. After signing the contract, the project is ready to be executed. The
research partner transfers the funds from the contract to the support agency
that implements the contracting and payments of the project. The coordinator,
together with his team, carries out the requested research. Necessary changes
to the agreement may occur, such as an extension of the term or composition
of the research team. Finally, after the research project is finished, accounts are
given about the use of the funds transferred, and the project is carried out.

We then tried to construct the corresponding *e³value* model using the hy-
potheses mentioned in Sec. 2.2. The proposed *e³value* model is illustrated in
Fig. 2. The Research Partner is the process customer and is modelled as a market
segment since there are many of these partners. The Research Finance Support
Agency (also a market segment) is responsible for handling the payments done
by the Research Partner because the GI, due to laws, cannot directly take money
from the sponsor. There can be many GI's; hence they are market segments in
the *e³value* model. Finally, we have added the ‘Customers’ market segment to
reflect that Research Partners need income in order to finance research.

<figure><img src="image_3.png" /><figcaption>Fig. 2. *e*<sup>3</sup>*value* model as designed and based on the BPMN model</figcaption></figure>

The *e<sup>3</sup>*value* model have six value transfers that were found from the com-
bination of message flow and event elements in the BPMN model. They were
difficult to track since not all flows represented a change of ownership. Our op-
tion was to take the message flow elements that were linked to an event, which
was also corresponding to a value object (money (x2), products, executables,
personnel, and project results), to judge which one was going to be designed in
the *e<sup>3</sup>*value* model, and which one was going to be disregarded.

The GI performs one value activity: ‘execute project’ – which should attract
everything that is necessary to perform the project (e.g., infrastructure). Most of
the activities and sub-processes in the BPMN model were of no use when aiming
at the *e<sup>3</sup>*value* model; they were defined in operational terms and not in terms of
value adding potential. In an *e<sup>3</sup>*value* model, we are only interested in activities
that can add value and are profitable. The value activity ‘execute project’ by the
GI was originated after the ‘income repass’ from the Research Finance Support
Agency. Further investigation should be made in order to clarify if the activities
in the BPMN model always precede a value activity in the e³value model.

The OR/AND dependency element in the *e<sup>3</sup>value* model represents that not all cash flow that enters the Research Partner (through the selling of its products) is expended on ‘research’. Although this may seem simplistic, it maintains the value interface principle and was not shown by the BPMN model.

The *e<sup>3</sup>value* model can be summarized via an example, e.g., an Energy
Provider company that wants to discover new ways to find clean energy. The
GI proposes a solution in the form of a project to which the Energy Provider
agrees. However, to repass any monetary amount to the GI in order to accom-
plish the project, the Energy provider needs to send the money to one or some
Research Finance Support Agencies (market) so that it can execute the value fi-
nancially and return what the GI needs (e.g., technology, infrastructure, devices)
to accomplish the consumer’s (Energy provider) need.

## 2.4 Treatment Evaluation: Observations extracted from the case

We now review our a-priory defined hypotheses based on the execution of the
treatment: the design of the *e<sup>3</sup>value* model by using a BPMN model as input.

L1 *Pools and lanes are candidates for actor and market segment.* Pools can be included as an actor/market with the same name in the *e<sup>3</sup>value* model. Although, distinguishing them between actor or market segment would not be possible without the BPMN model description knowledge, i.e., knowing that the GI's all do this process in the same way. We learned that the relation between pools to actor/market is not a one-to-one relation. Although this is a matter of interpretation, we could argue that this model is made from the viewpoint of the GI and the GI should map onto an actor and not a market segment. However, as in Brazil GI's are not entitled to receive direct funding of customers, the construction in the BPMN model and *e<sup>3</sup>value* model is often used by other universities, hence the GI is a market segment. There was also an actor/market that did not appear in the BPMN model as a pool/lane. The Research Partner's *Customers* were not part of the BPMN model but were essential to maintain the balance in cash flow of the Research Partner. Unfortunately, we were unable to associate the element lanes in BPMN models to any other element in the *e<sup>3</sup>value* model. This might be because they usually allocate *where* a series of activities should be place in the BPMN model, representing a role (e.g., departments); which has no direct related construct in the *e<sup>3</sup>value* model. In some cases, a lane may relate to a value activity, as this can be interpreted as a value-adding role.

L2 *Message flows may correspond to value transfers.* We used the flows of information related to deliver something of importance, flows which change the course of the process drastically, as candidate value transfers in the *e<sup>3</sup>value* model. For this, the events from the BPMN model were transformed into
value objects in the *e³value* model, and served as a compass to define the exchange of ownership from one actor to another. However, due to the lack of information on the other actors of the BPMN model, the message flows were sometimes connected straight to the pool element, indicating that something went in (e.g., information input), but not necessarily added value. In these cases, as we did not know what exactly was exchanged, we disregarded them when designing the *e³value* model. The value transfers occurred between the Research Partner and their Customers were not derived directly based on the constructs in the BPMN model, but through our interpretation. The relation between these two constructs was confirmed as not a one-to-one relation.

L3 *Start, intermediate, and end events may correspond to consumer needs, value objects, and boundary elements, respectively.* Events were more constant when trying to design from one model to the other. Although changing the names was not very reliable, small changes were made (e.g., 'monthly income' to 'money'). However, it was interesting to see that each event was a mark of a value tree (or value chain), but only those with message flows attached were transferred to the *e³value* model. Not all start and end events corresponded to a consumer need and a boundary element in the *e³value* model. This was because there were some of these elements that were only inputs and outputs to control the information flow, and not necessarily added relevance in the model. We can then conclude that events are not a one-to-one relation when designing an *e³value* model based on a BPMN model.

L4 *Tasks/Activities and sub-processes may correspond to value activities.* We were able to translate one value activity from the various activity elements in the BPMN model, the process activity 'execute project' was used. To get to this value activity, we looked inside the execution phase described in the BPMN model. We observed that most of the (sub-)activities from the BPMN model were of no use to the *e³value* model. However, the BPMN model activity 'execute project' is the first, and only, to receive an input of economic value – 'income repass'; and hence the process becomes economically viable.

L5 *Gateways may correspond to dependency elements value interfaces, and value ports.* This hypothesis was not confirmed. We were unable to empirically find the link between these constructs. Although gateway elements were present in the BPMN model, none of them translated to AND/OR dependencies of the *e³value* model. A reason would be the lack of frequent gateway elements (or gateway types) in the BPMN model, which might have compromised further investigation. The second reason would be the lack of detailing in the BPMN modeling. There was insufficient information from the Research Partner to extract the information from the BPMN model.

## 3 Discussion and Future Work

We analyzed the relation between the elements of BPMN models and *e³value* models in a selected real-world case scenario. We manually analyzed how each element in the BPMN model, addressing the operation of Research Project Con-
tracts, would relate when applied to the *e<sup>3</sup>value* model perspective. The goal of our analysis was to study our hypotheses described in Sec. 2.2 and learn from it.

Much information about the value transferred may have been lost. This was an issue when creating the *e<sup>3</sup>value* model as the customer is not detailed in the BPMN model at all (only the GI's perspective was considered). Our results show the process modeling perspective affects the design transition in general. It is known that BPMN provides many ways to model a process (even with best practices [5]). In our case, the modeler assumed the customer (Research Partner) as a 'white box' (i.e., only the trade of information is showed), which led us to not find, for example, the 'Customers' market segment in the *e<sup>3</sup>value* model.

This work is in its early stages, and our current hypotheses findings are based on a single real-world case scenario. Hence, this research cannot be a basis for generalization. This was also not the goal of this research; the goal was exploration mainly. We need to refine and validate our hypotheses by doing more real-world case studies.

We glimpse some future steps for our research. First, we can try to relate how each process activity may cooperate to the earnings of a company when designing from a BPMN model to the value activity in the *e<sup>3</sup>value* model. This would allow us to perceive the benefits of having the value perspective even when modeling in an operational level. Second, our approach can help track the value constellation of business processes and their contribution to stakeholders goals. If we can apply this approach more often and from a broader research perspective, we can also derive patterns from it. Finally, our plan is to come up with a method to support the co-creation of BPMN and *e<sup>3</sup>value* models.

## References

1. Bodenstaff, L.: Managing Dependency Relations in Inter-Organizational Models. Ph.D. thesis, University of Twente (2010)

2. Gordijn, J., Akkermans, H., van Vliet, H.: Business modelling is not process modelling. In: Int'l Works. on Concep. Modeli. Approac. for E-Busin. pp. 40–51 (2000)

3. Hevner, A., March, S., Park, J., Ram, S.: Design science in information systems research. MIS Quarterly: Management Information Systems 28(1), 75–105 (2004)

4. Hotie, F., Gordijn, J.: Value-based process model design. Bus. Inf. Syst. Eng. 61(2), 163–180 (2019)

5. Mansar, S.L., Reijers, H.A.: Best practices in business process redesign: Validation of a redesign framework. Comput. Ind. 56(5), 457–471 (2005)

6. Moore, J.F.: The Death of Competition: Leadership and Strategy in the Age of Business Ecosystems. Harper (1996)

7. Pijpers, V., Gordijn, J.: Bridging business value models and business process models in aviation value webs via possession rights. In: 20th Annual Hawaii Int'l Conf. on System Sciences (2007)

8. Recker, J.: Scientific Research in Information Systems – A Beginner’s Guide. Springer (2013)

9. Wieringa, R.J., Morali, A.: Technical action research as a validation method in information systems design science. In: 7th Int'l Conf. on Design Science Research in Information Systems. pp. 220–238 (2012)