Value-Based Process Model Design

Commercial services are an important economic factor. In Europe, the service sector was estimated to be 71.3% of the GDP in 2015.¹ Many services are in fact electronic services. These services are ordered and provisioned via the Internet (Mohan and Ramesh 2003). Examples include e-banking, software-as-a-service and electronic Intellectual Property Right (IPR) clearing, the domain of our business partner in this research.

A commercial service assumes a network of participating actors. The network contains at least one supplier and a customer, but in more complex services, many suppliers are involved to satisfy a customer need. We call such a network of actors a value constellation (Normann and Ramírez 1993, 1994).

For electronic commercial services (e.g., Spotify, Netflix, etc.), which heavily rely on information technology, the accepted way of working is to produce requirement specifications and designs in terms of conceptual models (Mylopoulos et al. 1990; e.g., UML diagrams). We consider conceptual modeling as an useful way of working; not only to understand the required information systems and business processes, but also to design and evaluate the service value proposition of a constellation of enterprises and end users in terms of a value model. Therefore, our long term goal is to contribute a model-based design method supporting the development of commercial networked service value constellations, starting at the value proposition to the customer and ending with the enabling information technology.

This paper considers two specific modeling techniques: \(e^{3}\)value (Gordijn and Akkermans 2001) for understanding such service value constellations, and the quasi standard for business process modeling, the Business Process Modeling Notation (BPMN) (Owen and Raj 2003; OMG 2011) for designing business processes for constellations. Note that we have chosen BPMN for pragmatic reasons; since our findings are applicable to a wide range process modeling techniques, our contribution is agnostic with respect to the selected process modeling technique. The proposed method is also useful for value modeling techniques similar to \(e^{3}\)value, such as the Resource Event Agent (REA) ontology (Geerts and McCarthy 1999).

Although they model different concerns, the \(e^{3}\)value models and the BPMN models are strongly related. The \(e^{3}\)value model represents actors (suppliers and customers) exchanging things of economical value (service outcomes and money) with each other. The concern here is profitability. Profitability is assessed by calculating the net cash flow for all actors involved. In order for a value constellation to be sustainable, all actors in the constellation should be able to generate a positive net cash flow. In contrast, the business process model shows how the value model is put into operation, in terms of activities, their time order, and messages exchanged. The concern here is the control flow of operational activities, as well as the assignment of these activities to actors.

A key problem while using two different modeling languages to understand different aspects of a service studied is that potentially these models may overlap, or relate in a different way, thereby exposing consistency issues. The formal consistency relationship between \(e^{3}\)value and process modeling has been investigated by, e.g., Bodenstaff (2010). Another point of departure with respect to relating different perspectives on the same artifact is to consider how to derive one perspective, given the other perspective. In our case, this implies deriving the BPMN diagram, given an \(e^{3}\)value diagram. However, the current state of the art with respect to deriving a process model based on a value model is rather fragmented, and a well integrated method, usable by practitioners, is lacking.

This paper proposes an easy to understand, and integrated, step-wise method to develop a process model when a value model is given, bringing together earlier developed work by a number of researchers. The aim of this method is simplicity of use; which is the same philosophy behind the \(e^{3}\)value methodology. The method should be lightweight, easy to understand, and teachable, as service development projects are typically characterized by short time-to-market. We assume that the user of our method is a business development consultant with conceptual modeling skills.

To develop and validate the step-wise method, we employ the technical action research (TAR; Wieringa 2014) method. The TAR method (1) identifies a problem to be solved by a treatment (here: how to design a process model when a value model is given), (2) proposes a treatment (here: the step-wise method and (intermediate) models), (3) applies the treatment in a real-life context (here: intellectual property rights (IPR) clearing in the music industry), and (4) reflects on the treatment in the real-life context, with the aim of learning and improving.

