When the grocery industry looked at EDI as a way to better communicate pricing and promotional information among manufacturers, retailers, and brokers, the hope was that EDI would eliminate errors over pricing and promotion dates that seemed inherent when using “paper” methods. However, the reality was that the implementation of EDI placed the majority of the burden for keeping the supply chain moving on brokers, who historically have had the least money and the fewest resources.
The best EDI implementations work to distribute such burdens evenly. Here is a look at some of the lessons learned in this EDI implementation and advice on how you should approach EDI-related contracts with your clients.
Second in a series
This is the second article in a series that details best practices based on the revised UCS II initiative. The previous article examined the initiative’s effect on the supply-chain relationships.
The Universal Character Set II (UCS II) initiative, a proposed industry mechanism that was intended to increase automation in pricing and promotional communications, was evaluated several years ago by a consortium that included more than a dozen leading manufacturers, several brokerage firms, and a retail food chain.
UCS II put forth three EDI documents for this purpose:
- The 888 Item Maintenance document would set up and amend all product master records in a supply chain.
- The 879 Pricing document would modify the pricing data stored in those master records.
- The 889 Promotion document would distribute promotional conditions.
It didn’t take long to identify the redundancies with this approach. In my work with clients who use EDI, many of whom are brokers accommodating larger trading partners, this kind of redundancy is commonplace. I’ve found it to be a frequent warning flag that further refinement of the EDI application is necessary, and that some negotiation will be needed.
Paying the bill for better bill-paying
The immediate problem identified by the consortium was the expense of implementing a UCS II solution. Incorporating a single EDI document into a business process between partners costs each partner many thousands of dollars and can require months of effort, taking into account parallel testing and in-house retraining. Retailers and manufacturers are generally cash-rich; brokers, who live in the middle and bear a tremendous communication burden, are not. So it was unlikely that brokers could accommodate the three documents—the entire UCS II solution.
The idea, then, was to reduce this implementation burden as much as possible. In this case, the necessary action was the elimination of promotional data miscommunications—master data synchronization could wait.
Which one should be used?
The 889 Promotion Announcement isn’t in itself a complex document, but agreement on its use between partners can be difficult to negotiate: It contains copious line-item detail, allowance specifics, and terms of sale, and also accommodates a huge spectrum of promotional conditions, performance requirements, promotional periods, and regional conditions.
Although the members of the consortium could agree on which features of the 889 to use, implementation of this single document represented a profound expense for the broker. It was agreed that the 889 would be the first document implemented, and that a success there would represent a minimal threshold of success for the project overall.
As an 889 pilot project got underway, the consortium evaluated the next step. Reducing the remaining implementation burden by deciding what steps could be eliminated, and simplifying the use of the other documents, became the project’s focus.
Resisting EDI’s bells and whistles is a crucial skill for any consultant working this territory. In two Ship Notice implementations, one for a grocery client, one in the biotech industry, I had to bring partners together for exactly these purposes in an effort to reduce redundancy and simplify the use of the document. The question is simple: What information do you really need? Just because the sending system and the chosen transport document are capable of sending every detail of an order—down to your mother’s maiden name—that doesn’t mean you need to send it all. Focusing on nice-to-have information, as opposed to application-critical information, is the most common barrier to rapid and clean implementation in EDI.
Too much information
The second document the consortium considered, EDI’s 888 Item Maintenance document, is formidable. It gives you plenty of line-item information: reference information, unit measurement, even details of how the product should be transported. It gives multilevel packaging information, including variations in product style and color. And it gives pricing information—price bracketing, terms of sale, and date ranges for pricing conditions. Basically, it contains everything the other two documents contain.
For this reason, 888’s redundancy worked against it. The consortium saw that the document was really only useful for the initial posting of a product master record. The 889 and the 879 could handle everything else.
In short, 888 became the lowest priority.
The consortium, therefore, decided to make the 879 the second step in their best practices pilot because it fulfilled the second-most important step in the process: synchronizing the price and pricing conditions of a product not on promotion, so that when an item went off promotion, the correct regular price was in place.
Simplifying the process of updating master data was easy: Get agreement among the partners that an 879 document, inbound from the manufacturer, would override product master data in the broker and customer databases, and that an 889 would provide temporary overrides. The 879 price would be the default to which a database would turn if promotional conditions no longer applied to the product. With this arrangement, 90 percent of the goals of the project were satisfied, and the implementation burden on all partners was reduced (at least from a technical standpoint).
As a brief aside, sometimes information reduction itself becomes the solution. I once assisted a broker in implementing purchase order changes from a customer, but the customer wanted to resend the 875 Purchase Order document, rather than an overriding 865 Purchase Order Change. This was tricky, because the broker’s system barfed on the inbound purchase order number (an obvious duplicate). We negotiated the removal of all the information in the revised 875 that wasn’t the same, so that the broker’s system would see all the blank fields and know that it was an override, not a duplicate. Simplification and the elimination of redundancy spared the parties the expense of implementing a new document or re-writing the existing systems.
First, it’s clear that the obvious initial step in reducing the burden of a difficult implementation is to trim the amount of work required to achieve the technical tasks. This not only cuts costs for all, but also simplifies testing and in-house changes in routine, which is good for everyone. Simpler systems get up and running faster, and don’t break down as often.
Second, realize that EDI is nothing if not redundant. There is almost always a way to get what you want in fewer steps. Why use three pack mules when two will do, if you simply rearrange their packs?
Finally, listen to the partners. A consultant can make a huge difference by encouraging early communication between the parties to avoid implementation bottlenecks, especially when one partner is very large and powerful, and others are small and weak.
Scott Robinson is a 20-year IT veteran with extensive experience in business intelligence and systems integration. An enterprise architect with a background in social psychology, he frequently consults and lectures on analytics, business intelligence and social informatics, primarily in the health care and HR industries.