Value-Driven Business Service Modeling

Zhongjie Wang1 and Yves Ducq2

1 School of Computer Science and Technology, Harbin Institute of Technology, China
2 IMS, University of Bordeaux 1, France

Abstract: To ensure that the service system to be implemented is closely aligned with the value
proposition expected by customers, this research presents a new business service modeling
approach by combining philosophy of model driven approach and a value modeling. In this
approach, value is considered as a key driven element to guide the model process and to ensure the
links between models at the various modeling levels. Value proposition combining state-transition
based functionality expectation and constraint based QoS expectation is firstly identified from
customer survey, then the service value network is established by identifying a set of potential
service partners and their value exchange relationships. Based on that, a decision and process
combined business service model (BSM) is constructed, and then value is annotated to the
activities in BSM to help check the value realizability in BSM. Performance indicators of BSM
are also connected with the QoS constraints in value propositions. After, BSM is transformed into
technical-level model by service composition approach. We will give the meta-model and
modeling framework for above idea, and shows the detailed model specification of value
proposition, value network and BSM. The value annotation method will also be shown. A case
study from cultural performance service domain is to be given to show the effectiveness of the
modeling approach.
Keywords: business service modeling; service value; value proposition; value annotation

1. Introduction
A service system is a kind of socio-technological system-of-systems integrating various types
of resources such as human, technology and shared information in different proportions. Roughly,
service systems are classified into software-intensive, product-intensive and labor-intensive ones,
and the combination of them.
Compared with a software system or a production system, the design of a service system is a
more complex engineering process, where requirements of various participants are gradually
transformed into executable implementations by approaches such as Model-Driven Architecture
(MDA) and service composition techniques. In this process, modeling is a pivotal step, and the
quality of service models determines to a large extent the quality of the final service systems.
From some typical cases, the ineffectiveness or low-effectiveness of service systems is
almost resulted in the deviation from the initial requirements of customers. The primary reason is
that, most service systems are developed solely by service providers who usually plan and design
the system around their own business. Such approach is feasible and rational if it is applied to a
production system because it is technology-dominant (i.e., there are not too much human-related
elements) and in the analysis and design phases it is comparatively easy to clearly identify all the
requirements which usually keep stable during the lifecycle of the system. But for most of the
services where “human” plays a central role, the participation of human and their dynamics, their
personalization, and the ambiguity of their requirements, all together lead to the situation that a
waterfall-style engineering process is extremely unsuitable to the corresponding service systems.
Periodic and active interactions with customers (and other participants) and intensive small-step
iterations are necessary to make service models and systems always keep high coherence with the
dynamic and flexible requirements.
In addition, there might be inconsistent and even conflicting requirements between various
participants in a service. To look for the tradeoff between these requirements is also an important
issue that is usually ignored in service engineering.
As service is defined as “a customer-provider interaction to co-produce value and share risk”,
value is considered as the ultimate goal of all the participants. From this point of view, “value”
could be utilized as a tool to drive the whole service engineering process, especially in modeling
phase, to help check whether the constructed service models support the production of the
expected values. If not, the model should be further improved, then the right models are to be
transformed to the lower technology-levels. In this way, expected values are always perceived in
the model-driven service engineering process.
Our objective is to link the business level represented by the value proposition model, with a
model driven approach (MDA), in order to obtain an implementation aligned with the customer
expectations. In this approach, value is utilized to guide the model process and to ensure the
coherent mappings between models at the various modeling levels in an MDA. To connect the
value and the business model and check whether the business model enable the value delivery is
the prerequisite of technology-level modeling and service system implementation.
This work is based on two existing service methodologies. The first is the Model-Driven
Service Engineering Architecture (MDSEA) based on MDA developed by OMG and MDI (Model
Driven Interoperability) developed in INTEROP Network of Excellence. MDSEA three-level
service modeling architecture named Business Service Model (BSM), Technology Independent
Model (TIM) and Technology Specific Model (TSM), and the corresponding model mapping
mechanisms from BSM to TIM, and from TIM to TSM.
The objective of a model driven approach is to separate the different preoccupations from a
business point of view of the product-service system to the technical preoccupations. So, an
engineering architecture specifies a framework (i.e. a conceptual structure) for engineering
activities, which provides a set of guidelines for structuring the specifications that are organized
around various abstraction levels.
The Model Driven Service Engineering Architecture (MDSEA) is inspired from MDA/MDI
(Model Driven Architecture/ Model Driven Interoperability).This methodology is proposed in the
frame of the MSEE project (MSEE, 2012) that defines its first Grand Challenge as making SSME
(Service Science, Management and Engineering) evolving towards Manufacturing Systems and
Factories of the Future,. MDSEA provides an integrated methodology dealing with modeling
languages at the various levels of abstraction to support Service models and Service System
design and implementation. The relationship between the MDSEA modeling levels (BSM, TIM,
and TSM) and the Service System lifecycle phases (user-requirements, design and
implementation) is established. One of the important innovations in MDSEA is to define the
integration between domains components (IT, Organization/Human and Physical Means) at the
BSM level in order to ensure that these integration aspects will be spread out at the other levels. In
this sense, this is therefore considered as an adaptation and an extension of MDA/MDI approaches
to the engineering context of product related services in virtual enterprise environment.
On the basis of MDA/MDI, the proposed MDSEA defines a framework for service system
modeling around three abstraction levels: BSM, TIM and TSM as presented in Figure 1.
Enterprise A Enterprise B
Business Services Models (BSM) Interoperability at Business Services Models (BSM)
the model level

Technology Independent Models (TIM) Technology Independent Models (TIM)

