CASSANDRA D4 3 final report - cassandra-project.eu deliverables... · The CASSANDRA project aims to...

31-05-2014 - CASSANDRA WP400 – D4.3 Final Report Living Lab Iberia-Africa [PU]

Page | 1

EUROPEAN COMMISSION

SEVENTH FRAMEWORK PROGRAMME THEME Monitoring and tracking of shipping containers

SECURITY FP7-SEC-2010-3.2-1

GA No. 261795

CASSANDRA

Common assessment and analysis of risk in global supply chains

WP400

Living Labs

Deliverable No. D4.3

Deliverable Title Final report of Iberia-Africa Living Lab

Dissemination level Public

Written By P. Pérez / J. García / G. Herrero / R. Venancio / P. Ponte / R. Gracia

28.04.2014

Checked by I. Lucassen (TNO) / V.Dignum (TUD) B. Klievink (TUD)

14.05.2014 28.05.2014

Approved by Heather Griffioen / TNO 31.05.2014 Issue date 31.05.2014


Page | 2

Executive Summary This document is a final version of the D4.3 Iberia-Africa trade lane Living Lab report. The aim of this report is to explain in detail how the CASSANDRA concepts have been implemented in the Living Lab Iberia-Africa to improve supply chain visibility and risk assessment both for industry and authorities. A new data sharing concept (data pipeline concept) has been demonstrated in the course of the Living Lab. The Living Lab Iberia-Africa comprises two trade lanes: Spain-Egypt and a demonstration trade lane involving Portugal. The aim of the Spain-Egypt trade lane is to demonstrate the CASSANDRA concepts in a real environment involving actors and stakeholders who are not directly involved in the project as partners. The aim of the Portuguese trade lane is to demonstrate IT solutions. Specifically, the solutions involve the implementation of a Cassandra dashboard and an interface of the Port Community System (PCS) Setubal based on the Data Security Framework as part of the backend of the dashboard. This document starts with a brief overview of the scope of the Cassandra project and the concepts that are demonstrated in the Living Lab (the security improvement through visibility, risk based approach, data pipeline, and piggy-backing concepts). Hereafter the document focuses on the Living Lab methodology used, the process followed to set it up and the data collection and analysis procedures carried out. Henceforth both trade lanes are analysed in depth explaining the status of the pilot, describing the actions to be implemented and the expected benefits. Finally this report concludes with an analysis and evaluation of the results. Please note that this report covers the whole duration of the Cassandra project including the preparation, the design of the technical solution and risk management approach phases, the installation and commission of the trade lanes, and the obtained results and findings. The Spain-Egypt has run for two months with one shipment every two weeks from Spain to Egypt and one shipment per week from Egypt to Spain. The trade lane has been able to demonstrate the uses cases set up satisfactorily. The participants remarked the advantages derived from the use of CASSANDRA mainly in four aspects:

- Access to the information in advance facilitating procedures (e.g. preclearance procedure)

- Access to safer information avoiding mistakes - Reduce the use of resources (administrative, software and system resources) - Improve the business risk analysis thanks to the immediate access to the information.

The Portuguese trade lane has focused on the set up of a customizable dashboard to cover the needs of different actors through the implementation of widgets. This platform was presented to the stakeholders in workshops. The main pros manifested by the participants were the ease of use and the way the information is organized. For the cons the main critic was related to the lack of actors sharing information through the platform. Nevertheless the dashboard was very much appreciated by different stakeholders, the concept has been approved and welcomed mainly by Portuguese and Spanish Customs and their legacy is perfectly tangible.


Page | 3

List of Abbreviations CIF Cost, Insurance, Freight (Incoterm)

ENS Entry Summary (declaration)

ESB Enterprise Service Bus

FCL Full Container Load

FF Freight Forwarder

FOB Free On Board (Incoterm)

KPI Key Performance Indicator

LCL Less than Container Load

LL Living Lab

PoD Port of Discharge

PoL Port of Loading

RBA Risk Based Approach

RTA Regional Trade Agreements

GATS General Agreement on Trade in Services

PCS Port Community System

TBA Transaction Based Audit

DC Data Capture

BCL Business Communication Layer

CML CASSANDRA Messaging Layer

TRL Transport and Routing Layer

ETL Extract Transform Load


Page | 4

Index 1 Introduction .................................................................................................................... 5

1.1 Background of the project ........................................................................................ 5

1.2 Objective and scope ................................................................................................ 5

1.3 Limitations ............................................................................................................... 6

2 CASSANDRA concepts put to practice ........................................................................... 7

2.1 Introduction to the CASSANDRA concepts ............................................................. 7

2.2 Putting the concepts to practice in the Living Lab ...................................................10

3 Approach/methodology..................................................................................................13

3.1 Living Labs approach .............................................................................................13

3.2 Living Labs 3 process .............................................................................................15

3.3 Data Collection Procedures ....................................................................................19

3.4 Data Analysis Procedures ......................................................................................20

4 Living Lab Iberia-Africa: the Spain-Egypt trade lane ......................................................22

4.1.1 As-Is situation..................................................................................................22

4.1.2 To-Be situation: Demonstration plan ...............................................................30

4.1.3 During pilot phase ...........................................................................................39

4.1.4 Use by parties and benefits .............................................................................39

4.1.5 Reflection ........................................................................................................40

5 Living Lab Iberia-Africa: the Portugal-Egypt trade lane ..................................................43

5.1.1 As-Is situation..................................................................................................43

5.1.2 To-Be situation: Demonstration plan ...............................................................46

5.1.3 During pilot phase ...........................................................................................54

5.1.4 Use by parties and (expected) Benefits ...........................................................55

5.1.5 Reflection ........................................................................................................56

Appendix A – Spain-Egypt trade lane: Activity and Decision Log ..........................................58

Appendix B – Portugal trade lane: Activity and Decision Log ................................................64


Page | 5

1 Introduction

1.1 Background of the project

At present the main challenge in the international intermodal container logistics supply chain domain revolves around improvement of the efficiency and the security. With increasing flows of containerised traffic and growing emphasis on (national) security, businesses and government are struggling to find efficient and effective means to ensure full supply chain control and security. A large number of research studies have been conducted to investigate supply chain dependencies, vulnerabilities and resilience. Supply chain security frameworks have been developed to support businesses in improving resilience and security. Governments are launching security programmes to further develop security standards and procedures. The CASSANDRA project aims to improve supply chain visibility, efficiency of trade compliance and effectiveness of border control and supervision by combining E-Freight with E-Customs. CASSANDRA builds on previous EC FP7 projects INTEGRITY, SMART-CM and ITAIDE. The Living Labs research approach studies innovation in complex real world settings. In a Living Lab, real world partners are involved. IFS and EFS freight forwarder companies have participated in the Spain-Egypt trade lane, other companies as Oxylane have participated in the preliminary phases of the living lab cooperating in the definition of requirements and providing crucial information. After a research phase in which the new RBA and data pipeline concept were investigated and defined, the demonstration through a Living Lab with two trade lanes started. The Spain-Egypt trade lane was devoted to demonstrate the main concepts of the project through three use cases:

- Export source = import source - ENS Multiple filing - Digital document based visibility

The Egypt – Spain trade lane focused on three main pillars: Port Community System simulation in Egypt, Data Capture implementation in Alexandria and Barcelona and set-up of dashboard both in Spain and Egypt. The Portugal trade lane counts only on the information from the Setubal PCS without other external source so this trade lane focused on demonstrating the CASSANDRA Security Architecture and the evaluation of the platform for the Portuguese stakeholders not only regarding the dashboard but also and in a broader sense about the way that the CASSANDRA approach can enhance visibility and how that would be beneficial to those key stakeholders.

1.2 Objective and scope

CASSANDRA’s main strategic goal is to enhance supply chain visibility in order to improve business operations and the efficiency and effectiveness of government security inspections. The scope of the CASSANDRA project is limited to enhancement of the security and efficiency of the supply chain of container logistics. CASSANDRA focuses on development of two main concepts (further explained in section 2.1 Introduction to the CASSANDRA concepts):

- Data pipeline: a new data sharing concept which combines existing information sources in supply chains to improve visibility.


Page | 6

- Risk Based Approach by means of the so-called piggy-backing concept that reuses business data for government control purposes.

The Cassandra data pipeline concept combined with the new Risk Based Approach is applied and demonstrated in real-life trade lanes using a Living Labs research approach. The results of the project will impact both the business and governmental domains:

- For businesses, the strategic impact of CASSANDRA can be found in supply chain performance and cost reduction. The reduction of administrative documentation and planning errors will produce improvements and substantial cost reductions in supply chain operations. The CASSANDRA Risk Based Approach will facilitate the detection of disruptions reducing their negative effects and improving the mitigation measures.

- For government agencies, the new Risk Based approach for auditing will help customs to assess business processes and procedures and identify secure supply chains. By minimizing the attention given to these secure flows and businesses, customs can focus on high-risk flows resulting in higher hit rates and greater effectiveness of security related government inspections.

1.3 Limitations

The integration of existing supply chain visibility solutions and data capture technologies that are currently used in both government and businesses to enable the adoption of CASSANDRA proves challenging. The project focuses on data availability and data quality with regards to risk management purposes for developing data capture interfaces. The Living Lab Iberia-Africa has put in practice the data capture principle within an experimental environment with a limited number of data and stakeholders. The trade lane in Portugal has focused on evaluating the technological solutions together with engaged Portuguese stakeholders. The evaluations took place during the last phase of the project and focus on:

- Export via the harbour of Setubal (use case); - Data visibility as a result of the CASSANDRA tooling.

The Iberia – Africa Living Lab has been facing some limitations related to the difficulty of engaging external participants and the limited involvement of them when they participate in the demonstration especially to share data or information or invest time or resources to play an active role in the demonstration. In the case of Portugal trade lane this fact supposed that the trade lane changed its original objectives and re-focussed the participation of the stakeholders in order to take advantage of them. The Portuguese stakeholders (e.g. customs, Port Community, Port & Maritime Authorities) participated as evaluators of the CASSANDRA concept.


Page | 7

2 CASSANDRA concepts put to practice

2.1 Introduction to the CASSANDRA concepts

The contribution of CASSANDRA to a more secure and efficient supply chain is based on two pillars:

- A Data Pipeline to enable data exchange in the supply chain to improve visibility among stakeholders regarding goods and logistic processes.

- A Risk Based Approach, for businesses to identify the data elements needed to assess the supply and improve control and for governments to re-use business data for security control purposes.

Data pipeline concept The current customs and trade system is included in Figure 1 – Current customs and international trade system. At the bottom of the figure the physical layer shows the movement of cargo (brown boxes). The organisational layer (light blue boxes) controls the physical layer and presents the typical transactions that are made within the supply chain. The data and document layer (white and yellow boxes) shows the documents that are involved in the transactions. Mainly customs related documents are shown here. The information in this layer is captured in numerous documents of different formats, with different senders and receivers, which explain that data ownership is not always clear. All parties in the organisational layer hold a subset of the supply chain information; not one party has full end-to-end visibility and the reliability of information often is unclear. On top of the layers the regulatory bodies of exporting and importing countries are included. These government authorities rely on different supply chain partners for different sets of information.

Figure 1 – Current customs and international trade systems


Page | 8

Because the current system of data sourcing and sharing does not always result in accurate, reliable and timely information, the new pipeline data sharing concept is introduced by CASSANDRA (Figure 2 – Future Customs and International Trade Systems with the CASSANDRA data pipeline). Besides bringing better visibility, this concept of data sharing also supports and facilitates the Risk Based Auditing approach. The data pipeline unifies the different sets of information held in the different types of documents, both commercial data as well as container tracking data. All partners in the supply chain feed their transaction related data in the pipeline. The data then comes available to other partners in the chain and to related government authorities, where it can be used for valuable risk assessments.

Figure 2 – Future Customs and International Trade S ystems with the CASSANDRA data pipeline

Even though the concept of the CASSANDRA data pipeline is quite simple, its realisation is severely complex. A large number of parties is involved, each having their own requirements and using their own IT systems. CASSANDRA aims to achieve interoperability of these heterogeneous systems by combining state of the art IT innovations. The result is a virtual pipeline through which data-sharing and data crawling is possible. The concept of pipeline is a virtual one which means that CASSANDRA will work on technically bridging the gaps between existing supply chain solutions instead of building a completely new platform. Risk Based Approach Business and government have different perspectives regarding risk assessment. Business focusses on disruptions and operational risks whereas the government’s main concern is about security and safety of citizens.


Page | 9

