This column usually focuses on things you need to hear about. This month, it will look at something you probably don't want to hear.
That's right, I'm going to talk about why you should spend more time in more meetings. Specifically, I want to talk about meetings that set standards that your company will eventually have to meet.
It should go without saying that standards generally help streamline business and result in lower equipment and software costs because things are, well, standard. Some of you might remember the chaos that resulted from early bar code "standards" where every group had a slightly different way of doing things that sometimes conflicted with other ways, making the bar codes unusable within your own facility. Or maybe you remember when wireless data communications equipment used proprietary methods, which made interoperability impossible. All these things led to higher costs, greater complexity, and limited vendor options.
Over the years, however, thanks to a handful of companies and individuals who realized the folly of having non-standard approaches, we've achieved a significant level of standardization. At the same time, I'd wager that many of you have seen standards published that a) you couldn't understand, and b) when you did understand them you thought they (or the people who wrote them) were crazy.
And therein lies the problem—and the point of this column. Without the active participation of people like you (you know, the people who actually have to make things work), standardssetting committees sometimes go off the deep end without even knowing it.
Let's take one case in point: the EPCglobal data structure. If you haven't been following this (and it's entirely possible that you haven't seen the documentation because it has been kept to a relatively small group of EPCglobal members), the proposed data structure changes the way the product code is represented. In addition to adding a serial number (which isn't an issue), the EPC structure moves the indicator digit (packing level indicator, PI) from the leading position in the data string to between the vendor code and the product code. In other words:
UPC: PI+Vendor_ID+Product_Code
EPC: Vendor_ID+PI+Product_Code+Serial_Number
From a purely theoretical perspective, this makes sense since it puts together two pieces of data (packaging level and product code) that seem to belong together. It sounds innocuous enough until you realize that the Vendor ID and the Product Code can be variable lengths. Suddenly, it's impossible to determine the packaging level (i.e., quantity) without going to either an Internet lookup or an 856-ship notice manifest. When this structure was developed, it had all the best intentions. The problem is, you have to parse the serialized global trade identification number (SGTIN) to figure out what you have. And that's only possible when you know the length of the Vendor ID.
The group developing this structure was either unaware of, or ignored, existing standards and the way things were being done. That allowed them to design an elegant but extremely cumbersome (some say " unworkable") system that places tremendous burdens on companies who have to add yet another level of complexity to their system software (which is going to require wrenching enough changes without messing about with the data structure).
While edgeware and middleware providers are addressing this issue to a greater or lesser degree, the fact remains that it shouldn't have been necessary at all. Had enough users who understood how things are being done (and how they need to be done in the future) been involved in developing the EPC data structure, it would have followed the existing UPC/EAN structure. Unfortunately, they weren't so it doesn't.
So, are you beginning to see the benefit of being actively involved in setting standards? Yes, meetings take time and sometimes require travel budgets but when you weigh the cost of participating in standards meetings against the costs of having to comply with a brilliant but unworkable standard, the bottom line is quite clear.
Get involved in developing standards that will affect your company for two reasons: First, you'll understand the motivating issues and functional requirements and be prepared to capitalize on the standard once it's published and enforced, and second, by helping to develop the technical or data content of a standard, you can help ensure that it can actually be implemented and benefit (or at the very least, not hurt) your operations.
By the way, there is still some active debate about aligning the EPC data structure with the UPC/EAN structure. If your company is a member of EPC, voice your opinion and take a hand in your own destiny. Contact EPC through www.epcglobalinc.org.
Bert Moore
