PORT OF MELBOURNE ECOMMUNITY
SMART FREIGHT SINGLE WINDOW PILOT - Q & A RECEIVED UP TO 18:00 FRI 01 DEC 2006
Contract No. 13110 Closing date: Thu 07 Dec 2006 - 1200 Melbourne time
[ Home ] [ eCommunity Tenders ] [ This EOI ] [ Q&A on EOI ] [ Port Info Flows ] [ AS 4590 Status ] [ Timetable AS4590 Conflict ] [ Copyright ]
		PORT OF MELBOURNE ECOMMUNITY-SMART FREIGHT SINGLE WINDOW PILOT 

QUESTIONS AND ANSWERS UP TO FRI 01 DEC 2006

Design, develop, build, operate, maintain and evaluate the Smart Freight Single Window Pilot
on-line system.

1	Index EOI emails received from Victorian Department Industry

	A	E-MAIL WED 29 NOV 13:04:21 - 15 Questions - PDF file
	B	E-MAIL WED 29 NOV 2006 16:35:22 - 4 Questions - email
	C	E-MAIL FRI 01 2006 16:35:22 - 4 Questions - Word document

2	Index Questions received in those EOI emails

	A	E-MAIL WED 29 NOV 13:04:21 - 15 Questions - PDF file
		1.1.1	Type of Directory service
		1.1.2	How will Directory be Populated and Maintained
		1.2.1	What Functionality required in Pilot
		1.2.2	How much more Functionality expected
		1.3.1	Are they any specific security requirements
		2.1.1	How many interface connections expected to be supported
		2.1.2	What are the volumes for each document message type
		2.2.1	EDI Support - any specific format expected
		2.2.2	What is meant by EDI is this context
		2.3.1	What other formats required for connection
		2.3.2	Are EDI document standards are expected to be defined
		4.1.1	Who will be the contracted provider
		4.1.2	What Model is expected to recover costs
		5.1.1	Who is responsible for co-ordinating supply chain interfaces
		5.1.2	What level assistance expected from suppliers for interfaces

	B	E-MAIL WED 29 NOV 2006 16:35:22 - 4 Questions - email
		1	Does the Pilot have to be hosted in Australia?
		2	Timescale to implement Pilot
		3	Difference between Contractor & Supplier
		4	Financials local or head-office

	C	E-MAIL FRI 01 2006 16:35:22 - 4 Questions - Word document
		Ca	Who Host the Pilot System
		Cb	What Disaster recovery Systems required
		Cc	please clarify "partnering approach"
		Cd	What detail required on Financials

3	Responses to Questions

A	E-MAIL WED 29 NOV 2006 13:04:21 - 15 QUESTIONS

From:           	tenders
To:             	diane
Date sent:      	Wed, 29 Nov 2006 13:04:21 +1100

		1.1.1	Type of Directory service
		1.1.2	How will Directory be Populated and Maintained
		1.2.1	What Functionality required in Pilot
		1.2.2	How much more Functionality expected
		1.3.1	Are they any specific security requirements
		2.1.1	How many interface connections expected to be supported
		2.1.2	What are the volumes for each document message type
		2.2.1	EDI Support - any specific format expected
		2.2.2	What is meant by EDI is this context
		2.3.1	What other formats required for connection
		2.3.2	Are EDI document standards are expected to be defined
		4.1.1	Who will be the contracted provider
		4.1.2	What Model is expected to recover costs
		5.1.1	Who is responsible for co-ordinating supply chain interfaces
		5.1.2	What level assistance expected from suppliers for interfaces

1. Required Application functionality

1.1. Directory service

1.1.1. 	Is the full LDAP directory required to be implemented for the 12 Month pilot, or
	can this be provided using an alternative means for the duration of the pilot ?

An LDAP compliant directory is the preferred approach for the pilot. 

The directory has two functions: 

A	to provide contact details for participants, this requires a "fuzzy search"
	capability, and 

B	for authentication, initially to services on the system i.e. only shipping lines
	will be able to enter a Berth Request, but in the future authentication to external
	service providers i.e. 1-Stop or MaxeTrade is envisaged. 

	In addition, at later stages of the project, (if the pilot is successful), the LDAP
	directory will also need to be able to support the ebXML registry standards.

The directory service is considered to be an integral part of the overall solution and a
proper directory is therefore required; LDAP is the defacto standard. 

The web based "fuzzy and component search" is a critical element in ensuring that the
service is user friendly and easily used by trade participants.

As an example, an exporter may wish to search for a shipping line offering sailings between
certain dates to Port Moresby, or an Importer may want to look for a country trucking company
with side loader capability servicing the Horsham region.

Should respondents consider an alternate mechanism to be preferable, they should so
advise.

1.1.2. 	How is it expected that the directory will be populated and maintained ?

The directory population is the responsibility of the selected vendor, there are
approximately 1000 participant records to be entered, some with multiple contacts.
Potential sources of electronic feeds are:

A	service providers such as 1-Stop, MaxeTrade and Port of Melbourne Corporations
	(PoMC)

B	industry associations such as the customs brokers association or the Victoria
	Transport Association.

