ΕΛ/ΛΑΚ Μονάδες Αριστείας (ΜΑ. ΕΛΛΑΚ) eServices - Open Source Software in...
-
Upload
ashley-powell -
Category
Documents
-
view
222 -
download
0
Transcript of ΕΛ/ΛΑΚ Μονάδες Αριστείας (ΜΑ. ΕΛΛΑΚ) eServices - Open Source Software in...
ΕΛ/ΛΑΚ Μονάδες Αριστείας (ΜΑ. ΕΛΛΑΚ)eServices - Open Source Software in Transport & Shipping I
UAegean Center of Excellence (CoE) – Open Source Software in Transport and Shipping
University of the Aegean Dpt of Financial and Management Engineering & Dpt of Shipping and Transportation Services
Lecture: I-C02 Service Interoperability the Standard Transportation Document (STD)
Costas PANOU, i4M Lab
Victoria Athanasopoulou, STT
@ i-nformation M-anagement Lab
i4M Lab
So far
Interoperability between systems and products from different stake-holders has proved a key policy issue for business development through innovation and new service designs that meet customer needs
What’s next
The challenge is to further increase the degree of system interoperability by adding new layers of co-operation on top of existing business services and process management layers to allow for a meta-synthesis of existing and novel e-logistic process-centric platforms.
2 i4M Lab
Transport Services have been traditionally evolving along national lines; they now experience the stress of globalization
Transport ICTs have been developed as “silo-ed applications”, following different industrial structures, operations and document models. They now seem to converge under the pressure for multimodal transportation.
Transportation Services, similarly to other industrial services, follow the path of dematerialization and progressively switch to electronic formats for transportation documents.
Freight e-services
A brief review
3 i4M Lab
Freight and transport companies doing e-business want to keep their processes no matter if they’re standard or not.
Large (global) players can set de facto standards; they have the economic power to convince their trading partners to follow.
SMEs do not play an active role in standardization; they are more reactive. This makes it hard for SMEs to develop IT-supported business relationships, should they
find an alternative business partner who provides lower cost or enhanced quality of service.
With the increased uptake of ICT, many argue that the large players will strengthen their position of economic control over the small / medium innovators who develop novel services and use them to compete in the industry.
An alternative form of interoperability is required to allow SMEs to gain access to low cost e-services, beyond any dominant dependencies
The document-based approach to interoperability provides a framework for achieving this goal.
Freight SMEsProblems & features
4 i4M Lab
IT-fueled innovation makes possible new operational efficiencies and enables the integration of supply-chains
e-business supports business processes along the freight value chain, horizontal cooperation between business partners from different transportation modes and service integration
The issue: How to efficiently organize effective e-business networks that span over different transportation modes and business models Several projects address the issue under different angles
Intermodality & e-business
Critical drivers
5 i4M Lab
Hypothesis 1: Behind transport e-business lies the simple idea of electronic documents exchange
Hypothesis 2: Documents in current practices are “mode-specific” and not always electronic. Transport documents for multimodal transport are already operating in the EU but there is no uniformity. The perspective of a Single Transportation Document, applying a single liability regime, is however approaching; it is expected to reduce the cost of administrative procedures and foster the competition between carriers, to benefit consumers of transportation services.
Hypothesis 3: Any suggestion for a Single Transportation Document should cover all the functions of a transport document (including a negotiable title, if it exists) and the accompanying documents but separate the document in sections with varying access rights to them.
Doc-based interoperabilityMain assumptions
6 i4M Lab
1. Implement a Single Transport Document (STD) as a componentized, standardized, document that allows for transport users and operators to dynamically combine their own process into a Single Process. that produces a finite number of document “states”, e.g. initial,
intermediary, final document etc…
2. Hide business processes behind the STD Participants execute their transport processes as usual Their obligation is to inform the STD by exporting to it (and
importing from it) the information bearing the outcome of their process
3. Include transaction information in the STD information model Invoices are part of the STD structure (not visible from everybody).
Doc-based interoperability
Challenges & requirements
7 i4M Lab
Business-to-business relationships are strongly shaped by document structure and document information architecture issues
Document Engineering [R. Glushko & T. McGrath, Berkeley]: A set of analysis and design techniques yielding specifications and rules for information
exchanges and providing meaningful and reusable models of business processes (e.g. patterns) and their documents
Documents are the inputs and outputs of business processeso Business use documents to organize their interactions
Documents serve as the packages of information needed to carry out business processes
Documents serve also as the final outcome of a processo Using standard documents as interfaces for business processes in transportation industry,
implies: “Plug and play” interoperability Business flexibility and high adaptiveness Market transparency
Theoretical frameworkDocument engineering
8 i4M Lab
Applying document-based interoperability requires a freight distributed federation through STD’s implementation and distributed management: Subsystem 1: A distributed Document Management System for STD Subsystem 2 (optional): A Social Business Network (SBN) as the community-enabler
mechanism for the freight federation
Technical overviewthe FreightBook Solution
Distributed Document Management System Social Business Network
+
9 i4M Lab
Point L
C
Transportation Scenario (end): path Origin Location (OL) TSP1 Point of Loading (Point L) TSP2 Transshipment Point (Point T) TSP2 Point of Discharge (Point D) TSP2 Customs (C) TSP3 Distribution Center (localdistr) TSP3 Destination Location (DL) TSP3
STD operational contextA typical use case
Point D
OL
DLlocaldistr
TSP1
TSP2
TSP3
Point T
Point X localdistr Y : check points
10 i4M Lab
As a load moves from the Origin Location (OL) to Destination Location (DL), through Points of Loading (Point L), Transshipment Points (Point T) and Points of Discharge (Point D), the STD changes Each check point “writes” information on the document, by filling up the corresponding sections
of the document; The document is progressively completed with information provided by all the intermediary
process steps, to reach its final version (that holds all relevant information to a load movement); The STD evolves along the transportation path as if shifting from one node to another in
a labeled graph where Nodes are “states” of the document, edges are business processes (OBPs or I-OBPs) A state is a step in the evolution of the STD at which the document has been successfully
updated for the output of a processo Document “accept states” should be considered at any mode, or TU/TSP, transition points, at
Transshipment points and Customs. “Non issue” states correspond to situations where a load, for “contingency” reasons, can not be moved forward, so either an emergency has occurred or re-negotiation of the transportation plan is necessary or the process has reached an end.
A business process is a manner to reach a targeted document state (i.e. process output), starting from the previous one (i.e. process input)
STD design issuesStates and edges
11 i4M Lab
12
STD structureFirst approximation
i4M Lab
Designed, modeled and implemented as application, the STD increases: Interoperability: STD introduces an additional layer of co-
operation functionality on top of business services and process management layers to allow for a meta-synthesis of existing and novel e-logistic process-centric platforms
Market competition: Once the STD is defined as a standard and is communicated, many Services Providers that maintain Business Process Management Systems, may compete to provide service to the “STD document application”
STD developmentImplemented as application
13 i4M Lab
1. Document Modeling
2. Design of an architecture for a distributed document management and records system within the freight federation Freight federation: an environment where common document services
(decentralized storage and search, document restitution from distributed components management etc.) are made available for use in conjunction with others. The collection of document components is managed by a set of interoperating servers distributed over the Internet.
3. Application Development Distributed Doc Components Management within the freight federation
4. API to underlying systems (BPMS, ERPs etc.)
5. Functional interfaces
Development featuresSTD as application
14 i4M Lab
The transport industry needs, as ever, to connect disparate pieces of information into structured knowledge.
The STD serves the move of a load by collecting all the relevant information as the load passes from one check point to another. To change (i.e. to reach an “accept state”), the STD should interact with the
underlying process (edge) so it receives the “expected” information, i.e. the outcome of the process that resulted to the load being moved to the relevant point
The document can hold links to any enterprise application, for example ERPs, so it can integrate invoice information, etc.
Loose coupling: the document is visible, the underlying business process is not. Because it is visible, it should be modeled and designed as an application The underlying process could be “any”, provided that it can produce and consume
the expected “states” of the STD (the business process modeling and execution becomes independent from the document itself).
Loose coupling
Between docs and processes
15 i4M Lab
STD document
Dealing with complexitySTD hides underlying processes
Process 0
TSP A TSP B TSP C
Process 0,1
TSP A TSP B TSP C
Process n-1, n
TSP A TSP B TSP C
16
Init State State S1
State S2…
State Sn-1
Final State
i4M Lab
Freight and transport companies doing e-business want to keep their processes no matter if they’re standard or not.
SMEs do not play an active role in standardization; they are more reactive. The document-based approach to interoperability provides a framework that
allows SMEs to gain access to low cost e-services. To achieve interoperability a Single Transport Document (STD) is
implemented as a componentized, standardized, document that allows for transport users & operators to combine their processes to a Single Process.
By doing so the business process complexity is hidden behind the STD. The STD should be designed, modeled and implemented as application. This provides for loose coupling - a SOA requirement: the document is
visible, the underlying business process is not. Thus, a large number of services and systems (BPMS, ERPs etc.) can become interoperable.
Summary
17 i4M Lab
Για περισσότερες πληροφορίες:
Ευχαριστούμε για την προσοχή σας!
18