The Four Hundred

You might have seen them lurking around your shop, but felt powerless to do anything about them. They're product data inconsistencies, and they could be costing retailers and suppliers up to $40 billion per year. The problem is that each major retailer, like Wal-Mart or Home Depot, has a different way of describing the products it puts on its shelves, and it passes down these inconsistencies to its suppliers. A relatively new industry body called UCCnet is trying to change all that.

While UCCnet is still in its infancy, the time could come when every manufacturer and distributor must conform to the new UCCnet product data standards or face giving up some business to suppliers that do what the major retailers want. With up to 30 percent of major retailers' tier-one suppliers running OS/400-based solutions, traditional iSeries software vendors like LANSA have recognized a business opportunity, and are beginning to roll out native iSeries UCCnet solutions.

Recently, Guild Companies had a chance to speak with Alan Christensen, LANSA's director of e-business solutions. Christensen has spent much of his time researching UCCnet issues in preparation for his company's product launch to support UCCnet.

UCCnet is a not-for-profit, neutral organization. It's an industry-endorsed initiative that was brought together by the major retailers to solve product data inaccuracies among trading partners. It started off in the food industry, because that's where a lot of the pain was, but it's rolling out to all the 23 industries that currently make up the Uniform Code Council. There are some numbers floating around that say there's roughly a $40 billion worth of inefficiency in the supply chain between the supply side and the demand side every year. It's important to understand that UCCnet is not an exchange. There's no ordering that takes place. It's the basis for higher level e-commerce processes. What that means is, until the retailers have the same information as the suppliers, you really can't get into higher level collaboration, because they're ordering the wrong products.

The major retailers that are backing UCCnet make up roughly $800 billion of revenue in the food industry, roughly 45 percent of retail dollars in North America. They adopted it because, obviously, it affects them. They are basically going to all of their suppliers; they aren't saying "you shall," but they are strongly suggesting that suppliers become a UCCnet subscriber so they can synchronize their manufacturing product data, referred to as GTINs [global trade item numbers].

In North American, the Universal Product Code (UPC) is 12 digits, and in Europe the European Article Numbering (EAN) code is 13 digits. It's not very efficient, because if someone in Europe wants to sell here in North America, they have to rebrand and give another UPC code. The GTIN is 14 digits, and is currently defined by 62 unique attributes. All those attributes are conforming to EAN and UCC standards. So that, if I'm a supplier, and I want to supply my item, and say it's 6 by 7 inches, I can't call it "inch" or "in" or whatever. I have to use EAN and UCC conforming data standards, so that my trading partner, wherever it may be, can understand what it is.

Some of the biggest problems start off with catalog errors. There is an AT Kearney study that says 30 percent of all item data in retail procurement catalogs does not match that of the supplier. Every UPC code, or stock keeping unit (SKU), requires roughly a half hour of cleansing per year to keep it in synch with what the supplier thinks it is. What happens is, you start with a product, and it goes through the supply chain; it gets abbreviated. The descriptions become so unreadable that the retailers don't know exactly what they're ordering sometimes. So sometimes a supplier will change its product from a 12-pack of 8-ounce yogurt cups, and then changes it to 6-ounce cups, and the information doesn't get communicated in an effective manner to the retailers. They order the wrong product, and what do you end up with? Deductions. And that's the biggest problem that suppliers are facing.

Which side--the suppliers or the retailers--are pushing the hardest for a permanent fix for the bad data?

Basically, the retailer is the dog wagging the tail, which is the supplier. What they're trying to do is push down their administrative costs to the supplier. It takes an average of six weeks to introduce a new product. One manufacturer may send a binding EDI document, like an 832. Another supplier may send it by an XML document. Another one might phone it in. Another one may fill in a form. Another one may send it snail mail. So the retailers are dealing with all these proprietary methods to get correct item information from their suppliers. And there are all sorts of manual errors. In fact, some retailers have these little electronic kiosks that they expect the supplier's sales rep to go up and key it in. So they're not getting the right information. It's not timely enough.

What happens is, a supplier or a distributor says, "Okay, Wal-Mart, here are three new GTINs, and here's all the information. And I know it's conforming because UCCnet will not even allow me to publish it to the Global Registry unless it's all conforming." So the retailer comes in and looks at his work list, and they can connect every five minutes, every hour, whatever they want to, and they see three new GTINs, published to me by ACME Corporation. They bring that into the retail system--they value add it--so they basically say, "This is a product that definitely matches our categories." Then they send back a notification saying "subscription approved" or "reject," "pend," "authorize," etc. So once a retailer subscribes to a product, every time a supplier makes a change, the Global Registry automatically disseminates that information to all the retailers that had originally subscribed to it.

What are the different options available to subscribe to the UCCNet Global Registry?

There are basically four categories of solution. If a subscriber to UCCnet has, say, 50 GTINs or less, they can opt to use the GUI that comes with the UCCnet subscription, called SYNCpoint. It's a very basic, rough GUI where they can manually re-key all their GTIN directly into a Web-based browser. And it will end up going to the retailer. Obviously, you don't want to do that if you have several hundred or several thousand GTINs. Then someone can hook up with a hosted solution, like Transora, Baolink, and World Wide Retail Exchange. Then you have a higher level of automation, which is behind the firewall catalogs, which get more automated. It's multi-source aggregation, but it incurs data replication, and the customer typically has to buy another box with that catalog software running on it. And the highest level of automation is direct integration methods, where LANSA and webMethods and IBM fit in, where we leverage ERP data directly and we support the full cycle through the workflow.

What are the costs associated with implementing a UCCnet solution for suppliers?

It depends on what level of integration they want. First, they have to subscribe to UCCnet as a trading partner. Their yearly fees are based on their annual revenue. A small supplier would pay a minimum of $1,500. Anywhere from medium to high-end, they're looking for automated solutions. Some of these suppliers are already members of organizations such as WWRE, Transora, and Beolink. They're basically exchanges that bring together suppliers and retailers. These companies offer a UCCnet connectivity service for a pay-as-you-play-type mode. To get to the higher end, to get to integrate with other solutions, it can run anywhere from $50,000 to $500,000. For an SMB [small and midsized business] shop--let's say it has 500 GTINs or greater--now we're talking $50,000 to $60,000.

We talked about the steps to e-collaboration. The tendency for true e-collaboration in the food industry is called CPFR, or collaborative planning, forecasting, and replenishment. In a nutshell, it's very sophisticated software that runs on the supplier side that looks at all these different factors, their production capacity, what the customer has ordered in the past, what their capacity is to store inventory, what their seasonal trends are, and, basically, the retailer says, "You're just delivering the product I need at the right time, like JIT [just-in-time manufacturing]. That's what CPRF is; that's the panacea. And you can't get into CPFR until at least you agree upon this GTIN. It's this Coke can, at 354 milliliters, and it comes 12 to a case.

Before going to a third-party provider like LANSA, should customers consult with their ERP vendor first? Are ERP vendors working to support UCCnet?

I can tell you we're in negotiations--I can't name names--with some major ERP vendors for them to OEM our product. Quite honestly, there's a lot of investment, and we've done our homework and put significant amount of time into this. For any ERP vendor to invest in this, it would have to be an alliance partner. Right now, there are no major ERP players in the iSeries marketplace that are alliance partners with UCCnet, other than J.D. Edwards.

It has a big impact. We learned in the early days as we started implementing this that our customers weren't educated enough as to what their responsibilities were. A lot of them thought, Well, I just buy this little adapter, click a button, and I'm finished. That's not the case. It's a lifetime commitment. And there's got to be ownership.

Where are we right now in terms of industry adoption of UCCnet? Has it reached the critical mass?

It's a lot lower than it should have been based on where it started. I think a lot of that has to do with the economy. Nobody expected it to turn upside down. I can tell you that every quarter they're signing up more partners. In the last six months, it's increased over 20 percent. But it's still, quite honestly, in its infancy. We're talking 300 suppliers. Think of this in numbers. The subscribers to UCC in North American number 300,000, and in Europe it is 900,000. So there are potentially 1.2 million subscribers to UCCnet. So there's a ways to go, but that's why you have to think ahead, and that's why we're ready with the product when that bulge comes.

What solutions does LANSA have for OS/400 shops to come into compliance with UCCnet?

We have a solution that's based on LANSA's technology, and it's part of our vertical Commerce Edition product line; it's called UCCnet Direct. It's a behind-the-firewall solution that sits right on the production iSeries or xSeries. We integrate directly with their item master, their product master in their ERP system, and this allows them to synchronize their "single point of truth" product data directly with the UCCnet Global Registry. It has a direct real-time communication with UCCnet, so there's no wait-and-see. On top of that, it's very difficult for a customer to make a mistake, because we put all the EAN and UPC referential integrity directly into our solution. We simply won't allow them to send a bad transaction. All the activity is done through an easy-to-use Web-based portal product that runs right on the production box. It doesn't require any modifications to be made to the ERP system. If they have 40 of the 62 [GTIN attributes], great. Then the other 22 you'll maintain, and they'll be populated, through our item extension. You don't have to touch the back end at all. We've got full auditing capabilities, non-repudiation, which is very important. We've put a lot of time into the workflow. It's completely table-driven, allows them to manage any type of internal activity within their item database. We also have the capability to import spreadsheets as a foundation for getting their data cleaned up. We allow them to take whatever spreadsheet format they're dealing with, suck it into our extension database, allow them to basically maintain all the attributes in controlled environment, with all the validation and workflows built in, so it helps them get prepared for actually publishing to UCCnet.