Monitoring Collaboration from a Value Perspective
Lianne Bodenstaff∗, Andreas Wombacher†, Manfred Reichert∗and Roel Wieringa∗
∗Information Systems Group, Department of Computer Science,
University of Twente, The Netherlands
Email: {l.bodenstaff,m.u.reichert,r.wieringa}@utwente.nl
†School of Computer and Communication Sciences,
´
Ecole Polytechnique F´
ed´
erale de Lausanne (EPFL), Switzerland
Email: [email protected]
Abstract— Collaborations among businesses can be described
from different viewpoints. Two of these viewpoints are the
value viewpoint, representing estimated values exchanged in
a collaboration, and the coordination viewpoint, representing
messages exchanged between the actors to coordinate the ex-
ecution of a collaboration. To observe and maintain the value
viewpoint during the complete life cycle, the estimated values
have to be validated during the execution of the collaboration.
However, since the value model is not implemented, the necessary
information for monitoring the value viewpoint needs to be
derived from the coordination viewpoint. Relating coordination
and value viewpoint is a difficult process because the coordination
viewpoint lacks information present in the value viewpoint. In
this paper we define the relation between both viewpoints for
the complete collaboration life cycle. Furthermore, we provide a
mechanism to monitor the collaboration from a value viewpoint.
I. INTRODUCTION
Monitoring the business from a value viewpoint is important
for decision making on the profitability of a cooperation during
the lifetime of this cooperation. A value model gives an indi-
cation on the profitability of an inter-organizational business
cooperation. It describes the value viewpoint of the coopera-
tion by estimating the number of objects with economic value
exchanged between the business partners. Business decisions
are based on the estimated economic behavior of the different
parties in the cooperation. The coordination model describes
how this cooperation can be realized. However, the value
viewpoint should not only be considered during the process of
business decision making. It should be considered during the
entire life cycle of the cooperation, monitoring the profitability
during runtime. In this paper we answer the question on how
to monitor the collaboration from a value perspective.
Since the value model is not directly implemented, a collab-
oration is executed by implementing the coordination model.
Therefore, monitoring is based on the coordination model.
Monitoring is enabled by explicating the relation between
coordination model and value model. Information present in
the log files of the implemented coordination model has to be
related to exchanges in the value model. However, the relation
between these two models is not straightforward since the
This research has been supported by the Netherlands Organisational for
Scientific Research (NWO) under contract number 612.063.409
coordination model lacks information necessary for evaluating
the value perspective. For example, the coordination model
contains information about the messages exchanged between
the parties but provides no information about the exchanged
objects of economic value in that specific message. Therefore,
the value perspective is of importance for monitoring the
economic results of the cooperation during runtime. Through
monitoring it is checked whether the results are consistent with
the original estimations made in the value model.
To monitor the value perspective of the cooperation during
runtime, the relation between the value model and coordination
model has to be established. In this paper we relate both
models by checking consistency. We give static and dynamic
consistency definitions, where static consistency relates both
models during design time and dynamic consistency relates
both models during runtime. Furthermore, we introduce an
approach to achieve dynamic consistency through actively
adapting the value model according to the results provided
by the coordination model. With this approach we provide a
mechanism to monitor the business from a value perspective.
This paper is structured as follows: in Section II our running
example used for illustrating our approach is introduced.
Furthermore, the business case is represented as a value
model and part of the business case is represented as a
coordination model. Section III introduces the concepts of
static and dynamic consistency. Our approach in relating value
and coordination model through consistency is discussed in
Section IV. Section V discusses related work. We conclude
this paper with a summary and outlook in Section VI.
II. MODELLING THE BUSINESS CASE
In this paper we use a running example based on a real case
in the health insurance sector in the Netherlands for illustrating
our approach. An insurance company provides insurance on an
annual basis to its customers. The customers pay premium on
a monthly basis and can claim refunds for received treatments.
Every paid refund by the insurance company is compensated
by CVZ, a Dutch organization distributing tax money. CVZ
gets its funding from the government. Next, we model this
scenario as a value model and part of the scenario as a
coordination model introducing the required concepts.
A. Value Model
For evaluating the economic profitability of a cooperation a
value model is created. The value model of our business case
is defined using e3-value [1](cf. Figure 1). In e3-value, Net
Present Value (NPV) [2] is used for cost-benefit analysis of the
cooperation to evaluate the revenue for every actor. We chose
e3-value because of its graphical representation. The approach
described in this paper is, however, applicable to value models
in general.
Our business case represented as e3-value model is de-
scribed in detail in a technical report [3]. In this paper we
restrict ourselves to those constructs necessary for understand-
ing the approach.
The example from Figure 1 comprises four actors and
eight value transfers. For example, the value object premium
is transferred from the customer to the insurance company.
Another value object, the insurance itself, is transferred from
the insurance company to the customer. In Figure 1 these two
transfers are annotated with an ‘F’. A combination of value
transfers in one transaction is referred to as a value exchange.
In e3-value a distinction is made between different kinds of
value objects. A value object either is a product, service, money
or consumer experience. In this example the premium is a
value object of type money and the insurance provided by the
insurance company can be considered as a service.
The consumer need is “having a health insurance for one
year”. This is represented by placing the start stimulus at the
customer. The set of value objects that has to be transferred
to fulfill the consumer need, consists of all value transfers
connected through the dependency path in the model. Every
month there are two possible sets of value transfers that
can fulfill the consumer need. Either the customer claims
restitution for treatments he paid for himself and he pays
the monthly premium, or he only pays the monthly premium.
When the customer claims a restitution, the insurance company
claims compensation from CVZ. CVZ, in turn, gets its funding
from the government. Also note that the health insurance
company has multiple customers, represented as a market
segment in Figure 1.
In Figure 1, the twelve monthly payments for fulfilling one
consumer need are realized by adding an explosion element,
annotated with ‘A’ in the figure, associated with ratio 1:12.
The choice between the two options for fulfilling the consumer
need is represented as an OR-split. After such an OR-split only
one of the dependency paths is selected. When the customer
has not received treatments that month, the path annotated
with ‘C’ is chosen. The two resulting value transfers constitute
the first set of transfers that can fulfill the consumer need.
Otherwise, if the customer received treatment that month, the
path annotated with ‘D’ is chosen. This path further splits
through an AND-split, representing a parallel occurrence of
two or more dependency paths. In an AND-join, in turn,
all incoming dependency paths share the continuation of
the dependency path. The two value exchanges between the
customer and the insurance company take place. To enable
Fig. 1. e3-value model, the business case
more than one restitution claim per month another explosion
element, annotated with ‘B’, is added. The insurance company
claims restitution from CVZ. These value transfers constitutes
the second set of value transfers. Finally, the dependency path
starting within CVZ represents the third set of value transfers.
In the profitability sheets (not shown in Figure 1), which
can be associated with the graphical representation of the
value model, the estimations are given. The market segment,
for example, can be quantified by estimating the number of
customers and the ratio on the explosion elements and OR-
split is set. For every monetary value transfer a quantification
is given in the profitability sheets. The expected revenue for
every actor in the model can be calculated.
B. Coordination Model
A coordination model depicts how the transfer of value ob-
jects between the parties is realized. In particular, it describes
the order in which messages between parties are exchanged.
An ordered set of messages is referred to as execution se-
quence. This ordering information is omitted in the value
model. Examples of formalisms for defining coordination
models are Petri Nets and Activity Diagrams.
Due to lack of space we depict a small example of a coordi-
nation model represented as a Petri Net in Figure 2 instead of
a graphical representation of our business case. However, [4]
provides a detailed description of the business case as well as
the model represented as a Petri Net [5]. Figure 2 represents
the coordination of the payment process of a customer to the
insurance company for having insurance for one year. This part
of the coordination process is related to the value exchange of
premium and insurance in the value model, annotated with ’F’
in Figure 1. The money value transfer premium is represented
as a message exchange in the coordination model. The service
value transfer insurance is not, since services do not instantiate
explicit message exchanges.
Places (indicated as circles) can hold any number of to-
kens (represented as black dots) and transitions (indicated as
squares) act on input tokens by firing. Message exchanges are
represented as places and tasks as transitions in the coordi-
nation model. Places and transitions are connected through
arcs. These arcs indicate the ordering of tasks and message
exchanges. In Figure 2 the customer has first to make a
payment through executing task Pay after which message
12
12
12
12 x = # arcs
p1
Customer
End
Insurance
Company
Start
Transition
Place
x
Initiator
p2
p3: Premium
p5
p4
Pay Process
Terminate
Fig. 2. Petri Net, example
Fig. 3. Consistency relations
Premium, place p3 in Figure 2, is transferred from customer
to insurance company.
III. STATIC AND DYNAMIC CONSISTENCY
To relate value and coordination model we define a con-
sistency relation which ensures that both models describe
the same system. We consider two types, namely static and
dynamic consistency. Static consistency refers to checking
static model aspects without considering the model behavior
during runtime. By contrast, dynamic consistency takes the
dynamic model behavior into account for two static consistent
models. Figure 3 depicts the relations between the different
systems. Dynamic consistency relates value and coordination
model during runtime through data gathered in the log files.
These log files reflect the behavior of the Information System.
In turn, the Information System implements and executes the
coordination model. Other work like e.g. [6] focusses on
directly relating log file and coordination model.
For defining static consistency we rely on the intuitive def-
inition of consistency between value and coordination models
given in [7].
Definition 1 A value and coordination model are considered
to be statically consistent if:
(i) for every set of value transfers in the value model
(dependency path in e3-value), there exists an execution
sequence in the coordination model such that exactly the
product/money value transfers contained in the set are
exchanged in the execution sequence, and
(ii) for every execution sequence in the coordination model,
there exists a set of value transfers in the value model
(dependency path in e3-value) such that the message
exchanges contained in the execution sequence represent
product/money value transfers exchanged in the set of
value transfers.
Next we consider dynamic consistency. In this paper we
assume a strict relation between coordination model and log
files which is defined as follows.
Definition 2 A coordination model and log file have a strict
relation if:
(i) and only if for each message exchange in the coordination
model there is an entry in the log file, and
(ii) the order of message exchanges in the coordination model
is equal to the order of entries in the log file.
Furthermore, two aspects have to be considered for our
dynamic consistency definition. First, the total value of the
transferred messages should be equal to the estimations made
in the value model. If, for example, the average value of
received orders is lower than the estimated average value of
each order then the two models are considered as being not
consistent with each other. Second, the number of occurred
value transfers has to be equal to the estimated amount of
occurrences. If, for example, the estimated number of orders is
twice as high as the realized number of orders then the models
would not be considered consistent. Taking these two aspects
into account, we define δdynamic consistency as follows.
Definition 3 A value and a coordination model are consid-
ered to be δdynamically consistent at time tif for all message
exchanges x in the log file representing value transfers y in
the value model it holds that:
(i) the average number of realized x between time t−δand
t(δ>0) is equal to the number of estimated occurrences
of y, and
(ii) the average value of x between time t−δand t(δ>0)
is equal to the estimated value of y.
In this context, dynamic consistency checking is based on
calculating averages over a period of time δ. The two models
are considered to be consistent with each other if the average
value and the average number of occurrences were consistent
during that period of time. If necessary, constraints of this
definition can be relaxed dependent on the nature of the
business and the value objects that are transferred.
IV. APPROACH
δdynamic consistency forms the basis for our approach
on relating value and coordination model. We use the data
from the log file as feedback information for the value model.
The value model is actively adapted during runtime using the
data perceived from the monitoring process. This approach
provides a mechanism for monitoring the business from a
value perspective.
Item (ii) of Definition 3) addresses the average value of each
transfer. The average value of each transfer is represented in
the log files. The monitored value of the transfers is compared
with the estimations made in the value model. This is described
in Subsection IV-A.
Subsections IV-B, IV-C, IV-D concern item (i) of Definition
3). The log files contain the information about the messages
exchanged between the different actors. These messages, in
turn, hold the information on the number of value transfers
that occurred between the actors. For using this information in
evaluating the value model, a correlation between both models
and their constructs has to be established. When constructing
the value model several estimations are made regarding the
behavior of the system like e.g. consumer needs and ratios on
explosion elements. The estimated number of value transfer
occurrences is based on these estimations. An equation system
can be derived which comprises the formulas for calculating
the number of occurrences based on the used constructs in
the value model. Data from the log files is entered into the
equation system. When solving the equation system with these
values there may be free variables representing the ratios.
These free variables are represented in a Graphical User
Interface.
After the adaptation of the ratios in the e3-value model,
these results are graphically represented together with the
result of monitoring the value of the transfers. This is demon-
strated in Subsection IV-E. In the following sections, the
different parts of the approach are explained in detail and
illustrated on behalf of our example business case. Due to
lack of space, the approach is explained only on behalf of the
customer which is sufficiently complex.
A. Average Value of Transfers
The value of the transfers is monitored in the log files.
Figure 4 represents the estimations made on the value of
each transfer as well as the monitored average of each value
transfer. We monitor the coordination process for the average
value of each transfer by calculating the moving average. Since
we assume in this example that the customer has constant
behavior over time, we are able to use time series. Every
quarter the average value of a transfer over the preceding
year is calculated. Using a moving average results in a
smoothly changing average over the time series. Figure 4
depicts measurements in quarter Q4 of 2005, quarter Q1 of
2006 and quarter Q2 of 2006, annotated with T1, T2 and T3,
respectively. For calculating the realized average value of a
transfer over a year, each quarter average should be multiplied
by the number of realized transfers and the total should be
Fig. 4. Average Value of Transfers
Fig. 5. Average Number of Transfers
divided by the total number of realized transfers over that
year.
B. Average Number of Transfers
During the execution of the coordination model, we monitor
the coordination process by calculating the moving average as
depicted in Figure 5. In the figure the number of message
transfers as observed at different times during execution are
depicted. In our example every quarter the averages over the
preceding year are calculated. Figure 5 depicts measuring
in quarter Q4 of 2005, quarter Q1 of 2006 and quarter Q2
of 2006, annotated with T1, T2 and T3, respectively. These
message exchanges are correlated to the value transfers in the
value model. This correlation is based on static consistency as
specified in Definition 1. 1
C. The Equation System
The equation system enables calculating the number of
occurrences through formulas based on the constructs of
the value model. The equation system of a value model is
constructed through use of an algorithm. The value model
is represented as a graph where vertices represent constructs
and edges represent parts of dependency paths. The equation
system is constructed by assigning variables to each part of
the dependency path between the different constructs of the
value model. The equations in the system can be related to
each other through these variables. When two constructs are
directly connected with each other through a dependency path,
the variable used in the equations of both constructs will be
the same. The algorithm is as follows:
1for details see [3]
OR-split: Start:
y=r
r+sx x =yz
z=s
r+sx
OR-join: Stop:
y=x+z y =x
z
AND-split: Transfer:
y=x y =sx
z=x z =tx
AND-join: Expl impl:
y=x y =s
rx
y=z
TABLE I
EQUATION SYSTEM
For each edge assign a unique variable. For each
vertex determine the edges and associated variables.
Represent each vertex as an equation based on the
equation system in Table I with instantiating the
variables as the assigned values.
For each construct of the value model a formula exists in
Table I. For example, in Figure 1 there is one dependency
path which enters an OR-split whereas two paths leave this
element. For the fulfillment of a consumer need, only one
of the outgoing paths is chosen. In the profitability sheets an
estimation is made on the relation between the number of times
each path is chosen. In the table this is indicated by rand s,
stating that path yis chosen rtimes and path zis chosen s
times. The resulting formula states that the estimated number
of times path yis chosen is equal to the number of times
dependency path xoccurs times the ratio on the OR-split,
namely r
r+s.Ine
3-value an OR-port is an exclusive OR. For
the OR-join the number of occurrences of both incoming paths
can be added up. For the AND-join as well as for the AND-
split the number of occurrences on each part of the dependency
path is the same. An implosion or explosion element multiplies
the number of occurrences with the ratio s
rassociated with the
port. The number of occurrences on outgoing path xof a start-
stimulus equals the number of occurences of consumer need
ytimes the number of actors zin the market segment. The
number of occurrences on stop-stimulus yequals the number
of occurrences of incoming dependency path xtimes the
number of actors zin the market segment. When the market
segment consists of a single actor the value of zequals 1.The
formula Transfer of Table I states that the outgoing number
of value transfers yis equal to the number of occurrences x
times ratio sand that the incoming number of value transfers
zis equal to the number of occurrences xtimes ratio t.This
ratio represents for example several payments for receiving
one value object.
We illustrate our approach by deriving the equation system
for the customer. Figure 6 depicts the customer with the ratios
and introduced variables as they are used for the equation
Fig. 6. Customer, ratios and introduced variables
Estimated T1 T2 T3
Numbers
x900 850 800 900
y600 600 550 650
z50 zzz
f112 600
z
550
z
650
z
f23
4
17
12f3
16
11f3
18
13f3
f32f3f3f3
TABLE II
LOG FILES
system. Since this example is for demonstration purposes only,
we consider the customer to be a single actor and we assume
there is no ratio on the value interfaces. Next, the resulting
equation system, without pure renaming, is represented. For
a synoptic representation of the graphical user interface, the
ratio on the first explosion element, s
r, is referred to as fraction
f1and the ratios on the OR-split, u
t+uand t
t+u, are referred
to as fractions 1−f2and f2, respectively. The ratio on the
second explosion element, n
mis referred to as fraction f3.
•x1=f1zwith f1=s
r
•x2=(1−f2)x1with 1−f2=u
t+u
•x3=f2x1with f2=t
t+u
•x5=x3
•x4=x3
•y=x4+x2
•x=f3x5with f3=n
m
D. Adapting the Equation System
In the value model estimations are made for the number
of consumer needs and the different ratios of the constructs.
Based on these estimations the estimated number of value
transfers can be calculated. In Table II the entries in Estimated
Numbers column depict these estimations and calculations.
The information from the log files is correlated with the
value transfers and the results at three different times, T1,
T2, T3, depicted in Table II. The observed average of message
exchanges during monitoring can deviate from the estimations
made in the value model. For example, the measurements
on the number of value transfers xat time T1, namely 850,
deviate from the estimated number of value transfers xin the
value model, namely 900. This result makes the value model
and coordination model δdynamically inconsistent according
to Definition 3.
Fig. 7. The Graphical User Interface
When the value model is not δdynamically consistent with
the coordination model one or more of the estimated ratios
in the value model have to be adapted to make the models δ
dynamically consistent. Entering the results of the log files into
the equation system as derived from the value model while
keeping the ratios as free variables and solve the equation
system can have two types of solutions. In the first case the
equation system is over specified and there is no or just one
solution to the equation system, in which case there is no
necessity for a graphical user interface. In the second case the
equation system is under specified leaving a possible infinite
number of solutions. In the latter case, representing the options
in a graphical user interface allows the user to dynamically set
the different ratios and visualize the effects on the value model.
The visualization is important for evaluating the economical
value of the business during runtime.
An example of this graphical user interface is depicted in
Figure 7. Here, the results of the log files from executing the
coordination model at time T2 are depicted. When the user
chooses a free variable to set and enters this value into the user
interface then the equation system is reevaluated. The results,
possibly still with free variables, are again represented in the
graphical user interface. After setting all free variables, the
ratios are adapted in such a way that the value and coordination
model are one year dynamically consistent.
E. Visualization of the Results
In this paper only one actor in a simplified business case
is evaluated. Real life business constellations, however, are
more complex and potentially consist of many constructs.
Adapting one of the ratios in the value model can influence
many other ratios and estimations in the value model. These
effects are visualized in the value model by adapting the colors
of the constructs automatically according to the adaptation of
the ratios. The user can directly see what the effects are of
adapting one specific ratio on the entire business constellation.
Here, the effects of the entered values on the value model,
compared with the original estimated values of the value model
are calculated, classified and represented by an appropriate
color. In the example a construct is colored green when the
entered or calculated ratio matches the estimations made in
the value model. A construct is colored dark green when the
ratio deviates less than 8.5% from the estimated value and
it is colored red when the ratio deviates over 8.5% from the
estimations made in the value model.
In Figure 8 examples of the value model coloring for time
series T2 from Figure 5 and Figure 4 are given. Figure 8 (a)
shows the value model after entering the results of T2. The
average value of transfer x, a restitution, is in timeseries T2
52.16 (cf. Figure 4). This is more than 8.5% deviation of the
estimated value 47. Therefore, the lines of value transfer xare
colored red. The average value of transfer y, the premium, is
in timeseries T2 131.33. This is less than 8.5% deviation and
therefore the lines of value transfer yare colored dark green.
The average number of occurrences of xin T2 is 800 while
the estimation in the value model for xwas 900 (cf. Figure 5).
The deviation between the realized number of value transfers
xand the estimated amount is greater than 8.5% and therefore
the interface is colored red. The realized number of yis 550
while the estimated number was 600. The deviation is less
than 8.5%, therefore the interface is colored dark green. The
remaining variables are still open and therefore grey.
Figure 8 (b) depicts the situation after setting the ratio for
f1. f1 denotes the number of payments each customer makes
for having insurance for one year. Since each customer pays
every month its premium, this is a fixed ratio of 12. When
choosing which ratios to adapt in the value model, f1 will not
be chosen since it is a fixed ratio. Therefore, this is the first
ratio to be set in the graphical user interface. After entering
the value 12 for variable f1, the explosion element on which
ratio f1 is set, changes into the color green. This indicates
that the estimated ratio of 1:12is equal to the realized ratio.
As a consequence, the realized number of consumer needs, z,
becomes 45.8. The estimated number of consumer needs was
50. The deviation is within 8.5%. Therefore, the start stimulus
is colored dark green.
In Figure 8 (b) a possible final marking is depicted. When
we assume there is additional information available on the
percentage of customers that use the possibility of asking
restitution in a month then the ratio on f2 can be set. We
assume this ratio is 70%. The deviation between the estimated
ratio of 75% and the realized ratio of 70% is lower than 8.5%.
Therefore, the OR-port associated with f2 is colored dark
green. As a result, f3 is assigned a value of approximately
2.1 which is also within the 8.5% deviation. The explosion
element associated with ratio f3 is colored dark green.
The conclusion from these results is that there have been
less people asking for a restitution on a monthly basis but
if a customer asked for a restitution, they asked for more
restitutions than estimated. This is indicated by the slightly
increased ratio on f3.
(a) (b) (c)
Fig. 8. Coloring of the Value Model
V. RELATED WORK
Consistency between different viewpoints has been ad-
dressed on different levels of abstraction. An analysis on the
conceptual level has been provided in [8] where the value and
coordination viewpoints are compared based on the semantic
concepts used in the different viewpoints have. However,
this approach does not provide a means to compare two
concrete models. A human intuitive consistency definition has
been proposed in [9] which gives an understanding on what
consistency means without explaining how to check it.
A well known approach for assessing business models is
using Key Performance Indicators (KPI). In these approaches,
KPI are chosen as evaluation criteria for business models. In
[10] KPI are used to overcome the problem of measuring a
priori the benefits of e-commerce investments. The e-business
is assessed by business process simulation where users can
experiment with different configurations. The resulting simu-
lated values of the KPI are compared with the estimated values
in the process models. A business decision is made based on
this comparison. In our mechanism, the profitability evaluation
criterium can be considered a KPI.
Another approach is forecasting modelling where a predic-
tion on future behavior is made based on current available data.
These models are used for decision making. In [11] decisions
on cooperative investments are supported using forecasting
models. Here, also simulation models are used for selecting
proper forecasting models. However, these approaches do not
provide a business view on the dependencies of the measured
values. Furthermore, these approaches do estimations on the
future rather than representing observed behavior.
Another mechanism for adapting models during runtime is
the use of reflection. [12], for example, separates representa-
tion and enactment domains which relates to our separation
of design time and runtime environments. Their approach
supports ongoing transformations between both domains. The
use of reflection allows generation of new programs by another
running program. This allows users to add new processes to
a running program. In [13] reflection is used for reusing,
extending and customizing current processes. While these
approaches using reflection focus on evolution of processes,
they disregard monitoring the business from a value viewpoint.
VI. CONCLUSION AND OUTLOOK
In this paper we propose a mechanism on monitoring
business from a value perspective. We relate the value model
and coordination model through consistency relations. The
contribution of this paper is the definition of δdynamic
consistency which enables correlation of value models and
coordination models. Furthermore, we introduced an approach
to enable monitoring the value model based on results of the
cooperation during runtime. The mechanism supports decision
making on the profitability of the cooperation as well as
adaptation of the value model during runtime.
We continue our work by considering complex situations
as noisy logs, error handling and season dependent customer
behavior. Furthermore, the visualization of the results of
adapting the value model will be extended, using a more
extensive coloring of the constructs in the value model. In
this paper the focus was on adapting the value model, in our
future work we will investigate the possibility of feedback
relations from the adapted value model to the coordination
model. Possibly resulting in an interactive environment where
both models are dynamically adapted due to the consistency
relations.
REFERENCES
[1] J. Gordijn and J. M. Akkermans, “Value-based requirements engineer-
ing: Exploring innovative e-commerce ideas.” Requirements Engineer-
ing, vol. 8, no. 2, pp. 114–134, 2003.
[2] K. Laudon and J. Laudon, Essentials of Management Information
Systems, 5th ed. Prentice Hall, 2003.
[3] L. Bodenstaff, A. Wombacher, and M. Reichert, “Dynamic consistency
between value and coordination models - research issues,” CTIT: Centre
for Telematics and Information Technology, P.O. Box 217 - 7500 AE
Enschede - The Netherlands, Technical Report 06-50, 2006.
[4] ——, “Dynamic consistency between value and coordination models -
research issues,” 2006.
[5] K. Jensen, Coloured Petri Nets. Basic Concepts, Analysis Methods and
Practical Use. Springer, 1997, three Volumes.
[6] W. M. P. van der Aalst, B. F. van Dongen, J. Herbst, L. Maruster,
G. Schimm, and A. J. M. M. Weijters, “Workflow mining: A survey
of issues and approaches,” Data & Knowledge Engineering, vol. 47,
no. 2, pp. 237–267, 2003.
[7] Z. Zlatev and A. Wombacher, “Consistency between e3-value models
and activity diagrams in a multi-perspective development method,” in
OTM Conferences (1), 2005, pp. 520–538.
[8] J. Gordijn, J. Akkermans, and J. van Vliet, “Business modelling is not
process modelling,” in Conceptual Modeling for E-Business and the
Web, vol. 1921. Springer LNCS, 2000, pp. 40–51.
[9] R. J. Wieringa and J. Gordijn, “Value-oriented design of service coor-
dination processes: correctness and trust,” in Proceedings of the ACM
Symposium on Applied Computing (SAC. New York, NY, USA: ACM
Press, 2005, pp. 1320–1327.
[10] G. Giaglis, R. Paul, and G. Doukidis, “Dynamic modelling to assess
the business value of electronic commerce,” in Bled: Proceedings of the
11th International Electronic Commerce Conference, 1998.
[11] X. Zhao, J. Xie, and J. Leung, “The impact of forecasting model
selection on the value of information sharing in a supply chain,”
European Journal of Operational Research, vol. 142, pp. 321–344, 2002.
[12] R. M. Greenwood, D. Balasubramaniam, G. N. C. Kirby, K. Mayes,
R. Morrison, W. Seet, B. Warboys, and E. Zirintsis, “Reflection and
reification in process system evolution: Experience and opportunity,” in
EWSPT ’01: Proceedings of the 8th European Workshop on Software
Process Technology. London, UK: Springer-Verlag, 2001, pp. 27–38.
[13] D. Edmond and M. Papazoglou, “Reflection is the essence of co-
operation,” in Cooperative Information Systems: Current Trends and
Directions, M. P. Papazoglou and G. Schlageter, Eds. Academic Press,
1998, pp. 233–262.