Risk, disruption and security are combined in the supply chain security framework as shown

in Figure 3 – Supply chain security strategy. Sources of risk can lead to disruption when they affect vulnerable parts or aspects of the supply chain. Vulnerabilities of the chain depend on the logistic structure and design of the chain (e.g. interdependencies) and the measures that have been taken to make the supply chain less vulnerable to certain risks. These measures are summarized as security enhancing measures consisting of analysis tools, and preventive and reactive measures. The analysis tools are as reliable and correct as the information that feeds them. This means that supply chain information that is used for risk (vulnerability) assessment is of crucial importance to both government and business, each for their own specific assessment goal (operations and security).

Figure 3 – Supply chain security strategy

At present government agencies perform risk assessments using the traditional Transaction Based Audit (TBA) approach. With this transaction approach each cross-border trade transaction is subject to inspection based on declaration data submitted to the authorities by supply chain partners. CASSANDRA introduces the Risk Based Audit (RBA) approach on top of TBA. RBA not only focuses on transaction results and records, but also on the risks and the underlying causes of disruptions. . It therefore shifts the attention from transaction data quality to overall process quality. RBA uses business process information instead of only transaction data for risk measurement and control. For supply chain management this means that with RBA


Page | 10

whole chains and container flows are audited, including the internal company processes as well as the intercompany processes. Special emphasis within the CASSANDRA project regarding RBA is placed on the principle of piggy-backing. Piggy-backing proposes to reuse existing business data for a goal other than for which this data was initially meant. Government agencies can use the piggy-backing principle to re-use business data for their risk assessments. The CASSANDRA RBA presents two challenges; On the one hand, current business and government risk assessment methodologies need to be aligned to be able to re-use business data (the piggy-backing principle). On the other hand, the reliability, quality and availability of the data provided needs to be ensured.

2.2 Putting the concepts to practice in the Living Lab

The CASSANDRA Living Lab of subject aims to demonstrate the aforementioned concepts. Specifically, in the Living Labs a dashboard tool that visualises collected data from the CASSANDRA pipeline is analysed, evaluating how the tool is used by stakeholders involved in the transport supply chain. The dashboard retrieves information from IT systems used by CASSANDRA stakeholders. To make this information available, the different systems recover information through a Data Capture (DC) interface. The DC interface has a specified structure defined in CASSANDRA deliverable D322 Interfaces. The main design aspects of the DC interface related to this deliverable’s objectives are: 1. Business Communication Layer (BCL), containing the functionality for assembling

semantically meaningful business content (such as documents, instructions etc.) into a valid CASSANDRA message payload conforming to the (business) ontology that is/needs to be developed. Also, BCL contains functionality for creating CASSANDRA message headers that handle business application level routing (again conforming to the business ontology). Thus, the CASSANDRA message header can be seen as a standardized (set of information on an) ‘envelope’ and the payload as the envelope’s contents.

2. CASSANDRA Messaging Layer (CML), containing all functionality for communicating (sending, routing and receiving) CASSANDRA messages. This layer contains the functionality for converting addresses between the BCL and the TRL (Transport and routing layer – see below). Also, it may contain functionality for checking the integrity of the structure (syntax) of messages transmitted, routed, or received. Note that checks for correct semantics belong to the business layer, as the business defines the corresponding ontologies. The structure of BCL and CML is shown in Figure 25 - DC messages structure

3. Transport and Routing Layer (TRL), containing all functionality for transporting messages between CASSANDRA stakeholder systems. This layer has no knowledge about how CASSANDRA messages are structured. It may use any existing protocol that provides the required functionality, such as ebMS, AS2, FTP, SOAP, etc. Within the context of a specific Living Lab, it must be decided which protocol(s) to use for this layer. An example of TRL can be seen in Table 10 – DC Transport and Routing Layer

The DC interface tries to keep things as simple and generic as possible to facilitate integration. For the Living Lab described in this document the following assumptions regarding the different DC layers are made: 1. Regarding the BCL the different stakeholders involved should agree about the workflow

process and required steps to interchange communication.


Page | 11

2. Regarding the CML the different stakeholders involved should implement a DC interface that will improve the business processes. Internally, this layer sends the information regarding a specific message (composed by headers and payload). This layer is the most relative to the living labs implementation, Section 3 Data capture implementation at CML of 4.1.1 As-Is situation go into detail about the CML contents to interchange messages. These messages will have to be accepted by stakeholders involved.

3. To facilitate the communications the DC Transport and Routing Layer is implemented using HTTPs protocol together with a REST interface implementation. Both technologies cover the needs of:

a. Standard Communications; b. Proved technology; c. Easy to integrate; d. Security;

In summary, the Data Capture interface is an auto discoverable service which is exposed to all the members involved in CASSANDRA. It offers a REST interface (with messages agreement) to make the communications available between the different stakeholders who want to retrieve information from a specific system. When somebody requests information, the system will be capable of discovering which DC owns the information and return it to the requestor. Finally, a web application (Dashboard) visualizes the information through the Data Pipeline which is connected to the different DC interfaces. “A dashboard is a visual display of the most important information needed to achieve one or more objectives; consolidated and arranged on a single screen so the information can be monitored at a glance”, Few (2004). The dashboard focusses on the compression of important facts and figures on one single screen providing decision-makers with an easier way to explore insights and scenarios. The ability to receive, process and analyses information can be increased by the use of visual applications. The dashboard aims to support business in operational risk management based on supply chain visibility going into the CASSANDRA data pipeline and providing visibility data to authorities through the Data Capture Interface. The dashboard allows to reducing costs and error improving the supply chain performance of shippers, freight forwarders, stripping centers, stevedores, hubs etc.


Page | 12

Figure 4 – Business dashboard developed for Spain-Egy pt trade lane

Figure 5 – Business dashboard developed for Portugal trade lane


Page | 13

3 Approach/methodology

3.1 Living Labs approach

The aforementioned data pipeline and Risk Based Approach concepts introduced by the CASSANDRA project are demonstrated following the Living Lab research methodology. The Living Labs approach goes beyond piloting - research findings are implemented in real environments, in this case in real trade lanes. The experimental setting provides a neutral ground where companies and institutions are usually willing to set aside differences, overcome obstacles, and focus on a creative collaboration to come to innovative solutions. Representative companies, stakeholders and government authorities are involved in the CASSANDRA Living Labs to ensure a real world setting. The CASSANDRA concepts are evaluated in three Living Labs:

- Living Lab 1: Asia – Europe, coordinated by TNO. - Living Lab 2: Europe – USA, coordinated by ISL. - Living Lab 3: Europe – Africa, coordinated by ATOS.

Each Living Lab contains a set of trade lanes. A trade lane is a specific flow of goods from certain origin to certain destination carried out by specific stakeholders. The different trade lanes offer specific circumstances in which the concepts can be demonstrated. This document presents the results of Living Lab 3, which is composed of two trade-lanes:

- Trade Lane 1: the Spain-Egypt trade lane; - Trade Lane 2: the Portugal trade lane.

A Living Lab is defined as a “gathering of public-private partnerships in which businesses, researchers, authorities, and citizens work together for the creation, validation, and test of new services, business ideas, markets, and technologies in real-life contexts”. 1 Continuity, openness and empowerment of the actors are three of the key principles that Bergvall-Kåreborn et al. (2009) identified with respect to Living Labs. To implement the right concepts in each Living Lab and to coordinate the whole process properly, a short Living Lab approach handbook was written for the CASSANDRA Living Labs. The handbook consists of four steps. This handbook included the following steps, which will be described in more detail in the following sections:

Figure 6: 4 Steps of the Living Lab Handbook

The activities in the preparation stage needed to determine how the Cassandra concepts, developed in WP200 and WP300, could be translated and applied to the specific Living Lab trade lane. The exact implementation of the concepts will be very trade lane specific although the evaluation work package describes the end benefit of the use cases in generic terms.

1 Bergvall-Kåreborn, B., M. Holst, and A. Ståhlbröst, Concept Design with a Living Lab Approach, in 42nd Hawaii International Conference on System Sciences (HICSS)2009.

1. Preparation

2. Technical realisation

3. Risk assessment

4. Pilot and evaluation


Page | 14

3.1.1 Preparation

The goal of the preparation stage was: To define who will be involved in what way and give input to possibilities for a Cassandra technical solution. For this stage, five activities were prescribed:

Figure 7: Preparation stage of the LL

To set-up a demonstration and at the same time get a good understanding of the Cassandra concepts that can be implemented, the trade lanes must be selected and described in detail. The trade lanes were chosen in close cooperation with the two freight forwarders that are part of the consortium and are participants in this Living Lab. The freight forwarders had to identify trade lanes that would include cooperating customers and partners, as permission from these parties was essential when using their data. An important part is the cooperation of actors in the supply chain that were outside the consortium, as innovations cross into various process steps and thereby can affect these actors as well. The entire supply chain is effected and being tested within a living lab. This includes suppliers, freight forwarders, customs officials, and end customers or consignees. The primary actors were the signed partners in the project. However, contacts must also be made with other parties involved to determine cooperation and feasibility of implementing concepts within the living lab. Where needed, an informed consent letter was signed to guarantee data confidentiality in the project and get official consent. An example of the letter of consent can be found in deliverable D9.5 ‘Ethics report’. An assessment of data requirements and availability was needed to make sure that the trade lane had all the necessary partners involved/committed, and would thus be able to capture a sufficient set of data elements to test the Cassandra concepts. It was accepted upfront that it would be unlikely to capture all data elements in the pipeline in any of the trade lanes.

3.1.2 Technical realisation The goal of the technical realisation stage was: To define how the Cassandra technical solution will look for the trade lane, build the technical solution, release and maintain. For this stage, four activities were prescribed:

Figure 8: Technical realisation stage of the LL Han dbook

The design of the pipeline needed to fit with the as-is architecture in each trade lane as was mentioned earlier, but also the various pipeline configurations that are possible needed to be

1. Preparation

1a) Identifying trade lanes

1b) Commitment of external parties

1c) Involvement of authorities

1d) IT mapping

1e) Data requirements


3. Risk assessment


1. Preparation


2a) Design pipeline solution

2b) Build pipeline solution

2c) Going ‘live’

2d) Continuous adaptation (based on evaluation)

3. Risk assessment



Page | 15

reflected in the Living Lab as a whole. As soon as the configuration was chosen, detailed designs could be created that specified how the pipeline would be developed exactly. In doing this, choices needed to be made for the phasing of the solutions or for the data capture.

3.1.3 Risk assessment

The goal of the risk assessment stage was: To investigate the risk assessment methodology in business and align this with assessment of authorities, design a new methodology for both business and authority, implement and maintain. For this stage, five activities were prescribed:

Figure 9: Risk assessment stage of the LL Handbook

3.1.4 Pilot and evaluation

The goal of the pilot and evaluation stage was: To identify business opportunities and improvements, in order to implement and evaluate them. For this stage, four activities were prescribed:

Figure 10: Pilot and evaluation stage of the LL Hand book

The activities in this stage were executed, where possible and needed, together with WP500. This resulted in an overview of possible use cases that described clear practical benefits for the participants. Based on these and various evaluation sessions during the pilot phase, some additional requirements were identified and implemented. These could include improvements for the technical realisation and for the control measures. Also performance issues were solved. In the next section, the actual process followed in Living Lab 3 is described.

3.2 Living Labs 3 process

In line with the overall approach, the organization of Living Lab 3 has been split up into four stages:

1. Preparation; 2. Technical realization; 3. Risk assessment; 4. Pilot and evaluation.

1. Preparation


3. Risk assessment

3a) Risk assessment of businesses (RBSCM)

3b) Piggy backing (RBGS)

3c) Design pipeline-enabling control measures

3d) Implement control measures

3e) Continuous adaptation, if needed


1. Preparation


3. Risk assessment


4a) Identify business opportunities / models

4b) Identify requirements from 4a

4c) Identify requirements from 2d and 3e

4d) Demonstrate

4e) Continuous loop


Page | 16

Stage 1: Preparation Stage 1 comprised the following phases.

