US20070221791A1

Movatterモバイル変換

Info

Publication number: US20070221791A1
Application number: US11/388,879
Authority: US
Inventors: Michael Voelk; Marcello Yanez; Shawyn Paxton
Original assignee: TRANSPORT INDUSTRIES LP
Current assignee: TRANSPORT INDUSTRIES LP
Priority date: 2006-03-23
Filing date: 2006-03-23
Publication date: 2007-09-27

Abstract

In accordance with the teachings of the present invention, a system and method for managing the transport of freight is provided. In a particular embodiment, a method for managing the transport of freight includes receiving information associated with at least a first plurality of loads and a second plurality of loads. In addition, the method includes applying at least one template to at least part of the information associated with at least the first plurality of loads, each template suggesting one or more preferred legs for at least one tour. The method also includes allowing a user, through a user interface, to accept one or more of the tours suggested by the at least one template. Additionally, the method includes allowing the user to manually create or modify one or more tours using at least part of the information associated with any loads that do not yet comprise an accepted tour.

Description

TECHNICAL FIELD OF THE INVENTION

The present invention relates generally to freight systems and related logistical and information technology and, more particularly, to a system and method for managing the transport of freight.

BACKGROUND

In modern industry, goods are typically manufactured in one location and sold in another. Thus, goods must be transported from the manufacturing site to the final commercial outlet and are typically stored at intermediate distribution centers along the way. Transporting these goods from one location to another may require a substantial fleet of commercial carriers such as trucks. In such cases, fleet operators, who may or may not own some or all of the trucks in the fleet, must find a way to manage the fleet effectively. Otherwise, the participants in the distribution network may become dissatisfied. These participants may include those manufacturing the goods, those transporting the goods, those operating the distribution centers, and those operating the final commercial outlets.

Typical fleet operators include manual dispatchers at distribution centers who receive information about loads of goods that must be transported. This information may include the delivery date of each load, the origin of each load, the destination of each load, and other information associated with the loads. Manual dispatchers may also be aware of information associated with the trucks and the drivers of the trucks at their disposal. This information may include the capacity of each truck, the availability of each truck or driver, and the time that a particular driver or truck may have to transport a load of goods. Dispatchers often have no effective tools to match drivers and trucks with particular loads, and thus, they often match haphazardly and inefficiently. The haphazard and inefficient nature of matching may create dissatisfaction for the clients and drivers of a dispatcher's company.

Thus, many manual dispatchers often use a dispatching system to coordinate matching of drivers, trucks, and loads more efficiently. Dispatchers enter the information they receive about loads of goods and about trucks and drivers into the dispatching system. Having that information organized and available for review may allow dispatchers to satisfy the interests of clients and drivers more effectively. In addition, dispatchers may match drivers, trucks, and loads more efficiently.

A push for efficiency has also led to the creation and adoption of dynamic solvers in some fleet management systems. A typical dynamic solver receives all of the information about loads, trucks, and drivers. The dynamic solver then analyzes this information and generates a matching solution that maximizes yield. Many times, however, the dynamic solver does not match all of the loads with trucks and drivers because matching all of the loads does not offer an optimal solution. This result can be problematic when all loads must be transported. Another problematic aspect of dynamic solvers is their exclusive concern with efficiency and complete disregard for the various other interests in a distribution network.

SUMMARY

Technical advantages of one or more embodiments of the present invention may include catering more closely to the various interests involved in transporting goods from one location to another. The interests in the transportation industry are more varied and multi-faceted than the one-dimensional focus on economic efficiency that is typically advanced. By having a toolset that can take into account these other interests in addition to economic efficiency, freight managers may manage the transport of freight more effectively.

Another technical advantage of particular embodiments of the present invention includes managing freight more effectively by forecasting legs of tours. Forecasting legs of tours allows for more effective tours to be created by increasing the number and type of legs that may be added to a tour. This may both increase the efficiency of the management system and lead to less carriers being stranded in a remote location at the end of a tour.

It will be understood that the various embodiments of the present invention may include some, all, or none of the enumerated technical advantages. In addition, other technical advantages of the present invention may be readily apparent to one skilled in the art from the figures, description and claims included herein.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of the present invention and its features and advantages, reference is now made to the following description, taken in conjunction with the accompanying drawings, in which:

FIG. 1 is a diagram illustrating an example freight distribution network;

FIG. 2 is a block diagram illustrating an example system for managing the transport of freight according to one embodiment of the present invention;

FIG. 3 is a flowchart of an example method of managing the transport of freight according to one embodiment of the present invention; and

FIG. 4 is a screen shot of an example user interface at a tour command center according to one embodiment of the present invention.

DETAILED DESCRIPTION

FIG. 1 is a diagram illustrating an examplefreight distribution network10. In a typical freight distribution network, goods are manufactured at a factory or other manufacturing site, transported as freight to one or more distribution centers, and transported to one or more commercial outlets for sale. Distribution centers are typically located in different geographic regions and facilitate the transfer of goods from manufacturing sites to final commercial outlets.

Examplefreight distribution network10 comprises distribution centers20, commercial carriers30, commercial outlets40, and manufacturing sites50. Distribution centers20 may comprise any suitable distribution center operable to store goods manufactured at one or more manufacturing sites50 and destined for one or more final commercial outlets40. Distribution centers20 may allow for loading of outbound goods onto commercial carriers30 and for unloading of inbound goods from commercial carriers30. It should be noted that, as used herein, outbound refers to the direction away from a distribution center, and inbound refers to the direction toward a distribution center. Distribution centers20 may be arranged in any suitable manner, such as, for example, in different geographic regions (as in the illustrated example). Distribution centers20 may be located relatively close to one or more commercial outlets40 or manufacturing sites50. One or more distribution centers20 may alternatively be located relatively far from one or more commercial outlets or manufacturing sites50. Any suitable number of commercial outlets40 or manufacturing sites50 may be associated in any suitable manner with one or more distribution centers20 (and this may differ from that illustrated).

Commercial carriers30 may comprise any suitable commercial carriers operable to transport freight, such as, for example, trucks, automobiles, airplanes, boats, ships, and/or trains. Commercial carrier operators may comprise any operator of a commercial carrier, such as, for example, the driver of a truck or automobile, the pilot of an airplane, the captain of a boat or ship, or the conductor of a train. Although much of the discussion below focuses on trucks and truck drivers, the discussion may apply to any suitable commercial carrier and commercial carrier operator. A commercial carrier30 may be operable to receive freight (otherwise known as a “load”) at a manufacturing site50 such as a factory and transport the load to one or more distribution centers20 or directly to one or more commercial outlets40. Commercial carriers30 may be further operable to receive a load at a distribution center20 and transport the load to one or more distribution centers20 or to one or more commercial outlets40.

