0% found this document useful (0 votes)

136 views78 pages

Finest d13

Uploaded by

mfakhrurizapradana

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

0% found this document useful (0 votes)

136 views78 pages

Finest d13

Uploaded by

mfakhrurizapradana

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

You are on page 1/ 78

FInest – Future Internet enabled optimisation

of transport and logistics networks

D1.3
Business Requirements
for future transport and logistics ICT solutions

The research leading to these results has received funding from the European Community's Seventh
Framework Programme [FP7/2007-2013] under grant agreement no. 285598
Project Acronym FInest
Project Title Future Internet enabled optimisation of transport and
logistics networks
Project Number 285598
Work package WP1 Domain Characterization and Requirements Analysis
Lead Beneficiary Kühne + Nagel
Editor(s) Michael Zahlmann Kühne + Nagel
Stefan Seysen Kühne + Nagel

Contributors(s) Andreas Köstler Kühne + Nagel

Evert-Jan van Harten Air France KLM
Agathe Rialland Marintek
Hande Koç Arcelik (ARC)
Cyril Alias UDE
Oyvind Olsen NCL
Michael Stollberg SAP

Reviewer Dirk – Henning Stuhr Kühne + Nagel

Prof. Dr. Bernd Noche UDE
Prof. Dr. Rod Franklin Kühne + Nagel
Dissemination Level
Contractual Delivery Date 31.03. 2012
Actual Delivery Date 31.03.2012
Version 1.0

The research leading to these results has received funding from the European Community's Seventh
Framework Programme [FP7/2007-2013] under grant agreement no. 285598
FP7-2011-ICT-FInest

Abstract
International transport and logistics operations are concerned with the planning and execution
of the world-wide shipment of goods and people. The FInest project addresses this domain as
a useful example for how Future Internet based services can improve operations within a
complex domain while “leveling the playing field” so that small companies can better
participate. The FInest project has identified three different use case scenarios in this domain
that characterize different aspects of transport and logistics operations that will serve as
examples for building Future Internet based services. Based on the preliminary analysis of the
domain business requirements, and based on the project’s initial analysis of these use cases,
the next step for the project was to analyze the domain to develop detailed Business
Requirements for possible future ICT (information and computer technology) solutions based
on Future Internet technologies.

This document is being submitted as specified in the FInest Description of Work (DoW) as the
foundation of deliverable D1.3 – Business Requirements for future transport and logistics ICT
solutions. The work done in this deliverable has been one of collaboration with all other work
packages in the project. The need to use the detailed information flows that pass between
partners in the project to define technical requirements for work packages 5 – 8 required that
business requirements be examined from the perspective of the development of an ICT
solution to the opportunities for improvement identified in work package 2. This
theme/perspective necessarily biases the analysis. However, given the parallel nature of the
project work packages where technical deliverables require information about certain business
needs before requirements definition has been completed, this approach was selected so that
the greatest benefit to the project in total could be achieved. The reader interested in the
detailed information passed between domain partners, its format, source, and destination
should review the Appendix to this document, which has been provided as part of this
deliverable.

The use cases that have been identifed for analysis within the project are:
 Use Case 1 – Fish Transport from Ålesund (Norway) to Europe: The use case is
covered by three companies (Port of Ålesund, NCL and Tyrholdm&Farstad), and focus
has been put on the perspective of three different roles covering one part of a
transport chain: the port, the shipping line and the container terminal. The intention
has been to understand the challenges of this shipment process from the perspective
of these three roles, and on understanding the interactions among business partners
in the process. Focus has not been on covering a complete door-to-door transport
chain.
 Use Case 2 – Air Transport of Equipment: The use case is covered by two companies
(Kuehne + Nagel and Air France-KLM Cargo) representing the two main parties in this
transport chain. Focus has been put on describing a complete door-to-door transport
chain. This transport chain has been divided into three main parts: 1. Shipper-to-
Carrier, 2. The Carrier process (Forwarder-to-Carrier, then Carrier-to-Forwarder), and
3. Carrier-to-Consignee.

 Use Case 3 – Global Consumer Goods Production and Distribution: The use case is
covered by one company (Arcelik). The perspective is, therefore, of the manufacturer,
and the use case consists of three transport chains: two covering the inbound logistics
of materials (from the Far East and Europe to Turkey), and one covering the export of
manufactured products to the UK.
The initial business requirements identified that the FInest platform should address include the
following:
 Improved information exchange to ensure that the right information arrives at the
right time, with easy access, but with security in transfer
 Improved coordination of business activities among all involved actors
 The ability to integrate with legacy systems
 Event-driven monitoring and real time tracking of processes
 A standardized communication interface between all participants
 Improved operational transparency between partners
 Flexible operations to respond to variable market demands
 Pro-active alerts to allow for problem avoidance
 Improvement in resource planning
 Automated data entry (eliminate paper and manual processes)
 Improvement in visibility to resources and their availability
 Safe and efficient transfer of documents
 Ability to plan and replan activities based on real time market conditions
 Improve operational efficiency to lower carbon emissions

Disclaimer
The content of the publication herein is the sole responsibility of the publishers and it does not
necessarily represent the views expressed by the European Commission or its services.
While the information contained in the documents is believed to be accurate, the author(s) or
any other participant in the FInest consortium make no warranty of any kind with regard to
this material including, but not limited to the implied warranties of merchantability and fitness
for a particular purpose.
Neither the FInest Consortium nor any of its members, their officers, employees or agents shall
be responsible or liable in negligence or otherwise howsoever in respect of any inaccuracy or
omission herein.
Without derogating from the generality of the foregoing neither the FInest Consortium nor any
of its members, their officers, employees or agents shall be liable for any direct or indirect or
consequential loss or damage caused by or arising from any information advice or inaccuracy
or omission herein.

Document History
Version Date Comments
V0.1 24-01-2012 First draft
V0.2 27-02-2012 Revised draft
V0.3 15-03-2012 Revised draft
V0.4 21-03-2012 Revised draft
V0.5 28-03-2012 Revised draft
V0.6 29-03-2012 Revised draft
V0.7 30-03-2012 Revised draft
V1.0 31-03-2012 Final document release

Table of Contents
Abstract ........................................................................................................................................................ 3
Disclaimer ..................................................................................................................................................... 5
Document History ........................................................................................................................................ 5
Table of Contents ......................................................................................................................................... 6
Acronyms ...................................................................................................................................................... 9
1 Introduction ....................................................................................................................................... 11
1.1 Work Package 1 ........................................................................................................................ 11

1.2 Relationship with other Work Packages ................................................................................... 12

1.3 Task 1.2: Detailed Business Requirements Analysis ................................................................. 13

2 Business requirements for transport and logistics domain ............................................................... 14
2.1 4Phases methodology ............................................................................................................... 14
2.1.1 Sales / Marketing ........................................................................................................ 15
2.1.2 Planning ...................................................................................................................... 15
2.1.3 Execution .................................................................................................................... 16
2.1.4 Completion ................................................................................................................. 17
2.2 Requirements Analysis .............................................................................................................. 17
2.2.1 Introduction................................................................................................................ 17
2.2.2 General Requirements identified in the Domain Analysis (D1.1)................................. 17
2.3 Generic requirements identified in the Analysis of the Transport and Logistics Domain ........ 19
3 Generic requirements overview ........................................................................................................ 20
3.1 Collaboration ............................................................................................................................ 20

3.2 Planning .................................................................................................................................... 21

3.3 Resource Management ............................................................................................................. 22

3.4 Monitoring and Visibility ........................................................................................................... 22

3.5 Targets to be achieved .............................................................................................................. 23

3.5.1 Simplifying the ICT landscape ..................................................................................... 23
3.5.2 Reduction of manual input and tasks .......................................................................... 23
4 Communication / Information Exchange ........................................................................................... 23
4.1.1 Data Flow ................................................................................................................... 24
4.1.2 Communication Analysis ............................................................................................. 25
5 Use case requirement analysis .......................................................................................................... 26
5.1 Use Case 1 – Fish Transport from Ålesund (Norway) to Brasil.................................................. 28

5.2 Use case 2 – Air Transport of Equipment.................................................................................. 34

5.3 Use case 3 – Global Consumer Good Production and Distribution .......................................... 39

5.4 Message detail consolidation ................................................................................................... 44

6 Detailed Domain Business Requirements .......................................................................................... 48

6.1 Business Collaboration .............................................................................................................. 48
6.1.1 Business alignment ..................................................................................................... 49
6.1.2 E-market place ............................................................................................................ 49
6.1.3 E-Contracting .............................................................................................................. 49
6.1.4 Administrating of business partners ........................................................................... 50
6.1.5 Security and privacy .................................................................................................... 50
6.1.6 Technical Collaboration .............................................................................................. 50
6.2 Planning .................................................................................................................................... 50
6.2.1 Event management ..................................................................................................... 51
6.2.2 Re-planning (multiple solution planning) .................................................................... 51
6.2.3 Strategic planning ....................................................................................................... 51
6.3 Resource Management ............................................................................................................. 52

6.4 Monitoring & Visibility .............................................................................................................. 52

6.5 Business opportunities for SME ................................................................................................ 52

7 Conclusion ......................................................................................................................................... 52
8 Next steps .......................................................................................................................................... 54
9 References ......................................................................................................................................... 55
10 Appendix – Detailed data flows by use case ...................................................................................... 57

List of Figures

Figure 1: Interactions between WP1-WP3 and WP5-WP8 ......................................................... 13

Figure 2: FInest domain mapping approach ............................................................................... 15

Figure 3: Generic requirements identified in D1.1 Analysis of the TL Domain ........................... 20

Figure 4: Data Flow Example (MARINTEK, 2011) ........................................................................ 24

Figure 5: IBM and KN Secure Trade Lanes Project ...................................................................... 25

Figure 6: Big picture Use Case 1 .................................................................................................. 28

Figure 7: Information Flow UC1 1 ............................................................................................... 29

Figure 8: Information Flow UC1 2 ............................................................................................... 30

Figure 9: Big picture Use Case 2 (IATA, 2011) ............................................................................. 34

Figure 10: Document Flow Airfreight (IATA, 2012) ..................................................................... 35

Figure 11: Information Flow UC3 Export (ARCELIK, 2011) .......................................................... 39

Figure 12: Information Flow UC3 Import (ARCELIK, 2011).......................................................... 40

Figure 13: UC1 Port Information flow consolidation .................................................................. 45

Figure 14: UC1 NCL information flow consolidation ................................................................... 45

Figure 15: UC2 information flow consolidation .......................................................................... 46

Figure 16: UC3 Import information flow consolidation .............................................................. 46

Figure 17: UC3 Export information flow consolidation ............................................................... 47

Figure 18: Requirements related to 4 phase methodology ........................................................ 53

List of Tables
Table 1: High level Use Case Requirements ................................................................................ 27

Table 2: Challenges and needs UC1 ............................................................................................ 33

Table 3: Challenges and needs UC2 ............................................................................................ 39

Table 4: Challenges and needs UC3 ............................................................................................ 44

Table 5: Needs related to business functions ............................................................................. 48

Acronyms
Acronym Explanation
AFKLM Air France KLM
ANSIX12 EDI format
ARC Arcelik
ÅRH Port of Ålesund
AS2 Data transport specification
AWB Air Waybill
dfd
BL Bill of lading
C2k Cargo2000
D Deliverable
D2D Door-to-door
EDI Electronical data interchange
ERP Enterprise Resource Planning
ETA Estimated time of arrival
ETD Estimated time of department
FFM Flight manifest
FHL IATA message
FSU Freight status update
FTP File transfer protocol
FWB Freight Waybill
HTTP Hypertext transfer protocol
HWB House Waybill
ICT Information and Communication Technology
ISPS International Ship and Port Facility Security
IT Information technology
KN Kuehne+Nagel
LSP Logistics service providers
NCL North*Sea Container Line
OP Operation Plan
PCS Port Community System
PPP Private Public Partnership
RCS IATA message
RFID Radio frequency identification
SCM Supply chain management
SLA Service level agreement
SME Small and medium enterprises
SoftShip Specialized ERP System
TEU Ton Equivalent unit
TF Tyrholm og Farstad
TIP Transport Information Provider
TL Transport and Logistics
TR Transport Regulator
TSP Transport Service Provider
TSU Transport Service User

ULD Unit Load Device

UNEDIfact EDI format
VHF Very high frequency
WB Waybill
WP Work package
XML Extensible Markup Language
XML Data interchange format

1 Introduction

The Future Internet Public Private Partnership (FI-PPP) focuses on the development of
innovative open network and service ICT solutions with generic common enablers serving a
multiplicity of demand-driven use cases in "smart applications". The work in Objective FI.ICT-
2011.1.8: Use Case Scenarios and Early Trials, focuses on vertical use case scenarios whose
intelligence, efficiency, sustainability and performance can be radically enhanced through a
tighter integration with advanced Internet-based network and service capabilities. The work
includes use case characterization; specification of ICT solution requirements; development
and technological validation of prototypes, and large scale experimentation and validation.

The FInest (Future Internet Enabled Optimisation of transport and Logistics Business Networks)
project aims to develop such an infrastructure on the basis of Future Internet technologies for
the Transport and Logistics (T&L) domain. Modern transport and logistics activity is often a
highly distributed, inter-business activity spanning several countries with each of the involved
business partners aiming at optimizing their individual complex supply and production chains
while not considering what these actions may do to the efficiency of the entire supply chain
process.

The FInest project addresses international transport and logistics businesses that are
concerned with the planning and execution of world-wide shipments of goods. These
companies operate in a highly competitive industry, one that demands novel ICT solutions for
enhancing their inter-organizational collaboration in cooperative business networks.

1.1 Work Package 1

The overall goal of Work Package 1 (WP1): Domain Characterization and Requirements
Analysis, is to determine the generic business requirements for the next generation of ICT
solutions for the transport and logistics domain. In the context of the FInest project, logistics is
considered to be the summation of individual tasks and actions within the supply chain. It
includes all supply activities from planning through execution and delivery completion. WP1’s
purpose is to ensure the suitability of the technological solution that shall be designed by the
project team for satisfying the business needs across these logistics activities.

To ensure a common understanding by all users of the results of the FInest project, the domain
analysis has been conducted with a view towards the development of a shared understanding
of the central domain elements. The identified business requirements form the foundation for
designing the technological solution to be developed in WP3 of the project and the conceptual
prototypes to be designed in WP5 – WP8. The use case scenarios, defined in WP2 of the
project, will be used to demonstrate the ability of these technical artifacts to address the
identified business requirements.

The specific objectives of this work package are, therefore, to:

 Establish a common understanding of the important elements of the transport and

logistics domain,
 Identify the business challenges arising in transport and logistics, and define a detailed
set of business requirements for the next generation of ICT solutions,

 Provide a comprehensive state-of-the-art analysis of ICT solutions for collaboration

and integration that are currently employed in the transport and logistics domain,
 Review and assess the design of the envisioned technological solution with respect to
its suitability for satisfying the identified business requirements, and

 Investigate business models and identify business opportunities for the envisioned
technological solution for involved industries.

1.2 Relationship with other Work Packages