a) Identify trade lanes Trade Lane 1: Spain – Egypt. The first trade lane identified was: Product type Textile FCL/LCL FCL and LCL Applicable Incoterm FOB (Damietta/Alexandria) Estimated volume (containers /yr) About 540 TEU/yr The parties involved were: Oxylane/Decathlon as shipper and consignee; Hapag-Lloyd as shipping line and carrier agent, Schenker as forwarder and terminal operator, and S.L. as stevedore. From the Egypt side Oxylane Egypt and GAC Logistics were involved. Oxylane withdrew the project in November 2012 because they were not operating the routes Egypt-Alexandria/Egypt-Damietta to Spain-Barcelona anymore. Portic subsequently contacted IFS international forwarding service as a main stakeholder in the trade lane. The information provided by Oxylane allows elaborating on the IT mapping and the requirements. Unexpectedly some of the parties involved announced their withdrawal during the first quarter of 2013. NSCE reacted immediately and they contacted Maersk, DHL, EFS and Aramex. They received a positive response from DHL and EFS (as partner of IFS in Spain). Finally, the identified trade lane was composed of IFS in Spain and EFS in Egypt. The final trade lane was: Product type Clothes FCL/LCL FCL Applicable Incoterm FOB Alexandria Estimated volume (containers /yr) Unk Trade Lane 2: Portugal – Egypt. The Portugal trade lane was initially planned with Cape Verde. After several meetings and contacts this option was abandoned due to administrative and financial problems. APSS then ascertained the support of AICEP (Trade & Investment Agency) in Portugal, Morocco and Turkey in order to reach Moroccan authorities. The project was presented to the Administration des Douanes et Impôts Indirects, Agence Nationale des Ports, Somaport, and Tarros. Despite explicit expression of interest from Moroccan participants the bureaucracy made this option unviable. During the past year, APSS (Administração dos portos de Setubal e Sesimbra) had to deal with a merger process of different administrations (Lisbon, Setubal and Port Administration), further complicating setting-up the trade lane. Useful contacts were established at Sadoport (Terminal) and Tarros (Logistic services) and it was agreed to use these contacts for the Portugal trade lane to test the implementation of the Cassandra business dashboard developed by GMV and the interface for the Port Community System (PCS) Setubal. The Portuguese trade lane also demonstrated the Data Security Framework.

b) Commitment of parties and involvement of authorities


Page | 17

The partners in the Living Lab APSS, GMV, Atos, Portic and NSCE have maintained constant contact with diverse stakeholders in order to set up a consistent trade lane. As explained before, Portic managed the relationship with AEAT and Autoridad Portuaria de Barcelona. In April 2012 a workshop was held in Barcelona at Portic premises where the project was presented to Spanish authorities, getting their support. Regarding the stakeholders, Portic and Atos met with Oxylane on several occasions in 2012 and telcos have been held with IFS in that year. Most of the parties involved have signed Letters of Intent. However, despite their interest in the project some of them have withdrawn from the project for different reasons. NSCE from the Egyptian side has organized presentations and workshops with different stakeholders (Aramex, GAC, DHL and IFS) and has established contact with Egyptian authorities (Ministry of Foreign Trade) and other stakeholders such as Chambers of Commerce. Finally the Spain-Egypt trade lane was formed with IFS (freight forwarder) in Spain and EFS (freight forwarder) in Egypt. Contact with authorities was established in a workshop in Barcelona with Aduana de Barcelona, Puerto de Barcelona and IFS. This workshop took place on the 15th of April 2014 to show the results of the project. GMV and APSS organized workshops and established contact with stakeholders and authorities from Cape Verde, Morocco and Turkey. Although in many occasions they have secured the explicit interest of authorities and stakeholders in participating in the project, concrete and practical commitment was not achieved.

c) IT mapping After analyzing the existing supply chain IT in both trade lanes, the maturity level objective of each trade lane was defined and the specific data pipeline was designed. The IT system analysed comprised the IT system of the Forwarders, the PCS in the case of Portic and APSS as well as the systems used by the authorities. These configurations are explained in detail in Sections 4 Living Lab Iberia-Africa: the Spain-Egypt trade lane. The configuration of the Portugal trade lane is defined in 5 Living Lab Iberia-Africa: the Portugal-Egypt trade lane. It was remarkable that in the case of some countries such as Egypt some of the documentation is produced just in paper form. The connection to the Data Capture is made through a dashboard instance which not only allows them to connect to data capture but also represents a step forward in the computerisation of their systems.

d) Requirements Once the trade lanes were identified, stakeholders, industry and authorities were involved and IT systems were analysed, the following step was to determine the key data elements, where the data was available during the process and which documents were able to provide those pieces of information. This was the so-called data mapping and is further explained in Section 4.1.1 (As-Is situation).

Stage 2: Technical realization This stage aimed to build and adapt the CASSANDRA technical solution to the Living Lab 3. This phase started on October 2012 with the definition of data capture solutions. The goal of Stage 2 was to define the adaptation of the CASSANDRA technical solutions to LL3 as well as to define the development, release and maintenance of this adaptation. During the fourth quarter of 2012 and first quarter of 2013, WP3 discussed how the DC interface should be defined. All participants in the LLs were involved, specifically Atos, Portic and GMV provided their input related to which functions, messages and events should manage the


Page | 18

CASSANDRA Data Capture interface. The interface is the main component to allow authorities to capture data from the pipeline.

a) Design pipeline solution Based on the requirements for LL3 the pipeline solution was designed. This included a comparison between the current IT systems and the required set up of the pipeline. Based on this comparison, white spots were identified and addressed. The data pipeline is a federated solution that makes use of existing systems as much as possible. Its design thus results in an overview of the entire data pipeline, the parts of that pipeline that are realized in existing systems, and those interfaces that need to be developed to complete the pipeline. The result of this step was the functional specifications of the technical components that need to be built. Available data standards (e.g. WCO, UN/CEFACT, etc.) were taken into account as well. In parallel of the definition and design of the Data Capture interface and the trade lane pipeline, the design of the IT systems involved in each trade lane of LL3 was defined. In summary, the most relevant systems involved in the trade lanes are: forwarder systems (IFS, EFS), Port Community Systems (Portic), Authorities systems (Setubal), and the appropriate dashboards to visualize the data captured for business. In the design phase, a mock-up for the dashboard was specified.

b) Build pipeline solution Next, the designed solution was built. Again, this required a close collaboration between the parties in LL3, technical development partners (GMV, Atos and Portic), and suppliers of other or additional components to be used in the solution. After the first specification of the Data capture interface delivered in March 2013, the partners involved in the development agreed how to implement it. The actors involved agreed to interchange messages with a set of headers in UN/EDIFACT and a payload using UN/CEFACT using the IFTMCS standard for documents. The Data Capture implementation exposes a REST interface to interchange the messages.

c) Going ‘live’ By the second half of 2013, there was a fully operational implementation of the Data Capture interface. A first version of the dashboard integrated with the Data Capture (DC) was ready by September 2013.

d) Continuous adaptation. From this first version of the dashboard, a refinement stage began. It was necessary to make the dashboard more user-friendly and to improve some of its functionalities. By February 2014, the dashboard was ready to be used and it was deployed in a real environment to test it within a real data flow.

Stage 3: risk management Stage 3 started in 2013 with the identification of risks in each trade lane. The trade lane Egypt-Spain held conference calls with the stakeholders in order to define and analyse the risks in the supply chain. The figure below shows the first approach of those identified risks. A set of risks as well as the detection process were identified and described.


Page | 19

Figure 11 – Risk identification. Trade lane Egypt-Sp ain

3.3 Data Collection Procedures

During the phase of the identification of data, Portic and Atos had a meeting with Oxylane in order to identify the key data, data sources and data ownership. Based on the process flow (Figure 19-. Detailed process flow of the trade lane Alexandria-Barcelona) 60 involved documents were identified as shown in the figure below.


Page | 20

Figure 12 – involved documents

Available Nice to have Unnecessary Samples of those documents were collected for the selected trade lanes. The sources of these documents were both Oxylane/Decathlon (EUR1, Packing list, commercial invoice, Freight Forwarder Sea Waybill, Import Customs declaration) and the Portic-PCS platform. The information provided by Oxylane/Decathlon as well as the vision and requirements proved to be aligned with the needs of the final participants in the Living Lab (IFS and EFS).

3.4 Data Analysis Procedures

The following step consisted of mapping data elements present in the identified documents to:

- Identify data ownership; - Identify data availability.

This exercise aimed to:

- Search for Data Elements where sharing or early mobilization is profitable for the trade lane partners;

- Identify trustable Consignors and Consignees for Customs; - Provide Customs with the information layers they are interested in:

� Physical Layer (information about the logistics) � Actors (seller, buyer, who has the custody of which goods at that

moment, liability, …)


Page | 21

� The goods (contract, purchase order, shipping order, all the information related to the goods themselves, …)

� Supply Chain finance (payments, insurance, …)

The data elements available in each document were listed as shown in the figure below.

Figure 13 – Data available in each document

This is mainly based on the information required for the Single Customs Document which supports the Import Customs Declaration. The data mapping result is shown in the following table:

Figure 14 – Data Mapping

The data elements were classified by groups: parties, places, dates, reference documents, goods, monetary, measures and conveyance. The template shows the data element name, if there is an available example, type of document, who is the sender and who is the recipient, which of these data elements will be present on the dashboard and in which moment of the process they are delivered.


Page | 22

4 Living Lab Iberia-Africa: the Spain-Egypt trade lane The Living Lab Europe – Africa comprises two main trade lanes. The first one involves Spain and Egypt, specifically Barcelona and Alexandria. In the following section detailed information about components, stakeholders, IT and data mapping, risk analysis and configuration is provided.

4.1.1 As-Is situation

1. Selection and mapping of trade lane in layered m odel

Trade lane 1: LL3 –Alexandria (Egypt) to Barcelona (Spain)

Figure 15 – LL3 trade lane for Alexandria - Barcelo na, overview

Figure 16 – LL3 trade lane for Alexandria - Barcelo na, pipeline configuration

The characteristics of the container flow on this trade lane are summarized in the table below. Product type Clothes FCL/LCL FCL Applicable Incoterm FOB Alexandria Estimated volume (containers /yr) Unk

Table 1 – LL3 Trade lane for Alexandria-Barcelona, characteristics

2. Parties/stakeholders involved Involved parties and their project involvement for this trade lane are summarized in the table below. Involved Consortium partners

External parties (contacted)

External parties of interest

PORTIC IFS AEAT (Dpto. Aduanas España)

NSCE EFS Autoridad portuaria de Barcelona

ATOS Table 2 – LL3 trade lane for Alexandria-Barcelona, involved parties


Page | 23

3. Mapping of current IT systems The mapping of current IT systems in the Spain-Egypt trade lane is shown in the figure below.

Figure 17 – IT Map of LL3, trade lane Alexandria-Ba rcelona

The most relevant systems involved in the trade lane are: • Forwarder systems

o IT system for EFS (Egypt) o IT system for IFS (Spain)

• Port Community Systems o PCS Barcelona (Portic)

• Authorities o Dashboard Spanish authorities o Dashboard Egyptian authorities

One of the key issues identified in this step, was that at the Egyptian part of the work and customs procedure are done by paper. So we identified the requirement of the digitalization of the information related to different shipments done by EFS between Alexandria and Barcelona. This digitalization is done through the development of a web-application, were the Egyptian data is captured, and made accessible through the Data Capture interface for the authorities involved in the trade lane (both Spanish & Egyptian). 4. Data mapping One of the first steps in the data mapping for the trade lane between Egypt and Spain was the detailed identification of the shipment processes involved. This definition of the process allowed us to identify which parties are involved in which step of the process for a further mapping with the documents and data generated in each of the sub-process steps as shown in Figure 18 - Process detail in trade lane Egypt – Spain


Page | 24

Figure 18 - Process detail in trade lane Egypt – Spai n

Using this information a detailed process flow was defined. This work was done with Oxylane and was validated with the new shippers and freight forwarders involved in the Egypt – Spain trade lane. In this detailed process, the flow and interactions between the shippers, freight forwarders, consignee, carriers, terminals and customs were included. (Figure 19-. Detailed process flow of the trade lane Alexandria-Barcelona)

Figure 19-. Detailed process flow of the trade lane Alexandria-Barcelona


Page | 25

Based on the already mentioned Process Flow, we identified a set of around 60 involved documents, of which some are relevant for the project and some are not. Samples of those documents were collected samples from the involved parties:

• Purchase Order • Shipment • Carrier bill of Lading • Other documents can be attached but not input:

o Certificate of origin o Customs clearance (or declaration) o Invoices (all kind) o Packing list o Transport documents (Release Order, Transport Order, etc.) o Other desired documents (EUR1, ENS, manifest, House BL, etc.)

Other documents were retrieved from the PORTIC PCS platform. In the trade lane, we based the data mapping on an Event driven Pipeline fed with the Data Elements that were perceived to be relevant for Customs and the Clearance process. That approach fully matches the vision in LL3 Spain-Egypt, and the pillars on which the solution is based:

• Key Shipment Events identification • Data Elements ownership and availability for each one of the Events • Events which will allow Shipment Unique Identification • Events which will trigger Data feeding to the Pipeline • Events which will trigger automated declarations to Customs • Events and Data Elements to be shown at the Dashboards • Events which will trigger automated Data Elements reporting at Export stage to

Import Customs The following trade lane events were identified based on the previous process flow. The first table reflects the events on the export side, and the second table for the import side events.

Event Id. Stage Event Description

EE01 Order Purchase Order Raised

EE02 Shipment Shipment Notice Filed

EE03 Export Maritime Booking Confirmed

EE04 Export Declaration Export Declaration Lodged

EE05 Export Declaration EUR1 Certificate Raised

EE06 Export Declaration ENS Declaration Lodged

EE07 Export Shipment Stuffed

EE08 Shipment Commercially Invoiced

EE09 Shipment Shipment Confirmed

EE10 Export B/L Confirmed

EE11 Export Loaded on Board

EE12 Export Vessel Sailed


Page | 26

Table 3 - Export events in trade lane Egypt-Spain

Event Id. Stage Event Description

IE01 Import Declaration Summary Declaration Lodged

IE02 Import Vessel Arrived

IE03 Import Discharged from Vessel

IE04 Import Procedures Transit Raised (Change of Location)

IE05 Import Declaration Import Declaration Lodged

IE06 Import Shipment Stripped Table 4 - Import events in trade lane Egypt-Spain

These events were located in the trade lane configuration as shown in the figure below.

Figure 20 - Events trade lane Alexandria - Barcelona

The identification of the key data elements required in the project was done taking into account the elements identified in WP2 for the RBA and the documents identified in the previous process flow. After analysing the elements needed for the RBA it was concluded that they are fully based on the information required for the Single Customs Document, which also supports the Import Customs declaration. Additional data elements of interest for Spanish Customs and their risk analysis procedures were also identified especially those available at early Export stages. The next table shows an example; every event identified has associated a set of documents, data and parties involved.


Page | 27

Event EE01 – Purchase Order Raised

Main Data Elements Buyer Id and Details Seller Id and Details Purchase Order Id. Purchase Order Item Id. Purchase Order Item Details Incoterms

Data feeding to the Pipeline None (Shipment is still not confirmed at this point)

Cassandra Products triggered None Table 5 - Data mapping for Event EE01

5. Mapping of current risk assessment The methodology to implement the RBA defined in the RBA Handbook has been mostly followed in the LL3.

Figure 21 - Schematic overview

The RBA handbook details the methodology used to obtain the expected results (Figure 21 - Schematic overview). This handbook addresses risk management on three different levels:

- The Strategic level - The Tactical level - The Operational level

The RBA handbook was followed up to the phase of identification, description and detection of risks. These risks were monitored to evaluate to what extend the use of the dashboard helps to reduce the risks or not. The characteristics of the living lab determined a business approach in the identification of risks due the absence of authorities involved in the trade lane. The table below shows the risks identified, how they can be detected and if the dashboard implementation has allowed business parties to mitigate them.


Page | 28

Nº Risk Description Detection Can be checked

1 Purchase Order time is up

The Purchase Order fix a calendar to dispatch the goods. The end date is over.

The status of the PO is active and the current date is greater than end of delivery

Yes

2 The Shippment arrive late at destination Port

The ETA of the Shippment is overdue. Almost one of the container is not at destination port.

The ETA of the vessel has changed or it is overdue

Yes

3 The Shippment / Container has been loaded in another vessel

The Container has been loaded in another vessel

The content is not present in the expected loading list or the manifest

No

4 Documentation is missing

The Requiered Documents are missing. Invoice, EUR, etc

The required documents are not present.

Yes

5 Mismatch Information

Relevant infomation declared in Origin do not match with the infomration declared at destination. ( Value, HS, Seal, Weight)

The information is checkd against the manifest.

No

6 Physical Inspection An unexpected Inspection came across

A physcial inspection has been requested.

No

7 Physical Inspection The commodity may be subject to inspection.

Based on commodity code. For express shipments is recommended to ship them by plane

Yes

8 Packing List Content Discrepency

The content of the container does not match with the packing list

Yes

9 Inland trasnsportation has still not been performed

Yes

10 The importer does not reclaim the goods at destination.

No

11 OverWeight The weight of the goods exceed the Maximun weight allowed by the transportation mode.

There is no Max.Weight field but it can be deduced based on experience

12 Dangerous Goods permits

In case of Dangerous Goods permits must be presented.

Yes

13 The container has not been unloaded

The vessel calls at the destination port but the container loaded has not been unloaded

Yes

14 The Empty Equipment has not been returned

After the exit of the container at the destination port has not been returned to the carrier

Yes


Page | 29

15 Unstuffing delay The container has arrived but is not possible to unstuff as estimated (customs, UAR, PIF)

No

16 Strike in any point No

17 Unstuffing delay The container has arrived but is not possible to unstuff as estimated (customs, UAR, PIF)

No

Table 6 – Risks Analysis

The Risk Based Approach developed in the project was applied, with the following exceptions:

• The freight forwarder met with the different stakeholders in order to identify the risk domains, but did not meet with customs, as the scope of their Living Lab was to create a business dashboard and thus was not customs-oriented.

• No additional method has been designed for monitoring processes that may lead to risk events, as the business dashboard has been considered suitable for monitoring.

• The team validating the model has been the same team involved in creating and testing the business dashboard, with no multi-disciplinary experts joining the discussion. This has been so as the scope of Barcelona-Egypt trade lane was of small scale (focusing only on one client with two shipments per week). As a conclusion, the involvement of a bigger team at this scale was considered unjustified.

6. Mapping of interactions with government The data mapping focused on searching for Data Elements in situations in which sharing or early mobilization is profitable for the trade lane partners, for authorities, and for business parties. The data mapping as well as the identification of the data’s ownership and availability aims to:

• Search for Data Elements where sharing or early mobilization is profitable for the trade lane partners

• Identify trustable Consignors and Consignees for Customs • Provide Customs with the information layers they are interested in:

o Physical Layer (information about the logistics) o Actors (seller, buyer, who has the custody of which goods at that moment,

liability, …)

CASSANDRA enables parties involved to retrieve high quality data from the original data source from the very beginning of the process. The availability of trusted data allow business parties improve their current risk analysis and customs processes enhancing the security of the trade lane. Besides, authorities and business parties can benefit from the CASSANDRA pipeline and the availability of information to generate new applications that are useful for business and authorities’ purposes. Some examples are provided below:


Page | 30

• Automated Export Customs Document filing based on Pipeline data: o Export SAD Single Administrative Document o ENS Entry Summary Declaration o EUR1 Movement / Origin Certificate

• Automated Import Customs Document filing: o Import Summary Declaration o Import ST (Simplified Transist) o Import SAD - Customs Consumption Clearance

4.1.2 To-Be situation: Demonstration plan

The main use cases demonstrated in this trade lane scenario are depicted in the following figure.

Figure 22 – Use Cases

The following tables provide to the reader detailed information about the three use cases proved during the Living Lab: Use Case ID CAS-C-1 Use Case Name Export source = Import source

Objective Source data for export declaration is also used for making ENS and import declarations

Table 7 – Use Case CAS-C-1

Use Case ID CAS-C-2


Page | 31

Use Case Name ENS Multiple filing

Objective ENS declaration is filed by multiple parties that provide the best possible information quality for the specific data boxes


Use Case ID CAS-C-3 Use Case Name Digital document based visibility

Objective Content of all exchanged documents is accessible in one integrated pipeline solution


For the living lab implementation and demonstration, we focussed on:

• PCS simulation for Egypt • DC for Egypt and BNC • Dashboard for Egypt and BCN

1. Overview of the pipe line configuration: As stated in the previous section an instance of the dashboard was implemented on both sides of the trade-lane (Spain and Egypt) allowing them to access the information and data in the pipeline and manage their own purchase orders. For the different specific IT systems of the parties involved in the trade lane a specific implementation of the Data Capture interface is implemented.

Figure 23: IT systems and DC interface in the trade lane Alexandria - Barcelona

Based on this configuration, we will provide access to the import side of the trade lane (Barcelona) to check data as soon as EFS has made them available. The different and


Page | 32

interested parties (both authorities and the Forwarder in the destination (EFS)) will be able to capture the data, and improve the quality of the information from the origin to perform the risk based analysis in the different use cases identified. In the trade lane we proposed the following design of the pipeline based on several core components: • Scenario overview

o Transmission of the different events between two CASSANDRA nodes. o Feed Dashboards with real information

• Data Capture Communication Layer implementation (DC-CML)

o Provide Interfaces for event and document submission. Based on the Data Capture interface done in WP3.

o Agreement about the interchanged messages format regarding headers and payload.

• Data Capture Business Communication Layer implementation (DC-BCL) o Definition of events / documents for the BCL as described in the WP3 o PCS can implement the integration of the existing systems and communication with

the new interface reducing the gap o PCS can act as a “hub” on behalf of the trading partner and reuse the data.

• Business Dashboard. Despite of the focus on the business dashboard the generated

information would be also used by customs. 2. IT System implementation in the Egypt scenario: The Egyptian party does not currently have a digital PCS. All the operations that take place are registered manually on paper. In this living lab, the aim is to address the problem by developing an IT system in which the information can be introduced, processed and exposed to the rest of the CASSANDRA partners. The idea is to facilitate a template, which will be in a web form, containing all the required fields that take sides in the registration of a purchase order. This process covers all the fields related to the purchase order (bill of lading, equipment, etc). The figure below shows a mock-up of the submission form:


Page | 33

Figure 24 - Purchase Order Form

3. Data capture implementation at CML As explained in the previous subsection, the Egypt actor does not have a digital PCS so, after providing one which is fed by means of web forms, both PCSs (Spain and Egypt) will be connected. The Data Capture will exchange messages with information related to the different PCS’s purchase orders. A CASSANDRA Message (as explained in the DC specification layer CML) maps straight onto so called a Standard Business Document (SBDH) in the UN/EDIFACT standard for the message’s headers. This setup of the CASSANDRA message allows putting any structure into the payload. It is convenient to use other standard payload syntax, such as the GS1 XML (UN/CEFACT) payload.


Page | 34

Figure 25 - DC messages structure

For the Living Lab implementation it was agreed that all documents which are part of the message follow the IFTMCS standard and will contain the fields explained in the Subsection 4.1.2.4. Thus, the actors involved agreed to interchange messages with a set of headers in UN/EDIFACT and a payload using UN/CEFACT which documents are in IFTMCS standard. Other standards can be adopted and implemented under new agreements. The DC specification remains independent of different technologies and standards. For the Data Capture demands, the interface should have a pull mechanism to supply logistic data to the dashboard, especially the Egypt PCS- and monitoring systems. The connection to the CML is a generic call in which identifiers of different identifier authorities can be used, as described below. Get Logistic Data can thus be summarized as follows:

URL https://[CASSANDRAPartnerDomain]/rest/message/{message_id}

Method GET

Returns 200 OK& XML (logistic/data)

401 Unauthorized

404 Not Found

Table 10 – DC Transport and Routing Layer

In addition, the messages are composed using a standard HTTP message protocol (Transport Routing layer) with XML documents and REST protocol verbs (GET). Actually, for security reasons HTPPS will be mandatory. 4. Standard data model messages We took as reference the standard for Instruction contract status message of the United Nations, the message IFTMCS, adapting the Edifact format to xml language. We have thus developed an xsd that contains the information requirements detected in WP3 to identify the relevant information related to the following documents and its belonging


Page | 35

entities in order to build the main backbone in FCL/FCL Shipments, as a future option the message can be adjusted to be used on other kind of shipments but this has not been our focus. Documents:

- Purchase Order - Shipment - Bill of lading

Entities:

- Commodities - Equipments - Charges - Attachments (out of the message)

Major nodes in the Schema Message Definition not entities themselves:

- Charges: input comes from all relevant charges, fines, taxes etc on a shipment, bill of lading or equipment that can help on further formalities.

- StatusOrEvents: Relevant info related to a shipment or equipment (status or actual location) that can trigger a risk analysis.

Some web services developed by Portic have been integrated in order to provide additional information to the main documents, mainly events and status. The dashboard can access to the PORTIC PCS to retrieve the current events of each of the purchase orders. The dashboard can obtain the purchase order’s status running an algorithm according to these events.

