Deal Promises to Put Trading Partners in Sync with Each Other
By George Anderson
Last week’s announcement that UCCnet and Transora have agreed to form a single organization promises to help retailers and their trading partners achieve the benefits of data synchronization.
The new organization will operate as a division of the Uniform Code Council (UCC) after the board of directors for Transora and the UCC formally approve the deal.
Michael Di Yeso, president and COO of the UCC said in a released statement, “Data synchronization is really just the start of better e-commerce. Companies that are synchronizing their data today will be able to more quickly realize the benefits of emerging technologies, such as the Electronic Product Code (EPC), as widespread implementations occur.”
Bob Noe, the current chief executive of Transora, has been named to head the new organization. “By joining forces we would make it even easier for retailers and manufacturers to establish a common approach for data synchronization that benefits all parties.”
Moderator’s Comment: What does the announced merger of UCCnet and Transora mean in practical terms for retailers and manufacturers? –
George Anderson – Moderator
I just have this feeling that someday, not too far in the future, we will have evolved another step, where differentiated retailers of scale get unique products from their largest vendors. At which point, industry-standard data alignment will be totally irrelevant for some large trading relationships, and the rest won’t be economically feasible to support it.
I have asked this question before and the continued consolidation of companies whose existence depends on the implementation of synchronization makes me ask it again: “Is data synchronization still necessary?”
Twenty years ago when the concept of a “Central Catalog” came out of the Efficient Consumer Response (ECR) efforts, it made sense. Communications networks were operating at 4800 baud and the need to limit the size of data transmissions by referencing attributes contained in a master file made sense. Now we have high speed connections exchanging full image files at megabyte speeds and the need for data compression has passed.
Without the need for data compression, it seems to me that the answer should be that many of the key item attributes that have traditionally been optional in many B2B transactions should become mandatory. If fields like manufacturer description, weight, case pack, dimensions, etc. were contained on every transaction, the receiving party could immediately compare the transaction values to their records. Instead of counting on a separate process that would coordinate the update of master data, the receiving party would be immediately aware of changes implemented by the sender. Some of these changes might be OK with the receiver and would merely lead to updates of their records. Other changes, such as a change in case pack or perhaps cost, would be brought to the attention of the receiving party’s personnel who handle those types of changes.
This constant feedback of what a particular GTIN represents allows for the supply chain to react appropriately as variations of a product flow from manufacturer, to retailer distribution center, and into the stores. It also immediately highlights the reason for imbalances when remittance advice show a difference in the retailer’s files from what the manufacturer has in its database. None of this prevents earlier notification of the changes, but if for some reason the notification is “lost,” it provides a way to get things back in sync without all the processes associated around a central catalog.
The only question that remains is how to answer the question, “What is this?” when confronted with a GTIN of an unknown item. This is where a catalog makes sense, much as the proposed ONS for the EPC implementation. This is a legitimate role for UCC (GS1-US) to provide, either through independent contractors or itself. They can also police it by ensuring GTIN’s are not reused and are properly formatted. By serving only as a registry, they still leave it up to manufacturers to either maintain a catalog or use a data pool for cost and deal information if retailers still need it.
I agree with Ron. It was only a matter of time when the other exchanges linked together. Now the question is, what happens next and will the industry get behind one (or more) exchanges to maintain the integrity of the data? My belief is that expecting ALL suppliers to manage ALL data remains a somewhat flawed model. Time will tell.
The combination of UCCnet and Transora solves the “Transora problem.” That problem is how the CPG companies that invested over $200 million in Transora should bring the venture to an end. It just never would make it as an ongoing venture. The investing companies didn’t want whatever assets had been developed to fall into the hands of tech companies such as IBM or SAP. Oddly, CPG companies view tech vendors as arms merchants that stoke unproductive arms races. Putting the assets in the hands of UCC, a non-profit funded by the Transora’s owners, and other CPGs, solves that problem. (They should have just folded the venture and destroyed any software.)
Ironically, a few years ago Transora had applied enormous pressure to UCCnet to split off the data pool function of data sync so that they and others could compete to provide that service. Now, UCC is having to buy that function back. Let’s hope they are paying little or nothing.
But the Transora solution is exacerbating the “UCC problem.” The problem with UCC is that it has strayed so far from its original mission as a standards maintenance organization for grocery UPCs. Today, they fancy themselves as a standards development organization and have expanded horizontally into every type of retail. The loss of focus has cost the CPG industry and their channels dearly. Bad enough that UCCnet represented a public utility of sorts, now the acquisition of Transora plants them squarely in competition with for-profit tech vendors. UCC needs to extricate itself from this business. The UCCnet-Transora venture should be spun off.
Just three weeks ago, responding to the question, “What will be the result of the merger of GNX and WWRE?,” I wrote in this space: “Another key question is where does this leave Transora, the CPG manufacturer-owned exchange? Transora had partnership relationships with GNX and WWRE for a few years, so the relationship will roll over to the merged company. But you have to wonder if Transora now will lose some leverage.”
Well, we didn’t have to wait long for my question to be answered. The combination of UCCnet and Transora will certainly be beneficial for both retails and manufacturers, particularly in terms of management. Bob Noe is a very capable leader with an understanding of and a genuine interest in the retail/CPG supply chain. UCCnet’s previous managers, while professional, didn’t have a grasp on the business opportunities (and obstacles) like Bob does.
By the way, it will be interesting to see what the names of the two groups — UCCnet/Transora and GNX/WWRE — wind up being. I have some ideas, if there is any interest from Mr. Noe or Mr. Sellers.
Bill Bittner proposes an interesting alternative to data sync. It would seem that an alternative is needed, because adoption of data sync has stalled. It’s just not making any headway. That leads me to believe that it’s NOT really needed.
Technical issues aside, as the “super-user” for our company, it’s my job to maintain, input, and publish GTIN’s to the various retailers through the UCCnet system. To date, there are 3 of our retailers on-line. Everyone else is demanding GTIN’s but are not actually live on the UCCnet system. (They don’t want to pay the huge fees to be active for publication.) They want the numbers but don’t want to be “involved” in the process or the system. So from my point of view we are already flawed and “Sunrise 2005” is only a faint memory.
This data-sync initiative was completely designed as a money making venture for the “systems” providers and a complete waste of time and efficiency for the manufacturers (or at least for those of us “manning the process”).
Either there need to be sanctions for those retailers not active on any system or we drop the whole thing. I waste more time putting together spreadsheets for all the retailers demanding GTIN’s than I would if I could just publish our product list to them on-line.
In theory, it was a good idea. It’s the execution that is completely flawed and no merger in the world is going to fix it without some negative pressure on the retailers rather than the manufacturers.