Designing centralization in the Physical Internet, from an operational perspective

University of Groningen

MSc Technology & Operations Management

Designing centralization in the Physical Internet,

from an operational perspective

Master Thesis

January 27, 2020

Heleen Wissink Student number 2761483 h.g.h.wissink@student.rug.nl

Supervisor / University of Groningen dr. N.B. Szirbik

Abstract

The Physical Internet is expected to be a solution to the unsustainable issues the global transport and logistics is currently facing. The Physical Internet is envisaged as a decen-tralized system. It is questioned in theory whether centralization should be incorporated in the Physical Internet in order to achieve global efficiency. Therefore, this research pro-poses centralization in the Physical Internet from an operational perspective. By means of Design Science Research, centralization in the Physical Internet is designed to take advan-tages of both, centralized and decentralized control. A theoretical and practical analysis are performed to identify the critical requirements. A new stakeholder, the central planning fa-cilitator, is introduced in order to achieve bottom-up centralization in the Physical Internet. Thereafter, the operational, tactical and strategic activities of the central planning facilitator are designed. Critical aspects of this design are information sharing, standardization and contracts. The outcomes are validated by means of a validation workshop.

Contents

1 Introduction 8

2 Theoretical Analysis 12

2.1 Centralization and decentralization . . . 12

2.2 Physical Internet . . . 15

2.3 Decentralization and centralization in the Physical Internet . . . 20

3 Methodology 23 3.1 Research design . . . 23 3.2 Theoretical analysis . . . 24 3.3 Practical analysis . . . 25 3.4 System design . . . 27 3.5 Design validation . . . 27 4 Practical Analysis 29 4.1 General requirements . . . 30 4.2 Operational activities . . . 32 4.3 Tactical activities . . . 36 4.4 Strategic activities . . . 36 5 System Design 41 5.1 Evaluation of critical requirements . . . 41

5.2 A new stakeholder: Central Planning Facilitator . . . 42

5.3 Operational scenarios and design . . . 44

5.4 Tactical scenario and design . . . 56

5.5 Strategic scenarios . . . 58

5.6 Evaluation of scenarios . . . 60

5.7 Critical aspects . . . 61

6 Design Validation 63 6.1 Validation of design . . . 63

6.2 Validation of critical aspects . . . 64

6.3 Role of a forwarder in the Physical Internet . . . 66

7 Discussion 67 7.1 Contribution to theory . . . 67

7.2 Contribution to practice . . . 70

7.3 Operational perspective versus strategic-business perspective . . . 71

7.4 Limitations and further research . . . 72

References 78

Appendices 79

A Interview Protocols 79

A.1 Interview protocol - Experts in the Physical Internet . . . 80

A.2 Interview protocol - Stakeholders in the current logistics system . . . 86

A.3 Interview protocol - (De)centralized planning company . . . 94

A.4 Presentation about the Physical Internet . . . 99

B Coding Tree 101 C System Design Scenarios 109 C.1 Generic process in the Physical Internet . . . 109

C.2 Operational scenarios . . . 110

C.3 Tactical scenario . . . 115

D Examples of System Design Scenarios 117 D.1 Examples operational scenarios . . . 117

D.2 Example tactical scenarios . . . 119

E Validation Workshop 120 E.1 Validation workshop protocol . . . 121

List of Figures

1 Research design . . . 24

2 Hierarchical organization of activities of central planning facilitator . . . 43

3 Design: Simplified generic process in the Physical Internet . . . 45

4 Design operational scenario: Making decisions . . . 46

5 Design operational scenario: Operational advising . . . 52

6 Design operational scenario: Matching capacity . . . 54

7 Design tactical scenario: Tactical advising . . . 57

8 Design tactical scenario: Tactical advising redesigned . . . 65

List of Tables

2 Overview of interviews . . . 26

3 Summary of coding tree - General requirements . . . 29

4 Summary of coding tree - Activities of coordinator . . . 29

5 Critical requirements abstracted from practice . . . 40

6 Coding tree - General requirements . . . 103

Glossary

Centralization is when the (informational advice for) decision making over transport routes of two or more shipments is transferred to the same coordinator and the coordinator advises or decides on the routes for all these shipments in a simultaneous fashion based on the optimization of system-wide goals.

Central Planning Facilitator

The central planning facilitator is the coordinator in the Physical Internet that achieves central-ization by performing operational, tactical and strategic activities. The mission of the central planning facilitator is to enable efficient movement of shipments.

Critical aspects

Critical aspects are the essential aspects to enable centralization in the Physical Internet in order to establish an operational system.

Critical requirements

Critical requirements are the essential requirements that need to be considered for the design of centralization in the Physical Internet in order to establish an operational system.

Decentralization

Decentralization is when the decision making over a transport route of one shipment is performed by a self-coordinating element that decides based on the optimization of its own goals.

Operational perspective

The operational perspective is concerned with the operations undertaken by a coordinator in the Physical Internet to achieve centralization. The operational perspective focuses on the planning and coordinating activities in order to move a shipment from a sender to a receiver.

Physical Internet

1

Introduction

The ever-growing transport and logistics activities throughout the world contribute to global eco-nomic, environmental and social sustainability issues (Lambrechts et al., 2019; Statista, 2019). Sustainability issues that arise due to operational inefficiencies, like poor space utilization of transport means and inefficient transport routes are, for example, increased pollution and de-creasing reliability of transport (Ambra et al., 2019; El-Berishy et al., 2013; Montreuil, 2011). To address the global unsustainability, Montreuil (2011) introduced the Physical Internet (PI or π). The Physical Internet is defined as an open global system for transport and logistics that aims to improve the efficiency and sustainability of the way physical objects are moved, stored, realized, supplied and used (Montreuil, 2011). The Physical Internet is envisaged as a decen-tralized system, which implies that decisions in the system are autonomously and locally made (Sternberg and Andersson, 2014). However, it is questioned whether centralization should be incorporated in the Physical Internet, in order to achieve global efficiency (Ambra et al., 2019). Therefore, this research focuses on the decentralization of the Physical Internet and proposes an alternative design for centralization in the Physical Internet from an operational perspective. The Physical Internet is envisaged as a decentralized open global logistics system in which smart, modular and standardized containers filled with physical objects are moved from the sender to the receiver through multiple nodes (e.g. ports and hubs) belonging to interconnected logistics networks (Meyer et al., 2019; Montreuil et al., 2015). The Physical Internet is based on the interconnection of logistics networks by standardized protocols and smart interfaces. This enables containers, that are controlled by IT, to decide on their own route through the open network and achieve increased efficiency and sustainability (Montreuil et al., 2012). Hence, the Physical Internet is defined as a future solution to the inefficient and unsustainable current logistics system (Sternberg and Norrman, 2017) and is expected to be implemented in the year 2050 (ALICE, 2019).

The introduction of the Physical Internet opened many new research directions, as each charac-teristic of the Physical Internet needs to be further researched and developed before implemen-tation (Montreuil, 2011). After the introduction, the vision of the Physical Internet has been defined by conceptualizing the open network structures and the corresponding elements (Mon-treuil et al., 2012). Thereafter, research focused on the definition and design of single elements of the Physical Internet, for example optimization of container routes or designing Physical In-ternet containers (Sternberg and Norrman, 2017). Literature about the Physical InIn-ternet is not mature (Treiblmaier et al., 2016), but the increase in Physical Internet research indicates the relevance of this concept.

flexibility, which implies that a system can respond to circumstances quickly and easily (Quak et al., 2018). This results in fast decision making and avoidance of local disturbances (Pan et al., 2016). However, decisions over transport routes can also be made in conjunction, which ensures centralization. Centralization in this research is defined as when the (informational advise for) decision making over transport routes of two or more shipments is transferred to the same coordinator and the coordinator advises or decides on the routes for all these shipments in a simultaneous fashion based on the optimization of system-wide goals. Centralization achieves the possibility to balance interests of stakeholders (Lafkihi et al., 2019). This results in global efficiency and sustainability. The focus of this research is on centralization in the Physical Internet.

Since the introduction of the Physical Internet, research is shifting more towards decentral-ized decision-making and is focused on enabling decentralization within the Physical Internet (Ambra et al., 2019). However, most of the research assumes that the Physical Internet in-cludes a common coordinating party that connects stakeholders (Meyer et al., 2019). Since the Physical Internet is envisaged as an open logistics system, actors in the Physical Internet are assumed to act upon that, for example by sharing information. To manage overall efficiency by using the information for optimization, most of the research relies on a coordinator (Meyer et al., 2019). The assumption of the presence of a coordinator in the Physical Internet and the possible advantages in terms of efficiency and sustainability of having a coordinator, makes the envisaged decentralized Physical Internet subject of discussion. For example, Ambra et al. (2019) questioned whether the Physical Internet should have centralization. However, this is still left unanswered and limited theory exists outlining centralization in the Physical Internet. This is where this research fits in, as it is investigated and designed how centralization can be implemented in the Physical Internet.

“What does the design of centralization in the Physical Internet look like and what are the critical aspects of this system, from an operational perspective?”

To be able to answer this research question the following sub-questions are addressed:

• Which opportunities for improvement exist within the current envision of the Physical Internet, with regard to centralization?

• Who are the stakeholders involved in the Physical Internet and what are their objectives? • What are the critical requirements for centralization in a decentralized system, according

to theory?

• What are the critical requirements for centralization in a decentralized system, according to practice?

• What does the design of centralization in the Physical Internet look like? • What are the critical aspects that can abstracted from the design?

• To what extent can the design outcomes and critical aspects be validated?

In theory centralization in the Physical Internet is limited studied before. Meyer et al. (2019) recognized the need for more control in the Physical Internet and provide a decentralized solution by using blockchain. Further, Sallez et al. (2015) and Vo et al. (2018) developed a combination of a decentralized system and a centralized system specifically for Physical Internet hubs. Although, incorporating centralization in the Physical Internet system is lacking in theory, while Cimon (2014) discusses the relevance of designing control in the Physical Internet. Therefore, this research suggests to design the centralization function in the Physical Internet by introducing a coordinator, named as the central planning facilitator. The central planning facilitator is the coordinator in the Physical Internet that achieves centralization by performing operational, tactical and strategic activities. The mission of the central planning facilitator is to enable efficient movement of shipments. Theoretically, this research contributes to Physical Internet theory by introducing centralization in the Physical Internet. This research is a first small step towards centralization in the Physical Internet by developing a high level design from an operational perspective. Practically, this research contributes by informing stakeholders in the current logistics system about the Physical Internet and may help developing initiatives in current logistics.

In parallel to this research, Jong de (2020) investigated centralization in the Physical Internet from a strategic-business perspective. In Section 7.3, the strategic-business perspective is ex-plained and it is discussed how the outcomes of the strategic-business perspective relate to the outcomes of the operational perspective of this research.

2

Theoretical Analysis

In this section, a theoretical analysis of the problem and opportunity under study is provided, which serves as a basis for designing centralization in the Physical Internet. In Section 2.1, centralization and decentralization in logistics is discussed in order to understand the general debate and to identify in Section 2.3 how this debate appears within the Physical Internet. In addition, centralization in a decentralized system is discussed in order to identify critical requirements of such a system. These critical requirements are used for designing centralization in the Physical Internet in Section 5. In Section 2.2, the Physical Internet concept is explained, its key elements and key pillars are described, and the key stakeholders with their objectives are identified. This section is helpful to understand the basics of the Physical Internet, as this research focuses on the key pillar decentralization of the Physical Internet and related to that, centralization in the Physical Internet is designed in Section 5. In Section 2.3, the state-of-the-art of centralization and decentralization in Physical Internet theory is discussed in order to point out the gap in theory and to emphasize the relevance of the research direction that is taken.

2.1 Centralization and decentralization

A logistics system can be controlled as a centralized system, as a decentralized system or as a combination of both (Quak et al., 2018; Trentesaux, 2009). From a global perspective, a fully centralized logistics system is a system where decision making over all transport routes is per-formed centrally by one coordinator (Pirttila and Niemi, 1996). In contrast, a fully decentralized logistics system is a system where decision making over each single transport route is performed decentrally by a single self-coordinating element (Cantamessa, 1997). A fully centralized sys-tem and a fully decentralized syssys-tem are both extremes. Although, in practice there can be a lot in between a fully centralized system and a fully decentralized system, which means that a combination of both is possible (Cummings, 1995). Like in this research the definition of cen-tralization is between the extremes, since in this definition a coordinator advises or decides on transport routes of two or more shipments in a simultaneous fashion. In the spectrum between the extremes, this definition is close to the extreme of a fully decentralized system.

To decide the optimal point between the extremes of a fully centralized system and a fully decentralized system for a system the (dis)advantages of both extremes should be considered (Kujula, 2015). In case of a centralized system, a coordinator is involved and creates and optimizes transport routes (Lafkihi et al., 2019). An important advantage of a centralized system is that it vastly outperforms a decentralized system in terms of global efficiency (Lafkihi et al., 2019). Although a centralized system requires more shared or hierarchically collected information, in specific contexts centralized control and planning is relatively more efficient and more sustainable (Sternberg and Andersson, 2014). In case of decentralized system, a self-coordinating element has the ability to take instant decisions independently (Sallez et al., 2015), which enables the decentralized system to make faster decisions than in a centralized system - where guidance or at least approval from a coordinator is necessary (Pan et al., 2016). Furthermore, a decentralized system is robust and prevents the spreading of the effects of local disturbances (Quak et al., 2018). One clear disadvantage of a decentralized system is that self-coordination is myopic and it may result in unexpected and undesirable results from a global perspective, even if the local decisions all seemingly rational (Quak et al., 2019). In case of a system that is a combination of a centralized system and a decentralized system the aim is to gain advantages from both. The centralized part is responsible for achieving predictivity and global optimization, while the decentralized part is responsible for achieving reactivity and local optimization (Trentesaux, 2009).

