|
| |
| Some years ago we wrote a short white paper on the evolution and expanded direction of inbound transportation planning
software ("Inbound Logistics Management"). That paper highlighted the increased type of motor freight shipments
involving multi-stop pick-up and drop-offs. Such shipping patterns were a part of an increasingly complex transportation
management system (TMS) software that attempted to model all potential ways of product distribution as it passes from raw
material / parts delivery to manufacturing, to retail shipments and finally to the customer. The retailer, a relatively new
party to "inbound" transportation planning, proved also to be the key player in establishing the need for a more
complex TMS software. |
| |
- Multi-stop linehaul through a set of vendors or suppliers.
- Multi-stop linehaul including a stop at a pool point or consolidator.
- Backhaul from a vendor or supplier at the end of multi-stop linehaul.
- Continuous move of a truckload carrier involving emptied trailers at each stop.
- Multi-stop linehaul with partial unloading, loading to capacity, partial unloading in order to maintain a continuously
full trailer.
- Multi-stop into a pool or consolidator site in conjunction with multi-stop drop-off.
- Multi-stop linehaul pick-up from vendors / suppliers to multi-stop drop-off.
- Multi-stop into and out of pool or consolidator sites in conjunction with multi-stop linehaul.
- Multi-stop assessment of best point to ship into / out of (e.g. DC, consolidator or store/drop/ship.)
|
| |
| "Inbound Logistics Management " made clear the need to evaluate all possible ways a shipment could be routed
(to best determine the minimum cost of shipping a product), which increased the requirements on the optimization routines
in processing the higher number of combinations of alternative routes in such a transportation model. The solvers,
i.e., the mathematical algorithms used to process data in the transportation model, took one, or a combination of,
two forms: A non-linear LP solution, where all combinations of routing and their costs are tested, or a heuristic solution,
where in conjunction with the logic of the transportation mode, an optimal, least-cost, best solution is obtained from a reduced
set of logically derived alternative combination of moves. Most vendors of TMS software have tried both solver approaches with
their current offering reflecting the way the wind blows when they are asked, versus sound problem solving decisions. More on
this later. |
| |
| The conclusion of "Inbound Logistics Management " was: |
| |
The new inbound system then breaks down the barrier between inbound and outbound logistics management. (In fact, the
maturity of requirements for the inbound system overshadows the need for an outbound system. The inbound system of Year
2000 will consider both inbound and outbound moves as if they are independent of their respective origins or destinations.)
Redefining all shipments as inbound results in a focus on customer service, i.e., concentration on the delivery date
rather than the destination. This also conforms to the now old concept of just-in-time delivery.
|
| |
| The conclusion of "Inbound Logistics Management ", then was there is only inbound transportation planning, that we
are always talking about planning to a time-space delivery; there is no concept -- outbound transportation planning. |
| |
| With much hindsight and some foresight, this paper argues that the current transportation models for TMS software would suggest
that we should abandon the concept -- inbound [transportation] logistics management as well. As a result of newer transportation
models whose intent is to improve the economic efficiency in product shipment, motor freight carriers in particular are never
traveling inbound or outbound but are continually moving in an attempt to maintain a full trailer at all points of the move.
Of course this also results in a more efficient, cost reduction, use of a driver's time. Examples of such continuous moves are
the following: For a retailer the trip of a contracted carrier may involve a pick-up at a vendor, a drop-off of a partial
load at a DC, a shuttle of a partial load from that DC to another DC where the entire load is dropped of and the driver and power
unit then pick-up a new trailer and deliver a multi-store load, followed by a pick-up at several vendors starting the process
all over. Again no inbound or outbound move occurs. A manufacturing shipper example finds the pick-up of raw materials,
unassembled parts at several suppliers, with the next step delivery to an assembly point where the trailer is reloaded for
delivery to multiple customer locations, and the shipment process is continued with the pick-up of parts. |
| |
| What the above examples of retail and manufacturing shipping patterns point to is a significantly more complex data management
issue where events in a continuously changing time-space continuum must be compared. To "optimize" the transportation
model (the process) and the optimizing solver (the mathematical solution calculator) must be sensitive to the data driving the
solution. Unfortunately, TMS' are data driven, therefore data sensitive. If the locations of the orders to be delivered
are scattered versus clustered a pooling TMS model may not apply; if LTL rates are extremely low in a particular region, a
continuous move solution will not "optimize", that is, minimize transportation costs; if on a particular day
equipment is unavailable then an optimal cost solution may not be a solution at all. All information (time-space data) is
in a state of change. This is a TMS software issue because location is added to the model. In the past we worried about our
transportation model not having across-industry application. That is, we could not use the retail TMS software in a
manufacturing shipping environment. Now we discover that the model (all transportation TMS models) is sensitive to the
data processed today versus yesterday, etc., largely again because a data value also has a location. |
| |
|
| |
| What events in the last several years likely impact TMS software and their underlying transportation model, as well as the
technology of the software? Examples are the: |
| |
- Rapid rise of Web-based or Web-component TMS software as well as firms offering Web-ASP.
- Related, increased use of the Internet to conduct business transactions.
- Attempts at collaborative planning across the supply-chain (for the most part confined to a segment of the market
-- the food industry).
- Rapid fall in Web-based providers of transportation logistics systems.
- Shortage of motor freight equipment and drivers.
- Downturn in the economy; dramatic drop in traditional shipping activity.
- Surplus of transportation capacity.
- Rapidly fluctuating fuel prices; uncertainty in fuel prices.
- Perceived need to track and trace a shipment (created out of the expanding small package / overnight delivery services
where the real issue became "when" will my shipment be delivered, not "where" is my shipment.
- Systems departments, as overseers of TMS software, increasingly desire integrated systems versus "best-of-breed"
TMS software.
- Overpricing of business software (TMS, et al.) as a result of Y2K demand with deep discounting of software in 2002.
- Systems became increasingly more difficult to install.
|
| |
|
| |
| What impact has the above had on TMS software and what directions has the software taken in response? First, from Web-based
solution for TMS, the more recent software is easier for the end-user to navigate around. Interfaces to the application and
database are more straight forward. Second, transportation models continued to become more complex as traffic departments
expand the routing possibilities or importance that transportation played in an overall manufacturing process. Two examples
can be given: The need to plan cross-dock moves that merge orders from different origin points going to the same destination
by controlling transit times (named, merge-in-transit); and in a manufacturing setting, planning production cycles based on
optimal shipment execution. That is, working back from promised customer delivery dates, if "ready-to-ship" dates
remain open and the overall transportation costs are minimized, what "ready-to-ship" date can be established for
what particular orders? Then production schedules are set to meet the required "ready-to-ship" date. Third, while
solvers have remained static in their processing power there has been an increased use of non-linear integer LP solvers to
perform most optimization routines. Fourth, access to transportation information, and the quality of that data have greatly
improved particularly with the maturing of the Internet. |
| |
|
| |
| After over ten (10) years of creating artificial intelligence (AI) software, the developers of optimization software systems
are again exploring the role of AI in business systems. The definition of such TMS' software's use of AI seems limited
to either a "learning" of the more current rates charged by the carrier or the selection of a particular transportation
solver based on the transportation planning environment (as example, the ARCLOGIX software, in the past, called either a branch
and bound heuristic or an LP solver in routing a shipment depending on the number of stops involved in the trip). |
| |
| However, the transportation model itself did not experience a metamorphosis. Until we learn from the unique data presented
the system, and the transportation model and the solver are restructured based on particular data stimuli, we are only
"selectively" choosing from a library of models and optimizers as they best match past examples of each. In fact
the data should trigger a change in the transportation model and the solver, i.e., in the process flow that manipulates
the data and in the mathematical calculation approach, i.e., the way the solver is executed. |
| |
|
| |
| A transportation model is comprised of rules and links between the rule statements, and the data driving the model. Rules
define the model, i.e., how and when to process information. Links connect the rules (their objects) to particular
data that further define the structure of the model. With today's transportation models the structure of the model remains
static. The model may utilize different objects (rules) and selectively choose different links (hence different information),
but rules and links are all predefined in the old model. The issue at hand: How does the software create new (and different)
rules and links that are a product of new information while at the same time defining what information and how the information
will be processed? That is, how can we create an adaptive (learning) dynamic transportation planning model where the rules and
links are not merely selected but actually change over time-space? Here we would achieve the true AI concepts in our model. |
| |
| The stimuli for change in the transportation model are the new information on the material or commodity to be shipped, the
locations of all the transfer points and their associated information, the travel network involved, the carrier mode and the
associated rates, and if applicable, the locations of available equipment (e.g., trucks). A model restructuring,
i.e., dynamic model building, is triggered by the AI part of the system drawing inferences from a "reading" of the
current information set. As with human processing of information, inferences are in the form of likely, or probability,
conclusions. The model is redefined based on how the stimuli cause changes in the rules and the building of links between
rules and the data involved. Rules are broad categories defining the transportation process. The process is controlled by
tunable parameters where the parameters define the rules. Parameters contain a range of values with the numeric value and
range specific to the type of parameter. Parameters are changed (hence the rule structure) based on the specific value
derived from the system's interpretation of the information presented to the transportation model at any one time.
The model structure can change each time the software reads a new set of stimuli. The software can be executed with each
new different set of stimuli, making both the model dynamic as well as the transportation planning results. |
| |
|
| |
| In traditional TMS software a historical view had to be taken to orient the transportation model toward a multi-stop pool
delivery model or a multi-stop linehaul delivery pattern. The decision on which model to weight more heavily often dependent
on history, how the traffic department wanted to use pool carriers, and in a manufacturing setting, the scatter or locations
of the orders to be delivered to customers. With this software the model was set-up on some sample period's data, fine-tuned,
or determined a priori and forever run with a pool or linehaul multi-stop bias. |
| |
| An example of an AI-based TMS model is the following. The example is much simplified to make the discussion more clear. The
software reviews the orders to be moved and finds orders are to be delivered in distinct patterns around major urban areas.
A sum of the weight for each cluster of orders is approximately a full truck load (40,000 pounds average). The software checks
for the availability of pooling sites and finds one at each cluster, The software adjusts the pooling parameters which
"forces" more orders through pool points thus assuring full truck loads into pools and a more efficient use of
truckload carriers. The next day the order-set shows that the locations of orders are scattered along major Interstates.
The linehaul parameter is activated, with the setting magnitude determined by the probability of several measures, one of
which is how strong is the linehaul delivery pattern given the destination location of the orders. |
| |
|
| |
| The value of the AI dynamic transportation model is straight forward: |
| |
| First, because the model's structure changes with the specific transportation data input, the model is easily adaptive
to cross-industry applications, thus solving the most basic problem facing a TMS software implementation -- adjusting the
transportation model developed for one industry to fit the conditions unique to another industry. The process of implementation
involves the running of the software against real data versus the implementation team second guessing the best setting of the
business rule parameters. Second, we have argued because of the "location" of all elements of data driving a TMS,
the transportation model producing the optimal results today may prove to be the worst solution the next day with a different
set of transportation data. The "location impact" is something we as model builders have only learned with TMS model building
over the last decade. We mistakenly have attributed this location factor to industry differences, versus a separate factor with
TMS software as a subset of supply chain management software. The AI dynamic transportation model addresses the location factor
by adjusting the model's structure as each new data set processes, with the adjustment of the business rules parameters
specifically evaluating the impact that location (of the data) has on the model's structure. |
| |
|
| |
| This paper identifies a weakness in current (on the street) TMS transportation model software, while highlighting the root cause
(location attributes) as the deficiencies of such models. The paper spells-out how ARCLOGIX has addressed the issues raised with
an AI-based dynamic (adaptive) transportation model. This model is representative of increased discussion by the OR-optimization
modeling body to bring AI concepts back into supply chain software model building. We believe this trend will dominate the next
decade. |