Organisation Physical Organisation Physical

IT IT
Human means Human means
Domain Domain
Domain Domain Domain Domain

TechnologySpecific Models(TSM) TechnologySpecific Models(TSM)

Generation of “components” Generation of “components”

( IT_ Organisation/ Human_Physical means ( IT_ Organisation/ Human_Physical means

Services in virtual enterprises Services in virtual enterprises

(IT Applications, Processes, Products , Interoperability at the (IT Applications, Processes, Products ,

Services, Organisation/Human

Means(machine, robots), etc…)

, Physical
service system level Services, Organisation/Human

Means(machine, robots), etc…)

, Physical

Service Service Service Service

Product System Product System

Fig. 1 The MDSEA Architecture proposed for the service product and service system design and
implementation

Specially, in BSM a combination of two modeling methods is employed to describe the

business-level services: the Extended Actgrams for the process modeling and the GRAI Grid for
decision modeling, but used in a coherent way. Nevertheless, this modeling process mainly
focuses on traditional enterprise modeling point of view and lacks of a means of identifying value
expectations of various participants from strategic level, thereby it is rather difficult to ensure a
higher customer satisfaction in TIM, TSM and service system levels.
The second work is the Value-Aware Service Engineering Methodology (VASEM) proposed
by Harbin Institute of Technology, whose objective is to solve a set of decision-making issues
about how to ensure a softwarized service system meet the value expectations of customers and
providers as far as possible, including value network innovation, value dependency, value
measurement, and choreography-based value delivery, using value as the key decision objectives.
However, VASEM and its service value mainly focuses on softwarized service system but is
difficult to be applied directly to broad-sense socio-technological service systems; in other words,
difficult to deal with those non-IT service elements such as human and physical means. Moreover,
there lack of considerations on decision issues in service.
In this research we combine both together to make use of VASEM’s advantages on
describing the strategic-level value expectations and mapping value to detailed service elements
and MDSEA’s advantages on the model-driven engineering process and describing non-IT part of
services, consequently form a value-driven business service modeling method (VBSM).
Firstly, value proposition combining state-transition based functionality expectation and
constraint based QoS expectation is firstly identified from customer survey, then the service value
network is established by identifying a set of potential service partners and their value exchange
relationships. Based on that, a decision and process combined business service model (BSM) is
constructed, and then value is annotated to the activities in BSM to help check the value
realizability in BSM. Performance indicators of BSM are also connected with the QoS constraints
in value propositions. After, BSM is transformed into technical-level model by service
composition approach.

The first methodology studied is Model Driven Architecture (MDA) [4]. This methodology
defined and adopted by the Object Management Group (OMG) in 2001, is designed to promote
the use of models and their transformations to consider and implement different systems. It is
based on an architecture defining four levels, which goes from general considerations to specific
ones: CIM Level (Computation Independent Model), focusing on the whole system and its
environment, PIM Level (Platform Independent Model): model the sub-set of the system that will
be implemented, PSM Level (Platform Specific Model): that takes into account the specificities
related to the development platform and Coding Level consisting in coding or more generally
enterprise applications (ESA: Enterprise Software Application).
To complete this description, a Platform Description Model used for the transformation
between PIM level and PSM level is added to these four kinds of models corresponding to four
abstraction levels.
The second approach “Model Driven Interoperability” (MDI) consists in considering
interoperability problems from enterprise modeling level instead of only at the coding step.
These works realised in the Task Group 2 (TG2) of INTEROP-NoE proposed at defining an
approach inspired from OMG MDA ([5]). The goal is to tackle the interoperability problem at
each abstraction level defined in MDA and to use models transformations techniques to link
vertically the different levels of abstraction or horizontally to ensure interoperability of models at
each level. The main goal of this methodology, based on model transformation, is to allow a
complete follow-up from expressing requirements to coding of a solution and also a greater
flexibility thanks to the automation of these transformations.
Moreover, Camarinha-Matos et al in [6] introduce the notion of “Transparent inter-enterprise
plug-and-play infrastructure” and “Service Driven Architecture” (SDA) that is considered as an
interface for Networked organizations to be able to rapidly define and set-up relations with other
organizations, which requires a plug-&-play-&-do-business infrastructure. This area is
investigated by several research activities and technology developments, but no clear consensus
on the definition of the concepts, research direction or action to be done is already emerged.
Nevertheless [6] already identified a list of specific needs of collaborative network organizations
(CNOs) that could take advantage of available / foreseeable results obtained in this domain.
Concerning the Business Model representations, two main languages can be mentioned: e3-
value and BMO. These are detailed in the following.
e3-value
e3-value model is developed by Vrije Universiteit Amsterdam. An example of e3-value
model is given in figure 1 on the service system related to a newspaper provider. There are many
readers that buy a newspaper (e.g. using a subscription) from a title they select. In this
constellation, all the titles obtain services (e.g. printing services) from a publisher and pay a fee in
return. The titles obtain also fees from advertisers, who pay for publication of their ads in the
physical newspaper of a title. As the dependencies show the amount of money to be paid by the
advertiser to the title, relates to number of readers - as for each reader, money has to be paid for an
ad. If we attribute the e3-value model with numbers, we can assess economic sustainability for
each actor involved. The figure 1 shows the model as the language concepts and formalisms used
for the modeling.

Fig. 2: Example of e3-value model for a newspaper value exchange

Business Model Ontology (BMO)

BMO is developed by Lausanne University. The f igure 11 presents the ‘clearing rights’
case study using the BMO ontology. It takes one of the right societies, called SENA, as a
point of departure. For reasons of space, only the top-level concepts of BMO are
presented. Also, we do not introduce BMO in detail. For more information see
(Osterwalder 2004).
The value proposition represents the offer of SENA. Its targeted customer segments
embrace the groups of people and organizations it wants to address, including Internet
radio providers. The customer segments are reached through distribution channels and
SENA establishes a specific type of relationship with them. The value configuration
describes the activities necessary to provide the company's value proposition, whereas the
resources and core capabilities outline what the company has to dispose of to provide its
offer. SENA's main activities are clearing rights and repartitioning the due fees. The
Partnership Agreements explains who assists the company in doing this and what they
supply. Finally, the revenue stream describes where the money comes from, while the cost
accounts estimate the expenses.
 Fig. 3 BMO Model for SENA company (only top level)

[We can recall here the global objectives of the paper before to describe the plan. ] This paper
is organized as follows. Section 2 presents the meta-model and modeling framework of VBSM.
Section 3 introduces the model specifications and modeling process of broad-sense service values
based on VASEM. Section 4 introduces a business service model combining decision and process
activities, based on the BSM adopted in MDSEA. Section 5 introduces the value annotation
method to connect the value and the BSM together. Section 6 briefly shows the transformation of
BSM to technology-level models by service composition techniques. Section 7 shows a case study
from culture performance service to validate the effectiveness of V-BSM. Finally is the
conclusion.

2. Meta-model and modeling framework

Fig. 4 shows the basic concepts and their semantics relations of the value-driven business
service models.
This models aims at clearly defining the concepts and their relations that will be used in the
modeling. A service has at least one customer, at least one provider, and 0..n enablers, who
 collaborates together to be a value network [May be we need before to define clearly what is a
value network, in comparison to service network of virtual organization.]. Service offers value to
each of its participants and value are exchanged between participants through the value network.
Value is measured from two aspects: whether the service provides the expected functionalities, and
to what degree the expected performance could be reached. Functional aspect of value is depicted
by the improvement on the state of the participant himself or his belongings, and QoS aspect of
value is depicted by a set of constraints on the performance indicators of state transitions. The
basic element of service model is the “activity” being classified into decision activity and process
activity. The former one is to make decisions in different time span and different function domains
on the key decision points of services with the objective of maximizing value delivery, and the
decision results are represented by the values of a set of decision variables. The latter one deals
with concrete service processes by transforming a participant (or his belongings) from one state to
another one, and exhibits different performances according to the decision results (the value of
decision variables). The execution of a process activity requires the support of three types of
resources (human, IT, and physical means). There are dependencies between different value
expectations of different participants, and such dependency results in a dependency structure
between decision activities. In technology level, all the activities and resources are to be
implemented service components which are then composed together to form the final service
system.

Provider Customer Enabler

FunctionAspect

Service Value StateTransition

contains described by

has QoSAspect

ValueNetwork
has measures
described by results in
ValueDependency

Lee, Minkyu PerformanceIndicator Lim, Heejin

measured by

determined by
Objective Human
has impact on exhibits
related to
has

DecisionStructure forms DecisionActivity change DecisionVariable impacts ProcessActivity has Resource

PhysicalMeans IT
Activity

implemented by
implemented by

ServiceSystem ServiceComponent implemented by

Fig. 4 Meta model of value-driven business service models

In Fig. 4 there is a dotted line, above which are the concepts from VASEM, and the bottom
being concepts from MDSEA. Both sides are interrelated in three aspects which show the interest
of the combination of both approaches:
(1) Value is regarded as the objective of decision activities in GRAI and ECOGRAI adopted
 in MDSEA;
(2) Performance Indicator (PI) is a common concept of both: in VASEM, it is used to
measure the value implementation degree; in MDSEA, it is the external exhibition of
business process performance and indirectly shows the effects of decision activities and
the implementation degree of objectives;
(3) The dependencies between values in VASEM are reflected as the decision structures
between decision activities in MDSEA.
Based on these connections, Fig. 5 shows the modeling framework of V-BSM with four
phases. The figure shows the separations of preoccupations between customers and business actors
(service provider) in the approach and shows the coherence between both preoccupations:
(1) Value modeling, where value proposition model is firstly constructed based on the survey
on different customer segments, and is further elaborately by the value on functions and value on
performance (QoS). A value network is designed as an optimal value exchange relationships
between customers, providers and potential enablers. This phase is totally related to the customer
preoccupations.
(2) Business modeling, where decision model and process model are separately constructed
based on the value network model. At this level, modeling languages for business process and
decision are used but from a systemic point of view, based on system theory principles, i.e. with a
global and a detailed modeling in coherence. We want to insist that these models are the
translation of value proposition and value network choices at a concrete level of running from the
strategic to the decisional levels.
(3) Value annotation, where values are annotated to the activities in business service models,
and value-oriented coherence checking is conducted. If there are value gaps, model optimization
has to be done to iteratively improve the BSM models until the gap is acceptable from the
business point of view.
(4) Mapping to technology-level models, where service composition techniques are employed
to select proper service components from candidates and compose them together as the initial
form of TIM/TSM in MDSEA.
Each phase is to be introduced in the following four sections.
 Customer Service
Segment Providers

Phase 1 Value Value Phase 2

Proposition Network

Decision Model Process Model

Value on Value on
Function Performance
Business Service
Model

Value
Annotation
Phase 3
Coherence Model
Business Level Checking Optimization
(BSM)
Technology Level
(TIM & TSM) Service
Composition

Phase 4
Service System

Fig. 5 Value-driven business service modeling framework

3. Phase 1: Service value modeling

3.1 Service Value Concept
Although it is initially an economical concept, service value is drawn more attentions by
researchers from various domains such as service management, services computing, web-based
services, production services. There are two types of values, tangible and intangible ones. The
former refers to the exchanges of goods or revenue, and the latter refers to “knowledge and
benefits”, including information, knowledge, technical know-how, experiences, and social impact.
The value production and delivery is externally exhibited by the improvement of a specific state of
a participant or his belongings (e.g., his ownership of something, the right to use something, the
amount of money, the body or spirit, etc) which is called “value carrier”.
However, to get the expected value, the participant has to pay for something for return (called
“cost”). In other words, a good service is to provide a participant better state transition but require
less cost.
3.2 Service Value Classification
From the concrete forms of value carrier, value is classified into 7 types, shown in Table 1.
Table 1 Service Value Classification
Participant Value Carrier Explanations
A provider’s economics situation is improved after he
Money
offers service to his customers, i.e., he earns the revenue.
Provider It is a kind of potential value with no or little economics
Value situation improvement, but the impact or word of month
Social impact
is improved to help the provider obtain more customers
in the future.
Customer The ownership of a A customer receives tangible products and own them
 physical belongings permanently
The right of using a For example, renting a car, buying a ticket, reserving a
physical resources hotel room
A customer receives enjoyments after the service, e.g., a
The spirits or body of restaurant service makes him from being hungry to
Value a customer being full, and a performance makes him from being
dispirited to being inspired.
The knowledge or
For example, education service
experience
The belongings of For example, machine maintenance service (e.g., R&R’s
customers TotalCare), car repair service

No matter what type of values, a service participant can uniformly raise his expectation from
the following two aspects:
(1) Functional expectation
 What is the value carrier?
 What is the initial state of the carrier?
 What is the goal state of the carrier?
 If required, what (0..n) intermediate states are expected to experience?
(2) Performance expectation
 In terms of the goal state of the carrier, to what level the attached performance
should reach?
 In terms of the state transitions, to what level the attached performance should
reach?

3.3 Value Proposition Model

A customer C has specific expectations regarding the functionality and QoS of a service, and
the degree in which these expectations are satisfied by a service measures the satisfaction degree.
Varying satisfaction degrees imply the different value-added C actually receives. We define
customer value by
CV=Benefit-Cost=SD´WTP-Cost
where SD[0,1] is the actual satisfaction degree regarding a specific service, WTP is the money C
is willing to pay when SD=1 (indicating that all the expectations could be met), and Cost is the
sum of (1) the money C actually pays to the corresponding service providers (i.e., the price of
service) (2) the indirect cost C pays for the human, physical means or IT resources owned by C
itself during the service.
SD is described by w groups of constraints being classified into function constraints (FCons)
and quality constraints (QCons):
 1, if FCons1  QCons1
  

SD   SD _ Valuei , if FConsi  QConsi
  

 0, if FConsw  QConsw
 This means that, if the FConsi and QConsi in i-th row are satisfied by a service,
SD=SD_Valuei. i>j, there is SD_Valuei<SD_Valuej; SD_Value1=1, SD_Valuew=0; for 1<i<w,
SD_Valuei(0,1).
FCons describes the state transition path that the customer expects, including one initial state
(I), one final state (F) and 0 or multiple intermediate states (M). It is described by
FCons={(Ij{Mj}|nFj, carrierj)}, each Ij{Mj}|nFj being a string of state transitions of
carrierj. A larger n indicates that the customer cares more about the intermediate state transitions,
and n=0 indicates that he only concerns the final state but does not care how to reach it. In terms
of the FCons in different rows, the state transition path might be same (indicating the
corresponding QCons must be different) or be different (indicating the customer expects different
intermediate or final states).
QCons describes the expected performance and is denoted by QCons=({(SiSj, qP,
scope)}{(Sj, qR, scope)}, |). (SiSj, qP, scope) indicates that the customer expects the value of
the performance indicator qP of the state transition SiSj should be in the certain scope. Similarly,
(Sj, qR, scope) means the customer expects the value of the performance indicator qR of the state Sj
should be in the scope. Note that all the states appearing in QCons should be a part of FCons in
the same row.
Regarding the value expectation of a provider P, it is represented by
PV=DV+PV
DV is the direct economic value denoted by
DV=CQ(Price-Cost)
where Price is the average revenue received from one customer, CQ is the quantity of customers,
and Cost is the money that P pays for the human, physical means and IT resources owned by P
itself in the period of service.
PV is the social impact value that is indirectly measured by the average satisfaction degree of
all the customers who actually receive services from P. The higher satisfaction degree a customer
has, the higher possibility he is willing to request P’s service in the future, and vice versa.
 1 CQ 
PV  f    SD  Ci  
 CQ i1 
where f is a function used to estimate the potential economic value based on the average
satisfaction degree.
A provider should specify his expectations on CQ, average SD of his customers, average
Cost per customer, and Price of the service.
Based on the definitions of value proposition of customers and providers, the design and
modeling of services should pursue the following objectives:
 To increase the quantity of potential customers
 To improve average SD of customers
 To reduce the cost
These value objectives are jointly determined by two aspects:
(1) The value network. To elaborately import different partners into a service facilitates the
better value production and exchange by making full use of competitive advantages of the
partners.
(2) The decision activities, process activities and resources (IT, human, and physical means)
in BSM. To elaborately design service activities and select proper resources in BSM facilitates the
better production and delivery of expected service values.

3.4 Value Network

Traditional value network is depicted as a directed graph, in which nodes are participants and
directed edges are value exchanges between participants. It is used to characterize the creation and
transferring of tangible/intangible values between participants.
After the value proposition model has been built, the next step is to design the service value
network for the production and delivery of the expected value to the corresponding customer and
provider by importing one or multiple enablers who facilitate the performance of value production
and delivery. There are multiple candidate value networks that could produce the expected values
but with different value implementation degree.
An iterative modeling process is used to look for an optimal value network. Staring with the
initial value network where there are only customers and providers, service designer analyzes each
of its value exchange relations; if there are potential deficiencies (e.g., high cost, low efficiency),
it is to be improved by iteratively applying four basic operations (i.e., outsourcing, mashup,
crowdsourcing, and third-party payment) and importing new enablers. This process is repeated
until there are no further possible improvements.

r3

r1 r1 r3

C PFE1 P PBE

VSR r2
=
C {r1, r2, r3, r4} P
r4 PFE2 r4
Original value network

CE
New value network

Fig. 6 Service Outsourcing

r1 r
ai1: P aj1: C

r2 r

ai2: P aj2: C

aj: C ai: P
…

al: CE & PFE al: CE & PFE

rn r

ain: P ajn: C
(a) (b)

Fig. 7 Service Mashup

 rk rk
C P C

Original value network P′

New value network

Fig. 8 Service Crowdsourcing

v1

v2
C P
v1

C P v2′ v2

Original value network

PFE
New value network

Fig. 9 Third-Party Payment

Now we have built the value proposition model (VPM) and value network model (VN). The
next step is to design the business service model by a value-driven approach.

4. Phase 2: Decision and process combined business service modeling

4.1 Modeling approach
Activities and processes are the basic elements of a business service model. By utilizing
specific resources (IT, human and physical means), the execution of activities and processes
results in the state transitions of specific “value carriers”, accordingly produces the value. The
objective of business service modeling is to identify a set of proper activities and processes to
make the value production keep coherence with the value propositions in the scope of the
designed value network.
There are two types of activities in a business services, based on system theory, called
Process Activity (PA) and Decision Activity (DA). A DA controls the execution of process
activities, meaning that it has multiple various possible outputs each of which represents a
different execution style of related PAs. By contrast, a PA has definite execution result and will
provide information to some DAs for further decisions.
More in details, there are some variable points with customizable features in the business
process, for example, the time and location of the execution of an activity, the type and quantity of
resources allocated to an activity, etc. Before the execution of service process, all the variable
points should be specified first. The result of decision is the specific value of a set of decision
variables which then determine the value of these variable points and subsequently the concrete
execution of process activities (e.g., branch choice, performance indicator, time, location, human
and resource selection, etc). Different decision results lead to different execution path and
performance of process activities, and the decision effect is demonstrated by the performance of
service process execution. Decision in a decision activity might be made by a human or an
automatic algorithm or the combination of them.
The relationship between DAs and PAs is shown in Fig. 10.
 PA1
DV11

DA1 Customizable point

PA2
DV12 Temporal relation
Control relation
Information Transferring
DAn DVn1 PA3 PA4

PA5

Decision Activities Process Activities

Fig. 10 Decision and process combined business service model

The Business Service Model (BSM) is represented by the combination of the following three
models.
 GRAI Grid: describing decision and decision structure;
 ECOGRAI: modeling the relation between objectives, performance indicators, and
decision variables in order to define a complete performance indicator system;
 Extended Actigram: modeling the process activities and their structural relationships
based on IDEF0 method.

4.2 Reference model for service-oriented GRAI Grid

GRAI Grid and GRAI nets are powerful tools to model decisions in various systems,
including services from a global point of view (cartography with GRAI Grid) and local point of
view (decision process with GRAI Nets). The decisions are classified into time horizons: strategic
at long term (define the objectives), tactical at medium term (define or plan the resources) and
operational at short term (to perform the activities). On the other side, decisions are decomposed
in terms of the functionality domains (or business process decomposition). Decisions in different
domain and different time horizons have interdependences which form the decision structure
graphically denoted by GRAI Grid.
However, different service sectors have quite diversified functionalities. Here we use the
value lifecycle as the base to identify 8 common functionality domains as a reference to build
service-oriented GRAI Grid model [May be we could justify why this decomposition. For
instance, there is nothing concerning service design and development (or is it in DO) neither
service decommission], i.e.,
(1) To specify value proposition (VP)
(2) To manage demand and offering (DO)
(3) To plan and manage partner relationship (PR)
(4) To plan and manage resources (IT, human and physical means) (RES)
(5) To plan and manage scheduling (SD)
(6) To plan and manage revenue and cost (RC)
(7) To manage the interaction (co-production) and uncertainties (CP)
(8) To manage the delivery and usage (DU)
The following figures describe the sequential relationships between the eight domains. Note
that such domain decomposition is applicable to both customers and providers.
 RES

VP DO PR SD CP DU

RC

Fig. 11 Eight phases in service value lifecycle

Based on the referential domain decomposition, the modeler identifies all the decision
activities and fills each into the corresponding decision centers in GRAI Grid.

GRAI Grid
To manage To manage To manage To manage To manage
External To manage To manage To manage Internal
value demand & partner interaction delivery &
info. resources scheduling revenue & cost info.
proposition offering relation (co-production) usage
Strategic
5 year
1 year

Tactic
6 month
1 month

Operational
1 month
1 week

OB J E CT IVE

PE R FOR M A N CE DE CIS ION

IN DICAT OR S VAR IAB L E S

Fig. 12 The reference GRAI Grid with the concepts of ECOGRAI to define performance
indicators related to decisions

For each decision activity, the ECOGRAI method is adopted to identify its objectives
(extracted from the value proposition model), the decision variables embedded in the objectives,
and a set of performance indicators whose values would have influence on the variability of
process activities (which will be discussed in the next section).

4.3 The combination of decision and process activities

Each decision in GRAI Grid is mapped to a decision activity in the service process. However,
only decision activities are not enough, but the modeler needs to identify the process activities that
make real state transitions on the value carriers, and then combine them with decision activities.
Such a compound process model complies with the lifecycle of service value. The BSM
modeling is to elaborate each phase of the value lifecycle by one or several decision activities and
one or several process activities, and the control relations between the former and the latter.
The modeling process is composed of 7 steps:
(1) Identify the process activities for each phase of the value lifecycle;
 (2) Connect the process activities in different phases into an integrated service process,
according to the execution order and information transferring relationship;
(3) Identify the variability of the process:
 Whether a PA is optional or mandatory;
 The execution path between multiple PAs (including sequence, AND-choice, OR-
choice, XOR-choice, etc);
 The performance indicator of a PA (including duration, reliability, price, cost, etc);
 The allocation of resources (human, IT, and physical means) to PAs;
 The date, location and contents of a PA.
(4) Identify the control relations from decision activities to process activities, i.e., for each
decision activity, if at least one of its decision variables is related to a variability of the
service process, a control relation is added between it and the process activity where the
variability locates, with the annotation of the corresponding decision variables;
(5) Identify the information transferring relations from process activities to decision
activity;
(6) For each process activity, identify the state transition it realizes (including the value
carrier, its initial and final state). A process activity might result in multiple state
transitions on different carriers, respectively.
(7) For each activity, identify its required resources (human, IT, physical means). [I don’t
understand exactly the difference between this step and the 4th phase of step 3.]

5. Phase 3: Value annotation and coherence checking

5.1 Value annotation
Value annotation is the process of identifying the activities in BSM that have direct
contributions to the implementation of expected value in VPM, in other words, of establishing the
mapping between value model and business service model, to help check the value
implementation degree under the support of the business service model.
In BSM, there are three-level service processes (strategic, tactic, and operational). Activities
in strategic and tactic levels are not directly related to value production because their time
horizons are comparatively longer; their objectives are to make preparations for the execution of
activities in the operational level to better produce values. For example, customer value is
measured by CV=SD*WTPCost, so the objective of strategic and tactic-level decisions is to look
for the best service providers to make SD=1 as far as possible and Cost being smaller; the
objective of operational-level decisions is to realize real state transitions on the customer himself
or his belongings, and the state transition satisfies expected QoS constraints as far as possible. For
provider value, it is measured by PV=f(average(SD))+CQ*(PriceCost), so the objective of
strategic and tactic-level decisions include: (1) to attract more customers (customer quantity CQ);
(2) to decrease the cost (Cost); (3) to improve customer satisfaction (SD), and the . Therefore, the
value annotation in the top two levels is to connect the decision activities and the value objectives.
 Customer Value Provider Value
CV=SD*WTPCost PV = f (Avg(SD), CQ)+CQ*(PriceCost)
Objective: ↑SD, ↓Cost Objective: ↑SD, ↑CQ, ↓Cost
State transition and QoS Help state transition and QoS

Decision Process Decision Process

Strategic ↑SD, ↓Cost Strategic ↑SD, ↑CQ, ↓Cost

Tactic ↑SD, ↓Cost Tactic ↑SD, ↑CQ, ↓Cost

Operational Operational Help customer’s state

State transition and QoS
transition and QoS

Fig. 13 Relations between GRAI Grid and Value Models

Activities in operational level are to make value production during service execution, and
their objective is to make state transition on the value carriers of customers. Here we adopt state
matching method to make annotations.
A value proposition is implemented by the activities and their composition in service models,
and the implementation degree is determined by the functions and corresponding QoS attached on
the functions. The purpose of value annotation is to establish such mappings. For each
FCons=IM1…MnF in the SD of value proposition model, for each atomic state transition
SiSj, in BSM there are 0, 1 or multiple activities enabling the transition:
 There are no activities supporting SiSj;
 There is one and only one activity Ai supporting SiSj;
 There are multiple activities {A1, A2,…, Ak} together supporting SiSj.
The annotation is realized based on the matching between the entity and its initial/final state.
A small example is shown in the figure below. […]
FCons I M1 M2 F

M1 M2
A2 A3
I
Process A1 XOR A6
Activities
A4 A5

Fig. 14 Relations between Process Activities and Value Models

For the decision activities in the operational level, there are also values annotated to them. If
a decision variable related to a decision activity has impact on some process activities, then the
value annotated to these process activities are also annotated to the decision activity.

5.2 Consistency checking

The consistency between the business service model and value model is checked from
function and QoS aspects:
 (1) For each atomic state transition in FCons=IM1…MnF of value proposition
model, there should be one or multiple process activities in the operational level. If it is violated,
the expected state transition is no longer consecutive, meaning that there lack of some
functionality in the business service model.
(2) For each QoS expectation in a value proposition, its satisfiability is checked based on the
QoS aggregation of the decision and process activities where the value is annotated. If the QoS
constraint is violated, the QoS design of related activities should be adjusted.

6. Phase 4: Model-based service composition in technology level

Service modeling is the first step of building service systems. After BSM is modeled and its
consistency with value models has been checked, the next step is to map it to the technology-level
model (TIM and TSM).
The technology model is composed of a set of concrete service components and resources,
with the coherent functionality and QoS. The composition process is shown in Fig.

Value
Customer Objectives and PI p2
Proposition p1 p3

Discovery Composition

BSM TIM/TSM

Service
Component
Repository
Candidate services

Fig. 15 Model-based service composition

There are two steps for the mapping:

 Service discovery: for each decision/process activity in the BSM, to look for the
candidate service components/resources from the repository based on the functionality
and QoS coherence, i.e., all the discovered components could fulfill the functionality of
the activity and satisfy the QoS constraints;
 Service composition: for each decision/process activity in the BSM, to optimally select
one service component from its candidate services discovered in the first step, and then
all the selected components are composed together to form the TIM/TSM.
For the decision activity, candidate service components might be a human’s behavior, a
decision algorithm based software entity. For the process activity, candidate service components
might be behavior of human, software API, or physical means.
7. Case study on the cultural performance service
7.1 Presentation of the case study
Cultural performance service is a popular daily entertainment service that many people often
use for enjoyment and pleasure, including drama, opera, dancing, concert, etc. Although it seems
simple, there are tens of service providers who collaborate closely to produce a good performance
for audiences. Typical service providers include: actors, producers, directors, undertakers, ticket
agents, theatres, and value-added service provider (food, travel, hotel, car renting, poster, book,
etc). To design such a complex service eco-system, the business service modeling is necessary.
Here we use this service as an example to demonstrate the proposed value-driven business service
modeling approach.

7.2 Value expectation

The ultimate goal of audiences who watch the performance is to get the spiritual enjoyment.
In order to fulfill such goal, two sub-values should be sequentially obtained: (1) to get the tickets;
(2) to watch the performance. Table 2 shows the details of the two sub-values.
Table 2 Value Proposition of Audiences
Value carrier State Transition QoS Expectations Type of Value
Q11: Timeliness of obtaining the
performance information (e.g.,
before 3 months);
Q12: Price of tickets (e.g., no
more than €70 per ticket);
Q13: Convenience of buying
tickets (e.g., tickets can be bought
The right of
from kiosks within the range of 1
using a seat in
Performance No ticketshaving a km, by Internet, or by telephone);
the theatre
Ticket ticket Q14: Responsiveness of
during the
delivering the tickets (e.g., no
performance
more than 24 hours after the
payment);
Q15: Variety of performances
(e.g., at least ten choices per day);
Q16: Frequency of one
performances (e.g., at least 1 per
day).
Q21: The quality of performance;
Q22: The popularity of the
producers/directors/actors;
Usual spirit before
Spirit of the Q23: The comfort level of the An enjoyment
performanceInspired
customer theatre’s seat and environment; value
spirit after performance
Q24: The coherence between the
performance topic and customer
interests.
 In terms of values of service providers, they are not related to state transitions but to four
value parameters (CQ, Prices, Cost and average SD). Table 3 shows the value propositions of two
typical service providers in the cultural performance service: an undertaker and a ticket agent.
Note that these value propositions aim at one performance project.
Table 3 Value Propositions of Service Providers
Service Provider CQ Price Cost SD
Undertaker > 2000 > €70  €100,000  0.85
Ticket agent >450 > €85  €12,000  0.92

7.3 Value network

The performance service eco-system follows the BIRIS model where the undertaker plays a
broker role. Its responsibility is two folds: on the one side, it collaborates with other providers and
organizes a performance in specific cities at specific time: to negotiate with performance investors
and producers and signs a contract, to negotiate with specific theaters and also signs a contract, to
select a set of value-added service providers, and to make propaganda promotion via various
channels; on the other side, it collaborates with numerous ticket agents to sell tickets to potential
audiences in various ways. Audiences who buy tickets then go to the theater and enjoy the
performance.

Aggregation of audiences Aggregation of resources

Ticket Investor
Enterprise Process
Agent
Clients
Producer
B2C

SNS Res.
Actor
Individual Search Performance
Audiences Group Undertaker
on
Call Info. Theatre
Center

Outlet Value-added
Last Provider
Minutes
Value
VIP club Mobile
Advertiser

Push the ticketing info. Mining and Planning

Fig. 16 An Overview of Cultural Performance Service

The service network of the performance service is shown in Fig 17.
 Investor
Ticket agent

Producer

Undertaker
Audiences

Director/Actor

Value-added
service provider
Theater

Fig. 17 Service Value Network of Cultural Performance Service

7.4 GRAI Grid Model

Based on the method given in section 4, we give the GRAI Grid models for undertakers,
ticket agents and audiences. In these models there are decision activities and the decision structure
between them.
GRAI Grid for the performance organizer (Role: undertaker)

To manage To manage To manage To manage To manage

External To manage To manage To manage Internal
value demand & partner interaction delivery &
info. resources scheduling revenue & cost info.
proposition offering relation (co-production) usage

Strategic Market Quantity, type Strategic Capacity planning Long-time Pricing strategy Marketing
positioning and freq. of selection of scheduling Cost planning promotion
and performances; producers, strategy
competition Demand mining theatres, and
strategy and analysis; ticket agents
Planning sources
of performances

Tactic Positioning of Performance Selection of Resource Scheduling of a Value estimation; Marketing

recent project planning partners (theatres, allocation; performance Cost and revenue promotion
performance and selection; ticket agents, project (times, planning; planning;
projects Feasibility value-added Theatre and date) Pricing strategy;
analysis; service providers, planning;
Value-added etc)
service design
and bundling
strategy

Operational

Fig. 18. GRAI Grid Model for Undertakers

GRAI Grid for the ticket agent (Role: ticket agent)

To manage To manage To manage To manage To manage

External To manage To manage To manage Internal
value demand & partner interaction delivery &
info. resources scheduling revenue & cost info.
proposition offering relation (co-production) usage

Strategic
1 year Long-term Audience Partner selection Ticketing channel Long-term Cost budget;
competition classification; for long-term design; ticketing Revenue forecast;
1month strategy Demand mining collaboration scheduling Pricing strategy
Ticketing facility
location design;
Resources planning
(human/ IT/machine)

Tactic Mid-term Demand Selection of Ticket allocation Ticket sales Value estimation Planning the Ticket
competition forecasting; channels for and reservation scheduling and risk analysis; promotion; delivery
3 months Selection of
strategy ticket sales strategy Planning cost and strategy
2 weeks performance revenue; Identifying potential
projects; Pricing strategy; audiences;
Planning
quantity of Queuing design
tickets by
contract

Operational Dynamic price

adjustment
1 week
1 hour

Fig. 19 GRAI Grid Model for Ticket Agents

GRAI Grid for the audiences (Role: customer)

To manage To manage To manage To manage To manage
External To manage To manage To manage Internal
value demand & partner interaction delivery &
info. resources scheduling revenue & cost info.
proposition offering relation (co-production) usage
Strategic Long-term Planning times Planning Long-time Long-time cost
1 year interest and frequency primary ticket performance budget
planning of watching agents and watching
1 month
performance producers schedule

Tactic Mid-term Planning times Planning Mid-time Mid-term cost

2 month interest and frequency of primary ticket performance budget
planning watching agents and watching
1 week performance producers schedule

Operational Short-term Selecting Selecting Planning

1 week interest performance, performance budget for one
planning ticket agent and date and performance
1 day channel, and time
value-added
services

Fig. 20 GRAI Grid Model for Audiences

7.5 Process model

Fig. 21~23 shows the decision and process combined service models for undertakers,
ticket agents and audiences.
Business Process for Performance Undertaker (in tactic level)

Decision Activities Process Activities

Aggregation of
Positioning of Aggregation of Survey of audience
performance
Performance project culture hotspots interests
projects

Performance project
planning and Importing
selection performance project

Value estimation Sign contract with

and feasibility Reusing existing
performance
analysis projects
producers

Producing new
performance project

Performance
scheduling

Cost and revenue

planning

Resource allocation
and scheduling

Marketing Marketing
Theatre planning promotion planning promotion

Ticket sale Sign contract with

Selection of theatres
planning theatres

Preparation of
Pricing strategy theatre related
designing resources

Selection of ticket Sign contract with

agents ticket agents

Allocation of ticket Ticket sale and

resources reservation

Fig. 21 Decision and Process Combined Service Model for Undertakers

Business Process for Ticket Agent (in tactic and operational level)

Decision Activities Process Activities

Aggregation of
Recommendation
available performance
from undertakers
projects

Selection of
performance project

Demand forecast Audience survey

Value estimation
and risk analysis

Negotiation with
performance
undertaker
Planning quantity of
tickets by contract
Sign contract with
undertaker
Planning the cost
and revenue
By website

Planning the Pricing strategy

Ticket sale By telephone
promotion planning

Ticket sale planning

(scheduling, By kiosk
channels)

Identifying potential Collecting audience

audiences information

Ticket information
pushing

Customer ordering

Order processing

Ticket printing and

delivery

Fig. 22 Decision and Process Combined Service Model for Ticket Agents
 Business Process for Audience (in tactic and operational level)

Decision Activities Process Activities

Planning personal
interests

Planning
performance
watching

Cost budget

Search performance
calendar and price
Select performance
and date
Performance info.
from ticket agent
pushing
Select ticket agent
and channel

Ticket booking

Select value-added
services
Payment

Ticket printing

Ticket delivery

Receive ticket

Go to theatre

Value-added service Watch the

Actors performing
offering perforance

Get spirit enjoyment

Fig. 23 Decision and Process Combined Service Model for Audiences

7.6 Value Annotation

Table 4 and 5 show the value annotations for undertaker, ticket agent and audience.
Table 4 Value Annotations (1)
Activity Cost CQ SD Price
Undertaker Performance project planning and selection ↓ ↑ ↑ ↑
Selection of theatres ↓ N/A ↑
Selection of ticket agents ↓ ↑ N/A
Ticket agent Selection of performance project N/A ↑ ↑
Planning quantity of tickets by contract ↓ N/A N/A
Ticket sale planning ↓ ↑ ↑
Identifying potential audiences N/A ↑ ↑
Table 5 Value Annotations (2)
Cos State Transition
Activity SD
t Initial State Final State
 Select performance and ↓ ↑ N/A N/A
date
DA
Select ticket agent and ↓ ↑ N/A N/A
channels
Ticket booking N/A N/ No ticket Ticket reserved
Audienc A
e Payment N/A N/ Ticket Ticket paid
A reserved
PA
Receive ticket N/A N/ Ticket paid Ticket in hand
A
Watch the performance N/A N/ Usual spirit Inspired spirit
A

8. Conclusion
Value plays a central role in services. In this paper we combine the value-driven approach
with business service modeling approach and present a new service modeling method. In value
modeling phase, the value proposition model (VPM) and value network model (VN) are employed
to describe the service from value point of view. GRAI Grid and decision/process combined
service model are employed to describe the decision activities and process activities and the
control relationships between them.
The advantage of the proposed modeling method is two folds:
 By identifying value expectations of each service participants and connecting them with
detailed service activities, it is convenient for service modelers to check the effect that
each activity takes on the value implementation;
 By classifying service activities into decision and process activities and combining them
together via control relation, information transferring relation and temporal relation, it is
portable for service system developers to select proper service components and resources
in technical level.

References