Centralization in a decentralized system

In other industries centralization in decentralized systems is proposed. These systems are stud-ied below, because these are considered to be relevant in this research. As in this research centralization in the Physical Internet, which is a decentralized system, is studied. Critical re-quirements for such systems are identified and may also be relevant for designing centralization in the Physical Internet. Therefore the identified critical requirements are included in Table 1 at the end of Section 2.

many aircrafts) centralization is used in the decentralized system. This implies that in quiet areas a fully decentralized system is operational, while in busy areas a decentralized system with centralization is operational (Tomlin et al., 1996). The need for centralization is acknowledged by Hoekstra et al. (2002), who mentioned that in bottleneck scenarios centralization is required. This centralization is achieved by using different coordinators (Tomlin et al., 1996). The critical requirements that can be abstracted from this decentralized system with centralization are the need for centralization in high density areas or bottleneck scenarios and the possibility to achieve centralization by using different coordinators.

In the Free Flight concept centralization is achieved by using coordinators, which is also sug-gested in the definition of centralization in this research. Since this research takes an operational perspective on centralization in the Physical Internet, it is interesting to identify the critical re-quirements for a coordinator to be operational. These critical rere-quirements can serve as a basis for the practical analysis in Section 4 and to design centralization in the Physical Internet in Section 5. According to theory, mainly about the Free Flight concept, a coordinator should meet critical requirements within at least four topics in order to be operational. These topics are the following: the nature of the coordinator, the operational range of the coordinator, the characteristics of the coordinator and the activities of the coordinator. These four topics are discussed below.

The nature of the coordinator in the Free Flight concept is a fully automated IT system that is managed by the control center, which possess an important link in the network, in the high density area (i.e. take off and landing area) (Tomlin et al., 1996). Since multiple perspectives should be incorporated in high density areas, a bottom-up approach is appropriate (Cumming, 2002). With bottom-up centralization, aircrafts and the coordinator interact in such a way that the local processes of the involved aircrafts become coordinated (Cumming, 2002; Tomlin et al., 1996). By bottom-up centralization the aircrafts are not too much relying on the decisions of one coordinator (Breil et al., 2017). The critical requirements that can be abstracted are that a coordinator should be a IT system that is managed by a stakeholder who is an important link in the network and that centralization should be achieved by a bottom-up approach.

The operational range of the coordinator in the Free Flight concept is decided per region. As mentioned before, centralization is used in the decentralized system in high density areas, while a fully decentralized system is operational in low density areas. This implies that if an aircraft enters a high density area the coordinator is operational and if an aircraft is in a low density area the coordinator is not operational (Tomlin et al., 1996). Relating this to logistics a high density area may be around a hub, while a low density area may be a shipping lane. The critical requirements that can be abstracted are that the coordinator is operational in high density areas and is not operational in low density areas.

that the coordinator should have sufficient computational power. Furthermore, the coordinator should, despite centralization, be adaptive as in a decentralized system (Bicchi, 1999). The critical requirements that can be abstracted are that a coordinator should have sufficient com-putational power and be adaptive.

The activities that a coordinator in the Free Flight concept performs are information collection, directing stakeholders, information provision and decision making. Siˇsl´ak et al. (2007) describes centralization in the Free Flight concept by designing the activities performed by a coordinator. The coordinator is responsible for identifying conflicts and for searching and providing an optimal solution for the conflicts. An example of a conflict is when multiple aircrafts have a mutual future collision on their flight plan. The coordinator should find a collision free set of flight plans for the colliding group of aircrafts. Therefore, the coordinator directs which aircrafts are involved in the colliding group, collects and stores information about the group, requests to generate a deconfliction proposal and sends if possible information about a found non-colliding flight plan to the group. As a result that the colliding group behaves according to the solution. This process is running while the aircrafts are flying, which implies that time to find a solution is limited. The critical requirements that can be abstracted are that a coordinator should identify conflicts and in case of conflicts a coordinator should identify the involved stakeholders, collect and store information of the stakeholders and identify and provide a solution to stakeholders. The activities that a coordinator in the Free Flight concept performs can be divided into different levels. Tomlin et al. (1996) explain centralization in the Free Flight concept by describing the activities performed by different coordinators on different decision levels. The coordinators of the different levels interact with each other. According to Tomlin et al. (1996) coordinators are active on a operational, tactical and strategic level. This is in line with Piecyk et al. (2015), who divided planning and coordination activities based on time horizon in operational, tactical and strategic activities. Operational activities have a short term (i.e. day-to-day) focus, tactical activities have a medium term (i.e. monthly or quarterly) focus and strategic activities have a long term (i.e. years) focus (Piecyk et al., 2015). The critical requirements that can be abstracted are that a coordinator should perform activities on operational, tactical and strategic level and that these coordinators interact.

2.2 Physical Internet

The debate about decentralization and centralization is linked to the Physical Internet, which is the central concept of this research. Before discussing decentralization and centralization in the Physical Internet, the Physical Internet concept is first explained in this section.

The Physical Internet is inspired by the Digital Internet (Montreuil et al., 2010). Within the Digital Internet messages are split into different parts (i.e. ”packages”) that move over the internet via (potentially) various routes and are combined again at the side of the receiver. These packages are transmitted through an interconnected network of nodes (Ambra et al., 2019; Montreuil et al., 2015). This Digital Internet paradigm of standard packages travelling over a uniform network is adapted by the Physical Internet. Within the Physical Internet, physical standard-packaged objects are transported from the sender, the supplier, passing via various standard operating nodes to the receiver, the customers’ point of use (Meyer et al., 2019). The physical objects are to be moved in standardised containers and are to be routed through the interconnected network by the use of standardised handling procedures (Montreuil et al., 2015). Thus, in both Internets (Digital and Physical) one of the main ideas is that the sender and receiver are not concerned about how the message or the physical object is moved through the network to reach the receiver (Ambra et al., 2019). Moreover, the overall system has good performance in terms of quality of service, it is cost-efficient, waste-efficient, but also robust and resilient in the same time (Montreuil, 2011; Montreuil et al., 2012).

A formal definition of the Physical Internet was given by Montreuil et al. (2012) as: “An open global logistics system founded on the physical, digital and operational interconnectivity through encapsulation, interfaces and protocols”. This definition implicitly reveals four key pillars that form the basis of the Physical Internet.