C	Sensis

It is expected that Single Window users will be able to maintain their own directory
profiles using an authenticated web-based function. 

Any other operational maintenance will be the responsibility of the selected vendor.

1.2. Scope

1.2.1.	Is all the functionality defined within the scope of the pilot required to be
	available before the pilot can commence ?

It is expected that all functionality defined in the EOI will be available from the beginning
of the pilot. 

If vendors believe there are good reasons to phase this functionality they should advise
such reasons in their response.

1.2.2. 	Are there any plans to expand the scope of single window beyond described in the pilot
	and if so approximately what percentage of known functionality is represented by that
	defined for the pilot ?

Yes. The pilot represents about 50% of the required functionality. 

Additional features that are expected to be added include:

A	electronic document interchange - providing the ability to generation and distribution
	of the standard shipping documents on-line

B	consignment status - expanding the container management operation to allow
	search on consignment

C	electronic payments - allowing the payment of fees to occur on-line with the
	attendant notification to involved parties.

D	electronic trade finance services and export insurance services offered by either
	domestic or international banks

E	integration with Australian Customs Integrated cargo System. 

	This might be a service offered by an existing bureau service or directly by Smart
	Freight to the Customs Service.

In addition the pilot functionality will be expanded. 

Improved alert notification, better trade statistics and more comprehensive container
management are envisaged.

1.3. Security

1.3.1. 	Are there any specific security requirements such as restricting certain company types
	to view certain data ?

The only restriction considered for the pilot is the restriction on the Berth Request -
limited to shipping lines/principle agent.

There will also be a restriction on access to another participant's documents. 

For instance organisations submitting Hazardous Cargo Declarations will be able to access
their forms only. 

Official organisations such as AMSA and the POMC will be able to receive and see the contents
of all declarations.

2. Interfaces

2.1. Connections required

2.1.1. 	There are a number of different shipping lines, freight forwarders and other parties 
	that would be required/able to interface data into the single window, is there an
	expectation on how many of these interfaces need to be supported as part of the pilot ?

All the interfaces defined in the EOI document are the minimum to be supported for pilot.

To the degree possible a single interface for each feature of the system should be
sufficient. 

For instance - if a container park is unable to support the CODECO message it is not necessary
to design another interface for that specific instance. 

It is likely that additional interface requirements will arise during the course of the pilot; 
respondents may wish to limit their development to just those interfaces defined.

2.1.2. 	What are the volumes for each document/message type that would be required to be
	supported during the 12 month pilot ?

Our estimates at the current time - at the 12-month mark are:

a	Vessel Arrival/Departure
	1	lookups (interactive) 500 /day
	2	updates (bulk uploads) 20 /day

b	Berth Request 15 /day

c	Hazardous Goods 	1	import 5 /day

d	Hazardous Goods 	2	export 5 /day

e	Container Status 	1	import- lookups 1,000 /day

f	Container Status 	2	export - lookups 500 /day

2.2. EDI

2.2.1. 	Most of the interfaces are defined as requiring EDI support, is there a particular 
	format (e.g. EDIFACT/X12) and technical connection type (e.g. AS2, Proprietary VAN 
	client) that is required ?

The messages defined in the EOI document are EDIFACT Messages, but there are different
versions and content interpretation that need to be considered.

The shipping industry uses messaging based on the UN/CEFACT standards but these are often 
implemented slightly differently by different participants. 

There is also a move towards XML-based forms within the industry; again various participants 
have defined their own schemas.

The pilot solution envisages a system with an EDI engine i.e. ability to translate forms
and generate forms, some support for variants of forms maybe required.

The preference for the connection would be AS2, however some participants are using
the US based Sterling Commerce network and others connected to Telstra, so depending
on their requirements, service providers may need to be able to support such
connections.

2.2.2. 	What is meant by EDI in this context ?
Electronic Data Interchange. 

It is not expected that the Single Window will offer VAN services, simply termination of an
UN/CEFACT message or generation of a message is envisaged.

2.3. Other formats

2.3.1. 	There are specific formats defined for some interfaces (eg Haz Goods Export is XML via
	FTP) and some web services definitions, is there a particular preference as to which
	formats and connection types are to be offered ? 

To some extent this will be determined by the connections required.

Based on our initial discussions with the providers of information the transports and
formats specified are believed to be what is required.

Vendors should assume that a number of message formats and transport protocols need to be 
supported (e.g. FTP, XML/SOAP, EDI). 

While web services interfaces are preferred some participants e.g. PoMC still rely on FTP and
CSV files.

2.3.2. 	Are Smart Freight looking to define document standards to support the required
	messages either as part of this project or as a long term goal ?

It is intended that the Single Window will be a catalyst for more standardisation in the
supply chain and it is expected that part of the pilot design will define the schemas
required to support the required messages.

The industry participants, particularly shipping lines, will insist on support of their
current message types.

3. Business Model

4. Owner/contracting entity

4.1.1. 	The solution is required to be provided as a hosted/outsourced solution by the service
	provider (e.g. Mincom Axis), who would actually contract with the service provider to
	make the Single Window capability available to all participants ?

