![](bg6.png)
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
DiscoveringtheEISArchitecturethatSupportsHub-and-SpokeFreightTransportationNetworksOperatinginaCross
DockMode
393