ENG - POI Proof of Concept (PoC) Publication v0.3

POI Proof of Concept
‘World-class asset management in the port of Rotterdam’

Project number: I.000425
Status: Draft
Version: 0.3 1 of 26 version date: 9/11/2012

Status: Draft
Authorisation
Name Role Position Date Initials
E. Rademaker Programme manager Programme manager
Asset Management
Version management
Version Date Brief description of change
0.1 5 November 2012 First version of the Proof of Concept
0.2 9 November 2012 Additions to products of PoC steps
0.3 16 November 2012 Publication version
Distribution list
Names Role/Position Distributed version(s)
P. de Beijer Client
C. Pons Steering group member
R. de Vries Steering group member
H. Meijer Steering group member
L. Visser Steering group member
E. Rademaker Project leader (author)
A.J. Boersma Project team member
L. van der Slik Project team member
F. Apeldoorn Project team member
J. van Scherpenzeel Project team member
W. Albers Project team member
M. van Nederpelt Project team member
N. van Neerven Project team member
L. Wagemans Project team member
E. Jacobs Project team member
E. Jaquet Project controller
I. Schoonenberg Project support

Status: Draft
Audit trail changes
To version Brief description of change
0.1 Initial design of the Proof of Concept
0.2 Products added to the PoC steps
0.3 Textual changes. Suppliers will give a general presentation of the organisation, customers,
solutions, vision, etc: added to step 3.

Status: Draft
Copyright 2012, Port of Rotterdam Authority

Nothing from this publication may be reproduced and/or published by means of
printing, photocopying, microfilm or in any other way without the prior written
permission of Port of Rotterdam Authority.

Status: Draft
Contents
1 Introduction ................................................................................................................... 6
2 PoC structure ................................................................................................................ 7
3 Steps in detail .............................................................................................................. 10
3.1 Step 1. PoC preparation ......................................................................................................... 10
3.2 Step 2. Furnish PoC location .................................................................................................. 10
3.3 Step 3. PoC kick-off (procedural) ........................................................................................... 11
3.4 Step 4. PoR and GEO 2.0 workshop (functional) ................................................................... 11
3.5 Step 5. Supplier basic solutions workshop ............................................................................. 11
3.6 Step 6. Import, export and management ................................................................................ 12
3.7 Step 7. Transfer of basic data ................................................................................................ 12
3.8 Step 8. Import basic data ........................................................................................................ 13
3.9 Step 9. Validate basic data (core objects and core lines) ...................................................... 13
3.10 Step 10. Retrieve/select.......................................................................................................... 14
3.11 Step 11. Design (Amazonehaven project) .............................................................................. 14
3.12 Step 12. Three clicks .............................................................................................................. 15
3.13 Step 13. Export data ............................................................................................................... 15
3.14 Step 14. Make maps ............................................................................................................... 15
3.15 Step 15. Validate data ............................................................................................................ 16
3.16 Step 16. Retrieve, select, design and three clicks .................................................................. 16
3.17 Step 17. PoC steering group try-out ....................................................................................... 17
3.18 Step 18. PoC steering group .................................................................................................. 18
3.19 Step 19. Look ahead for levels 2 and 3 .................................................................................. 18
4 Cases ........................................................................................................................... 19
4.1 Project Development Cases ................................................................................................... 19
4.2 Asset Management Cases...................................................................................................... 24
4.3 Ports and Waterways Cases .................................................................................................. 26
Figures
Figure 1: PoC step-by-step plan ............................................................................................ 7
Figure 2: PoC area .............................................................................................................. 12
Figure 3: Processes and data exchange ............................................................................. 17

