Discovering the EIS Architecture that Supports Hub-and-Spoke
Freight Transportation Networks Operating in a Cross Dock Mode
Nick Szirbik and Paul Buijs
Department of Operations, University of Groningen, Nettlebosje 2, 9747 AE Groningen, The Netherlands
Keywords: Function-driven Development, Logistic Coordination and Control, Networked System Integration.
Abstract: We propose a line of research for road freight logistics that may deliver novel enterprise information system
(EIS) architectures, procedures, and novel ways of applying existing technology, with the direct objective of
enabling and making more efficient a variation of an existing logistic scenario, which is presented to some
extent in this position paper. We argue that the enabling and support of this setting via appropriately
identified, tested, and practitioner-validated EIS functions may have the effect of increasing the load factors
in palletized road freight, as well as allowing mass Just-in-time (JIT) trans-shipment from small scale
suppliers and delivery to small scale end-customers.
1 INTRODUCTION
Recent studies (Marcucci and Puckett, 2012) show
that the average truck load factor for palletized
transport in Germany is 51%. Other national level
data estimates for EU countries give values that are
even lower than 50%. In two extreme
interpretations, these numbers suggest that either
most trucks travel half empty all the time, either that
they travel empty half of the transportation time (e.g.
one leg of their transportation journey). It is hard to
believe that these numbers are still so low, in the
light of the fact that dedicated enterprise information
systems (EIS), which contain functionality for
supporting the customer management, operations,
and analytics of the palletized road freight industry
have been massively deployed in recent decades.
Moreover, “cross-fertilizing” research activities
of vendors, practitioners, and academics led to the
development, standardization, and continuous
enhancement of various transaction and decision
support systems like highly complex Warehouse
Management Systems, Fleet Management Systems,
Yard Management Systems, Tracking and Tracing
Systems, as well as web based communication and
coordination systems. All these make use of
versatile, affordable, and embedded technologies
like board computers, GPS, RFID, wireless internet,
etc. Today, academic research is focused mostly on
various optimization problems faced when applying
novel kinds of logistic scenarios, leading to a
plethora of algorithms for resource allocation,
operations scheduling, route planning, network and
facility design, etc. The innovative professionals in
practice contributed most to the improvement of
these logistic scenarios. However, there are still gaps
of understanding between these two communities.
Our position is that academics doing research in
logistic process supporting ICT should be
encouraged, facilitated, and be able to better
communicate their own ideas directly to
practitioners. A potential way is to transform the
manner in which case studies – used to gather
empirical knowledge directly from practice – are
executed. Academics should have illustrative tools
which can be easily set and parameterized to reflect
the situation encountered in practice, and allow
practitioners and academics to cooperate for
improving scenarios and finding new ones.
This paper proposes such a way of cooperation
for potential research. We present first two related
logistic scenarios in LTL road freight that have been
investigated via a multi-year multiple-case study –
involving 13 large cases and a significant number of
smaller cases. The analysis of the results of these
studies revealed that in the execution of a variant of
the second scenario, there are still unanswered
questions about the functions necessary in the
supporting EIS architecture. That makes the
effective execution of this scenario variant difficult.
388
Szirbik N. and Buijs P..
Discovering the EIS Architecture that Supports Hub-and-Spoke Freight Transportation Networks Operating in a Cross Dock Mode.
DOI: 10.5220/0004566803880395
In Proceedings of the 15th International Conference on Enterprise Information Systems (ICEIS-2013), pages 388-395
ISBN: 978-989-8565-61-7
Copyright
c
 2013 SCITEPRESS (Science and Technology Publications, Lda.)