Victorian Department of Infrastructure will be the contracting party with the
hosted/outsourced service vendor. 

The Department of Infrastructure is also establishing MOUs with the initial external service
providers e.g. MaxeTrade, 1-STOP and Port of Melbourne Corporation (POMC). 

It is intended that these service providers will be part of the service providing key 
information through the Single window to the Community participants.

4.1.2. 	Is there any expectation that costs will be recovered from the participants, either 
	by the service provider (Mincom) or the Dept of Infrastructure ? 

	This would necessitate certain types of reports etc to provide information to the
	billing process	?

For the pilot the answer is no. 

Beyond pilot there may be commercial models that evolve but such models are yet to be defined 
or agreed.

5. Participant/Trading Partner engagement

5.1.1. 	Who is responsible for engaging with the various supply chain participants to
	facilitate and implement electronic connections ?

It is considered best practice that the vendor develop the necessary interfaces directly
with the various supply chain supply chain participants.

A representative from the Department will make themselves available if assistance is required.


5.1.2. 	What level of assistance is expected from the service provider in implementing and
	support the participants own activities with respect to building capability or
	providing interfaces ?

It is expected that the service provider will define and design the interface requirements
for the participants but the actual development of the "participants side" of the interfaces
is out of scope for the pilot. 

However should the service provider wish to offer such services to participants they will be
free to do so, subject to approval from the DoI.

B	E-MAIL WED 29 NOV 2006 16:35:22 - 4 QUESTIONS

Subject:        	Tender 13110 - Smart Freight Single Window Pilot
From:           	"diane
To:             	diane
Date sent:      	Wed, 29 Nov 2006 16:35:22 +1100

		1	Does the Pilot have to be hosted in Australia?
		2	Timescale to implement Pilot
		3	Difference between Contractor & Supplier
		4	Financials local or head-office

A further Q & A bulletin has been issued with this tender. Please see
below.

1. Does the Pilot have to be hosted in Australia?

No the Pilot does not have to be hosted in Australia, though there may be
advantages to hosting it in Australia.  

In future Government may deem that the Pilot is to be hosted in Australia.

2. Can you advise on a timeframe for the commencement of the Pilot, or will
this depend on the scope of the requirements after the EOI analysis?

We hope to have contracts in place by 30 April 2007, with services up and
running in quarter 3 or 4, 2007.

3. Can you clarify the difference between the contractor and supplier?

The contractor is the proposed operator of the Single Window and a supplier
may provide goods/services to the contractor.
At times contractor and supplier are used interchangeably.  They both
denote the provider of the good or service to the Department.

4. If EOI is submitted by a local office, must financials be for the local
office or can financials be for head office ?

Both local office and head office financials must be submitted.

C	E-MAIL FRI 01 2006 16:35:22 - 4 QUESTIONS

Subject:        	Tender 13110 - Smart Freight Single Window Pilot
From:           	robert
To:             	diane
Date sent:      	Fri, 1 Dec 2006 16:35:22 +1100

Q&A 4

		Ca	Who Host the Pilot System
		Cb	What Disaster recovery Systems required
		Cc	please clarify "partnering approach"
		Cd	What detail required on Financials

1.	In relation to hardware infrastructure do you require the Pilot and eventually the 
	full system to be hosted on it own hardware or could it be hosted on the vendors 
	existing hardware infrastructure.

Smart Freight is willing to consider a hosting situation in which the Single Window is hosted 
in the vendor's hardware.  

Vendors are requested to indicate what portion of the cost of operation is attributed to the
hosting costs.

2.	Do you require for "Disaster Recovery" (DR) systems and if so does this need to be 
	hosted separately from the vendors existing DR infrastructure or can it be hosted on
	existing DR infrastructure.

The Single Window pilot is not considered 'mission critical' however normal redundancy mechanism 
(power, disk mirroring etc.) are highly desirable.  

Normal disaster recovery mechanisms (e.g. disk backup) are considered mandatory.

3.	Can you please clarify "partnering approach"? 

	Is this how the vendor will partner with Smart Freight?

Smart Freight's preference is for the system operator to maintain relationships with service 
providers.  

However, if there are commercial reasons that makes this inadvisable the department will 
discuss other mechanisms to ensure continuity of service delivery.  

Vendors are requested to indicate to what degree they would like Smart Freight to be involved 
in the relationships between participants.

4.	How much detail is required regarding the vendors financial status?

Annual revenue figures are requested to assist the Department in due diligence considerations


[ Home ] [ eCommunity Tenders ] [ This EOI ] [ Q&A on EOI ] [ Port Info Flows ] [ AS 4590 Status ] [ Timetable AS4590 Conflict ] [ Copyright ]

RUBAC Electronic Information Management Methodology Copyright of Hamme Family Trust












































Revised: S: 20:03 Sat 2004/11/06 Syd 2089
F: 20:34 Sat 2004/11/06 Syd 2089
Who: aer
Authorised: prh
Created: 09:45 Tue 13/06/2000 Syd 2065
By: kmb
Revision: 3a4h1.002
Original Page: 3a4h
Change date:
Who:
Authorised: