=Paper=
{{Paper
|id=Vol-30/paper-2
|storemode=property
|title=Business-to-Business E-Commerce in a Logistics Domain
|pdfUrl=https://ceur-ws.org/Vol-30/paper2.pdf
|volume=Vol-30
|dblpUrl=https://dblp.org/rec/conf/isdo/DamenDDE00
}}
==Business-to-Business E-Commerce in a Logistics Domain==
https://ceur-ws.org/Vol-30/paper2.pdf
Session 2: B2B eBusiness Today
Business-to-business E-commerce in a Logistics Domain1
Zef Damen, Wijnand Derks, Matthijs Duitshof, Henk Ensing
KPN Research
{j.t.w.damen; w.l.a.derks; m.j.duitshof; henk.ensing}@kpn.com
Abstract
Today companies outsource part of the service provisioning to other companies
that are not part of their core competence. Companies can use current workflow
management systems to control the progress of the service process within one
organisation. However, with business-to-business e-commerce, service processes
extend beyond organisational boundaries and the workflow management paradigm
should be extended to incorporate specific inter-organisational aspects. This
problem is investigated in the CrossFlow project. In this paper the CrossFlow
concepts are applied to a logistics scenario and it shows the applicability of the
CrossFlow paradigm in practice.
1 Introduction
The last few years many companies have set up alliances and other co-operation forms with external companies.
The reason for this can be the incapacity of their own organisation to deliver value-added services, or the well-
considered choice to stick to their core competence. This co-operation will often result in the outsourcing of
some activities to well chosen partners. If a company wants to outsource work, but does not want to give up on
the control of the outsourced activities, concepts for controlling outsourced processes should be developed.
These concepts are developed within the CrossFlow project. In this paper we present the approach of KPN
Research to model an outsourcing relation between a telecom company and a logistics company (called TELCO
and LOGIS here2). The modelling is done from the concepts developed in the CrossFlow project. The scenario
deals with the selling of telecom equipment by TELCO. The warehousing, order picking, delivery and payment
of the order in this scenario is outsourced to LOGIS.
We will first give an overview of the CrossFlow approach. Then the business scenario is explained in detail.
After that, it will be shown how the CrossFlow concepts are applied to the scenario and what issues will arise.
2 CrossFlow approach
CrossFlow is a European research project aiming at the support of cross-organisational workflows in virtual
enterprises. The co-operation in these virtual enterprises is based on service outsourcing specified in electronic
contracts. Service enactment is performed by linking the workflow management infrastructures of the involved
organisations. Extended service enactment support is provided by Co-operative Support Services (CSS), which is
explained below. CrossFlow technology has been designed to run on top of commercial workflow management
platforms and is product independent.
1
The work presented in this paper is supported by the European Commission in ESPRIT project CrossFlow, project no.
28635.
2
The names of the original companies are not made explicit here and we do not present the original processes in this paper,
but rather an abstract derivation.
Session 2: B2B eBusiness Today
consumer contract provider
A invoke
B D’ monitor D
control
C E’ E
results
F
Figure 1 CrossFlow approach
Figure 1 illustrates the CrossFlow approach. In this figure, we see how the service consumer outsources its
activities D and E to a service provider. The contract is the basis for the co-operation that apart from service
invocation and result reception also encompasses detailed monitoring and control of the outsourced activities.
Three main aspects characterise the CrossFlow approach:
• Dynamic vs. pre-defined service outsourcing
The co-operation between partners can be based on dynamic service outsourcing paradigm with service
consumers and service providers. Compatible business partners find each other through a matchmaking facility.
If the dynamic matchmaking is not needed, the business partners can pre-define their fixed outsourcing.
• Contract-based service specification
A detailed service specification in the form of a contract is the basis for a tightly linked co-operation
implementing the service provision from service provider to service consumer. The definition of the interaction
in the contract is independent of the specific enactment technology of the organisations.
• Advanced influence on service provider
The service consumer can influence the progress of processes at the provider at a fine grain and a high semantic
level, enhanced by the availability of a set of advanced Co-operative Support Services.
A broad spectrum of Co-operative Support Services (CSS) is relevant for cross-organisational workflow
management, like remote process monitoring and control, cross-organisational transaction management,
automatic service remuneration, trust and security management, etc. The design of these services is such, that
they can be selected and combined in a modular way, depending on the application context. In the context of the
CrossFlow project, three areas of advanced Co-operative Support Services are addressed:
• Quality of Service (QoS) monitoring allows to track the progress of outsourced services, both online
during service execution and off-line to analyse aggregate information.
• Level of Control (LoC) enactment provides means for high-level cross-organisational transaction
management and consumer-controlled process control over outsourced services (e.g. stop, start, abort).
• Flexible Change Control (FCC) allows for flexible service enactment, choosing between alternative
paths during service enactment.
3 Business scenario
The LOGIS – TELCO scenario is derived from the real life co-operation between TELCO Telecom and LOGIS
Logistics. Part of the delivery of equipment from TELCO Telecom to customers is carried out by LOGIS
Logistics. This involves purchases by telephone or by Internet (e-commerce). The most interesting part of the
scenario deals with the handling of cellular phone orders. LOGIS takes care of the warehousing, distribution,
delivery and payment, based on orders from TELCO. In CrossFlow terminology, TELCO acts as the service
consumer whereas LOGIS is the service provider. The details of the scenario will be described with the help of a
flow diagram.
Session 2: B2B eBusiness Today
TELCO activities LOGIS activities
customer
requests
service
start order
start order
processing
order
No
OK?
order
Yes Yes
complete?
GSM
Yes
equipment?
GSM
pick order
allowed?
Yes
fetch GSM serial
number
No
allocate
GSM number
No
include GSM
number and wrap
up parcel
activate
GSM number
send and process &
deliver deliver
parcel order
delivery
No send proof
Yes & payment
of delivery
OK?
No
put equipment return and
back in stock unwrap parcel
cancel exit
Figure 2 Processes at TELCO side and LOGIS side
The flow diagram is divided into two sides, a TELCO side and a LOGIS side. It represents a single order for
telecom equipment. Each order starts and ends with the consumer TELCO.
The control flow starts when a TELCO customer requests a service, be it either a telecom connection or
equipment. On order entry, customer and order data are checked for completeness. After that the order data is
checked at LOGIS. If it is not OK, LOGIS refuses the order and TELCO has one more chance of completing the
data. If this succeeds, LOGIS will accept the order after all; otherwise the order is cancelled.
If the requested equipment concerns a GSM (cellular) phone, the left branch at LOGIS will be taken; otherwise
the right branch will be chosen. Note that this branch is straightforward; we will only discuss the left branch in
more detail. This part of the diagram shows the assignment of a phone number to the physical telephone. To this
end, LOGIS provides TELCO with a unique identifier of the physical phone (GSM serial number), which is used
by TELCO to assign a phone number to. The phone number is included in the parcel to be delivered. This way,
the customer is ready to use the phone immediately after delivery. After delivery, LOGIS arranges the billing
(not detailed in the diagram) and a proof of delivery is returned to TELCO. TELCO finishes the order and may
contact the customer to check his satisfaction.
4 Applying CrossFlow to the scenario
In this paragraph we apply the CrossFlow concepts to the logistics scenario presented above. This way we
identify strengths and weaknesses of the CrossFlow approach with respect to our application. We will discuss the
Session 2: B2B eBusiness Today
applicability of the matchmaking and contract establishment facilities, the contract definition and the co-
operative support services.
4.1 Party identification
Contract establishment is closely linked to the different parties involved in the end-to-end service provisioning.
Looking carefully at the scenario we identify five rather autonomous organisational departments (see dashed
boxes in Figure 2):
• TELCO Sales,
• LOGIS Order Entry,
• TELCO GSM,
• LOGIS Order Processing,
• LOGIS Delivery.
TELCO Sales receives the order from its customer and communicates status information and order changes.
LOGIS Order Entry gets the order from TELCO and may improve on the quality of the order data to LOGIS
standards. TELCO GSM handles GSM subscriptions, LOGIS Order Processing performs the actual order picking
and packaging and LOGIS Delivery takes care of final delivery and payment.
The different parties have different roles in the scenario. For example, TELCO Sales has a consumer role and
submits its order to the LOGIS Order Entry, hence establishing a ‘Consumer to Provider relationship’. The
LOGIS Order Entry department may ask TELCO Sales to complete the order data, hence TELCO Sales acts here
in a provider role, mirroring the relationship.
In the table below, a complete list of the relationships involved is given:
Table 1 Consumer – Provider relationships
Consumer Provider Description of relationship
TELCO Sales LOGIS Order TELCO Sales submits order to LOGIS Order Entry
Entry
LOGIS Order Entry TELCO Sales LOGIS Order Entry asks TELCO Sales to complete
order data
LOGIS Order TELCO GSM LOGIS Order Processing synchronises with TELCO
Processing GSM to activate GSM subscription
LOGIS Order LOGIS Delivery LOGIS Order Processing outsources delivery of parcel
Processing to other organisational unit
Following the CrossFlow approach, the different consumer – provider relationships should be reflected in
different contracts. We highlight two aspects here: applicability of dynamic outsourcing and role symmetry.
4.2 Applicability of dynamic outsourcing
CrossFlow foresees a marketplace where parties establish co-operations dynamically when opportunities arise.
When we look at the scenario we see that LOGIS has customised its processes to the processes of TELCO,
offering advanced interaction between both parties. This means that it is very difficult for TELCO to find a
suitable partner that matches the specific interaction pattern. If TELCO wishes to co-operate with other logistic
partners as well, this would require either a new process definition for this new party, or it would require TELCO
to simplify its process interaction. Within the CrossFlow context, this would typically imply restrictions on the
interactions that occur during exchange of GSM serial number and phone number. A solution to the problem is
given in Figure 3.
4.3 Role symmetry
At a high level, we see two organisations co-operate in order processing: TELCO and LOGIS. TELCO maintains
a contact with its customer that placed the order. Therefore it is natural for TELCO to know the status of the
order process and TELCO should be able to influence the progress of the process. However, in Figure 2 we see,
that the role of individual departments within TELCO and LOGIS may change between consumer and provider.
According to the CrossFlow paradigm, a consumer may influence progress of the process at the provider side,
but not vice versa. Therefore, when for example LOGIS Order Processing acts as consumer and TELCO GSM as
provider, TELCO is not in control of the process. This may not be desirable, because TELCO wants to control
Session 2: B2B eBusiness Today
the progress at all times. One solution would be to view TELCO GSM as a separate company that co-operates
with LOGIS. TELCO GSM then acts as a third party in the scenario out of control of the TELCO Sales
department. In that case, LOGIS would then be able to request GSM subscriptions at will, without explicit
control flow between TELCO Sales and TELCO GSM (see Figure 3). Whether this should be allowed is a
business decision. Summarising we conclude that the CrossFlow paradigm is not suitable to support intermediate
interaction between departments of different companies as is.
4.4 Process interaction
The CrossFlow paradigm is based on dynamic outsourcing. In the previous paragraph we already mentioned, that
dynamic outsourcing is difficult in our case, because processes at TELCO GSM and LOGIS Order Processing
are tightly integrated. LOGIS must first deliver the product identifier, before TELCO can allocate a GSM phone
number. This phone number must be returned to LOGIS to include it into the phone parcel. This interaction
implies execution dependencies between both parties. Particularly, for LOGIS therefore it may not be possible to
guarantee certain delivery deadlines, because it is dependent on the speed of the TELCO GSM process. Within
CrossFlow these dependencies between consumer and provider are classified into the following classes
[LAGN+99]:
Table 2 Dependencies between consumer and provider
Classification # provider activities Interaction control flow CrossFlow support
Black box single N/A. yes
Glass box multiple none yes
Open box – outward multiple outgoing from provider yes
Open box – inward multiple incoming to provider no
Broken box multiple incoming & outgoing no
The black box represents a provider process with just one activity. No interaction is defined. The glass box
provides the consumer the ability to look at multiple activities of the provider process. However, no incoming or
outgoing control flow is defined. The open box classes provide synchronisation of outgoing (outward) control
flow (from provider to consumer) and incoming (inward) control flow. The open box – outward class preserves
the independence of the execution at the provider and therefore the provider can guarantee the contractual
obligations. Incoming control flow (consumer to provider) could hinder the provider to fulfil its tasks according
to the contract. The broken box class includes both incoming and outgoing control flow. In CrossFlow it is
decided not to include incoming arrows so as to preserve the autonomy of the provider.
However, in our scenario we indeed have identified a broken box class: the interactive processes between
TELCO GSM and LOGIS Order Processing. To conform to CrossFlow, we had to do some process redesign.
Particularly, we had to divide the flows into strict outsourcable units, removing some interacting flows. The
result is shown in Figure 3. Note that it is not desirable to adapt business processes because of technical
limitations. Another solution would be to keep the control flow exchange between parties implicit. In that case
one could include send and receive of messages explicitly in the activities themselves. Clearly, this is not a nice
way of modelling control flow.
4.5 Co-operative Support Services
CrossFlow includes three Co-operative Support Services as described earlier: Level of Control (LoC), Quality of
Service (QoS) and Flexible Change Control (FCC). Next we describe the applicability of all three services.
4.5.1 Level of Control
Level of Control provides the consumer with the ability to influence the process enactment at the provider side.
The primitives include start, stop, change, rollback and abort. The rollback primitive is associated with the
CrossFlow transaction model, called the X-transaction model [VDGK00]. The X-transaction model is based on
the SAGA model [Garci87], where each activity is executed atomically and isolated and has a compensating
activity associated with it. A rollback is here performed by executing the corresponding compensating activities
of passed activities in reverse order [VDG99]. The X-transaction model was inspired by the WIDE project
[GPS99].
All activities and complex decisions are transformed into single steps as shown in Figure 3. Since compensating
activities are defined for each step, the exception handling like ‘unwrap parcel’ and ‘put equipment back in
stock’ remain implicit in the workflow process definition. The activity ‘check order data’ at TELCO remains a
Session 2: B2B eBusiness Today
valid exit point to cancel the order. At this point the primitives allowed in the provider process are yet to be
defined.
4.5.2 Quality of Service
Quality of Service is defined as constraints on the delivery times of LOGIS. Also the process status of LOGIS
can be monitored (called on-line monitoring), so that TELCO can see what the status is of the process. Important
for TELCO is whether the LOGIS activity ‘delivery and payment’ has succeeded. Off-line monitoring can be
used to estimate the average performance of the LOGIS process. In [Kling00] it is shown that continuous-time
Markov chains can be used to estimate throughput times.
4.5.3 Flexible Change Control
Flexible Change Control is concerned with the flexible enactment of the workflow specification. In this case, we
look at the LOGIS side. In [Kling00] three constructs are proposed to model flexible workflow: alternative
(either A or B is executed, i.e. [A, B]), non-vital (A may not be executed, i.e. Anv), optional order (B follows A,
but their order may be interchanged, i.e. {A, B}). These constructs are used to give the scheduler the opportunity
to choose between high quality (and cost) execution paths or low quality (but efficient) alternatives. Looking at
the LOGIS scenario, we may include an alternative construct at the delivery activity. Here we could extend the
single activity with the choice to include the conventional delivery or express delivery. Non-vital activities could
include the send ‘proof of delivery’, because this activity provides status information that is redundant with the
process status. For the optional order construct we could not identify application within this scenario.
customer
requests
service
start order
check order data
check
type of
equipment
cancel
check
pick order pick order
customer
fetch GSM serial
number
allocate
GSM number
include GSM
number
with parcel
activate
GSM number
send and send and
deliver deliver
parcel parcel
check
send proof
exit delivery &
of delivery
payment
Figure 3 Scenario partially rewritten towards CrossFlow concepts
5 Conclusions
The scenario shows how business-to-business e-commerce is applied in the logistics domain and that close co-
operation is essential for delivering high quality advanced services to customers. In this context CrossFlow
brings a paradigm to control the business-to-business outsourcing. The main aspects of CrossFlow include
Session 2: B2B eBusiness Today
dynamic service outsourcing, contract-based service specification and advanced influence on provider processes.
When applying the CrossFlow paradigm to the scenario we find that dynamic outsourcing has limited
applicability. The TELCO and LOGIS processes are tightly integrated and not easy to outsource. Although one
could think of TELCO and LOGIS as two parties, separate contracts for individual departments seem natural.
Another difficulty with the CrossFlow paradigm is the process interaction required between TELCO GSM and
LOGIS Order Processing. As CrossFlow does not support the Broken Box paradigm, the business process should
be redefined. This is not desirable in practice.
The definition of the Co-operative Support Services is explained in this paper, and suggestions for their
application to the scenario are given. Refinement of the definition is left for future work.
6 Acknowledgements
We would like to thank the members of the Crossflow team for lively discussions. Special thanks go to Jochem
Vonk, Paul Grefen and Marjanca Koetsier at the University of Twente.
7 References
CSSE00 Grefen, P.; Aberer, K.; Hoffner, Y.; Ludwig, H. CrossFlow: Cross-Organizational Workflow.
Submitted to CSSE 2000
Garci87 Garcia-Molina, H.; Salem, K. Sagas, Proceedings of the 1987 ACM SIGMOD International
Conference on Management of Data, USA, 1987
GPS99 Grefen, G.; Pernici, B.; Sanchez, G. (eds.) Database support for Workflow Management - The
WIDE Project, Kluwer Academic Publishers, Boston, 1999
Kling00 Klingemann, J. Flexible Change Control. CrossFlow Deliverable D8a, 2000
KWA99 Klingemann, J.; Wasch, J.; Aberer, K. Deriving Service Models in Cross-Organisational Workflows.
RIDE Workshop, 1999
LAG+99 Ludwig, H.; Aberer, K.; Grefen, P. et al. Outsourcing Re-Visited, CrossFlow internal deliverable,
1999
VDG99 Vonk, J.; Derks, W.L.A.; Grefen, P. LoC Model, CrossFlow Deliverable D10a, 1999
VDGK00 Vonk, J.; Derks, W.L.A.; Grefen, P.; Koetsier, M. Cross-Organizational Transaction Support for
Virtual Enterprises, submitted to CoopIS 2000
Abstracts of the CrossFlow deliverables can be downloaded directly from www.crossflow.org.
Full version of the deliverables can be requested via this site as well.
Session 2: B2B eBusiness Today