According to a December 2004 report from Venture Data Corporation (VDC), the automatic identification and data capture market is a $6.1 billion industry. The report also indicates that the wireless handheld scanner segment represents more than 10% of that and is growing at a staggering rate of 70% per year. The iSeries computing platform, incidentally, remains the critical application "run-time" solution of choice for a high percentage of enterprises within the manufacturing, distribution, and retail industries.

So, why are so many supply-chain organizations adding wireless handheld scanning to their existing system environments?

The answer is both simple and logical. Replacing, upgrading, or significantly modifying core applications of supply-chain information systems is very disruptive to operations, very time-consuming, and very costly. On the other hand, adding wireless automatic data capture (ADC) capabilities—barcode or RFID—to an existing supply-chain system's application need not disrupt current operations, can be done very quickly, and costs very little by comparison.

The Advantages of ADC

All ADC technologies offer the benefits of faster and more accurate data entry. For example, a barcode scanner can typically record data five to seven times as fast as a skilled typist using a keyboard entering data from handwritten forms. As for accuracy, human keyboard-driven data entry creates an average of one error in 300 keystrokes; this computes to 333 errors each day (17,000 per year) for a typical warehouse processing some 10,000 order lines per day. By comparison, scanned barcode data entry has an error rate of only about one in three million.

The case for implementing ADC technology has long been made, but wireless ADC brings even greater advantages to the table. In short, wireless ADC allows supply-chain workers to bring data-entry functionality to the source of the transaction. The big benefit is the timeliness of the data being captured.

For instance, rather than scanning barcodes for all received shipments at a fixed scanning location after deliveries are received and then updating inventory status, barcodes on pallets or packages can be scanned as they are removed from a truck on the loading dock, immediately updating the inventory system. This approach eliminates any potential latency between when goods that may be needed for a particular transaction are physically in hand and when they would typically show up as received in your information system.

The previous example actually illustrates a benefit of the use of real-time wireless ADC versus a batch (or store-and-forward) approach. Figure 1 shows the existing ADC methods and the distinguishing features of each.

Figure 1: Different types of wireless ADC approaches present different challenges. (Click images to enlarge.)

Which Method Should You Use?

The decision as to which of the above methods of wireless ADC to use is affected by many factors. Here are some helpful questions to ask about the specific processes you may be considering adding wireless ADC to:

• Does the current application screen where data gets entered into run as part of a centralized host-based software application with terminals (or PCs running terminal emulation) being used for data entry, or is it a PC-based, standalone application?
• Will the worker doing the wireless ADC be within a wireless network coverage area at all times? (Note: Some route-accounting supply-chain applications require field/service workers to go to locations where there is no wireless network coverage available, even via cellular).
• Does the data acquired as part of a wireless ADC process need to be made available to the enterprise immediately, or can it be uploaded at a later time? Although the data may not be needed immediately, could it still provide significant value if it were made available immediately after it was acquired?

The answers you get to these questions will play a big part in determining which specific wireless devices you will need for the various transactions and how they will need to function with your information system's applications. They will also help you determine whether or not you can simply add the use of wireless ADC devices as a new means of accessing your existing application programs and screens or whether you will have to create new applications and/or special procedures to handle it.

The Terminal Access Approach

Going back to our previous example, you may have a host-based, terminal-driven, character-based data-entry screen (IBM 5250/3270 "green-screen" or UNIX/Windows "VT," etc.) application for entering received-goods data at the receiving clerk's desk. To take advantage of the benefits of wireless ADC to capture received-goods details (scan a barcode) as they come off the truck, there are a few things to consider. If you want the scanned data to be immediately reflected in your centralized, host-based inventory-management system, you can actually use the same applications/screens you currently offer to users on a fixed terminal at their desk—except now on a wireless, handheld terminal device they will use on the truck.

Because the application itself is not running on the wireless device, but merely accessed by the device for input/output, the reliability and performance of the wireless network connection will be a critical factor. The same is true of your current desk-based terminal accessing the host system over your wired network, but connectivity there is a given.

