For the complete and official description of UCCnet you should review the material on UCCnet's website: www.uccnet.org. But for our purposes, we will define UCCnet's purpose and role as follows:
UCCnet coordinates the establishment of electronic standards for synchronizing product item data between retailers and their suppliers. But unlike standard setting bodies of the past, who only publish standards, UCCnet has actually architected a data processing infrastructure that all participants are obligated to use. UCCnet actively enforce the standards through the UCCnet applications themselves.
This is a significant departure from the role of previous electronic standards bodies and it has profound implications for how companies need to approach UCCnet-based data synchronization. UCCnet is not simply an extension of EDI or EC practices; it is a completely new model that complements existing order-to-payment transactions such as the purchase order, ship notice and invoice.
The most important reason why it’s important to my company’s business is that retailers such as Wal*Mart, Lowes, Food Lion, Ace Hardware, Lowe’s and J.C. Penney require implementation of UCCnet for their suppliers.
Data synchronization is a much broader term for making sure that all of the data required for maintaining trading relationships is kept current throughout the supply chain at all times.
UCCnet is currently focused on synchronizing of a sub-set of product item information between retailers and their suppliers. This is an important sub-set of the broader mission of overall data synchronization. As UCCnet adds new functionality such as pricing attributes and product images, it may grow to include the entire scope of data synchronization required to support the retail industries. This is an important distinction as retailers may require suppliers to send additional information which not covered by the UCCnet initiative.
UCCnet is not a catalog service in the traditional sense. It is designed to certify item information and orchestrate the publication and subscription process between trading partners. It is not designed to be the "system of record" for retailers or suppliers. And it is definitely not designed to provide on-line product look-up or "shopping" functionality.
There are three basic categories of item attributes: baseline, extended and "other". Baseline attributes are the most basic attributes associated with a product. These are the attributes that must be precisely defined for every product. For example, a baseline attribute would be a UPC. UCCnet enforces the use of baseline attributes rigorously.
UCCnet and the organizations that support it have recognized and allowed for the sharing of industry- defined "extended attributes". Extended attributes are defined by industry standards bodies. Some of these attributes might be the same from industry to industry, while others may not. UCCnet subjects extended attributes to more limited edits and validation than baseline attributes.
The third, "other" category includes those attributes that a retailer may require, but that are not currently defined by UCCnet. It is unclear how these elements will be handled. UCCnet may develop an approach to exchanging them within the framework of UCCnet or, in some cases, they may need to be communicated to your trading partner outside of UCCnet processing.
Wal*Mart is already doing UCCnet with manufacturers as are Shaw's and Food Lion. Others, such as Home Depot, Lowe's and Ace have programs underway which are requiring compliance. UCCnet is most definitely real and the rate of adoption by major retailers is accelerating. If one or more of your retailers is asking you to participate, you need to begin preparing now. Thousands of suppliers will need to be implemented in the next six to twelve months. There is likely to be a "log jam" of implementations as mandate deadlines approach. Completing your UCCnet implementation as early as possible may allow you to avoid costly delays, and insure that you are ready on time.
If you sell to retailers in different industries, you may need to provide different extended attribute information for each industry, but this would be industry by industry rather than retailer by retailer. For example, if your products are carried by both hardlines and general grocery channels, you should expect to see some differences in the message requirements for retailers in each channel. One proviso is that while all retailers expose the theory of “standards” It is expected that some retailers may "deviate" from the standards path so it is a good idea to implement a flexible solution that takes into account how retailers may implement UCCnet.
If your catalog service provides UCCnet certification functionality, then you may not need to worry - other than joining UCCnet and taking advantage of your current catalog service provider's functionality.
If your service provider is not able to supply UCCnet functionality - or if their offering is limited, then you might want to investigate other solution options. It is important to verify the full capabilities of any provider to make sure you are receiving the services you need at a reasonable cost. In the interim, there may be cases where a retailer requires item information to be sent via UCCnet and a catalog service but it is envisioned that UCCnet will supplant other catalog services data needs as UCCnet already requires more information than a traditional catalog service.
In a sense, UCCnet will replace the EDI 832/888 as they were originally intended, but UCCnet is much more than simply a new transaction set and business process.
EDI 832/888 transaction sets represent an early attempt to exchange item data using EDI, but they have not been widely adopted except in the retail department store industry. EDI is, by its nature, a batch oriented point-to-point technology for documents. UCCnet, by contrast, is more real-time in nature and it provides a common infrastructure for all trading partners to access.
For example, instead of one supplier sending an EDI 888 to fifty different retailers or a catalog service, a supplier can post item data to UCCnet just one time, using a series of defined XML messages. The supplier would then direct UCCnet, again via XML messages, to publish that data to the fifty retailers who would retrieve it from UCCnet according to their needs.
It is possible that you will be able to discontinue EDI 832/888s with some partners following an UCCnet implementation, but it is also possible that you will keep using those transaction sets, albeit differently, to convey non-UCCnet product item data to your trading partners. The following is a brief description of the differences between the EDI model and the UCCnet model:
EDI Model |
UCCNet Model |
| Document focused | Process focused |
| Exchange document with one trading partner at a time; one-to-one document sharing | Implement entire process, supported by many documents; One-to-many Document sharing |
| Use existing tools (EDI Translator) to implement new document | May be able to use existing tools for XML documents, but significant processing logic needs to be developed or acquired to implement the synchronization processes that the XML messages support |
With UCCnet, retailers are changing the basic premise of communication of item information between suppliers and retailers. In the past retailers have required suppliers to manually create product specification or listing sheets. These sheets were the basis of all of the retailers’ information on specific items. The information was used to update all of their internal systems (warehousing, logistics, POS, planogram, ordering, inventory etc). The manual system was inefficient as information was frequently out of date and was costly to input into multiple systems. UCCnet is taking the old "listing sheet" and requiring the information to be presented to the retailer in an electronic format. The original hardlines specification (2.1) required 151 item attributes to be communicated. As new retailers are added, the newest hardline specification (2.3.4) has added over 50 new item attributes.
Retailers are aggressively pursuing UCCnet implementation because there are substantial financial benefits associated with timely and accurate product item information.
Studies have shown that 30% or more of the information in retailer systems is different from the supposedly same information in the manufacturers' systems. These differences lead to errors in purchase orders, shipments, invoices and payments, which in turn lead to deductions and costly manual error resolution processes.
A recently completed A.T. Kearney case study found that grocery retailers could save between $700K and $1M per $1B in revenue every year by synchronizing item data with suppliers.
Additionally, retailers are trying to tap into their supplier’s item expertise to receive enhanced information on supplier’s products. UCCnet allows suppliers to publish more information on their products which can be used by retailer’s to sell their products.
Several large suppliers were directly involved in the development of UCCnet to ensure that the resulting processes were beneficial for retailers as well as suppliers.
The A.T. Kearney case study mentioned above also found that grocery suppliers could save between $800K and $1.2M per $1B in revenue every year by synchronizing item data with retailers. Supplier benefits come in many forms including:
Realistically, supplier implementation costs will vary widely based on the size of the company, the number of items sold, the number and quality of back-end applications to be integrated and the level of business process automation implemented.
A small suppler with fifty products can implement UCCnet for less than $30K - perhaps a lot less. A large, multi-division, multi-national supplier who offers thousands of products might spend $30K for an interim solution and then go on to invest several hundred thousand dollars on a full-scale implementation.
Just synchronizing with a retailer through a hosted solution can take as little as a week or two, once you have all the attributes ready. Implementing a behind-the-firewall solution could take anywhere from one month to many months depending on the size of your organization, the number of back office systems that require integration and the level of process automation you choose to implement. Experience has shown that the average company should allow for three months to implement an integrated UCCnet solution.
The first step is to develop a sound understanding of UCCnet and data synchronization. As such, it is important to find an alliance partner who can provide quality, general education to your organization and preferably one that you have had experience with. A sound general understanding of the issues is necessary before you can begin to evaluate the right solution and the right partner for your company. Look for guidance from a company that understands the history and guiding principles that led to UCCnet's creation. Generally speaking, consulting companies, especially those with some history in UCCnet, will be better able to provide independent guidance and the all-important, business process expertise that you will need to make effective decisions about how much to invest and what type of solution is appropriate.
First and foremost this is a business project. UCCnet has designed based on business processes that have for many years consisted of handshakes, phone calls, faxes, emails, manually filled out listing forms, and mailed documents or diskettes. Trying to implement an UCCnet solution without the detailed involvement of the business people responsible for these processes is a recipe for disaster.
Only business managers can make sure that the subtle aspects of your customer relationships are best represented, and that they benefit from the implementation of an UCCnet program.
As UCCnet is a cross-departmental solution, it is critical to implement a proven methodology for implementing UCCnet. The recommended approach is to establish a project team.
The critical first step is to establish a cross-departmental team to work on the implementation of UCCnet. This team will establish the project goals, educate themselves on UCCnet, receive management approval and establish timelines and budget to implement UCCnet. The first key of this team is to receive management approval for the establishment of a team to implement UCCnet
The following is a brief list of questions to be answered prior to establishing a project plan for UCCnet:
Project plans must outline the project and tasks for your UCCnet implementation. Some of the issues to consider in this phase are:
It is recommended that implementation of UCCnet be grouped into three phases; internal implementation, external implementation and software implementation. The implementation should start with implementing internally the business process and technology and then implement externally to UCCnet. On average a medium sized supplier should allow for three months to implement an integrated UCCnet solution.
1-888-SOFTCARE info@softcare.com (604) 983-8083 © 2004-2005 SoftCare EC Solutions