2 BACKGROUND
Increasingly, road-freight transportation companies
are confronted with shipments comprising smaller
volumes of freight which require more frequent
transportation with reduced lead times. These Less-
than Truck Load (LTL) shipments are volumes of
freight not large enough to justify dedicating an
entire truck, but are too large to transport by means
of a parcel delivery service. To realize economies in
transportation costs, these shipments are typically
consolidated with many other smaller-sized
shipments in order to transport them as full truck
loads. For example, in a cross dock, the
consolidation is performed while aiming for
minimum dwell-time between receiving and
shipping the freight (Boysen and Fliedner, 2010).
One of the main drivers that made cross docking
increasingly popular and necessary was the large
penetration of the Just-In-Time (JIT) strategy in
various manufacturing industries. Logistic
management quickly adopted JIT in transportation
and distribution, foreseeing correctly the desire to
achieve large reductions in inventories throughout
the supply chain. Already at the end of the last
century, a vast percentage of the freight distributed
by the top mass merchandisers (such as Walmart and
Kmart) have been consolidated at cross docks
(Napolitano, 2000). However, smaller companies are
only now starting to make the move towards JIT-like
delivery in their supply chains.
Cross docks appear in various sizes and
configurations, and there is still some debate about
the “exact” definition of a cross dock (Vogt, 2010).
To provide our interpretation of cross docking, we
propose three inter-related features characterizing
any cross dock, which remained unchanged since the
original definition given in (Napolitano, 2000):
(i) Every effort at a cross dock is made to
facilitate the flow of freight from the inbound
vehicles to the outbound vehicles in the minimum
amount of time possible.
(ii) There is no explicit inventory kept. The
freight is either moved directly from the inbound
vehicle to the outbound vehicle, or allowed a short
stay (named “staging”). Including a potential period
of staging, a shipment typically stays less than a day.
Moreover, no fee is charged by the transhipment
facility for the staging of a shipment.
(iii) In a transportation networks with a
transhipment facility, the information flow is
preceding the physical flow of shipments. The
supply chain actors give considerable attention to the
synchronization of inbound to outbound shipments.
This is achieved by means of externally
synchronized schedules, which aim to reduce the
trans-shipment time and resource utilization at the
facility, while reducing handling and transportation
lead times in the network as a whole.
We consider that only the first feature (i) is
fundamental for a cross-dock. Other logistic settings
may have (ii) and (iii), but if they do not present (i),
we, and many other researchers, do not consider
them a real cross docking setting, albeit (i) is
practically impossible to be realized without (iii). In
the following sub-sections, we present two logistic
scenarios with trans-shipment – one with that has the
cross dock fundamental feature (i), one that does not
have it, but clearly has (ii) and to some extent (iii).
After these two, we present a variation of the second
scenario that has elements of (i) and (ii), but it is still
lacking a proper understanding of how (iii) can be
fully realized form an EIS point of view.
2.1 Observed EIS Functionality for
Single-direction JIT Consolidation
This scenario refers to moving a shipment item from
a supplier and delivering it its consumer with little
material handling in between, only by passing it fast
through a cross dock – without the intermediate
steps of disposition, storage and order fulfillment
done in warehouses. The shipment is arriving in a
truck/trailer that contains multiple LTL shipments to
various consumers. These resulted from the same
supplier or an optimized “milk-run” from
neighboring suppliers. Immediately, the shipment is
moved to an outbound truck/trailer to consolidate a
full truckload (TL) for a consumer or consumers that
are easy to deliver to in one run – because they are
geographically close for example. At the moment
the full TL objective is achieved, the outbound
truck/trailer leaves immediately. In some instances,
the pallet does not touch the floor of the facility,
being moved directly from trailer to trailer, and in
other instances very short staging may be necessary.
The speed of this kind of material flow allows
precise JIT delivery at the consumer’s site (Erera et
al., 2013).
This scenario is implemented for certain products
in manufacturing supply chains, mostly for
perishable or promotional goods, but also for
products for which the demand and supply is highly
predictable. There are a series of ICT requirements
on the accompanying information flow and also on
the necessary resource allocation and planning
interaction (Larbi et al., 2011). Today, the
procedures and technologies used to support the
DiscoveringtheEISArchitecturethatSupportsHub-and-SpokeFreightTransportationNetworksOperatinginaCross
DockMode
389

monitoring, coordination and control of such a
logistic process are well established (Van Belle et.
al, 2012).
Large distribution and retail organizations,
supply chains like the ones in the automotive
industry, and also non-parcel transportation services
(for palletized freight) are using variations of this
scenario, and ample practice-based experience with
the ICT related issues exists. Also, there is
substantial empirical knowledge about the used in
practice EIS architectures and models. This
empirical information was mostly collected and
analyzed by academics, but also by vendors and
consultants.
From a functional point of view, derived directly
from critical requirements of operating as a cross
dock, the focus is on four main functions for an EIS
that covers the whole network:
a. Support for synchronization of trailer arrivals
and departures
b. Support for synchronization of the internal
operations with the schedules of the trailers
c. Support for dynamic door allocation
d. Support for staging decisions
The first functionality is required because there are
strong dependencies between the load of various
inbound and outbound trucks (Liao et al., 2013).
This is easily achieved if the overall supply chain
synchronization is already in place (that is, the
supplier’s and consumer schedules are already
aligned, which is natural in an JIT or/and lean
manufacturing setting, see Luo and Noble, 2012).
The second and the third functionalities are
realized by a mixture of tracking, identification
technology, and transaction processing, having on
top of these various dynamic resource allocation
mechanisms (Liu and Takukawa, 2010). Dedicated
optimization-driven components perform the fourth
function.
What is interesting about the focus on these
functions is that most of the practitioners interest
and also the ICT academic research emphasize only
the operational decisions “inside” the transshipment
facility. What is happening “outside” is taken as
given fact, and makes the rather strong assumption
that the supply chain operation and the
transportation schedules are already in synch. What
it makes it work in practice is that the external
structure of the overall transportation network in
such a scenario is rather simple and the flow is
viewed as single-directional through the cross dock
facility.
2.2 Observed EIS Functionality for
Hub-and-Spoke Consolidation
This scenario refers to moving a LTL shipment to a
location named hub from a location named spoke -
by an inbound hauler that plays a local logistic
operations role in the spoke’s area. The shipment
order is made by a supplier who also pays upfront
this hauler for the whole delivery to the target
consumer. When the shipment is staged at the hub,
or in some cases in advance, the hub operator hires
immediately another hauler (operating in the area of
the target consumer) to take the staged shipment
from the hub and deliver it. When this outbound
hauler has enough load at the hub or in hub’s
neighboring area to consolidate its truck trip, it sends
a truck (typically loaded with shipments intended for
the same hub or close to it) to bring the full LT in its
area and finally delivers these shipments. Typically,
the haulers that bring inbound shipments seek to
take a full load back, from the hub or its
surroundings, in order to keep load factors high.
The main feature of this scenario is its
heterogeneity. The hub, in most cases focuses only
on its own internal operation and rarely operates its
own truck fleet. For the transportation from/to the
hub it relies mostly on local haulers, and it may have
different type of contracts with them – long, short-
term, or ad-hoc, depending on their size and the
variability of the flow they enact through the hub.
The way the haulers operate on their side can be also
very different. Some use their own smaller hub,
transshipping from/to smaller trucks that do the local
milk-runs to/from bigger trucks that do the spoke-
hub route, and some do directly the milk-runs. From
a dynamic information flow point of view, the
haulers need to know what is present (or will be in
the near future) at the hub, which makes their own
TL consolidation, truck scheduling, and truck
routing tasks easier. This information function
requested by the hub is called manifestation. It is
possible to pre-manifest loads that are to arrive at the
hub in the near future, and in some cases, haulers
who have long term contracts with the hub do that,
via an ICT infrastructure that is deployed or adapted
for this purpose. However, our multiple case study
reveals that albeit considered useful by various
stakeholders, many found that the cost of this
infrastructure does not justify the investment.
We have also observed that the logistic operators
(hub owner, local haulers) implementing this
scenario serve a completely different market than the
ones in scenario 1, where the supply networks are
typically required to support the JIT manufacturing
ICEIS2013-15thInternationalConferenceonEnterpriseInformationSystems
390

or distribution of a large organization in a supply
chain. For scenario 2 networks, the size and industry
sector of their clients providing and receiving the
freight can be very diverse. Most of the customers of
a scenario 2 network are small and medium-sized
companies. The relatively fast (only a few days) by-
road transfer through a country-, or continental
region-size network allows these pairs of supplier-
consumer to achieve an “almost JIT-like”
performance of operating their supply chains.
On the other hand, it is still difficult to give to
these end-customers a reliable prediction of the
throughput time of a shipment – and hence, a precise
(JIT-like) delivery time. This is due mostly to the
heterogeneity and the operational loose coupling of
the logistic companies involved. Their transport
decisions are made autonomously and at different
moments, and these are always dependent on other
factors, like the variability of demand and supply of
other end customers – which are not using the hub
and spoke network. The dynamic decision of the hub
to which outbound hauler to hire for a shipment, its
availability, and its response also contribute to this
overall lack of predictability. Moreover, the daily
schedules and truck load distributions made by any
pair of haulers are never coordinated to take into
account the eventual dependencies between the
inbound and outbound shipments they may share.
In an operating mode that allows that these
inbound/outbound dependencies do not interfere
with overall performance, which can be easily
achieved when the whole daily flow is transshipped
in one shift, the customers can be sure that that the
throughput time is the predicted one (with the
reserve that the inbound and outbound haulers have
no technical problems). This time equals to the sum
of the time from picking to staging at the hub, plus
the staging and transshipment time, plus the hub to
delivery time. Such an operating mode assumes that
all trucks in a shift arrive before a “unload spike”
moment, and all the flow volume of this shift is
staged at the hub. Only after the loading of the
outbound trucks – which all arrive in time at the hub
yard – starts with a FCFS strategy for example.
There will be a “load spike” moment, but there is
enough slack in the transport and delivery schedules
of the outbound haulers to deliver each pallet load in
time.
The focus is on four main EIS functions that are
necessary for the whole network operating under this
scenario are:
a. Support the manifest of existent and incoming
flow at/to the hub
b. Hub to hauler relations management
c. Hauler to end-customer relations management
d. Truck schedule, routing, and truck load
optimization (locally executed by haulers)
Compared with the four main functions identified
for scenario 1, these four function emphasize the
focus on the “outside” of the transshipment facility.
The first function is performed through a mix of
identification, tracking, and web-portal technology
that links the hub to the rest of the operators – only
this function has a real-time input that comes from
“inside” the hub, albeit it depends on what the
“outside” manifests as load. The second function is
achieved through classic CRM, and it covers the
long-term management of the different types of
contracts and agreements between the hub operator
and the spoke area operators. The components that
perform these two functions are typically owned by
the hub operator. The third function is performed
rather independently from the first two by a
heterogeneous mix of components owned by the
haulers. The same heterogeneity and distribution is
observable in the physical realization – or even the
lack – of the fourth function.
2.3 A Close to Capacity Operating
Mode of Hub
and Spoke Consolidation
The temporal dependencies between inbound
arrivals and outbound departures become critical in
two situations, which can appear together. First, the
“unload spike” and the “load spike”, due to a lack of
enough slack in the transportation schedules – or
other factors – can become too close to each other,
and the effect is that the hub has less and less time to
process the whole daily trans-shipment volume
during a single shift. Second, the departure from a
continuous hub flow operation towards a daily shift
style may cause that the volume that accumulates at
the height of the operational cycle is actually close
or even higher than the physical capacity of the hub.
This cycle height is positioned during “unload
spike” and the “load spike”. When these situations
occur – and some of cases studied by us show that
they happen more and more often – the hub starts to
operate in an “extreme” mode that resembles the
cross docking operation mode.
Indeed, hub and spoke operators who have been
interviewed stated themselves that they do “cross
docking” (Buijs et. al, 2012). However, in all of
these cases, our independently made observation
was that the fundamental feature of cross docking
(i) is actually missing. Even if, for all means and
purposes, a hub is not an inventory point any more,
DiscoveringtheEISArchitecturethatSupportsHub-and-SpokeFreightTransportationNetworksOperatinginaCross
DockMode
391