The first term “an open global logistics system founded on the physical, digital and operational interconnectivity” is linked to the first key pillar: openness. It means that the system is open to access and use by any actor and that components of the system are interconnected (Montreuil et al., 2012). The second term “through encapsulation” is linked to the second key pillar: modularity. The Physical Internet deals with modular and standardized containers in which the physical objects are encapsulated (Montreuil et al., 2012). The last term “through interfaces and protocols” is linked to the third and fourth key pillar: autonomy and decentralization. Based on smart interfaces and standard protocols containers flow smoothly through the Physical Internet and enable containers to decide on their routing through the interconnected network (Montreuil et al., 2012). Transporters (routing) and hubs (network nodes) are also able to take autonomous decisions, without a need for central monitoring, control, decision making and overall planning (Montreuil et al., 2012). This insures that the system is highly robust (is less affected globally by local disturbances) and resilient (finds ways to adapt to these disturbances) (Montreuil et al., 2012).

Key pillars of the Physical Internet

Openness is defined by Montreuil et al. (2012) as “the accessibility, willingness and availability of actors and networks to deal with any actor or network”. As the boundary is unset, the Physical Internet is open to join and leave (Pan et al., 2016) and is thus not a private, closed, member-only system (Montreuil et al., 2012). This means that actors should be willing to participate and have to think and act in terms of openness. As in, the actors have to design, implement and exploit their Physical Internet components in an open way, so that other actors can easily access and use it. This implies that the use of Physical Internet components is not limited to the owners or leaseholders of these components (Montreuil et al., 2012). The typical actors that can join the Physical Internet are the senders and receivers (i.e. everybody on the globe can use the Physical Internet), but also transporters and hubs (i.e. any service provider or cross-docking facility that can align itself to the operational standards) (Pan et al., 2016). By openness, the Physical Internet becomes extendable and reducible to answer flexible logistics requirements (Pan et al., 2016).

Modularity is the possibility to interlock or combine multiple containers to create a single trans-portable unit. In the Physical Internet physical objects are to be encapsulated in modular, standardized, smart, and reusable containers (Montreuil et al., 2012). Ideally, each shipment equals one single modular container of the right size and right specifications. These single con-tainers are standardized in terms of dimensions, functions and fixtures (Montreuil et al., 2012), which creates the capability to interlock or combine into a single transportable unit. By mod-ularity, transferring and handling containers becomes more efficient and an infrastructure to handle containers around the world can be built (Landsch¨utzer et al., 2015; Pan et al., 2016; Yang et al., 2018).

Autonomy is the ability of containers to act independently and self-determined within the Physi-cal Internet (Janiesch et al., 2019). By equipping the containers with capabilities for independent decision making autonomy is created and the containers locally control their actions (Janiesch et al., 2019). Consequently, interfaces are important in establishing autonomy as they help achieving efficient universal interconnectivity (Montreuil et al., 2012). In addition, automation is important to enable containers to perform autonomously, without human support (Janiesch et al., 2019) and to enable self-driving transportation and fully robotic handling of containers at hubs (Montreuil et al., 2010,1). By autonomy, containers that are controlled by software can locally decide on the most efficient route that is enabled by automated transporters and hubs (Montreuil et al., 2015).

protocols enable a global coordinated network, without the need of collaborative agreements like bilateral or multilateral contracts (Montreuil et al., 2012). An analogous decentralized system is for example road traffic, which is bottom planned and generally-accepted rule-based. Everybody has the goal to go from A to B, which becomes a system-wide goal, and everybody has to a cer-tain extent access to information about traffic, allowing them to make routing decisions. In the same vein, by choosing for Physical Internet decentralization, the autonomous decision-making of containers in the Physical Internet is supported towards a system-wide common goal and information is available for individual decisions, enabling that unpredictable and undesirable individual outcomes are avoided (Krommenacker et al., 2016; Pan et al., 2016).

Key elements of the Physical Internet

The key pillars are fundamentally characterizing the Physical Internet and create the essential difference between the Physical Internet and the current logistics system. In addition to these key pillars, the Physical Internet is built on three key elements: containers, nodes and π-movers (Montreuil et al., 2010). Basically, these are quite similar to the elements in the current logistics systems. However, for the Physical Internet, these key elements are extended with new features (Montreuil et al., 2010). The three key elements are explained below in order to understand how the key pillars affect the key element and to understand the operational working of the Physical Internet, which is required to develop the Physical Internet system in Section 5. Π-containers are the units that are moved, handled and stored in the Physical Internet and encapsulate physical objects within them (Montreuil et al., 2012). A π-container consists of a physical part and an informational part (Montreuil et al., 2010; Sallez et al., 2016).

establish effective and efficient communication and decision-making an agent based model can be used, in which an agent represents a physical container in the digital world (Sallez et al., 2016). In the Physical Internet this works as follows. The Physical Internet can be split into a physical layer and a cloud layer. The physical π-container is active in the physical layer. This π-container is represented by an agent in the cloud layer. The agent in the cloud layer takes care of complex communication and decision making. The agent only sends simple instructions and final decisions to the π-container in the physical layer, which enables the π-container to move through the network (Moesker, 2018). According to the key pillars, decentralization is achieved by the agent based model and π-containers have autonomous reasoning capabilities in order to select the optimal route and handling within the Physical Internet (Montreuil et al., 2012). Π-nodes are ports, cross-docking hubs and distribution warehouses within the Physical Internet where operations on π-containers are performed, for example storing, sorting, (de)composing or assembling (Montreuil, 2011). Π-nodes exist in various types in terms of mission orientation, scope, scale, capabilities and capacities. Overall, nodes bring full automated handling of π-containers and should provide a fast, smooth and synchronized transfer of π-π-containers from the incoming π-movers to the outgoing π-movers (Tran-Dang and Kim, 2018; Walha et al., 2014). At π-nodes it is re-decided at π-nodes how π-containers can be most efficiently further transported (Montreuil, 2011). This implies that it is decided how the π-containers are combined and allocated to transporters to move the π-container through the network (Meyer et al., 2019). According to the key pillars, modularity enables fast handling of π-containers and openness allows π-containers to pass all π-nodes.

Π-movers convey, handle or transport the π-containers within and between the π-nodes and make sure that the containers move from the sender to the receiver. Π-movers exist in three types: π-transporters, π-conveyers and π-handlers (Montreuil et al., 2010). Within the Physical Internet the π-containers make use of multi-segment intermodal transport, which implies that multiple π-transporters can be used to move a π-container from the sender to the receiver. A transfer from one π-transporter to another takes place in a π-node (Montreuil, 2011). Π-movers can communicate with π-containers for information sharing and manage them temporarily. Accord-ing to the key pillars, openness and modularity enable the easiness of transferrAccord-ing a π-container, while decentralization and autonomy help π-movers move through the network.

