Proceedings of the 39th Hawaii International Conference on System Sciences - 2006
Agent-based Supply Chain Event Management – Concept and Assessment
Roland Zimmermann, Stefan Winkler, Freimut Bodendorf
Department of Information Systems, University of Erlangen-Nuremberg
Lange Gasse 20, 90403 Nuremberg, Germany
{Roland.Zimmermann; Stefan.Winkler; Freimut.Bodendorf}@wiso.uni-erlangen.de
Abstract
Supply chain event management (SCEM) provides
timely event-related information on disruptions and
malfunctions in operational fulfillment processes.
Agent technology is especially suited to realize distributed SCEM in complex supply chains. A concept
for agent-based SCEM is presented. Two different
prototype implementations of the concept are used to
assess the benefits of an agent-based approach to
SCEM. The results indicate significant monetary
benefits due to reduced follow-up costs of disruptive
events and efficient monitoring processes.
1. Introduction
Problems occur during the execution of processes
regardless of industry or process type. These problems
have an impact on the performance of enterprises and
their supply chains: Timeliness of fulfillment, quality
measurements, costs and revenues of supply chain
partners are affected negatively. For instance, in the
automotive industry just-in-time partnerships between
first-tier suppliers and car producers rely on very tight
schedules for delivery of parts. If these schedules are
violated complete production lines may have to be
stopped in a matter of hours (e.g. [14]). Even small
problems in suppliers’ processes result in deviations
from globally planned and optimized schedules with
serious impacts on supply chain performance. But
consequences can be reduced, if high-quality information is provided to supply chain partners at an early
stage shortly after such events have occurred and
corrective actions can be taken. However, a lack of
reliable and accurate information on events and insufficient communication of event-related data between
partners is observed. The resulting information deficit
regarding event-related information will be referred to
as the Supply Chain Event Management (SCEM)
problem. It is characterized by an "implicit" demand
for event-related information which arises at supply
chain partners, e.g. customers. Demand for information on a specific event cannot be made explicit by
these actors, because they do not know when and
where disruptive events1 will occur since such events
remain uncertain.
Improved information management in supply
chains is required to reduce the SCEM problem. The
objective is to provide a SCEM solution for overcoming the information deficit and thereby improving the
management of supply chain processes. To realize this
objective supply chain partners ought to act proactive:
First, partners in the supply chain have to "sense"
what kind of information might be needed by themselves in the future and act proactive by pulling information from all available data sources including
related partners. Second, information on disruptive
events identified by a partner should be communicated to potentially interested supply chain partners
proactively (information push). A SCEM solution has
to enable and support both types of proactivity.
A structural factor in supply chains adds complexity to the development of a SCEM solution: the
autonomy of the supply chain participants. A SCEM
solution has to accept individual goals and behaviors
of the supply chain partners and must not interfere
with individual strategies. Therefore, each company
has to be able to adapt its information logistics services to its own goals and strategies (e.g. define an
information policy) as well as govern the behavior of
these services (e.g. restrict data availability for external partners in certain situations).
In the following, a concept for an agent-based
SCEM system is presented and assessed. Agent technology is selected since it best suits the needs and
restrictions of the SCEM domain: Autonomy, reactivity, proactiveness of behavior and social ability to
communicate with other agents (or humans) are
characteristics which are agreed upon as being fundamental to the notion of a software agent ([19], [8]).
Proactivity as the primary requirement for a SCEM
solution is inherently satisfied by agent technology:
An agent is endowed with a goal it pursues and its
1
Types of events without any negative consequences on supply
chain processes are not considered relevant for event management,
since they do not require management’s attention.
0-7695-2507-5/06/$20.00 (C) 2006 IEEE
1
Proceedings of the 39th Hawaii International Conference on System Sciences - 2006
advanced capabilities to engage in dialogs with other
software agents enables it to proactively gather SCEM
data and to decide on the necessity of proactively
generating alert messages.
A second aspect is agent technology’s support for
designing distributed systems. Jennings generalizes
the applicability of agent technology to all those
problems that are characterized by independent roles
of different actors where these have to interact in
order to solve the problem ([8]). This characterization
applies to the SCEM problem where actors try to
satisfy their implicit demand for SCEM information
on disruptive events by interacting with each other.
2. Related Work
2.1. SCEM Systems
In the last years an increasing demand for SCEM
systems ([2]) is observed which is addressed by a
growing number of available SCEM systems from
large ERP vendors (e.g. SAP) as well as specialized
solution providers (for an overview see [15]). Although SCEM vendors claim to provide interorganizational solutions, current SCEM implementations primarily focus on intra-organizational processes
within single enterprises, while implementations with
a true inter-organizational multi-level supply chain
perspective are rare ([11]). One reason is that current
offerings of SCEM systems build upon centralized
architectures which prevent the integration of multiple
systems among different enterprises. This is illustrated by an initiative of the automotive industry to
interconnect existing supply chain monitoring systems. In its official recommendation it points out that
decentralized infrastructures are needed which aim at
cooperation between enterprises. However, such
solutions are not available ([12]).
Another major drawback of current SCEM systems
is their lack of autonomous proactive behavior and
their inability to participate in flexible dialogs with
changing communication partners (e.g. for data gathering and alert exchange). However, some SCEM
vendors are beginning to use agent technology (or at
least proclaim certain functions to be agent-based)
([1]). This is an additional indicator for the suitability
of agent technology to implement a SCEM system.
2.2. Agent Applications in SCM
In supply chain management (SCM), agent technology is at the brink of being integrated in fullfledged industrial applications. One successful example is a prototypical industrial implementation at
Daimler-Chrysler where agents negotiate in order to
control a manufacturing process in cylinder production ([4]). A vendor specialized on approaches to
optimize production plans and manufacturing control
is Whitestein Technologies ([18]).
Research regarding application of software agents
in the supply chain domain often focuses on optimizing schedules with decentralized coordination mechanisms such as negotiations for resource capacities
(e.g. [17]). Specialized on machine control are concepts of Holonic Manufacturing Systems (HMS) that
have been extensively studied in many research
projects (e.g. [16]). To provide support for administrative business processes, agents are used for process
management in the ADEPT project with British
Telecom ([9]). Further examples of agent applications
to industrial problems are provided by Parunak ([13]).
For an agent-based SCEM system insights on information gathering agents in supply chains can be of
interest. A series of workshops on Cooperative Information Agents (CIA) is regularly organized since 1997
([10]). Latest results have focused on aspects of
information gathering based on the semantic web,
interactive and mobile agents and recommender agent
systems. Any focus on SCEM like problems has not
been identified.
3. Agent-based Event Management
3.1. SCEM Process and Roles
All functions of the proposed SCEM solution are
aggregated in a generic process for event management
(see fig. 1). This process is applicable to every enterprise in a supply chain ([3]) and realizes interorganizational event management. The focus is on
operational supply chain processes such as production, transportation or warehousing. Hence, orders
which are fulfilled within these processes are the
objects to be monitored. However, the generic
mechanism is in general also applicable to other
domains (e.g. project management).
The first activity is the Monitoring decision (see
fig. 1) which is initialized by different triggers: queries from customers, alerts from suppliers and internally available critical profiles (CCPj). Critical
profiles are used to identify orders with a high probability of encountering disruptive events and thus
focus monitoring efforts on high-risk orders ([3]). A
critical profile is a collection of criteria describing a
certain order type. Typical profile criteria are destinations of transportation orders, contracted carriers,
produced products, ordered quantities and combinations of these criteria.
2
Proceedings of the 39th Hawaii International Conference on System Sciences - 2006
Although it is possible that more than one type of
trigger requires monitoring of the same order, the
SCEM process is only initiated once for each order
and continued until the order is finished.
Supply chain partners
QueryCust
AlertSup
Monitoring decision
CCPj
QuerySup
ResponseSup
Information gathering
QueryInternal
CCPj
Interpretation of SCEM data
ResponseInternal
AlertInternal
Evaluation of CCPj
Alert generation
AlertCust
Order not finished
ResponseCust
Order finished
Enterprise
Cust =
Customer
Control flow
Sup =
Supplier
Object flow
Figure 1. SCEM process
A strategy for proactively gathering SCEM data in
supply chains is used within the activity Information
gathering. This activity is cyclically initiated as long
as a monitored order is not finished (see fig. 1). Data
is gathered both from internal data sources (e.g. an
ERP system) and from external supply chain partners
to assess suborders, as indicated by the two query
variants. Since a status request for a suborder forces
the queried supplier to monitor its own order and its
related suborders, a cascading distributed data gathering mechanism is realized, if the SCEM process is
implemented by every supply chain partner. To prevent excessive communication and resource consumption due to proactive data gathering, critical profiles
are used to restrict monitoring efforts (see above).
Interpretation of SCEM data analyzes all gathered
SCEM data and Alert generation decides whether and
how to generate alerts. Both process steps use Fuzzy
Logic mechanisms to imitate human assessment
mechanisms ([22]). Alerts are directed to actors
within an enterprise in order to initiate reactions to
contain negative effects of disruptive events. Besides,
alerts are sent to customers who will be affected
subsequently by the effects of disruptive events (see
fig. 1). After an order is finished and monitoring is
terminated, results of monitoring activities are evaluated (Evaluation of CCPj) to improve existing critical
profiles and enhance the focus of SCEM efforts on
potentially critical orders.
The SCEM process is associated with various roles
which realize functions in this process. In the following, four clusters of roles are proposed that are assigned to specific agent types and thus enable to
define an agent society for SCEM (see fig. 2).
1) All external communication with supply chain
partners is conducted via one dedicated interface.
The interface ensures that received data conforms
to predefined syntax and semantics (role Commu-
nicationManager). It also ensures consistent
encryption/decryption of messages (role SecurityManager). Both roles are aggregated in the cluster
External communication.
2) All triggers (see fig. 1) which initiate the SCEM
process are managed by one role. This role ensures
that no order is monitored redundantly (role SurveillanceManager). Corresponding to the trigger
type QueryCust is the response to customers, and the
management of proactive alerts (role AlertManager). The evaluation of critical profiles is used to
enhance the focus of monitoring activities. This is
realized by the role ProfileManager. All three roles
are included in the cluster Coordination of event
management.
3) Proactive gathering of SCEM data based on internal and external requests is realized by the SCEM
role InformationGatherer. It provides the data basis
to the process step of analyzing and interpreting
SCEM data with Fuzzy Logic mechanisms which
is the duty of the role DataAnalyzer. This cluster of
roles is termed Order surveillance cluster.
4) Access to internal data sources requires interfaces
for each data source. They provide a data-sourcespecific function for data retrieval which is realized
by the role DataRetriever, and a mapping of the
selected source data to the terms used by the software agents (role DataTransformer). This group of
interfaces and their corresponding roles are referred to as the Wrapper layer.
Basic SCEM roles
CommunicationManager
SecurityManager
Cluster of roles
Agent type
External communication
Discourse agent
Coordination of event
management
Coordination agent
Order surveillance
Surveillance agent
Wrapper layer
Wrapper agent
SurveillanceManager
AlertManager
ProfileManager
InformationGatherer
DataAnalyzer
DataRetriever
DataTransformer
Figure 2. Roles and associated agent types
3.2. Agent Society
The use of role definitions to determine and justify
agent types in multi-agent-systems (MAS) is typical
for agent-oriented software engineering. Hence,
different agent types are defined based on the SCEM
role clusters (see fig. 2):
1) A discourse agent provides the interface to external
supply chain partners.
2) The coordination agent coordinates initialization of
monitoring processes and distributes their results.
3) A surveillance agent is responsible for creating an
information product by gathering and interpreting
SCEM data.
3
Proceedings of the 39th Hawaii International Conference on System Sciences - 2006
4) A wrapper agent hides heterogeneous data sources
from a SCEM system and allows standardized access to these sources.
Consumer
Enterprise 1
Oinit
Enterprise 2
O1
Enterprise 3
Software agent
O2
Order issued
Enterprise 4
Agent interaction
Inter-organizational communication
Discourse agent
Discourse agent
Coordination agent
Intra-organizational communication
Enterprise 3
Surveillance agent i
Wrapper
agent
Coordination agent
Coordination agent
Wrapper
agent
...
...
ERP-system
(e.g. SAP R/3)
Production
controlling
database
Discourse agent
Surveillance agent i
Surveillance agent i
Coordination agent
Wrapper
agent
Wrapper
agent
...
Wrapper
agent
Wrapper
agent
...
Surveillance agent i
...
ERP-system
(e.g. SAP R/3)
Enterprise 1
Warehouse
management
system
...
ERP-system
(e.g. SAP R/3)
3.3. Agent Interactions
Enterprise
O3
Discourse agent
available data source in every surveillance agent. This
redundancy is avoided by introducing wrapper agents.
Production
controlling
database
Enterprise 2
Wrapper
agent
Wrapper
agent
...
...
ERP-system
(e.g. SAP R/3)
Production
controlling
database
Enterprise 4
Figure 3. Agent society
To realize the SCEM concept within a supply
chain, each supply chain partner provides one agent
society2 with a discourse and a coordination agent, as
well as various surveillance and wrapper agents (see
fig. 3) ([20]). A single coordination agent in each
enterprise assures that initialization of monitoring
efforts as well as management of external status
requests and alerts is handled consistently within an
enterprise. It realizes an enterprise specific information policy which enables to relate critical information
only to trusted partners while others only receive a
reduced amount of event management information as
a reply to requests or in alerts [3]. The coordination
agent also allows to gain an overview of all monitored
orders of an enterprise and serves as a management
cockpit.
For each monitored order of an enterprise a dedicated surveillance agent is triggered by the coordination agent. Varying priorities of orders result in
different update cycles (gathering new SCEM data) in
the SCEM process which are to be enforced by the
surveillance agents. Managing these cycles by a single
agent for various orders would require additional
scheduling procedures. To avoid these complexities,
an encapsulation of the data gathering and analysis
functions in dedicated surveillance agents for each
monitored order is proposed for an SCEM agent
society.
Wrapper agents provide a standard interface to internal data sources for surveillance agents. An integration of theses abilities in surveillance agents would
require a replication of all access details for each
2
If a supply chain partner cannot provide an agent society but is
willing to grant access to his internal order data (e.g. based on a
web service), he can be integrated by his customers’ agent societies
using dedicated wrapper agents (see also section 4.2).
Two main dimensions of communication are distinguished in the agent-based SCEM concept:
ƒ Interaction between enterprises which is referred
to as inter-organizational communication: It is facilitated by discourse agents of the enterprises
which exchange messages via the Internet. Every
SCEM agent society has one discourse agent that
serves as the single point-of-contact for external
communication of SCEM data among enterprises.
ƒ Intra-organizational communication within one
enterprise: It refers to the interactions within one
agent society between the various agent types that
realize a SCEM system of a single enterprise. G
Interactions among all agent types are based on requests for SCEM data and requests for activities to be
performed for gathering or manipulation of this data.
A suitable basic interaction protocol is the standardized FIPA "Request" interaction protocol ([6]). The
content of the messages is defined based on a SCEM
ontology which is discussed in detail in [21]. Each
agent type decides, based upon the message type, the
sender and the content of a message, on an appropriate action, in order to fulfill its duties within the
SCEM process (e.g. analysis of received data). Besides reactions to messages, every agent can decide
proactively to take or initiate further actions in the
event management process (e.g. send an alert).
An example of inter-organizational agent interactions is presented in fig. 4. Proactive monitoring of
orders is initiated within an enterprise by the coordination agent, based on critical profiles. The monitoring activities result in requests of a surveillance agent
to suborder recipients. In fig. 4 Enterprise 1 begins to
proactively monitor order Oinit and sends a request to
its supplier Enterprise 2 regarding suborder O1. Consequences of this initial request are cascading requests
to the two suppliers of Enterprise 2 which return
SCEM data on the suborders O2 and O3 to Enterprise 2. After Enterprise 2 has interpreted all available data (including its internally gathered data) it
returns an inform to Enterprise 1. In this inform
SCEM data on order O1 is communicated which
integrates relevant information on all currently active
suborders of the supply chain. The extent of the
included SCEM data in an inform varies according to
the enterprise’s information policy which is realized
by the coordination agent. The information selection
mechanism employs a heuristic based on Fuzzy Logic
(for details see [22]). Customers’ surveillance agents
which eventually receive these informs (not depicted)
4
Proceedings of the 39th Hawaii International Conference on System Sciences - 2006
Consumer
Enterprise 1
Oinit
Enterprise 2
O1
Enterprise 3
Enterprise
O2
Order issued
Enterprise 4
Agent interaction
Discourse agent (Enterprise 3)
Discourse agent (Enterprise 4)
O3
Proactive data gathering – cascading status requests
Discourse agent (Enterprise 1)
Discourse agent (Enterprise 2)
REQUEST (O1)
Initiate SCEM process for O1
REQUEST (O3)
REQUEST (O2)
Initiate SCEM process for O3
Initiate SCEM process for O2
INFORM (O2)
INFORM (O3)
Forward SCEM data on O2 and on
O3 to surveillance agent (O1)
INFORM (O1)
Figure 4. Agent interactions
thus may have to cope with incomplete data from
suppliers due to restricted content of the inform (or if
suppliers fail to respond at all). However, surveillance
agents are designed to cope with a limited amount of
data, if necessary [20] [22].
The result is a distributed system of agent societies
for monitoring critical orders across a supply chain
with a combination of proactive SCEM data gathering
(pull mechanism) and distribution of alerts (push
mechanism). The implicit demand for information on
disruptive events (see 1.) is satisfied with messages
that are exchanged between supply chain partners.
numbers of surveillance agents. An additional agent
type provides white and yellow pages services to all
discourse agents of a supply chain: a global directory
facilitator (GlobalDF, see fig. 5).
Enterprise 1
Enterprise 2
O1
Enterprise 3
O2
Software agent
Enterprise
Order issued
Enterprise 4
O3
Agent interaction
Data base transaction
GlobalDF
JADE® agent platform
Enterprise 2
Enterprise 1
Discourse agent
Discourse agent
Coordination agent
CCPj
4. Prototypes
Coordination agent
Simulator
Simulator agent
A generic prototype with all agent types has been
realized for conducting experiments in a laboratory
environment: Each enterprise in a simulated supply
chain hosts one agent society (see fig. 5). A single
wrapper agent per enterprise is required to access a
database that simulates the enterprise’s ERP system
which provides all internal SCEM data on orders. The
main focus of the implementation is on SCEM features provided by coordination and surveillance
agents, whereas only basic mechanisms of discourse
and wrapper agents are realized. Every agent society
is realized on its own instance of the FIPA-conform
JADE agent platform. As in a realistic supply chain,
agent platforms can be hosted on different computers
to realize a physical distribution of SCEM systems.
Furthermore, the implementation design principally
allows to distribute a single SCEM agent society to
different JADE platforms. Thus, additional computational resources are available to cope with large
ƒ
ƒ
ƒ
ƒ
CCPj
Wrapper agent
JADE® agent platform
Discourse agent
4.1. Generic Prototype
...
Surveillance agent iBBSim
Sim
Generate DE
Measurements
Time control
Experiments control
Surveillance agent i BBSim
Sim
BSim
Wrapper agent
JADE® agent platform
Simulated
ERP system
Reaction function
Experiments
data base
Figure 5. Architecture of the MAS
Within the generic prototype all agents rely on the
SCEM ontology. The JADE agent platform selected
for implementation of the generic prototype supports
a special representation of ontologies based on Java
Beans (JB) ([5]). Information on a certain instance of
an ontological concept (e.g. a specific order) is represented as an instance of a JB class Order. Instantiation
of ontological concepts define knowledge facts of an
agent’s knowledge base. Besides creating, accessing
and manipulating an agent’s knowledge base with
JBs, this representation is used by the JADE platform
to define content of FIPA-ACL messages. Thus,
knowledge is standardized among agents in a SCEM
5
Proceedings of the 39th Hawaii International Conference on System Sciences - 2006
system, easily exchanged between agents, and always
accessible through Java programming instructions.
To facilitate simulation of all orders in a supply
chain during experiments a single data base aggregates all ERP systems of enterprises in a simulated
supply chain. Each wrapper agent responsible for
accessing internal data from its enterprise’s ERP
system has a restricted view on this database.
A simulator reflects changes in fulfillment processes in the ERP system. These changes are identified
by agents of the SCEM system. Most functions are
integrated in a special agent type: a simulator agent
which has direct access to both the ERP system and
an experiments data base (see fig. 5). This agent
initiates new experiments by starting all agent societies and triggers monitoring through requests to Enterprise 1 which it transmits via an additional
discourse agent. During execution of fulfillment
processes it generates disruptive events for selected
orders of the supply chain. It stores these disruptive
events and its effects on process times (delays) in the
ERP system for discovery by the agents of the SCEM
systems. As soon as a surveillance agent has identified a new disruptive event and its corresponding
delay, a reaction mechanism is triggered that calculates how much of the delay can be reduced depending on the remaining reaction time. The results of this
reaction are stored in the ERP system, and measurements (e.g. time point of identification of disruptive
event, reaction consequences) are stored in the experiments data base. All delays in suborders that
cannot be coped with propagate to the next customer
level of the supply chain. Such propagation is assured
by the simulator agent. In case several suborders are
delayed, a maximum delay is assumed for the superorder. Thus, propagating disruptive events are
simulated and effects of agent-based SCEM are
measurable.
4.2. Industry Showcase
A second prototype of an agent-based SCEM system is realized as a showcase within a real-world
environment of a logistics service provider (LSP). The
prototype provides insight into the ability to integrate
agent-based SCEM concepts into existing fulfillment
processes and IT-infrastructures. The showcase is
documented in detail in [3].
Industrial carriers which receive suborders from
the LSP and which are integrated in the agent-based
SCEM solution do not have their own SCEM agent
societies, but only provide conventional webinterfaces for their customers. These interfaces offer
status information on transportation orders. Dedicated
wrapper agents are realized to integrate these web
interfaces in the agent-based SCEM system. The
implementation is based on the FIPA-compliant
FIPA-OS platform. A focus of the showcase is on
integration of real-world data sources and on realization of the proactive monitoring of orders based on
critical profiles.
The coordination agent offers a graphical user interface (GUI) which allows a user to monitor and
manage the SCEM agent society of the LSP (see
fig. 6).
Currently known
wrapper agents
Edit SCEM
parameters
Aggregated
order status
Manage
critical order
profiles CCPj
Currently
active surveillance
agents
View surveillance
agent in detail
Terminate
surveillance agent
Start surveillance
agent manually
Figure 6. GUI of coordination agent
A user can manually start surveillance agents to
monitor certain orders, access detailed information of
a specific surveillance agent, and terminate observation tasks. The GUI provides a short overview of all
currently active surveillance agents with their monitored order’s identifier, predicted duration of the
order, and an aggregated status that indicates whether
the order is on time, late, critical, or finished. Configuration and management of critical profiles is also
managed by this GUI.
If a user decides to monitor a specific order or if an
order is identified as potentially critical by a profile,
the coordination agent instantiates and initializes a
surveillance agent. The surveillance agent monitors
the fulfillment process across the entire supply chain
from order reception to order delivery. The system
uses a series of milestones which divide the fulfillment process into individual sub-processes defined by
the LSP. Based on the order’s milestone plan which
defines when a milestone is supposed to be completed, each surveillance agent identifies any deviations. All deviations are registered by the agent and
displayed to the user upon request. The main GUI
provided by each surveillance agent employs a traffic
light metaphor. To indicate the status of a monitored
order the agent differentiates between states of single
milestones and an aggregated status of an order. This
order status indicates, whether an order is fulfilled on
time, is late, or critical. Proactive alerts to actors are
provided by the agents through warning emails and an
automatic display of a surveillance agent’s GUI to an
actor (“pop-up”).
6
Proceedings of the 39th Hawaii International Conference on System Sciences - 2006
5.1. Experimental Results
Evaluation of the agent-based SCEM concept is
guided by the question: By how much can follow-up
costs of disruptive events be reduced by a SCEM
system?3 A theoretical cost-benefit-model not presented here suggests conceptual superiority of the
agent-based SCEM concept compared to existing
SCEM solutions due to the agents’ ability for flexible
inter-organizational communication. This enables
advance notices of partners along a supply chain in
case of disruptive events. In especially, the model
provides hypotheses that are validated in experiments
and in an assessment of the showcase (see 5.2):
ƒ The number of update cycles (SCEM cycles) in
the SCEM process determines follow-up costs. A
SCEM cycle consists of data gathering, data
analysis and alert generation activities (see fig. 1).G
ƒ The use of critical profiles provides additional
benefits through further reduced follow-up costs.G
All experiments are conducted with the simulator
presented in section 4.1. The mechanism for reducing
a delay assumes that to a certain extent the planned
duration of fulfillment processes can be reduced.
However, this reduction is limited to a predefined
threshold, since in reality fulfillment processes (e.g. a
production process) always have some minimum
duration (e.g. for working on a product).
Depending on when event information becomes
available, the intensity of a reaction changes: The
earlier information is available the more intense is the
reaction and vice versa. A linear function is selected
for calculating the exact extent of a reaction. In realworld scenarios different reaction functions to calculate a reaction might also be realistic (see section 5.2).
Within experiments, disruptive events are inserted
by the simulator during fulfillment of a suborder
which is placed with Enterprise 4 (see fig. 7). All
orders in the supply chain have the same planned
duration of five days. An initial advance planning
horizon for Enterprise 3 is 15 days. A maximum
3
Further qualitative benefits not considered here are achievable,
e.g. competitive advantages of enterprises which employ SCEM.
Consumer
Enterprise1
Enterprise2
Enterprise3
Enterprise4
= Enterprise
= Order issued
Enterprise5
Disruptive events
Figure 7. Supply chain configuration
In fig. 8 (left side) results of an experiment are depicted where a disruptive event occurs very early
during fulfillment at Enterprise 4 (within the first day
of the planning horizon) and results in an initial delay
of 100 hours. Measurements are taken at Enterprise 3
for different numbers of SCEM cycles.
96
90
89
88
-0,0061
y = 90,008x
R2 = 0,8335
87
Remaining delay in hours
5. Evaluation
reduction of 10%, which is 12 hours, is defined for
every enterprise.
Remaining delay in hours
Scalability of the showcase prototype is analyzed
in [3]: A realistic number of surveillance agents for
the LSP is about 130 surveillance agents, if critical
profiles reduce monitoring efforts. Hence, about
90 MB of memory are required for the agent society
and a linear increase in memory consumption for
additional surveillance agents is identified.
95
94
y = 95,222x-0,0037
R2 = 0,5954
93
0
20
40
60
Number of SCEM cycles
0
20
40
60
Number of SCEM cycles
Figure 8. Impact of SCEM cycles
Since a very precautious reaction function with
only 10% maximum reduction is chosen, the absolute
difference between low and high numbers of SCEM
cycles is relatively small. However, the results state
that an increase in SCEM cycles results in a sharp
decline of the remaining delay similar to behavior
predicted by the theoretical cost-benefit-model. In the
experiments the minimum number of SCEM cycles
per order is an average of 2.5 which results from fixed
intervals between data gathering rounds and the
specific fulfillment duration of an order. An increase
of SCEM cycles allows to realize nearly the maximum reduction of 12 hours. Compared to the situation
with 2.5 cycles (10 hours reduction) this is approximately an additional 20% reduction.
The impact of SCEM cycles on the remaining delay at Enterprise 3 for a later disruptive event (seven
days later) is depicted in fig. 8 (right side). The more
erratic pattern of reductions results from fixed intervals for gathering data and from random occurrence
of a disruptive event: In some cases, a disruptive
event will be very close to an update round, even
though this update round is one of very few in an
experiment with a low number of SCEM cycles.
However, an approximated trend indicates the same
pattern as for the early disruptive event although the
overall reduction is less. This is due to the later occurrence of the disruptive event and thus a reduced
reaction time. On a relative basis the additional reduc-
7
Proceedings of the 39th Hawaii International Conference on System Sciences - 2006
tion realized for more SCEM cycles compared to the
situation with 2.5 cycles is even larger: 4.5 hours
reduction as compared to 6 hours reduction for many
SCEM cycles. This is an additional reduction of more
than 30%.
Similar reductions are realized on following supply
chain levels (not depicted here): On average, the
reductions of delays are even larger since information
is available earlier for customers in supply chains due
to the agents’ advance notices. This benefit of the
MAS approach is not realized by current implementations of SCEM systems which primarily concentrate
on limited sections of supply chains (see 2.1, [11]).
In fig. 9 the experimental results of fig. 8 are rated
with costs: Every additional hour of delay is valued
with 5 monetary units (MU), and every additional
SCEM cycle costs 0.1 MU. The ratio of both cost
types is thus 50:1. This is a realistic minimum ratio
for follow-up costs which add up to multiple Euros
(see section 5.2) and costs of IT resource consumption
for monitoring efforts that add up to at most 4 EuroCent per SCEM cycle. For instance, provisioning
costs for IT-services range at around 0.8 Euro for one
hour of CPU-time or for 1 Gigabyte of storage capacity including storage management and for 1 Gigabyte
of communication volume (e.g. [7]). Execution of a
SCEM cycle is well below an hour CPU-time and
requires at most a few kilobytes of data (both stored
and communicated). Thus, resource consumption is at
the highest in the range of single Euro-Cents per
SCEM cycle. However, the maximum number of
SCEM cycles which is technologically possible with
an agent-based system is not necessarily reasonable
from an economic point-of-view: For instance, updates every five minutes for an order with a five day
cycle time would result in monitoring costs of up to
57.6 Euro per order.
451
Cumulated follow-up costs of a disruptive event
in monetary units [MU]
Cumulated follow-up costs of a disruptive event
in monetary units [MU]
472
470
468
466
464
462
460
458
w = 20
CDE = 5
CSCEM = 0.1
456
454
452
y = 0,0927x 2 - 1,5303x + 453,42
R2 = 0,8658
450,5
450
449,5
449
448,5
448
447,5
w=6
CDE = 5
CSCEM = 0.1
447
446,5
0
5
10
Number of SCEM cycles
15
0
5
10
15
20
Number of SCEM cycles
Figure 9. Cost functions
Assuming that all orders of an enterprise are monitored and only 5% of these orders are affected by a
disruptive event, an average hit-rate per monitored
order is 5%. Hence, a monitoring efficiency parameter
w is 20 in this scenario: This means, for one order
with a disruptive event 19 orders are monitored without identifying any disruptive event. Since all costs
associated with a single disruptive event are considered as follow-up costs, monitoring costs for all 20
orders are considered. Cumulated costs for the experiments indicate a cost optimum for the disruptive
event in the experiments at a little more than 453 MU
and 3 to 4 SCEM cycles (see fig. 9, left side).
If a more focused monitoring due to the use of
critical profiles is realized the hit rate for each monitored order is increased to at least 15 % based on data
mining results [3]. Thus, the monitoring efficiency
parameter w is reduced to 6 (only 5 orders per disruptive event are monitored needlessly) and an additional
reduction of cumulated follow-up costs is realized.
The approximated trend in fig. 9 (right side) indicates
that the result is an additional reduction of the cost
optimum to about 447 MU and an increase of optimal
SCEM cycles to around 8. Critical profiles are currently only available in the agent-based SCEM concept and not in existing SCEM systems.
5.2. Showcase Assessment
An assessment of the industry showcase provides
insight into the impact of agent-based SCEM on realworld processes and associated costs. For instance,
the prototype provides significant improvements
compared to the manual monitoring processes currently implemented at the LSP. Process times in this
manual process result in a cumulated 125 seconds for
finding status information on a certain order and
assessing this information [3]. Associated costs are
approximately 1.15 Euro per manual SCEM cycle
since average costs of personnel are 34 Euro per hour.
The showcase prototype provides the same information automatically in a matter of seconds and without
manual intervention. Although no direct cost measurements are available for the prototype it is assumed
that every update cycle costs at most 4 Euro-Cent (see
above).
Costs associated with reactions to disruptive events
largely determine benefits of SCEM. For the LSP a
process analysis has been conducted which exemplifies a method to determine cost functions for different
reactions. In the analysis reactions to severe disruptive
events within orders of important European customers
are in the focus: A second delivery has to be triggered
since the initial delivery is definitely not arriving at
the planned delivery date. Typical reasons for this
reaction are - as stated by experts of the LSP - damages during transportation and incorrect routing of
goods (e.g. to another country). The reaction process
of the LSP is depicted in fig. 10.
8
Proceedings of the 39th Hawaii International Conference on System Sciences - 2006
Process duration
Disruptive event identified
≈ 1 hour
Create plan for reaction
Create new delivery note
(∅ ≈ 5 order items)
Picking in warehouse
≈ 20 minutes
Packaging
4
3
Regular carrier
X
1
≈ 0.5 days
Express pick-up
≈ 2 hours
Air freight
≈ 2 days*
2
Transport by ≈ 5 days
truck
Air freight
≈ 2 days*
Dedicated direct
express courier
≈ 1 day
* including delivery from airport to customer
Associated costs
Internal activities of LSP
Alternative 1
Alternative 2
Alternative 3
Alternative 4
1h20min at 34€/h
= 45€
45€
45€
45€
170€ per 100kg
air freight
160€ for airport
express
170€ per 100kg
air freight
Direct express
courier 660€
275€
375€
705€
Picking up order from LSP
60€
74€ per 100kg
Transportation
Cumulated costs
119€
Figure 10. Process analysis LSP
In every case where a new (second) delivery is initiated due to a disruptive event, internal activities
within the administration of the LSP take about one
hour and consist of devising a plan for reaction and
creating a new delivery note. Picking and packaging
is finished about 20 minutes after the delivery note is
received in the warehouse, if goods are available on
stock. Packaged goods then wait for pick-up by a
carrier.
Four variants depending on the remaining time for
reaction exist (see fig. 10): Regular transportation by
truck to a European destination requires about 5.5
days from order dispatch at the LSP to delivery to the
customer (1). By using air freight and a regular service to transport goods to the airport, about 2.5 days
are needed (2) which can be reduced to about two
days and 2 hours, if an express service courier to the
airport is used (3). If only about one day remains a
dedicated direct courier with a small and fast transportation vehicle can reach most locations of central
Europe within about 24 hours (4).
For each alternative associated costs are gathered
in interviews with experts of the LSP (see fig. 10). For
instance, alternative 2 is cheaper than alternative 3,
because a regular carrier is used for sending goods to
the airport while in the latter case an express is used.
Based on the process analysis and associated costs
a cost function is devised in fig. 11. It illustrates use
of the cheapest alternative available for each point in
time between beginning of fulfillment of an order and
its planned delivery date. In the example, a planned
cycle time for orders of 10 days is assumed which is
realistic for deliveries to central European countries
outside the European Union. For instance, not before
four and a half days of fulfillment have passed is a
second regular transport by truck viable with lowest
costs of 119 Euro.
The step-wise cost function illustrates realistic alternatives for the LSP in relation to the remaining
reaction time during an order’s fulfillment. Two
statistical trends based on a linear and a non-linear
trend are depicted. In the example the linear function
provides better statistical results and underlines the
viability of using linear cost models for assessing the
benefits of event management in supply chains (see
e.g. reaction function in section 5.1). The cost function in fig. 11 indicates a cost reduction potential for
follow-up costs compared to the worst case (after day
10) of more than 80% for early disruptive events.
1000
Costs of reaction to a severe
disruptive event
in Euro
Euro
Process for taking reaction
800
y = 82,18x - 0,48
R2 = 0,84
600
y = 30,12x1,44
R2 = 0,54
400
200
0
0
Begin
fulfillment
2
4
6
Time in days
8
10
Planned
delivery
Figure 11. Cost function
A forecast on potential benefits for the LSP is realized based on data mining results of a three month
period of the LSP’s international orders [3]. They
indicate that 483 orders had severe problems during
this period and the cost function of fig. 11 is used for
the forecast: The majority of disruptive events are
encountered during transportation between day 1 and
day 10. To forecast follow-up costs, the linear approximation is used and an equal probability of encountering disruptive events is assumed. In
consequence, a disruptive event occurs on average at
day 5.5 and about 451 Euro per severe disruptive
event are forecasted, if every disruptive event is
identified immediately. This adds up to 218,079 Euro
which is a 55% decrease compared to the situation
where events are identified after the planned date of
delivery which would result in a maximum cost of
485,415 Euro. However, this reduction would require
monitoring all orders continuously and inducing high
monitoring efforts. Hence, realistic critical profiles for
focusing monitoring efforts are also identified in the
data mining approach [3]. They focus on only 5.3% of
all orders and thus already identify 36.6% of all
critical orders. It is shown that a further increase of
identified disruptive events is realistic while even this
prototypical approach to define critical profiles results
in a reduction of follow-up costs of about 97,845 Euro
with monitoring efforts reduced by almost 95%.
6. Conclusions
It is shown that an agent-based concept is suited to
reduce negative effects of disruptive events in supply
chains. While agent technology supports the auton-
9
Proceedings of the 39th Hawaii International Conference on System Sciences - 2006
omy of supply chain partners it also offers mechanisms to both pull and push event-related information
(for conceptual details see [3], [20], [21], [22]).
Hence, the initial information deficit is significantly
reduced which is reflected by improved process
measurements (e.g. reduced delays) and reduced
follow-up costs of disruptive events not achieved by
existing SCEM systems. Since monitoring is not free,
the approach to focus monitoring activities with
critical profiles has been shown to yield additional
monetary benefits. The viability of agent-based
SCEM in real-world scenarios is underlined by a
showcase which indicates large benefits for enterprises that implement agent-based SCEM.
A final assessment has to consider investments required to set up agent-based SCEM. A critical cost
factor is the configuration of wrapper agents while all
other issues are assumed to cost no more than realizing conventional SCEM systems. The configuration
task is simplified as Semantic Web technologies
become available: Due to the SCEM ontology employed in the MAS cost-efficient integration of various data sources is enabled, if semantic descriptions
for data sources are provided. Web Services as well as
Enterprise Application Integration (EAI) infrastructures increasingly provide simpler data access, too.
Besides, future RFID implementations in supply
chains will assure higher quality of monitoring data.
Thus, investments for realization of SCEM MAS tend
to decrease in the future while the benefits of reduced
follow-up costs of disruptive events remain the same.
7. References
[1] Barrows, T., Using the SCOR Model to Map Collaborative Multi-Agent Systems (MAS) Business Environments.
Presentation at Supply-Chain World-Australia/New Zealand
Exe Technologies, 2003.
[2] Bittner, M., E-Business Requires Supply Chain Event
Management - The Report on Supply Chain Management,
AMR Research, Boston, 2000.
[3] Bodendorf, F., Zimmermann, R., “Proactive Supply
Chain Event Management with Agent Technology” Int.
Journal of Electronic Commerce, 9 (2005) 4, 57-90.
[4] Bussmann, S., Jennings, N.R., Wooldridge, M., Multiagent Systems for Manufacturing Control - A Design
Methodology, Springer, Berlin 2004.
[5] Caire, G.; Cabanillas, D.: JADE Tutorial - Applicationdefined Content Languages and Ontologies, TILab S.p.A.,
2004, http://jade.tilab.com/doc/CLOntoSupport.pdf, accessed on 2005-03-31.
[6] Foundation for Intelligent Physical Agents, FIPA Request
Interaction
Protocol
Specification,
2002,
http://www.fipa.org/specs/fipa00026/SC00026H.pdf,
accessed on 2004-09-24.
[7] Gray, J., Distributed Computing Economics. Technical
Report,
Microsoft
Research,
Redmond,
2003,
http://arxiv.org/ftp/cs/papers/0403/0403019.pdf, accessed
on 2005-04-27.
[8] Jennings, N.R., “An Agent-Based Approach for Building Complex Software Systems”, Communications of the
ACM 44 (2001) 4, 35-41.
[9] Jennings, N.R., Faratin, P., Norman, T.J., O'Brien, P.,
Odgers, B., Alty, J.L., “Implementing a Business Process
Management System using ADEPT: A Real-World Case
Study” Int. Journal of Applied Artificial Intelligence 14
(2000) 5, 421-463.
[10] Klusch, M., Ossowski, S., Kashyap, V. (eds.), Proceedings of Cooperative Information Agents VIII: 8th International Workshop, CIA 2004, Erfurt. LNCS 3191, Springer,
Berlin, 2004.
[11] Masing, N., Supply Chain Event Management as
Strategic Perspective – Market Study: SCEM Software
Performance in the European Market, diploma thesis, 2003,
http://www.cata.ca/files/PDF/Resource_Centres/hightech/re
ports/studies/SupplyChainEventMgt.pdf, accessed on 200504-18.
[12] Odette, Supply Chain Monitoring, Version 1.0, Recommendation Mai 2003, http://www.odette.org/html/scmopr
.htm, accessed on 2005-04-19.
[13] Parunak, H.v.D., “A Practitioners' Review of Industrial
Agent Applications” Autonomous Agents and Multi-Agent
Systems 3 (2000) 4, 389-407.
[14] Radjou, N., Orlov, L.M., Nakashima, T., Adapting to
Supply Network Change, Forrester Research Inc., Cambridge (MA), 2002.
[15] Tohamy, N., Radjou, N., Hudson, R., Grading Order
Fulfillment Solutions, TechStrategy Report, Forrester
Research, 2003.
[16] van Brussel, H., Wyns, J., Valckenaers, P., Bongaerts,
L., Peeters, P., “Reference architecture for holonic manufacturing systems” Computers in Industry 37 (1998) 3, 255274.
[17] Wagner, T., Guralnik, V., Phelps, J., “Software agents:
enabling dynamic supply chain management for a build to
order product line”. In: Arabnia, H.R.; Mun, Y. (eds.):
Proceedings of the Int. Conference on Internet Computing,
IC'2002, CSREA Press, Las Vegas, 2002, 689-696.
[18] Whitestein Technologies, Products and Solutions,
http://www.whitestein.com.
[19] Wooldridge, M.J., Jennings, N.R., “Intelligent Agents:
Theory and Practice”, Knowledge Engineering Review 10
(1995) 2, 115-152.
[20] Zimmermann, R., Butscher, R., Bodendorf, F., Huber,
A., Görz, G., “Generic Agent Architecture for Supply Chain
Tracking” The 2nd IEEE International Symposium on
Signal Processing and Information Technology. IEEEPress, Marrakesh 2002, 203-207.
[21] Zimmermann, R., Käs, S., Butscher, R., Bodendorf, F.,
“An Ontology for Agent-Based Monitoring of Fulfillment
Processes”. Tamma, V., Cranefield, S., Finin, T.W.; Willmott, S. (eds.), Ontologies for Agents: Theory and Experiences, Birkhäuser, Basel, 2005.
[22] Zimmermann, R., Winkler, S., Meyreiss, C., Bodendorf, F., Assessment of Supply Chain Event Management
Data by an Agent-based System with Fuzzy Logic, accepted
for ASIM/ABS 2005.
10