Commercial carriers30 may be owned and operated in any suitable manner. For example, one or more commercial carriers30 may be associated with owner-operators. Additionally or alternatively, large numbers of commercial carriers30 may be owned by a single entity. Operators of commercial carriers30 may receive their route in any suitable location, such as, for example at a distribution center20 or other field office. During periods in which loads are not being transported, such as, for example, during a commercial carrier operator's vacation, a commercial carrier30 may be left by its operator in any suitable location, such as, for example, in a location proximate to a distribution center30.

Commercial outlets40 may comprise any suitable commercial outlets at which goods are sold to consumers. As examples only, commercial outlets40 may include Walmart stores, Target stores, or any other suitable commercial outlet. The goods sold at commercial outlets40 may originate at one or more manufacturing sites50 and may be transported by one or more commercial carriers30. Commercial outlets40 may request regular shipments of goods at regular intervals. Alternatively, commercial outlets40 may request shipments of goods without any predictability, such as, for example, if commercial outlets40 order goods as actual inventory is sold (and the sale of actual inventory cannot be predicted accurately). In such cases, a relatively quick response time may be required to deliver the goods requested to commercial outlets40.

Manufacturing sites50 may comprise any suitable manufacturing sites or other sites that supply goods, such as, for example, factories. Manufacturing sites50 may manufacture any suitable good, such as, for example, hardware items, soft items such as clothes, or food such as canned, dried, or refrigerated food. Alternative manufacturing sites50 may not manufacture any good and may instead supply goods such as, for example, sand. The goods supplied by manufacturing sites50 may eventually be sold at one or more commercial outlets40 and may be transported by one or more commercial carriers30. Manufacturing sites50 typically deliver shipments to distribution centers20 with regularity. However, manufacturing sites50 may at times be required to make an urgent shipment, in which case a relatively quick response may be required to transport the goods. From the vantage point of distribution centers20 coordinating routes for commercial carriers30, commercial outlets50 and manufacturing sites50 may be examples of destination points for commercial carriers30.

In operation, commercial carriers30 may receive their routes (also known as “tours”) at a distribution center20 or other suitable field office. A “tour” may generally be referred to as a route of one or more legs (each leg defined by an origin and a destination) on which a commercial carrier transports at least one load over at least one leg, each leg comprising any suitable number of stops, including no stops, between the origin and destination for the particular leg. Operators of commercial carriers30 may transport loads according to the tour that each receives. In the illustrated example network, after receiving a tour, the driver oftruck30amay, on the first leg of the tour, transport a load fromdistribution center20atocommercial outlet40a,with possible delivery stops (not illustrated) in between. After delivering the remaining part of the load todistribution center20a,the driver oftruck30amay then return todistribution center20a.This is referred to as a “tour of one,” as the driver oftruck30adelivers only one outbound load before returning todistribution center20a.Again, though not illustrated, it should be noted that transport of one load may consist of any suitable number of stops at one or more locations between the origin and destination of the load.

If the driver oftruck30awere traveling fromdistribution center20atomanufacturing site50awith no load on its first leg, were to receive a load frommanufacturing site50a,and then were to transport that load back todistribution center20a,this tour would be referred to as a “deadhead.” A “deadhead” generally refers to tours with one load where the load is transported inbound to the distribution center.

The route oftruck30binexample network10 illustrates a “tour of two.” Here, the driver oftruck30bmay receive a load atdistribution center20band transport and deliver the load tocommercial outlet40b,possibly two delivery stops, illustrated as points on the leg, at one or more locations in between. Again, it should be noted that any suitable number of delivery stops (where part of the load is delivered), including no stops, may be made on one leg between the origin and destination for the particular leg.Truck30bmay then travel todistribution center20c,receive a load atdistribution center20c,and return and deliver the load todistribution center20b.As may be observed, tours of any number of legs may be created, and managing loads effectively (or put another way, creating effective tours) becomes increasingly difficult and important as more distribution centers20, commercial carriers30, commercial outlets40, and manufacturing sites50 are involved in the system.

Modifications, additions, or omissions may be made to thedistribution network10 described without departing from the scope of the invention. The components of thedistribution network10 described may be integrated or separated according to particular needs. Moreover, the operations of thedistribution network10 described may be performed by more, fewer, or other components without departing from the scope of the invention.

Tours may be created to transport loads, and tours of numbers greater than one may be created to generate efficiencies. For example, it may be more efficient forcommercial carrier30binFIG. 1 to travel todistribution center20cafter delivering its load tocommercial outlet40bif, for example,distribution center20cis closer tocommercial outlet40bthan it is todistribution center20b.In fact, there may be many factors to consider when creating tours in order to generate maximum allocative efficiency. In addition, consideration of other important interests in addition to or in place of allocative efficiency may be required to operate an effective distribution network. Thus, a need exists for a system that considers efficiency and the myriad of other interests involved in a distribution network in creating tours and managing loads.

FIG. 2 is a block diagram illustrating anexample system100 for managing the transport of freight according to one embodiment of the present invention. Unlike typical systems,system100 may offer a more effective solution to managing freight by better catering to the various interests involved in a distribution network in addition to considering the efficiency of the system. These interests may include, for example, those of manufacturers, commercial outlet operators, commercial carrier operators, and distribution center operators.

As an example only, at times, a manufacturer or commercial outlet operator may prefer to ship or receive goods according to a particular template. The value of having a tour according to the template may be greater to that party than the value of having a less expensive tour that does not follow the template. As used herein, a “template” generally refers to one or more preferred, additional legs for a particular tour. As discussed further below, there may be any suitable justification for a leg being preferred. For example, a manufacturer may have run a tour a certain way for a long time and does not want to exchange the stability and predictability of the route for another route that may be slightly less expensive. However, it should be noted that the template need not offer a more expensive tour per se.

In yet another example, a manufacturer or commercial operator may prefer a tour that does not violate a particular constraint. The value of having a tour that does not violate the constraint may be greater than the possibly lesser cost of a tour that does violate the constraint. As used herein, a “constraint” generally refers to a pre-determined condition that should not be violated when creating a tour. For example, a manager at a manufacturing site may disfavor allowing dead-head tours because dead-heads are perceived as being less efficient (by upper management, for example), even if dead-heads may be more efficient under particular circumstances. The manager may thus prefer tours that do not violate a dead-head constraint.

Templates or constraints may be catered to the interests of commercial carrier operators too. For example, commercial carrier operators may desire a template that specifies a pre-determined route, such as, for example, along a highway near an operator's home. Commercial carrier operators may also prefer to have tours that do not violate a constraint, such as a constraint limiting the number of hours a tour can last before the commercial carrier operator rests. Typical systems that focus solely on efficiency may not adequately take these factors into account and may thus produce less effective tours by increasing operator dissatisfaction.

Although templates and/or constraints may cater to interests other than that of efficiency, templates and/or constraints may, in particular circumstances, lead to more efficient tours being created. For example, templates may define multi-legged tours that experience indicates constitute very efficient tours. Thus, having a template for such a tour may save time by not requiring those creating tours to re-calculate efficiencies for each new set of unsolved loads, assuming that loads corresponding to the template legs are available. As another example, constraints may allow those creating tours to quickly determine if a tour they have created violates a state regulation, such as, for example, a limit on driving time for a commercial carrier operator.

System

100 ofFIG. 2 comprisesdispatch system110, distribution centers120,access point130,network140, data stores150-170,tour command center180, data stores200-260, anddynamic optimizer system270.Dispatch system110 may comprise adispatcher interface112 through which dispatchers at distribution centers120 or at any other suitable location, such as, for example, a field office, communicate withdispatch system110. Distribution centers120 may be the same as distribution centers20 ofFIG. 1, and thus, will not be described again.Dispatch system110 may also comprise a commercial carrier operator interface114 (in the trucking industry, a driver interface, for example) through which commercial carrier operators usingaccess point130 may communicate directly withdispatch system110 over anysuitable network140.Network140 may include, for example, the internet.Access point130 may include any wireless or wireline communication device, such as, for example, a computer, a telephone, or a personal digital assistant, that a commercial carrier operator may access to communicate withdispatch system110.

In particular embodiments,dispatch system110 may be operable to receive information from dispatchers or commercial carrier operators themselves regarding power time availability (PTA) and store that information indata store150. As used herein, “PTA information” may include, for example, any suitable information that identifies a commercial carrier's availability, such as, for example, the real-time location of the commercial carrier, the duration of a commercial carrier at a particular location, and the remaining time before the operator of the commercial carrier must stop for a regulatory-required rest.

Dispatch system

110 may also be operable to receive load information from any suitable source. For example, if dispatchers at distribution centers120 or at other suitable field offices receive load information from a manufacturing site or commercial outlet (such as, for example, manufacturing sites50 or commercial outlets40, respectively, inFIG. 1), they may forward the load information todispatcher system110 which may then store that information indata store160. Load information may include any suitable information associated with a particular load, such as, for example, characteristics of the goods that make up the load, the source of the load, and the destination(s) for the load.

Dispatch system

110 may also be operable to receive tour information fromtour command center180 and store that information indata store170.Dispatch system110 may be further operable to forward that information in, for example, a report format to dispatchers. Dispatchers may be located in distribution centers120 or in any other suitable location such as a field office.Dispatch system110 may forward the tour reports to the dispatchers through, for example,dispatcher interface112. Additionally or alternatively,dispatch system110 may forward the tour reports to commercial carrier operators directly, such as, for example, throughoperator interface114.

Tour command center

180 may comprise auser interface182, aconstraint engine184, atemplate engine186, aforecasting engine188, anoptimizer interface190, and areport engine192. In particular embodiments,tour command center180 may be operable to receive PTA and load information fromdispatch system110 and store that information in

data stores

210 and220, respectively.Tour command center180 may be further operable to create tours based on the load and PTA information to satisfy some or all of the interests (described above) which may be involved in a distribution network. In alternative embodiments,tour command center180 may be operable to receive load information and ignore any PTA information, store the load information indata store220, and create tours based on the load information while ignoring any PTA information. It should be noted thattour command center180 may be programmed using the Visual Net programming language, allowing for easy portability to the Internet and other networking capabilities.

User interface

182 oftour command center180 may comprise any suitable interface operable to allow a user to communicate withtour command center182 to create tours. Before a user may create tours throughtour command center180, however,tour command center180 may also be operable to request user information from the user to authenticate the user and verify that the user is authorized to accesstour command center180. Information authorizing the user to accesstour command center180 may comprise, for example, a user name and password. User identification information may be stored as master data indata store200, andtour command center180 may accessdata store200 to authorize a user to accesstour command center180. It should be noted that, in particular embodiments, more than one user may accesstour command center180 and create tours at one time, and each user may lock tours such that another user cannot create tours from the loads in the locked tours. In particular embodiments, each user may also lock unsolved loads such that another user cannot use those loads to create tours.

As described above,tour command center180 may be operable to receive PTA information and loads information fromdispatch system110.Tour command center180 may be operable to receive this information automatically in particular embodiments. In alternative embodiments, a user oftour command center180, throughuser interface182, may download the information to tourcommand center180. In particular embodiments, a subset of all load information may be manually selected by a user and received bytour command center180. However, beforetour command center180 receives the new PTA and loads information, one or more old tours, loads, and/or PTA information stored intour command center180 may be deleted in particular embodiments (either automatically or manually by the user). If information from previous sessions is not deleted, the new information that tourcommand center180 receives fromdispatch system110 may modify and/or add to the existing information (such as, for example, modifying existing loads or adding new loads). Aftertour command center180 receives the PTA and loads information, the PTA information may be stored indata store210, and the load data may be stored indata store220 as “unsolved loads.”

As mentioned above, in particular embodiments,tour command center180 may ignore any PTA information. In such embodiments, an assumption may be made that there is unlimited power time availability at distribution centers120. In particular embodiments,tour command center180 may automatically make this assumption and create a tour of one for outbound loads and/or deadheads for inbound loads, storing the tour information indata store260. In such embodiments, any remaining loads may continue to populateunsolved loads store220.Tour command center180 may then allow the user to pair (manually, usingtemplate engine186, and/or using optimizer270) the remaining loads with the created tours to add legs to the tours.

The assumption that there is unlimited power time availability may not reflect reality at times and may in fact provide an allocatively inefficient result if, for example, the number of tours does not match the power time availability at a particular distribution center. On the other hand, not ignoring any PTA information may offer several advantages. The first and most evident is that ignoring PTA information may provide for a simpler, and thus more manageable, system. Considering PTA information may increase the number of variables to be analyzed, adding to the complexity of the system.

A second, less evident advantage of not considering PTA information in creating tours is that, in such embodiments, particular tours need not be linked to particular commercial carriers. In other words, under the assumption of unlimited power time availability, a list of tours may be generated that is not linked to particular carriers, and this list may be presented to commercial carrier operators for the operators to choose which tour to accept. Operators need not be automatically assigned to a particular tour because it is the most efficient one based on their real-time PTA information. Thus, operators may choose a tour that best satisfies their preferences. These preferences may include, for example, the mileage they prefer to travel on a tour, the time they prefer to spend on a tour, or the schedule that allows them to attend a special event like a birthday or anniversary. Because many commercial carrier operators prefer to have a choice among several tours rather than be assigned the most empirically efficient tour, a system that assumes unlimited power time availability may be more effective and “operator-friendly” than one that considers PTA information, even if efficiency may not be greater.

In embodiments in which load and PTA information is received and stored bytour command center180, the assumption about unlimited power time availability at distribution centers120 need not be made. In these embodiments,tour command center180 may automatically create, or a user may manually create, tours of one for outbound loads by matching PTA information with outbound load information. In particular embodiments,tour command center180 may also automatically create, or the user may manually create, deadhead tours for inbound loads by matching PTA information with inbound load information. Legs associated with unsolved loads may then be added to these tours. Since their PTA information would be used to match their power to a more limited set of tours, commercial carrier operators may have less choice over which tours to take, and thus may not be as satisfied with the tours they receive. For example, a first commercial carrier waiting at a distribution center may be matched with the next tour received by the distribution center dispatcher (with the distribution center as the origin), even if a second commercial carrier on an inbound leg ten miles away from the distribution center would prefer to take that tour (and the first commercial carrier does not prefer that tour). Thus, although a system considering PTA information may be more economically efficient, it may ultimately be less effective.

Regardless of whether PTA information is considered in initially creating tours,tour command center180 may comprise several tools to assist in generating effective tours. These tools may compriseconstraint engine184,template engine186, forecastingengine188, andoptimizer interface190.Constraint engine184 may comprise any suitable engine operable to access, either automatically or after user input, the constraint definitions information indata store230. Constraint definitions may comprise mandatory or default constraints on tour generation. Mandatory constraints may comprise constraints that a user may not override in creating tours, and default constraints may comprise constraints that a user may override in creating tours. Thus, for example, if a user seeks to create a tour that violates a state regulation, such as, for example, a regulation that limits how much time a driver may drive without rest, the tour may be flagged as violating a mandatory constraint, and the user may not be allowed to create such a tour. Other example mandatory constraints may include a constraint on having the second leg of a tour begin before the first leg of the tour ends, a constraint on pairing a refrigerated load and a non-refrigerated load on the same tour (to reduce the risk that a commercial carrier without refrigeration capabilities accepts the tour), or an operational constraint, such as, for example, creating a tour whose value is less than the cost of the tour. If, for example, a user seeks to create a tour that violates an unofficial company policy, such as, for example, a policy of not creating a tour whose final destination is far from the tour's origin, the tour may be flagged as violating a default constraint. In such a case, though the tour is flagged, the user may override the constraint and create the tour despite the violation. Alternatively, the user may need approval from the user's superior to override the default constraint. To override the default constraint, the user may either do so passively, such as, for example, by ignoring the flagged status of the tour, or actively, such as, for example, by removing the tour's flagged status in order to create the tour. Other default constraints may include, for example, a constraint on creating tours with dead-heads.

Template engine

186, which may also be referred to as a rule automation engine, may comprise any suitable engine operable to access the tour templates indata store240, the unsolved loads (or a subset of unsolved loads) indata store220, and the tours intours store260. A tour template may comprise any suitable template which, for a given tour, offers one or more preferred, additional legs for that tour. Thus, for example, assuming an origin and destination are identified by the user, say, for example, in a tour that has already been created and stored intours store260,template engine186 may access tourtemplates data store240 to find preferred leg(s) that may be added to that tour.Template engine186 may access unsolvedloads data store220 to compare the preferred legs information in tourtemplates data store240 with the unsolved loads available since the unsolved loads available may limit the preferred legs that may be added to a tour. Based on the unsolved loads and preferred legs information,template engine186 may suggest one or more preferred legs that may be added to the tour.Template engine186 may also identify the relative efficiencies of selecting one preferred leg over an alternative preferred leg if the tour template has two or more alternative preferred legs for one tour.Template engine186 may also identify the relative efficiencies of selecting one load over another load to satisfy a particular preferred leg of a tour if more than one unsolved load would satisfy the particular leg. So, for example, the template engine may compare the parameters of the two loads, such as, for example, the waiting time associated with the two loads, to find the best load to satisfy the preferred leg of that particular tour.

After a user selects one or more preferred, additional legs for a first tour, the loads associated with those legs may be removed from further consideration by the template engine. Thus, the template engine may not consider these loads in suggesting preferred legs for any remaining tours, thereby possibly limiting the options available for adding preferred legs to these remaining tours. Considering only the remaining loads, the template engine may then recalculate preferred legs for any remaining tours. The user may choose one or more preferred legs (and associated loads) for a second tour, after which the associated loads are removed from further consideration by the template engine. This process may continue until all of the tours that the user sends to the template engine have been matched with loads that satisfy preferred legs for those tours (or until the user decides to end the process).

Tour templates stored indata store240 may be based on any number of factors. For example, over time, a user oftour command center180 may realize that for a particular origin and destination, the user always adds a particular leg to that tour (for example, if it is the most efficient leg to add). In that case, the user may create a tour template that identifies that leg as being a preferred leg for that particular origin and destination. Alternatively, a tour template identifying that leg as being a preferred leg for that particular origin and destination may be automatically created based on the same factors considered by the user, for example. Thus,template engine186 andtemplate data store240 may offer a user a tool by which the user may more quickly and efficiently generate tours. In addition, by allowing the user to create templates (or for templates to be created automatically) based on any policy or rationale, the tool allows the user to consider interests in addition to efficiency, such as, for example, what may be preferred by manufacturers, commercial outlet operators, or commercial carrier operators.

Forecasting engine

188 may comprise another tool that a user oftour command center180 may use to create more effective tours. A user may, at times, desire to create a tour with multiple legs where load data corresponding to one of the legs of the tour does not yet exist. For example, assume that a user desires to create a tour with a first load from A to B and a second load from B to C, where C is relatively distant from A. Because the user would prefer to avoid the inefficiencies and inconveniences of having the carrier travel back from C to A empty, the user may desire to include in the tour a leg from C to A or from relatively near C to A to reduce the miles that the carrier travels empty. At the time that the tour is being created, however, loads may only exist from A to B and from B to C, and no loads may yet exist at that time from C to A or from near C to A.

