"We need to turn data into information and technology into processes."
— Jon Chorley, senior director of development
for Oracle inventory and warehouse management systems.
Chorley's statement neatly sums up the challenge today: It's not technology that's the great issue; it's making it all work effectively in a real-time, demanddriven environment.
Automatic identification and data collection (AIDC) is — or should be — a pervasive tool in supply chain execution. But collecting data is only the small first step in developing a system that provides bottom line benefits.
The AIDC quandary
Whether the technology is bar code, radio frequency identification (RFID) or speech systems, AIDC applications stretch from suppliers through the warehouse and out to customers.
Within the warehouse, AIDC applications also proliferate. For virtually every business function, data can be collected — or activities directed or verified — through some form of AIDC technology.
Bar code or RFID labels can be used to identify items, cartons, pallets and locations; they can be used to receive shipments, close purchase orders, authorize payment, update inventory and identify storage locations; they can be used to confirm picks, verify orders, direct automated sortation equipment, track items or cartons staged for shipment, identify pallets and contents and facilitate the creation of 856 ASNs.
Employee ID badges can have a bar code, magnetic stripe or RFID tag for access control, automated T&A, equipment or tool checkout.
Speech systems, mobile computers, pick-or put-to-light systems can be used to facilitate inventory, pick/ putaway, order status and more.
This list isn't anywhere near being comprehensive. There are simply too many options and too many ways to implement AIDC to go into detail. Suffice it to say, there many options and many ways in which AIDC can improve data collection and warehouse operations. Choosing the right technology and vendor may be difficult, and RFID implementation is admittedly still a bit problematic, but the options are there and most of them have standard interfaces to make integration easier.
And, of course, WiFi wireless LANs (WLANs) can tie everything back to the mainframe.
And that's where things get messy.
The system quandary
Some companies have quietly, or not so quietly, begun wondering what real benefits RFID offers that bar codes don't. Bar code systems, in fact, can be designed to uniquely identify individual items, associate item serial numbers with various levels of uniquely identified packaging, be automatically read by fixed location scanners as cartons are palletized, then be used to track pallets as they're run past loading dock scanners onto or off of trucks.
Looking at the EPC system's overall structure, RFID is only one component. Given bar codes with the same data, the system could work perfectly well.
So some companies are asking, "Why do we have to pay for RFID when we could do all this with bar codes?"
Why? Perhaps the question should be, "Why haven't you already done all this with bar codes?"
The capabilities have been there all along; much of this could have been done with bar codes; it wasn't.
Ignoring some of the additional benefits of RFID for the moment, perhaps the greatest benefit of RFID lies in its disruptive effects on reforming business practices.
In many ways, RFID is to corporate data infrastructure what Y2K was to legacy systems in the last decade. By forcing a change in data and communications, RFID mandates will, in the view of one industry expert, finally get companies to do what they should have done 20 years ago.
The data quandary
Forced to focus on radio frequency identification (RFID) to meet current customer mandates or to prepare for anticipated mandates, many companies are struggling to find an adequate ROI for RFID implementation. And, because standards and systems are still evolving, many have become bogged down in trying to understand the physics of system implementation.
But, according to Bob Moyer, president of FullTilt Solutions, focusing on the physics of RFID puts the emphasis on the wrong problem. The real issue, he insists, is the data.
RFID mandates aren't the only ones coming from customers. There are also requirements to comply with UCCnet data synchronization.
Data is the fundamental building block of any AIDC or IT system. Without the ability to communicate product information — both internally and among trading partners — any effort to streamline operations is ultimately doomed to failure.
Internal confusion is one of the most common occurrences. Marketing may have its own way of describing an item, purchasing another and warehousing a third — each meeting a department's particular needs.
The same level of packaging might be called a case, a carton, a pack or a unit, depending on departmental preference.
In the day of stovepipe operations, this kind of variation could be tolerated since systems weren't required to talk to each other. In today's real-time environment, however, all parts of an organization have to communicate with all parts of a customer organization.
That's why many customers are demanding compliance with UCCnet. The problem, according to Moyer, is that much of the information already sent to UCCnet is wrong because companies haven't developed a strategy for product information, that is, a way of determining the source of product "truth."
That's where offerings such as FullTilt's Perfect Product Suite come into play. A knowledge base repository of product "truth" is established for internal product attributes. FullTilt then dynamically translates each department's description of a product's attribute for a complete and consistent answer available across the enterprise that can be seamlessly communicated to ERP systems such as SAP, People-Soft/JD Edwards and Oracle, and then out to their customers or UCCnet.
Maintenance is the other major issue in data synchronization. Mapping existing data structures is a significant task. And once it's done, the repository should be the sole source for all product information. Thus, as information is added or changed, it is done only in the data repository; then, through workflow automation, the internal product information repository should push and pull the applications that use it both inside the firewall and outside it.
Data synchronization is, according to A.T. Kearney and others, the very necessary first step in developing a successful RFID implementation strategy.
As painful as this may sound, the next step may be even more painful.
Gathering a great amount of data — or communicating it with business partners — does nothing unless systems are properly integrated and the data is meaningful.
RFID, for example, will provide a huge flood of data. Because it will be possible to read tags on cartons as well as pallets during receiving, systems have to be developed to read the appropriate tag at the appropriate place.
And a pallet that sits in a reading portal for a few minutes, for whatever reason, will be read over and over again. Only the first instance of this data is information. The rest is noise.
Or take the instance where a pallet is read coming off a truck, then read again going back on. Is the lift truck blocked by other traffic and forced to move out of the way? Or is this a case of product diversion?
Timing may be the determining factor here. If other pallets are read between the first and second time the suspect pallet is identified, then perhaps it is an attempt to divert product — assuming the pallet was supposed to be delivered and not just loaded in the wrong order.
Having the ability to collect more data in more places with less effort places tremendous burdens on the IT infrastructure.
That's where RFID middleware or RFID-specific modules become critical.
Chorley's assertion that the challenge is to turn data into information definitely applies here. Of all the times data may be read from an RFID tag, it is possible that only one read is really a business event. The same can also be true with fixed location scanners for bar codes — particularly when there are multiple symbols on a shipping label. The application might require only the SSCC-18 and not the P.O. number or ship date or any other data on the label.
Catalyst, RedPrairie and other suppliers have developed RFID middleware that handles many of the data managementissues. Oracle also offers many rules-based options.
Most new middleware offerings focus on RFID but, again, the considerations apply to all aspects of AIDC.
These products can parse and filter data so that only relevant data is passed to application software. In addition, they will enable rules-based decision-making and localized modification of business processes as they apply to RFID — without having to modify the core ERP or WMS application.
Here again Chorley's statement applies: businesses need to transform technology into business processes. And here's where the other great quandary may be solved.
The ROI quandary
Where, in all these changes, is the ROI? Time and again, one hears that the ROI comes from greater operating efficiencies. But what, exactly, are those efficiencies?
Taken individually, they probably don't exist. Taken as an overall business improvement process, they can be truly impressive.
Two major consumer goods manufacturers have seen a reduction of 80 percent in new product launches through proper data synchronization. Another has seen a 75 percent increase in order accuracy and a 25 percent reduction in inventory. And these companies had already gone through the "lean and mean" meat grinder.
Other benefits may be "softer" but can produce real results.
Consider the time spent entering duplicate information across multiple internal systems; the effort expended and errors generated in translating customer order quantities into quantities used by marketing, warehousing and suppliers; consider the waste of fulfillment errors, overages, shortages ( including administrative, warehouse and transportation costs); consider the time wasted looking for misplaced product or product that isn't there; consider the cost of shrinkage; consider the cost of the money that's required to maintain an inaccurate inventory. These are process problems that cannot be solved by technology alone. They require an enterprise-wide desire to effect change.
Here, companies are a little less willing to share numbers since they point to inefficiencies within their own systems. But when you look at the roster of companies on the consumer goods supplier side that have lined up behind initiatives such as UCCnet and EPC, it's clear that they've considered all these issues and have found a healthy ROI.
While technology enables efficiency enhancements, it's actually process changes that deliver them.
Gathering piles of useless data at the speed of light delivers nothing. Sifting through that data to produce meaningful business transactions that are immediately actionable is what delivers the ROI.
The business aphorism of the 1980s is still true today: "When the pain of change exceeds the pain of the status quo, change will happen."
The demand for real-time information will not create change. The demand for accurate real-time information will demand change.
And, while AIDC can deliver accurate information in real time, it's developing the synchronized, interconnected systems to make use of that information that is today's challenge.
The changes required to develop these systems may be, for many companies, extremely painful. But the result of not developing them will be even more painful.
It has been suggested that, for many companies, information contributes as much to the bottom line as the products and services they make or sell.
Moyer puts it another way. "Companies," he says, "need to be 'information agile' for the demand-driven supply chain."
And that may be the best aphorism for the new millennium.
For More Information
- A.T. Kearney, www.mhminfo.com/3920-339
- Catalyst, www.mhminfo.com/3920-340
- FullTilt Solutions, www.mhminfo.com/3920-341
- Oracle, www.mhminfo.com/3920-342
- PeopleSoft/JD Edwards, www.mhminfo.com/3920-343
- RedPrairie, www.mhminfo.com/3920-344
- SAP, www.mhminfo.com/3920-345