Key stakeholders in the Physical Internet

specific restrictions, for example time and place (Sternberg and Norrman, 2017).

Senders receive the order for physical objects from customers and are responsible for processing the order and the arrangement of transport via matchmakers. Their objective is to process the physical objects and send them to the right receivers (Sternberg and Norrman, 2017).

Container owners offer the π-containers to the Physical Internet network and maintain them. Their objective is to make profit from providing π-container that meet the right requirements (Horst, 2018).

Matchmakers match requests for transport from senders to π-containers. Their objective is to match requests for transport from senders with the right π-container (Horst, 2018).

Hubs offer services to stage and consolidate π-containers and to let them move further through the logistics network (Montreuil et al., 2012). Their objective is to process π-containers efficiently (Sternberg and Norrman, 2017).

Transporters perform the physical transportation of π-containers between senders and receivers (Montreuil et al., 2012). Their objective is to transport π-containers efficiently through the network (Sternberg and Norrman, 2017).

2.3 Decentralization and centralization in the Physical Internet

The focus of this research is on the key pillar decentralization of the Physical Internet, as there seems to be a dichotomy in interpreting the Physical Internet as a fully decentralized system or as a decentralized system with centralization. In theory the Physical Internet is envisaged as a decentralized system, while in optimization models the presumably decentralized Physical Internet is assumed to have centralization.

et al., 2015). Most of these research rely on centralization in the Physical Internet, for example that a coordinator provides a platform solution or data governance. Assumed is that a coordi-nator enables centralization in the Physical Internet by connecting stakeholders in the Physical Internet, managing issues of trust and collaboration, and ensuring global efficiency (Meyer et al., 2019). For example, Yao (2017) assumes for establishing his scheduling optimization model that information transparency among stakeholders is realized. However, to achieve data sharing in a trusted and collaborative way a significant level of coordination is required (Vargas et al., 2019). This assumption suggests that there is centralization in the Physical Internet.

Thus, it appears from the above that on the one hand, the Physical Internet is envisaged as a fully decentralized system, while on the other hand the Physical Internet is assumed to have centralization. This contrast in interpreting the Physical Internet as a fully decentralized system or as a decentralized system with centralization is recognized in theory (Ambra et al., 2019; Meyer et al., 2019; Sallez et al., 2015). In theory, the question whether the Physical Internet should have centralization is posed multiple times. Sternberg and Andersson (2014) indicate that little scientific support exists for the efficiency of a fully decentralized system, which raises the question of having centralization. In addition, Ambra et al. (2019) reviewed both, Physical Internet papers and synchromodality research papers that are related to the current trends in logistics. An important finding in this review is that the Physical Internet and synchromodality research streams are not intertwined. Since, the Physical Internet stream is following a decentralized trend, while the synchromodality stream is following a centralized trend. As a consequence, to move towards the Physical Internet, they pose the question whether the presumably decentralized Physical Internet should have centralization.

The advantages and disadvantages of decentralized system and a centralized system are dis-cussed in Section 2.1 and the main (dis)advantages appear to be the same in the Physical Internet. Decentralization has its fundamental strengths, which is why it was used as a key pillar in the Physical Internet, while the advantage of global efficiency strengthens the position of incorporating centralization within the Physical Internet (Sallez et al., 2015). A research gap exist in closing the distance between the envisaged Physical Internet and the need for central-ization within the Physical Internet. There seems a strong need to incorporate centralcentral-ization in the decentralized Physical Internet.

Centralization in the Physical Internet

Internet, a system that is between the extremes of a fully decentralized and a fully centralized system is created, which may be similar to the aircraft example in Section 2.1. In this way there can be optimized at a global level (Trentesaux, 2009), while handling reactive at a local level (Quak et al., 2018).

Topic Critical requirement

1. Stakeholders

1.1 Centralization in a decentralized system can be achieved by using different coordinators. 1.2 The objectives of stakeholders in the Physical Internet need to be taken into account.

2. Nature of coordinator

2.1 The coordinator should be a IT system that is managed by a stakeholder who is an important link in the network.

2.2 Centralization in a decentralized system should be achieved by a bottom-up approach.

3. Operational range of coordinator

3.1 Centralization in a decentralized system should be achieved in high density areas. 3.2 Centralization in a decentralized system should be achieved in bottleneck scenarios. 3.3 A coordinator should be operational in high density areas.

3.4 A coordinator should not be operational in low density areas. 4. Characteristics

of coordinator

4.1 A coordinator should have sufficient computational power. 4.2 A coordinator should be adaptive.

5. Activities of coordinator

5.1 A coordinator should identify conflicts.

5.2 A coordinator should, in case of conflicts, identify the involved stakeholders.

5.3 A coordinator should, in case of conflicts, collect and store information of the involved stakeholders.

5.4 A coordinator should, in case of conflicts, identify and provide a solution to the involved stakeholders.

5.5 A coordinator should perform activities on a operational, tactical and strategic level. 5.6 Coordinators on operational, tactical and strategic level should interact.

3

Methodology

In this section the research methodology that is used to answer the research questions is de-scribed. In Section 3.1, the research design is described and justified. In Section 3.2 and 3.3, it is explained how data is collected and analysed. In Section 3.4 and 3.5 it is described how the system is designed and how the design and critical aspects are validated.

3.1 Research design

In order to design centralization in the Physical Internet from an operational perspective and to identify the critical aspects of this proposed system, Design Science Research is performed. Design Science Research focuses on developing knowledge that can be used in an instrumental way to design and implement actions, processes or systems that are used to address field problems or promising opportunities. In addition, Design Science Research aims at improvements based on thorough understanding of these problems and opportunities (Aken van et al., 2016). Design Science Research fits the aim of this research, developing knowledge for designing centralization in the Physical Internet to help tackling the global logistics problem, since this research strategy helps developing knowledge needed in designing systems (Aken van et al., 2016).

According to (Wieringa, 2009), Design Science Research for emergent systems consists of four phases: problem investigation, solution design, design validation and solution implementation. However, the Physical Internet system is not yet implemented and can therefore be charac-terized as an envisaged system. Szirbik (2019) introduced, based on the phases of Wieringa (2014), four Design Science Research phases for envisaged systems, which are applicable to this research. According to Szirbik (2019), Design Science Research for envisaged systems consist of the following four phases:

1. Analysis of existing theory about the envisaged system.

2. Analysis of systems that exists and may be replaced by the envisaged system. 3. Design of a generic architecture, or parts of it, and guidelines to apply it. 4. Validation of the design outcomes via expert panel assessments.

Figure 1: Research design 3.2 Theoretical analysis

