Bridgefield Group Consultilng
Business Planning+Execution™
globe

Supply Chain Event Management

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 Response

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 extraordinary 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 start with an analysis of the occurrence 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©2013. All rights reserved.

This article, in part or entirety, is the sole property of the Bridgefield Group and may not be copied, transmitted, or otherwise published without the express permission of the Bridgefield Group Inc.