It’s a reality of business that companies often create the appearance of orderly operation by off-loading their logistical troubles on smaller, weaker trading partners. When the grocery industry sought to implement EDI as a standard means of communicating pricing and promotional information, such shortcomings became apparent. Trading relationships that had been in place for decades were suddenly threatened by a technology that was supposed to improve operations for everyone. Instead, inherent weaknesses were amplified and a new operational philosophy had to be considered.

These lessons, reviewed by a best practices committee (of which I was a part), offer guiding principles for any large-scale EDI implementation between partners in a supply chain. They changed my thinking about how to apply EDI: I learned that the on-paper implementation plan is not always the best, and that practical considerations in partner relationships are far more critical to success than the elegance of the software solution.

The original proposed best practices in this project were proposed by a consortium of key manufacturers and retailers, with some brokers invited to offer input. Here’s a rundown of lessons that the grocery industry learned and some thoughts on how they can be applied to your EDI-related contracts.

First in a series

This is the first part of a series that will examine best practices in EDI based on the revised UCS II initiative. Future installments will detail the solutions that ended up working for the grocery industry.

“EDI will solve everything”
Often in EDI supply chain work, companies see the value of handling all master data electronically, eliminating data entry errors and verbal misunderstandings. Perpetuating this belief is part of the EDI trade.

I hope that none of us is naïve enough to buy into the fallacy that EDI will resolve every problem. But that was the goal with the Universal Character Set II (UCS II) initiative, which was intended to get everyone who was involved in the grocery industry—manufacturers, distributors, brokers, and retailers—on the same page, all with product/pricing databases that matched.

Before EDI, the relationship worked like this: promotional data was taken from the manufacturers and faxed or phoned by the sales rep to the broker, who then typed it into the broker’s database (more potential for error). From there, the broker faxed or phoned the information to the retailer. Often, the end result was misunderstandings over regional pricing, promotion dates, and other conditions, and the manufacturer ended up with a stack of amended invoices and an unpleasant loss.

The belief was that if everything came straight from the manufacturer’s database via EDI, all these errors would be cleaned up.

Putting the solution before the problem
The UCS II initiative, designed to solve the invoicing errors problem, was thorough but overly so. It took three standard EDI documents—two master/maintenance documents and a transactional document—and outlined very specific uses for them.

  • 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 Promotions document would distribute promotional conditions.

It’s hard to fault this solution in concept. It addresses the root of the problem by generating all master records and modifying information from a single source, eliminating mismatched master records and communication problems in distributing transactional data.

It’s simple and elegant. And it turned out to be unworkable.

Infrastructure defects
UCS II couldn’t work as a canned solution, not because the proposed documents and procedures wouldn’t do the job (they would), but because the relationships of the supply chain participants placed a huge burden on brokerage firms.

In the grocery industry, a retailer requires products from dozens of manufacturers. Because it’s logistically impossible for the retailer to deal directly with this many partners, middlemen—brokerage firms—do the job for them. A retailer can deal with a handful of brokers, and thereby have access to a huge number of manufacturers, with the logistical burden shifted to the brokers.

It looks the same way on the other side of the supply chain. Manufacturers have potentially hundreds of retail outlets for their products, more potential partners than they could ever realistically deal with. So they, too, deal instead with a handful of brokers.

I visited many of these brokerage offices personally. The middleman in many supply chains is a humble participant, valued only for the willingness to do this massively complex networking with minimal resources. I found many brokerage offices to be very marginal operations, with modest offices, few computer resources, and minimal personnel. On paper, it looked like EDI would make their lives easier; in reality, it was a gargantuan burden, from a cost-of-implementation and training standpoint.

A retailer, then, has a one-to-many relationship with brokers. A manufacturer, likewise, has a one-to-many relationship with brokers. In the middle, however, everything is many-to-many. Each broker supplies many retailers, from many manufacturers.

In EDI terms, a retailer or manufacturer generally has a single in-house EDI system cranking out orders or invoices and uses a single value-added network (VAN). The broker, however, must accommodate every last one of these partners, interconnecting to all their different VANs, in order to keep their business. This situation is made far worse by the fact that retailers and manufacturers tend to be large and cash-rich, while brokers tend to be small, existing in very slim margins.

The implementation of UCS II, then, with the broker serving as the critical clearinghouse for data flying in both directions, placed the bulk of the expense and responsibility on the party in the supply chain with the least money and the fewest resources.

Lessons learned, round one
Right out of the gate, two things are clear. First, in the ever more dynamic world of supply chain management, the need to be lean and mean generally invalidates any canned solutions to data distribution. Flexibility is a must, of course, and any solution that can’t be very specifically tailored to the actual distribution scenario is probably a poor solution. And flexibility here doesn’t just mean software and procedure; it also means the building up of infrastructure and the distribution of the burden of putting it together.

Second, it’s clear that the age of synchronized data is upon us. The goals of the UCS II initiative are pursued vigorously in supply chains serving most industries at this point. The benefits in error reduction are obvious, and the competitive advantage is irresistible. EDI does offer the means to coordinate data distribution throughout a supply chain: It’s just a matter of avoiding the wrong ways to do it, and finding the right way.

The “right way,” in this case, is to abandon preconceptions going in—the value of EDI’s flexibility is lost if a canned solution is preordained. Data synchronization is worth all manner of inconvenience to achieve for the long-range savings realized from error reduction. But, like all partnerships, it hinges more on cooperation than elegance.