5. Customs and business dashboards The operators are the main actors who will take advantage of the dashboard implemented in the Living Lab. They can access the information stored in the systems through this visual tool, which uses the Data Pipeline and the connected Data Capture interfaces to retrieve information from the systems. There are two parties involved, Barcelona PCS and Egypt, in the Living Lab. For this reason, two instances of the dashboard have been deployed, one for each party. Each instance of the dashboard contains its own information. This information concerns to different purchase orders and all the information related to them. From the dashboard, the users will have the possibility of retrieving information of a purchase order from another partner through the pipeline. The Data Capture plays a very important role in the information collecting process. Each dashboard is connected to the pipeline and asks for specific information, for example a purchase order, if needed. The pipeline will access the correct Data Capture and retrieve the information of the requested purchase order showing it to the user. The Data Capture is in charge of recovering the requested information. The pipeline is equipped with a DC discovery service which determines which DC owns the information requested. The next figures show the whole functionality of the dashboards.


Page | 36

Figure 26.Login

The login page requires a user name and a password to get into the application. A similar screen is provided to sign up in the system and create a new entity/user to use it. The following screenshot (Figure 27 - Main Information Page) shows the general information page. Once a user is logged on the system shows the purchase orders available in the system for the current user. The dashboard allows the user to use different kinds of filters or do searches within the set of purchase orders listed below. The main page provides functionality named “Get Remote PO” which will show a dialog window to enter a Purchase Order Identifier, once the identifier has been entered the dashboard retrieve all the information regarding to the purchase order requested.


Page | 37

Figure 27 - Main Information Page The user can access to detailed local purchase order information:

Figure 28 - Purchase Order Detailed View

Figure 28 - Purchase Order Detailed View shows all the attributes related to a specific purchase order such as shipments, bills of lading, equipment and charges, as well as a


Page | 38

functionality which allows the user to provide and upload documents to the system (e.g. contracts between parties). When user retrieves information from the pipeline, gets a remote purchase order, all the information related to this PO is shown in the same way as in the figure below.

Figure 29.Purchase Order related information

Through this detailed view, stakeholders can navigate through the different sections regarding the selected purchase order and consult the information, for example the detailed information regarding the equipment or the bill of lading. This information can be edited by the authorised user. The user can submit a new purchase order using the web form or edit any information related to the purchase order or associated information. See figure below:


Page | 39

Figure 30 - Purchase Order Edition

4.1.3 During pilot phase

At this point, the dashboard is fully implemented and it is running in a real environment between Barcelona and Egypt. All the expected functionalities have been introduced such as the connection with the Portic Systems to obtain information related to the incoming and outcoming purchase orders. The existing functionalities were improved and many aspects were refined in order to provide the final users a better experience using the dashboard, such as the integration with the Portic PCS through the different web services or the attachment of documents related to the purchase order. A mechanism to upload specific documents has also been developed. This is an added value to the project because nowadays there is not a tool that encloses all these functionalities. Regarding the implementation all stakeholders involved in the trade lane indicated that there was a smooth implementation of the RBA and no major challenge was faced. Indeed, the users were not reluctant to using a new dashboard, as it was built upon the Port Community System already in place and did not represent a very significant change in their routines. Therefore no change management was involved when implementing the RBA. The pilot phase for the pipeline and business dashboard in the Spain-Egypt trade lane started in March 2014 when the final version of both the data capture tool and the business dashboard became available. The demonstration will last until the end of the project in May 2014. The shipments that will be monitored are one every two weeks from Spain to Egypt and one every week from Egypt to Spain.

4.1.4 Use by parties and benefits

The 15th April, 2014 was held in Barcelona a workshop involving Aduana Española (Spanish Custom), Autoridad del Puerto de Barcelona (Barcelona Port Authority) and IFS with the objective of gathering the feedback about CASSANDRA project both from the point of view of the authorities and business. The workshop included a general overview of the Cassandra project to put the attendees in context, a presentation of the Customs Dashboard developed by IBM and Intrasoft, a real


Page | 40

demo of the Bossiness dashboard implemented in LL3 by Atos and Portic and the experience from ILS using the dashboard. An overview of how the risks had been faced in the living lab was carried out by ZLC. Spanish customs and Barcelona Port Authority expressed their interest on the Customs Dashboard and asked questions regarding the scope of the dashboard (if it covers both import-export lines), who is the responsible party for introducing data and what is exactly the data that is shared. They assess the tool as extremely useful but they express their concerns on how the information get from the dashboard could actually reinforce their own risk processes. The advantages of the business dashboard were analysed by IFS. They remarked as proved benefits to get the information in advance which allows them to initiate processes, that with the current systems, are not possible to initiate, for instance prepare the documentation for the import clearance or to apply their risk management processes in advance. The security of the information is another strong point for IFS so CASSANDRA guarantees the reliability of the data. The benefits reported by stakeholders can be summarised in the table below: Organization / role Interests Advantages of CASSANDRA

Forwarder Improved efficiency of Customs process, possibilities for pre-clearance and green lanes

Improved agility to respond to disruptions during transport thanks to the access to immediate information.

Administrative benefits and reduction of costs

Reduction of mistakes and frauds thanks to a more accurate information

PCS Improved traceability

Improved goods and container tracking

Improved efficiency of risk forecasting

Improved user experience

Figure 31 – Benefits for the parties

4.1.5 Reflection

The Alexandria-Barcelona trade lane has overcome several difficulties not only organizational problems but also technical complexities. The special characteristics of third countries as Egypt are quite remarkable. The bureaucracy and the delicate political situation in the country have made the organization of a workshop with the presence of European partners inadvisable. However NSCE has carried out excellent work presenting and promoting CASSANDRA in the country. The absence of freight forwarders as part of the consortium has been more difficult in terms of the involvement of the stakeholders. In that sense the work of Portic and NSCE has been excellent in providing contacts and acting as facilitators. Even though the obstacles to engage stakeholders and authorities from Africa and the difficulties derived from their IT systems or even the lack of IT system at all, the involvement of these countries is an important opportunity of investment to improve the governmental and business processes to improve import/export security, reducing risks as corruption derived


Page | 41

