John Parkinson: Mobilize Me!

By John Parkinson  |  Posted 08-01-2004

I got my first cell phone back in 1989—it was a Motorola "brick" that cost more than $1,000—and I've probably used a couple of dozen different models since. My first PDA arrived as soon as they were available, and I've probably gone through a dozen different models. I got a "luggable" business computer in 1986 and a notebook computer in 1991. I've tried the entire repertoire of converged phone/PDA/ultra-lightweight PCs available—and some that aren't.

It's all because I spend almost all of my working time away from the "office"—in fact, I no longer have a permanent office location. With a wired, or wireless, connection to the Internet and good VPN software, I can "office" just about anywhere. In this sense I'm at the extreme of the mobile executive market segment—but by no means at the extreme of the mobility market.

Consultants aren't the only people who operate in highly mobile workplaces. Face-to-face sales forces and the teams of technicians who install everything from domestic cable service to industrial machinery are just two examples of jobs that require mobility. Add in field-service teams, couriers and transport operators, emergency service first-responders, even utility-company meter readers, and you get a significant population of people who make up the mobile workforce. Even people who work in one location may not have a fixed office: Security, messenger, janitorial and supervisory roles generally require movement as a part of the job design. And we all go to meetings.

What's the best way to provide all these different folks with efficient and reliable access to information and business automation capabilities? Essentially, you have three approaches to choose from, which clearly are not mutually exclusive:

Scatter fixed access points around the areas where people work so that they are never very far from a place where they can be connected. This works well in applications such as assembly lines and distribution centers, where staff can check in periodically to update status, report progress and get new work orders. You can start and stop tasks, picking them up again at a later time and at a different place, with the fixed infrastructure maintaining "state"—a critical feature when different people interact with the system and each has to know, reliably, what the others have done and how far along the work really is. You can provide interface equipment at every access point (the pay phone approach) or move the equipment with the people (using something like notebook computers and wired LANs). It gets expensive, however, when you have a large area to cover, or when you have to provide reliable, secure access in public or shared private (where multiple people use the same infrastructure) environments.

Provide "untethered" connectivity by using some part of the electromagnetic spectrum—infrared or radio—to maintain persistent or intermittent links to fixed access points. Depending on device characteristics and requirements (bandwidth, security, portability, ruggedness), the access points can be fewer, more widely spaced and more easily secured than in the first approach. Cellular, 802.11 (Wi-Fi) and Bluetooth technologies all support this approach. State is fairly easy to manage because you are either always connected or functioning like the first approach, but without the wires. The disadvantages are a matter of physics—noise, interference and limited data rates, plus issues with device battery life and with both physical and information security. This approach works well in warehouses and loading docks where workers and products move around a lot and can't be tethered to a single location.

Design the information environment to tolerate "occasional connection" behavior and add the ability to synchronize information periodically (RFID falls into this category). Synchronization in the general case is a very challenging problem to do well. However, it turns out that in a lot of situations only a small amount (usually between 2 percent and 7 percent) of the information is "dynamic," in the sense that it needs to be changed or created while untethered and switched with the stored data later on. Almost all the rest is read-only reference information that doesn't need much, if any, updating. If you know which information is which, you can build a very efficient "asymmetric" information exchange that loads up the mobile device with the static information when it is attached to a high-bandwidth access point, and exchanges small packets of compressed information (which doesn't require much bandwidth or battery power) at other times. Field service is the prime example here.

Implementing the right blend of these strategies has been getting easier for a decade, and it's now just about reached the mass-deployment tipping point, especially around the third approach, where standard platforms (such as J2ME and the .NET mobile framework) are emerging that provide most of the capabilities that previously had to be custom built. Adding mobility-based business automation to manual or under-automated processes can have a pretty compelling business case. Three critical areas to add to the ROI equation for mobile business processes are:

Compliance. This is especially true where there is significant liability in the event of a missing status check, as well as potential litigation costs. This might include lots of things, from utility pipelines and refineries to elevators and amusement park rides; it turns out to be a long list. In these situations, platform-based mobility systems can pay for themselves simply by providing a secure record that mandated maintenance was in fact undertaken and that operators were in compliance.

Productivity. This comes into play especially when there is a lot of hard-to-schedule movement required between "productive" events, such as in "break-fix" field service. If you combine mobility systems with agent-based dynamic scheduling, it's possible to just about double productivity and increase customer satisfaction at the same time.

Extended working. This involves situations where the people who need information aren't in predictable places when the information shows up. Lots of business decision-making scenarios fit this model ("I'm done early, what do I do next?" for installers, for example, or direct-store delivery drivers who have excess inventory along their routes), and an increasing number of them will crop up as real-time business operations become more widely deployed.

Even with strong ROI, you don't get something for nothing. Adding mobility capabilities often exposes gaps in available data and problems with data quality that can be expensive to fix. Integrating mobile systems with back-office systems is always a challenge, and network traffic that's connected occasionally has very different resource demands from traffic that is connected constantly. Security is an issue in any detached design, and although the tools to make systems more secure exist, they are often unfamiliar to application designers. Development tools for the new platforms are still at an early stage of sophistication, making for steep learning curves and potential total cost of ownership problems in the future. Devices are often fragile—or expensive if made more rugged. Standards for interoperability are not quite finalized yet, although we are getting close.

As with all tipping points, it's next to impossible to predict exactly when mobile operations will be broadly deployed. But if you're looking for a way to leverage existing business automation investments to significantly reduce compliance costs, improve field-service productivity and increase customer satisfaction, then consider mobility platforms. In other words, it's time to mobilize!

John Parkinson is chief technologist for the Americas at Capgemini.