With all the advances in data collection and data communication these days, it's now possible to gather and disseminate completely useless information at the speed of light.
Useless? Product data and shipment information is useless?
Absolutely—unless all your trading partners know exactly what your codes mean.
Sure, many of you have been muddling along with "catalog number," "U.P.C. code," "old product number," "re-order number," and more—all of which have a variety of attributes attached to them. And each variation at one time made sense.
When data was manually entered, adjustments could be made by workers, noting quantities or product codes from the text on cartons or shipping labels. When bar codes came on the scene, databases had to be modified to include a variety of "alias" fields to accommodate historical product codes and quantities.
But that's just the tip of the problem. Product descriptions vary from supplier to distributor to customer. What's worse, product attributes and descriptions can vary from department to department within a company. In a business environment that is more and more database-driven, even small differences can make data fields incompatible.
Today, with the impending RFID mandates and the growing need to seamlessly— and automatically—exchange data among trading partners' databases, those "alias" fields and inconsistent product attributes and descriptions are becoming a boat anchor on corporate IT systems. And that boat anchor is getting heavier and heavier all the time.
Many articles on RFID have proclaimed that the tangible, bankable benefits of RFID will be achieved through process changes. Many of you have probably wondered, "What kind of process changes?"
Here's one: data synchronization. RFID will require synchronized data among trading partners. That means developing a single database for product data and standardized attribute fields. The benefits are the elimination of redundant data entry points, multiple database storage and maintenance requirements and reduced IT workload.
Even if you're not under an RFID mandate, standardizing your product codes and descriptions will return real benefits. But it won't be without a certain amount of pain and bloodshed.
The reason most companies haven't already undertaken data synchronization is that it is a painful process involving multiple departments, legacy systems, trading relationships,and budgetary considerations.
Simply deciding which descriptions to use in a particular data field can be a major struggle. Convincing people to give up their local databases in favor of a single, centralized one is fraught with peril. And understanding and addressing the needs of all the different departments—or convincing them their requirements are out-dated—is time-consuming and often acrimonious.
Painful? Absolutely. Worth it? Absolutely. Companies that have gone through the process have reported "substantial" savings—though few are willing to give real figures. And, rather like removing an adhesive bandage, companies can choose to experience their pain all at once or a little at a time.
Some companies have committed to putting their entire product line on a third party system such as UCCNet. By committing to this approach, every department has to relinquish control—something that, in some companies, makes the pain a bit more tolerable.
Others companies, particularly those with a high product changeover rate such as fashion and electronics, develop common identification and attribute definitions for each new product and packaging variation. This allows them to work the kinks out of the system and move to standardized data on a more manageable time scale. At the same time, because of the "churn" in their product line, they are still moving fairly rapidly to standardized data. (Putting the effort into a product that may have only another six months to a year lifecycle simply isn't cost effective.)
There's one other data synchronization caveat. You can't go it alone. Standardizing data isn't productive if suppliers or customers continue to use legacy systems that aren't compatible with your streamlined data files. It will require a cooperative effort to convert existing products to standardized data.
As painful as the prospect may be, it's not a question of whether you need to standardize your data to enhance data exchange with your trading partners and regulatory agencies but which method best fits your product mix and trading relationships.