This paper is structured as follows. First, in Sect. 2, we review the existing work on relating value models and process models, as we use this work to compose an integrated and easy to learn step-wise method to develop value-based process models. Section 3 introduces \(e^{3}\)value, the technique we use to represent value models. For process models we use BPMN, and we assume the reader is familiar with this technique. In Sect. 4 we present the TAR method. Hereafter, we discuss the step-wise method for deriving a process model based on a value model. Then, we apply the proposed method to our IPR business partner. In Sect. 7, we reflect on the use of our method and suggest changes and improvements. Finally, the conclusion and suggestions for future work are presented.

During commercial service development in value constellations, a number of activities have to be performed, and two of them are (1) developing the value propositions (what are we actually offering to whom, and what do we request in return), and (2) designing a process that provisions the propositions (as many services are in fact processes in terms of provisioning).

The traditional way of conducting business development is rather verbose, with ideas expressed in natural language. Using natural language as requirements specification language may result in a number of well known drawbacks such as noise (irrelevant information), silence (omission of important information), overspecification, contradictions, ambiguity, forward references, and wishful thinking (Meyer 1985).

A conceptual model-based method would mitigate these problems, and additionally, if the method allows for a graphical specification, communication with stakeholders is easier (Wiegers 1999). Moreover, conceptual models allow for semi-automated analysis. For example, an \(e^{3}\)value model (see Sect. 3 for a brief introduction) can be analyzed for a positive net cash flow for all actors involved, and a BPMN process specification can provide the groundwork for a simulation of the process at hand. Last, but not least, we argue that business development should start with a business value model, with an emphasis on model, and economic value. In many cases, business development starts with business process design immediately, thereby implicitly assuming value propositions. We claim that value proposition design should be a first class citizen in the design of service value constellations, allowing to assess promising propositions, and selecting the most interesting ones.

Taking two perspectives on a service constellation (namely a business value and business process perspective) carries the risk that both perspectives appear to be unrelated or even inconsistent with each other. To relate process models and value models, two view points can be taken: (1) considering consistency between both models explicitly, and (2) designing a process model when a value model is given, such that the process model puts the value model into operation.

Understanding consistency between both model types allows to conduct (formal) model checking between a particular value model and a process model. In Bodenstaff et al. (2007); Bodenstaff (2010), a framework is proposed to check and maintain consistency between a value model and the corresponding process oriented coordination model. The framework makes it possible to check business and coordination models on a structural model level, that is the specification of the value- and process models, but also on an instance level, namely the execution of the process in terms of a workflow management system. The notion of value model and process model instance deserves further explanation. Normally, an \(e^{3}\)value model describes, for a particular time period (e.g., a year), the net value flow. Using profitability analysis, net value flow sheets can be generated. These sheets show the expected profit, based on a number of variables (e.g., number of customers, pricing formulas, etc.), and are considered as a running instance of the value model. During the same period, the process instance runs, resulting in actors exchanging objects of value with each other. The economic results of a running process instance should ideally, for a chosen time period, match with the expected profits from the value model. Although consistency checking between value and process models provides some starting points for deriving process models from value models (e.g., by considering the consistency rules themselves), it is not an explicit design method which helps consultants to develop a process model for the corresponding value model. In fact, it supposes existence of both models already, whereas the design problem is to find a suitable process model that implements a value model.

In Schuster et al. (2010); Schuster and Motal (2009), a semi-formal mapping is proposed between the \(e^{3}\)value methodology, REA (Geerts and McCarthy 1999), and UMM (Huemer 2011). This method gives mapping rules, but acknowledges that sometimes mapping requires manual work.

Based on an analysis of previous work (Pijpers and Gordijn 2007a, 2008a; Weigand et al. 2006, 2007b; Wieringa and Gordijn 2005) we conclude that to transit from a value model to a process model, the following two questions should be answered:Trust motivations can influence the time ordering of value transfers, and therefore are of relevance to process models. For instance, a shop may require a payment in advance, before the shop actually delivers the products. We have studied trust issues extensively, see for instance Kartseva et al. (2009), and more recently Ionita et al. (2015). In order to represent solutions with respect to trust, we change the \(e^{3}\)value notation in such a way that time ordering of value transfers can be represented. We call the resulting model an \(e^{3}\)valuetrust model, as the model still only represents transfer of economic valuable objects and not topics such as message flows and control flows, which are common in process models.