Status: Draft
1 Introduction
The Port of Rotterdam Authority (hereinafter referred to as PoR) is developing a basic facility
for geographical port object information which is reliable, forms an integral part of the
processes, will keep up with relevant changes and which both internal and external parties
will use to a maximum extent. The facility is being developed in phases with a commercially
sound approach. The basic facility for geographical object information contributes to
performing (part of) the PoR processes as efficiently and effectively as possible. This has
been formulated as ‘port object information is the basis of operational excellence’.
The basic facility for geographical port object information will be achieved through the Port
Object Information project (hereinafter referred to as POI). The POI project team has the
following mission:
‘From the port map, a user is able to find relevant and reliable information within three mouse
clicks, without any restrictions and without any training.’
Firstly a Proof of Concept will be made so that the basic facility for geographical object
information can be created. The aim of the PoC is to validate the extent to which the solutions
offered by suppliers meet the PoR’s wishes and requirements regarding the GIS Port Solution
(GEO 2.0).
This DRAFT document sets out the main features of the steps with which the PoR expects to
implement the PoC (HOW). The PoC steps to be completed will be coordinated with the
selected supplier(s).
The functional aspects of the PoR GIS Port Solution are described in the GEO 2.0 Blueprint
document.

Status: Draft
2 PoC structure
PoR currently anticipates the implementation of the PoC to follow the step-by-step plan
below. A final step-by-step plan for the PoC will be drawn up together with the suppliers. The
aim of the step-by-step plan is the efficient and structured implementation of the PoC so that
the desired results are achieved.
Figure 4: PoC step-by-step plan
The completion time of the PoC is estimated to be 3 months (13 weeks). The PoC is planned
to start on Monday 28 January 2013, and a final presentation to the POI steering group has
been planned for Tuesday 30 April 2013. The PoC consists of 18 steps. Step 19 is a project
step which is not formally a part of the PoC. The progress of the PoC and agreements with
the suppliers can determine whether steps 9 to 14, or parts of them, are followed several
times.
Each PoC step is described briefly below. The PoC steps are worked out in greater detail in
the next chapter.
Step 1. PoC preparation

Suppliers are introduced to PoR and provided with information about work locations,
company rules, etc.
Step 2. Furnish PoC location

A separate work location will be furnished for each supplier for the PoC. The suppliers can
set up and install their hardware and software in this PoC room.
Step 3. PoC kick-off

The kick-off is the occasion for the suppliers to get to know the PoR PoC participants. GEO
2.0 functional matters will not be discussed at this kick-off. It is an opportunity to get to know
each other, a time when working arrangements, schedule and suchlike are discussed and
suppliers give presentations about their organisations.

Status: Draft
Step 4. PoR and GEO 2.0 workshop

In the PoR and GEO 2.0 workshop, the PoR explains the required GEO 2.0 functionality and
the object data which will be used in the PoC. This workshop can be considered as the
transmission of information by PoR to the suppliers and an opportunity for the suppliers to
ask questions.
Step 5. Supplier workshop on basic solutions

In this workshop, the suppliers show how they will implement the GEO 2.0 Port Solution.
Step 6. Import, export and management

This is a technical step. The technical components are:
how object data are imported and exported, management aspects of meta data of objects,
authorisation rights of employees and external organisations, authorisation rights for data and
functionality on the basis of roles and the technical rights according to the ‘single sign-on’
principle.
Step 7. Transfer of core data

PoR has collected core data of the objects which will be used in the PoC. The objects come
from Maasvlakte 1 and (part of) Maasvlakte 2 and part of the Maas Entrance.
Step 8. Import core data

Suppliers import the object data from the regions Maasvlakte 1, (part of) Maasvlakte 2, part of
the Maas Entrance and their systems.
Step 9. Validate core data

In this step, the imported data is validated. The data is validated in order to guarantee correct
object data for the implementation of the further steps.
Step 10. Retrieve/select

The ‘retrieve/select’ functionality is tested using cases written out by PoR.
Step 11. Design (Amazonehaven project)

The ‘designed’ functionality is tested on the basis of the cases; the widening of the
Amazonehaven and creation of a passage from Maasvlakte 1 to Maasvlakte 2.
Step 12. Three clicks

Testing the ‘three clicks’ functionality.
Step 13. Export data

A number of export files are created for external organisations. The export files are checked
for completeness (data) and correct file structure.
Step 14. Make maps

A number of theme maps are produced.
Step 15. Validate data

