Moving Beyond Information Visibility

In my last article, we began providing examples of MEC (multi-enterprise collaboration) supply chain initiatives whose processes had been standardized. Here, we continue our examples of standardized MEC.


Last time, we discussed how vendor managed inventory (VMI) is used to assist buyers and sellers in their efforts to avoid stockouts while still minimizing inventory. But, VMI—for all its good points—still does not provide the level of information availability that is possible or beneficial. In addition, it fails to employ the kind of collaborative analysis that could really fine-tune the process. As a result, a process known as collaborative planning, forecast, and replenishment (CPFR) has been defined. Like VMI, it speaks to the need of the seller to have visibility into what is being sold at POS and the inventory levels of stock at stores and DCs.

But, CPFR goes well beyond mere information visibility. [That would only utilize the availability component of MEC.] CPFR also defines a process for the analysis and application of the shared information to mutually benefit its practitioners. The planning and forecasting portions of CPFR define how the buyer and seller will share views of anticipated inventory drawdown rates and purchasing behaviors, compare those to historical patterns, identify and resolve anomalies and agree on expected inventory needs. [Figure 1] With this more collaborative analysis of the information, the seller can more effectively apply the results of that analysis to its manufacturing mix, production cycles, etc. The result is one step closer to the perfect order.


The promise of CPFR to vastly improve the retail supply ecosystem is nothing short of remarkable. And, its applicability to buyer/seller interaction is broad. CPFR is useful for retail event collaboration to facilitate promotions, new item introductions, item rollovers new store openings, etc. It can be used for store and/or DC replenishment collaboration avoiding overstocks and stockouts. Finally, it is well suited to enabling collaborative assortment planning to optimize sell-through at the store level.


More promise than practice as of this writing, RFID (radio frequency identification) sets the stage for extensive information availability, analysis, and action among entities within a supply ecosystem. Similar to the function of the bar code, an RFID provides an ID that allows anyone in the ecosystem to recognize what a given product, case, pallet, etc. is. But, unlike the bar code, it can be read without direct line of sight. And, unlike the bar code, the RFID tag [Figure 2] contains an EPC (electronic product code) that provides a specific serial number that identifies each specific instance of a product.*2


Combined with the EPCglobal Network [Figure 3]—which will allow all authorized reporting points for a given EPC to share what they know about what was reported by each reader that read the RFID tag containing that EPC—RFIDs are poised to allow trading partners and others in a trading community to monitor the activity of a specific instance of a product throughout the entire supply ecosystem.


But, obtaining information from RFID readers only speaks to the availability component of MEC. In order for organizations to generate substantial benefit from RFID, they must implement the analysis and application components of MEC to generate benefit from the use of the knowledge that RFID makes available. Said differently, what questions will you ask of the RFID reporting data (that tags, readers, and the EPCglobal Network make available) and what actions will you initiate (based on the answers to those questions) to generate worth? That is the seminal RFID question.


As promising as initiatives such as RFID, CPFR, SBT, and others are, they are all directly dependent on one critical condition, the accuracy and consistency of the information they use as input for their analysis. Without clean data, these initiatives amount to nothing more than errors processed and bad decisions made faster than ever. And, with greater collaboration, we have bad data being shared throughout the supply ecosystem.

Realizing that any MEC initiative presumes—and requires—accurate data, numerous communities are turning their attentions to cleansing and synchronizing the data they will use within their own organization and with others in their supply ecosystem. This requires that an organization get in sync with itself (internal synchronization), get in sync with its trading partner (external synchronization), and, then, stay in sync over time (ongoing synchronization).

Lack of data integrity emanates from several problem spots. Internally, organizations frequently have numerous, uncoordinated versions of the same information. Changes made in one location are not updated in all other instances of that same piece of information throughout the organization. Different departments, different business units, different divisions, etc. each have their own version of the information. [Figure 4]

To make matters worse, the information in any given location can be changed by far too many people…many of whom don’t fully appreciate the impact of poor information management and inaccuracies—however slight—on the rest of the organization and on their customers and/or suppliers. Rarely is the management of a given piece of information restricted to only those people who are impacted most negatively if the information is incorrect. By controlling who can make changes to information and coordinating changes across all instances of that information, organizations can create an internal environment where consistent, accurate data becomes a possibility.

With the information accurate and consistent throughout the organization, it’s possible to synchronize with a partner. Once again, MEC is applied to achieving external and ongoing synchronization. By collaboratively making updates available to recipients who can then analyze and apply the new values to its internal systems and data stores, the two organizations are able to get and stay in sync with one another over time. [Figure 5]

Operationally, the ongoing synchronization process is as follows.

The source:

  1. Extracts and aggregates information from its internal data of record to create a snapshot of its current version of the “truth”
  2. Compares the current values to previously published values to detect any changes that may have occurred*5
  3. Routes any changes to be published to appropriate internal personnel to review and approve before publishing
  4. Creates and sends the data to be published in the appropriate message(s)*6
  5. The recipient:

  6. Monitors and retrieves the published the data
  7. Determines what kind(s) of changes have been received*7
  8. Routes the published changes to the appropriate internal personnel to review and approve the updating of internal data of record locations with the new values
  9. Creates and sends a status message*8 back to the publisher indicating whether or not the recipient intends to update the internal data of record with the published value(s)
  10. Updates internal data of record with the published value(s)
  11. The source:
  12. Monitors for return status messages*9 from the recipient and notifies internal personnel as appropriate


Our MEC examples to date have involved two or more enterprises interacting with one another to accomplish multi-enterprise collaboration. In the next issue, we’ll look at the application of MEC strategies within the enterprise.

*1 Source:

*2 The EPC will tell you that you’re talking about a can of Coke. And, it will provide a separate identifier for each can of Coke.

*3 Source: EDS

*4 Source: EPCglobal

*5 Potential “changes” include: a new item to publish, new values to be published for a previously-published item, a previously published item to be published for the first time to a given recipient.

*6 Published data is sent to a certified data pool that interacts with the GS1 Global Registry (a centralized registry of all participants and the items being published) and other certified data pools on the global data synchronization network (GDSN).

*7 Inbound changes include: first-time publish of an item that the recipient already has on file (i.e., the first step in External Synchronization), first-time publish of a never-before-seen item, and changes to a previously published item.

*8 Potential status states include: (a) received but no status determination yet, (b) stop publishing this item to this recipient, (c) received and intend to update internal files, (d) have updated internal data of record.

*9 E.g., Error messages from the data pool will likely be routed to data synchronization technical support personnel. Rejections from recipients will usually be routed to business personnel concerned about such actions.

About the Author

John Stelzer is Director of Industry Development for Sterling Commerce. Since 1984, he has been providing education and consulting on electronic commerce—to date, educating more than 27,000 professionals from over 16,000 companies. For more information on electronic commerce in the retail industry or data synchronization specifically, John can be reached at 614.793.7046 or

More by John Stelzer

About Sterling Commerce

Sterling Commerce is one of the world’s largest providers of business integration solutions. For more than 25 years, thousands of companies have depended on Sterling Commerce expertise to optimize collaborative relationships through the integration of applications, external partners, suppliers and customers. With more than 25,000 customers worldwide, Sterling Commerce is the dominant business integration solutions provider in retail, consumer packaged goods, manufacturing, financial services and telecommunications.