The basis of any business application's ability to control and manage business processes is transfer of data. IT has come a long way from the early days when the only way to transfer data back and forth was manually through a stationary computer terminal. Today, mobile data collection uses bar-coding and radio-frequency (RF) devices to automate data collection and transfer to your back-end system or to your process control systems.

The benefits of automated data collection are increased accuracy and speed of data exchange (bar-code readers), direct data transfer and event triggering (process control systems), and last but not least, bringing the data collection point closer to the process — for example, to the shop floor or warehouse. Now, data can be collected and posted in real time and without the use of paper. The operator can make decisions based on real-time data that he or she can look up on a mobile device. Using modern technology, the application can be designed and configured much closer and better aligned to the process as it flows.

Mobile data collection in conjunction with bar coding is one example of enhanced data collection and data flow. If you work in a manufacturing or warehousing environment, you likely already use various types of mobile data-collection devices and bar codes to collect and post data and possibly trigger events to initiate subsequent steps of the business process.

In the last five years, I have helped a number of companies implement mobile data collection within an SAP environment. What follows is a review of the expectations you should have before implementing mobile data collection, and an overview of the most commonly used technology available for use with the SAP environment. My goal is to give you enough information to decide what general architecture and hardware is appropriate for your situation.

The Approach: Process-Specific and Simple

Applications for RF devices are usually developed to fit a business process. The application logic should be very simple and intelligent at the same time, requiring as little bar-code scans, data entry, and keystrokes as possible. The screens and flow logic should also be kept very simple. This approach helps with speed and does not disrupt the operator's real job. It may even help operators who are intimidated by busy and confusing R/3 transaction screens. Using bar codes allows for significantly faster and more accurate data entry, further simplifying, expediting, and enhancing the overall quality of the data entry.

Real-time postings provide great potential for business process improvement throughout the supply chain. Just think about available-to-promise (ATP) and availability checks and how they rely on accurate and up-to-the-minute information. The availability of real-time data on the shop floor through the ability to query and search data right from the shop floor provides great decision-making support and eliminates the need for traveling pieces of paper (e.g., a picklist).

How Is It Done?

Until a few years ago, middleware solutions were widely used to enable communication between a mobile data-collection device and the back-end system (Figure 1). Middleware is a separate system with its own logic and data repository that acts as the “middleman” between the front end (process side) and the back end (application side). Typical middleware solutions were designed to operate — at least for a limited period of time — independently of the back-end system. The middleware would validate and process requests received from the front end based on its own logic. It would then periodically sync up and exchange data with the back-end application.

Figure 1

The relationship between SAP R/3 and middleware

Middleware applications were selected for two main reasons:

1. They constituted highly specialized systems for specific applications that offered superior functionality over the more general ERP packages.

2. They operated independently of the back-end systems, allowing for parts of an organization (e.g., the warehouse) to operate even if the back-end system or the data line to it was down or overloaded.

Middleware might still be the preferred option in certain cases where very specialized functionality is required. In the majority of application areas, however, middleware is obsolete. SAP R/3, for example, offers superior warehouse management functionality with special features such as complex and customizable placement and picking strategies.

Technological advances in the area of high-availability for both large system landscapes and broadband data lines at reasonable cost have made the second reason for using middleware moot.

In today's ERP world, the disadvantages of middleware far outweigh the advantages in most cases. Those disadvantages are lower levels of integration in the overall business process, lack of real-time availability of data in other areas of the organization, and added complexity to the system landscape.

Instead, so-called “translators” are used in a typical ERP environment. A translator also acts as a middleman between the front and back ends. However, all business logic and processing remains in the back-end system. The translator merely enables a non-PC device — for instance, a handheld RF terminal with an integrated bar-code scanner and a character-based screen — to directly communicate with the back-end ERP system. SAP's version of the translator is SAPConsole (Figure 2). (Third-party products with similar functionality and features have been on the market several years prior to the introduction of SAPConsole.)

Figure 2

SAPConsole allows mobile devices to communicate with SAP R/3

Using SAPConsole has two additional advantages. First, the entire transaction logic remains in the back-end R/3 system and is programmed in ABAP. With a little training, internal ABAP programmers can develop additional transactions and modify existing ones as needed. Second, operators are directly logging into the back-end R/3 system. This allows for standard log-in logic, security, and authorization checks.

Mobile data collection yields the most benefit when it is important to collect and post data when and where it physically happens. Movements of materials in a warehouse or production environment, their consumption and inspection, and making the usage decision after inspection are the most typical areas where mobile data collection is used.

Available Technology

Regardless of whether a mobile device talks to a middleware system or directly to the back-end ERP system, the most commonly used devices are still handheld RF terminals with integrated bar-code scanner and a character-based display. They have been around for years and represent a proven technology. The ruggedly built terminals have screens and keypads ergonomically optimized for production and similar environments. Exchanging only essential, character-based data, they require little network bandwidth. Figure 3 (on the next page) compares how an R/3 screen segment appears on a computer versus an RF terminal.

Figure 3

An R/3 screen display on a computer (left) and an RF terminal (right)

More recently, some implementations have opted for Windows CE-based devices connecting to the corporate network through wireless LANs. Using such devices expands the possibilities of the mobile application design and development by allowing the use of other development environments — Visual BASIC, for example — to create more sophisticated applications. These devices are based on mass-produced personal digital assistants (PDAs), lowering the cost of internal development and maintenance of both the hardware and the operating systems. The purchase price of such devices — industrial-grade PDAs or pocket PCs — could be as much as 50 percent less than comparable RF devices.

In some cases, it might make sense to use tablet PCs, as they are becoming better in quality and less expensive. Now, even standard SAPGUI and standard R/3 transactions can be used with tablet PCs, eliminating the need for custom development. It might still make sense to develop custom transactions that better fit the business process as mentioned earlier.

Depending on the number of devices needed and in use simultaneously, using PDAs or tablet PCs might mean significant savings on hardware and software, but it might require an expensive upgrade of the corporate network and its bandwidth to accommodate the traffic. Table 1 compares the different mobile devices.

Cost considerations aside, I recommend the “old-fashioned” character-based RF terminals for most small, simple implementations. Why add the complexity of a PDA or a Windows-based Pocket PC if all you are going to run on it is a telnet session to send data back and forth to the “translator” software?

If the mobile device must run all sorts of custom or standard applications, or having a graphical screen environment suits your situation, go with the newer technology. A tablet PC will give you the full range of capabilities and features of a full-fledged portable personal computer.

SCM Expert will publish follow-up articles that discuss the details of two real-life implementations. The first will be a study of an implementation of warehouse and production transactions using SAPConsole and traditional RF devices, and the second will cover an implementation in a QM environment to perform mobile quality data collection and inspection result recording where tablet PCs were used. These articles will discuss not only the technical aspects of the developed solution, but also aspects of the application design.

Ali Sarraf

Ali Sarraf is the managing partner at Enowa Consulting. He has 15 years of experience as a senior consultant for SAP Business Suite applications and 20 years of IT experience. During much of his career, he has focused on helping customers optimize their logistics business processes by analyzing and explaining cause-and-effect relationships and by bringing the machine and the human sides of IT closer together.

You may contact the author at ali.sarraf@enowa.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.