The data from the cases is validated for the integral testing in step 16.

Status: Draft
Step 16. Retrieve, select, design and three clicks

This step is the integral testing of the PoC solution as realised by the supplier. The testing is
performed on the basis of a number of cases. These cases go through a number of business
processes of PoR.
Step 17. PoC steering group try-out

In this step, the presentation to be held for the POI steering group is discussed, checked and,
if necessary, refined so that it has the correct information, depth and clarity.
Step 18. PoC steering group

Each supplier gives a presentation to the steering group.
Step 19. Look ahead for levels 2 and 3

This step provides the suppliers with the opportunity to show the POI project team members
the functionality in their solutions for supporting levels 2 and 3 and any additional functionality
PoR could use in the future.

Status: Draft
3 Steps in detail
The PoC steps are explained in more detail below.
3.1 Step 1. PoC preparation
Suppliers are introduced to PoR and provided with information about work locations,
company rules, etc.
1) Access to World Port Centre
2) Lunches
3) Overtime
4) Office supplies
5) Telephone connections
6) Protecting work locations (closing)
7) IT topics
o Systems
o Authorisation
o Security
o Internet
o ……..
Product/result
Supplier knows what the PoR company rules are and how he can work in the WPC.
3.2 Step 2. Furnish PoC location
A separate work location will be furnished for each supplier for the PoC. The suppliers can
set up and install their hardware and software in this PoC room.
Topics:
1) Tables and chairs
2) Electricity connections
3) Network connections
4) Flip charts (resources)
5) Whiteboard and accessories
6) Projector and screen
7) Printer
8) …………
Product/result
Supplier has set up his working space, placed equipment, installed software and connected
to the Internet.

Status: Draft
3.3 Step 3. PoC kick-off (procedural)
Part one
The kick-off is the occasion for the PoR PoC participants to get to know the employees of the
suppliers who will implement the PoC. The working arrangements, schedule, procedures and
suchlike are discussed in this kick-off. Kick-off topics:
1) Meeting PoR POI participants
2) Communication
3) Procedures (method, decisions, issues, reports, .........)
4) Availability of employees and their role
5) PoC schedule
6) Data transfer
7) Priorities
8) Overview of what PoR does
9) Topics:
o Objects
o Object relationships
o Functionality (the WHAT)
Part two
The suppliers give a general presentation in which they present the organisation, customers,
solutions, projects, GEO vision, etc. This presentation does not show the PoR aspects.
Product/result
It is clear to all persons involved which activities have to be undertaken, who is accountable
for what and how work will be performed during the PoC.
PoR PoC participants have a clear picture of the suppliers.
3.4 Step 4. PoR and GEO 2.0 workshop (functional)
In this workshop, the PoR explains the objects and the GEO 2.0 functionality needed to
support the business processes of PoR. This workshop can be considered as the
transmission of information by PoR to the suppliers and an opportunity for the suppliers to
ask questions.
Product/result
It is clear to the suppliers which GEO 2.0 results are expected.
3.5 Step 5. Supplier basic solutions workshop
In this workshop, the suppliers show how they will implement their GEO 2.0 Port Solution.
Product/result
It is clear to the PoR PoC members which GEO 2.0 functionality they can expect and how the
supplier will achieve the requested functionality during the PoC.

Status: Draft
3.6 Step 6. Import, export and management
This is the technical step concerning:

1) how object data are imported and exported
2) management aspects of meta data of objects
3) management aspects concerning authorisation rights of employees and external
organisations
4) management aspects concerning authorisation on the basis of roles and data
5) management aspects concerning system functionalities
6) management aspects concerning the ‘single sign on’ principle.
7) validation rules concerning data import
8) validation rules concerning baseline creation
9) validation rules concerning the realisation of object relationships
10) standard functionality for general set up
11) standard functionality for set up of each individual user
Product/result
Report on how management aspects can be organised.
Report on how and which validation rules can be used.
Report on how data can be imported and exported.
Report on how functionalities can be arranged for users.
3.7 Step 7. Transfer of basic data
The basic data are transferred in the format agreed with the suppliers. The supplier validates
these data.
The scope of the PoC is the entire Maasvlakte 1, parts of Maasvlakte 2 and part of the Maas
Entrance.
Figure 5: PoC area