To resolve the dilemma, the user may accessforecasting engine188 to determine whether, though no loads exist from C or near C to A at the time that the tour is being created, there is a reasonable probability (based on a pre-defined constraint, for example) that a load will exist from C to A when the carrier reachesC. Forecasting engine188 may be operable to make such a determination by accessing pastload data store250.Data store250 comprises past load data that may identify, for example, the number of loads that have originated at a particular origin and that have been destined for a particular destination over a certain period of time. There may be other parameters associated with these loads, such as, for example, the day of the week or the day of the month that these loads were available for transport. Based on the parameters stored in pastload data store250, forecastingengine188 may forecast the probable number of loads that will be available to satisfy the desired leg of the tour. Alternatively, the user herself may calculate the probable number of loads that will be available to satisfy the desired leg of the tour by looking at past load directly (and not by using forecasting engine188). As used herein, “to forecast” generally refers to using past load data to predict whether a particular load associated with a particular leg will be available to transport at a particular time in the future.

Forecasting engine

188 may, in the situation above, predict, for example, that there will be ten loads available from C or near C to A based on past load data indicating that ten loads associated with that leg have been available every month (or, alternatively, every week) on the day (or, alternatively, the hour) in which the carrier is expected to arrive at C fromB. Forecasting engine188 may then access constraint definitions store230 to assess whether the number of forecasted loads meets or exceeds a pre-defined, minimum threshold. If the threshold of forecasted loads that must be available for a particular leg is met, then a tour including the forecasted leg may be generated. If the threshold is not met, then a user may override the constraint if the constraint is a default constraint. Thus, if the threshold is met,forecasting engine188 may indicate to the user that the user's proposed tour, including the forecasted leg, is reasonable and may be created. If, on the other hand, there are never (or rarely) any loads from C or near C to A and the threshold is not met, then forecastingengine188 may indicate to the user that the user's proposed tour cannot reasonably include a forecasted leg from C or near C to A. In an alternative embodiment, forecastingengine188 need not accessconstraint definitions store230 and may simply present to the user a prediction of the number of loads that will be available at a particular time for a particular leg(s), and the user may decide if it is reasonable to add a forecasted leg to a tour based on this information.

It should be noted that, at any suitable time, information associated with current loads may be stored in past load data store250 (to be used for forecasting legs of future tours). In particular embodiments, current load data may only be used for forecasting legs of tours created in future sessions. In alternative embodiments, current load data may be used for forecasting legs of tours currently being created. It should further be noted that although an available load from C to A at the time that the carrier arrives at C would be ideal in reducing empty mileage traveled, a user may also be interested in available loads from near C to A or from C to near A at the time that the carrier arrives at C. Although the carrier would travel some miles from C to near C empty (or, similarly, from near A to A empty), the load from near C to A may produce a more efficient and/or more effective tour. This may be the case if, for example, a forecasted load from near C to A produces less, total waiting time for a driver than a forecasted load from C to A, thereby decreasing the cost of the tour.

Forecasting engine

188 may allow a user to forecast legs of tours in order to create tours that are either more efficient or satisfy some other interest in the distribution network more effectively. It should be noted that, although the forecasted leg in the example tour above is from the final destination of the tour to the origin of the tour, forecasted legs may be used for any leg of a proposed tour. Forecasting may not be beneficial, however, with regard to the first leg of a tour since load data, it may be assumed, exists for the first leg. It should further be noted thatforecasting engine188 may make forecasting decisions based on past load data taken from any suitable period in the past. However, in particular embodiments, forecastingengine188 may analyze only recent past load data, as older past load data may be outdated and may provide for less accurate predictions. For example, older past load data may provide for less accurate predictions if the demands of manufacturers or commercial outlet operators changes. It should further be noted that once a forecasted leg is added to a tour, the forecasted load associated with the forecasted leg may be taken into account if a user desires to create another tour with the same forecasted leg. Thus, for example, forecastingengine188 may take into account that one of the forecasted loads has already been requested for another tour and may reduce the number of loads that it forecasts as available for the leg of the particular tour it is considering by one.

Access todynamic optimizer system270 throughoptimizer interface190 offers yet another tool that a user oftour command center180 may use to create more effective tours.Dynamic optimizer system270 may comprise any suitable optimizer operable to receive load data and generate a tour solution that offers a maximum yield for the load data that it receives. In embodiments in which PTA information is also used to create tours,dynamic optimizer system270 may be operable to receive PTA information and load information and create a maximum yield solution based on these factors. As described above, sending all load information received bytour command center180 todynamic optimizer system270 may be undesirable because allocative efficiency may not be the only interest at play in the distribution network (and becauseoptimizer270 may not offer a solution for all of the loads). However, there may be times when a user desires to send a subset of the unsolved loads received fromdispatch system110 todynamic optimizer system270 to find the most efficient tour solution for that subset of loads. This may occur, for example, after the user has created tours manually and/or using the template engine, and a subset of unsolved loads remains for which the user desires to create optimally-efficient tours.Dynamic optimizer system270 may be operable to receive the subset of loads and generate the most efficient tour solution for those loads, taking into account factors such as, for example, waiting time between legs of a tour and distance to be traveled. The most efficient tour solution may comprise the set of tours for the subset of loads with the least aggregate cost. The user may then select whether to accept or reject the tour solution generated bydynamic optimizer270. If the user accepts the tour solution, the tours in the tour solution are stored intours data store260. It should be noted that in creating a tour solution,dynamic optimizer system270 may be further operable to accesspast load data250 to forecast legs in order to create an even more efficient tour solution (similarly to the manner in whichforecasting engine188 may accesspast load data250 to forecast legs).

Report engine

192 oftour command center180 may comprise any suitable engine operable to accesstours data store260, generate a report of the tours that have been created and stored, and send the report to dispatchsystem110.Tours data store260 may comprise the tours created and stored by a user during one or more sessions. These tours may have been created automatically, manually, usingtemplate engine186, and/or usingdynamic optimizer system270. After a tour is stored intours data store260, a user may reconsider the particular tour and modify the tour or delete the tour fromdata store260. A tour may be deleted, for example, if all loads in that particular tour are removed. After a user is satisfied with one or more of the tours intours data store260, the user may forward one or more of the tours to dispatchsystem110. Alternatively,report engine192 may automatically forward one or more of the tours to dispatchsystem110.Report engine192 may do so, for example, after the user logs out oftour command center180. In particular embodiments, the tours in the tours report may be stored intour data store170. The user oftour command center180 may be required to log intodispatch system110 in particular embodiments to store the tours in the report intour data store170.

