IDAT Consulting | Developing Real Solutions <META name="resource-type" contents="a-real.html">; <META name="description" content="Developing Real Solutions."> <META name="keywords" value="Consulting ADC AIDC Automatic ID"> <META name="distribution" content="global"> <META name="copyright" content="Copyright Bert Moore, contents may be used upon request and with appropriate reference(s).">

 
IDAT logo
Article Index
 

  Developing Real Solutions

Bert Moore

The other day, I decided to "get organized" by putting contact names and addresses in Microsoft Outlook to use when writing letters and addressing envelopes. If I could just click on the contact name and "new letter," I reasoned, what could be easier? I developed a special form for this type of contact then dutifully keyed in all the information.

When I went to use my new system, however, I discovered I couldn't use my existing letterhead and envelope formats. I had to use the defaults, which I didn't want to use. To use the names and addresses, I ended up having to cut and paste each individual field into my letterhead and envelope formats.

And this saves me time how?

Automation projects are sometimes like that. What sounds great in theory isn't so great in practice either because the system isn't as flexible as we expected it to be, because we didn't fully investigate what our "improvements" would mean, or because we've only implemented part of a solution.

So, how do we avoid "improvements" that actually slow things down or aren't cost-effective?

First, we look at the application from the workers' point of view. What movements must they perform? Where are the bottlenecks (what problem are we trying to address)? What do they think would make them more productive? Will implementing AIDC actually improve things and, if so, where should it be put? What other modifications to the existing process might make sense or be required? What is the impact of all these changes on the job or overall process?

By way of example, I'm looking at an application to track items that are taken off pallets, manually sorted onto other pallets then hand-loaded into trucks. Information about each item is manually recorded as trucks are loaded then compared with a printed manifest. This provides a double-check to ensure that all the items, and the right items, have been loaded.

In a larger operation, moveable roller conveyors with fixed location scanners might make sense. But in this case, the time it would take to set up or move the conveyors would be greater than the time it takes to manually unload and sort the pallet.

Overhead scanners at the loading doors that would automatically read a bar code on the item as it's loaded onto the truck is one possible solution. This wouldn't require employees to deal with handhelds or even wearables.

However, drivers need handheld scanning terminals for tracking deliveries.

For pure efficiency, overhead scanners at the doors is the best solution. Hand scanning items as they're loaded balances efficiency and cost. Even though hand scanning takes time, it eliminates most of the time to read and hand write information.

But wait. AIDC alone isn't the answer.

Other changes are required to develop a real solution. The information from the manifest needs to be downloaded to a local computer in advance. Then, it can be compared to a batch upload from the handheld or, even better, loaded on the handheld in advance, or compared to the data from the overhead, for instant and automatic verification of each load.

Without the availability of a downloaded manifest, it may not make sense to implement an AIDC "solution." Scanners would only be able to capture data, not warn drivers not to load an item. Data collected by the scanners would have to be printed out and visually compared to the manifest. This incomplete "solution" might, in fact, waste more time than it saves.

This column was originally published in the April 2000 issue of Material Handling Management.
Copyright © 2000 Penton Publishing. Used with permission.