and the information flow may precede the physical
flow, that does not mean that the hub can be
considered a cross-dock. The main EIS related
reason for this inference was that we have found no
functionality that was intended for the coordination
of operations or the optimization at the level of the
whole network – therefore a lack of the fundamental
feature (i) presented in section 2.
The main position of this paper is that when the
flow at the hub transshipment facility approaches
near maximum capacity and/or the temporal
dependencies prevent the fast (cross dock style)
outbound move of the shipments, the main issue is
the lack of those EIS functions that allow for
coordination at the level of the whole network.
An EIS that would support to achieve the cross
docking fundamental feature (i) in a hub-and-spoke
network, would create in fact a JIT-enabling
network. There is a potential market today for “real”
JIT shipments between those SMEs which
intensively use road freight hub-and-spoke 3PL
operators for country and continental region wide
supply chain operations (Kemény et. al, 2011). The
perceived advantages of this operating mode for
hubs are the following:
I. Throughput times for pallet-based shipment
from supplier to consumer can be reliably predicted,
hauler delivery promises kept, and JIT levels in the
supply chains can be achieved for a large number of
SMEs.
II. Prices for fast and reliable shipments can be
reduced to the level of normal hub-and-spoke
delivery – down from courier shipment price levels,
and can be afforded all the time, by everybody, not
only by a small “elite” or only in exceptional rare
circumstances.
III. 3PL operators which will make the transition
to this mass-scale JIT-enabling will become
transportation network orchestrators and by doing
this they open themselves to a lucrative business
model and a new channel of revenue.
3 DISCUSSION
An observation made during the multiple-case study
is that the realization of this interesting operating
mode is effective only for a certain type of hub and
spoke operations. For example, almost any 3PL
operator who wants to extend its current
logistic/warehouse processes with hauler network-
based hub and spoke JIT consolidation flow, using
its existing dock door procedures, will encounter
serious difficulties. Here we enumerate some of the
often occurring features that would make the
adoption of this mode practically impossible:
1. if the level of constraint interdependencies
between the inbound and outbound flows is
high and also difficult to predict.
2. if the variability of the timing of the “spike” of
operations’ tempo at the hub moments is high.
3. if the trucks are loaded or unloaded only
through their backdoor, and the local
constraints of ordering the pallets in the
outbound trucks are strong.
4. if there is limited staging capacity and there are
constraints on the internal trans-shipment
resources (like forklifts).
5. if one of the main functions identified for the
scenario 1 EIS are not present.
All these restricting features, and most importantly
the lack of any EIS-level coupling between the
“inside the facility” and the “outside of it”, will
make extremely difficult the attempt to achieve the
synchronized (cross dock style) flow of pallets
through these trans-shipment facilities.
3.1 What EIS Functionality is needed
to enable the Cross Docking Mode
The first and most striking ICT infrastructure related
observation made at the hub operators that
encountered the close-to-capacity mode was the lack
of interfaces between the various components of the
network wide EIS – i.e. the loosely-coupled one
covering the entire hub-and-spoke network. The
second interesting observation, made repeatedly at
different hub operators during the multiple-case
study, is that planners from different operators
continuously and pro-actively collaborate in order to
facilitate the smooth trans-shipment of particular
orders. However, due to the lack of dedicated
interfaces, there was no effective support for this
collaboration from the EIS, and as a result, the
handling of the situation was human-work intensive,
and the communication was exclusively done via
POTL (plain old telephone line). Furthermore, the
interaction was decidedly un-structured, albeit some
patterns emerged when thoroughly investigated.
Based on this observation, our first intuition is to
have an EIS function that provides visibility between
various planning and scheduling components of the
network wide EIS. In physical terms, this can be
achieved by enacting intelligent interfaces between
EIS components. These should be able to detect,
filter and report changes in the schedules of others,
and also be able to estimate the negative effects and
eventual opportunities caused by these changes.
ICEIS2013-15thInternationalConferenceonEnterpriseInformationSystems
392