In operation,dispatch system110 may receive, throughdispatcher interface112, load and PTA information from dispatchers at distribution centers120 or at any other suitable location such as, for example, a field office.Dispatch system110 may additionally or alternatively receive PTA information from commercial carrier operators themselves through, for example,communication device130 overnetwork140.Dispatch system110 may also additionally or alternatively receive load information from manufacturing sites or commercial outlets. After receiving PTA and load information,dispatch system110 may store that information in

data stores

150 and160, respectively.

A user may accesstour command center180 throughuser interface182.Tour command center180 may authenticate the user and authorize access by comparing information received from the user with master data parameters. After the user logs on to tourcommand center180, the user may prompttour command center180 to request, receive, and store the PTA and load data in

data stores

210 and220, respectively. Alternatively,tour command center180 may request, receive, and store the PTA and load data automatically.

After PTA and load data is stored, the user may begin creating tours. Additionally or alternatively, tours of one may automatically be created for outbound loads and/or for inbound loads as dead-heads. The user may create or modify tours manually, which refers to manually pairing loads. Additionally or alternatively, the user may accesstemplate engine186 to apply one or more templates to all or a subset of the loads. Additionally or alternatively, the user may accessdynamic optimizer system270 throughoptimizer interface190 to receive a tour solution for one or more subsets of loads.

For particular tours, a leg of the tour may be forecasted. A user may useforecasting engine188, past load data instore250, and optionally constraint definitions instore230 to add forecasted legs based on forecasted loads to tours created manually. Additionally or alternatively, forecastingengine188 and pastload data store250 may be used in conjunction withtemplate engine186 to forecast legs of template tours. Additionally or alternatively,dynamic optimizer system270 may forecast legs of tours using past load data instore250.

For particular tours, the user may accessconstraint engine184 to determine whether one or more constraint definitions stored indata store230 may be violated by a particular tour. Additionally or alternatively,constraint engine184 may automatically flag tours that violate constraint definitions instore230. These definitions may be mandatory or default definitions. Tours that violate mandatory definitions may not be created. Tours that violate default definitions may be created if the default definitions are overridden by the user or by the user's superior for the particular tour (whether by passively overriding the default definition, such as by ignoring the flagged status of a tour, or by actively overriding the default definition, such as by removing an impediment to creating a tour).

Tours that are created may be stored intours data store260. If a user is dissatisfied with one or more tours indata store260, the user may modify or delete those tours. After a user is satisfied with the tours indata store260, the user may promptreport engine192 to generate a report of the tours indata store260 and to send the report to dispatchsystem110. Alternatively,report engine192 may automatically generate a report of the tours indata store260 and send the report to dispatch system110 (at the end of a user session, for example). At any suitable time, such as, for example, after the tours have been created, information associated with the loads comprising the tours may be stored in pastload data store250 to be used for forecasting legs of future tours.

After receiving the report of tours fromtour command center180,dispatch system110 may store the tours intour data store170.Dispatch system110 may communicate tour data to dispatchers at distribution centers120 or at any other suitable field office throughdispatcher interface114. Alternatively, commercial carrier operators may access and accept available tours throughinterface114 using acommunication device130 over anetwork140. In this way, the transport of freight may be effectively managed insystem100.

Modifications, additions, or omissions may be made to thesystem100 described without departing from the scope of the invention. The components of thesystem100 described may be integrated or separated according to particular needs. Moreover, the operations of thesystem100 described may be performed by more, fewer, or other components without departing from the scope of the present invention.

FIG. 3 is a flowchart of anexample method300 of managing the transport of freight according to one embodiment of the present invention. Atstep310, the tour command center receives load data from the dispatch system. The tour command center may receive the load data from the dispatch system after it is prompted by a user of the tour command center. Alternatively, the tour command center may receive the load data automatically. The tour command center may store the load data in an “unsolved loads” data store after it receives the data. In particular embodiments, any PTA information may be ignored in creating tours. In these embodiments, unlimited power time availability may be assumed for outbound loads (and/or dead-head, inbound loads). In alternative embodiments, the tour command center may receive PTA data in addition to load data from the dispatch system.

At step320, the actual process of creating tours begins. Tours may initially be created automatically by the tour command center. For example, the tour command center may automatically create tours of one for outbound loads and/or inbound loads. Additionally or alternatively, the user of the tour command center may decide whether to create tours from the unsolved loads manually (atstep320a), using a template (atstep320b), or using an optimizer (atstep320c).FIG. 4, described further below, is a screen shot of an example user interface at the tour command center.FIG. 4 illustrates how a user may create tours manually, using a template, or using an optimizer in one embodiment.

A user may decide to use one or more of the three methods to create tours. For example, a user may create tours manually (at step330) for two or more of the unsolved loads. The user may also apply the tour templates to a subset of the unsolved loads (at step340) and accept one or more of the tours suggested using the templates (at step350). The user may also run the optimizer for a subset of unsolved loads to generate a tour solution for those loads (at step360) and accept or reject the tour solution (at step370). Any remaining unsolved loads may be reconsidered through any of the three methods. It should be noted that mandatory and/or default constraints may be applied, automatically or after a prompt by a user, to any created tour. It should further be noted that legs of tours may be forecasted, based on, for example, past load data and a constraint, in creating tours using one or more of the three methods.

The generated tours are stored atstep380. Atstep390, a report of the tours is created either automatically or after a prompt by a user. Atstep400, the report is sent to the dispatch system. Atstep410, the dispatch system stores the tours and distributes them to dispatchers located at distribution centers or other suitable field offices for distribution to commercial carrier operators. Additionally or alternatively, the dispatch system may distribute the tours to commercial carrier operators themselves over a network such as the Internet. The transportation of freight may thus be managed effectively.

Modifications, additions, or omissions may be made to themethod300 described without departing from the scope of the invention. The components of themethod300 described may be integrated or separated according to particular needs. Moreover, the operations of themethod300 described may be performed by more, fewer, or other components without departing from the scope of the present invention.

FIG. 4 is a screen shot of anexample user interface500 at a tour command center according to one embodiment of the present invention. The example user interface comprises an infeasible (or “unsolved”)load section510, atours list section520, a highlightedtour section530, atemplate engine button540, adynamic optimizer button550, and ahistory button560. It should be noted that the screen shot may not capture some of the information displayed at the tour command center, and described below, that would be accessed by using the illustrated scroll bars.