The other important decision towards a process is the physical flow of value objects, and more specifically the distinction between the possession flow and ownership flow of objects. In the \(e^{3}\)value methodology, we are only interested in ownership, as a value transfer implies a transfer of ownership of products, or the transfer of the right to enjoy an experience in case of intangible services. However, in order to transfer ownership, a different physical possession flow of objects may happen. For instance, if we order a book at a web shop, a logistic partner will be involved. That logistic partner has physical possession of the book for some time, but does not own that book. The distinction between ownership and possession of an object has been acknowledged by a number of authors. In Weigand et al. (2007a), a value object is considered as a value transformation and the right to transfer a resource, whereas for the process perspective, the physical transfer is identified, which comes close to our notion of the physical possession flow of objects. We used the distinction between ownership and possession rights as an aid to develop process models in Pijpers and Gordijn (2007b), in a method called \(e^{3}\)transition. Here, ownership is defined “as the right to use and claim possession of the value object” [see also Snijders and Rank-Berenschot (2001) Pijpers and Gordijn (2007b)]. Also possession is identified as “the right to have actual (and if possible physical) possession of an object (Snijders and Rank-Berenschot 2001), but not to use the object” (Pijpers and Gordijn 2007b). We use both definitions extensively in our work. The physical flow of value objects is represented by an \(e^{3}\)valuepossession flow model.

Since the \(e^{3}\)value trust and possession flow models are just slight variations of the original \(e^{3}\)value model, these variants are easy to learn, assuming that the modeler already is experienced in designing \(e^{3}\)value models.

We briefly explain the \(e^{3}\)value technique using an educational example (see Fig. 1); for a more detailed overview the reader is referred to Gordijn and Akkermans (2001, 2003).

Legal, profit-and-loss responsible entities (both end-users and enterprises) are represented as actors and market segments. An actor is a single end-user or enterprise; a market segment is a set of actors who economically value things equally and is used to state that multiple actors of the same kind exist. In the example, there are many readers who want to read a book, precisely one book store, and multiple publishers.

Actors offer value objects to and request them from their environment. A value object is of economic value for at least one actor. In the example, value objects are: books, and money. Actors request and offer value objects via value ports, thereby abstracting from how these objects are delivered, which is the focus of business process design. Ports are grouped into value interfaces, which denote economic reciprocity and atomicity. Therefore, in the model, it is only possible to obtain a book while paying for it with money, and vice versa. Note that this presumes an ideal, honest world; in other words, actors do not commit a fraud. The focus of an \(e^{3}\)value model is on how value is offered, requested, and transferred in a network, and not on different kinds of deviations.

Finally, there is the notion of dependency path. Such a path starts with a consumer need, here the need to read a book. The actor (the reader) needs to exchange value objects via its value interface to satisfy such a need, in the example a book for money. The book store needs to exchange value objects, too, to deliver the book to the reader. In fact, the book store obtains the book from the publisher. The publisher has a boundary element, signaling that no further value transfers are considered. When to use a boundary element is a modeling decision. It could be argued that the publishers need paper and ink to print the book; if the modeler wanted to express this, additional transfers would be needed.

An \(e^{3}\)value model can be quantified, e.g., by stating the number of actors in a market segment, the number of consumer needs, pricing, etc. Tool support can then calculate the number of transfers, and the net cash flow for each actor involved.

There exist two other ontologically founded approaches for value-oriented business modeling: the Business Model Canvas (Osterwalder and Pigneur 2010; BMC), and the Resource Event Agent (REA) ontology (Geerts and McCarthy 1999). BMC has a single actor perspective, whereas \(e^{3}\)value and REA have a multi-actor perspective. Also, BMC is informal, and therefore cannot do tool supported analysis, specifically net cash flow calculation. REA and \(e^{3}\)value are quite similar although they have different origins. REA was developed as an ontology to represent the accounting domain, whereas \(e^{3}\)value was exclusively designed for business development. Ontologically, \(e^{3}\)value is richer in its constructs, for instance to represent dependencies between actors (dependency path), actor composition (actors having joint value propositions), multi-party (>2 actors) transactions, and value activities.

