Developing methods
to react to unplanned events within your own facility is
difficult enough; the effort in creating systems to effectively
discover,
communicate and resolve events across the entire value chain is
magnified
by the number of nodes and trading partners. Event management is
a
proactive, systematic method of predicting and reacting to
situations and is
much different than the standard exception reporting found in
typical ERP
systems. The following steps are involved:
Event Definition
What is an
event? Any situation, usually unplanned, that threatens to delay
the flow of goods, services or information across the supply
chain. Examples
include production line breakdowns, delays in component
delivery, people
shortages, missing shipping or other documentation, quality
rejects, logistics
network delays, and any number of other typical problems. The
first step in
event management is to identify and classify the typical problem
situations
across the entire supply chain- a group effort with trading
partners.
Severity Level
Definition
Not all
events are created equal- the reaction and the number of trading
partners involved will vary based on many factors: current or
future date,
place in the chain (vendor, manufacturer, distributor,
customer), a to-stock
vs. a to-order environment, unique vs. commodity item,
requirement to
cancel or defer vs. expedite, etc. The severity level is
normally determined
by the combination of the date, quantity, product or component,
customers
and number of trading partners affected; rankings can be
assigned to each
category to build a system-generated severity level score
(easier done in
theory than in practice).
Detection and
Prevention Method Definition
The best
systems can predict future events based on trends, warning
signals, and the use of a group knowledge base that uses
parameters
stored from past events. Prevention is the ideal but is not
always possible;
detection methods that provide information to the partners
involved should
be continuous, automatic not manual discovery, real-time instead
of batch,
and timely enough to allow reaction before the event becomes an
emergency. Detection involves monitoring order, inventory,
facility, logistics
and personnel status across the chain, and is often hindered by
a lack of
common technology or trust among trading partners.
Definition of
Partners Involved
After detecting an
event and assigning a severity level, the next step is to
identify the chain partners involved. Along with detecting
events too late,
a typical system problem is that the wrong partners are
notified. Similar
to situations inside an organization where discovery of a
problem is not
communicated to other departments, manual methods don't ensure
the
proper chain partners will be notified. An opposite problem is
notifying
too many partners- does your local packaging material vendor
need to be
informed of a potential supply disruption 4 months from now by
your
foreign steel supplier?
A typical problem
with many ERP systems is burying a planner under a
blizzard of exception messages that leaves them unable to react
on a
timely basis. While most systems have message filters based on
quantity
and date change, ABC category, etc., customization is often
required to
avoid subjecting trading partners to the same blizzard to the
point where
urgent events are hidden or ignored. Notifying every supply
chain node
of every event is counterproductive for most value chains.
Determine
Methods of Communication
Defining the
type, severity level and partners involved in an event will
determine the method of communication. While ideally all
partners use the
same methods, an extended chain often contains multiple
capability levels of
communication, from phone, fax, EDI and e-mail through workgroup
and
collaboration systems, public and private trading exchanges, and
Automatic
Planning and Scheduling (APS) systems. Automatic notification
(but not
automatic assumption of a resolution) is always better than
manual.
Chain partner
notification can be done a node at a time, with each node
taking responsibility for passing on event data to the next
relevant node.
This method avoids overpublicizing the event to non-involved
partners, but
risks breaks in the information chain if one node is slow or
fails to react
and may lead to a reinterpretation of the actual problem by each
partner.
A centralized communications chain can be built if common
technology
exists and the node chain can be clearly defined for each event.
In this
method, a manufacturer would notify both Tier1 and Tier 2
suppliers at
the same time, giving both vendors the same timing and view of
the event.
Propose and
Publicize Event Reponse
Reacting to
events involves identifying the problem, notifying the proper
partners and proposing a response (expedite order #11340 from
1/25 to
1/15, move production lot to contract manufacturing vendor,
etc.) that
optimally includes why this particular response was chosen. Each
proposed
response to an event requires an acknowledgement from the
notified
trading partners that they understand the problem, the proposed
response,
and are able to respond as requested, or to propose an
alternative if they
are not. Dominant chain partners may often assume agreement.
APS systems are
capable of automatically considering material and capacity
when analyzing supply and demand, and rescheduling, changing
quantities,
or creating orders as required. While sometimes feasible within
a single
organization, automatic responses across the supply chain
require detailed
knowledge of partner capacity and material capabilities, and are
often not
realistic. Event notification is not properly complete until the
trading partner
acknowledgement is received and the event problem agreed upon.
Monitor Event
Response
After
notifying trading partners and receiving an acknowledgement, event
management also includes monitoring the success of the response.
Were
the dates and quantities achieved as promised? Did expediting
and extra-
ordinary measures occur that created additional costs and other
problems
in the chain? Did the same event require multiple interventions
over a
period of time, changing dates and quantities? A supply chain
event is not
considered 'over' until the partners agree the conditions that
caused the
initial situation no longer exist.
Analyzing Event
Responses
The most
efficient supply chains document and analyze event response to
build for the future ("Those who do not remember the past,
....."). How
many normal vs. abnormal events occurred? What type of events
occurred
most frequently? Which products and product lines, chain
partners, and
geographic areas accounted for the majority of events? What
responses
solved the event the first time, instead of requiring multiple
interventions?
Are current systems for prevention, detection and notification
adequate?
Analyzing supply
chain event responses serves multiple purposes: building
a knowledge base to allow storing parameters that will allow
prevention
instead of detection, uncovering weak and strong links in the
chain, creating
proper measurement and reward systems, and changing supply and
demand patterns. Outsourcing decisions and changing current
trading
partners often starts with an analysis of the recurrence and
response to
events across the chain.
Supply chains are
dynamic; the size, length and number of nodes can
change continually. Analyzing why events occurred and the effect
of the
responses allows for optimization and future growth, and allows
partners
to control the chain, instead of vice versa.
Source: Bridgefield Group Copyrightｩ2002. All rights reserved.
This
article, in part or entirety, is the sole property of the Bridgefield
Group and may
not be copied, transmitted, framed or
otherwise published without the express
permission of the Bridgefield Group Inc.