The first phase in Design Science Research is reviewing existing theory about the proposed system and is indicated here as the theoretical analysis. The aim of the theoretical analysis is to study theory about decentralized systems, centralized systems and combinations of both in order to identify critical requirements for incorporating centralization in the Physical Internet. In addition, the aim is to provide the basics of the Physical Internet as a basis for designing centralization in the Physical Internet. The upper left part of Figure 1 represents the theoretical analysis, which consists of two parts that lead to the critical requirements from theory.

theoret-ical analysis is addressed in Section 2 and the abstracted crittheoret-ical requirements are included in Table 1.

3.3 Practical analysis

The second phase in Design Science Research is analysing existing systems that may be replaced by the proposed system and is indicated here as a practical analysis. The aim of the practical analysis is to analyze centralization in the Physical Internet from a practical perspective and to analyze an existing combination of a decentralized system and a centralized system, in order to identify critical requirements for centralization in the Physical Internet. The upper right part of Figure 1 represents the practical analysis, which also consists of two parts that lead to the critical requirements from practice. The practical analysis is addressed in Section 4.

The first part of the practical analysis consists of investigating centralization in a decentral-ized system from a practical perspective. The practical perspective means the perspective of stakeholders in the current logistics system. Section 2.2 describes the key stakeholders in the Physical Internet. Relating this to the current logistics system, transporters and hubs are rele-vant for this part of the practical analysis, as those may become part of the Physical Internet. With regard to centralization in the Physical Internet, the air traffic control system in Section 2.1 suggests a likely new role of a coordinator. Therefore a forwarder in the current logistics system is considered to be relevant for this part of the practical analysis, as a forwarder has a coordinating role in the current logistics system. In addition, the practice on logistics and future logistics like the Physical Internet can be highlighted by experts.

The second part of the practical analysis consists of investigating an existing system that is a combination of a decentralized system and a centralized system. This system can be considered as a practical example of the proposed Physical Internet system, such as the air traffic con-trol system in Section 2.1. The existing system is investigated independent of its application environment and can provide critical requirements for incorporating centralization in a decen-tralized system, like the Physical Internet. This part of the practical analysis is performed at one company.

Data collection for both parts of the practical analysis is structured in a similar way. Semi-structured interviews are conducted with multiple logistics specialists of different companies. Table 2 provides an overview of the companies that are involved in the practical analysis and the position of the interviewees. This is a small number of cases, which limits generalizability of the outcomes. However, in this first steps of investigating centralization in the Physical Internet, it may provide valuable information for an initial design. The face-to-face interviews took place in November, 2019.

Type Company Role of interviewee(s) Transporter Peter Appel Transport Business Development Manager Transporter, Hub Koopman Transmission BV Operational Manager

Transporter, Forwarder, Mediterranean Shipping Manager Special Projects Container owner, Hub Company

Transporter, Hub Wijnne Barends Manager Logistics

Hub Port of Rotterdam Manager Business Analysis & Intelligence Forwarder Team Freight Forwarding Managing Director & Sales

and Manager Operations

Expert, Hub Eco2City Project Manager

Expert TU Delft PhD Student on Physical Internet

(De)centralized planning company Hospital Nij Smellinghe Capacity Manager

Table 2: Overview of interviews

the company and interviewee. Roughly, three interview protocols can be distinguished: one for experts in the Physical Internet, one for stakeholders in the current logistics system and for a (de)centralized planning company. The protocol for experts is focused on centralization in the Physical Internet and is included in Appendix A.1. The protocol for stakeholders in the current logistics system is focused current logistics system and centralization in a decentralized system. This protocol is included in Appendix A.2. The protocol for a (de)centralized planning company is focused on the combination of a decentralized system and a centralized system, independent of the nature of the company and the Physical Internet. This protocol is included in Appendix A.3. The presentation that is used during the interviews is included in Appendix A.4.

Furthermore, a second researcher, who also investigates centralization in the Physical Internet was present during the interviews to ensure that there was sufficient depth and that answers are well interpreted. The interviews, which included also questions from a strategic-business perspective for the research of Jong de (2020), are conducted in Dutch. The interviews lasted about 1-1.5 hour and are recorded for reliability purposes.

Data analysis started with transcribing the interviews in order to ensure the use of accurate outcomes. The transcriptions of the interviews are sent to the interviewees to confirm the correctness of the data. Thereafter, the data is coded using an inductive approach. Inductive coding means that by interpreting the raw data concepts, themes and dimensions are developed (Karlsson, 2016). This is a useful approach of coding, because of the exploratory aim of the interviews. In Section 2 several critical requirements are abstracted from theory. These critical requirements have functioned as a base in the coding process, which means that the coding process also has a deductive approach.

step, differences and similarities between the first order concepts are identified and coded in second order themes. The first order concepts are coded as 46 different second order themes. In selective coding step, the 46 second order themes are compiled as 12 aggregated dimensions. The codes, themes and dimensions are based on interview data, interpretation as well as on theory. In the end multiple critical requirements for centralization in the Physical Internet can be defined based on the structured interview data.

3.4 System design

The third phase in Design Science Research is designing the generic architecture of the proposed system and describing guidelines to apply it. The aim of the system design is to develop a generic design, based on the critical requirements abstracted from the theoretical and practical analysis, and identify the critical aspects of the design. The middle part of Figure 1 represents the system design. The system design is addressed in Section 5.

Based on the critical requirements multiple scenarios for centralization in the Physical Internet are defined. To have a graphical depiction of the scenarios Business Process Model and Notation (BPMN) models are developed. BPMN models can be used for capturing activities, decision responsibilities, control and data flow in processes (Decker and Barros, 2007). As this research is a first step in developing centralization in the Physical Internet, a high level design is developed and according to Dijkman et al. (2008) BPMN models are especially useful in the first phases of systems development and for designing high level systems design. Developing the design is an iterative process, which means that there is cycled between the outcomes of the theoretical analysis, practical analysis and the created designs. When the design was finalized the critical aspects are identified.

3.5 Design validation

The last phase in Design Science Research is validating the outcomes. According to Wieringa (2014), the aim is to define the academic value of the design outcomes and its intended objective. The lower part of Figure 1 represents the design validation. The design validation is addressed in Section 6.

4

Practical Analysis

In this section the results of the practical analysis are discussed, which complement the critical requirements for designing centralization in the Physical Internet. The practical analysis con-sisted of multiple interviews, as explained in Section 3.3. The gathered data is analysed and structured by means of coding. The coding tree is included in Appendix B.

In this research centralization is when a coordinator advises or decides on transport routes of two or more shipments in a simultaneous fashion. The aggregate dimensions of the coding tree, which are included in Table 3, represent the aspects to consider for critical requirements for a coordinator to be operational in the Physical Internet and by that achieves centralization in the Physical Internet. According to Table 3, six aggregate dimensions can be considered as general requirements for achieving centralization: presence of a coordinator, the nature of the coordinator, the operational range of the coordinator, the access to the coordinator, the characteristics of the coordinator and the activities of the coordinator.