from a low management capabilities due to obsolete systems. Engaging these countries and working in this direction will improve commercial relationships and international trade. Within the CASSANDRA project it is of the utmost importance to reach consensus on several issues that are related to the IT development of the pipeline that creates more visibility within the supply chain. During this process and within the collaboration with WP300, it was very difficult to reach an agreement about the characteristics that the Data Capture interface should provide (main interface from the CASSANDRA architecture to be implemented in the Living Labs. The initial discussions were more focused on non-technical discussions, because of the different views from the authorities and private sector about what information should be available to be captured. After that, the technical difficulties were focused on the agreement of the technical specification of the data capture, which type of standards should be used to share data and how to provide notifications of the availability of the information in the different parts of the pipeline. Regarding the work related to the Data mapping and IT mapping it was done successfully thanks to the good collaboration of the different parties involved. The final version of the dashboard was the result of a refine process exploring functionalities as user’s control and improving the usability and user’s experience and in particular the response time. The time to put in practice the Cassandra Business Dashboard in the Barcelona-Egypt trade lane has been very tight. The living lab lasted two months with one shipment every two weeks from Spain to Egypt and one every week from Egypt to Spain. Despite the short duration of the living lab and the reduce number of shipments it has been enough to demonstrate the use cases satisfactorily. Regarding the Risk Based Approach the methodology has been useful to discuss, define and agree a set of risks to be analysed. Most of them are mitigated just with the use of the dashboard because the information is reliable, accurate and early accessible. The lack of authorities in the living lab has focussed the identification of risks on business side. All stakeholders agree that CASSANDRA RBA will only be successful when all customs are tackled (by involving the World Custom Organization). Spanish customs described CASSANDRA system based approach as a step beyond their current risk assessment process (transaction based). IFS expressed their interest in applying CASSANDRA RBA to other trade lanes (e.g. Morocco) as they consider the methodology will potentially imply an improved supply chain performance. The evaluation of the benefits for the Freight Forwarders participating in the living lab has been very positive. They remark at least four main benefits:

• They are able to access to the information with the maximum anticipation and foresight. This allow them to organize the procedures and documentation requested by each shipment in advance (e.g. preclearance procedures)

• Information and data security. The security of information is higher avoiding frauds and errors.

• Optimization of resources. The system reduces administrative, software and system costs. They are able to organize and take advantage of the resources improving the efficiency.

• They receive immediate information improving, among other, the risk analysis before the cargo arrives.

The Living Lab 3 did not have participation of Spanish customs or other authorities as partners in the project, however they have been involved from the very beginning of the project informing them about the progress and findings of the project and gathering their feedback.


Page | 42

During the last workshop held in Barcelona in April, 2014 Spanish customs and Barcelona Port Authority evaluated the business dashboard as very useful considering it a step forward in the supply chain logistics management. Regarding the Authorities dashboard they remark the utility of the information and the reliability of the data, however they still consider that this kind of tool cannot substitute their current risk management tools. The Living Lab 3 has served as proof of concept to demonstrate the objectives initially set up by the project. In the case of Spain-Egypt trade lane the demonstration has been focused on business stakeholders, the data pipeline concept and the use of reliable information to improve risk management by traders has been demonstrated. Going beyond this point requires the participation and involvement of authorities, not only at local level but also at international level (e.g. WCO) to push the Cassandra approach among all stakeholders in the supply chain through new projects and policies. The definition of a consensus to align the different points of view, stakeholders, initiatives and organisations involved has been approached in work package 6 Policy Support, privacy and human issues and network preparation. The contacts established in Egypt and other African countries provide an opportunity for investment and further research that must be taken into account.


Page | 43

5 Living Lab Iberia-Africa: the Portugal-Egypt trade lane The Living Lab Europe – Africa comprises two main trade lanes. This chapter is devoted to the trade lane from Portugal to Egypt, specifically between the Ports of Setubal and Alexandria. In the following section detailed information about components, stakeholders, IT and data mapping, risk analysis and configuration is provided.

5.1.1 As-Is situation 1. Selection and mapping of trade lane

Trade lane 1: Setubal (Portugal) to Alexandria (Egypt)

Figure 32 - Setubal trade lane overview

Characteristics of the container flow on this trade lane are summarized in below table. Product type Paper Pulp / Paper FCL/LCL FCL Applicable Incoterm CIF or delivery at place Estimated volume (containers /yr) About 1500 containers/yr

Figure 33 – Portugal- Egypt trade lane characteristic s

2. Parties/stakeholders involved Involved parties and their project involvement for this trade lane are summarized in the table below. Involved Consortium partners

External parties (contacted)

External parties of interest

APSS (Port of Setubal) Portuguese Customs Shipping Agent (Turkey) Portuguese Paper factory Containers Terminal

(Setubal) - SADOPORT

TARROS Shipping (Portugal, Italy, Turkey, Egypt & Morocco)

Shipping Agent (Portugal) – Orey Shipping

Portuguese Embassy in Egypt

AICEP (Trade & Investment Agency) in Portugal, Morocco Turkey, and Egypt

Table 11 – Portugal- Egypt trade lane, involved par ties

3. Mapping of current IT systems


Page | 44

Figure 34– IT Map of Portugal- Egypt trade lane

The most relevant systems involved in the trade lane are:

• Forwarder systems

o IT system Dispatch Place / (Carrier Agency)

• Port Community Systems

o PCS Setubal Port

• Sea Transporter System o Tarros – Automatic Vessel tracking

• Authorities

o Dashboard Portuguese authorities

All stakeholders needed for a pilot phase were involved;

• The Shipper (Paper factory); • Cargo and shipping agency – O´Neill • The container terminal (Sadoport); • Portuguese Customs; • The sea transport (Tarros); • Carrier Agent; • Buyers; • Agencies for trading promotion;

On the dashboard the source of information came exclusively from the Setubal PCS. The PCS in use at Setubal was developed by a third party company and did not have any API to connect with external systems, excluding the ones demanded by national regulations (e.g. SDS, the Customs IT System). The solution, found to overcome this issue in a less intrusive way, was a creation of several database views with all the relevant data that need to be available in the dashboard. These views were created and managed by APSS. GMV created an ETL (Extract-Transform-Load) that processes the data contained in the views and subsequently transform them in a format accepted by the internal web service. This web


Page | 45

service will be responsible for the storage of the data. Due to this specificity, the ETL was a mechanism created by GMV specifically to be used by APSS and, in order for it to work, the views should not be changed. The rationale behind this constraint is based on the fact that the information/data gathered from those views are the only source which the ETL is capable of accessing. Therefore changes to the views without prior notice may, and indeed are expected to, have a significant impact on the data gathering mechanisms. It is for this reason that the views should not be changed. The platform developed has the openness for receiving data through a web service from any sources that comply with the internal schema definition. This can be done simply by configuring an access token for that particular entity. The access token will be used by the authentication service and for the identification of the data received by that source. On the dashboard the source of information came exclusively from the Setubal PCS. The PCS in use at Setubal was developed by a third party company and did not have any API to connect with external systems, excluding the ones demanded by national regulations (e.g. SDS, the Customs IT System). The solution, found to overcome this issue in a less intrusive way, was a creation of several database views with all the relevant data that need to be available in the dashboard. These views were created and managed by APSS. GMV created an ETL (Extract-Transform-Load) that processes the data contained in the views and subsequently transform them in a format accepted by the internal web service. This web service will be responsible for the storage of the data. Due to this specificity, the ETL was a mechanism created by GMV specifically to be used by APSS and, in order for it to work, the views should not be changed. The rationale behind this constraint is based on the fact that the information/data gathered from those views are the only source which the ETL is capable of accessing. Therefore changes to the views without prior notice may, and indeed are expected to, have a significant impact on the data gathering mechanisms. It is for this reason that the views should not be changed. The platform developed has the openness for receiving data through a web service from any sources that comply with the internal schema definition. This can be done simply by configuring an access token for that particular entity. The access token will be used by the authentication service and for the identification of the data received by that source.

4. Mapping of current risk assessment For the risk assessment, GMV developed an interactive dashboard providing widgets where users have the flexibility and ability to configure their own environment depending on their own needs. Furthermore, some fixed pages were created where the users can expand information in a hierarchical perspective. For instance, from a purchase order it is possible to see the relation with the cargo of that order, the containers related with the cargo and the transports and its legs. All the information has the identification of the source; in this way it is possible to verify any data inconsistencies. Furthermore, and as requested by Portuguese Customs, a web service is available for this governmental entity in order to extract information for their own Risk Assessment. 5. Interactions with government In Portugal several governmental entities are involved in, and sensitive to, the CASSANDRA goals and objectives. We succeeded in achieving several high-level interactions between the Setubal Port Authority and these governmental entities.


Page | 46

The Foreign Ministry services are involved via AICEP (Portuguese foreign commerce agency). The Portuguese Customs have been involved in the project since the early stages of the project participating actively at some meetings. They have been present at the LL Kick-Off Meeting, at the visit to Morocco, and several others with APSS. In terms of the system they do not have an interest in the dashboard. The Portuguese Customs did not accept to share information from their system, but expressed their desire to receive information from the CASSANDRA through a webservice, and to use that data for their own risk assessment. APSS has frequent meetings with all Port community entities and CASSANDRA has been discussed several times. The CASSANDRA project has been discussed with many private and public entities. Different analyses have been done from the security point of view to trade facilitation point of view, passing by the IT integration. One of the major concerns is the involvement of the fraud department of Portuguese Customs, mainly because some of the critical information related to risk assessment and value of goods is located at a confined PCS section. Several presentations were carried out to different Authorities (Maritime Authority, Police, Republican Guard, Customs).

5.1.2 To-Be situation: Demonstration plan

1. Idea and demonstration purpose • Data re-use (export functionality from CASSANDRA) to other systems for

purposes other than their intended use (namely customs). • Data from multiple sources, more accurate information. • Data early in time. • Earlier Pre arrival information, for different entities, such as;

o Terminal; o Authorities;

• Earlier Pre arrival dispatch, for releasing of goods; • Programmable automatic triggered events, for different entities, such as:

o Customs; o Maritime authority; o Port Authority; o Sanitary Authority;

2. How Use Cases fit with the trade lane


Page | 47

Figure 35 – Uses Cases fitting with the trade lane

The below figures demonstrates how Cassandra fits into the existing business processes. The Purchase order and other conditions are agreed between seller and buyer. The Seller nominates an agent to act on his behalf to deal with the entire export process (documentation and procedures). The agent uploads a manifest file with required information to Customs and Port Authority. This manifest file is processed by a third party product and depending on the information contained will be available to SDS (customs systems) or/and JUP (Port Community System). Cassandra will use the PCS as the primary source of information and make existing data available to customs through a web service for their own risk analysis. Portugal as open economy industrial policy focuses on establishing connections among domestic firms and between firms and the world market. Independently of the North Africa country on the other side of the trade lane is clear that supported in some standards we can inject this information in the pipeline to enhance knowledge flows, foster productive innovation and strengthen non-traditional exports 3. Design of pipeline configuration The configuration of the pipeline in the Portugal-Egypt trade lane is shown in Figure 36 – Design of pipeline configuration below.


Page | 48

Figure 36 – Design of pipeline configuration

Due to the lack of stakeholders to provide a list of particular requirements, the data elements available in the dashboards are the ones identified by the UK and Dutch Customs in the D1.2- User requirement report and Business Drivers. Contacts with the Turkish entities occurred in a forum between Portugal and Turkey in Portugal on 6th May 20132. GMV followed up with the contact established during the business forum with more information about the project (brochure and website) and confirmed their availability to schedule a conference call or meeting. After several contacts between Portuguese Partners and Turkish entities, the Turkish option has been abandoned taking into account that Turkey is not in a geographical area of interest for this Living Lab and due to EC regulations. Since the LL configuration changed from Morocco to Turkey and posteriorly to Egypt, stakeholders needed to be re-contacted (shipper, shipping agent, Egypt port authority and Egypt container terminal). The paper factory is exporting an interesting volume of goods to the Turkish and Egyptian markets, and we strongly believed that the CASSANDRA project could help to reinforce the Portuguese-Turkish commercial relations and trade policies. Despite their interest in the project, they requested the formalization and materialization of the participation of Egypt or Turkish entities to have a formal commitment from them. They accepted the use of the information related with them but with a masked name and forbid any explicit connection between CASSANDRA and their systems, this was the final decision taken on the 11th December 2013. During the process several entities were contacted: AICEP (Trade & Investment Agency) in Portugal, Turkey and Morocco, Morocco Embassy in Portugal, Portugal Embassy in Turkey, the shipper with a commercial line between Portugal and Turkey (Arkas), the shipper with a commercial line between Portugal and Egypt used by the paper factory. This last shipper,

2 http://www.trtenglish.com/trtworld/en/newsdetail.aspx?haberkodu=7cc8c8ae-8cb7-49c1-a9d9-18ac783d5f12


Page | 49

Tarros, manifested their interest in the project and offered their help to facilitate the contact with the major Egypt Ports. Due to these (negotiable) uncertainties and the need for progress in the development of the solution, a platform was created with openness in mind in order to accommodate the data sharing from any party that may be interested in the project in the near future. Customs are interested as a receiver of information, but do not want to share information from their system. For demonstration will be available information gathered from the Port Community System. 4. Description of the solutions The login page requires a user name and a password to get into the application. A similar screen is provided to sign up in the system and create a new entity/user to use it.

Figure 37 – Login page

The figure below shows the widgets that can be added to the user private dashboard. Each user will have a personalized customizable view depending on their own needs and requirements.

Figure 38 – Widgets available

Next figure shows the Active Carriers widget:


Page | 50

Figure 39 – Active carriers

The figure below shows the Cargo widget:

Figure 40 – Cargo widget


Page | 51

Next, the Consignment widget:

Figure 41 – Consignment widget

The figure below shows the transport screenshot:

Figure 42 - Transports


Page | 52

The next figure corresponds to the Purchase Order hierarchical visualization The user can submit a new purchase order using the web services integrated with the dashboard

Figure 43 – Purchase order

There is as well a containers hierarchical visualization. It is possible to access the container status and all the historical information.

Figure 44 – Containers hierarchical visualization


Page | 53

In the following view is visible the interaction between container number and the vessel which the container is being transported

Figure 45 – Carriers hierarchical visualization

Next figure shows the Ship Information (external source of information – complementary to the dashboard)

Figure 46 – Ship information

The dashboard provides Track&Trace functionality associated with the AIS of the vessel:


Page | 54

The user is able to configure alerts in the dashboard: programmable automatic triggered events for different users such as Customs, Maritime authority, Port authority, Sanitary authority etc.

Figure 47 – Alerts

5.1.3 During pilot phase

The platform implements a web service where any interested party can connect by using an authorization token, but for the pilot phase the only source of information available was the PCS of Setubal. The PCS is a black box without any API to connect with. In this particular case (and specifically for this LL) an additional development (ETL process) was produced by GMV to extract information directly from the database (through pre-defined views created and maintained by APSS for this goal), transform it in a recognized message and pull it to the CASSANDRA web-service. In other words, this represents a middleware layer to simulate a web service invocation of the PCS. The dashboard is fully implemented and running since February 2014. After this and until mid-March it was subject to enhancements and defects solving. In mid-March two workshops with the Port Authority of Setubal and with Portuguese Customs were held. Both organizations showed a high level of satisfaction with the final results, mainly with what refers


Page | 55

to the presentation layer and specifically on the way the information is displayed to the end-user. In fact, the platform presents a new concept with the implementation of widgets that offers to the end user the ability to customize the dashboard according to their own needs. The results of this workshop were quite good and the results of the technical evaluations were also quite satisfactory. The main pros manifested by the participants were the ease of use and the way the information is organized. For the cons the main critic is related to the lack of actors sharing information through the platform. Despite the fact that Customs never manifested formally their participation in the project they appreciated and thanked, when demonstrated, the implementation for a requirement elicited by them in a meeting on an early phase of the project. This requirement refers to a web-service where customs could retrieve information from the platform for their own risk analysis.

5.1.4 Use by parties and (expected) Benefits

Organization / role Interests Advantages of CASSANDRA

Forwarder Improved efficiency of Customs process, possibilities for pre-clearance and green lanes

Customs / authorities Improved efficiency of risk analyses and Customs processes

Improved intelligence to reduce fraud, smuggle, theft and other risks

Sharing of experiences

Awareness - Visible notation regarding several events

Possible queries to different data sources

Better information regarding the supply chain

Port Authorities Opportunities to develop their single window and to migrate to the logistics single window.

Opportunities to positively differentiate the Authorized Economic Operators

Increment on the transparency of the data flow

Administrative benefits

Innovation relevance

Port community involvement

Different stakeholders engagement

Calculation of trade facilitation indicators (TFIs)

Health Authorities Sanitary and phytosanitary measures

Container compatibility with different contents

Visible notation regarding miss uses


Page | 56

5.1.5 Reflection

The biggest challenge faced during the development phase was the lack of stakeholders and subsequently the inexistence of particular requirements. Because of this “D1.2 – User Requirements and Business Drivers” was used as the baseline for the technical implementation. The platform was created based on several assumptions and with openness in mind in order to accommodate any stakeholder that could arise later in the process, but we cannot deny that creating a solution without knowledge on the actual business requirements, and without inputs from real stakeholders, poses several risks for the usage of this application (for instance, inadequacy with the reality of the business). However, and if the base requirements were well understood and well implemented, this can imply the platform that can be used by any business or authority (such as customs). From the experience gained throughout the projects having a partner on both sides of the trade lane seems to be of critical importance for the success of a Living Lab. One of the biggest difficulties faced in this trade lane was the lack of a partner in the other country to facilitate the contact with relevant entities and to commit with the project. In this can it is clear that these countries are facing very hard moments, and most of times the private companies are, understandably, more interested in their own survival than in demonstration projects. But if we can manage a successful Living Lab, there are good possibilities to attract different players in a near future. With nothing to put in the spotlight, it is difficult to point out the main advantages of this programme, mainly to exporting companies, which are frequently “bombarded” with different solicitations from several projects. The CASSANDRA project encourages and makes it easier for buyers and sellers to move goods between countries. Several players mainly the Authorized Economic Operators (AEOs) will reap benefits, such as faster processing of goods by Customs, e.g. through reduced examination rates. This, in turn, translates into savings in time and costs. One of the main tenets of the CASSANDRA is to create one set of international demonstrable standards and this establishes uniformity and predictability on the supply chain. Using the OECD Trade Facilitation Indicators (TFI) is possible to measure the real benefits of the CASSANDRA project not just for trade but as a tool to increase coordination and collaboration between publics, partners and the private sector Near the end of this project we learned that:

a) To promote the engagement of both parts (producers and consumers) it is very important to present more than just a virtual concept. It is crucial to demonstrate tangible benefits.

b) The integrated and harmonized supply chain management must be enabled for all modes of transport.