Status: Draft
Basic data are supplied from the following source files:

1) GBKN/GBT (Municipality of Rotterdam)
2) Land Registry details (Land Registry Office)
3) Addresses and Buildings Database (Land Registry Office)
4) Cables and pipelines (Municipality of Rotterdam)
5) PoR objects (RIV and AutoCAD)
6) ENC data
7) ………..
Product/result
Delivery of the basic data by PoR in the agreed file exchange format.
3.8 Step 8. Import basic data
The suppliers import the data into their systems, create the baselines and apply the data
validation rules.
Product/result
Data have been imported correctly by the suppliers into their systems.
3.9 Step 9. Validate basic data (core objects and core lines)
In this step, the data are validated. Validation of the data is essential in order to guarantee
correct object data for the implementation of the further steps. The data are validated on the
following points:
1) Imported object data are complete
o The number of objects and other numerical characteristics such as the
length of quay walls, number of bollards and the surface area of roads and
sites are counted in advance.
2) Object data have been imported correctly
o Spatial position
o Administrative data
3) Relationships between objects have been created correctly
o Baselines
o Connection of related objects, such as berths and sites, to the baselines
4) Validation rules have been applied correctly
o Determine which validation rules have been applied and whether they have
actually been implemented. Example: connections of baselines in the
transition from quay wall to bank.
5) Error messages
o Data could not be processed.
o Validation rules could not be applied.
6) ………..
Product/result
Description of the validation rules.
Report of the result of the data import.

Status: Draft
3.10 Step 10. Retrieve/select
The retrieve/select functionality is tested:

1) Predefined retrieve/select cases with predefined objects.
2) Ad hoc retrieve/select.
3) See retrieve/select examples from the blueprint
Product/result
Report (growth document) with the retrieve/select functionality, the data used and the result.
o What is going well?
o What has to change?
o What is going wrong?
o What still has to be done?
3.11 Step 11. Design (Amazonehaven project)
Testing the ‘design’ functionality on the basis of two project cases:

1) Widening of the Amazonehaven
o Project boundary and project data
o New quay wall (design and realisation)
o Removal of old quay wall and soil
o Deliver project
o …………
2) Creation of waterway connection between Maasvlakte 1 and Maasvlakte 2
o Dredge out soil
o Sound depth
o ……..
Product/result
Report (growth document) with the design functionality, the data used and the result.
o What has to change?
o What still has to be done?

Status: Draft
3.12 Step 12. Three clicks
Testing the ‘three clicks’ functionality from the processes of the organisational units:
1) Asset Management Structures
2) AM Ports and waterways
3) PD contracts
4) Projects
5) Harbour Master
Product/result
Report (growth document) on results of application of the ‘three clicks’ functionality.
3.13 Step 13. Export data
Testing the ‘export functionality’. A number of export files are created for external
organisations. The export files are checked for completeness (data) and correct export file
structure.
1) Vademecum for Pilotage Service
2) ………
Product/result
Description of the export validation rules.
Description of the export file structure.
Report with findings of the data export file
o What is good?
o What is wrong?
3.14 Step 14. Make maps
Testing the ‘make map’ functionality. The proposal is to create the following maps:
1) Vademecum
2) Segment division
3) Two scenarios for the non-issued sites on Maasvlakte 2
4) Widening of the Amazonehaven project
5) ……….
Product/result
Maps
Report with the results of the functionality for making maps.
o What is good?
o Which functionality is not present?

Status: Draft
3.15 Step 15. Validate data
In this step, we determine whether the correct data are available for the integral testing step
with integral cases to be carried out in step 16. The cases are used to validate the data.
Product/result
Report with the data required for implementing the cases.
Report with the result of the validation performed of the data in the system for the integral
testing step.
3.16 Step 16. Retrieve, select, design and three clicks
This step is the comprehensive testing of the GEO 2.0 functionality on the basis of cases, in
which a number of processes of PoR are completed. See the draft global cases in chapter 4
and the GEO 2.0 blueprint
The functionality is validated in two steps:

1) Validate whether the GEO 2.0 functionality and data can be seen from the processes
of the organisational units:
AMC
o Risks
o Maintenance costs (structure)
AMI
o Maintenance costs (road, green space)
o …….
Port and waterways
o Actual depths versus agreed depths
o Dredging depths, construction depth, (quay wall) bottom width and depth
o
PD
o Sites of customer
o Spatial balance
o Segment revenue
Harbour Master
o Actual depths and the agreed waterway depths and contract berth depths
o
Projects
o Create project
o Close project
EM
o …….
CBL and PIB
o …….
2) Validate whether functionality is available and whether the data can be

changed/modified correctly on the basis of the Widening Amazonehaven project and
the Maasvlakte 1  Maasvlakte 2 connecting waterway project.
The full process schedule below, Implementing Data Management for Investment
Projects, is used for this purpose.

Status: Draft
Figure 6: Processes and data exchange
Product/result
Report with the result of implementing the cases with the retrieve/select functionality.
Report with the result of implementing the cases with the design functionality.
Report with the result of implementing the cases with the ‘three clicks’ functionality.
3.17 Step 17. PoC steering group try-out
In this step, the presentation which the supplier will hold for the POI steering group is
checked and refined so that it has the correct information, depth and clarity.
The presentation is worked out in a step-by-step plan. The step-by-step plan indicates who
does what, how long a step takes, which functionality is presented with which data and which
PowerPoint slides, etc. as supporting information.
Product/result
PoC steering group step-by-step plan
Supporting PowerPoint presentation, etc.
System set up and ready for presentation

Status: Draft
3.18 Step 18. PoC steering group
Presentation of the PoC GEO 2.0 functionality to the steering group.

The purpose of this session is to show the GEO 2.0 functionality to the steering group. Each
supplier presents his own GEO 2.0 solution. The content of both sessions is the same
(functionality and data).
Product/result
Presentation to the steering group of the GEO 2.0 solution.
3.19 Step 19. Look ahead for levels 2 and 3
The suppliers have the opportunity to show the POI project team members the functionality
their solutions offer for supporting levels 2 and 3. The suppliers can also show extra
functionality which PoR could use in the future within the PoR work processes. This session
will be given to the Project team members of POI. The suppliers organise this session entirely
themselves.

Status: Draft
4 Cases
A number of extremely global cases are described below. The cases, or parts of these cases,
are used in the different steps of the PoC. In step 16 of the PoC, the cases are passed
through in full. Parts of the cases are used in step 18 of the PoC. This guarantees that the
cases do not stray far from the daily experience of PoR.
4.1 Project Development Cases
4.1.1 Introduction
The following process activities can be distinguished in the process of establishing a

customer:
A. The search process
B. Site issue
C. Contracts
D. Support
The process of establishing a customer can be described as follows:
a. An existing or new customer requests a site.

b. This request is received by a Business Development Manager (BDM) in the commercial
departments (PIB/CBL).
c. This is the moment when the so-called tripartite consultation takes place between the
managers of PIB, CBL and Project Development, in which they decide whether to take up
the request. If that is the case, the project team is put together in the consultation hour.
d. The BDM ascertains what the wishes of the customer are. Do they just want a site, or do
facilities such as a quay wall also have to be developed? This is called the ‘Search
process’.
e. An internal reservation is placed on an object in SAP-RE. Attention is paid to whether the
surface area offered is actually available. This check is done in SAP-RE using
administrative characteristics and in GEO 2.0 using spatial characteristics (size, location).
f. If the customer only wants a site and no extra investment will be made, the request goes
directly to the Port Development department. Often the location where the customer will
rent a site is already known.
g. Port Development lays down the conditions, which are provided in a letter of offer. This
letter is sent to the customer along with an offer drawing.
h. When the letter of offer is made, the offered site is checked to make sure it is actually
available. The rental object is reserved in SAP-RE.
i. The next step in the process is for the customer to sign the contract.
j. This is when the site is actually issued and registered in SAP-RE.
k. The Port Development Department maintains contacts with the customer.
l. Port Development is responsible for the invoicing, price increases, contract extensions,
checking the occupation, etc.
m. If a customer wants a site for which extra facilities have to be developed, the process
goes via Project Development the same way as for a normal site issue, but it takes a lot
longer.