In Hevner et al. (2004), Design Science is framed as “the scientific study and creation of artifacts as they are developed and used by people with the goal of solving problems of general interest”. This paper addresses the problem of finding a suitable process model for networked value constellations when a value model is given. These artifacts can be methods (in our case the way how to develop process models based on value models) as well as models [the (intermediate) models, from value model to ultimately a process model].

There exist multiple research strategies to study the above mentioned artifacts. As argued in Sect. 2, already a considerable amount of ground work has been done on designing process models by using value models. However, these works are fragmented, and an integrated method to make these works for practitioners is missing. The aim of this research therefore is (1) to develop an easy to understand, step-wise method for deriving process models from value models, which can be followed by practitioners, and (2) to test this method in a real world setting.

To learn about a method in practice, Wieringa (2014) proposes the technical action research (TAR) method. TAR specifically focuses on the artifacts (developing process models using value models, and the models themselves), rather than on the problems in general, as many other research methods do. Therefore, TAR fits our research goals, namely to develop a method to derive process models from models (the artifacts), and to do so in a real-life context. The TAR cycle comprises (1) the problem statement, to be solved by a treatment, (2) the treatment design, (3) the usage of the treatment in a real-life context, and (4) the evaluation and improvement of the treatment.

The problem this paper aims to solve is how to design a process model for networked value constellations, with a given value model as input. The goal of the method is that it is (1) model based, cf. the accepted way of working in Requirements Engineering, and (2) usable by practitioners who have modeling skills (e.g., the UML). We assume that the practitioner is capable of designing \(e^{3}\)value networked business model himself; in other words, our method is not a recipe for developing \(e^{3}\)value models.

In our paper, the TAR method is further used as follows. Section 5 presents our treatment design, which is the step-wise method to derive a process model based on a given value model, as well as the required intermediate models. In Sect. 6, we apply the proposed treatment to a service value constellation whose activity comprises the clearing of intellectual property rights. Finally, Sect. 7 evaluates the treatment and suggests improvements to the step-wise method.

For the real-life context, we have selected a company that works in a networked value constellation, since value models are primarily intended for designing networked business models. Our selected business partner (hereafter called the IPR society) clears IPR on music for music users (radio and television, restaurants, etc.), pays right holders (artists, producers) for the use of their music, and uses information from radio stations for doing so. Since a number of different actors are involved in this process of rights clearing, these actors form a value constellation by definition.

Regarding validation and evaluation of our method, we have deliberately chosen the process of clearing international IPR, which we know very well. The same holds for the value model. This allows us to evaluate whether our method produces a process model that is close to the known reality.

The aim of this paper is to develop a step-wise method for the design of a process model using a value model for networked value constellations, making use of the existing research related to this problem (see Sect. 2). As explained, two different design decisions frequently occur in the literature:Our proposed treatment will be based on supporting the above mentioned design decisions. We design our treatment, the step-wise method, using an example which is easy to understand. The example networked value constellation consists of Customers, a Seller, a Carrier for handling logistics, and a Bank. The Seller is a web shop, and therefore needs a logistic provider to transport the product to the Customer. The Customer and Seller exchange a product (e.g., a book) for money, the Carrier provides a transportation service to the Seller and is paid for this, and the Bank provides payment services to the Customers and the Sellers and gets paid for service provisioning. The corresponding \(e^{3}\)value model is shown in Fig. 2.