Aggregate dimension Presence of coordinator

General requirements Nature of coordinator

Operational range of coordinator Access to coordinator

Characteristics of coordinator Activities of coordinator

Table 3: Summary of coding tree - General requirements

The aggregate dimension that is about the activities of the coordinator is turned out to be specific and extensive, as such that it is possible to divide the single activities further into three time horizons. Therefore, the single activities of the coordinator are included in the coding tree as aggregate dimensions, as is shown in Table 4. These activities are divided, based on time horizon, into operational, tactical and strategic activities, which are respectively discussed in Section 4.2, 4.3 and 4.4. From each aggregate dimension can be critical requirements abstracted, which are included in Table 5 at the end of Section 4. The critical requirements that are abstracted from theory, Table 1, and from practice, Table 5, are used for designing the system in Section 5. Therefore, the numbering in Table 5 continues the numbering of Table 1, if possible.

Aggregate dimension Making decisions

Operational activities Operational advising

Matching capacity

Tactical advising Tactical activities

Developing infrastructure

Strategic activities Providing information on long term collaboration

4.1 General requirements

According to the practical analysis, the coding tree shows that a coordinator should meet several general requirements within six dimensions in order to be operational. The first dimension, presence of a coordinator, defines whether a coordinator actually should be involved. The second dimension, the nature of the coordinator, defines who should initiate the coordinator. The third dimension, the operational range of the coordinator, defines which part of the logistics network the coordinator should concern about. The fourth dimension, the access to the coordinator, defines which stakeholders are allowed to collaborate with the coordinator. The fifth dimension, characteristics of the coordinator, defines what characteristics the coordinator should contain. The sixth dimension, the activities of the coordinator, defines what activities the coordinator should perform. The five dimensions are further discussed below.

Presence of a coordinator

The coordinator can be involved to achieve centralization. A first thing that is investigated is whether interviewees agree that a coordinator should be incorporated in a decentralized system in order to achieve centralization. Most interviewees agreed that a coordinator should be involved, except two interviewees. One expert in the Physical Internet argued that if there is sufficient interaction between the Physical Internet elements, a coordinator is not required. However, it turned out later that this expert indirectly assumed that the hub serves as the coordinator. In addition, one stakeholder in the current logistics system argued that stakeholders should not collaborate at all, also not via a coordinator, which is in contrast to the Physical Internet. Since, most interviewees agreed that a coordinator should be involved, this is abstracted as a critical requirement.

Nature of coordinator

The coordinator can be a hub or a platform. It is argued by two interviewees that the coordi-nator should be initiated by a hub, as a hub is already a central point in the logistics network that coordinates between stakeholders and has access to relevant information, which is consid-ered important to achieve centralization. However, the hub is not independent as it also has its operational task as a hub. Therefore, it is mainly argued, and thus abstracted as critical requirements, that the coordinator should be a platform initiated by a neutral party and the platform should exist in the form of a IT system.

Operational range of coordinator

perceived as an important link in the logistics network, since the (de)composition of shipments takes place here and multiple stakeholders are involved, which requires coordination. In addition to the local hub level, it is mentioned by an expert in the Physical Internet that the coordinator should have control over both homogeneous elements and heterogeneous elements in the logistics network and should connect the control over these elements. This implies, for example, that the coordinator should control between multiple road transporters (i.e. homogeneous elements), but also between the road transporters and hub (i.e. heterogeneous elements). The critical requirements that can be abstracted are that the coordinator should be operational at a local hub level and should control over homogeneous and heterogeneous elements.

Access to coordinator

The coordinator can be accessed by all stakeholders in the Physical Internet. Some interviewees indicated that in principle all stakeholders should be allowed to collaborate with the coordinator at any time, but should be identified at all times. Since each stakeholder is part of the Physical Internet, each stakeholder should be able to access the coordinator and no stakeholder should be excluded. However, it is mentioned that the open access should not hold for all cases. For example, as stated by an interviewee: ”If a coordinator makes decisions about planning, stakeholders that are involved should not be able to exit the coordinator if they are harmed due to an inbalance in supply and demand.”. If there are a few shipments and the coordinator decides that all transporters need to stop half of their trucks then the harm should be shared among the involved stakeholders and one should not be able to drop out. The critical requirements that can be abstracted are that all stakeholders should be able to collaborate with the coordinator in an open way, which holds to a certain extent.

Characteristics of coordinator

The coordinator can be characterized by adaptivity, neutrality, transparency and needs sufficient calculation power and scale to be operational. Interviewees indicated several characteristics that a coordinator should meet in order to be operational. The coordinator should be able to adapt fast to the actions around and it is often marked by interviewees that the coordinator should be neutral and transparent towards stakeholders. For example by providing the stakeholders with arguments on which decisions or advice are based. Furthermore, the coordinator should have sufficient calculation power to process information and make decisions and a certain amount of stakeholders need to collaborate with the coordinator in order to achieve efficiency. The critical requirements that can be abstracted are that the coordinator should be adaptive, neu-tral, transparent, is equipped with sufficient calculation power and is operational over sufficient shipments.

Activities of coordinator

activities. Therefore these activities can be divided into operational, tactical and strategic ac-tivities. The activities and related time horizon are added as critical requirements. As explained in the introduction of this section and as shown in Table 4, the single activities are structured as aggregate dimensions. The operational, tactical and strategic activities are discussed in, re-spectively, Section 4.2, 4.3 and 4.4. However, overall, interviewees mentioned that the activities of the coordinator may change over time or may differ per part of the logistics network, and thus may differ per coordinator. For example, it is likely that the first activity performed by the coordinator is advising and that thereafter a decision making activity or a more strategic activity is performed. Another example is that it is likely that the coordinator makes decisions as a first activity in road transport, especially the last mile.

4.2 Operational activities

According to the practical analysis, the coordinator can perform three operational activities and should meet several requirements to perform these activities. As shown by the aggregate dimensions of the coding tree in Table 4, the operational activities include making decisions, op-erational advising and matching capacity. These activities are discussed below. The abstracted critical requirements are not explicitly named, but are included in Table 5.

Making decisions

The activity of a coordinator can be making decisions. According to experts in the Physical Internet, the coordinator should make decisions. In contrary to experts, most stakeholders in the current logistics system argued that the coordinator should not make decisions, but should advise. Therefore, this section focuses on making decisions, while the next section focuses on advising. Overall, most interviewees agreed that the basis of decision making and advising is collecting and exchanging information, which is apparent from the second order themes of the coding tree, for example, information handling and real time information.

multiple containers that aim to be transported by the same truck. By performing this activity the coordinator serves as an information exchanger and decision maker. To establish this activity, the second order codes in the coding tree show that the following things should be considered: interaction, type of information, information handling, real time information, information and IT standardization, access to information, authorization and restrictions.