These interfaces should be designed in a way that
triggers the planners in different organizations to act,
interact, and decide for more efficient courses of
action when necessary. Nevertheless, there are many
difficult issues related to visibility, for example
confidentiality – haulers may compete against each
other in the same spoke zone – and all these have to
be carefully analyzed before deploying such a
function. Some current tracking components offer
alarm and triggering features, but some operators
used these parsimoniously, because it is very
difficult to set the constraints in the system, and the
excessive triggering may become more a hindrance
than help for the planner (Meyer et al., 2012).
The second observation is that typical operation
related tasks as load building, schedule computing
and various resource allocations, are all made and
optimized in a hub and spoke network only from a
local (“greedy”) perspective (Shakeri et al., 2012).
This may lead to degraded network-wide
performance indicators, and in the long term
potential loses for all involved. The collaborative
alignment of the plans and schedules, made with the
purpose to achieve a win-win network wide
outcome, would be possible only if the interfaces
performing the “provide visibility” function are in
place. However, these interfaces alone would not be
sufficient to achieve schedule alignment.
Our second intuition is to have a function to
align intentions between the various components
that support planning and scheduling. The
experience gained and the technology used in
aligning supply chain partners can be of use here.
For example, various auction based mechanisms and
agent based systems (Fischer et. al, 1996),
automated negotiation (Davidsson et al., 2011), and
the technology of intelligent products (Meyer et. al
2009) can be applied for the implementation of the
necessary components to perform this function. Of
course, we are aware that the realization of such a
function is not trivial (a list of these difficulties is
presented in Mes et al., 2011), and we also know
that the main issue revolves always around the
establishment of an incentive mechanism that brings
partners into collaborating for win-win situations.
We believe that the discovery and testing of models
for these incentive mechanisms will be one of the
most difficult parts of the research. Also, each hub
and spoke network may have different requirements
and attitudes that makes the model unique for the
network, and the generalization of these models may
prove to be very difficult.
Beside these two strong intuitions above, other
potential intuitions we have for the EIS functionality
are: first, to provide network wide optimization (to
enable look-ahead and potential performance
evaluation); second, provide pro-active, network
wide, real-time, operational monitoring and control.
Related to this last function, our research group has
already experimented with components performing
this function, in one of the cases of the case study
research (Meyer et al., 2012). Another interesting
idea is to continuously gather network wide
historical data and provide analytics (based for
example on data mining and learning), to allow
planners and decision makers to observe change
over longer intervals of time and maybe discover in
this way emerging and useful patterns of interaction
that can be developed further to improve the
alignment function.
Nevertheless, at this stage, we can say that these
are only our educated intuitions for functionality.
Only applied and active research can establish with
certainty which functions are effective in enabling
and improving hubs that will operate in the cross
docking mode.
3.2 How to Identify, Test, and Validate
the Functionality of a Hub
and Spoke Supporting EIS
Both the market essentials and the technology in this
field of research have been evolving and changing
fast. To discover the currently needed functions and
evaluate their effectiveness quickly, the research
must involve from the start a certain number of
cooperating practitioners from the operators.
Because it is extremely difficult and disruptive for
the operators to run pilots embedding experimental
prototypes – as we have observed during our active
research attempts – another approach for this
cooperative research is necessary. Our proposal is to
develop, in conjunction with software vendors, an
evolving series of simple and easy to implement
platforms that allow the demonstration, simulation,
and serious gaming of shift operations at various
hubs and cross docks.
The functional design of such a platform should
be based on requirements elicited from the
practitioners. The intuitions illustrated in the
previous section can be used as a starting point in
the interaction with the practitioners. The functional
design should be always completed with a
benchmarking function (McKinnon, 2009) that is
supposed to play the role of the real environment of
the network. The platform design should be the base
of an implementation allowing simulations that have
the purpose of testing the appropriateness and
DiscoveringtheEISArchitecturethatSupportsHub-and-SpokeFreightTransportationNetworksOperatinginaCross
DockMode
393