c) The co-operation between Customs administrations must be strengthened to improve their capability to detect high-risk consignments. The Customs/Business co-operation must be strengthened in order to promote the seamless movement of goods through secure international trade supply chains.

In order for this “Data pipeline concept” to be implemented not only will capacity need to be built, but it will also be required to have understanding for the need of a phased approach. It is unreasonable to expect that every stakeholder will be able to implement the CASSANDRA framework immediately. Developing countries often confront two types of binding constraints. Firstly, they face difficulties turning trade opportunities into trade flows due to capacity constraints and lack of adequate trade related infrastructure. Secondly, some domestic constraints choke the impact


Page | 57

of trade expansion on economic growth. Not all countries have the same capacity to adjust, i.e. to reallocate its scarce resources. This difference in capability to adjust will affect the growth response to the trade reform. However, Regional Trade Agreements (RTAs) can be a powerful lever and indicator of the types of concessions that states would be willing to multilateralise in the General Agreement on Trade in Services (GATS). While there are important legal and economic dimensions to ponder, considerations of political and technological economy must also be taken into account. The Living Labs supported on Regional Trade Agreements, will have a huge potential when established between countries with some affinities. For example the CPLP, community of Portuguese language countries. The CASSANDRA project will help the benchmarking approach in comparing a country’s performance with those of other countries. In some of the country’s involved, a small number of key sectors believed to have significant potential for expansion in output, including in boosting the national capacity (public and private) to formulate and implement sharper trade policies; From a technical perspective the biggest challenge faced was the lack of stakeholders and specific requirements. This forced GMV to create a platform based on assumptions and with openness in mind so as to accommodate any stakeholder that could arise later during the process. Creating a solution without knowledge on the actual business requirements poses several risks in the usage of this application, for instance, inadequacy to the reality of the industry. At the end of the project there was a workshop with the participation of the Port Authority and Customs where both contributed to the Technical Evaluation of the developed Solution. Despite the lack of specific requirements, the stakeholders identified several positive aspects highlighting the ease of use and how the information/data is presented to the user.


Page | 58

Appendix A – Spain-Egypt trade lane: Activity and Decision Log

Activity log 1. Meeting – Workshop Morocco Date 13/03/2011

Parties involved APSS, HMRC, ATOS, GMV, TUD, Portugal Customs Reason for meeting • Portugal-Morocco trade lane: involvement of stakeholders

Outcomes (if applicable)

• Presentation of CASSANDRA project to: Agence Nationale des Ports, SOMAPORT (Casablanca terminal) and Morocco Customs

Follow-up activities Preparation of DoI letters Check financial possibilities Check research cooperation posibilities

Activity log

2. Meeting – Setubal Meeting Date 13/03/2011

Parties involved APSS, TNO, TUD, ATOS, GMV Reason for meeting • Portugal-Morocco trade lane: involvement of stakeholders


• Presentation of CASSANDRA project to: Portuguese customs, Autoridade Marítima, Sadoport, Tarros line, Orey, AICEP and Marocco embassy representation

Follow-up activities Living lab alignment session. Involvement of stakeholders.

Activity log

3. Telco – WPL Telco Date 01/09/2011

Parties involved CBRA, TNO, ATOS, TUD, ZLC, EUR, ISL Reason for meeting • Status of WPs


Communication of workshop in Portugal

Follow-up activities 1. Result of the meeting in Rabat

Activity log




Roadmap based on overall roadmap to outline the Living Labs specifically


Page | 59

Enhance the involvement of customs in LL3

Follow-up activities Communication of workshop in Portugal

Activity log




• Report of the meeting held in Setubal

Follow-up activities

Activity log




• Report of the meeting held in Setubal


Activity log

7. Telco – LL3 Telco Date 22/03/2012

Parties involved Atos, Portic, TUD, NSCE Reason for meeting • Status of the engagement task


Preparation of meeting in Barcelona

Selection criteria of the trade lanes


Activity log

8. Meeting – Barcelona Meeting Date 23/04/2012

Parties involved TUD, TNO, APSS, GMV, NSCE, PORTIC, ATOS , HMRC Reason for meeting • Spain-Egypt trade lane: involvement of stakeholders


Page | 60


• Internal LL3 Meeting and Presentation of the project to: Spanish customs and Oxylane group

• Experiences from LL1 Follow-up activities

Living lab alignment session. Involvement of stakeholders.

Activity log


Parties involved Atos, Portic, TUD, NSCE Reason for meeting • Status of the engagement task


LoI Aduana Española / Oxylane

CASSANDRA Living Lab Template

Preparation of technical meeting with Oxylane

Follow-up activities 2. Follow up contacts to Oxylane in Egypt

Activity log

10. Meeting – Oxylane meeting Date 11/06/2012

Parties involved ATOS, Portic Reason for meeting • Requirements from Oxylane


• Analysis of the process • Documentation involved

Follow-up activities Meeting foreseen in July

Activity log


Parties involved Atos, Portic, TUD, NSCE, GMV Reason for meeting • Status of trade lanes: engagement phase


Informed consent letter template

Organisation of meeting with Oxylane

Follow-up activities 3. Follow up of the Living Lab Template

Activity log


Parties involved Atos, Portic, TUD, NSCE, GMV


Page | 61

Reason for meeting • Status of trade lanes: it mapping phase / role of ISPF


Specify data and events in the process

Result of the meeting in Rabat

Follow-up activities 4. Organisation of an internal meeting after the review

Activity log


Parties involved Atos, Portic, TUD, NSCE, GMV Reason for meeting • Status of trade lanes: definition of dashboard


Dashboard development one per each trade lane

Data capture interface

Egypt web form

Follow-up activities 5. Organisation of internal LL3 Technical meeting

Activity log


Parties involved Atos, Portic, TUD, NSCE, GMV Reason for meeting • Status of trade lanes: it mapping phase / role of ISPF


Specify data and events in the process

Result of the meeting in Rabat

Follow-up activities 6. Organisation of internal meeting after the review

Activity log

15. Meeting – WP4 Meeting Amsterdam Date 27/02/2013

Parties involved TNO, ISL, ATOS, GMV, Portic, APSS, TUD Reason for meeting • Status of the three Living Labs


Info exchange of dashboards

RBA in LLs

Backbone implementation

Follow-up activities 7. Definition of exploitation approach

Activity log


Page | 62

16. Meeting – Data Capture meeting Date 25/04/2013

Parties involved ATOS, Portic Reason for meeting • Data Capture definition


Analysis of requirements

Follow-up activities 8. Guidelines for the development of DC

Activity log

17. Meeting – General Assembly – LL3 Session Date 25/04/2013

Parties involved ATOS, Portic Reason for meeting • Definition of Dashboard


• Specification and functionalities of Dashboard • Dashboard interface design • Data message specification

Follow-up activities 9. Dashboard specification document

Activity log

18. Telco – Trade lane status Date 09/09/2013

Parties involved ATOS, Portic Reason for meeting • Progress of Dashboard


• Refine dashboard functionalities • Data message modifications

Follow-up activities 10. Dashboard specification document

Activity log

19. Telco – Dashboard specification Date 10/01/2014

Parties involved ATOS, Portic Reason for meeting • Progress of Dashboard

• Control users Outcomes (if applicable)

• Modification of users control • Access to remote purchase orders

Follow-up activities 11. Dashboard review v5.0.xlsx

Activity log


Page | 63

20. Workshop – EFS Dashboard Date 01/01/2014

Parties involved NSCE, EFS Reason for meeting • Presentation of dashboard

• Definition of the shipments during the living lab Outcomes (if applicable)

• Involvement of IFS • Start up of the trade lanes

Follow-up activities 12.

Activity log

21. Workshop – Business Dashboard presentation Date 15/04/2014

Parties involved ATOS, Portic, ZLC, Spanish Customs, Port Barcelona Authority, IFS Reason for meeting • Present the project results to authorities.