Status: Draft
4.1.2 The search process
In the ‘Establishing a customer’ process, Port Development carries out a global test of the
feasibility of the customer wishes within the project team. Sites are examined in the search
process to see whether they might be eligible for issue. This search process requires a
spatial presentation and spatial demarcation of the search request.
Information required
In concrete terms, insight into the following themes is needed:
all the sites of one customer;
market segment information;
status of the sites;
this concerns information about (internal) reservations including end date;
term of the contracts;
term of the contracts including options;
berths, length, width and depth;
shore site numbers;
agreements in Convenants insofar as they can be indicated in spatial terms;
management area of PoR;
photos.
Open up aeroview (bird’s-eye view) photos on location (GPS tag) of several years. For
example, the (result of the) construction of a quay wall can be viewed from a bird’s-eye
perspective.

Status: Draft
4.1.3 Site issue
Port Development already has an idea of where the customer can be established when the
request to 'Establish a customer' comes in at Port Development.
Port Development matches the site to be issued as well as possible within the existing
situation and lays down the boundaries.
Recording the boundaries

In the context of Quality Management of data and streamlining the issue process at Port
Development, the site issue is recorded immediately in spatial terms. The spatial and
administrative preconditions are checked and enforced in the recording.
Required information, minimum need

In concrete terms, insight into the following themes is needed as a minimum:
berths length, width;
market segment information;
Land Registry information (boundaries, parcel numbers, certain rights);
the latest aerial photo;
cables and pipelines;
user information from the Chamber of Commerce for each parcel recorded in the Land
Registry;
status of environmental permits;
berths;
safety contours;
soil data;
noise zone;
noise distribution scheme;
zoning plans.

Status: Draft
4.1.4 Contracts
Once a customer has been established, Project Development is responsible for invoicing,
price adjustments, contract extensions, and checking the occupation and the compliance with
agreements concerning use in the contract. Project Development receives questions and/or
requests from a customer concerning an existing customer contract and uses SAP-RE and
GEO 2.0 to gain insight into the contract situation and be able to answer the question or grant
the request (for instance, the declaration of an option).

contract information concerning the sites;
berths length, width;
the latest aerial photo.

Status: Draft
4.1.5 Support
Project Development provides support for:

1. checking the recording of data in GEO 2.0 and SAP
2. drawing up a spatial balance
3. theme maps of products
Re 1: The data administrator is responsible for checking the recording of an internal

reservation of a new or existing site.
This reservation for an existing site or a new site is made in a reservation contract.
The offer is registered in SAP-RE and checked to see whether the offered surface area is
actually present and whether the boundaries fit in the current situation.
Re 2: The Spatial balance is drawn up every year at PoR. This report gives an overview of all
of the PoR land and shows how much land has been issued and how much land has a
different use. The spatial balance is drawn up on the basis of the data in SAP-RE, where the
administration of the issues is updated. The issues are also stored in GEO 2.0 as rental
object. This allows a visual overview of the situation to be given in the report on the Spatial
balance.
Re 3: Theme maps are drawn up in which different parameters can be used. For instance,
you can have maps for expiring contracts, including the extension on options. The period and
class division of the theme displayed can be different for each request. The data
administrator receives requests from departments to produce map overviews based on a
theme which is not directly present in SAP-RE, such as spatial productivity or berth
occupation rate.
Reports
Visualising the spatial balance on maps with:
the current situation (issued, non-issued, non-issuable, etc.);
map of changes compared with last year;
market segment map;
degrees of occupation of jetties/quays;
contract category;
sub areas (parcels);
price per m2;
difference maps show the differences between the current and the future situation.