effectiveness of the functions. The final validation of
the functional architecture of a potential network
wide EIS could be in form of an interactive
simulation or even a serious game, where
practitioners play their real roles in the
organizations. For example, real planners playing
this game can interact when supported by the new
functionality. Managers can assess if the process that
is simulated and/or gamed via the platform
resembles what they know from reality, and the
improvements are the expected ones.
A platform that allows for realistic simulation
and gaming and also encompasses functionality for
collaborative alignment may be complex and
difficult to develop. There are also caveats related to
the participation of the practitioners – their time to
attend games is severely limited, as we have seen in
our multi-case study. On the other hand, we also
discovered that they are very keen and interested in
such kind of platforms – we know that because we
have tentatively experimented with early prototypes.
The software vendors are in principle interested
because they will enjoy the advantage of having a
validated functional architecture early, enabling
them to develop quickly components for the various
logistic operators. Moreover, demo platforms,
allowing for also simulation and gaming, can be
used for promotion and marketing purposes by the
vendors.
4 CONCLUSIONS
Many academic research efforts in road freight
transport are today directed towards the “grand”
themes, like for example the effectiveness and pay-
offs of tracking infrastructures, or EIS architectures
for multi-modal transport (Marcucci and Puckett,
2012). However, many “quiet” evolutionary changes
are constantly occurring in this field, and researchers
who are performing in-depth case longitudinal case
studies are those who are the first to be aware of
these.
Being part of one of these particular groups of
researchers, we take the position that in the
transshipment area, many hub facilities and the
transportation and supply networks surrounding
them are confronted more and more (due to
competition, various market factors, and changes in
the supply chain management paradigms of many
SMEs) with the situation that they work in an almost
cross docking operating mode. Our main conclusion
after the analysis of the empirical information
collected during a multiple case-study is that a new
direction and method for research is needed in this
area, one that will reveal the needed functionality for
this mode in the EIS of the participating logistic
operators.
Our main intuition is that a function enabling a
highly collaborative intention alignment between the
operators is necessary. In order to achieve results
fast, our proposal is to develop (maybe with the help
of software vendors) relatively simple and easy to
implement platforms that allow demonstration,
simulation, and serious gaming of operations at hubs
and cross docks. These are to be used in cooperative
research with practitioners involved in case studies,
with the aim to discover the appropriate functions,
modes, necessary data, components, interfaces, and
the potential combinations of new technologies that
will allow hub and spoke systems to operate in the
highly efficient operating mode that encompasses
the cross docking fundamental features.
ACKNOWLEDGEMENTS
This research is supported by the European
Commission through the 7th FP project ADVANCE
(http://www.advance-logistics.eu) under the grant
number 257398.
REFERENCES
Boysen, N., and M. Fliedner. 2010. Cross dock
scheduling: Classification, literature review and
research agenda. Omega 38:413-422.
Buijs, P., N. Szirbik, G. Meyer, and J. Wortmann. 2012.
Situation Awareness for Improved Operational
Control in Cross Docks: An Illustrative Case Study. In
Proceedings of the 14th IFAC Symposium on
Information Control Problems in Manufacturing.
Edited by I. Dumitrache, F. Filip, and T. Borangiu.
Volume 14, Part 1 (Elsevier - digi. ref.
DOI:10.3182/20120523-3-RO-2023.00080)
Davidsson, P., J. Holmgren, J.A. Persson, and A.
Jacobsson. 2011. Plug and play transport chain
management: Agent-based support to the planning and
execution of transports. In e-Business and
telecommunications, Communications in computer
and information science 130:139–155, ed. M.S.
Obaidat and J. Filipe,. Berlin/Heidelberg/New York:
Springer.
Erera, A., M. Hewitt, M. Savelsbergh, and Y. Zhang.
2013. Creating schedules and computing operating
costs for LTL load plans. Computers and OR
40(3):691-702.
Fischer, K., J. Müller, and M. Pischel. 1996. Cooperative
transportation scheduling: an application domain for
ICEIS2013-15thInternationalConferenceonEnterpriseInformationSystems
394

DAI. Journal of Applied Artificial Intelligence, 10:1–
33.
Kemény, Z., E. Ilie-Zudor, J. Fülöp, A. Ekárt, C.
Buckingham and P. Welch. 2011. Multiple-participant
hub-and-spoke logistics networks: Challenges,
solutions and limits. In Proceedings of the 13th
International Conference on Modern Information
Technology in the Innovation Processes of Industrial
Enterprises.
Larbi, R., G. Alpan, P. Baptiste, and B. Penz. 2011.
Scheduling cross docking operations under full, partial
and no information on inbound arrivals. Computers &
Operations Research 38(6):889-900.
Liao, T., P. Egbelu and P. Chang. 2013. Simultaneous
dock assignment and sequencing of inbound trucks
under a fixed outbound truck schedule in multi-door
cross docking operations. Intl. Journal of Production
Economics 141(1):212-229.
Liu, Y. & Takakuwa, S. 2010. Enhancing simulation as a
decision-making support tool for a crossdocking center
in a dynamic retail-distribution environment. In
Proceedings of the 2010 Winter Simulation
Conference. Edited by B. Johansson, S. Jain, J.
Montoya-Torres, J. Hugan, and E. Yücesan, 2089-
2100.
Luo G., and J. Noble. 2012. An integrated model for
crossdock operations including staging. Intl. Journal
of Production Research 50(9):2451-2464.
Marcucci, E., S. Puckett (guest editors). 2012. Freight
transport analysis: new trends and methodologies
(special issue). European Transport 50.
McKinnon, A.C. 2009. Benchmarking Road Freight
Transport. Benchmarking: An international journal
16:640-656.
Mes, M., M. Heijden, and P. Schuur. 2011. Interaction
between intelligent agent strategies for real-time
transportation planning. Central European Journal of
Operations Research, found via:
http://dx.doi.org/10.1007/s10100-011-0230-7.
Meyer, G., K. Främling, and J. Holmström. 2009.
Intelligent products: A survey. Computers in Industry
60:137-148.
Meyer G., P. Buijs, N. Szirbik, and J. Wortmann. 2012.
Intelligent products for enhancing the utilization of
tracking technology in transportation. Accepted for
publication, to appear in Intl. Journal of Operations
and Production Management.
Napolitano, M. 2000. Making the Move to Cross Docking
– A practical guide to planning, designing, and
implementing a cross dock operation. Warehousing
Education and Research Council (WERC).
Shakeri, M., M. Low, S. Turner, and E. Lee. 2012. A
robust two-phase heuristic algorithm for the truck
scheduling problem in a resource-constrained cross
dock. Computers and OR 39(11):2564-2577.
Van Belle, J., P. Valckenaers, and D. Cattrysse. 2012.
Cross-docking: state of the art. Omega 40:827–846.
Vogt, J. J. 2010. The successful cross-dock based supply
chain. Journal of Business Logistics 31:99-119.
DiscoveringtheEISArchitecturethatSupportsHub-and-SpokeFreightTransportationNetworksOperatinginaCross
DockMode
395