• Present the Customs dashboard • Present the Business dashboard • Present the user`s experience to the authorities


• Risk methodology evaluation • Feedback from authorities


Page | 64

Appendix B – Portugal trade lane: Activity and Decision Log

Activity log 22. Meeting – LL3 (Portugal) Meeting Date 7-2011

Parties involved APSS – Enapor - Cape Vert Port Authorities Reason for meeting • Approaching and engaging stakeholders


Invitation of this entities

Follow-up activities 13. Follow up actions and meetings Involvement of potential Living Lab stakeholders. Several different contacts

Activity log

23. Meeting – LL3 (Portugal) Meeting Date 7-2011

Parties involved APSS – Luanda Port Authority Reason for meeting • Approaching and engaging stakeholders


Invitation of this entity

Follow-up activities 14. Follow up actions and meetings Involvement of potential Living Lab stakeholders. Several different contacts

Activity log


Parties involved APSS – Sadoport, Setubal Container Terminal Reason for meeting • Approaching and engaging stakeholders



Follow-up activities Follow up actions and meetings Involvement of potential Living Lab stakeholders. Formal Invitation´s and follow up

Activity log


Page | 65


Parties involved APSS – Maritime Authority (Captain of the Port) Reason for meeting • Approaching and engaging stakeholders



Maritime Authority interaction Approaching and engaging stakeholders. Identification of the Maritime Authority point of view and consensus building (Captain of the Port)

Follow-up activities Follow up actions and meetings Involvement of potential Living Lab stakeholders. Formal Invitation´s and follow up

Activity log


Parties involved APSS – Services of Ministry of Foreign affairs Reason for meeting • Approaching and engaging stakeholders


To enable government authorities to have a complete view of chains and all activities involved. Contribution from Portuguese Government point of view. Networking and consensus building

Follow-up activities 15. Multiple phone interactions

Activity log


Parties involved APSS – Portuguese Customs Reason for meeting • Approaching and engaging stakeholders


Customs interaction - Identification of suitable supply chains:

Contribution from Portuguese Customs and identification of their point of view.

Follow-up activities 16. Multiple subsequent informal meetings

Activity log



Page | 66

Parties involved APSS – Portuguese Customs – SADOPOR, TARROS, TU, ATOS, OREY, GMV, AICEP and Marrocos embassy representation

Reason for meeting Living lab alignment session meeting in Setubal • Preparation, coaching and set-up of living lab 3


Parties interaction. LL3 Presentation

Follow-up activities 17. Building up networking and common interest

Activity log


Parties involved APSS – Marroco´s ambassy Reason for meeting • Marrocos embassy interaction – economic attaché - networking and

consensus building



Follow-up activities 18. Follow up actions and meetings Involvement of potential Living Lab stakeholders

Activity log


Parties involved APSS – AICEP Reason for meeting AICEP interaction - networking and consensus building (Rui Cordovilo and

other AICEP Directors) • AICEP Portugal Global - Trade & Investment Agency



Follow-up activities 19. Preparation of the Marrocos trip

Activity log


Parties involved APSS – Ship agency – Orey and Ship Owner – Tarros;


Page | 67

Reason for meeting interaction • Networking, consensus building and Ship agency point of view


System integration and networking and consensus building

Follow-up activities 20. Informal contacts

Activity log


Parties involved APSS – Port Community Reason for meeting interaction


Engaging National stakeholders

Follow-up activities Press releases production “Dissemination”

Activity log


Parties involved APSS – Port Protection Committee Reason for meeting CASSANDRA presentation


Risk based approach improvement Approaching and engaging Public stakeholders (Authorities)

Follow-up activities Several informal contacts

Activity log


Parties involved APSS – Port users Reason for meeting Single window – process alignment

system integration with user requirements


Page | 68


Approaching and engaging Private stakeholders


Activity log


Parties involved APSS – Sadoport Reason for meeting Technical meeting with IT Terminal operator Sadoport - system integration


Improve interaction with the Terminal Alignment and coordination for future actions


Activity log


Parties involved APSS – IT experts Reason for meeting Technical workshops – internal and external aligning the concerns of the

internal stakeholders of the living lab (business, customs, (IT) service providers) and the concerns of the external stakeholders


Single window – process alignment – Information and content System development Identification of the end user requirements


Activity log


Parties involved APSS – Customs Reason for meeting Customs interaction


National Participation (Declaration of interest)

Stakeholder involvement and engagement


Page | 69

Follow-up activities Asking for National Participation (Declaration of interest)

Activity log


Parties involved APSS – Portucel Reason for meeting Portucel – interaction




Activity log


Parties involved APSS – Morroc´s Customs interaction and meeting Reason for meeting interaction




Activity log


Parties involved APSS – Morroc´s Customs interaction and meeting Reason for meeting Requirements gathering during the preparation phase.

Involvement of the Marroc´s stakeholders




Activity log


Page | 70


Parties involved APSS – ANP interaction Reason for meeting Requirements gathering during the preparation phase.





Activity log


Parties involved APSS – SOMAPORT Reason for meeting Requirements gathering during the preparation phase.





Activity log


Parties involved APSS – Several Stakeholders Reason for meeting CASSANDRA dissemination



International Conference – Cascais, LOGISTEL

Follow-up activities Media dissemination

Activity log


Parties involved APSS – Portbase, ATOS, TU Reason for meeting Containerized trade lanes identification and characterization



Page | 71


Project alignment


Follow-up activities Several different contacts Exchange and access relevant data between partners in a chain themselves and between those partners and government authorities with a specific focus on the Living Labs (Iberia-Africa).

Activity log


Parties involved Consortium Reason for meeting General Assembly

Delft meeting preparation


Project alignment

Follow-up activities Several different contacts Exchange and access relevant data between partners

Activity log


Parties involved APSS - Stakeholders Reason for meeting Lisbon International Fair (FIL) – Workshop Potential Business Portugal

Marroc´s


Stakeholder involvement and engagement.

New lines and cargo identification

Dissemination action AICEP


Follow-up activities Several different contacts Exchange and access relevant data between partners

Activity log


Parties involved APSS - Port National security interaction IPTM

Reason for meeting Stakeholder involvement and engagement




Page | 72

Follow-up activities Several different contacts Exchange and access relevant data between Port Authorities

Activity log


Parties involved APSS - SADOPORT



Characterization of all goods moving via this Terminal to Casablanca or from Casablanca

Follow-up activities Characterization of the Volumes of commerce

Activity log


Parties involved APSS - new Ship-owner Line - Setubal Casablanca



Identification of the potential interest in the Project

New operator with different solutions


Activity log


Parties involved APSS - GMV

Reason for meeting Technical meeting


process harmonization,

Follow-up activities Several different contacts


Page | 73

Activity log


Parties involved APSS – Port Community

Reason for meeting presentation to Port community – General Assembly



Follow-up activities Several different contacts and email changing

Activity log


Parties involved APSS – Customs

Reason for meeting Customs articulation regarding the technical solutions


Stakeholder involvement and engagement Involvement of the risk department

Follow-up activities Several different contacts and email changing

Activity log


Parties involved APSS – APLOP

Reason for meeting CASSANDRA Dissemination on the following seminar “III Encontro de Portos da CPLP”

6 and 7 of December



Follow-up activities Networking


Page | 74

Activity log 54. Meeting – LL3 (Portugal) Meeting Date 01-2013

Parties involved APSS – GMV

Reason for meeting IT articulation regarding the technical solutions for the dashboards


Designing the dashboards


Activity log


Parties involved APSS – Portucel





Activity log

56. Meeting – LL3 Meeting Date 16-11-2011

Parties involved GMV; APSS; ATOS; TUDelft; TNO: AICEP; Morocco Embassy Reason for meeting • General LL3 Meeting: Kick Off Meeting


Follow-up activities Follow contacts with Morocco Embassy.

Activity log

57. Meeting – LL3 Meeting Date 23-4-2012 and 25-4-2012

Parties involved GMV; APSS; ATOS; PORTIC; TUDelft; TNO


Page | 75

Reason for meeting • General LL3 Meeting



Activity log

58. Meeting – LL3 (Portugal) Meeting Date 26-7-2012

Parties involved GMV; APSS Reason for meeting • Presentation of GMV’s initial prototype and ambitions for the

dashboard. GMV will use the latest trends to create a customized HMI.

• Presentation of the list of data elements considered to CASSANDRA. • Discussion about the access matrix (for each data element).


Follow-up activities 1. APPS will check if all the data elements are available in JUP. 2. APSS to fill the access matrix.

Activity log

59. Meeting – LL3 Portugal meeting Date 4–10-2012

Parties involved GMV; APSS Reason for meeting • Discussion about the dashboards. Next steps.

• Presentation by GMV of the draft version of the LL template and IT mapping.

• Discussion about LL3 meeting to be held in Delft. • Discussion about access matrix and data elements. • Risks about the not yet involvement of Morocco and other possible

alternatives. Outcomes (if applicable)

Follow-up activities 1. APPS will check if all the data elements are available in JUP. 2. APSS to fill the access matrix. 3. APSS to complete/comment LL template and IT Mapping. 4. APSS to analyse other possible commercial lines from Setúbal.


Page | 76

Activity log 60. Meeting – LL3 meeting Date 18–10-2012

Parties involved GMV; Atos; TUDelft Reason for meeting • Discussion about LL3

• Atos wants to specify the requirements and that GMV’s develop the dashboard to all LL3 (Barcelona-Alexandria and Setúbal-Casablanca)

• Discussion about the lack of response from the Morocco entities. Outcomes (if applicable)

Follow-up activities 1. Atos scheduled a conference call for the 22nd of October to discuss the dashboard development by GMV.

Activity log

61. Conference Call – LL3 meeting Date 22–10-2012

Parties involved GMV; Portic; Atos; TUDelft Reason for meeting • Atos wants to specify the requirements and that GMV develops the

dashboard to all LL3 (Barcelona-Alexandria and Setubal-Casablanca).


1. Morocco backbone is unknown. GMV should need to develop dashboard, interfaces for Setubal and it may be possible that extra development is needed for Morocco. GMV is the only IT Company in the Setúbal trade lane. No more leeway because of the unknown and the risks are too high.

For GMV to develop the dashboard for Barcelona, the internal project plan should be all revised. Ad-hoc interfaces are being created for the case of Setúbal. The priority to GMV is the dashboard, the interfaces will be the last thing to be ready. In order to develop the dashboard for Barcelona, priority should be given to the interface in order to accommodate different realities. GMV will focus only in the Setúbal trade lane.


Activity log


Parties involved GMV; APSS Reason for meeting • Discussion about a Plan B for our trade lane (Mediterranean sea is a

possibility). Tarros and Portucel in this Line. • Need to fill Living Lab Template by APSS. • Need of signature of the Declaration of Interest by Tarros and


Page | 77

Portucel. • Data Elements Matrix. • Integration between CASSANDRA and JUP.

Outcomes (if applicable) Follow-up activities Date Parties involved

1. Another approach for the integration between JUP and CASSANDRA has been discussed. JUP have some XML information inside the database. If this XML have information required to CASSANDRA, no extra development will be needed.

1. APPS will check if all the data elements are available in JUP. 2. APSS to fill the access matrix. 3. APSS to complete/comment LL template and IT Mapping 4. APSS to verify the existence of XML in the database that can be used as

a source of information to CASSANDRA. 5. APSS will send all the existent XML files for further analysis of GMV. 6. GMV to send information to APSS about infrastructure requirements. 7. GMV to create a draft version of the process modelling.

31–1-2013

GMV; APSS

Reason for meeting • Discussion about a Plan B for our trade lane (Mediterranean sea is a possibility). Tarros and Portucel in this Line.

• Need to fill Living Lab Template by APSS. • Need of signature of the Declaration of Interest by Tarros and

Portucel. • Data Elements Matrix. • Integration between CASSANDRA and JUP.

Activity log


Parties involved GMV; APSS; Portuguese Customs Reason for meeting • Meeting to discuss the involvement of Customs in the CASSANDRA

Project


1. Customs don’t have interest in being a source of information to CASSANDRA

Customs don't seem interested in the Dashboard. It will be another system where they need to look for information.

Customs asks for a web service where they can download information from CASSANDRA to an internal database for their own risk analysis. (GMV accepted to provide this service).


Activity log

64. Meeting – WP4 meeting Date 26–02-2013 & 27-02-2013

Parties involved GMV; APSS; Portic; Atos; TUDelft; ISL, TNO


Page | 78

Reason for meeting • WP4 meeting. • LL’s status



Activity log


Parties involved GMV; APSS; Portucel Reason for meeting • Discussion with Portucel about their involvement and interest in the

project.


1. Portucel may be interest in the project if the trade lane is from Setúbal to Egypt or Turkey

Follow-up activities 1. Follow up with Portucel to present the project to the Administration. 2. Inform WP Leader about the meeting and get suggestion/decision in

which of the countries we should focus to complete the trade lane.

Activity log


Parties involved GMV; APSS; TUDelft Reason for meeting • Discussion with TUDelft about the meeting with Portucel.


Follow-up activities 1. TUDelft to communicate if the trade lane should be developed to Egypt (using a partner already existent) or if we should try to bring Turkey to the project.

Activity log


Parties involved GMV; APSS Reason for meeting • Turkey will be the next step. GMV to develop the contact with Turkish

entities. • APSS presented which data elements needed for CASSANDRA are

available in JUP.


Page | 79

• GMV presented the integration solution to be developed. • GMV presented the scheduled and project plan. Receive

commitment from all parties. Outcomes (if applicable)

1. APSS to develop views in the database with information required (no webservice available).

GMV will create an ETL process to extract information from that view, transform in CASSANDRA format and load into the system.

Follow-up activities 1. APSS to confirm if all the elements are really in the JUP. Some elements are questionable and caused some doubts.

Activity log


Parties involved GMV; APSS; Portucel Reason for meeting • Discussion with Portucel to get their participation in the project.



Activity log


Parties involved GMV; APSS Reason for meeting • Technical discussion about the estimation to get more data elements

available in order to proceed with dashboard development • Discussion about the contacts made with stakeholders and their

availability to participate in the project. Outcomes (if applicable)


Activity log 70. Meeting – LL3 Portugal meeting Date 07–11-2013

Parties involved GMV; TuDelft; Atos


Page | 80

Reason for meeting • Situation about the Portuguese Trade Lane


Follow-up activities • GMV to send email to APSS requesting information about other companies exporting through Setubal.

• TuDelft to follow up this matter as WP Leader.

Activity log


Parties involved GMV; APSS Reason for meeting • Meeting to discuss the following steps for stakeholders cooperation in

the LL. Next steps and strategies.



Activity log


Parties involved APSS; National Focal Point; and other National Authorities Reason for meeting • CASSANDRA presentation.

• Meeting to discuss the following steps for stakeholder’s cooperation in the LL. Next steps and strategies.


National involvement


Activity log 73. Meeting – LL3 Portugal meeting Date 17–10-2013

Parties involved APSS; other Port Authorities Reason for meeting • CASSANDRA presentation and future cooperation between

transnational Authorities


Page | 81


Interaction of PCS system’s


Activity log


Parties involved APSS; Shipping Agent OREY Reason for meeting • Meeting to discuss the following steps for stakeholder’s cooperation

in the LL. Next steps and strategies.


Definition of the format of the Bill of lading

Clarification of the information fields

Methodology of interaction regarding the CASSANDRA project


Activity log


Parties involved APSS; Portuguese Customs Reason for meeting • Meeting to discuss the following steps for stakeholder’s cooperation



Identification of the possible cooperation with the fraud department


Activity log


Parties involved APSS; TARROS Reason for meeting • Meeting to discuss the following steps for stakeholder’s cooperation




Page | 82

Follow-up activities • Possible integration of the AIS signal and container tracking

Activity log

77. Meeting – LL3 Portugal phone meeting Date 5–12-2013

Parties involved APSS; TARROS Reason for meeting • Meeting to discuss the following steps for stakeholder’s cooperation

in the LL. Next steps and strategies. • Exchange of documentation


Follow-up activities • Involvement of the technical director

Activity log


Parties involved APSS; Portuguese Customs Reason for meeting Identification of some critical points for this authority .



Activity log


Parties involved ; APSS; Paper factory Reason for meeting • Meeting to discuss the following steps for stakeholder’s cooperation



Information confidentiality; non-disclosure of the paper factory name


Activity log


Page | 83


Parties involved APSS; GMV Reason for meeting • Dashboard Presentation to the Port Authority

• Technical Evaluation Outcomes (if applicable)


Activity log


Parties involved ; APSS; GMV; Portuguese Customs Reason for meeting • Dashboard presentation

• Technical Evaluation Outcomes (if applicable)

More involvement of this critical Authority

Follow-up activities Increment of the number of data sources (possible implementation of a web insertion manifest )

Activity log


Parties involved ; APSS; GMV Reason for meeting • Meeting to discuss other functionalities on the dashboard


Follow-up activities Alarms associated to different events

CASSANDRA D4 3 final report - cassandra-project.eu deliverables... · The CASSANDRA project aims to...

Documents

Transcript of CASSANDRA D4 3 final report - cassandra-project.eu deliverables... · The CASSANDRA project aims to...