Status: Draft
4.2 Asset Management Cases
The functional wishes and requirements for asset management for the management of Quay
walls, Works of art and Shores, Roads and Outdoor area.
4.2.1 Introduction
Asset Management uses spatial information very intensively. The asset management
constructions and infrastructure process is performed by managers and inspectors. Broadly
speaking, the functional wishes come from 3 roles:
Inspectors work outside and check whether the managed objects are still in good condition.
Should they encounter any irregularities, they will report them. In practice this means that the
inspector goes out to work with a laptop. If he sees an object on which he wants to report, he
finds the function location of the object in question, and then records the report directly. The
inspector may possibly consult relevant documents before he makes the report.
Managers make and implement policy and supervise contractors for maintenance and
repairs. These activities mean that there is a significant demand for information. The concept
is to create access to all information from an area. This involves opening up whichever data
set or management theme is required with a spatial component.
This information mainly comes from SAP-PM and DgDialog, the archives and the document
management system. The managers use them to consult the information and make simple
maps. The manager is responsible for checking and prioritising the work orders and putting
them on the market. Each report has a response time and/or a solution term. The manager
tries to schedule the activities the best way possible. He can do that by putting all activities
with a low priority in one contract document, or combining activities with a high priority with
activities in progress in the same area.
This requires an area-based approach and spatial overview of the reports and work orders.
When an inspector enters a report, it is checked and prioritised by the manager. The
manager uses GEO 2.0 to gain insight into the location of the reports and work orders.
The data administrator is partly responsible for structuring the management data so it can
be entered in GEO 2.0 and other systems.
The emphasis at AMI is on testing the reality against contract requirements, analysing
performance losses and advising. The quality of the public infrastructure is determined mainly
by maintenance, layout and use.
It is clear from the above that management involves more than just maintaining the area.
There is a concrete relationship between use (wear), layout (design) and maintenance. This
shows that the demand in the AMI management process can be different every time and
therefore the information required can also be different every time. It is important for the
Advisory, Accessibility, environmental and area tasks to be able to consult and analyse
existing information and to be able to present it clearly in map form and overviews, such as
maps, graphs and tables. This especially involves being able to create relationships flexibly
between different spatial components. For Maintenance Management, park management and
disaster management, it is important to compare data from the contractor with data from our
own systems (such as maintenance schedules). Deviations from the contract requirements
need to be analysed, and trends and developments therein determined.

Status: Draft

1. All the stored management object characteristics of the management objects as stored in
SAP-PM
2. All stored management object characteristics of the management objects as stored in
DgDialog (insofar as not stored in SAP-PM)
The export from the expert system DgDialog is linked to GEO 2.0, so the results from
DgDialog can be combined with spatial information.
It must be possible to distinguish status differences (priority, work order created and suchlike)
clearly, using a different colour or symbol. Insight must be created in:
the reports on a past period and in a particular type of report (by means of a theme map)
a theme map of the priority of reports and/or work orders in a particular coming period
(basic schedule for annual plan)
Soundings of quay walls in connection with construction depth available and signal for
certain transgression
Work in progress/project boundaries PoR
Building applications
Documents related to management objects (for example, photos, drawings, front views)