Also, it is very common these days to access a host-based application data-entry screen with a PC running terminal emulation software so it looks and acts like a terminal device. Therefore, you will see a lot of handheld wireless devices that are actually PCs running some version of a Windows-based operating system but actually being used as wireless terminal devices by running terminal emulation software on them to access a host-based application over the air.

All the leading wireless handheld device manufacturers our company deals with (Symbol, Intermec, PSC, AML, etc.), as well as their major solutions resellers, tell us that although the wireless devices are actually handheld Windows PCs, some 65–70% of all the wireless devices they sell today are still being used as wireless terminal devices, not running standalone PC-based applications.

There is a good reason for this. It is far easier to take an existing application with its processing logic and databases running on a centralized host system and simply add wireless terminals as a new means of accessing it, versus putting all that functionality onto the handheld device itself. Most of these systems were written years ago and are very complex. This approach allows organizations to take advantage of all the benefits of wireless ADC without having to develop new applications or make heavy modifications to existing ones. If you're a developer, the process is adaptive to the point that you don't even need to make any code changes. In short, keeping the operation terminal-based lets you preserve your legacy application and add mobility at the same time.

That said, you do need to be careful to implement a wireless terminal emulation solution that features functionality that shields the users from the negative effects of periodic wireless outages, which will happen. With a wireless terminal, users can be cut off from the host-based application if they go out of wireless network range or have any problems that prevent access to the host where the application and databases reside.

As most of your IT support resources are also centralized, you should likewise look for a solution that features some sort of centralized management facility so your help-desk staff can see what the wireless terminal users see on their devices and control them remotely. This is extremely important if you will have wireless terminal users in remote facilities (distribution centers, retail locations, etc.).

When Terminal Access Is Unavailable

Sometimes, however, it is not possible to use a wireless terminal approach, and it becomes necessary to run a standalone, PC-based application on the wireless ADC device itself. This can happen if the wireless ADC user routinely needs to acquire data with the device in areas where no wireless network access is available.

The challenge with running a standalone application on the device itself is that all the needed databases and screen applications must be installed and maintained on the device so it can function on its own without connecting to another system. This creates many additional challenges that do not exist with a wireless terminal approach.

For example, consider the challenge of keeping database items like price codes or standard costs up-to-date on each of your handheld wireless computers that need that data for validating scanned values in the field. It is very possible that a change has been made on the centralized system/server, but the handheld computer functioning in a standalone mode will not see that change yet.

This also reminds us that wireless and real-time do not necessarily go together. If a potential user of a wireless ADC device is inside some sort of wireless network coverage area (even cellular) most of the time but routinely needs to acquire data while outside wireless coverage, then the use of a standalone application on the device will need to be considered.

On the professional IT services side, our company has seen and dealt with many of these situations in the real world. The solution involves either the store-and-forward approach—in which the data is collected while the device is out of range and then uploaded/validated when the user gets back in wireless network range—or just enough of the application logic and data needed for validation is maintained on the device through custom-developed synchronization routines so that everyone is using the same screens, logic, and data.

The Bottom Line

Wireless ADC can bring a lot of value to your organization, enabling it to have up-to-date, accurate inventory data at the disposal of those who need to make informed decisions about supply-chain related events. Almost everything is possible today. There is software available that provides centralized management while reliably extending iSeries supply-chain applications to wireless devices through 5250 terminal emulation. There are also focused professional services that can modernize, extend, or provide integration capabilities for mature enterprise applications running on the iSeries computing platform. But you will need to do your homework and seek out experts who can walk you through the various methods so that you can see what will work best, considering your specific information systems environment.

Mike Pagani is vice president of sales and marketing for eBusiness Solution Pros, an IBM iSeries Business Partner, developers of Stay-Linked wireless terminal emulation/session management software, and provider of professional services solutions for inventory control, warehouse management, manufacturing, distribution, and retail application environments. During his nearly 20-year career as an IT professional, Mike has held senior marketing and product management positions with several prominent computer software, hardware, and network technology vendors. He is also a regularly invited speaker at industry trade events. He can be reached at This email address is being protected from spambots. You need JavaScript enabled to view it..

Also Read

TechTip: A Primer to Bootstrap 4, Part 2

TechTip: A Primer to Bootstrap 4, Part 1

A Hand-Holding App Builder for Handheld Devices