The coordinator should direct the interaction between stakeholders. Information need to be shared between the elements in the Physical Internet: containers, movers and nodes. At specific points in the logistics network this can be directed by the coordinator. It is not necessary that all elements in the logistics network interact with each other. One interviewee clearly noted that in general, an element should interact with another element if they affect each other’s process. This implies that the node that a container reaches has interacted with the previous node and the next node that the container reaches. Also, a transporter should interact with the transporter that is before him and that is after him at a hub. And, a container, a hub and a transporter should interact with each other when affecting each other’s process. In the end, the coordinator should, based on the interaction and if required, return a decision to the elements.

The coordinator should handle the right type of information in a proper way. Most interviewees agreed that the minimum information that should be shared with the coordinator and among stakeholders is operational information, except the information about senders and receivers and prices. In order to overcome an information sharing barrier, one interviewee stated that stake-holders should define on beforehand stakestake-holders should define what the minimum information is that they want to exchange with coordinator and with each other. Furthermore, it is ob-viously mentioned that stakeholders should be sure that information is handled properly by a coordinator with regard to confidentiality, safety and privacy.

The coordinator should work with real time and standardized information in order to make efficient decisions. One interviewee stated: ”In a planning is time limited information included, if that information is not real time accessible it is not possible to adapt the planning efficiently”. Therefore the coordinator should make decisions based on real time information, as a result that stakeholders can adjust efficiently and optimize their processes. Using real time infor-mation should prevent for conflicts and for performing activities that are not relevant. When elements are closer to a node, which may be the operational range of the coordinator, the real time information should be updated more frequently. In addition to real time information, the coordinator should work with information standards in order to be able to exchange consistent information with all stakeholders. One interviewee remarked a barrier that currently hinders information sharing: ”Transporters have different IT systems, which implies that data is named differently and that it is difficult to decide who needs which data.”. Therefore, information that is exchanged with the coordinator should be defined similar by all stakeholders and in the IT systems of stakeholders.

all stakeholders should have access to all information, which was mentioned before. Therefore, the coordinator should identify which stakeholders should receive which information. Thus, the coordinator should ensure that the relevant stakeholders receive the relevant information, which means that stakeholders that affect each others process should receive each others information. One interviewee explained how this may work, which is summarized as: ”A stakeholder receives information from the coordinator, sends information back to the coordinator, which can be used by the stakeholder that is next in line.”. The coordinator should authorize the stakeholders per information element. If a stakeholder aims to have an information element from another stakeholder, one stakeholder should authorize the other and should perform this authorization per information element.

The coordinator should take restrictions into account in terms of containers, movers and nodes when making decisions. Restrictions are the preferences of containers, movers and nodes that need to be considered in order to provide an efficient decision. The more restrictions added to the elements the more complex and it is limiting the options. For containers preferences in terms of price, route, time, type of shipment (e.g. fresh goods) and service level should be taken into account. For movers and nodes their preferences in terms of price, type of transporter and service level should be taken into account. For example, in the current logistics system not all transporters are allowed to transport all types of shipments and transporters have different service levels. An option could be that the coordinator should make a distinction between type of shipments. Further, it is important that the coordinator should check for the leading element, while making decisions. For example in a port, the leading element is the ship.

Operational advising

The activity of a coordinator can be operational advising. As mentioned at the decision making activity, most stakeholders in the current logistics system argued that the coordinator should not make decisions, but should advise. Most interviewees emphasized that the coordinator should not make decisions, since most stakeholders aim to keep control by make decisions for themselves.

According to the results of the practical analysis, a clear conclusion about whether the coordi-nator should make decisions or should advise cannot be drawn, which is why both are included as an activity. Some interviewees argue for decision making and others argue for operational advising, but when discussing both activities two additional arguments are made. First, it is indicated that a differentiation can be made between coordinators that make decisions and co-ordinators that make no decisions. For example, it is mentioned that coco-ordinators may make decisions in the last mile, because of its relatively large inefficiency, while operational advising in other parts of the logistics network. This indication suggests that the activity of the coordi-nator may differ per part in the logistics network. Second, it is indicated by the interviewees that the initial activity of the coordinator is probably operational advising, but thereafter the coordinator may take smart decisions based on the information. This indication suggests the change of activities of a coordinator over time and that the operational advising activity is a first step towards the making decisions activity.

Matching capacity

The activity of a coordinator can be matching capacity. Some interviewees, mostly transporters in the current logistics network, mentioned the existing platform where shipments are offered. In the current logistics network transporters offer shipments, which they cannot transport them-selves, on a platform and other transporters can take these shipments and execute the transport of these shipments. In this way capacity of transporters is matched by a platform. When dis-cussing this in the Physical Internet context, it turned out that the coordinator can perform a similar activity. Relating the platform in the current logistics system to the Physical Internet where shipments are not linked to a specific transporter, but transporters are linked to contain-ers, the activity can be the other way around. This means that not shipments are offered, but capacity is offered.

The activity matching capacity implies that transporters provide the coordinator with informa-tion about their capacity. By offering the capacity the coordinator can match available containers with the transporter in order to increase efficiency. To establish this activity, the second order codes in the coding tree show that the following things should be considered: information and inbalance in supply and demand.

4.3 Tactical activities

According to the practical analysis, the coordinator can perform one tactical activity and should meet several requirements to perform this activity. As shown by the aggregate dimensions of the coding tree in Table 4, the tactical activity is tactical advising. This activity is discussed below. The abstracted critical requirements are not explicitly named, but are included in Table 5.

Tactical advising

The activity of a coordinator can be tactical advising. It is argued by an interviewee that the coordinator should exchange information about future events and advise on that in order to optimize the logistics network over a medium term.

The activity tactical advising implies that the coordinator should collect information from stake-holders and functions as an information database that provides based on the information a tac-tical advice for decisions to stakeholders. The coordinator should use the information that is collected over time to make predictions. For example, the coordinator could provide a forecast to a hub. In addition, the coordinator should check for future irregularities and conflicts. 4.4 Strategic activities

According to the practical analysis, the coordinator can perform two strategic activities and should meet several requirements to perform these activities. As shown by the aggregate dimen-sions of the coding tree in Table 4, the strategic activities include developing infrastructure and providing information on long term collaboration. These activities are discussed below. The abstracted critical requirements are not explicitly named, but are included in Table 5.

Developing infrastructure

The activity of a coordinator can be developing infrastructure. One interviewee suggested that the coordinator can facilitate in developing the infrastructure of the logistics network.

The activity developing infrastructure implies that the coordinator should identify based on its collected information over the long term which infrastructural investments should be made and it should establish collaboration between stakeholders to develop the infrastructure. However, to establish collaboration, stakeholders should know what their return of investment is in terms of efficiency.

Providing information on long term collaboration