Status: Draft
4.3 Ports and Waterways Cases
4.3.1 Introduction
The aim of the dredging maintenance process, the dredging process, is to keep ports and
waterways accessible.
The Ports and Waterways Asset Management department is responsible for this.
The activities can be divided into 4 categories:
1. maintenance activities
2. dredging projects for internal parties
3. dredging projects for external parties
4. exploitation of North Sea sand
Re 1: The main task consists of managing the maintenance activities. The match between
the theoretical port model (the contract depths) and the measured port model (periodic
assessments) determines where how much needs to be dredged. The dredging activities are
carried out by various dredgers who work according to a framework contract. The quality of
the dredged material determines where it is discharged. Heavily contaminated dredged
material goes to the Slufter, while the rest of the material is dumped at sea.
The accessibility of the port is expressed in the maintenance status. The maintenance status
is the difference between the theoretical port model and the measured port model. The
maintenance status is recorded per area. The maintenance status is the basis for determining
how much dredging needs to be done where. Both the maintenance status and the amount of
dredged material can be made accessible in spatial terms.
Re 2, 3, 4. There is a request from the Port Authority to perform extra dredging. This is done
when a new quay wall is built, for instance. There are two underwater sand depots. They are
filled with sand which can be brought back by the dredgers after they have discharged a
dredged load at sea. This sand is sold to third parties. In addition, there is the management of
the Land depots.
Information required
Capability of presenting management information in a spatial form as a theme map in GEO
2.0. This involves obtaining management information from the combination and geographical
visualisation of data from SAP. Examples are:
the maintenance status per dredging section/region/port
the percentage which satisfies the dredging atlas (the maintenance status)
the maintenance quantity shifted per time unit/cumulatively and per dredging
section/region
comparison with estimated quantity and the forecasts given
the costs incurred per time unit/cumulatively and per dredging section/region
comparison with the available budget and the forecasts given
the quality of the dredged material per sample section/region

ENG - POI Proof of Concept (PoC) Publication v0.3

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

ENG - POI Proof of Concept (PoC) Publication v0.3

Încărcat de

Drepturi de autor:

Formate disponibile

POI Proof of Concept

‘World-class asset management in the port of Rotterdam’

Version: 0.3 1 of 26 version date: 9/11/2012

0.1 5 November 2012 First version of the Proof of Concept

0.2 9 November 2012 Additions to products of PoC steps

0.3 16 November 2012 Publication version

C. Pons Steering group member

R. de Vries Steering group member

H. Meijer Steering group member

L. Visser Steering group member

E. Rademaker Project leader (author)

A.J. Boersma Project team member

L. van der Slik Project team member

F. Apeldoorn Project team member

J. van Scherpenzeel Project team member

W. Albers Project team member

M. van Nederpelt Project team member

N. van Neerven Project team member

L. Wagemans Project team member

E. Jacobs Project team member

E. Jaquet Project controller

I. Schoonenberg Project support

Version: 0.3 2 of 26 version date: 16/11/2012

Audit trail changes

To version Brief description of change

0.1 Initial design of the Proof of Concept

0.2 Products added to the PoC steps

Version: 0.3 3 of 26 version date: 16/11/2012

Copyright 2012, Port of Rotterdam Authority

Version: 0.3 4 of 26 version date: 16/11/2012

Version: 0.3 5 of 26 version date: 16/11/2012

Version: 0.3 6 of 26 version date: 16/11/2012

Figure 4: PoC step-by-step plan

Step 1. PoC preparation

Step 2. Furnish PoC location

Step 3. PoC kick-off

Version: 0.3 7 of 26 version date: 16/11/2012

Step 4. PoR and GEO 2.0 workshop

Step 5. Supplier workshop on basic solutions

Step 6. Import, export and management

Step 7. Transfer of core data

Step 8. Import core data

Step 9. Validate core data

Step 10. Retrieve/select

Step 11. Design (Amazonehaven project)

Step 12. Three clicks

Step 13. Export data

Step 14. Make maps

Step 15. Validate data

Version: 0.3 8 of 26 version date: 16/11/2012

Step 16. Retrieve, select, design and three clicks

Step 17. PoC steering group try-out

Step 18. PoC steering group

Step 19. Look ahead for levels 2 and 3

Version: 0.3 9 of 26 version date: 16/11/2012

The PoC steps are explained in more detail below.

3.1 Step 1. PoC preparation

3.2 Step 2. Furnish PoC location

Version: 0.3 10 of 26 version date: 16/11/2012

3.3 Step 3. PoC kick-off (procedural)

3.4 Step 4. PoR and GEO 2.0 workshop (functional)

3.5 Step 5. Supplier basic solutions workshop

Version: 0.3 11 of 26 version date: 16/11/2012