Home' MHD Supply Chain Solutions : MHD Nov-Dec 2014 Contents 62
WHY TRANSPORT OPTIMISATION PROJECTS GO
WRONG, HOW TO GET THINGS RIGHT -- AND HOW
A GROUP OF WORLD-RENOWNED RESEARCHERS
IN AUSTRALIA DEVELOPED A SUCCESSFUL
COMMERCIAL TRANSPORT OPTIMISATION SYSTEM.
All software projects can go wrong for
a variety of reasons. Transport and
optimisation projects are particularly
risky, because they are difficult to get right and
errors lead to highly visible and costly outcomes,
as seen with the Ariane rocket crash which
resulted from a software overflow. Nevertheless,
transport optimisation projects are well worth
implementing as they can bring about huge
savings with a relatively small investment.
Transport planning and scheduling systems
have been in active commercial use since
their deployment for military logistics in World
War II. To date, there have been two types of
systems: the first type automates the behaviour
of human dispatchers - a flexible approach, but
its optimisation is quite basic; the second type
incorporates optimisation algorithms tuned to a
specific version of the transport problem. The
drawback of this type is its inability to handle
Recent advances in optimisation techniques
have enabled novel transport planning and
scheduling systems to be implemented that
are both flexible and optimising. The Opturion
platform, developed by a group of world-
renowned researchers in Australia, supports
a number of successful commercial transport
optimisation systems of a third type, for which
the flexibility and high quality of its results have
been proven at the coal face.
Managing software projects can be problematic
in that only once the software has been imple-
mented, is its functionality precisely specified.
It is easy to stipulate that 'vehicles should take
the best route' or that 'drivers should be allowed
sufficient time for breaks' for example, but such
requirements are imprecise. Moreover, it is easy
to omit specific mention of obvious constraints
-- that a B-double truck cannot enter a driveway,
for example. When the software is finally tested
it often proves not to have enforced the actual
customer requirements. Furthermore, by the
time the software is completed, these specifi-
cations may have changed; for instance, there
may be new laws on driver breaks, new routing
methods and even new conditions on customer
sites. Three months is a long time in business!
Novel software often enables, or imposes
, novel ways of working. The opportunity for
improved efficiency can be experienced instead
as a threat by the users of the software, and as
a result the new process may be undermined by
the very people who need to make it work.
Finally, whilst it is possible to observe
progress during the construction of a house, the
construction of software is practically invisible to
everyone except the implementers. The mantra
that a software implementation is '90% finished'
can be repeated for months! As software
projects go on, their expected completion dates
often start to slip, faster and faster until the time
till completion ceases to narrow. Under these
circumstances the project will never end!
Software (TOS) risks
Transport disruptions resulting from software
bugs are obvious and expensive.
Optimisation adds another layer of difficulty
to the usual software risks. If the software fails
to meet all the user requirements, or when
the requirements change over time, adapting
optimisation software is challenging and time-
consuming. This is because the algorithms
encoded in the software usually need amending
in order to find good solutions satisfying the
new requirements. Developing a new algorithm
may cause old requirements to be violated, or
may need more computing resources, may yield
lower quality solutions, or may even fail to scale
to the original problem size.
A fundamental issue when managing a
software optimisation project is how to tell
whether a solution is 'optimised'. When a
problem has previously been tackled by hand,
the solution produced by the software may
be radically different, making it very hard for
the problem experts to determine whether the
new solution is either correct or of high quality.
Worse still, even if the new solution proves to
be correct and looks good to the human expert,
there may be much better solutions undetected
by the software.
For academic problems, such as the 'Travelling
Salesman Problem' (of which more will be dis-
cussed later), it is sometimes possible for the
algorithm to prove that the solution it has found is
indeed the best possible solution. Unfortunately,
even the most powerful computer grids are
unable to complete such proofs for real-world
application problems. Moreover, from a theo-
retical point of view, this limitation will never be
overcome by bigger and faster computers.
Why bother with TOS?
Given the risks of transport optimisation
software, it is tempting to ask why one should
bother with it at all! The answer is that when it
works, TOS projects yield tremendous benefits
that dramatically enhance the competitiveness
of the companies where they are deployed.
British Telecom, for example, used optimisation
software to reduce the travel and waiting times
for their field engineers. As a result, the average
number of jobs per day for each engineer
-- PART 1.
PROFESSOR MARK WALLACE AND PAUL BELL
MHD SUPPLY CHAIN SOLUTIONS --- NOVEMBER / DECEMBER 2014
Links Archive MHD Spt-Oct 2014 MHD Jan-Feb 2015 Navigation Previous Page Next Page