Infeasible load section

510 comprises the unsolved loads downloaded from the dispatch system that have not yet been assigned to any tour. The header ofsection510 identifies the total number of unsolved loads displayed and provides a drop-down menu that allows a user to filter the loads by their division. A division refers to the geographic area associated with a load. The header also provides a “Show only Unlocked” check box that a user may select to display only those loads that have not been locked and are available for tour creation or tour modification. The remainder ofsection510 provides detailed information associated with each unsolved load, and the information is organized into multiple fields.

In addition to fields,section510 may include command buttons for a user to select for particular purposes. Command buttons may include, for example, a button to lock a load (so that other users may not access the load, for example), a button to display detailed stop information for a particular load, a button to display a map of the load itinerary, and a button to display a window showing the total miles, total out of route miles, and/or estimated time of arrival if the selected load is added to a pre-selected tour(s). Another command button may include a button to move a load to a tour intours list section520 and a button to add a new tour totours list section520 comprising the selected load.

Tours list section

520 comprises the tours that have already been created. These tours may be modified by adding or removing legs, deleted, or locked so that other users cannot access the loads comprising the locked tour to create another tour. The header ofsection520 identifies the total number of tours displayed and provides drop-down menus that allow a user to filter the tours by their first origin or by their division. The header also provides a “Show only Unlocked” check box that a user may select to display only those tours that have not been locked. The header additionally provides a button to modify the display ofsection530. The remainder ofsection520 provides detailed information associated with each tour, and the information is organized into multiple fields.

Tours list section

520 also includes fields comprising checkboxes. Some boxes are checked automatically to alert a user that a tour satisfies a pre-determined condition. For example, a tour that comprises more than one load is automatically flagged as “paired.” A tour that violates a constraint may also be automatically flagged. These constraints may include a “no dead-head” constraint which identifies a tour with one load where the direction is inbound, a “no date discrepancy” constraint which identifies paired loads where the first load arrives at its destination after the second load on the tour must depart, or a “no stranding” or “destination” constraint which identifies a tour where an operator is left stranded at the end of the tour because the origin of the first load is not the same as the last stop destination of the last load of the tour. If a tour violates a default constraint, the box flagging the constraint violation may be unchecked by the user or by or with the permission of the user's superior to override the warning.

Tours list section

520 also includes command buttons for a user to select for particular purposes. For example, a user may lock a tour by selecting the “locked” button beside each tour. Once locked, other users may not access the load(s) comprising the locked tour to create other tours. However, other users may access these loads if the user unlocks the tour by deselecting the “locked” button.

Highlightedtour section530 comprises a detailed description of a tour intours list section520 that has been selected. The header ofsection530 provides the tour identification number of the selected tour, the early departure time of the first stop in the selected tour, the early arrival time of the last stop in the tour, the total miles for the tour, the total out of route miles for the tour, the total hours for the tour, and the estimated time of arrival of the tour.Section530 also provides a cost button, which, when selected, opens a window displaying the tour cost, the wait time cost, the dead head cost, and the outbound cost. The remainder ofsection530 provides detailed information associated with each load in the tour, and the information is organized into multiple fields.

The fields insection530 include a pro number field, a sequence number field (which identifies the sequence of the loads in the tour), an equipment type field, a type of load field (inbound or outbound), a load division field, a departure date field, a reference number field, an origin code field, an origin city field, a destination code field, a destination city field, an arrival time field, a load identification field, a stops field, a loaded “L” miles field (which identifies the number of loaded miles for the load), an “hours to next pick-up” field (which identifies the time between the early arrival of the previous load and the early departure of the current load), and an empty “M” miles field (which identifies the number of empty miles for the load). It should be noted that particular information associated with a load displayed in highlightedtour section530 may be modified by a user.

In addition to fields,section530 may include command buttons for a user to select for particular purposes. Command buttons may include, for example, a “change division” button that allows a user to change the division of a load, a “map” button that opens a map window with the load itinerary, a “displays stops” button that opens a window that displays detailed stop information, and a “remove load” button that removes a selected load from a tour. It should be noted that, after a load is removed from a tour, the load may become an unsolved load insection510. Furthermore, after the load is removed from the tour, one or more of the tour's parameters (appearing insections520 and530) may be recalculated to reflect the removal of the load.

Template engine button

540 may be selected by a user to send all or a subset of the unsolved loads to a template engine, such as, for example, the template engine described above with reference toFIG. 2.Dynamic optimizer button550 may be selected by a user to send all or a subset of the unsolved loads to a dynamic solver, such as, for example, the dynamic optimizer described above with reference toFIG. 2. It should be noted that althoughtemplate engine button540 anddynamic optimizer button550 may be located in infeasible loads section510 (as illustrated), these buttons may alternatively be placed in any other suitable window, such as, for example, a separate window that also displays a report button (which may generate a report of the tours created and send the report to the dispatch system).History button560 may be selected by a user to display past load data in order for the user to forecast legs for a tour. In alternative embodiments,history button560 may access a forecasting engine that may forecast a particular load for a particular leg and determine whether the leg may be added to a tour, returning the result to the user.

In operation, a user accessing tour commandcenter user interface500 may analyze the loads ininfeasible load section510 for the purpose of creating effective tours. The user may create tours from these loads manually, using the template engine (via button540), and/or using the dynamic optimizer (via button550). The user may further select the history button to facilitate forecasting of legs. The tours created may populatetours list section520. After one or more tours are created, the user may select a particular tour intours list section520. After the user selects the tour, the tour may be displayed in highlightedtour section530, allowing the user to evaluate the tour more closely. Tourcommand center interface500 may thus allow a user to quickly and easily create and evaluate tours. After evaluating the created tours, the user may open a window displaying a report button, select that button, and send the created tours to the dispatch system.

Modifications, additions, or omissions may be made to theuser interface500 described without departing from the scope of the invention. The components of theuser interface500 described may be integrated or separated according to particular needs. Moreover, the operations of theuser interface500 described may be performed by more, fewer, or other components without departing from the scope of the present invention.

Although the present invention has been described with several embodiments, various changes and modifications may be suggested to one skilled in the art. It is intended that the present invention encompass such changes and modifications as fall within the scope of the appended claims.

Claims

1. A method for managing the transport of freight, comprising:

receiving information associated with at least a first plurality of loads and a second plurality of loads;

applying at least one template to at least part of the information associated with at least the first plurality of loads, each template suggesting one or more preferred legs for at least one tour;

