ROI in the Here-and-Now: A Case Study
ROI in the Here-and-Now: A Case Study
By: Larry Mittag
Jun. 7, 2001 01:06 PM
There's no need to always wait for technology to catch up with the way you want to use it. Here's a real wireless app that offered return on investment even in its first year...
This particular customer was in a business that serviced industrial customers on a route-oriented basis. Many of the appointments were performed on a regular schedule, but there was also a significant number of clients serviced on an as-needed basis. The scheduling for these drivers had been done centrally, with the assignments being passed out via a series of job orders. The regular customers were handled fairly well under this system, but there were continual problems with efficiently handling the as-needed customers.
Previously Existing System
The existing routing system was tied into their order entry and billing systems. These systems were critical to the rest of the company, so they had to be maintained rather than replaced. There were also constraints on the overall cost of the system. This is not a company that could afford to install technology for technology's sake. If there was not a foreseeable return on their investment within a fairly short period they were not interested.
However, this solution had been heavily resisted in this case. The problem with a central dispatcher is that it removes the capability for the route drivers to govern their workload themselves. For a company such as this where the drivers are also skilled technicians, this is an important consideration.
What was needed was a set of tools that the route drivers could use themselves to optimize their day. These tools had to interface to the existing systems and be adaptable to changes in the schedule during the day. It's relatively easy to set up a schedule that's optimized to the nth degree, but such a schedule would rarely be fully carried out in the real world.
It was obvious that wireless data technology could solve the problem, but that technology had to fit within the parameters of the business. If it cost them too much to develop or operate a system then it didn't really matter if it worked. They would go out of business trying to deploy it. One of our primary concerns for this customer was the efficient use of existing technology. They could not afford to reinvent the wheel.
This step was a good start. It made it possible to print a report that would give a fully optimal schedule, but it was still necessary to adapt that process to the vagaries of the real world. The process had to be interactive.
Today, the fashionable way to do that in wireless is to use a thin client on a device like a WAP phone. There are several problems with that as a solution in this case. For starters, the display on a cell phone would not display enough information to be useful. There would be enough to show the next customer location, but the use model would be awful. These users wanted to employ the device to plan their day, not have the device dictate what they should be doing.
The solution was to put more intelligence into the device. We combined a set of Windows CE-based handheld PC (H/PC) devices with a GPS receiver and a CDPD modem as the mobile hardware for each of the service vehicles. This provided us with the computing and communications platform we needed to provide them with a solution.
Again, the fashionable way to accomplish that solution would have been browser-based. This would have worked well if the devices were wired, but it doesn't work well under current wireless conditions. For starters, such a design would have been very slow as the screen updates were sent across the slow CDPD network. That design also would have been susceptible to coverage problems. Browser-based solutions are essentially useless in areas that don't have wireless coverage.
This system would benefit greatly from regular updates, but there wasn't much need for those. The schedule could change several times during the day, but not several times a minute. The fully online model of WAP or other browser-based solutions was unnecessary and would have driven up the airtime usage of the system, making it more expensive. Something else had to be worked out.
The final piece of the puzzle was an intelligent application running on the H/PC device. This application utilized a small database resident on the device to display a series of routing options from which the driver could select. As work was completed throughout the day, this database was updated on the device.
The key to how we could do this is that the database would synchronize through the CDPD wireless connection to a central database back at the home office. These updates combined with the GPS information to allow the GIS routing algorithms on the server to reorder the service queue for the route driver and feed that information to the H/PC device. The application on that device could then display the options to the driver for his or her selection.
The key difference between this solution and a browser-based one is that the device could operate independently. The updates would be queued up when CDPD connectivity wasn't possible, and when connection could be made, the queue would automatically drain. This meant that it wasn't necessary for the driver to periodically call into the home office. The device, itself, would do it when it had something to say.
Improvements could be made to the system. Right now the H/PC is connected to the CDPD modem and the GPS receiver through serial port interfaces, a relatively clumsy set of wired interfaces. Bluetooth would work nicely to untether the H/PC from the other devices in the system.
Also note that it would be quite possible to integrate all of the components into a single ruggedized device that could be built into the dashboard of the truck. This level of integration would make the device much more robust, especially given the fact that the biggest danger is the heat it will experience if left on the dashboard of the truck.
There were secondary benefits as well. It turned out that there was no need for the drivers to report to the central depot every day except to pick up their scheduling slips. Thus they were able to go directly to their first job instead, saving both time and money, and further increasing their satisfaction with the system.
The back-end interfaces should prove robust as well. We resisted the impulse to build detailed knowledge of the terminal devices into the central system, which will make it easier to upgrade either, without affecting the other. The defined interface in between guards both sides.
Reader Feedback: Page 1 of 1
Latest Cloud Developer Stories
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
SYS-CON Featured Whitepapers
Most Read This Week