Work packages 1 and 2 (WP1 and WP2) of the FInest project are concerned with collecting
general domain requirements from the domain-partners involved in the project. Domain
requirements are relevant throughout the entire project as the FInest project is – in contrast to
many other research projects – not technology driven, but domain driven. This means that
domain requirements define the need for certain technical services (they “pull” the proper
technology from designers). These services are not pre-defined and “pushed” onto the domain
partners who are then forced to fit them to their business requirements if they can.
Additionally, WP1 and WP2 define concrete use cases that will be applied to demonstrate the
effectiveness of the FInest extension to the FI PPP Core ICT solution and that address the
business requirements of the transport and logistics domain. WP1 and WP2 provide the
essential inputs for all other work packages in the FInest project as displayed in Figure 1.

General Domain
Requirements
WP1 WP2
Concrete Use
Cases

WP3
Business Concrete
Requirements Scenarios
Technical
Governance

WP5 WP6 WP7 WP8

Technical Work Packages

Figure 1: Interactions between WP1-WP3 and WP5-WP8

WP1 is concerned with eliciting and documenting business requirements and to understand
the actual status of current ‚ICT systems for collaboration’. These Business Requirements
provide the overall design goals and rationale for the development of the technical solutions in
WPs 3 and 5-8.

WP2 is concerned with the definition of use case scenarios, which serve two main purposes:

1. They support the refinement and illustration of the business requirements and “state
of affairs” (from WP1), and
2. They are used as demonstration, test and evaluation scenarios for assessment of
prototypes (in WP3) and the design of the experimentation environment (in WP4)

Additionally, WP2 provides a methodology that is used by WPs 5-8 to provide a refined “as-is“
and “to-be“ situation analysis.

1.3 Task 1.2: Detailed Business Requirements Analysis

The Task 1.2: Detailed Business Requirements Analysis aims to identify the detailed business
requirements for various forms of the international and domestic shipment of goods (air, sea,
land, etc.). The requirements documentation is developed based on standard protocols that
the consortium has established for this purpose. The identified business requirements serve as
the basis for designing of the technical solution (WP3) and are addressed for detailed
demonstration and evaluation in particular use case scenarios (WP2), therewith forming the
principal foundation for achieving the objectives of the project.

2 Business requirements for transport and logistics domain

This deliverable will provide the detailed business requirements analysis, presenting the
central result of the domain analysis that forms the principal foundation for technology and
use case scenario design.

The 4phases process model methodology (Section 2.1) has been chosen by the FInest team as
the framework and standard tool for documenting all business process tasks, investigations
and results. To identify the business requirement for the transport and logistics domain, a high
level domain analysis has been conducted (deliverable 1.1). Beside the business requirements
identified in deliverable 1.1, current communication processes and protocols among domain
business partners has been another focus of the research. The messages exchanged,
regardless of the technology used, are crucial elements in the proper execution of a shipment
and without which a supply chain could not function. The evaluation of general business
requirements from the domain and requirements derived from communication flows among
the parties involved in a supply chain act as the input to the detailed business requirements
analysis of this deliverable.

2.1 4Phases methodology

Within WP2 (D2.1) a methodology has been introduced that segregates supply chain activities
into 4 process phases. These phases represent different states of the process and facilitate the
modularization of supply activities.

The 4phase methodology segments a logistics process into four distinct activities. These
activities are:

1. Sales and marketing of the service;

2. Planning of the service execution;
3. Execution of the service; and
4. Completion of the service.

An example of how this approach is used for organization of information concerning domain
processes is shown in Figure 2 following.

Figure 2: FInest domain mapping approach

2.1.1 Sales / Marketing

Marketing, Sales, and Alignment processes are concerned with creating contact between
parties that have a need for transport or logistics services and those who can offer transport
and logistics services that fulfil the demand. This activity consists of the following steps:

 publishing of needs or offered services,

 establishing contact between the parties,
 agreeing on the terms of the service, and
 sale of the service.

2.1.2 Planning
The provision of transport and logistics services is planned and managed based on actual and
forecast demand, information about the transportation network infrastructure, and traffic
conditions. Planning includes decisions about:

 routes,
 schedules,
 service types, and
 utilization of resources.

Shipping consolidation and load/trip planning is the planning of the physical loads for
placement in a transport unit (truck trailer, sea freight container, ULD, etc. depending on the

mode of transport). This type of planning assigns shipments (goods) to a transport mode,
taking into account constraints like pickup and delivery time windows and allowed
combination of goods. Trip planning is used to define the most efficient trip, based on
geographical maps and plans. Combining both load and trip planning is necessary to create the
the most efficient transportation trip.

Load design means to plan how the goods will be stored in the container (three dimensional).
Design is done based on criteria such as sequence of loading and unloading and stackability of
the products. This process can include load design for pallets using alternative stacking
patterns driven by product, customer and transport unit data/constraints.

Route planning is based on the created trip. The actual route is determined by customer
delivery requirements, carrier network design and more granular information depending on
the type of transport being used.

In case the planner’s own equipment is used to execute the actual shipment, the planning
process needs to allocate loads appropriate to the equipment and schedule the correct
operating personnel to the equipment and routes. Constraints that typically can be taken into
account are operating hours, the current location of personnel, equipment and the condition
of the transport equipment.

Carrier selection can include transport mode selection and the selection of the actual carrier.
In its most basic form the planner assigns a transport mode and/or carrier to the shipment.
Decision rules might be used that simplify the selection criteria, such as having an approved
carrier for each mode or lane. It is also possible that carrier selection is supported by tendering
of loads amongst contract carriers or via public tendering on the web.

2.1.3 Execution

The Execution phase begins when work processes are initiated in accordance with the
execution plans and ends when the shipment is completed or cancelled. The execution of the
operations includes movement of goods, cargo handling, document handling, monitoring and
control of operations and goods, supporting effective coordination and accomplishment of the
whole transport chain. This may include transport and terminal operations managed by several
logistics service providers (LSPs). This phase also deals with detection and management of
deviations.

Order entry and consolidation is the registration, validation and management of orders. The
exact content differs considerably depending on the user role; either shippers, LSPs or carriers.
For a shipper it is the key to register the relation between the customer order and the
transportation/orders/deliveries that are being created as part of the fulfilment process.

A logistics service provider typically receives transportation orders from customers, either by
phone, fax, email or electronically. Depending on the activities being outsourced and the IT

solutions used, LSPs and carriers might only get a transportation order, possibly with a
reference to a client customer order.

When dispatching the carriers internal execution resources need to be informed. Confirmation
may need to be obtained, especially when subcontracted carriers are used. At this point
additional information, such as vehicle identification and operator information, might be part
of the confirmation.

The process used to record order status information related to the pick-up/collection and
delivery of shipments is sometimes called the visibility or track and trace process. This process
is used to monitor the execution of transportation and logistics services for every order.
Information captured during this process can be used for financial settlement later.

Global logistic execution/customs and transport documentation generation processes support

international transportation with trade compliance information for import and export. These
processes provide compliance information about rules and regulations and support printing of
specific import/export documents. (Lidasan 2012)

2.1.4 Completion
The completion phase commences when the shipment has been delivered. It includes all
“after shipment” processes such as the handling of payment and claims when the actual
service has deviated from the agreed terms. Note that while the handling of payment for
services may come at any time in the process (e.g. prepayment), it fits in the completion phase
from a logical viewpoint.

2.2 Requirements Analysis

2.2.1 Introduction
This section formulates the high level business requirements. It aims to be self-contained, thus
providing the necessary background, where needed, in order to understand these
requirements. It builds on top of the terminology and the definitions introduced in the
previous sections. An important aspect of the requirements definition at this level is to define
precisely which business problems should be solved in lieu of proposing technical solutions.
This is done by means of describing scenarios, actors, incentives and use cases.

2.2.2 General Requirements identified in the Domain Analysis (D1.1)

Within a supply chain several parties are linked together. These parties have the common
purpose of fulfilling the service requested by a shipper and consignee. Managing the supply
chain requires that certain activities for aligning the partners, suppliers and subcontractor be
carried out. These activities include those of Collaboration, Planning, Resource Management,

Monitoring and Tracking so that the shipment can be observed and actions taken in case of
expected or unexpected deviations from the defined process.

Defining business requirements for supply chain operations, therefore, requires that the
particular supply chain process be documented and the information flows between process
stakeholder be defined. The approach taken in this deliverable was to develop a
questionnaire that asked domain partners to document their current inter-company processes
(intra-company processes were “black boxed” to ensure that competitive internal activities
were not revealed) along with the volume, format and frequency of the information that is
sent between process partners. The goal of the survey process was to describe the
information flow among the partners involved in managing a supply chain so that proper ICT
services can be designed. The assumptions made in using this methodology can be
summarized as:

 Input data is that information that a preceding process steps creates as output so that
the following process step can perform the particular tasks assigned to the step and
generate outputs required as inputs to the next downstream process.
 Output data is the result of certain processes performed by a partner in the supply
chain on the input data, as well as new data generated by the process. It is mandatory
input for the process step(s) that follow.

The data collected in the survey included information about:

 who the sender / receiver of the data was,

 what technology was used to exchange the data (e-mail, fax, EDI, etc.),
 if applicable, which format was used (e.g., ANSIX12, UNedifact, XML, etc.) ,
 the content to be delivered / sent (e.g. order ID, quantity, weight and dims, DG code,
etc. ).

Gaps, missing information that is important for the receiver, was also identified to ensure
that any ICT solution includes this information.

The results of these inquiries form the basis for the information exchange study.

In cooperation with WP2 the use case gap analysis, part of D2.3, has provided very valuable
input and assistance in identifying the detailed requirements. Within the gap analysis, the
investigation and documentation of challanges and root causes in the as-is use case scenarios
has been approached in two steps.

1. Challenges

• Collection and consolidation of Challenges

• Localization of Challenges in the supply chain
• Challenge description (what, why, where, etc)

2. Root Causes

• Hierarchy
• Categorization

All uses cases have been investigated and a certain number of challanges, as well as their root
causes, have been identified. A number of requirements have been identified based on the
work performed in the development of D2.3. While the detailed analysis of the «as is»
processes for each use case is a part of D2.3, the results of this work has informed the work
performed in D1.3 as well.

2.3 Generic requirements identified in the Analysis of the Transport

and Logistics Domain
This section summarizes the findings of D1.1 where generic high level requirements were
identified. These requirements were developed based on an analysis of the current state of the
transport and logistics domain. What is found in the domain today is a complex set of service
providers, shippers, consignees and regulatory bodies interacting with one another using a
fragmented ICT landscape and multiple modes of communication. As has been documented
elsewhere (e.g., Kummer, 2009), in this business domain where information is critical to the
success of shipment processes, the complex, heterogeneous makeup that exemplifies the ICT
and information exchange landscapes means that organizations must develop operational and
strategic “patches” to overcome the various information exchange failures.

The figure below shows the generic requirements identified in D1.1 in relation to the 4phases
process model and the FInest core modules. .

Figure 3: Generic requirements identified in D1.1 Analysis of the TL Domain

3 Generic requirements overview

3.1 Collaboration
Collaboration within the supply chain has two main parts:

1. Business alignment and contracting, and

2. Technical collaboration / communication.

Business alignment part is part of the sales and marketing activities of each party. When
looking for business partners, a supply chain entity needs to have knowledge concerning the
capabilities of potential partners. A service in which both parties could meet each other and
negotiate rates, terms and conditions would be more efficient than the common current
process of calling or sending e-mails to potential partners.

Collaboration requires the definition of information flows between partners. In addition, to

properly collaborate, partners need to define the methods and technologies they will use to
exchange the defined information (Blecker, 2000).

The definition of the information to be exchanged is a basic requirement for all interactive
tasks and action within a supply chain. Information that is required to as input to a task, as well
the information the task has to provide, are mandatory definitions that must be developed.

Communication standards, such as e-mail and fax (basic), or EDI (advanced), need to be
defined. Also, the content of the information to be provided has to be agreed to. With respect
to EDI, the protocol (AS2, FTP, HTTP, etc.) and the message standard (UN/EDIFACT, ANSI X12,
XML, etc.) have to be agreed to among the partners.

While collaboration is a relationship that must be organized between two parties, to efficiently
operate and manage a supply chain requires a more global approach.

3.2 Planning
The main function of planning is to guarantee availability, which is used to procure or produce
the required quantities on time. The planning process includes the monitoring of stocks and, in
particular, the creation of procurement proposals for purchasing and production.

Planning tries to strike the best balance between:

 optimizing service levels, and

 minimizing costs and capital lockup.

These objectives are often in conflict, thus making the planning process a very difficult one to
carry out effectively in complex supply operations.

Planning in a supply chain has two primary tasks. The first is to plan material flows for the
procurement of raw and semi-finished products, the production of goods, as well the
distribution of finished goods and ensuring their market availability. This task is generally
covered by ERP solutions that could provide essential inputs to a global collaborative supply
chain ICT solution.

The second task concerns planning the efficient physical flow of items within the supply chain.
This task requires an overview of available resources, technical constraints/capabilities on the
legs of the supply chain, as well as costs, risks and the points at which responsibilities transfer.

The coordination of several legs in the supply chain requires reliable input from suppliers and
partners. The risk of deviations increases rapidly with the level of uncertainty in shipment data
or transport operator reliability.

Planning is closely linked to resource management, monitoring and visibility. It requires

transparency from all parties involved. Transparency facilitates monitoring, which is
mandatory if one wishes to pro-actively manage their supply chain.

3.3 Resource Management

Resource management is the efficient and effective deployment of an organization's resources
when they are needed. Such resources may include financial resources, inventory, human
skills, production resources, or information technology.

The requirement for resource management within the transport and logistics domain consists
of:

 demands for various resources based on shipment type, logistics process, etc.,
 forecasts of resource demands by time period,
 resource configurations required based on demand requirements, and
 resource availability based on demands, again forecast by time period into the
future.

The goal of resource management is to achieve 100% utilization of each resource, but this goal
must be traded off against other constraints such as maintenance requirements, service level
impacts and costs.

Efficient resource management is a key factor in the successful operation of a supply chain. It
is also a critical component of any planning system used to plan supply chain operations. Since
resources must be planned and consumed in each step of supply chain operations, the
requirement for resource management demands that there be transparent access to resource
requirements for each task, the availability of appropriate (and alternative) resources for each
task (by partner), the constraints that impinge on each resource by task, the costs of each
resource, their capabilities, etc. Resource management is an essential part of the planning.

3.4 Monitoring and Visibility

Management of the execution activities within a supply chain requires access to information
about where shipments are, what state/condition they are in, notifications about status
changes and any one of numerous other pieces of real time information concerning the
shipment. Since there are numerous partners providing services during the shipment of
goods, there are several ways to retrieve the necessary information from the business
partners. (E-Freight, 2012)

The events to be monitored are different for each party involved in a shipment. This means
that information can be provided in different formats with different levels of timeliness.
Systems that are used to address these varying requirements for status and notification data
should be flexible and have the ability to be configured appropriately for the event being
monitored and tracked.

3.5 Targets to be achieved

Along with the high level generic requirements identified in D1.1, a set of objectives, or
targets, was developed in that deliverable for the FInest project. These targets are discussed
briefly in the paragraphs that follow.

3.5.1 Simplifying the ICT landscape

SCM software is a highly fragmented collection of software applications. Each of the major
supply chain transport and storage modes is composed of dozens of specific tasks, most of
which have separate software solutions. Organizations need to track supply, demand,
manufacturing status, logistics and distribution on a real-time basis. They also need to share
data with supply chain partners at an ever increasing rate. Vendors assemble these different
chunks of software under a single roof, but no single vendor will have a complete package that
is right for every company. (OECD,2012)

3.5.2 Reduction of manual input and tasks

While the ICT landscape within the transport and logistics domain is highly fragmented, the
physical processes performed by those providing execution services is also fragmented. This
leads to the requirement of employing multiple organizations in any international shipment of
goods. Each of these organizations have their own information processing systems that may,
or may not, be integrated. The need for multiple organizations to perform execution tasks, the
highly fragmented nature of the ICT landscape and the lack of common standards contribute
to numerous manual information exchange and input processes. (Freightwise, 2006) This
reality requires that any system developed in the FInest project should take as a target the net
reduction in manual input required to maintain accurate information for system partners.

4 Communication / Information Exchange

Building a well-organized supply chain requires a well-defined communication mechanism to

provide a precise and complete set of definitions for both business communication and
transaction data. A common communication mechanism is needed to manage individual
member companies. It can also be useful for creating an operation strategy in a supply chain.
Furthermore, the data specification for the chain can be used to support the design of a
distributed database among companies using Electronic Data Interchange (EDI) or an internet
protocol. There are several information modelling methodologies, modelling languages, and
implementation methods available to support the development of such communication
mechanism. The approach to developing this communication mechanism and the data
specification are listed here:

 Perform case studies to investigate a real supply chain system.

 Identify the scope of the target application.

 Identify core processes of supply chain management.

 Analyze communication data flow.
 Layout data specification.

This deliverable provides a generic specification of supply chain management data with which
the supply chain members use to communicate with one another.

4.1.1 Data Flow

The transport and logistics domain is highly fragmented with a large number of participating
companies in all sizes, offering numerous different services and approaching the marking in
various levels of capabilities and professionalism (Kaltenbrunner, 2012). To manage the
complexity that this highly fragmented structure yields requires smooth data exchange
between partners so that each partner can do their part in fulfilling the supply chain’s
objectives. Unfortunately, data flow becomes more fragmented and difficult to align with the
supply chain’s overall objectives as the number of heterogeneous parties involved in the
transport process increases. This is one of the main issues in the set up and execution of
modern supply chains (Evangelista, 2012).

Figure 4: Data Flow Example (MARINTEK, 2011)

As an example of how quickly fragmentation of partners and activities within the supply chain
can lead to complex information exchange patterns, take a small slice from the activities that
occur in shipping fish from Norway to Brazil. The figure above is taken from the gap analysis of
Use Case 1 in the FInest project (D2.3). This figure shows just a small part of the of the
complete use case process (the scheduling of ship into port for unloading and loading), but

displays the complex and fragmented communication processes among the partners and their
ICT systems.

Figure 5: IBM and KN Secure Trade Lanes Project

Figure 5 above shows the complex relationships among partners when attempting to clear
customs. This complex process occurs in parallel to the process noted in Figure 4 and is
performed by an entirely different group of actors using entirely different systems from those
used by the ship captain, the port and the terminal operator. Complexity is layered on top of
complexity at each step in the supply chain creating a significant challenge for any supply chain
manager to keep track of their goods and ensure that they arrive at the required destination at
the right time. Expanding this complexity on a global scale indicates that the effort to
seamlessly share information and align partners in a global shipment process is an extremely
difficult task given current approaches to communications and data management.

Within this deliverable the information flow of the three FInest use cases will be used as
examples for documenting the concrete information flows in a supply chain. These use cases
will also be used to document the content of the information being exchanges as well as the
technologies typically employed for exchanging and managing this information.

4.1.2 Communication Analysis

Based on the use cases chosen for the FInest project, detailed requirements have been
developed through an in depth analysis of each use case scenario. The flow of information

among the parties with regard to tasks and actions has been used as the foundation for
business requirements to establish a supply chain. The information exchange that is required
to execute the tasks identified in the use case scenarios enables the parties to collaborate,
plan and manage resources while monitoring the flow of goods through their supply chains.
The next section of this report documents the requirements that have been derived from this
analysis.

5 Use case requirement analysis

Based on the results of Work Package 2 “Use Case Specification”, and especially based on
deliverable D2.2 “High level specification of use case scenarios”, this chapter will describe the
resulting requirements identified for each of the three use cases. The following table
summarizes the high level requirements determined in WP2 – Root Cause Analysis.

Use Case 1 Use Case 2 Use Case 3

Fish Transport from Norway to Air Transport – Import from Global Consumer Goods
the EU Asia to NL Production and Distribution

 Centralized and improved  Event-driven monitoring and  Better overview over

exchange of information: tracking of logistic processes available capacity /
right information, right  Collaboration manager (A availability
time, easy access, higher standardized  Real-time tracking and data
coordination among all communication interface visibility
involved actors. between all participants)  Automation of information
 More automation of  Transparency and documents exchange
information registration  Pervasive RFID structures  Ensure security in
(reduced manual work)  Real -time Tracking and information transfer
 A system adapted to current Tracing  Legal documents: need for e-
systems in place  Clear responsibilities# transfer of legal documents
 Online Booking  Predictability  Integration with the data
 Improved predictability of  Resource overview systems with the partners to
market demand (Statistics, reduce manual inputs
forecasts, market portal)  Need to access the right
 Enabling high cooperation information
and capacity overview and  Needs an alert system which
management (resource hub; gives info on deviations,
one virtual meeting place and/or periodic reports
for all actors)  Foresee possible bottlenecks
 Increase transparency and & problems to take action
enable flexibility on-time
(Networking/pooling could  Re-planning of the routes
be a valuable strategy) when deviations from the
 Facilitate Port Call and more plans
flexible use of slot-time  Need less manual work
(need more coordination)  A unique reference number
 Improved handling of which can be used to trace
deviations; Better the materials/products and
monitoring and immediate data associated with them

treatment of information through all the phases of the

(e.g. PTI check) transport
 Real- time tracking of  Visibility on environmental
container and vessels carbon footprint and
around the world. reduction of carbon
emissions

Table 1: High level Use Case Requirements

As one can see, the requirements of the different use cases are either the same or strongly
correlated with one another. This indicates that many of the seemingly different modal
requirements could be fulfilled through a few common, but configuration, features in an ICT
system.

Because of these observations, a requirements analysis has been performed for each of the
three use cases with a focus on ICT. Several interviews with each domain partner who is
involved in one of the use cases were performed to gather all the needed information
regarding processes and information flows in their respective supply chain scenarios. A set of
core processes in the use cases was identified. The input and output flow of information in
these processes between the different stakeholders was categorized and analyzed. As a result,
the information required for the integration of this processes in an ICT system has been
identified. These information requirements are a set of different kinds of messages that are
exchanged or shared among all stakeholders through different communication channels.

The information flow of each use case was examined for the amount of three kinds of
information that are necessary to transport every kind of good:

Addresses:

Addresses can be the address of the shipper or the consignee, which identifies the start and
end points of the transport chain or, for example, the port of loading / discharge or an airport
or any other stopover in the chain.

Freight details:

Freight details include the basic facts concerning the goods that have to be transported. This
could be the measurements (volume / size / weight / etc.) or the number / type / weight of
containers that have to be shipped, depending on the use case.

Time:

Information about time contains the date of the start / end of a shipment and estimated times
of arrival / departure.

These three kinds of information have been identified as the most important information types
in every use case. It does not matter by which means goods have to be transported, without
knowledge about addresses, details on cargo and critical times in the supply chain it is not
possible to effectively execute a supply operation. Using this fact as a basis of analysis, each of
the FInest use cases business requirements (documented in the next sections) were analyzed
and a set of requirements for the FInest ICT solution was developed.

5.1 Use Case 1 – Fish Transport from Ålesund (Norway) to Brasil

Figure 6: Big picture Use Case 1

This first of the FInest use cases consists of the export of fish in containers from Norway to
Brazil. The business process is documented above in Figure 6. The project partners
represented in the use case are the shipping operator (feedering operations) NCL, the
container terminal operator Tyrholm & Farstad , and the Port of Ålesund. The use case focuses
on the parts of this chain in which the three domain partners are engaged in order to highlight
their main processes and challenges, but especially the interaction among these three actors

Figure 7: Information Flow UC1 1

As depicted in Figures 7 and 8, and refined in the detailed process flow analysis in the
appendix, a large amount of information is carried through this link in the transport chain.
Because of the importance of information to effective and efficient execution of these
partners’ operations, it is critical that every message reaches the intended receiver at the right
time. For example if customs is not informed about the kind of goods that are being imported
before they arrive, the whole transport process is forced to pause until the shipment is
inspected, the proper paperwork received, reviewed and signed off and the goods get
released. By evaluating the data that is exchanged it comes clear that some kinds of
information are transmitted more often than others.

Figure 8: Information Flow UC1 2

Based on the analysis of gaps or current challenges that the partners have experienced, a set
of requirements and potential ICT “solutions” were developed. A summary of this information
appears in Table 2 following.

Challenge Needs Possible IT Solution

Late cancellations: A. Open reservation of capacity Online Market place:
(Maintain flexibility for •Collect and display transport needs and
Dummy booking +
customers) transport services offer

No-show

B. Alternative cancellation Booking Manager:

windows & price models
(Incentives for less •Register booking according to status (reservation
cancellations) / confirmed booking)
•Impossible to register several identical bookings


C. Early warning of cancellation Booking manager:

(for longer reaction time and •Register cancellations and update of booking list
replanning window)
•Simultaneous warning of all actors (forwarder,
shipping agents, terminals)

D. Search for new alternatives Match maker
with match

(find replacement to the •Integration with external market places

cancelled booking)
•Identify available capacity short time before
departure
•Identify pending transport needs
•Suggest best match
•Send offer to shipper on behalf of carrier (both
replacement bookings and rebooking of cancelled
shipment)

E. Offer alternatives to keep 
cancellation
(to minimize the consequences
of cancellations)
•Real- time information Early-warning:
•Immediate notification of Signalising any cancellation of booking
Change in booking changes in TEP
(Late notification)
•Single source of 
information
•Improved planning •Booking manager (carrier-shipper) with more
upstream i SC binding booking
•Reduce number and •Match maker (carrier-shipper) enabling last
frequency of cancellation minute booking of available cargo at terminal
Late Changes in •Reduce number of late 
Booking cancellation
•Enable the quick
replacement of cancellation
with cargo available at
terminal
• Less one-to-one -Integration with backend system
communication
• single information source -Standard e-document (lad/ldis charge list and
booking list) for automatic transfer and registration
Information
Exchange • Less manual processing of
data
• standard format
•All trucks equipped with PC to
remove paper communication
Early warning Port traffic information platform:
Single information source •Combining all information and real-time data
related to port call and maritime traffic
•Provide up-to-date info on planned port calls
Ship delay
•Sends automatic warnings in case of changes in
ETA/ETD (event characteristics to be defined by
receiver of warning)

•Early warning Early warning from cargo owner
Cargo delayed
•Right data

LOW AWARENESS •More coordinated

ABOUT SEA marketing of sea transport A "information centre" for the entire maritime
TRANSPORT transport community, combining:
LOW USE- •Simplified regulations
FRIENDLYNESS -up-to-date information on any TSD
•Centralization of
information -Simulation tools (as a support for TEP)
INCOMPLETE •Centralization of
OVERVIEW OF information (one place) Partly presented in DEMO2 (only for
PORT & TERMINAL information on destination (port & terminal services) 
SERVICES •Easy-to-find information
•Centralization of real-
time data
•Support for
benchmarking of services
•Support for planning
BOOKING PORT / •A single login for any A "booking portal"enabling:
TERMINAL registration of port call and
SERVICES: LOW booking of all related services
USER-
FRIENDLYNESS •A single platform for any -Captain or ship agent to register all information
destination (port/terminal) related to port call in a same place, both legal and
commercial information.
•Harmonization of -Access to all existing registration systems (SSN),
information (voyage nr) and
messages
•Automatic retrieval of -Send booking request and automatic updates to
information from existing the concerned suppliers/stakeholders,
systems
•Booking based on real- -The port/terminal service suppliers to confirm
time information on resource booking directly in the platform.
availability
•Handling of booking -Access to real-time information about resource
confirmation availabilities so that the booking can be as accurate as
possible.
•Centralization of -Prepares a resource plan centralising all
reporting resources booked, and showing real time status of
resource booking.

Single window for centralizing all mandatory legal
reporting
Already tackled by SingleWindow concept (e-
Freight/e-maritime) 
LATE OR NO •Notification asap of any A "booking portal" that allows for:
UPDATES OF PORT changes in ETA / ETD
CALL AND •Notification asap of any -direct updates in plan,
BOOKINGS OF changes in services / resources
SERVICES needed
•Correct information -Automatic reception of deviation messages
(directly from AIS system, or other local system etc)

•Centralization of -Distribution of warning msg, so that all

information concerned stakeholders receive notification about
updated information at same time and from same
source..
DEVIATIONS IN 
BOOKINGS (NEED
REPLANNING)
RESOURCE •Up-to-date information A "booking portal" that:
UNAVAILABILITY about all port & terminal
resources available
•Access to this information -Indicates the real-time information about
at the time of booking resource availabilities so that the booking can be as
accurate and immediate as possible.
•Automatic warning of -Coordinate the bookings and sends the booking
resource unavailability, request automatically to the suppliers; and register
automatic change in resource confirmations.
plan or need for the ship to
rebook resources.
-Prepares a resource plan centralising all
resources booked, and showing real time status of
resource booking.

LACK OF •One place featuring all A "resource coordination" portal :
SYNCHRONIZATION services and resource available
OF RESOURCES in real-time
•Accessible by all service -Collecting / with access to all information about
suppliers from a single service suppliers, by destination
destination (port call)
•Connection to all -Access to real-time information
local/back-end systems
-Enable automatic sending of booking requests to
suppliers
-Enable booking confirmation through the portal
(less dependency on back-end systems)
-Able to prepare resource plan based on any
booking criteria and constraints .
-Provide information to suppliers about all port
calls and related resources requested / booked.

Table 2: Challenges and needs UC1

5.2 Use case 2 – Air Transport of Equipment

Figure 9: Big picture Use Case 2 (IATA, 2011)

The second FInest use case is covered by the companies (Kuehne+Nagel and AirFrance-KLM
Cargo) representing the two main roles in the transport chain. Focus has been put on
describing a complete door-to-door transport chain by dividing it into three main parts:

1. Shipper to Carrier,
2. Carrier process (Forwarder to Carrier, then Carrier to Forwarder), and
3. Carrier to Consignee.

Figure 10 shows the standard flow of documents that occurs in the airfreight shipping process
used for the FInest use case. This flow has been established by work of member of the
International Air Transport Association (IATA) and is one of the few true standards in any of
the international shipment processes.

Figure 10: Document Flow Airfreight (IATA, 2012)

Note: 0,n means that there may be no associated documents but possibly more, i.e. zero to many
1,1 means that there must be only 1 associated document, i.e. one to one
1, n means that there must be at least 1 associated document but possibly more, i.e. one to many

The various documents that are exchanged in Figure 10 are described below (note that this
information is provided to maintain the self-contained nature of this document. This
information is available in the FInest domain dictionary at www.finest-ppp.eu).

Air Waybill:

A shipping document used by the forwarders and airlines for air freight. It is a contract for
carriage that includes carrier conditions of carriage including such items as limits of liability
and claims procedures. The air waybill also contains shipping instructions to airlines, a
description of the commodity and applicable transportation charges. Air waybills are used by
many truckers as through documents for coordinated air/truck service. Air waybills are not
negotiable. The airline industry has adopted a standard formatted air waybill that
accommodates both domestic and international traffic. The standard document was designed
to enhance the application of modern computerized systems to air freight processing for both
the carrier and the shipper.

Flight Manifest:

Details of consignments loaded onto a specified flight.

House Waybill:

Document made out by an agent / consolidator which specifies the contract between the
shipper and the agent/consolidator for the arrangement of carriage of goods

House Manifest:

Document containing the same information as a cargo manifest and additional details on
freight amounts, etc

Receipt for the Cargo:

A document which is provided to the shipper, upon shipper’s request, by the Carrier creating a
shipment record as a substitution for the issuance of an air waybill and which permits
identification of the shipment.

Shipment Record:

Any record of the contract of carriage preserved by Carrier, evidenced by means other than an
air waybill.

The Shipment Record is initiated by the FWB information and confirmed or modified by the
subsequent FSU(RCS). FSU/RCS would only modify the information regarding Total Number of
Pieces, weight and Volume Amount of the shipment. Only at that time the Cargo Contract shall
be deemed concluded.

FFM Message:

The FFM message provides the details of consignments loaded onto a specified flight. It is the
electronic message of the Flight Manifest.

FHL Message:

The main objective of the FHL message (type 1) is to provide a “check-list” of Freight
Forwarder house waybills associated with a Master Air Waybill.

A second type of FHL (type 2) has been accommodated to provide details of one House Waybill
consignment in order for the carrier to provide Customs with advance information based on
the house waybill information provided by the origin freight forwarder.

Under IATA e-freight the IATA Cargo-IMP Consolidation List (FHL type 1) message serves as the
house manifest document.

FWB Message:

The FWB message is used to transmit a complete set of Air Waybill data in accordance with the
IATA Cargo Services Conference Resolutions.

FSU(RCS) Message: The FSU message is used to notify/update interested parties with a (change
of) status of a specified consignment as recorded in the system of a handling party.

The standard code “RCS” specifies that “The consignment has been physically received from
the shipper and is considered by the Carrier as ready for carriage on this date at this location".

FHL’ Message:

For the purpose of these specifications, the message that contains House WayBill (HWB) data
sent by the Origin Freight Forwarder with potential updates made by the Origin Ground
Handler.

FWB’ Message:

For the purpose of these specifications, the message that contains Air WayBill (AWB) data sent
by the Origin Freight Forwarder with potential updates made by the Origin Ground Handler on
data such as weight, number of pieces, volumes. (IATA, 2012)

Some of the documents shown in Figure 10 already have an electronic standard message
format developed through IATA:

 Flight Manifest (CIMP-FFM),

 Air Waybill (CIMP-FWB),

 Shipper’s Declaration for Dangerous Goods (CIMP-FDD or XML-SDDG).

 House Manifest (CIMP-FHL),

 House Waybill (CIMP-FZB),
 Invoice (XML),

 Packing List (XML),

 Certificate of Origin (XML),

Generally, the Flight Manifest is a list of all Air Waybills that are loaded onto a specific flight.
The Shipper’s Declaration or Dangerous Goods is associated to the Air Waybill.

The flow of information required to ship goods by air, while relatively well documented (Figure
10) is still open to implementation interpretations. Those documents that are exchanged that
have not been standardized in message form by IATA are still exchanged in formats that vary
by partner. In addition, even though IATA has defined standard electronic formats for many of
the documents, not all partners are able to exchange information in electronic form. This
leads to many paper based documents being exchanged and numerous manual data entry
processes in a normal goods shipment.

Based on the detailed root cause analysis conducted in WP2, the following challenges have
been identified:

 Order management: From booking to actual receipt

 Better information availability for local authorities ahead of shipment

 Monitoring and visibility of shipment

 Deviation management
 Optimize data quality

Similar to the first use case, analysis of the business processes results in different kinds of
requirements that are listed in Table 3.

Challenge / Root Causes Needs Ideas for solutions

•Volatile Market •Correct booking •A collaboration platform that delivers in real time
demand information information to all parties in the supply chain chain,
when a deviation occurs in the process from booking to
the actual shipment.

•Forget to communicate •Being informed about •A booking intelligence applications who combines
due to daily operational changes as soon as booking information from different supply chain
priorities possible/when the moment partners and gives a trigger when inconsistencies occur.
it occurs For example: products, dimensions versus weight.

•Human Errors, wrong

processing of
information/data input
•Not informing other
partners about changes
•Traffic Jams
•Measurements often •The right dimensions of •Weighing at the source / shipper, sharing via the
are bottle neck, creating the freights, on different Finest Platform to all relevant parties.
wrong dimensions for aggregation levels, from
further planning smallest package to total.
•Information too late •Information being •A collaboration platform that delivers in real time
available exchanged with several information to all parties in the supply chain chain,
supply chain partners, including authorities. This system also monitors
including authorities, deadlines and gives triggers on time when information
without or with a minimum needs to be sent to be in the ‘safe zone’
of human interface

•Missing or Wrong •The right information •Data quality management in within the platform
information on time in full •Next “step” in transport can only be initiated if all
necessary input (correct, weight, dimension etc) is filled
in
•Shipper not aware of • Shippers and •A push system for shippers & forwarders regarding
information needed or forwarders fill in and the right information delivery system. Based on the
documentation deliver all the required booking & product, the system forces the shipper to fill
documents in all relevant documents.

•Data Quality existing •Time stamping done •A collaboration platform that collects data from
measurements without human interface containers via tags. This should be a solution where the
internet of things is combined with the Finest
Collaboration Manager to exchange the data.
•Not enough milestones •Time stamping done •Use of RFID chips included in every shipment
without human interface

•IT capabilities Supply •Low threshold tooling •A Collaboration Platform, accessible via the internet
Chain Partner available for supply chain where tooling can be downloaded and used.
partners, via internet.
Assumption: all partners
have access to internet

Table 3: Challenges and needs UC2

5.3 Use case 3 – Global Consumer Good Production and Distribution

Use Case 3 „Global Consumer Good Production and Distribution“, can be divided into two
main scenarios, the export of finished goods and the import of raw materials for production.
These two scenarios are described below.

Figure 11: Information Flow UC3 Export (ARCELIK, 2011)

Finished goods are loaded into containers and containers are transferred to the port of loading
(Gemlik Port) in Turkey. After customs clearance at Gemlik Port, they are loaded on a vessel
and shipped to the UK. After the vessel has arrived in Felixtowe Port in the UK, containers are
unloaded from the vessel and transferred to the warehouse of customers after customs
clearance.

Figure 12: Information Flow UC3 Import (ARCELIK, 2011)

Purchased items (raw materials) from the material supplier in Korea are loaded into containers
and transported to the port of loading (Busan Port). Then containers are customs cleared and
loaded on a vessel and shipped to the Gebze Port in Turkey. After the ship has arrived in
Gebze Port, the containers are unloaded from the vessel to the unloading area at the port.
They are then loaded onto a truck and transferred either to a bonded warehouse or to a
normal warehouse after customs clearance.

The following table summarizes the requirements that have to be addressed regarding Use
Case 2 for both Import and Export processes.

Challenges Needs Ideas for solutions

INFORMATION •Visibility of the status of the A “monitoring” portal:
INACCURACY shipment (considering the
points of interest, comparison
with pre-defined transit time
etc.)
•Right data, standard format, •Takes (semi) automated input from the tracking
on-time systems of logistics service providers regarding the
status of the cargo
• Status of the cargo (or event) is visible to all
relevant parties on their request (search option)

• (semi) integration with ERP systems so that

electronic extraction of data can be realized
•A manual input taking option for cases where
electronic data extraction is not possible
• Standardized format for manual inputs where
system gives alerts if the input is not inline with
the standards defined


DATA COLLECTION AND •Right data, standard format, A platform that supports automatic data transfer
PROCESSING IS COMPLEX on-time regarding the status of the cargo & deviations and
AND TIME CONSUMING creates alerts for deviations:
•Less manual communication • Data sharing through one channel leads to one
truth for all the relevant parties hence data is
retrieved from one source
•Less manual processing •Enable defining points of interests/alert rules
•Trigger re-planning with •Enable defining expected performance criteria
ease (less man hours spent) for points of interests
•Workload monitoring •Real-time alerts for deviations are generated
automatically by comparing actual performance
with expected performance criteria and alerts are
notified to the transport planner and other related
parties
• In case of critical deviations (alerts) system does
not allow further processing without confirmation
• Alerts that are directly connected to re-planning
• Automatic record of changes (e.g. a change in
ETA results in change in plans and change in
records)


Delay in document/data • Less manual communication A portal that facilitates document exchange:
transfer • Information sharing • Automated creation and electronic transfer of
through one channel some documents through integration (e.g. Freight
invoice, B/L, Packing List etc.)
• Less manual processing of • Monitoring the status of document transfer
data
• Alerts for delays in • Automatic alert creation for delays in document
document / data flow transfer and responsible are notified
Incorrect document/data • Right data, standard A portal that:
format, on-time • Checks the correctness of documents (e.g.
Compares the Freight invoice with agreement in
the contracts)
•Standardized format for documents where
system gives alerts if the input is not in line with
the standards defined
Manual data registration • Less manual data A portal that:

processing • Automatically links the data/documents to

purchase/sales order ((Semi) Automated Input &
(Semi) Integration with ERP systems
Legal restrictions • E-document -
• E-customs
DATA COLLECTION & • Right data, standard A “booking” portal:
PROCESSING IS COMPLEX format, on-time
AND TIME CONSUMING • Overview of schedules, • Enables extracting transport demand data from
FOR TRANSPORT voyages, transshipments ERP systems through integration
PLANNING
• Overview of contracts • Enables manual inputting transport demand
data or uploading it using a standardized
template where electronic extraction is not
possible
• Less manual communication • That takes service information electronically
from LSPs (schedule, voyage details etc.)
• Less manual data • Creates overview of alternatives using contracts
processing (e-contracting) and criteria defined (best price,
best lead time etc.)
• Planning & booking with • Provides cost estimation to transport planner
ease
• Booking confirmation & • Enable automatic sending of booking requests
billing with ease to logistics service providers when planning is
completed
• Transport plans overview • Enable booking confirmation through the portal

• Open orders and shipments • Enable monitoring the status of the booking
status tracking

COMPLEXITY OF • Overview of contracts A “booking” portal:
PERFORMANCE • Data handling for • Takes agreed performance criteria from the
OVERVIEW performance calculation contracts
• Less manual data • Historical booking / transport data recording
processing
• Contract based control with • Calculating KPIs comparing agreed performance
ease with actual performance for the transport plan
(automated contact based control)
MANUAL PROCESS OF • Overview of contracts A “booking” portal that facilitates spot buying:
SPOT BUYING • Less manual processing • Publish the service request on market place
• Get quotations
• Enables sending booking requests to spot service
providers
• Enable booking confirmation through the portal

• Enable monitoring the status of the booking



DELAYS IN INFORMATION • Less manual communication A “monitoring” portal:

FLOW • Information sharing • Takes (semi) automated input from the tracking
through one channel systems of logistics service providers regarding the
status of the cargo
• Less manual processing of • Status of the cargo (or event) is visible to all
data relevant parties on their request (search option)
• (semi) integration with ERP systems so that
electronic extraction of data can be realized
• A manual input taking option for cases where
electronic data extraction is not possible
• Standardized format for manual inputs where
system gives alerts if the input is not inline with
the standards defined
• Creates alerts for delays in information flow (e.g.
Status of the cargo has not changed for 3 days)
 Planned to be included in DEMO for
AUTOMATED SHIPMENT TRACKING (After M12)
LIMITED EARLY WARNING • Early indicators A “platform” that:
MECHANISM • Enables defining points of interests, early
indicators /alert rules
• Enables defining expected performance criteria
for points of interests
• Real-time alerts for deviations are generated
and notified to the transport planner and other
related parties
• Enables sharing disruption information / critical
changes at early indicators through one channel

• Ability to determine which operations are

affected in case of disruptions


DELAYS IN RE-PLANNING • Right data, standard Direct link to “monitoring” portal to “booking”
format, on-time portal:
• Overview of schedules, • Trigger re-planning using the real-time alerts
voyages, transshipments and
contracts
• Less manual communication • Option to close/cancel the alert if the change
does not require re-planning
• Less manual data • Creates overview of alternatives using contracts
processing and provides cost estimation to transport planner

• Re-planning & re-booking • Enable automatic sending of booking requests

with ease to logistics service providers and getting booking
confirmation through the portal
• Transport plans overview • Enable monitoring the status of the booking
• Open orders and shipments • If the booking is cancelled or updated, informs all
status tracking the relevant parties

LACK OF A FAST AND • Real- time visibility of A “appointment making” portal for loading &
CONVENIENT information unloading:
APPOINTMENT MAKING • Timely monitoring of • Linked to “booking” portal
SYSTEM vehicles on road
• Advanced shipping • Automatic information input from “monitoring”
notifications portal regarding the status of the shipment

• Defined resources • Real- time updates depending on status of the

shipment
• Defined constraints • Facilitates communication between
shipper/consignee and logistics service provider
• Integrated systems with • Enables appointment making on the defined
actors involved time interval depending on capacity and working
hours of warehouses and local regulations
• Pre- organized daily schedules for a frozen
period
• (Semi) automated prioritization of loading &
unloading depending on constraints defined

Table 4: Challenges and needs UC3

The outcome of this detailed analysis of the business needs in the use cases clearly is that the
main requirement is the availability of basic product and status information throughout the
supply chain. This means a solution is needed for all stakeholders that provides them with
access to this information in an easy and comprehensive manner.

5.4 Message detail consolidation

After analyzing and comparing all the messages in the information flows for each use case (see
the Appendix to this deliverable for the detailed information on data that is passed between
partners in each use case, its format, the source of the elements in the data and the recipient
of the processed data) , the assumption that the most important kinds of messages concern:

 Address (shipper / consignee …)

 Freight details (weight / volume…)
 Time (ETA / ETD…)

appears to be valid. These messages are important for each party because they are essential
for the proper execution of each process step. The following figures show the large proportion
that messages focused on these three areas are of the total volume of messages exchanged
between partners for each of the use cases.

The information flow of Use Case 1 is divided into two parts: the flow of information in the
port and the flow in NCL.

Port information flow

Total

Time

Amount of messages
Info about goods

Address

0 10 20 30 40 50

Figure 13: UC1 Port Information flow consolidation

The total number of different message types exchanged by the port is 39. 15 messages contain
address related data, 16 messages contain information about the goods and 26 are related to
some aspect of time.

NCL Information flow

Total

Time

Amount of messages
Info about goods

Address

0 5 10 15 20 25

Figure 14: UC1 NCL information flow consolidation

For the NCL information flow there are a total number of 23 messages exchanged. 11
messages contain information about the goods as well as address information and 6 messages
contain information about time.

Use Case 2 - Air freight

Total

Time

Amount of messages
Info about goods

Addresses

0 5 10 15 20

Figure 15: UC2 information flow consolidation

The information flow in Use Case 2 consists of 19 messages of which 10 contain data regarding
time, 8 include information about goods and 9 contain essential addresses.

Use Case 3 information flows are split into Import and Export flows.

Arcelik Import

Total

Time

Amount of messages
Info about cargo

Addresses

0 5 10 15 20 25 30

Figure 16: UC3 Import information flow consolidation

The import process includes a total of 24 messages. 20 contain information about time, and 15
about the cargo and addresses.

Arcelik Export

Total

Time

Amount of messages
Info about cargo

Addresses

0 5 10 15 20 25

Figure 17: UC3 Export information flow consolidation

For the export process there are 23 messages used. 10 messages contain information about
time, 11 about cargo, and 12 messages include addresses.

The diagrams above show that in every use case there are similarities in the type of
information that is exchanged between partners. While formats vary for this information, it is
clear that similar information is required by each partner and this observation provides a
valuable input into any ICT solution that will result from the FInest project.

Closely examining the consolidated needs developed in cooperation between WPs 1 and 2 it
has become clear that many issues identified can be solved by bettering the flow of
information and making common information available for every stakeholder whenever it is
needed.

Needs Business Functions

Easy-to-find real-time information on available services for enabling voyage CENTRALIZATION OF
planning, and overview of transport demand INFORMATION
Single information source for all parties, less one-to-one communication CENTRALIZATION OF
INFORMATION
Overview of contracts CONTRACT OVERVIEW
Improved planning upstream i SC and reduce cancellations by PLANNING
implementing alternative cancellation windows & price models
Transport plans overview PLANNING
Booking based on real-time information on resource availability, PLANNING
Synchronizing of resources and automatic resource planning
Booking with ease, Less manual communication BOOKING
One place featuring all services and resource available in real-time REAL-TIME
accessible by all service suppliers from a single destination INFORMATION
AVAILABILITY
Single platform for port call & service booking at any destination ONE STOP SHOPPING
Visibility of the status of the shipment (ref points of interest) VISIBILITY

Contract based control with ease PERFORMANCE

MANAGEMENT
The right information and documentation on time with Alerts for delays in INFORMAITON
document / data flow REALIABILITY
Correct booking information INFORMATION
RELIABILITY
Detection and immediate notification of deviations. Real-time information SIGNALING
Handle late cancellations (rebook and find replacement) CAPACITY UTILIZATION
Trigger re-planning with ease REPLANNING
Less manual processing of data, minimum human interface AUTOMATED DATA
GATHERING
Time stamping done without human interface AUTOMATED DATA
GATHERING
Links between documents / messages ELECTRONIC
INFORMATION
AVAILABILITY
Low threshold tooling available for supply chain partners, via internet. ONLINE APPLICATIONS
Assumption: all partners have access to internet
Immediate and fast communication between supply chain partners when COLLABORATION
deviations occur

Table 5: Needs related to business functions

6 Detailed Domain Business Requirements

Merging the identified general requirements with the results of the investigations of the
information flows facilitates detailing the business requirements for domain operations in a
more detailed way. These descriptions of the requirements will be used for further
investigations and assessments of existing or future ICT applications.

6.1 Business Collaboration

Business relationships and cooperation on a global level requires communication and
coordination of tasks and events. The related parties have to collaborate intensively. Manual
interaction causes a lot of time consuming and inefficient manual effort. A collaboration ICT
solution allowing parties to establish smart modes of interacting and that facilitate the easy
exchange of information is required. Easy exchange of information requires that electronic
message formats and protocols must be established/used and instantiated in the ICT solution
to ensure that all parties can communicate and that messages are really exchanged in a timely
and automated fashion.

6.1.1 Business alignment

Finding a business partner and figuring out their capabilities is not easy in a global
environment. SMEs face particularly difficult problems as they do not cover the globe with
branches, contact offices or representatives who could provide an insight into the local or
regional markets and know about possible qualified partners or sub-contractors. (Alt, 2012)

A collaboration ICT solution will assist companies in identifying potential partners for transport
and logistics operations that have the skills, resources and capabilities to execute the specific
supply chain activity required, no matter where in the world the activities is required. The
solution should also assist in qualifying the potential partners so that historical performance
with similar activities can be assessed and informed partnership decisions made. Finally, the
solution should provide the individuals with information about what will be required to
consummate a partnership (e.g., legal requirements depending on the partner’s location and
business practices). Such an ICT solution will need to provide for, and manage, the different
stages of partnership development and relationship execution.

To facilitate partnership development, the solution should provide potential partner

organizations with the ability to list their services, capabilities, business rules, legal
stipulations, etc. in a directory. This directory would be searchable using standard search keys
for partners by type, service, location, scope of services, capabilities, ratings, etc. Membership
and access to the directory should be controlled so that only “approved” entities can be listed
or view the information in the directory.

6.1.2 E-market place

When partners are not available through the solution directory, the ICT service should
facilitate or provide the use of an eMarketplace for bidding out requirements and obtaining
proposals from potential partners. Such a service should include:
 company profile, locations services and capabilities,
 specific service offered in response to bid,
 browsing for target profiles with customizable browsing criteria.

6.1.3 E-Contracting

Once partners decide to conduct business with one another, the ICT solution should provide
them with the means to develop formal contracts for the services that they will be
providing/consuming. The types of capabilities that such a service should include are:
 Facilities for providing offers and quotes for requested services
 Facilities for negotiating quotes and offers
 Facilities for defining service levels (SLA) and agreeing on terms and conditions
 Facilities for closing legally binding contracts
 Security so that contract information is not accessible by unauthorized parties.

6.1.4 Administrating of business partners

Tools must be provided to authorized users so that they can administer their data and
relationships in the ICT solution. Setting up profiles, user authorizations, company
information, contract standards, etc., must be facilitated in the solution through easy to use
administrative tools.

6.1.5 Security and privacy

The ICT solution must provide the user with a secure and private means of conducting their
business. This requirement means that information stored in the ICT solution must be
accessible only by those authorized by the information owner to see the information. There
should be alerts provided concerning how the owner’s desired levels of security are affected
by where data is stored, how the information is being accessed and whether individuals have
tried to access the information in an unauthorized manner. Multiple levels of security and
access control should be configurable to the data owner to ensure that the appropriate levels
of data security are maintained.

6.1.6 Technical Collaboration

As is noted throughout this deliverable, transparent information exchange is critical to the
success of a supply chain operation. For an ICT solution this means that the information being
used on in the solution is managed to well defined standards and exchanged in well defined
protocols. The solution should facilitate integration with existing systems through easy to use
mapping services that allow legacy system data to be mapped quickly to the internal formats
used by the solution. In addition, the system should accommodate manual data interactions
as well as emerging technologies so that data from any source that is required within the
solution can be obtained in an easy to use fashion.

6.2 Planning
Planning how a shipment will be made (for setting up relationships as well as for
understanding whether a particular model for the shipment will yield the performance
required), tracking the shipment during execution against the plan, and replanning the
shipment should problems arise, is a key component of any ICT solution to the requirements
identified during this study. A planning service should facilitate creating shipment plans based
on available solution partner information so that the planner can determine if current partners
are capable of meeting a particular shipment’s demands. The service should facilitate the
integration of new partners into the plan as tentative potential service providers based on the
information that these partners have provided in their service descriptions.

Once all identified partners in the logistics chain have agreed to the plan, the plan should
become locked in as the basis for execution of the supply chain service. The plan now forms

the basis against which the service should track performance. Should events arise that affect
the plan, the planner should be notified and the planning service should allow the remaining
links in the chain to be replanned based on the type of issue that has arisen so that delivery of
the goods can be made as close to the originally agreed to requirements as possible. As the
development of feasible plans requires that the planner have access to resource availability
and capability data, the planning service should integrate with partner information sources in a
sufficiently detailed manner such that the plan that is ultimately generated is actually feasible.
Once the plan has been agreed to the planner should be able to track progress not only against
link time gates, but against resource utilization factors as well.

6.2.1 Event management

Event monitoring and management is critical to ensuring that shipment processes are
executed as planned. An event monitoring and management system should be provided by
the ICT solution that can be configured based on KPIs arising from the contract established
between execution partners, the plan created for the shipment and external inputs that could
influence the progress of the shipment. The event manager should listen for the configured
events and notify the system when any event occurs that it has been configured to listen for.

A potential additional service of the event manager would be the pro-active alerting of
conditions that might affect the shipment. Such alerts might be a change in weather
conditions, congestion on a highway or a mechanical problem in an assigned shipment vehicle.
This type of additional service would allow the planner to take action before a problem occurs
and replan the shipment so that delivery parameters are met.

6.2.2 Re-planning (multiple solution planning)

The planning tool should facilitate feasible plans that meet the requirements of the shipment.
The tool should offer alternatives and facilitate replanning activities if events occur that put
the original shipment requirements at risk. The tool should allow for multiple layers of plans
to be developed in a hierarchy so that contractors can “roll up” the plans of sub-contractors to
arrive at a total link and chain plan.

6.2.3 Strategic planning

The planning tool should be able to be run in both real time and off line modes. Real time
modes would be used for operational execution of agreed to supply chain activities. Off line
modes would be used to initially develop tentative plans for a potential shipment that require
agreement by the selected business partners (a quotation plan) or for the development of
strategic and “what if” plans to facilitate new products or process improvements.

6.3 Resource Management

The efficient and effective utilization of resources throughout the supply chain is critical to
ensuring the cost effective shipment and delivery of goods. The ICT solution that is provided
should allow users to identify which resources will be used for a shipment and to manage that
resource to ensure that they execute as planned. This may require the system to manage
resource capacities, capabilities, assignments, etc.

6.4 Monitoring & Visibility

The ICT solution should provide all members of a supply chain execution process to observe, in
an authorized manner, the state of the shipment at any point in real time. The service should
provide alerts as to when a milestone or KPI has been reached or if one of these key metrics is
about to be exceeded. Viewing of supply chain statuses should be provided to any authorized
user on fixed as well as mobile devices.

6.5 Business opportunities for SME

Today the worldwide market for global supply chain services is dominated by a few big players
who have established a worldwide network of branches and agents. Small and medium-size
service providers have difficulties in competing with these large players because they lack
presence and knowledge in markets outside of their local areas. By providing these service
providers with the ability to connect with partners across the globe an open, collaboration
solution with the capabilities identified should be able to “level the playing field.” In addition,
as SMEs usually do not have the financial where with all to afford the costly systems that are
required for managing complex supply chains, the ICT solution that is developed based on the
identified requirements should be able to overcome the cost constraints that these
organizations labor under. This implies that the solution should be an “on demand” service
that facilitates rapid setup and integration of partners without the costly need for premise
based IT infrastructure or IT staff. How the service will be provided is the topic of D1.6.

7 Conclusion

Global logistics activities are complicated and difficult to handle not because of complex
production processes or technologies, but because inter-company communications processes
have developed in an ad hoc manner and make having the right information at the right time a
difficult process to achieve. The analysis summarized in this deliverable identifies the gaps in
the communications processes and documents the business requirements that lead to these
gaps. The analysis also documents a set of business requirements that must be met if an ICT
solution is to be developed that will be of use to domain practitioners.

Using the 4phase framework that is a foundation for analysis in the FInest project, the business
requirements that have been identified can be mapped to show where they provide the
greatest contribution to the process of managing a supply chain (Figure 18).

Figure 18: Requirements related to 4 phase methodology

Certain high level business requirements have detailed requirements in multiple phases of the
model. This is particularly the case of the requirement for collaboration.

Collaboration demands that information flow smoothly between phases and between
partners. This fact requires any ICT solution that hopes to provide effective collaboration
facilities to be able to speak a common language across all of its services while facilitating the
rapid mapping of legacy data to this internal format. This fact also requires that partners in a
supply chain openly exchange data so that information on shipments can be seen by all parties
as the information is generated and that appropriate actions can be taken in a timely manner
so that shipment requirements can be met.

8 Next steps

The results of this deliverable feed into the analysis of the existing ICT solutions landscape to
determine how ICT solutions are currently provided for the transport and logistics domain.
This study is documented in D1.4.

9 References

Alt, R., Schmid, B.: Logistik und Electronic Commerce – Perspektiven durch zwei sich
wechselseitig ergänzende Konzepte, online avaiable at
www.alexandria.unisg.ch/export/DL/204704.pdf , last access 20/02/2012.

Blecker, T., Kaluza, B.: Produktions- Und Logistikmanagement in Virtuellen Unternehmen Und
Unternehmensnetzwerken, Springer Verlag, Heidelberg, 2000.

E-FREIGHT Project Website, online available at http://www.efreightproject.eu , last access on

16/02/2012.

Evangelista, Pietro: The role of ICT in the logistics integration process of shipping lines, online
available at: http://hrcak.srce.hr/file/83092 , last access on 20/02/2012.

FREIGHTWISE Framework Architecture, European Union Project no

TREN/06/FP6TR/S07.60148, Deliverable D13.2 Release 2, 2006.

IATA, Cargo 2000 Website, online available at http://www.iata.org , last access on 06/03/2012.

Kaltenbrunner, R.: Die Bedeutung des Internets für die traditionelle Luftfrachtspedition, online
avaiable at www.wu.ac.at/itl/veroeff/pdfs/ver/kaltenbrunner.pdf , last access 15/02/2012.

Kummer, S., Schramm, H.-J., Sudy, I.: Internationales Transport- und Logistikmanagement,
UTB, Wien, 2009.

Kummer, S., O. Grün, W. Jammernegg, Grundzüge der Beschaffung, Produktion und Logistik,
Pearson Studium, München, Germany, 2009.

Lidasan, Hussein S.: A study on the impact of information and communication technology on
urban logistics system, online available at: www.easts.info/on-line/journal_06/3005.pdf , last
access on 14/02/2012.

OECD (Organisation for economic cooperation and development): Transport Logistics shared
solutions to common challenges, online available at:
http://www.internationaltransportforum.org/pub/pdf/02LogisticsE.pdf , last access on
24/02/2012.

Straube, F.: e-Logistik, Springer Verlag, Heidelberg, 2004.

10 Appendix – Detailed data flows by use case

Use Case 1:

Process or Content (information) Sender Receiver Means of

activity transfer
Publication information on the port’s services, capacity, and Port Customers Website
of port resources etc Control (ship
services agents,
terminal
operators),
+ all other
stakeholde
rs
Inform AIS-based information about traffic situation, Port Maritime Phone
stakeholde also available on website. Control Radio,
rs Customers,
Norwegian
food safety
authority,
Ministry of
fishing
Retrieve Inform about expected cargo or ship arrival for Ship Port Phone
info on the day: ship name, ETA, cargo type agents; Control
ship Terminal
arrivals. operator
Inform Inform newspaper about ship calls planned for Port Local Phone,
stakeholde next day: ship name, ETA, POO Control community Website
rs ,
Newspaper
Inform Answer phone calls from maritime pilots and ship Port Pilot Phone
stakeholde supply services about ship arrival: ship name, ETA Control Ship supply
rs services
workers
Inform Weather condition at port (also available on Port Captains; Phone,
stakeholde website) Control Pilots radio
rs
Admittance Ship name, previous and next port of call, date, Ship agent, . Port e-mail, fax,
of ship calls nationality of ship, name of master, GT, NT. Vessel Control EDI (from
at port. Some info on of voyage and cargo, number of (Master) . SSN to PCS)
persons onboard, ISPS information Norwegian
Coastal
Administra
tion (SSN)
Vessel call Ship name, ETA, ETD, number of persons Ship agent, Port Fax, paper,
onboard, type and amount of dangerous goods, Vessel Control e-mail
agent, depth, port services, etc. (Master)
Booking of Ship name, ETA, ETD, Previous and next port of Vessel / Norwegian electronic
pilot / Pilot call, number of persons onboard, MMSI, type Master or Coastal (registered
exemption and amount of dangerous goods, agent, depth, Shipping Administra in SSN)
etc. Need of pilots and tugs. Pilotage track. Agent tion (SSN)

Booking of Information about pilot booked: ship name, ETA, Norwegian Port electronic
pilot / Pilot Coastal Control (SSN =>
exemption Administra PCS)
tion (SSN)
Booking of Ship name, ETA, ETD, type and amount of Pilot, tugs, fax, paper,
Pilots, Tugs dangerous goods, agent, depth, etc mooring electronic
& Mooring planner or
and crew, phone/radi
or via Port o
Control
Discharge Name of ship, flag state, ETA, ETD, previous and Vessel via Port fax, e-mail
of waste next port of call, last port where waste was shipping Control
delivered and date, IMO-nr, Type of waste; oils, agent
garbage, sewage, cargo associated waste and
cargo residues
Booking of Ship name, ETA, ETD, and need for water, energy Vessel / Tug and fax, e-mail
ship supply, and other ship services shipping mooring
services agent crew, or via
Port
Control
Custom Ship name, ETA, ETD, Previous and next port of Ship agent, Customs
clearance call, number of persons onboard, agent, etc. Vessel
(Master)
Declaration Ship name, arrival and departure date, contents, . Port
of type and amount of dangerous goods, agent Control
Dangerous .
goods Norwegian
Coastal
Administra
tion (SSN)
Immigratio Name of ship, flag, port of arrival/departure, Vessel / Port fax, paper,
n service date, information on crew and passengers: Master Control electronic
name, nationality, place and date of birth,
position on board
Port State Required information by inspection authority: Vessel / Port state Fax, paper,
Control ship identification, checklist of certificates and Master inspection e-mail
valid documents, hazardous cargo list, crew list..; authority
Ship Ship positon, course, speed, destination Vessel AIS Norwegian AIS
notification Coastal
Authority
Port
Control
Planning Berth allocated: confirmation sent to Port Captain, Phone,
berth vessel/captain, and information registered in PCS Control Terminal email, PCS
allocation
Pilot Ship name, ETA, ETD, Previous and next port of Ship agent, 1. 1. Fax,
booking call, number of persons onboard, MMSI, type Captain Norwegian paper,
and amount of dangerous goods, agent, depth, Coastal electronic
etc. Need of pilots and tugs, mooring persons. Administar or phone
Pilotage track, purpose of visit. tion 2. EDI
(register in (SafeSeaNet
SafeSeaNet => PortIT)
)
2. Port

Control

Updated Announcement of arrival: updated ETA, ship Shipping . Port phone,

notification name, IMO nr, cargo type, terminal/destination. agent or Control radio, e-
cargo, stowage plan, diacharging/laoding list vessel . Customs mail/fax
Border Ship name, position, expected border crossing Vessel / Coast Radio
crossing time Master Control
Arrival ship identification ,ETA,ETD,port of destination, Vessel / Port Telephone,
Clearance draft…, cargo type (for quay allocation) Master Control radio
Confirmati Ship name, ETA, ETD, type and amount of Pilot, tugs, fax, paper,
on of dangerous goods, agent, depth, etc mooring electronic
Pilots, Tugs planner or
& Mooring and crew, phone/radi
or via Port o
Control
Confirmati Quay number Port Vessel / fax, paper,
on of quay Control Master electronic
or voice
Cargo Transport movement details, place/location ship agent . Port Electronic,
handling identification, equipment details, number of / vessel Control (in fax, e-mail
units, measurements, dangerous goods arrival
notification
)
. Terminal
operator,
cargo
workers
Line AIS actual arrival notification (at port and at AIS Port Electronic
passing quay) Vessel Control, or radio
then
transmitte
d to Port
supply
services
providers;
Quay
owner;
Terminal;
Cargo
workers
Arrival Inform external stakeholders that the ship is in Port Ship owner electronic,
notification port Control / agent, e-mail, sms
authorities,
customs
Declaration Complete list with information regarding the Shipping Port fax, paper,
of cargo, goods (origin, destination, contents, ID number, agent, Control electronic
port safety etc) previous or voice
and port or
security vessel

Confirmati Confirm loading and unloading of units, date, Terminal Agent or EDI, fax, e-
on loaded/ ports of arrival and departure, message recipient operator shipping mail
unloaded and sender, Nature of cargo, Transport company,
goods movement details, gross weight, etc. next port
Ballast Contents, Amount, Processed, Previous port Vessel / Port fax, paper,
message Master authority email
Notice of Signed by the ship, its agent and the cargo Shipping Vessel fax
Readiness owners. ATA, ShipName and quay is included agent operator,
Cargo
owner
Customs Name of ship, port of arrival/departure, Vessel, via Customs fax, paper
nationality of ship, crew list, name, period of ship agent
stay, rank, signature, date; dutiable effects that
are dutiable; name of articles, quantity; place of
storage
Departure ship identification ,ETD,port of destination, Vessel / . fax, paper,
notification draft… Master Norwegian electronic
Coastal or voice
Administra
tion
. Port
Control
Departure AIS info on actual departure time from quay and Port Ship owner e-mail, sms
notification port Control / agent,
authorities,
customs
Invoicing Ship name, nr, date, Pilotage services esecuted, Norwegian Ship agent fax, email
(Pilot due) price, date etc. Coastal
Administar
tion
Invoicing ATA, ATD, port and quay fees, port services; . Port Ship agent e-mail,
(Port dues) Finance/ad paper
m.
Monitoring Surveillance report generated by PortWin Port Ministry of e-mail (pdf)
and Control Defense
reporting
Statistics All port calls, including Ship name, previous and Port Norwegian e-mail,
reporting next port of call, date, nationality of ship, name Control statistics paper
of master, GT, NT, Brief particulars of voyage and register
cargo, number of persons onboard, confirmation (SSB)
of attached documents (cargo declaration, ship's
store declaration, crew's effects declaration,
crew list, passenger list, dangerous goods,
maritime declaration of health)
Statistics Complete list with information regarding the Shipping Port fax, paper
and/or goods (origin, destination, contents, ID number, agent or Control
admittance etc) vessel
of ship calls
at port
Notificatio Name of ship, cargo, time of arrival and Shipping Vessel fax, paper,
n to the departure, Discharge hours, number of crews in agent owner e-mail
owner ports, agent name

A short Information fields in the message (e.g. ship size, Sender of Receiver of Typical
description no. of containers to be loaded or unloaded, message message communica
of the shipname, ETA etc.) tion
purpose of channels
the (e.g. phone,
message, fax, e-mail)
when is it used for
used? this
message
Schedule For each vessel: vessel, name, description of Shipping Vessel e-mail (pdf)
planning voyage, schedule (Arrival / Departure), booking Line /
place, transhipments, Feeder
Operator -
NCL
Operations
Dept.
Schedule For each vessel: vessel, name, description of Shipping Ship Agents Softship
planning voyage, schedule (Arrival / Departure), booking Line / (agent has
place, transhipments, Feeder access to
Operator - softship)
NCL
Operations
Dept.
Schedule For each vessel: vessel, name, description of Shipping Stakeholde Website
planning voyage, schedule (Arrival / Departure), booking Line / rs
place, transhipments, Feeder
Operator -
NCL
Operations
Dept.
Prepare Number of container, type (reefer), size, origin Fish Freight
booking and destination exporter Forwarder
Prepare Number of container, type (reefer), size, origin Forwarder Overseas e-mail,
booking (port) and destination (port) informs Line Agent telephone,
(Norwegian EDI
branch (IFTMIN)
office)
Prepare Number of container, type (reefer), size, origin Overseas Overseas e-mail,
booking (port) and destination (port) Line Agent line Agent telephone,
(Norwegian at port of EDI
branch loading in (IFTMIN)
office) Rotterdam
Prepare Number of container, type (reefer), size, origin Overseas Feeder e-mail,
booking (port) and destination (port) Line Agent Agent telephone,
at port of EDI
loading (IFTMIN)
Prepare Vessel name/number, voyage, number of Feeder Feeder e-mail,
booking container, type (reefer), size, origin (port) and Agent Operator - telephone,
destination (port), consignee direction, cargo NCL EDI
type (EU code) , container number and seal Operations (IFTMIN)
number (if known) Dept.

Confirm Booking referance, vessel name, number, Feeder Feeder e-mail,

booking schedule Operator - Agent
NCL
Operations
Dept.
Confirm Booking referance, vessel name, number, Feeder Overseas e-mail
booking schedule Operator - Line Agent
NCL (Norwegian
Operations branch
Dept. office)
Prepare Operation plan summarising all bookings, Feeder Vessel Email (pdf)
Operation specifying cargo (type, volume, number), port of Operator -
Plan loading, and discharging, customer NCL
Operations
Dept.
Prepare Operation plan summarising all bookings, Feeder Ship Agent Softship
Operation specifying cargo (type, volume, number), port of Operator -
Plan loading, and discharging, customer NCL
Operations
Dept.
Prepare Vessel . NCL e-mail (pdf)
Stowage Information on cargo to be loaded and Operations
Plan discharged, type of container, location on ship. Dept.
Based on information from operation plan. . Ship agent
. Terminal
Prepare Discharge/loading list established based on Ship Agent Port, e-mail (pdf),
Discharge / information from Softship: Transport movement Terminal EDI
Loading details, place/location identification, equipment (COPRAR /
List details, number of units, measurements, COARRI)
dangerous goods
Prepare Announce planned port call based on operation Ship Agent Port email, EDI
Vessel Call plan and disch/load list; info included: vessel (COPRAR)
name, number, ETA
Prepare Announce planned port call based on operation Ship Agent Terminal e-mail (pdf),
Vessel Call plan and disch/load list; info included: vessel EDI
name, number, ETA (COPRAR /
COARRI)
Send information and instruction about the shipment. Ship Agent Customer e-mail (pdf)
waybill (Fish
exporter /
Forwarder)
Send Summary of all waybills Ship Agent Authorities EDI
manifest to (IFTMCS)
authorities
Gate-in / Container number, booking number of all Terminal EDI
Gate-out container coming in (empty) and out (full) of the (CODECO)
terminal, and which are part of an active
shipment order
Conf. Confirmation of loading/discharging of cargo NCL Customer e-mail, EDI
load/discha Operations (Fish (IFTSTA)
rge Dept. exporter /
Forwarder)

Conf. SOB list Vessel Customer

load/discha (Fish
rge exporter /
Forwarder)
Electronic invoice specifying cargo, ports of NCL Customer e-mail, EDI
loading and discharge, and price (ref information Finance (Fish (INVOIC),
Issue form waybill) Dept. exporter / snail-mail
invoice Forwarder)
Invoice Customer NCL e-mail, EDI
Acceptance (Fish Finance (APERAK)
exporter / Dept.
Forwarder)
Bank / NCL NCL
Invoice Finance
control Payment information: Dept.

Use Case 2

Means of
Process or activity Content (information) Sender Receiver transfer
adresses (bill to, pick up,
ship to), pick up times,
goods describtion,
meassurements, delivery E-Mail, Fax,
deadline (if available, etc EDI, KN
Shipping order (see shipping order) shipper forwarder website
Telephone,
Shipment booking forwarder carrier E-Mail, EDI
agreement about
shipment taking Telephone,
over time and place forwarder shipper E-Mail
Telephone,
E-Mail,
forwarder to shipper can carrier forwarder website,
flight confirmation content HAWB as well forwarder shipper EDI
invoicing according to
incoterm, in case Import KN intern
has to invoice Export or carrier / customer / EDI, Extern
Invoicing the other way around forwarder shipper Mail
to shipper depending on
pre carriage status from Condition (from
confirmation Aiport or from Door) forwarder shipper / carrier EDI
The FWB message is used
to transmit a complete
set of Air Waybill data in
accordance with the IATA
Cargo Services
FWB Conference Resolutions. forwarder carrier EDI
The main objective of the
FHL message (type 1) is
to provide a “check-list”
of Freight Forwarder
house waybills
associated with a Master
Air Waybill. A second
type of FHL (type 2) has
been accommodated to
provide details of one
House Waybill
consignment in order for
the carrier to provide
Customs with advance
information based on the
house waybill
information provided by
the origin freight
forwarder. Under IATA e-
freight the IATA Cargo-
IMP Consolidation List
FHL (FHL type 1) message forwarder carrier EDI

serves as the house

manifest document.
EDI,
website,
flight status forwarder telephone,
confirmation carrier shipper/cnee email
Freight
Forwarding
Request/Answer
(FFR/FFA) Kind of goods Between airlines EDI
Freight received from Between
RCS Shipper/Agent forwarder/agent airline EDI
Freight received from Between
RCT other carrier forwarder/agent airline EDI
Freight received from a Between
RCF flight forwarder/agent airline EDI
Freight booked on a Between
BKD flight forwarder/agent airline EDI
Freight manifested on a Between
MAN flight forwarder/agent airline EDI
Freight departed on a Between
DEP flight forwarder/agent airline EDI
Between
PRE Freight ready to load forwarder/agent airline EDI
Freight handed over to Between
TFD other carrier forwarder/agent airline EDI
Forwarder/Agent
informedregarding Between
NFD arrival forwarder/agent airline EDI
Freight released by Between
CCD Customs forwarder/agent airline EDI
Freight delivered to Between
DLV Forwarder/Agent forwarder/agent airline EDI
Freight with deviations / Between
DIS specialties forwarder/agent airline EDI
FFM = Flight Manifest
(which AWB are
manifested on which
Flight?)
FWB =Airway bills,
connected to the FFM
prealert customs FHL = House way bills forwarder customs EDI
NFD: Freight &
Documents ready for carrier(handling
entry in Country forwarder pick up agent) customs/forwarder EDI, email
Content of imported
goods HS code Volume EDI,
Weight Consignee Usage original
customs of goods Shipper Export docs if
declaration Country Origin of goods cnee/forwarder customs needed

Shipment is out of
customs hands and can
shipment be moved freely within
releasement EU now customs carrier/forwarder(cnee) E-Mail
Telephone,
Delivery time and place forwarder cnee E-Mail
original
POD document signed by cnee forwarder cnee hand over
delivery/handover Shipment handover EDI,
status confirmation or Delivery telephone,
confirmation confirmation forwarder cnee email
invoicing according to
incoterm, in case Import KN intern
has to invoice Export or EDI, Extern
Invoicing the other way around forwarder cnee/customer Mail
CASS AWB number costs forwarder carrier EDI

Use case 3

Process or Means of
activity Content (information) Sender Receiver transfer
PO number, PO date, Product type,
Product description, Quantity,
Delivery date,
Supplier code, Supplier Name,
Supplier Address, Supplier
Responsible contact details,
Incoterms, Consignee
name,Consignee address, Consignee
contact details,
Contract Reference number
(reference to Payment terms, Value,
Delivery Conditions etc.),
Requested document list (Invoice,
packing list,
ATR or EURO-1 for EC or EFTA
originated materials, Certificate of
Origin, Shipper
Certificate of Analysis, Production (Material SAP and
Purchase Order B/L,AWB,FCR) Planning Supplier) email
PO number, PO date, Product type,
Product description, Agreed
quantity,
Agreed shipment date, ,Agreed Shipper
Purchase Order Incoterms, Agreed payment terms, (Material Production phone,
Confirmation Agreed value Supplier) Planning fax,email
Shipper Name, Shipper Address,
Contact Details (Name, Tel,e-mail),
Consignee Details, Notify,
Incoterms, Pick up address, Ready
Date,
Port of Loading, Port of Discharge,
PO Number, Description of Goods,
Total Number and Kind of
Packages/Pallets, Net Weight in
kgs,Gross Weight in Kgs,
Number of Containers and Type, If Shipper
Shipping Order Hazardous Cargo / IMCO Class + (Material Logistic
Form Page No + UNO No, Notes Supplier) Controller email
Vessel Schedules (Vessel names,
Voyage number, ETD, ETA, Port of
Discharge,
Port of Loading, Cutoff date),
Freight Cost, Truck Availability,
Transport Transit time, Logistics Logistic phone,
Alternatives Truck type, Airplane type Provider Controller email

Transport order number, Shipper

Name, Shipper Address, Contact
Details (Name, Tel,e-mail),
Consignee Details, Notify,
Incoterms, Pick up address, Ready
Date, Port of Loading,
Port of Discharge, PO Number,
Description of Goods,
Total Number and Kind of
Packages/Pallets, Net Weight in
kgs,Gross Weight in Kgs,
Number of Containers and Type, If
Hazardous Cargo / IMCO Class +
Page No + UNO No,
Notes, Commercial Invoice details, Logistic
Customs broker name, Customs Logistic Logistics Portal,
Transport Order point Controller Provider email
Transport Order number, PO
number, Ready date, Incoterms,
Shipment type/Quantity,
Gross Weight, Package Quantity,
Volume, Commercial Invoice, Notes,
Logistics provider name, Logistics
provider address, Logistics provider
contact person's name,
Logistics provider contact person's Shipper
Transport Order email, Logistics provider contact Logistic (Material
Info. person's phone Controller Supplier) email
phone,
email,
Booking Transport Order number, Confirmed Logistics Logistic Logistic
Confirmation date, Confirmed capacity Provider Controller Portal
Transport Order number, Confirmed
Booking date, Confirmed capacity, Package Shipper
Confirmation dimensions, Logistics (Material phone,
Info. WH working hrs Provider Supplier) email
Shipment Status (Has not departed,
Has not arrived, Waiting for
customs clearance,
Waiting for inland transport,
Waiting for arrival to WH, Vessel
Actual Arrival time (ATA),
Vessel Unloading Completed time, Logistic
Departure time of the container Portal,
from the Port), Logistic Logistic email
Shipment Status Schedule change Provider Controller ,phone
Invoice (Seller name, Buyer name,
Ship to address, Bill to address,
Date, Payment terms,
Value, Bank Details, Product Name,
Unit Price, Currency, Country of
Shipping Origin, VAT, Incoterms), Shipper
Documents Packing list ( Product type, Product (Material Logistic
(except waybill) description, Gross Weight, Net Supplier) Controller email, post

Weight,
Type and Number of Packages,
Package dimensions, Quantity per
pallet/box, Total volume,
Total quantity),ATR, EURO-1,
Certificate of Origin, Certificate of
Analysis
Invoice (Seller name, Buyer name,
Ship to address, Bill to address,
Date, Payment terms,
Value, Bank Details, Product Name,
Unit Price, Currency, Country of
Origin, VAT, Incoterms),
Packing list ( Product type, Product
description, Gross Weight, Net
Weight,
Type and Number of Packages,
Package dimensions, Quantity per
pallet/box, Total volume,
Shipping Total quantity), ATR, EURO-1, Shipper
Documents Certificate of Origin, Certificate of (Material Logistics email,
(except waybill) Analysis Supplier) Provider hand-in
B/L (Bill of Lading number, Name of
the shipping company,Shipper's
name,
Shipper's address, Order and notify
party, Consignee's name,
Consignee's address,
Product Type, Description of goods,
Gross/net/tare weight,Freight
rate/measurements
and weighment of goods/total
freight, Vessel and Voyage number,
Port of Loading,
port of Discharge, Place of Delivery,
Container Numbers, Seal Numbers
and Marks,
Container Type, Place and Date of
Issue, Demurage details, Customs
Tariff Number, Package Type),
AWB (Master Waybill number,
House Waybill number, Shipper's
name,
Consignee name and address,
Carrier's name, Carrier's address,
Carrier's phone,
Airport of Departure, Airport of
Arrival, Routing and Destination,
Currency,Flight Name,
Flight Date, Number of Packages, hand-in,
Gross Weight, Chargable Weight, Shipper post, telex
Dimensions, Notes) Logistics (Material release
Waybill Provider Supplier) (email)

B/L (Bill of Lading number, Name of

the shipping company,Shipper's
name,
Shipper's address, Order and notify
party, Consignee's name,
Consignee's address,
Product Type, Description of goods,
Gross/net/tare weight,Freight
rate/measurements and
weighment of goods/total freight,
Vessel and Voyage number, Port of
Loading, port of Discharge,
Place of Delivery, Container
Numbers, Seal Numbers and
Marks,Container Type,
Place and Date of Issue, Demurage
details, Customs Tariff Number,
Package Type),
AWB (Master Waybill number,
House Waybill number, Shipper's
name, Consignee name
and address, Carrier's name,
Carrier's address, Carrier's phone,
Airport of Departure,
Airport of Arrival, Routing and
Destination, Currency,Flight Name,
Flight Date,
Number of Packages, Gross Weight, hand-in,
Chargable Weight, Dimensions, Shipper post, telex
Notes) (Material Logistic release
Waybill Supplier) Controller (email)
B/L (Bill of Lading number, Name of
the shipping company,Shipper's
name, Shipper's address,
Order and notify party, Consignee's
name, Consignee's address, Product
Type,
Description of goods,
Gross/net/tare weight,Freight
rate/measurements and weighment
of
goods/total freight, Vessel and
Voyage number, Port of Loading,
port of Discharge, Place of Delivery,
Container Numbers, Seal Numbers
and Marks,Container Type, Place
and Date of Issue,
Demurage details, Customs Tariff
Number, Package Type), AWB
(Master Waybill number,
House Waybill number, Shipper's
name, Consignee name and
address, Carrier's name, Logistics Logistic
Waybill copy Carrier's address, Carrier's phone, Provider Controller email

Airport of Departure, Airport of

Arrival, Routing and Destination,
Currency,Flight Name, Flight Date,
Number of Packages, Gross Weight,
Chargable Weight, Dimensions,
Notes)

Invoice (Seller name, Buyer name,

Ship to address, Bill to address,
Date, Payment terms,
Value, Bank Details, Product Name,
Unit Price, Currency, Country of
Origin, VAT, Incoterms),
Packing list ( Product type, Product
description, Gross Weight, Net
Weight,
Type and Number of Packages,
Package dimensions, Quantity per
Shipping pallet/box, Total volume, Shipper
Documents Total quantity), Certificate of Origin, (Material hand-in,
(Export) - Certificate of Analysis Supplier) Customs Broker post,email
Invoice (Seller name, Buyer name,
Ship to address, Bill to address,
Date, Payment terms,
Value, Bank Details, Product Name,
Unit Price, Currency, Country of
Origin, VAT, Incoterms),
Packing list ( Product type, Product
description, Gross Weight, Net
Weight, Type and Number of
Packages, Package dimensions,
Quantity per pallet/box, Total
Shipping volume, Total quantity),
Documents Certificate of Origin, Certificate of Logistics hand-in,
(Import) Analysis Controller Customs Broker post,email
B/L (Bill of Lading number, Name of
the shipping company,Shipper's
name, Shipper's address,
Order and notify party, Consignee's
name, Consignee's address, Product
Type, Description of goods,
Gross/net/tare weight,Freight
rate/measurements and weighment
of goods/total freight,
Vessel and Voyage number, Port of
Loading, port of Discharge, Place of
Delivery, Container Numbers,
Seal Numbers and Marks,Container Logistics hand-in,
Waybill Type, Place and Date of Issue, Controller Customs Broker post, email

Demurage details,
Customs Tariff Number, Package
Type), AWB (Master Waybill
number, House Waybill number,
Shipper's name, Consignee name
and address, Carrier's name,
Carrier's address, Carrier's phone,
Airport of Departure, Airport of
Arrival, Routing and Destination,
Currency,Flight Name, Flight Date,
Number of Packages, Gross Weight,
Chargable Weight, Dimensions,
Notes)

(Stamped, signed original

document) (For Sea Transport:
Logistics provider name,
Summary Declaration number,
Summary Declaration date, Vessel
name, Voyage number,
Flag of nationality, B/L number, Port
of Loading, Total Gross Weight,
Number of packages,
Container numbers, Loading at Port
Permission Info (?), Date of
signature (date of signing process),
Name of the Owner of Goods, Port
of Discharge) (For road: Truck plate,
Summary Declaration number,
Summary Declaration date, Total
Gross Weight, Number of packages, Customs
Name of the Owner of Goods, Online
Summary Descrition of Goods, TIR CARNET Logistics system,
Declaration number, Border Gate name) Provider Customs Broker hand-in
Invoice number, Invoice date,
Contract reference number,
Requested Custom Clearance date,
Actual Custom Clearance date,
Payment type (?), Supplier name,
Custom Clearance Reference
number,
Customs point/port,
Product/Material code, Product/
Material description, Quantity, Unit
(KG,PCS),
Consignee name, Customs Tariff Logistics
Customs Number, Monetary value, Currency, Customs Logistics Portal,
Decleration Info. Incoterms) Broker Controller email
Port Authority
Customs Customs Clearance Reference Customs /Customs
Decleration info. number Broker Authorithy hand-in
Vessel Port Authority Customs Broker
Unloading /Customs /Customs phone,
Completed Info. Vessel Unloading Completed time Authorithy Authorithy email

Customs Declaration, Proof of

Proof of Custom Customs tax payment, Proof of the Customs Logistics
Clearance payment of port expenses Broker Provider hand-in
Customs Declaration, Proof of Port Authority
Proof of Custom Customs tax payment, Proof of the Logistics /Customs hand-in,
Clearance payment of port expenses Provider Authorithy show
Container Port Authority
Release /Customs Logistics
Permission Container Release Confirmation Authorithy Provider -
Expected arrival time of trucks
(container) to the Consignee
(Warehouse), Truck plate numbers, Logistic
Driver name, Driver phone, Invoice Portal
Incoming number, Container number, Waybill Logistics Consignee ,phone,
Containers number, Supplier name Provider (Warehouse) email
SAP,
Logistic
Actual arrival time of truck Portal,
Container Arrival (container) to the Consignee Consignee Logistics phone,em
Confirmation (Warehouse) (Warehouse) Controller ail
Claim Description, Transport Order
Reference number, Customs
Broker's name, TIR carnet number,
Truck plate, Container number,
Logistics Provider's name, Summary
Decleration reference number,
Supplier name, Invoice number, Consignee Logistics phone,em
Logistical Claims Production Planning Responsible (Warehouse) Controller ail

Process or Means of
activity Content (information) Sender Receiver transfer
SAP or
Pre-Order Number, Product Type, email or
Quantity, excel files
Description of Goods, Delivery on
address, Incoterm, Logistic common
SAP Pre-Order Shipment Type, Requested Date Order Planning Controller webfolder
Vessel Schedules (Vessel names,
Voyage number,
ETD, ETA, Port of Discharge, Port of
Loading, Cutoff date),
Freight Cost, Truck Availability,
Transport Transit time, Logistics Logistic phone,
Alternatives Truck type, Airplane type Provider Controller email
SAP Order Number, Product type,
Quantity, Desription of
goods, Gross Weight in Kgs, Port of
Loading, Port of Discharge,
Vessel name, Voyage number,
Vessel Cut-off date,
Number of Containers and types, Logistics
Consignee Details Provider
(Delivery address etc.), Inland Logistics (Forwarder,
SAP Order info. Logistics Provider, Controller Carrier) SAP, email

International Logistics Provider,

Pick-up address

SAP Order Number, Product type,

Quantity,
Desription of goods, Gross Weight
in Kgs, Port of Loading,
Port of Discharge, Vessel name,
Voyage number,
Vessel Cut-off date, Number of
Containers and types,
Consignee Details (Delivery address
etc.), Inland Logistics Provider,
International Logistics Provider, Logistics Shipper
SAP Order Pick-up address Controller (Warehouse) SAP
SAP Order Number, Transport Order
Number, Port of Loading,
Port of Discharge, Vessel name,
Voyage number, Vessel Cut-off
date,
Number of Containers and types,
Consignee Details (Delivery address
etc.),
Inland Logistics Provider,
International Logistics Provider, Logistics
Transport Order Pick-up address, Logistics Shipper Portal,
info. Pick-up date Controller (Warehouse) email
SAP Order Number, Transport Order
Number, Port of Loading,
Port of Discharge, Vessel name,
Voyage number, Vessel Cut-off
date,
Number of Containers and types,
Consignee Details (Delivery address
etc.),
Inland Logistics Provider, Logistics
International Logistics Provider, Provider Logistic
Pick-up address, Logistics (Forwarder, Portal,
Transport Order Pick-up date Controller Carrier) email
Logistics
Booking Confirmed/ Not Confirmed , Logistics Logistic Portal,
Confirmation Container number, Truck plate Provider Controller email
Booking Logistics
Confirmation Confirmed/ Not Confirmed , Logistics Shipper Portal,
info. Container number, Truck plate Provider (Warehouse) email
Logistics
Shipper Logistic Portal,
Problem Loading Problem content (Warehouse) Controller email
Truck/Container Arrival (driver
Loading Status contact details),Loading Started, Shipper Logistic Logistics
Info. Loading Completed (Warehouse) Controller Portal

Truck/Container Arrival (driver

Loading Status contact details),Loading Started, Shipper Logistics Logistics
Info. Loading Completed (Warehouse) Provider Portal
SAP Order Number, Port of Loading,
Port of Discharge, Vessel name,
Voyage number, Vessel Sailing date,
Invoice number, Quantity, Net
Weight,
Gross weight, Container number,
Product type, Customs tariff
number,
Packaging type, Volume,Consignee
Name, Consingee Address, Logistics
Loading details Shipper Name, Shipper Adress Controller Customs Broker email
SAP Order Number, Port of Loading,
Port of Discharge, Vessel name,
Voyage number,
Vessel Sailing date, Invoice number,
Quantity, Net Weight, Gross weight,
Container number, Product type,
Customs tariff number, Packaging
type, Volume,
Consignee Name, Consingee
Address, Shipper Name, Shipper Logistics Consignee
Loading details Adress Controller (Customer) email
SAP Order Number, Port of Loading,
Port of Discharge, Vessel name,
Voyage number,
Vessel Sailing date, Invoice number,
Quantity, Net Weight, Gross weight,
Container number,
Product type, Customs tariff
number, Packaging type, Logistics
Volume,Consignee Name, Provider
Consingee Address, Shipper Name, Logistics (Forwarder,
Loading details Shipper Adress Controller Carrier) email
Consignee name, Consignee
address, Shipper name, Shipper
address, Notify name,
Notify address, Delivery address,
Port of Loading, Port of Discharge,
Description of goods,
Packaging type, Gross weight, Net
weight, Sap order number,
Incoterms, Truck plate number,
Customs point, Invoice number,
Payment terms, Contact details of Logistics
B/L instruction the responsible Controller Logistic Provider email

B/L (Bill of Lading number, Name of

the shipping company,Shipper's
name, Shipper's address,
Order and notify party, Consignee's
name, Consignee's address, Product
Type,
Description of goods,
Gross/net/tare weight,Freight
rate/measurements and
weighment of goods/total freight,
Vessel and Voyage number, Port of
Loading,
port of Discharge, Place of Delivery,
Container Numbers, Seal Numbers
and Marks,
Container Type, Place and Date of
Issue, Demurage details, Customs
Tariff Number, Package Type),
AWB (Master Waybill number,
House Waybill number, Shipper's
name,
Consignee name and address,
Carrier's name, Carrier's address,
Carrier's phone,
Airport of Departure, Airport of
Arrival, Routing and Destination,
Currency,
Flight Name, Flight Date, Number of hand-in,
Packages, Gross Weight, Chargable post, telex
Weight, Dimensions, Notes) Logistics Logistic release
Waybill Provider Controller (email)
B/L (Bill of Lading number, Name of
the shipping company,Shipper's
name, Shipper's address,
Order and notify party, Consignee's
name, Consignee's address, Product
Type,
Description of goods,
Gross/net/tare weight,Freight
rate/measurements and weighment
of
goods/total freight, Vessel and
Voyage number, Port of Loading,
port of Discharge, Place of Delivery,
Container Numbers, Seal Numbers
and Marks,Container Type, Place
and Date of Issue,
Demurage details, Customs Tariff
Number, Package Type), AWB
(Master Waybill number,
House Waybill number, Shipper's
name, Consignee name and post, telex
address, Carrier's name, Logistics Consignee release
Waybill Carrier's address, Carrier's phone, Controller (Customer) (email)

Airport of Departure, Airport of

Arrival, Routing and Destination,
Currency,Flight Name, Flight Date,
Number of Packages, Gross Weight,
Chargable Weight, Dimensions,
Notes)

Commercial Invoice (Seller name,

Buyer name, Ship to address, Bill to
address, Date,
Shipping Payment terms, Value, Bank Details,
Documents Product Name, Unit Price, Currency, Logistics Post,
(Export) Country of Origin, VAT, Incoterms) Controller Customs Broker hand-in
Commercial Invoice (Seller name,
Buyer name, Ship to address, Bill to
address, Date,
Payment terms, Value, Bank Details,
Product Name, Unit Price, Currency,
Country of Origin,
VAT, Incoterms), Packing list (
Product type, Product description,
Gross Weight, Net Weight,
Type and Number of Packages,
Package dimensions, Quantity per
pallet/box, Total volume, Total Logistics
Shipping quantity), Provider
Documents Certificate of Origin, ATR, Euro-1, Logistics (Forwarder,
(Import) Insurance policy Controller Carrier) hand-in
Customs Customs Logistic
Decleration info. Customs Decleration is completed. Broker Controller email
Proof of
Customs Customs Declaration, Proof of the Customs Logistics
Clearance payment of port expenses Broker Provider hand-in
Proof of
Customs Customs Declaration, Proof of the Logistic hand-in,
Clearance payment of port expenses Provider Port Authorithy show
Container Port Authority
Release /Customs
Permission Container Release Confirmation Authorithy Logistic Provider -
Vessel departure (Vessel departure
time, Estimated Arrival Time (ETA),
Arrival Port, Customer list, B/L), Logistics
Vessel Arrival (Actual Arrival Time Logistics Logistic Portal,
Shipment Status (ATA)) Provider Controller email

Commercial Invoice (Seller name,

Buyer name, Ship to address, Bill to
address, Date,
Payment terms, Value, Bank Details,
Product Name, Unit Price, Currency,
Country of Origin,
VAT, Incoterms), Packing list (
Product type, Product description,
Gross Weight, Net Weight,
Type and Number of Packages,
Package dimensions, Quantity per
Shipping pallet/box, Total volume,
Documents Total quantity), Certificate of Origin, Logistics Consignee
(Import) ATR, Euro-1, Insurance policy Controller (Customer) email, post
Commercial Invoice (Seller name,
Buyer name, Ship to address, Bill to
address, Date,
Payment terms, Value, Bank Details,
Product Name, Unit Price, Currency,
Country of Origin,
VAT, Incoterms), Packing list (
Product type, Product description,
Gross Weight, Net Weight,
Type and Number of Packages,
Package dimensions, Quantity per
Shipping pallet/box, Total volume,
Documents Total quantity), Certificate of Origin, Logistics Consignee
(Import) ATR, Euro-1, Insurance policy Provider (Customer) hand-in
Expected arrival time of trucks
(container) to the Consignee
(Warehouse), Truck plate numbers,
Driver name, Driver phone, Invoice
Incoming number, Container number, Waybill Logistics Consignee phone,
Containers number, Supplier name Provider (Customer) email
Unloading
Appointment Consignee
details Unloading time, Unloading dock (Customer) Logistic Provider email
Proof of delivery
(CMR/unloading Proof of delivery (CMR/unloading Consignee
doc.) doc.) (Customer) Logistic Provider hand-in
Proof of delivery
(CMR/unloading Proof of delivery (CMR/unloading Logistics Logistic Logistic
doc.) doc.) Provider Controller Portal

HLA BVL Paper Final
No ratings yet
HLA BVL Paper Final
29 pages
Urban Freight Solutions for Engineers
No ratings yet
Urban Freight Solutions for Engineers
81 pages
CFE17 Mika-Lammi Kouvola-Innovation
No ratings yet
CFE17 Mika-Lammi Kouvola-Innovation
24 pages
Notes For First Round Interview
No ratings yet
Notes For First Round Interview
10 pages
ISM Case Studies
No ratings yet
ISM Case Studies
15 pages
877936.new Challenges of Ict Usage in Transport and Logistics
No ratings yet
877936.new Challenges of Ict Usage in Transport and Logistics
8 pages
Physical Internet
No ratings yet
Physical Internet
91 pages
Permavirg Chapter 1 Draft
No ratings yet
Permavirg Chapter 1 Draft
9 pages
Icet 2017 Untar
No ratings yet
Icet 2017 Untar
11 pages
AFM211E-Suggested Solution Test 1
No ratings yet
AFM211E-Suggested Solution Test 1
4 pages
Last Mile Delivery Solutions & Challenges
No ratings yet
Last Mile Delivery Solutions & Challenges
7 pages
4 CASE STUDY Digital Transformation and Use Cases in Logistics - Ubuntu
No ratings yet
4 CASE STUDY Digital Transformation and Use Cases in Logistics - Ubuntu
5 pages
Automation of Freight Transport
No ratings yet
Automation of Freight Transport
17 pages
(Final) Analysis Phase - Group 1 v2
No ratings yet
(Final) Analysis Phase - Group 1 v2
19 pages
It in Logistics
No ratings yet
It in Logistics
5 pages
Onthespot
No ratings yet
Onthespot
2 pages
UPS Competes Globally With Information Technology
100% (1)
UPS Competes Globally With Information Technology
2 pages
FedEx Integration of Technology SCM Latest
No ratings yet
FedEx Integration of Technology SCM Latest
19 pages
Automation Parcel Delievery
No ratings yet
Automation Parcel Delievery
5 pages
L12 Information Technologies and Transportation Ap - 250324 - 235022
No ratings yet
L12 Information Technologies and Transportation Ap - 250324 - 235022
44 pages
Name: Samwel Bonga REG NO: 22/0981 Course: Bachelor of Procurement and Logistics (BPL Unit:Research Project
No ratings yet
Name: Samwel Bonga REG NO: 22/0981 Course: Bachelor of Procurement and Logistics (BPL Unit:Research Project
10 pages
DBI2021 - Group 2 Consumerization of Transportation
No ratings yet
DBI2021 - Group 2 Consumerization of Transportation
38 pages
Briefing Report Deliva Courier Services
No ratings yet
Briefing Report Deliva Courier Services
2 pages
FedEx - Competitive Advantage Through Information Technology
100% (4)
FedEx - Competitive Advantage Through Information Technology
9 pages
Core 2 Latest Docu
No ratings yet
Core 2 Latest Docu
137 pages
1 Stchapterintroduction
No ratings yet
1 Stchapterintroduction
70 pages
(Final) Analysis Phase - Group 1
No ratings yet
(Final) Analysis Phase - Group 1
17 pages
WiRED 6 0 1692343728
No ratings yet
WiRED 6 0 1692343728
15 pages
Gian No Pol Uos
No ratings yet
Gian No Pol Uos
48 pages
Novack 9e CH03 IM
No ratings yet
Novack 9e CH03 IM
23 pages
MIS Presentation: Industry - Courier/Logistics
No ratings yet
MIS Presentation: Industry - Courier/Logistics
10 pages
Synergylabs Case Studies - CY23-2
No ratings yet
Synergylabs Case Studies - CY23-2
46 pages
Ey Envisioning The Future of Indian Logistics at 2047-33-64
No ratings yet
Ey Envisioning The Future of Indian Logistics at 2047-33-64
32 pages
Ch1-7 Case
No ratings yet
Ch1-7 Case
19 pages
Maritime Shipping Tech Trends 2018
No ratings yet
Maritime Shipping Tech Trends 2018
46 pages
Logistics Tracking Innovations
No ratings yet
Logistics Tracking Innovations
10 pages
Speedyship CMS Final Report
No ratings yet
Speedyship CMS Final Report
20 pages
E Case h8
No ratings yet
E Case h8
3 pages
Rooseveltllanos CP Systemsplatformbusinesses Unid1
No ratings yet
Rooseveltllanos CP Systemsplatformbusinesses Unid1
6 pages
IT Applications in Trade and Logistics
No ratings yet
IT Applications in Trade and Logistics
6 pages
NCP Info Day 13 May 2011, Brussels: Factories of The Future & Next ICT Calls
No ratings yet
NCP Info Day 13 May 2011, Brussels: Factories of The Future & Next ICT Calls
17 pages
Adl Digital Platforms in Freight Transportation PDF
No ratings yet
Adl Digital Platforms in Freight Transportation PDF
16 pages
Freight Forwarder Practices
No ratings yet
Freight Forwarder Practices
9 pages
DCIT 307, Group 2 SRS
No ratings yet
DCIT 307, Group 2 SRS
7 pages
UPS IT Innovations and Global Competition
No ratings yet
UPS IT Innovations and Global Competition
14 pages
Information Technology in Logistics Management
No ratings yet
Information Technology in Logistics Management
28 pages
Logstcs & SCM Unit 5
No ratings yet
Logstcs & SCM Unit 5
14 pages
SCM Final Report On Logistics
No ratings yet
SCM Final Report On Logistics
20 pages
UPS Logistics & Tech Innovations
100% (1)
UPS Logistics & Tech Innovations
7 pages
Logitics
No ratings yet
Logitics
18 pages
Session 9 - UPS Case Study
No ratings yet
Session 9 - UPS Case Study
2 pages
Lokesh Singh 14/279 Shikha Gupta 14/300 Naveen Vyas 14/283 Shipra Agarwal 14/301 Sakshi Gupta 14/296 Varun Madan 14/312
No ratings yet
Lokesh Singh 14/279 Shikha Gupta 14/300 Naveen Vyas 14/283 Shipra Agarwal 14/301 Sakshi Gupta 14/296 Varun Madan 14/312
22 pages
EU Maritime ICT Innovations
100% (2)
EU Maritime ICT Innovations
11 pages
Industry 4.0 & IoT in Logistics
No ratings yet
Industry 4.0 & IoT in Logistics
5 pages
Presented By:-: E-Business & E-Commerce Solutions
100% (2)
Presented By:-: E-Business & E-Commerce Solutions
26 pages
Rolling Stock Procurements - Lessons Learned
100% (1)
Rolling Stock Procurements - Lessons Learned
24 pages
SMART Logistics Chain: March 2012
No ratings yet
SMART Logistics Chain: March 2012
8 pages
ERP Assignment
No ratings yet
ERP Assignment
4 pages
Form Survey Lalu Lintas 24 Jam
100% (1)
Form Survey Lalu Lintas 24 Jam
6 pages
Group2 MIP Model
No ratings yet
Group2 MIP Model
3 pages
Dbpfirst
100% (1)
Dbpfirst
5 pages
Experimental Design For Simulation
No ratings yet
Experimental Design For Simulation
7 pages
GBI S4H Part 00 Introduction
No ratings yet
GBI S4H Part 00 Introduction
168 pages
Tips For Successful Practice of Simulation
No ratings yet
Tips For Successful Practice of Simulation
6 pages
2019
No ratings yet
2019
337 pages
Cheap Car Rental in Europe - Grand Modus
No ratings yet
Cheap Car Rental in Europe - Grand Modus
2 pages
VIOS Minor Change 2015
No ratings yet
VIOS Minor Change 2015
1 page
Tutor Marked Assignment (Tma) : Shipmasters Law and Business
No ratings yet
Tutor Marked Assignment (Tma) : Shipmasters Law and Business
4 pages
G-450 Performance
100% (1)
G-450 Performance
43 pages
Experienced Uber Driver Profile
No ratings yet
Experienced Uber Driver Profile
1 page
Evaluation of Advanced Air Bag Deployment Algorithm Performance 2008
No ratings yet
Evaluation of Advanced Air Bag Deployment Algorithm Performance 2008
10 pages
Safe Ground Handling Guidelines
No ratings yet
Safe Ground Handling Guidelines
19 pages
400scale - A380 - Emirates - Expo 2020 Blue
No ratings yet
400scale - A380 - Emirates - Expo 2020 Blue
1 page
D. Amm Irm Aug 06
No ratings yet
D. Amm Irm Aug 06
48 pages
Luxor Airport Pilot Guide
No ratings yet
Luxor Airport Pilot Guide
17 pages
Transportation Engineering Chapters 1 3
No ratings yet
Transportation Engineering Chapters 1 3
90 pages
2011 Suzuki Grand Vitara Specs
No ratings yet
2011 Suzuki Grand Vitara Specs
3 pages
Travel Reservation December 24 For MR FAYAZ MOHAMMED
No ratings yet
Travel Reservation December 24 For MR FAYAZ MOHAMMED
2 pages
Honda XRE190 Parts Catalogue
No ratings yet
Honda XRE190 Parts Catalogue
246 pages
Brosur Passenger V17
No ratings yet
Brosur Passenger V17
28 pages
HR06AV2116
No ratings yet
HR06AV2116
6 pages
Mve Chap 1
No ratings yet
Mve Chap 1
17 pages
Oxford Geography Chapter 03
No ratings yet
Oxford Geography Chapter 03
3 pages
Cebu Public Transport Terminal Proposal
No ratings yet
Cebu Public Transport Terminal Proposal
13 pages
Tata Commercial Vehicles Review
100% (1)
Tata Commercial Vehicles Review
12 pages
Rapid KL - Integrated Transit Map - MyRapid
No ratings yet
Rapid KL - Integrated Transit Map - MyRapid
1 page
Five Pillars of Traffic Management (Traffic Management Center Is Under The Supervision of The City Mayor)
100% (1)
Five Pillars of Traffic Management (Traffic Management Center Is Under The Supervision of The City Mayor)
9 pages
Truck Lights
No ratings yet
Truck Lights
79 pages
The Raven Parts - The Edge Products
No ratings yet
The Raven Parts - The Edge Products
7 pages
MEL CRJSCL-600 - Rev - 21
No ratings yet
MEL CRJSCL-600 - Rev - 21
307 pages
Tariff Conversion and Incoterm Formulas
No ratings yet
Tariff Conversion and Incoterm Formulas
5 pages
L550 - L580 2plus2 Serie 6 - en - Ok
100% (2)
L550 - L580 2plus2 Serie 6 - en - Ok
832 pages
Honor Buick GMC Follow Up
No ratings yet
Honor Buick GMC Follow Up
5 pages
PZ MODS 2022 v3
No ratings yet
PZ MODS 2022 v3
41 pages