Cross-town Improvement Project Evaluation
3.0 Drayage Optimization Tests
Given the lack of railroad participation in the operational test, FHWA-OFM sponsored separate drayage optimization tests in Kansas City and Chicago to develop better metrics of bobtail reduction using C-TIP technologies. These tests focused on providing cross-town drayage companies with real-time information on driver location and trip events (e.g., load pick up and drop off) to help rationalize the dispatch process, minimize the potential for human error, and reduce unproductive moves. The following sections describe the Kansas City and Chicago tests and the efficiency improvements associated with them.
3.1 Kansas City IXT Test
The IXT drayage optimization test was conducted in Kansas City from April 1 to August 31, 2011. The control period was defined as April 1 to June 27, with an operational test period from June 28 to August 31. IXT is a drayage services provider in Kansas City, specializing in moving freight between intermodal terminals and customer locations in the metropolitan area. IXT utilized the C-TIP Open Source Architecture Package (C-TIP OSAP) deployed on in-cab smart phones to help optimize its cross-town drayage moves by minimizing unproductive bobtail moves. C-TIP OSAP provides IXT dispatchers with real-time driver location data along with wireless notification when a container is released for pickup. Dispatchers are therefore able to assign work orders to drivers who are nearby and not carrying a load, thus eliminating a bobtail trip.
CS’ evaluation relies on the use of dray movement event data provided by IXT through Profit Tools, a major provider of IT solutions for the trucking industry. The data cover the entire period of the test from April 1 to August 31, 2011. The data describe multiple events, including freight deliveries, ‘hooks’ (when a driver picks up equipment), ‘drops’ (the driver drops off equipment), the type of equipment involved, whether the driver bobtailed to the location in question, and miles in bobtail and load status. It also provides the rail terminal, IXT yard, or customer location of each event. Data are provided on an ‘itinerary’ basis, allowing truck movements to be tracked by driver, date, and sequence of events.
Examination of the detailed data revealed that there were some records in the data set that were not relevant to the present analysis. For example, some records revealed trip lengths of hundreds of miles (clearly outside the realm of cross-town drayage), or trips that occurred outside of Kansas City entirely. Others had no reported mileage. In order to better capture true cross-town freight and improve the accuracy of mileage statistics, all trips greater than 40 miles in length were eliminated, as were all records with no mileage value and all records of movements that occurred outside of the Kansas City metropolitan area. For the purposes of the evaluation, the metropolitan area was defined as all cities within the 15-county metropolitan statistical area (MSA) with populations of at least 10,000 as of the 2010 Census. These cities are shown in Table 3.1.
Source: U.S. Census Bureau.
After making these adjustments, revenue loads were identified using a shipment ID field; the number of unique shipment IDs per month equals the number of revenue loads in that month. Records in bobtail status were then identified by month by selecting records where the ‘bobtailed’ field was equal to 1 (a 0 indicates a truck was pulling equipment, i.e., not bobtailing). Bobtail trips by month were calculated by summing the number of bobtail records in each month of the baseline (April to June) and test (July and August) periods.
The results are shown in Table 3.2 along with monthly percent changes in bobtail trips and revenue loads, as well as the number of phones deployed during the July and August test period. As the table indicates, bobtail activity rose from April to May by 3 percent, then again from May to June by 23 percent. After that, bobtails fell by 6 percent in July and eight percent in August. Revenue loads also rose in May and June, fell slightly in July (though not by as much as bobtails), then rose by 2 percent in August. These data show that there was a reduction in bobtails which coincided with the introduction of the C-TIP OSAP-enabled smart phones. Moreover, bobtail activity continued to fall even as revenue loads grew in August.
The owner of IXT concurred that these reductions in bobtail trips are reasonably the result of the C-TIP OSAP deployment.
Source: CS analysis of Profit Tools/IXT truck movement data.
Note: All trips greater than 40 miles, outside of the Kansas City metropolitan area, or with no reported miles have been eliminated.
3.2 Chicago Test
Another C-TIP OSAP test was conducted in the Chicago region involving Pride Logistics, LLC, which is a provider of intermodal transportation services located in Palos Heights, Illinois. Flatirons Two, Inc., a technology company specializing in network/database administration, system integration, and smart phone applications, developed an Android smart phone app with the following functionality:
- Upload drivers’ daily schedules to smart phone;
- Provide drivers the ability to enter status updates;
- Provide schedule updates to drivers; and
- Periodically capture truck location information.
Two truck drivers were provided with Android smart phones during the test. The baseline test period was June through August of 2011, with the operational test period occurring in September.
Flatirons Two also reviewed Pride’s business model and dispatch process to identify opportunities to automate the process and reduce unproductive moves. Under Pride’s current business process, customers request container pickup via fax, phone call, or other manual methods. Those requests are then manually entered into a data base called IMX. From the IMX database the Pride dispatcher produces T-Cards with the pertinent information associated with the move. A wall display containing card slots is used to manage the progression from future workload to current workload to assignment to a driver, to the final step of notifying the driver of the work to be completed. This final step is done via e-mails and/or phone calls. Dispatchers must sort T-Cards manually throughout the day and attempt to find the most efficient allocation of equipment and labor resources based on changing customer needs, traffic conditions, and regulatory constraints. With an average of about 60 work orders per day, there is substantial opportunity for human error when planning workload.
Once the work order is completed the completion time is entered into the IMX database for tracking and billing purposes. However, this often occurs several hours later or the next day, thus slowing down the billing process, reducing shipment visibility for customers, and hampering efficiency.
Flatirons Two automated this process by developing a web application to handle the dispatch function. This application enables the dispatcher to sort work orders by origin, destination, and driver itinerary, with results presented clearly and concisely on the computer screen. This allows dispatchers to better match up drivers and loads throughout the day, eliminating the manual resorting of T-Cards. Dispatchers are able to quickly identify potential bobtails and make a more informed assignment. A schematic of the information and data flow for the dispatcher web application is provided in Figure 3.1.
Figure 3.1 Dispatch Web Application Information Flow
Source: Flatirons Two/Pride Logistics.
Determination of Benefits
The benefits associated with this test deployment revolve around three areas:
- Reduced Bobtail Miles/Trips – The process of the system being able to sort by origin and destination gives the dispatcher the ability to search for the best, most efficient loads available. This will reduce bobtail miles by eliminating human error in the selection of a load. The process for calculating bobtail miles was as follows:
- Pride used Google map mileage from actual start point to all stop points to determine actual mileage from each start/stop location. Pride then calculated all bobtail mileage using its internal move records. Total miles were then matched against the odometer reading turned in on each driver’s daily log. If there was a discrepancy between the Google map miles and odometer miles Pride checked the route taken and manually adjusted the route on Google maps.
- Once the miles were verified, bobtail miles were divided into total miles to produce the percentage of total miles that are bobtail miles. This measure adjusts for fluctuation in workload.
- Driver Productivity – Driver productivity during the baseline and test periods was measured using the average number of loads per driver. This was calculated by taking the average number of drivers per day for each month and dividing it into the average number of loads per day. So, for example, if there are an average of 16 drivers per day and an average of 85 loads, this would equate to 5.3 moves per driver (85 moves divided by 16 drivers).
- Dispatcher Productivity – Much of the dispatcher’s time is involved in the communication with the drivers and the planning of workload. This system can reduce the amount of phone communication by dispatching through the system. Communication has a minimum of four contacts – when the dispatcher dispatches the load, when the driver arrives at the customer, when the driver departs from the customer and when the move is finished. Drivers equipped with the Android smart phones were able to receive their work orders on the telephone and update their arrival and departure status in real time using a button included in the app.
Test Results
The test results for the bobtail miles/trips and driver productivity metrics as reported by Pride are shown in Table 3.3. These results have not been independently verified but CS believes them to be accurate based on the methodology described by Pride and Flatirons as well as subsequent conversations with them.
Source: Pride Logistics, LLC.
Note: June through August is the baseline; September is the test period.
There was substantial improvement in the bobtail metrics during the September operational test period. The percent of total miles in bobtail status fell from 8.9 percent in August to 4.7 percent in September. Although total miles fell by 8.4 percent in September, bobtail miles fell even faster (more than 50 percent), leading to substantial improvement in this metric. Meanwhile the percent of total trips as bobtails fell from 9.1 percent to 4.1 percent on a consistently growing number of total trips. Driver productivity also improved, from an average of 40 loads per driver in June to 46 loads per driver in September.
There are no similar quantitative metrics to evaluate dispatcher productivity because this would require detailed time keeping records that were not available for this study. However, under the T-Card system the dispatcher often required help from other employees to accomplish his or her task – thus diverting other staff from their assigned work. Inasmuch as the web application allows the dispatcher to handle more of the dispatch function by himself, Pride can accommodate additional business growth without having to hire another dispatcher or divert labor from other business activities to accomplish the necessary function of allocating drivers and equipment.
While most of the bobtail and driver productivity benefits in this test flow from the dispatch web application, Pride reported substantial business process benefits associated with the real-time arrival/departure information enabled by the Android app. The billing procedure was improved since billers could initiate the process once they knew a container had been delivered to the customer. It also eliminated the manual dispatcher effort required to update IMX for billing purposes and improved shipment visibility for customers. Moreover, the drivers using the app liked the ability to see their work orders on the phone and read them at their convenience. Previously, they would copy down work orders from the dispatcher over the telephone, which required them to pull over if they were driving at the time and also introduced substantial opportunity for transcription or other errors.
An interview was conducted with a driver who was equipped with a smart phone during the test. The interview instrument is provided in Appendix B. This driver confirmed that the primary use of the phone was to obtain dispatch instructions (through the automated T-Card system), and to provide status updates such as pickup/drop off times to the central office. The driver liked the application and stated multiple times that it was much easier than calling back and forth to get work orders from the dispatcher. Previously, the driver obtained work orders via e-mail or instant message, usually the night before; any updates or changes had to be handled on a case-by-case basis through phone calls to the dispatcher. The automated T-Card eliminated the need for him to do this.
previous | next
