FSM Full Service Model Initiative Full Service Model Initiative Latest developement Brussels 16 June 2014 Advisors Full Service Model Initiative 1
Comparing multi-carrier distribution between air and rail From a customer s, railway s and Ticket Vendor s point of view the distribution of tickets looks like this Airlines vs. Railways Full Service Model Initiative 2
FSM signatories FSM has grown into a truly multi-stakeholder industry initiative FSM Members Advisors 1 FSM Sounding Board 2 DG MOVE (EU s Directorate-General for Mobility and Transport), ERA (European Railway Agency), EPF (European Passengers Federation), EIM (European Rail Infrastructure Managers), UITP (International Association of Public Transport), UNIFE (Association of European Rail Industry), EPTO (European Passenger Transport Operators), UIC (International Union of Railways), CIT (International Rail Transport Committee), RNE (RailNetEurope), IATA (International Air Transport Association), 1) ETTSA (European Technology & Travel Services Association), ECTAA (European Travel Agents and Tour Operators Associations) 2) Members of the TAP TSI Steering Committee plus representatives of other modes of transport Full Service Model Initiative 3
The scope of the Initiative is to define the FSM interface standards in order to support a set of identified roles Users Retailers Passenger Customer Retailer Legend: FSM roles FSM standards PO Product owner Relationships (examples) Intermediate distributors Rail Distributor Content aggregator (GDS) Travel service provider PO Combination logic Producers Transport Service Provider Transport Service Provider Transport Service Provider PO PO PO Contractual carrier Contractual carrier Contractual carrier Full Service Model Initiative 4
The FSM organization 1 steering group, 2 Initiative managers, 7 core team work stream experts FSM Steering Group Initiative Managers Claudius Gärtner (DB), Davide Pifferi (TI) Sounding Board WS 1 WS 2 WS 3 WS 4 WS 5 WS 6 WS 7 Master Data, Timetable Data, Nonfunctional requirements Service Subscription, Profiles, In-journey Info Shopping Booking, After Sales Fulfilment, On-board control, Revenue protection Accounting & Settlement, Payment Legal and Contractual consideration General topics, reporting Experts (Reviewers/ Contributors) Full Service Model Initiative 5
The FSM WS leaders have released the first draft version of the overview document The FSM overview will be the first deliverable of the Initiative and it has to be considered as part of the requirements phase. What it is Notions and fundamental concepts The basis to write the requirements A solution-oriented-draft of a possible implementation What it is NOT Summary of requirements Definition of the requirements Definition of the functional scope To be completed in the next two weeks: Some subchapters Revision and proofreading by the experts Full Service Model Initiative 6
How to read the overview document Overview Chapter Important Concepts Outline of the functional scope Content List some of the driving forces which lead to FSM Provide a rationale for some important aspects Provide the ideas behind the business procedures and business object Fundamental and conceptual results They serve as: Referable terms Basic definition of central business abojects or activities First idea of the implementation of the FSM scope A solution is presented on a high level of detail Full Service Model Initiative 7
Bringing FSM to reality: the Proof of Concept On April 8 th 2014, the FSM Steering Group agreed the prepare for a POC as well as for the FSM specification phase X X New house? X The purpose of a proof of concept is to: validate fundamental assumptions design decisions and concepts discover as early as possible potential flaws in the conception before they are transformed into specifications. The POC will require coding and testing and additional tasks as a preparation (e.g. scenario data, interfaces, communication platform, etc.). Planning and performing those tasks will require a dedicated team of technically skilled resources. A specific PoC effort estimation based on a consolidated list of verification items is currently work in progress and will be addressed separately to the FSM Steering Group Members Full Service Model Initiative 8
PoC Procedures and Types of Verification The PoC aims to validate each verification item (requirements to be proofed). Each verification will be one of three types (I, II and III). Each verification task will be put into the full context of known PoCs. This may lead to mergers of verification items and therefore reduce the overall amount of time and effort. The defined tasks will be performed: Type I Verification by Review. The completeness and consistency of requirements related to this general business requirement can be proofed by thinking about it and discuss scenarios Type II Verification by Specification/Design. The draft of the design of a partial solution based on UML diagrams and text will proof the idea behind and its feasibility Type III Verification by Design, Coding and Testing. Example: Affinity Shopping of a Sequence of Business Meetings. A particular aspect of the business requirement Affinity Shopping deals with scheduling issues and has to be checked by prototype coding. Full Service Model Initiative 9
A specific process dedicated to the proof of concept has been designed Each writer of a chapter will have to spend some effort to define specific items for each work package to be validated by the PoC. All verification items for the PoC will be evaluated with respect to the tasks which are necessary for a valid verification and usable results. If the experts and the PoC team agree that no further evaluation is necessary, the result is taken over to the requirements definition Else coding, testing and further evaluation tasks have to be performed Planning and performing those tasks will require a dedicated team of technically skilled resources. Each FSM Member is asked to consider participating in the POC. PoC Team Requirements team Full Service Model Initiative 10