TORONTO USERS GROUP for Midrange Systems
TUG eServer magazine May 1996: Volume 11, number 5
Data Collection Issues & Myths
By Jeff Lem
y golf instructor is always telling me, "If you can visualize the swing, you can do it." The reason for this is simple: it's a confidence builder and a form of practice. On the subject of data collection it's the thinking and planning that goes into a project that determines its success. Here's a potpourri of issues you should consider before embarking on your "excellent data collection adventure".
Let's begin by dispelling some myths:
Now that we have some misconceptions out of the way let's start with the issues. Before you begin a data collection project you must consider these specific elements:
- I don't know a thing about bar coding. And you may never need to! In reality data collection is more than using bar code symbology, it is the process of moving the data capture function to the place where it happens. Taken in this context bar coding is not the issue, rather one must ask: "who will perform this new activity and how?". By NOT using bar codes immediately, you won't need special printers, scanners, software, or specialized training. This can save you time and money.
- It'll cost lots of money. Data collection solutions run the gamut from a few hundred dollars to the millions. Any process requiring hand written forms or entering of information through a keyboard are candidates for data collection. A simple solution may involve integrating a weigh scale to a factory floor terminal so that workers don't have to key in the weight. As a first project choose an application that is bounded, clearly identified, and has minimal downside risk. Coincidentally these are also the projects that cost the least.
- I'm going to have to rewrite my apps. Nonsense! A lot of solutions involve attaching a keyboard wedge which means all scanned or transmitted data goes into your application as if someone entered it on their keyboard. Other solutions involve the importation of a flat ASCII file and in the case of wireless data collection terminals they can function under 5250 or ANSI emulation.
- It takes a long time to implement. Again its question of how much you want to bite off in the first go around. I've implemented large projects involving printing and scanning of bar codes and wireless data collection terminals in under a week (mind you it couldn't have happened without management's unqualified support).
- Data Capture at the Source
- Transmission of data captured at source
- Data Collection Equipment
Data Capture at Source
Once you've identified your application, you have to determine how to get that information into its digital equivalent. If you're eliminating time sheets, work orders, or some other paper form be prepared to replace them with a keypad, scanner, or both. Contrary to what I said earlier about bar coding, it does offer some tremendous benefits. Bar coding is fast, up to 20 times faster than manual systems. It is more accurate, manual entry systems have errors as high as 1 in 300 versus 1 in a million for bar coding.
Whether or not you're going to use bar codes may be decided by who has to do the data entry. If the person performing the data entry function resists the notion of using keypads you may have to implement a combination of scanning and keypad entry. To capture transactions with bar codes you should consider the following areas:
Transmission of Captured Data
- symbols on incoming products
- symbols on work in progress
- symbols on finished goods
- location tags and employee identification
- scannable templates or menus
- scannable work orders
This involves the transmission of data from the source to the host application. In some instances this may not be an issue because information is entered as keyboard data via a wedge device. But for other applications such a field work, an AS400 terminal would not be feasible. In these cases your host application must have the capability to support data importation either on a batch or real time basis. Your decision to update your data files in either real time or batch mode will have a major impact on the nature of the interface required and the selection of the data collection hardware. Other issues to consider:
Data Collection Equipment
- host computer communications to and from the
work centre (may need to write code so that incoming data is automatically
picked up and written to the appropriate data files)
- impact on the host processor by devoting memory
to a data queue for real time processing
- data collection terminal communications to and
from the work centre (moving the data from the field or floor
back to the host)
- data entry time and operator ID stamps (useful
for audit trail purposes)
Traditional data entry functions are accomplished by people recording data manually with clipboard, pencil, and printed form. These source documents are then hand carried, mailed, or faxed to data entry personnel for inputting to the computer. Data collection projects seek to transfer this process to the people who are actually doing the work. An argument against this transfer is the additional labor required and the potential decrease in productivity. However by selecting the right equipment, productivity and data accuracy should actually go up. Within the realm of data collection hardware you have the choice of on-line and batch systems. On-line systems can be hardwired or wireless. Both on-line and batch system can be either fixed position or portable.
Batch Based Equipment
- Hardwired Wedges.
Provide a seamless link between the computer terminal and the
scanner. Connection generally consists of physically locating
the device between the keyboard and terminal or via the RS232
port. These devices will support up to 1,500 terminal types, all
major bar code symbologies, and can perform some data editing
features such as carriage return, line feed, and elimination of
unwanted character strings. Little or no programming is required
to support wedges.
- Full Featured, Fixed Position
Data Collection Terminals. These specialized
terminals are designed for industrial environments. They feature
smaller footprints, hardened cases, special mounts, and many capabilities
associated with a PC or computer terminal. To support this equipment
the host application must be able to download and upload files
to the data collection network. When implementing these products
factor in costs such as cabling, conduit, and separate power lines.
These terminals are best used in situations where the data collection
process is relatively static for example time & attendance
and work in progress activities.
- Wireless Terminals.
For situations where a hardwired link is not possible, the alternative
is to use radio frequency (RF) communications. RF equipment are
linked directly back to a work centre or host computer and permit
on-line inquiry and updating of records and files. A typical RF
installation may include hand helds and forklift mounted units
all transmitting and receiving at a specified frequency with a
base station/communications multiplexor. There are currently two
general categories of RF systems: narrow band and spread spectrum.
Narrow band systems have the advantage of wider coverage but require
a DOC license and transmit at slower rates (typically 9600 bits
per second). Spread spectrum on the other hand does not require
a license, transmits at higher rates (up to 1 mega bit per second)
but have a shorter range. A competent vendor who offers both types
of technologies should be able to advise on which is best for
As opposed to being actually on-line to a database in real time, batch based systems work independently of the host computer. Where interaction occurs is when data is uploaded to the application. Batch based system require programming work such as additional software is at the host level to permit downloading and uploading. The units themselves must be programmed to perform the various data capture functions. While newer products support standard programming languages such as C or BASIC, it remains a challenge to develop an application that is easy to use and is event prompted. Generally speaking batch based units are most appropriate in field applications such as sales order entry and internal functions like inventory counts. And one last point, batch based systems are usually less costly than on-line solutions.
Irrespective of the hardware chosen, the environment that the equipment must work in can make or break your project. For instance liquid crystal displays shut down at high temperatures and freeze up at very low temperatures. Batteries also have a shorter life at low temperatures. The moral of the story is check the specifications carefully and then ask to speak to some references; manufacturers' ratings tend to be overly optimistic. Aside from equipment, bar coded labels and printers are also temperature sensitive. Special label stock and adhesives have been developed to address a multitude of situations.
In Lewis Carroll's Alice in Wonderland, the Chelsire Cat had a line that seems simple on the surface but speaks volumes about proper planning. That is if you don't know where you're going then really any road will do. Defining your project by considering some basic issues will ensure your first step is the right one.