We have carefully designed this example so that the example exhibits the earlier identified two design decisions while developing a process model with a given value model:The naive approach would be to, preferably automatically, translate the value model for the example at hand into a process model. However, we argue that a value model cannot be directly translated into a process model because many different intermediate design decisions are of relevance (Pijpers and Gordijn 2007b, 2008b). For instance, the time order of the value transfers and the physical flow of the value objects are very relevant to process models, but are simply not given in a value model, as the value model shows only dependencies between value transfers, without stating whether the dependee should occur before or after the dependent.

To arrive at a process model, with a given value model, we therefore consider trust issues between actors, as well as physical flow of value objects between actors. We represent these two considerations by means of two intermediate models, namely the trust model and the possession flow model.

To keep the complexity of our step-wise method to the bare minimum, the models used to represent solutions to trust issues and the physical value flow of objects, are models that are slight, and precise articulated variations of the \(e^{3}\)value models. As we assume that practitioners are already capable of developing \(e^{3}\)value models, we therefore expect that these practitioners can easily learn the required variations in the \(e^{3}\)value modeling language to deal with trust and possession considerations.

In sum, to create a process model, we propose to perform the following three steps: (1) create the trust model based on the inital value model, (2) create the possession flow model based on the trust model, and (3) create the process model based on the possession flow model. In the remainder of this section we discuss this step-wise method in more detail by means of the web shop example.

In line with the TAR method, we now apply the treatment as discussed in Sect. 5 to a real-life context. This real-life context in question belongs music intellectual property rights (IPR) clearing and distribution of so-called neighboring rights on music. This is a networked value constellation by nature, as many different actors are involved, and therefore suitable for our purpose. Moreover, there is already detailed knowledge about the existing processes and value models relating to neighboring rights management, which allows us to validate the produced process model by applying our treatment.

Our business partner is an IPR Society who focuses on the right to make music content public. Radio stations, restaurants, shops, etc., collectively referred to as right users, make music public (e.g., they play music on their premises/on the radio) and earn money while doing so (e.g., by advertisements, creating a good shopping atmosphere, etc.). The played music has right owners, for instance artists, producers, and sing & song writers. Right societies act as the intermediate party between right users and right owners: they collect money from music right users, and pay the collected fees to the right owners.

Our business partner, the IPR society, performs two value activities namely (1) clearance of music rights and (2) distribution of collected money to the right owners. In other countries, it is also possible that two different societies perform these two tasks. Clearance implies that the IPR Society collects fees from IPR users, e.g., restaurants and radio stations, on behalf of national and international IPR owners. The IPR Society provides the right to make public (RTMP) to the IPR users in return. Distribution entails that the IPR Society divides the collected fee between the IPR owners, such as artists and producers, based on how many times a music track is played by radio stations and other entities. To obtain play-list data, the IPR Society collaborates with a market research company, radio stations and IPR Sister Societies abroad (Razavian and Gordijn 2015).

The last step of the TAR method is (1) to evaluate the treatment, and (2) to improve the treatment based on this evaluation.

In this study, we proposed a step-wise method that enables to manually derive a process model from a value model. In this method the \(e^{3}\)value model is the point of departure. To represent the time order of the value transfers, which is not part of the \(e^{3}\)value methodology, we created a trust model. The next step in the construction of a process model is the physical possession flow of value objects. To this end, we introduced a possession flow model.

We illustrated our step-wise method with the aid of two online networked services of the intellectual property rights society, namely the right clearance and distribution over the IPR owners. The method as well as the constructed models were validated by the IPR society.

The method was tested with one elaborate field study, so further validation is needed. The method can be improved by allowing iterative development, as to our experience, value models and process models are developed side-by-side rather than in a sequential process. Additionally work on model-consistency checking can be integrated with our method, to enable formal consistency checking between value models and process models in every stage.

We believe our method is usable for practitioners, although we have not validated this explicitly. All models are constructed by the researchers, in close cooperation with the IPR society, cf. the TAR method. Extensive validation of the method is a topic of research. However, the \(e^{3}\)value itself has already a standing tradition and is used in the field. Since the intermediate models for trust and possession are very close to \(e^{3}\)value, we expect that the method should be usable for practitioners.