In this paper we discuss the problem of how to go from a business model to a process model in a systematic way. Business models are economic models used for business analysis, while process models capture low-level business activities and their coordination. We propose a method that starts with a business model where the main actors and their relationships are identified. This forms a basis for design of a final process model. Processes are described in terms of patterns stored in a pattern library.
In e-commerce it is possible to identify two basic types of models: business models
and process models. A business model focuses on the what in an e-commerce system,
identifying agents, goals, resources, and exchanges of resources between agents.
Thus, a business model provides a high-level view of the activities taking place in
ecommerce. A process model, on the other hand, focuses on the how in an e-commerce
system, specifying operational and procedural aspects of business communication.
Although different, business and process models are interrelated as the correctness
and quality of a process model depends on its ability to support a business model.
Two questions arise in the context. First, how can we be sure that an operational
process does support the goals and exchanges specified in a business model? This
question has been discussed in [
We propose a method for addressing the second question by starting from a
business model and arriving at a process model by using patterns from a process library.
As suggested in [
The business model formalism that we use in this paper is that of e3-value as
proposed in [
In the next section we describe our method which is followed by a deep analysis of the use of process patterns in Section 3. Section 4 contains some concluding remarks and future research.
In order to design a process model supporting a business model, we need to
analyze in more detail the structure of value exchanges and value objects [
Another component of a value exchange is transferring the custody of the resource being exchanged from one actor to another. An actor has the Custody of a resource if he has immediate charge and control of the resource, typically physical access of the resource. If an actor has the custody of a resource, this does not mean that she has any rights on the resource. For example, a distributor may have the custody of some goods, but he is not allowed to use the goods in any way. Providing custody of a resource is essential in a value exchange, as the buyer is typically unable to exercise the rights she gets unless she has custody of the resource.
A value exchange may also include the transfer of some evidence document that certifies that the buyer has certain rights on a resource. A typical example of an evidence document is a movie ticket that certifies that its owner has the right to watch a movie. Summarising, a value exchange can be seen as combining four components: - The resource being exchanged from one actor to another, e.g., a book - The right that the buyer obtains on the resource, e.g., the ownership of a book - The custody of the resource, e.g., the delivery of a book to the buyer - The evidence document, e.g., a ticket While the first two components, the resource and right, always are included in a value exchange, the last two components are optional. For example, when buying a piece of land, the buyer is typically not given the custody of that resource. Clearly, evidence documents are not always provided in a value exchange. Furthermore, the provision of custody and evidence documents may be so trivial that it is not of interest to make them explicit.
The analysis above will give a basis for the initial steps of the proposed methodology. The starting point is an e3-value model, which we extend by introducing elements corresponding to the components of value exchanges. In Fig. 1 rectangles represent actors and arrows represent value exchanges.
Step 1: Consider an e3-value model (see Fig. 1).
Step 2: For each value exchange, determine whether the custody component of the value exchange exists and shall be modelled explicitly. If so, add one or more arrows to the model that represent transfers of custody from one actor to another.
This step can be viewed as “factoring out” the custody component of a value exchange and modelling it explicitly by additional flows in the model. It should be noted that several actors may be involved in transferring the custody from one actor to another. This is illustrated in the extended model in Fig. 2a, where the custody of a painting is first transferred from the producer to the distributor and then from the distributor to the customer (flows for custody are dashed).
Step 3: For each value exchange, determine whether the evidence document component of the value exchange exists and shall be modelled explicitly. If so, add one or more arrows to the model that represent transfers of evidence documents from one actor to another.
Analogously to the step for custody, this step can be viewed as factoring out the evidence document component of a value exchange. Also in this case, several actors may be involved, e.g., when a ticket office supplies tickets on behalf of other service providers. In Fig. 2b, the transfer of the owner certificate of a painting is made explicit (flows for evidence documents are dotted). Step 4: Identify a set of processes based on the extended e3-value model from Step 3 and the Open-EDI transaction phases described in Section 1. a) For each value transaction, one negotiation process is added b) For each arrow in the extended model, one actualization process is added c) For each arrow in the extended model, optionally one post-actualization process is added
The following processes will be identified based on the extended e3-value model in Fig. 2 (The nomenclature is Custody when discussing physical goods and Access when discussing services): Negotiation process for Painting, Negotiation process for Transport, PaintingCustody2Distributor, PaintingCustody2Customer, TransportAccess2Supplier, Money2Supplier, Money2Distributor, Painting2Customer, Transport2Supplier and EvidenceDoc2Customer.
The above steps only concern the identification of flows relating the actors, which gives a set of processes. The following step concerns the design of the resulting processes. For this end we make use of a library where processes are described in terms of patterns. A pattern contains information about properties that characterize sets of processes. For example, a pattern may characterize a process as involving three actors and to be secure.
Step 5: For each process, select a pattern based on the resource managed by the process and the goals of the actors (for details on this selection procedure, see the next section). Apply the selected pattern to the set of identified processes.
Applying a pattern to the set of identified processes will result in specifying the internal structure of a process or relating processes to each other. In some cases, a process is not retained but replaced by two or more new processes related to one or more added actors. For example, a payment process between a buyer and a seller can be restructured to include an intermediate additional actor (a bank) that participates in new processes with both the buyer and seller. Application of patterns with this effect means that the structure of the business model is also changed. In the following section we elaborate on the concept of pattern and illustrate the use of a pattern library.
Patterns can be described from different points of view. From a model designer’s
perspective, they are off-the-shelf business processes that can be linked and chained
up to build more complex, end-to-end transactions. The UN/CEFACT Unified
Modelling Methodology [
In business terms, patterns can be considered as instruments to achieve business goals. Let us consider the example in Fig. 5: A Supplier receives a purchase order from a Customer. Instead of invoicing the Customer after the goods’ delivery, he sells his claim on the order value to a Factoring Partner who pays him 80% of the value of the claim’s value upfront before he collects the money from the Customer. This pattern solves several business purposes: ! For the Supplier, it fulfils a financing function as he receives his money upfront. It also relieves him from the burden to collect his money from the Customer. Whether there’s a delay in payment or the Customer goes bankrupt, he can be sure to have 80% of the total order value. ! For the Factoring partner, he can either make a profit of 20% of the order value or loose 80%. In order to reduce his risk exposure he would want to engage only in the business with the Supplier, if the latter contracts him on a regular basis. Given such a business case, we can derive the commercial conditions for the use of our Factoring pattern: there need to be a Supplier who has regular trade with a Customer and wants or needs – due to either a requirement for financing or because he perceives the risk of non-payment with regards to the Customer in question as rather high - to mitigate all payment-related risks by involving a Factoring partner. Furthermore, the profit margin must be higher than 20 % in order to obtain an economically sound Factoring solution.
Generally speaking, we can associate all patterns with their business characteristics so as to find the best pattern for any given business situation, and to evaluate the pattern’s feasibility with regards to the business goals of the firms involved. There are four categories of pattern characteristics: ! The collaboration phase it refers to. Some patterns (e.g. business processes for price negotiations) apply to one collaboration phase of the Open-EDI model, while others are more generic. ! The type of resource used in a business exchange. Patterns that can be used to mitigate payment risks are in most cases not suited to deal with information exchange or the transport of physical goods or services. ! Contractual characteristics: - Patterns have specific characteristics with regards to their ability to manage risks. While some patterns put all risks on a single business partner, others do balance risks among the firms involved. An example of the latter is a letter of credit. A specific aspect is the moment (and hence the risks associated with) when the transfer of title on a resource passes from the seller to the buyer. - Patterns can be described in terms of their cost allocation behaviour. Many patterns, among which we find the Incoterms, define which party needs to pay which part of the value creation activity. ! Process characteristics. This category subsumes the practical concerns related to the execution of the business process the pattern describes: process efficiency, duration as well as administrative and technical complexity of execution. For each of these categories, there is a range of possible values, and each vector of values (instances) maps onto a set of patterns that would fit the requirements.
In this paper we have discussed the problem of how to go from a business model to a process model in a systematic way. A method is proposed that starts with a business model where the main actors and their relationships, in the form of value exchanges, are identified. In a number of steps, each value exchange is analysed and identified as a sub-process that is to constitute the final process model. When analysing value exchanges between business actors, we consider them as consisting of components, which we call resource, right, custody, and document evidence. Each separate component motivates a sub-process in the process model, and consequently a modeller should decide whether to treat a value exchange as a unit or factor out one or several of its components. Using a set of criteria, identified sub-processes are matched with the complete process descriptions described in form of patterns stored in a library. Use of the patterns enables a fast, module-based process design and stipulates the alignment between the starting business model and the process model.
Future research also involves investigations on how to properly use a pattern library in this context. For instance, should the current content in the library decide the design of the process model, or should the pattern library be used for validation purposes when the modeller is finished, or both. Another topic for future research includes further identifying and describing the dependencies that exist between processes. These dependencies are expected to be useable means of deriving and facilitating the selection of appropriate candidate patterns for implementing a particular relationship, and consequently increase the quality of the resulting process model.