allowing a user, through a user interface, to accept one or more of the tours suggested by the at least one template; and

allowing the user to manually create or modify one or more tours using at least part of the information associated with any loads that do not yet comprise an accepted tour.

2. The method ofclaim 1, wherein the loads are associated with a plurality of distribution centers.

3. The method ofclaim 1, further comprising:

determining whether at least one of the suggested, accepted, created, or modified tours violates at least one constraint definition;

if the at least one constraint definition comprises a mandatory constraint, preventing the user from sending the tour that violates the mandatory constraint to a dispatch system;

if the at least one constraint definition comprises a default constraint, notifying the user of the tour that violates the default constraint; and

allowing the user to override the default constraint and send the tour that violates the default constraint to the dispatch system.

4. The method ofclaim 1, further comprising allowing the user to forward at least part of the information associated with one or more of the loads that do not yet comprise an accepted tour to an optimizer, the optimizer operable to suggest at least one tour solution for some portion or all of the loads associated with the information that the optimizer receives.

5. The method ofclaim 2, wherein tours are created or modified assuming unlimited power time availability at the distribution centers.

6. The method ofclaim 1, wherein power time availability information is considered in creating or modifying tours.

7. A method for managing the transport of freight, comprising:

allowing a user, through a user interface, to send at least part of the information associated with only the first plurality of loads to an optimizer, the optimizer operable to suggest a tour solution for some portion or all of the first plurality of loads; and

allowing the user to accept the tour solution suggested by the optimizer.

8. The method ofclaim 7, further comprising allowing the user to manually create or modify one or more tours using at least part of the information associated with any loads that do not yet comprise an accepted tour.

9. The method ofclaim 7, wherein the loads are associated with a plurality of distribution centers.

10. The method ofclaim 9, wherein tours are created or modified assuming unlimited power time availability at the distribution centers.

11. The method ofclaim 7, wherein power time availability information is considered in creating or modifying tours.

12. The method ofclaim 7, wherein the optimizer may use at least past load data and a constraint to predict that a particular load will be available to transport at a particular time in the future, and based on this information, add one or more legs to one or more of the tours in the tour solution.

13. A method for managing the transport of freight, comprising:

receiving information associated with a plurality of loads;

allowing a user to manually create or modify one or more tours using at least part of the information associated with the loads; and

allowing the user to predict whether a particular load associated with a particular leg will be available to transport at a particular time in the future in order for the user to decide whether to add that leg to a tour.

14. The method ofclaim 13, wherein the prediction is based at least in part on past load data and a constraint.

15. A method for managing the transport of freight, comprising:

receiving information associated with a plurality of loads; and

allowing a user, through a user interface, to:

apply at least one template to at least part of the information associated with one or more of the loads, each template suggesting one or more tours comprising one or more preferred legs, each leg associated with at least one load that the particular template considers;

accept one or more of the tours suggested by the at least one template;

manually create or modify one or more tours using at least part of the information associated with one or more of the loads, wherein:

a leg in at least one of the manually created or modified tours is added after a user predicts, based at least in part on past load data, that a particular load associated with the particular leg will be available to transport at a particular time in the future; and

a determination is made whether at least one of the manually created or modified tours violates one or more constraints;

send at least part of the information associated with two or more loads to an optimizer, the optimizer operable to suggest at least one tour solution for some portion or all of the loads associated with the information that the optimizer receives; and

accept the tour solution suggested by the optimizer.

16. Logic encoded in a computer-readable medium, the logic operable when executed by a computer to:

receive information associated with at least a first plurality of loads and a second plurality of loads;

apply at least one template to at least part of the information associated with at least the first plurality of loads, each template suggesting one or more preferred legs for at least one tour;

allow a user, through a user interface, to accept one or more of the tours suggested by the at least one template; and

allow the user to manually create or modify one or more tours using at least part of the information associated with any loads that do not yet comprise an accepted tour.

17. The logic ofclaim 16, wherein the loads are associated with a plurality of distribution centers.

18. The logic ofclaim 16, further operable when executed by a computer to:

determine whether at least one of the suggested, accepted, created, or modified tours violates at least one constraint definition;

if the at least one constraint definition comprises a mandatory constraint, prevent the user from sending the tour that violates the mandatory constraint to a dispatch system;

if the at least one constraint definition comprises a default constraint, notify the user of the tour that violates the default constraint; and

allow the user to override the default constraint and send the tour that violates the default constraint to the dispatch system.

19. The logic ofclaim 16, further operable when executed by a computer to allow the user to forward at least part of the information associated with one or more of the loads that do not yet comprise an accepted tour to an optimizer, the optimizer operable to suggest at least one tour solution for some portion or all of the loads associated with the information that the optimizer receives.

20. The logic ofclaim 17, wherein tours are created or modified assuming unlimited power time availability at the distribution centers.

21. The logic ofclaim 16, wherein power time availability information is considered in creating or modifying tours.

22. Logic encoded in a computer-readable medium, the logic operable when executed by a computer to:

allow a user, through a user interface, to send at least part of the information associated with only the first plurality of loads to an optimizer, the optimizer operable to suggest a tour solution for some portion or all of the first plurality of loads; and

allow the user to accept the tour solution suggested by the optimizer.

23. The logic ofclaim 22, further operable when executed by a computer to allow the user to manually create or modify one or more tours using at least part of the information associated with any loads that do not yet comprise an accepted tour.

24. The logic ofclaim 22, wherein the loads are associated with a plurality of distribution centers.

25. The logic ofclaim 24, wherein tours are created or modified assuming unlimited power time availability at the distribution centers.

26. The logic ofclaim 22, wherein power time availability information is considered in creating or modifying tours.

27. The logic ofclaim 22, wherein the optimizer may use at least past load data and a constraint to predict that a particular load will be available to transport at a particular time in the future, and based on this information, add one or more legs to one or more of the tours in the tour solution.

28. Logic encoded in a computer-readable medium, the logic operable when executed by a computer to:

receive information associated with a plurality of loads;

allow a user to manually create or modify one or more tours using at least part of the information associated with the loads; and

allow the user to predict whether a particular load associated with a particular leg will be available to transport at a particular time in the future in order for the user to decide whether to add that leg to a tour.

29. The logic ofclaim 28, wherein the prediction is based at least in part on past load data and a constraint.

30. Logic encoded in a computer-readable medium, the logic operable when executed by a computer to:

receive information associated with a plurality of loads; and

allow a user, through a user interface, to:

accept one or more of the tours suggested by the at least one template;

accept the tour solution suggested by the optimizer.