Request for Proposal (RFP) Schedule for „Revenue

Request for Proposal (RFP) Schedule for „Revenue Management

System (RMS)‟ in Biman Bangladesh Airlines.

Biman Bangladesh Airlines invites proposal from bona fide potential bidders for the

development of „Revenue Management System (RMS)‟ in Biman for optimizing load

factor and to determine optimal fare class seat allocation to maximize revenue.

The requirements of the RFP and related information are described in Annexure –

A.

Special instructions for the bidders are mentioned as below:

I. Non-compliance of any condition in the RFP Schedule will be treated as non-

responsive.

II. Proposal is to be submitted to Director Marketing & Sales, Biman Bangladesh

Airlines Limited, Head Office, Balaka, Kurmitola, Dhaka-1229, Bangladesh at

any time on or before Bangladesh Standard Time at 10:00 hours (04:00 hours

UTC) on 29/10/2013 through courier service and e-mail to

[email protected].

III. Offer should remain valid for 90 (ninety) days from the date of closing of the

RFP.

IV. No unsolicited paper/document/information/approach will be entertained at

any stage.

V. As part of the evaluation process, bidders may be requested to present

and/or demonstrate the proposed solution in Biman Bangladesh Airlines

premises at their own cost. Bidders are required to state their willingness to

comply with this requirement in their offer.

VI. Biman Bangladesh Airlines Ltd. reserves the right to accept or reject any or all

proposals/offer(s) at any time and/or stage without assigning any reason,

whatsoever, and no claim shall be acceptable in this regard.

Director Marketing & Sales

Biman Bangladesh Airlines

mailto:[email protected]

Revenue Management System Request for Proposal

10/9/2013 2

Annexure - A

Biman Bangladesh Airlines

Revenue Management System

Request for Proposal

- Private and Confidential -

1. EXECUTIVE SUMMARY ............................................................................................................ 5

2. INTRODUCTION .......................................................................................................................... 5

2.1 ENTERPRISE OVERVIEW ................................................................................................................ 5 2.3 INSTRUCTIONS TO VENDORS ......................................................................................................... 6 2.4 VENDOR RESPONSE ....................................................................................................................... 7 2.5 EVALUATION CRITERIA ................................................................................................................. 7 2.6 CURRENCY AND GOVERNING LAWS ................................................................................................ 8 2.8 APPROVAL ..................................................................................................................................... 8

3.0 DESCRIPTION OF THE BUSINESS REQUIREMENT ....................................................... 9

3.1. BUSINESS OBJECTIVE .................................................................................................................... 9 3.2 EXISTING ENVIRONMENT .............................................................................................................. 9 3.3 DRIVER .......................................................................................................................................... 9 3.4 TARGET SOLUTION METHODOLOGY .......................................................................................... 10

BUSINESS FUNCTIONALITY .......................................................................................................... 10

TECHNICAL DESIGN ........................................................................................................................ 10

PROVIDER DETAILS (INCL ANY 3RD PARTY INVOLVEMENT) .......................................... 10

SOFTWARE ......................................................................................................................................... 10

HARDWARE ........................................................................................................................................ 10

LICENSING ARRANGEMENTS / ONGOING MONTHLY PAYMENT SCHEME .................. 10

SECURITY ........................................................................................................................................... 10

HIGH LEVEL COSTS ......................................................................................................................... 10

PLANS FOR THE PROVISION OF NON-STANDARD FUNCTIONALITY .............................. 10

INTERFACES WITH OTHER SYSTEMS ....................................................................................... 10

TIME SCALE ESTIMATES FOR INSTALLATION ...................................................................... 10

SKILL SET REQUIRED TO INSTALL AND SUPPORT ............................................................... 10

COMMUNICATIONS SUPPORTED AND/OR REQUIRED ......................................................... 10

SCHEDULE OF NEW RELEASES ................................................................................................... 10

OPTIONS AVAILABLE TO BIMAN BANGLADESH AIRLINES WHEN NEW RELEASES

BECOME AVAILABLE ...................................................................................................................... 10

OPTION FOR ASP OR SIMILAR SOLUTION ............................................................................... 10

4.0 VENDOR’S PROPOSED APPROACH AND TIME FRAMES ...................................................................... 11 4.2 VENDOR REQUIREMENTS ............................................................................................................ 11 4.3 VENDOR PROFILE ........................................................................................................................ 11 4.2 SIZE AND STAFFING LEVELS ........................................................................................................ 11 4.3 VENDOR UNDERSTANDING OF BIMAN REQUIREMENTS .................................................................... 12 4.4 VENDOR ASSUMPTIONS, RISKS AND MITIGATING FACTORS ............................................................ 12 4.5 GUARANTEES ............................................................................................................................ 12 4.6 VENDORS PROPOSED SOLUTION ...................................................................................................... 12 4.7 VENDOR’S PROPOSED APPROACH AND TIME FRAMES ...................................................................... 12 4.8 PROJECT ORGANISATION ............................................................................................................. 12

5 BUSINESS REQUIREMENTS ................................................................................................... 13

5.1 USER INTERFACE REQUIREMENTS ............................................................................................... 13 5.2 FORECASTING SYSTEM ................................................................................................................ 18 5.3 OPTIMISATION SYSTEM ............................................................................................................... 20 5.6 REPORTING SYSTEM .................................................................................................................... 23

6. COMMUNICATIONS ................................................................................................................. 37

6.6 E-BUSINESS ................................................................................................................................. 38


10/9/2013 4

6.7 IMPLEMENTATION AND MAINTENANCE ....................................................................................... 39 6.9 QUALITY MANAGEMENT ............................................................................................................. 41 6.10 SECURITY .................................................................................................................................... 41

7 OPERATIONAL REQUIREMENTS ......................................................................................... 42

8.1 CONFIGURATION ......................................................................................................................... 42 7.2 PERFORMANCE ............................................................................................................................ 42 7.3 NETWORK MANAGEMENT ........................................................................................................... 43 7.4 SCHEDULING ............................................................................................................................... 43

8 COSTS ........................................................................................................................................... 43

8.1 EQUIPMENT ................................................................................................................................. 43 8.2 PROFESSIONAL FEES .................................................................................................................... 43 8.3 TRAINING .................................................................................................................................... 44 8.7 CHANGE REQUEST COSTS ........................................................................................................... 44 8.7 SUPPORT COSTS .......................................................................................................................... 44 8.7 EXPENSES .................................................................................................................................... 44 8.7 OTHER ......................................................................................................................................... 44 8.9 APPLICATION SERVER PROVIDER (ASP) SOLUTION .................................................................... 44


10/9/2013 5

1. Executive Summary Biman Bangladesh airlines (hereafter referred to as Biman) is seeking proposal for the provision of a Revenue Management System together with the provision of resources that will enable the full implementation of a new Revenue Management System by 29 Oct 2013. In this document Biman has set out the business, technical, process and organizational requirements for the software and hardware developments it requires. In order to qualify for evaluation Biman requires that Vendors submit an accurate response that fully complies with the Vendor Guidelines.

2. INTRODUCTION

2.1 Enterprise Overview

Biman Bangladesh airlines is the national flag carrier of Bangladesh. Its main hub is at Shahjalal International Airport in Dhaka and it also operates flights from its secondary hubs at Shah Amanat International Airport in Chittagong and Osmani International Airport in Sylhet. The airline provides international passenger and cargo services globally as well as to major domestic routes inside Bangladesh. It has air service agreements with 42 countries. The airline's headquarters, Balaka Bhaban, is located in Kurmitola, Dhaka. Annual Hajj flights; transporting tourists and non-resident Bangladeshi workers and migrants; and the activities of its subsidiaries form an integral part of the airline's business. Bangladesh's air transport sector is experiencing an 8% annual growth rate, thanks to a large number of tourists, VFR traffic and non-resident Bangladeshi travelers. Created in February 1972, the airline was wholly owned and managed by the government of Bangladesh until 23rd July 2007, when it was transformed into the country's largest public limited company by the Caretaker Government of Bangladesh. Since becoming a public limited company in 2007, the airline has begun to modernize its fleet, including replacement of their DC10 fleet with ten new Boeing 777s along with options for ten more. Biman Bangladesh Airlines is certified as safe to fly in Europe by the European Aviation Safety Agency and it also successfully passed the IATA Operational Safety Audit. 2.2 Vendor RFP Guidelines This section describes the format and content of the response that Vendors should supply for evaluation. It is important that all are covered in order to qualify for evaluation.

Biman requires Vendors to submit a proposal that will provide the following:

The Vendor‟s own resources to develop, integrate, and implement the system into existing structures, including a site survey. Vendors should indicate source of resources, e.g. USA, Asia or Europe.

Detailed business functionality to match up with the requirements set out in Section 5

Business functionality over and above the requirements in Section 5

Software required for its operation

Special environment requirements

Support software requirements

Details of implementation support available

Details of ongoing post-implementation support

Backup and standby facilities

Level of training provided - User

Level of training provided - Technical


10/9/2013 6

Equipment configuration required to support the product

Size, capacity and speed of hardware required

Identify any capacity limitations

Security Features

Itemized costs

Summary of costs

The proposed solution will support:

• The business objectives of Biman (see section 3.0)

• The integration of the business and technical objectives by developing the existing processes (see sections 5,6,7)

The delivery will include functional and technical design, development, testing and implementation of all outlined requirements in this document. Availability of the Vendor for post-implementation support and future development is considered an advantage to their proposal.

The airline will provide key senior Biman IT specialists, Business expertise and Project Management to work closely with the Vendor team. The vendors should only propose a solution that adheres to Biman‟ standards, procedures and security criteria.

Biman require that the Vendor work closely with the Project Team with the appropriate skill transfer taking place. Biman will provide a number of full time business and technical resources to work with the Vendor. Biman has a Steering Committee in place to lay down the broad directions and provide the necessary resources to carry out the project. The project is sponsored by the Group Commercial Director.

2.3 Instructions to Vendors

This RFP is placed with Vendors on the understanding that its contents are confidential and may not be disclosed to any third party not involved in fulfilling the proposal requirements. Any form of canvassing will disqualify. Government regulations require the successful contractor to provide Biman with a copy of their current tax clearance certificate before the contract may commence. Responses should be returned by email as a soft copy Word/Excel document to

[email protected] Late submissions will be omitted from the evaluation. Interested parties requiring additional information may address all queries to the following people at Biman via e-mail. (No other personnel in Biman should be contacted in this regard). The e-mail contact address is: [email protected]

2.3.1 Time Scale

Time Scale Action

08 October 2013 RFP circulated to Vendors

21 October 2013 Deadline for receipt of queries

23 October 2013 Biman response to queries

29 October 2013 Noon Deadline for receipt of proposals from Vendors

4-12 November 2013 Vendor Presentations & demo

Relevant information contained in the proposal submission may, at the discretion of Biman, form part of the final agreement between it and the selected Vendor.




10/9/2013 7

Acceptance by Biman of a proposal submission will not constitute a binding agreement and any such acceptance will be subject to the negotiation of satisfactory contractual arrangements with the selected Vendor. Each party shall bear their own legal costs in relation to the negotiation and preparation of contractual documentation. Biman does not bind itself to accept the lowest cost, or any tender and reserves the right to:

Select any tender in whole or in part

Reject any tender which, in its opinion, fails to address any of the points specifically mentioned in the RFP

Make no selection

Seek further clarification with one or more Vendors The option selected will be chosen on the basis of greatest benefit to Biman and not necessarily on the basis of lowest price or any other criteria. All costs incurred in the preparation and development of a response to the proposal is to be borne by that Vendor and do in no way create any liability on the part of Biman. The proposed solution is to be implemented in three phases, starting in January 2014, with phase two to commence in April 2014 with a completion target date of August 2014 for the Revenue Management System.

2.4 Vendor Response

The Vendor will become the single point of contact for all dealings with the RFP and if successful will handle all dealings with third parties for the implementation of this project. Subsequent to the project Biman will retain all rights to negotiate support contracts with any third party Vendors. Failure to submit the minimum criteria in the proposal will render the proposal invalid. A Vendor‟s proposal and all supporting documentation and manuals will be retained (and copied internally, if necessary) by Biman. The Vendor should identify the owners of intellectual property rights of the solution components. Biman will treat all information, documentation and other materials provided by Vendor‟s as confidential subject to its obligations at law.

2.5 Evaluation Criteria

• The proposals will be evaluated based on their effectiveness in fulfilling the minimum criteria as outlined below:

Suitability of proposed approach to the project (resources, skill set, project management)

Length of time to deliver all aspects of the project

Costs (breakdown by functional module as outlined in the pricing structure)

Business Functionality (The Business Functionality of the proposed product)

Technical requirements

Implementation Support

Security (as outlined in Section 6, sub-section 6.10 - Technical Requirements)


10/9/2013 8

Systems Performance

Integration with current Biman environment

Suitability of reference sites

Post implementation support

2.5.1 Evaluation Process

The proposals will be reviewed to assess if the criteria are met.

2.5.2 Presentations to Management

The opportunity will be given to present your proposal to Biman management at an appropriate location during early November 2013. It is expected that a whole day will be allocated to each of the short-listed Vendors. The Vendor will be free to bring in any of their own equipment for the presentation and the room will be available for 30 minutes prior to the start of the presentation for the setting up of equipment.

2.5.3 Response Format

Please ensure when replying to questions in this document that your numbering is consistent with this document in order to coincide with the numbering used in sections 4, 5, 6, 7 and 8. This will greatly assist the project team when evaluating your response. Biman request that wherever possible, you supply a compliance matrix in table format as an appendix to your tender. This should state clearly the RFP reference number and one of the following classifications associated with your response. Vendors are encouraged to comment on the responses they provide in this matrix.

a) A - where you are able to satisfy the requirement in full without modification to your existing software or hardware;

b) B - where you are able to satisfy the requirement in full with some modification to the existing software or hardware. In these cases please also supply a date when these changes could be made available for Biman‟ use and the effort required to make the modification. The effort required should include the Biman effort required, the required location of the Biman staff for work on the modification, and the length of time the Biman staff will be required;

c) C - where you partially satisfy the requirement;

d) D - where you do not satisfy the requirement.

Where possible, please provide examples of screen prints, functional descriptions, user documentation, system reports, and calculations used to supplement your responses.

2.6 Currency and Governing Laws

All proposal costs must be quoted in US dollars. This RFP and any resulting contracts shall be governed by and enforced in accordance with the laws of Bangladesh.

2.8 Approval

Awarding of this contract under this RFP is subject to and conditional upon approval by the Biman board.


10/9/2013 9

3.0 Description of the Business Requirement

3.1. Business Objective

Revenue Management is recognized in Biman as a significant contributor to the profitability of an airline. An in depth evaluation of Inventory Management in Biman has identified benefits that are achievable through investment in Revenue Management functionality. This functionality includes business rules, forecasting of unconstrained demand, having serial nesting reflected in both the optimization and the reporting systems, and groups optimization. Currently Biman has no reporting functionality in the Commercial area, so the RMS must have leading edge reporting capability as standard.

3.2 Existing Environment

3.2.1 Current System

Currently Biman has no RMS, but uses SITA Inventory to control its flights manually. Biman has little reporting capability at present, so the RMS should be able to fund substantial commercial reporting for the airline both in the RM areas and externally for key partners such as Sales, Marketing, and Customer Services etc.

3.2.2 Current system volumes

Summer schedule Winter schedule

Average number of daily departure 28 40

Classes in inventory system 25 15

Total number of users: 24

3.3 Driver

There are a number of drivers behind this project.

Revenue benefits are achievable with new functionality

To bring Biman Bangladesh airlines to the state of the art in Revenue Management Technology and functionality

To minimize the cost of maintenance and development

3.3.2 Scope

The scope of the existing activity covers the operation of the Revenue Management department based in Dhaka. The operations of the department include the support and management of the following domains: Achievement of budget revenue and passengers through control of inventory Facilitation of pricing, scheduling and promotional decisions Forecasting of booked and flown passengers Reporting on flight inventory In addition, the department supports decision making in the following areas Pricing Sales Distribution Resource Management Fleet Allocation Schedules Planning Business Planning Vendors should indicate how their proposed solution supports decision making and business integration with these areas.


10/9/2013 10

Biman would also like to file all their fares in future with ATPCo (currently only a small percentage are filed with ATPCo who undertake the work on Biman‟s behalf) ideally using the RMS to view filings and action them. Manage and maintain fare database

Reads ATPCO submissions Auto-respond to competitive fare changes Can transmit ATPCO change files

3.3.3 Future system volumes The proposed system should be able to handle at least double the volumes described in section 3.2.2 along with 26 inventory classes. Vendors should demonstrate the implications of doubling the volumes.

3.4 Target Solution Methodology

Biman Bangladesh Airlines proposes to identify and acquire a suitable Vendor software package to support its Revenue Management requirements. All potential scenarios will be given due consideration. Please propose for consideration an internal solution where at least the following should be defined:

Business functionality

Technical Design

Provider details (incl any 3rd party involvement)

Software

Hardware

Licensing arrangements / ongoing monthly payment scheme

Security

High level costs

Plans for the provision of non-standard functionality

Interfaces with other systems

Time scale estimates for installation

Skill set required to install and support

Communications supported and/or required

Schedule of new releases

Options available to Biman Bangladesh airlines when new releases become available

Option for ASP or similar solution


10/9/2013 11

4.0 Vendor’s Proposed Approach and time frames

4.1 Vendors are asked to submit a schedule for the overall solution showing the time scales to implement all aspects of the project. This should detail options relating to ASP or similar solutions. As Biman Bangladesh Airlines is anxious to complete a quality project within a tight time frame, the length of time to deliver all aspects of the project will be a key evaluation criterion. Biman Bangladesh Airlines reserves the right to approve all personnel (both Vendor and third party) who will work on the project. Biman Bangladesh Airlines will hold the Vendor responsible for the delivery of the entire solution including those deliverables that are sub-contracted to a third party. The Vendor will be the sole point of contact for all aspects of the supply of this project.

4.2 Vendor Requirements

The questions in this section are aimed at giving the Biman an indication of the capability, size and financial stability of your company.

4.3 Vendor Profile

Briefly describe your company‟s activities in terms of: - 4.1.1 Company profile including: 4.1.1.1 The relationship with any parent group 4.1.1.2 Principal Products and Services 4.1.1.3 Sub-contracting arrangements 4.1.2 Financial Summary and organizational structure, including evidence of financial

strength necessary to provide the proposed solution. 4.1.3 Customer base and references 4.1.4 An outline of the company‟s relationship with other companies who will form part of

their proposal 4.1.5 Information on what qualifies the Vendor to provide this solution to Biman 4.1.6 Functional and technical experience 4.1.7 Strategy for future development 4.1.8 Identification of a key contact point 4.1.9 Relevant experience of Vendor including proposed Vendors partners And provide a copy of your mission statement and most recent financial statements of the proposed contracting organization.

4.2 Size and Staffing Levels

4.2.1 Specify the number of employees in your company: 4.2.1.1 World-wide 4.2.1.2 in Europe 4.2.1.3 in Asia 4.2.2 How many projects, of a similar size (in terms of the size of the project team) have

you conducted in this country in the last five years? Please provide brief descriptions of two such projects and the names of reference clients that we may contact.

4.2.3 How many projects, of a similar size (in terms of the size of the project team) have

you conducted elsewhere in the last five years? Please provide brief descriptions of two such projects and the names of reference clients that we may contact.


10/9/2013 12

4.2.4 How many projects, of a similar size (in terms of the size of the project team) have you conducted in the airline industry in the last five years? Please provide brief descriptions of two such projects and the names of reference clients that we may contact.

4.2.5 The Vendor should supply details of contacts at the aforementioned reference sites. Biman may consider a site visit to the reference sites in the final stages of selection.

4.3 Vendor Understanding of Biman Requirements

Vendors should outline what they understand the requirements of the RFP to be. This will allow Biman to read the suggested proposal in these terms.

4.4 Vendor Assumptions, Risks and Mitigating Factors

Vendors are required to clearly state the assumptions they have made in proposing a solution to the RFP. Vendors should state which assumptions could affect the project in terms of cost and/or time frame. Vendors are required to clearly state the risk and mitigating factors, which they perceive in proposing a solution to the RFP. Vendors should clearly state which risks and mitigating factors could affect the project as regards the costs and/or time frame. Vendors are also asked to outline their risk management approach in delivering this project.

4.5 Guarantees

Please supply details of the warranty provided and any other guarantees that are provided with the proposed solution.

4.6 Vendors Proposed Solution

The Vendor should detail how they propose to address Biman requirements as detailed in this document. This should detail options relating to ASP or similar solutions.

4.7 Vendor’s Proposed Approach and time frames

4.7.1 Vendors are asked to submit a schedule for the overall solution showing the time scales to implement all aspects of the project. This should detail options relating to ASP or similar solutions. As Biman is anxious to complete a quality project within a tight time frame, the length of time to deliver all aspects of the project will be a key evaluation criterion. Biman reserves the right to approve all personnel (both Vendor and third party) who will work on the project. Biman will hold the Vendor responsible for the delivery of the entire solution including those deliverables that are sub-contracted to a third party. The Vendor will be the sole point of contact for all aspects of the supply of this project. 4.7.2 Vendors should outline the options for performing the various tasks of the project in terms of location. Biman can provide facilities at their head office in Dhaka for a project team.

4.8 Project Organization

(This information is provided for Vendor information) Biman has established a steering committee to oversee this project. Biman expect Vendors to submit a proposal, which is based on taking responsibility for the delivery of the functional and technical design, development, testing and implementation phases of the project.


10/9/2013 13

The Vendor resources will work as a team with Biman resources. Biman will supply business and technical resources throughout the project. The core Biman implementation team is estimated as follows. Key users will be co-opted onto the team as necessary. Internal Biman Project Team Project Manager Technical Manager Business Manager

5 Business Requirements This section should be answered using the classifications outlined in Section 2.5.3

5.1 User interface Requirements

The business objective of the Revenue management user interface system is to provide users (both ordinary and administrator) with a means to view the details of the flights that have been optimized and of the influences that they have put on flights and to forecast and optimize flights on a daily basis. This is to be done in a way that allows Biman to use and administer the system in the most efficient manner possible.

The main objectives of the front end are To allow users to access flight forecast and optimization information To allow users to perform their daily tasks in as efficient a manner as possible To allow users to influence forecasts and the optimization process through an intuitive

and user friendly front-end To action mass manual edits Ability to view and edit hundreds of flights simultaneously

The main objectives of the daily processing are To upload data from the inventory, reservations and departure control systems to the Revenue management system to generate and update forecasts To perform optimization and update the inventory system automatically To run reports System is highly customizable

One, two, three or four cabin aircraft Interfaces with any reservations system Totally flexible bucket and nesting configurations Hundreds of other configurations can be set

Customizable view of details for an individual flight

Hundreds of variables to choose from Automatic graphs Tabs to organize display Easily see all history used for Forecast

Unique ability to review hundreds of flights at once

Color coded display allows analysts to easily see flights that need addressing Ability to filter to flights that meet specific criteria related to bookings, forecast

or competitive position Ability to change inventory on all flights in a display with a single action

5.1.1 SYSTEM FRONT END 5.1.1.1 The front end should be a Graphical User Interface 5.1.1.2 The front end should allow access to the following in one program 5.1.1.2.1 Flight optimization details 5.1.1.2.2 Forecast information 5.1.1.2.3 Forecast influences 5.1.1.2.4 Optimization influences 5.1.1.3 It should be possible to define flight groups, i.e., to group flights by flight number


10/9/2013 14

5.1.1.4 It should be possible to define route groups, i.e., to group flights by board and off point

5.1.1.5 The flight and route groups should be available to 5.1.1.5.1 Forecast influences, i.e., users should be able to specify that a forecast influence

applies to a particular flight or route group 5.1.1.5.2 Optimization influences 5.1.1.6 Users should be able to define the information that goes on each screen 5.1.1.7 Users should be able to click on any graphs and see the values on the data

points 5.1.1.8 It should be possible to display up to 26 classes. 5.1.1.9 The system should only display the classes offered for sale on a flight 5.1.1.10 It should be possible to display up to three cabins. 5.1.1.11 The system should only display the cabins offered for sale on a flight 5.1.1.12 There should be context sensitive on-line help provided 5.1.1.13 The help file should have a table of contents through which users can navigate 5.1.1.14 Users should be able to search through the help files for keywords 5.1.1.15 Where error messages are generated, there should be on-line help related to the

error message 5.1.1.16 The system should display revenue values in USD or Biman Taka 5.1.1.17 The system should comply with IATA/SSIM standards 5.1.2 DAILY OPTIMISATION REVIEW 5.1.2.1 The users should be able to see the list of flights for their attention as soon as

they run the program 5.1.2.2 This list should display all flights that have been optimized and that had revenue

opportunity 5.1.2.3 The list should display the following 5.1.2.3.1 Flight number 5.1.2.3.2 Date 5.1.2.3.3 Days left 5.1.2.3.4 Revenue Opportunity 5.1.2.3.5 Revenue Priority 5.1.2.4 Reasons for optimization 5.1.2.4.1 Fixed days left 5.1.2.4.2 Class level booking surge 5.1.2.4.3 Cabin level booking surge 5.1.2.4.4 Schedule change 5.1.2.4.5 Group cancellation 5.1.2.5 When displaying this list, the following on/off flags should be used 5.1.2.5.1 Automatically updated to the inventory system 5.1.2.5.2 Capacity change recommended 5.1.2.5.3 Planned upgrades recommended 5.1.2.5.4 Projected booking factor > x1% 5.1.2.5.5 Projected booking factor < x2% 5.1.2.5.6 Projected load factor > y1% 5.1.2.5.7 Projected load factor < y2% 5.1.2.6 Users should be able to sort this list by any combination of the fields in the list 5.1.2.7 Users should be able to view the details of the optimization results for each flight

directly from this first screen 5.1.2.8 The details of the optimization results should display the following items in the

same screen 5.1.2.8.1 Class level Authorization and SCI changes 5.1.2.8.2 Booked by individual and group passenger 5.1.2.8.3 Cabin level forecasts 5.1.2.8.4 Unconstrained remaining demand by class 5.1.2.8.5 Forecast no show rate 5.1.2.8.6 Average fares by class 5.1.2.9 The class level authorization changes should be numeric 5.1.2.10 Users should be able to update flights to the inventory system where they agree

with the recommended inventory changes.


10/9/2013 15

5.1.2.11 Where users want to update a flight in the inventory system, this should be done on-line

5.1.2.12 5.1.2.13 When a flight is displayed from the flight list, the system should trigger up to two user-definable reports

5.1.2.14 When a flight is displayed from the flight list, the system should send a user-definable message to the inventory system to access the on-line information relating to the flight

5.1.2.15 Users should be able to add an influence directly from the screen showing the optimization results

5.1.2.16 When adding an influence in this manner, it should be possible to specify the level at which the influence applies

5.1.2.16.1 Flight level 5.1.2.16.2 Route one way 5.1.2.16.3 Route round trip 5.1.2.16.4 Route group 5.1.2.16.5 Class level 5.1.2.16.6 Cabin level 5.1.2.16.7 Aircraft level 5.1.2.16.8 Departure time range 5.1.2.16.9 Date range 5.1.2.16.10 Day of week 5.1.2.17 The system should be able to automatically enter some of the data required to

enter an influence in this way, e.g., where route round trip and cabin level are chosen, the values for this should be entered automatically and the user should only have to enter the influence value

5.1.2.18 Users should be able to see the effect of the influence immediately 5.1.2.19 There should be screens showing all of the data that make up the forecasts for a

flight. 5.1.2.20 Users should be able to bring the current bookings for the flight into the optimizer

and the system should automatically re-forecast and re-optimize the flight 5.1.2.21 Current bookings should always be brought up for a flight that falls into user

definable days left parameters 5.1.2.22 Users should be able to change the aircraft type in the Revenue management

system and re-optimize the flight, i.e., to see the effect of using a different type of aircraft, users should be able to enter a type that would be read from the Equipment Seat map.

5.1.2.23 There should be a status bar on the front end that shows 5.1.2.23.1 Percentage of flights reviewed/updated 5.1.2.23.2 Percentage of Revenue Opportunity reviewed/updated 5.1.2.23.3 Percentage of Revenue Priority reviewed/updated 5.1.2.24 It should be possible to optimize flights on an ad-hoc basis 5.1.2.25 Ad-hoc flights should be included in reports on system usage 5.1.2.26 When flights are ad-hocked, the flight should be re-forecasted and re-optimized.

All other processes should be as described for flights taken from the user‟s flight list

5.1.3 USER TYPES 5.1.3.1 There should be at least three types of user – RM Analyst, Reporting capability

only and administrator 5.1.3.2 An administrator should have access to all tables in the system 5.1.3.3 An administrator should have direct access to the database through SQL. 5.1.3.4 A user should only have access to the tables relating to forecast and optimization

influences 5.1.3.5 It should be possible to deny ordinary users access to other ordinary users‟ flights 5.1.4 DATA REQUIREMENTS Vendors should state the data required from the reservations, inventory, and, departure control system in each nightly download. Any other data required to use and run the system should be specified here.


10/9/2013 16

Additional data Biman require to be incorporated into the RMS: 5.1.4.1 PNR data 5.1.4.2 SSIM 5.1.4.3 ATPCo 5.1.4.4 OAG 5.1.4.5 Web fare data collected by a robotic such as QL2 or Infare 5.1.4.6 Ancillary revenues 5.1.4.7 “Look to book” data from Biman‟s website 5.1.4.8 Weather 5.1.4.9 Twitter All of these elements become part of the revenue management database and can be reported on for historical purposes (i.e. historical competitive fares). 5.1.5 EXCEPTIONAL DATA REQUIREMENTS 5.1.5.1 There should be a facility for taking flown data by cabin from non-mechanized

stations and estimating flown data by class from it. 5.1.5.2 There should be a table indicating which stations are non-mechanized stations 5.1.5.3 It should be possible to manually enter Denied Boarding data for a flight 5.1.5.4 Where Denied boarding data exists in the manual table and from departure

control, the manual data should be used. 5.1.5.5 There should be a facility for entering historic average revenue by segment and

class 5.1.5.6 It should be possible to enter a start date and an end date for each historic

average fare value 5.1.5.7 There should be a facility for entering forecasted average revenue by segment

and class 5.1.5.8 It should be possible to enter a start date and an end date for each forecasted

average fare value 5.1.5.9 There should be at least two types of forecasted average fare, 5.1.5.9.1 A batch loaded fare which has a start and end date of the first and last day of the

month to which it applies 5.1.5.9.2 User overridden fare which can have any start and end date 5.1.5.10 The system should be able to handle two different segments or legs with the

same board point, off point, departure date or local departure date, and departure time

5.1.6 DAILY PROCESSING REQUIREMENTS The following requirements relate to forecasting and optimization of flights. These are required to be performed at least once a day. Vendors should state whether or not these functions need to be batched and if so, whether or not the system needs to be shut down to perform them. 5.1.6.1 Where the system needs to be shut down, it should be done within the hours of

10pm and 5:30am LOCAL TIME 5.1.6.2 The daily processing should do the following 5.1.6.2.1 The system should load data from the inventory/reservations system and the

departure control system into the Revenue management system, the Groups evaluation functionality, and the reporting system

5.1.6.2.2 The system should create and update forecasts for flights in the manner outlined in section 5.2, Forecasting Methodology

5.1.6.2.3 The system should optimize all flights that have been forecasted and decide on uploading these flights to the inventory system

5.1.6.2.4 The system should run a set of reports specified by the users 5.1.6.2.5 The system administrator should be able to kill the reports process 5.1.6.3 The system should optimize a series of flights and sort them by the users to

which they apply 5.1.6.4 It should be possible to specify which flights apply to which users by 5.1.6.4.1 Flight number 5.1.6.4.2 Days left range


10/9/2013 17

5.1.6.5 It should be possible to set a minimum value of revenue opportunity that must be fulfilled before a flight is updated to the inventory system or placed on the user‟s flight list.

5.1.6.6 During the optimization process, the system should automatically update optimization recommendations to the inventory system (Autopilot/Auto controls)

5.1.6.7 The system should use user specified criteria in deciding whether or not to update a flight automatically to the inventory system

5.1.6.8 These criteria should include 5.1.6.8.1 Projected load factor by aircraft or cabin 5.1.6.8.2 Projected booking factor by aircraft or cabin 5.1.6.8.3 Exclude regardless of recommended changes 5.1.6.8.4 Exclude if recommended overbooking profile by aircraft or cabin is greater than a

certain value 5.1.6.8.5 Exclude if recommended overbooking profile by aircraft or cabin is less than a

certain value 5.1.6.8.6 Exclude if the recommended Authorization by cabin or class exceeds a certain

value 5.1.6.8.7 Exclude if the recommended SCI is at a certain value 5.1.6.9 The scope of the criteria should be 5.1.6.9.1 Flight number range 5.1.6.9.2 Route 5.1.6.9.3 Route group 5.1.6.9.4 Date range 5.1.6.9.5 Day of week 5.1.6.9.6 Days left range 5.1.6.10 Flights that are not automatically uploaded to the inventory system should be

placed on a list for each user to review the following morning 5.1.6.11 New special events should be processed when the forecasts are updated 5.1.6.12 The system should be capable of optimizing up to 5,000 flights per day 5.1.7 VENDOR SUPPORT 5.1.7.1 There should be comprehensive user documentation provided for users 5.1.7.2 There should be comprehensive system documentation provided for system

administrators 5.1.7.3 There should be training for users in Revenue Management concepts 5.1.7.4 There should be system training for users 5.1.7.5 There should be advanced system training for system administrators 5.1.7.6 There should be upgrades to all modules available on a regular basis. 5.1.7.7 Vendors should state the level of support offered for each component of their

system. 5.1.8 INTERFACES The following are the interfaces with the Revenue management system. Interfaces g) to n) are possible future interfaces.

a) Robotic web fare data collected by a system like QL2 or Infare b) Groups evaluation functionality b) Reporting system c) Inventory system d) Reservations system e) Departure control system f) Revenue accounting system g) Pricing i) Sales j) Distribution k) Resource Management l) Fleet Allocation m) Schedules Planning n) FF program


10/9/2013 18

Indicate how it is proposed to handle these interfaces in terms of 5.1.8.1 Processes 5.1.8.2 Delivery Mechanism 5.1.8.3 Software 5.1.8.4 Content

5.2 Forecasting system

The business objective of the forecasting system is to have a stable forecasting engine that forecasts individual and group demand characteristics such as bookings, no-shows and cancellations. This should provide forecasts for every flight segment, date, and inventory class. Users should be able to influence the forecasting system to reflect their view of market conditions and to impose business rules on the process. Forecasting should provide

5 different models

Multiple methods to select historical data

The RMS should have No Data Collection Points (DCPs), but have a historical database which contains flight information for every day prior to departure 5.2.1 FORECASTING METHODOLOGY Vendors should describe in detail the forecasting methodology used in their system. In each answer, the level of detail at which each forecast is generated, i.e., aircraft, cabin, etc., should be specified. Where several components go into making up a forecast, this should be specified and the data used in each component should be outlined. The responses should include the following. How a forecast for individual demand is calculated How a forecast for individual no-shows is calculated How a forecast for individual go-shows is calculated How a forecast for individual cancellations is calculated How a forecast for group no-shows is calculated How a forecast for group cancellations is calculated What data is needed to produce a forecast for a flight How seasonality is calculated How constraining is done. How outliers are detected and removed How a system administrator can influence outlier detection 5.3.1.1 The system should forecast the following 5.2.1.1.1 Unconstrained individual demand by class 5.2.1.1.2 Individual cancellations by class 5.2.1.1.3 Individual no shows by class 5.2.1.1.4 Individual go shows by cabin 5.2.1.1.5 Group no shows by class 5.2.1.2 The system should detect outliers in the data and remove them from forecasts. 5.2.1.3 It should be possible to forecast flights as soon as they come into the inventory

system (currently this is at 342 days left) 5.2.1.4 There should be no limit to the data capture days left and forecast should be re-

run every 7 days for each flight 5.2.1.5 There should be triggers that will cause a flight to be re-forecasted between the

data capture days left values. These triggers should be 5.2.1.5.1 Bookings in a class since last data collection days left, individual or group

exceeds a set value 5.2.1.5.2 Bookings in a cabin since last data collection days left, individual or group

exceeds a set value 5.2.1.5.3 Group cancellations 5.2.1.5.4 Schedule change 5.2.1.6 It should be possible to set different triggers on different days of the week.


10/9/2013 19

5.2.1.7 The system should forecast by segment by departure time. 5.2.1.8 In looking for history, the system should find the history with the nearest

departure time 5.2.1.9 If there is no history within a user specified number of minutes then the forecast

should not be done 5.2.1.10 The specified number of minutes should be specifiable by 5.2.1.10.1 Board Point 5.2.1.10.2 Off Point 5.2.1.10.3 Date range 5.2.1.10.4 Minutes before 5.2.1.10.5 Minutes after 5.2.1.11 The system forecast, i.e., the forecast the system would produce without any

influences, should be stored 5.2.1.12 The user influenced forecast should be stored 5.2.1.13 There should be a tool to analyze the forecast generated on any flight, including

all historical data used and influences that affected the outcome 5.2.2 FORECASTING INFLUENCES 5.2.2.1 When entering influences, users should be able to enter an influence that applies

to some or all days of week (numbered 1 to 7) in one entry 5.2.2.2 When entering influences, users should be able to enter an influence that applies

to some or all inventory classes in one entry Demand Forecasts 5.2.2.3 Users should be able to influence demand forecasts using multiplicative factors 5.2.2.4 Users should be able to influence demand forecasts using additive factors 5.2.2.5 Scope of influence 5.2.2.5.1 Board and off point 5.2.2.5.2 Booking class 5.2.2.5.3 Date range 5.2.2.5.4 Day of week 5.2.2.5.5 Departure time range No Show Rate forecasts 5.2.2.6 Users should be able to enter a maximum numerical value for no-show forecasts 5.2.2.7 Users should be able to enter a minimum numerical value for no-show forecasts 5.2.2.8 Users should be able to enter a maximum percentage value for no-show

forecasts 5.2.2.9 Users should be able to enter a minimum percentage value for no-show forecasts 5.2.2.10 Where a numerical and a percentage limit exist for a flight the more restrictive

value should be used 5.2.2.11 Scope of influence 5.2.2.11.1 Board and off point 5.2.2.11.2 Booking class 5.2.2.11.3 Date range 5.2.2.11.4 Day of week 5.2.2.11.5 Departure time range Go Show Rate forecasts 5.2.2.12 Users should be able to enter a maximum numerical value for go-show forecasts 5.2.2.13 Users should be able to enter a minimum numerical value for go-show forecasts 5.2.2.14 Users should be able to enter a maximum percentage value for go-show

forecasts 5.2.2.15 Users should be able to enter a minimum percentage value for go-show forecasts 5.2.2.16 Where a numerical and a percentage limit exist for a flight the more restrictive

value should be used 5.2.2.17 Scope of influence 5.2.2.17.1 Board and off point 5.2.2.17.2 Booking class 5.2.2.17.3 Date range 5.2.2.17.4 Day of week 5.2.2.17.5 Departure time range


10/9/2013 20

Special Events 5.2.2.18 It should be possible to enter dates as special events 5.2.2.19 Users should be able to enter any date as the equivalent previous special event 5.2.2.20 Users should be able to enter special events after the event has occurred to

ensure that the data is not used for forecasting. This may happen where weather disrupts flight schedules.

5.2.2.21 Special event adjustments should be calculated at segment and class level 5.2.2.22 Special events should not be used in forecasts 5.2.2.23 The system should be able to deal with moveable special events, e.g., Easter 5.2.2.24 It should be possible to enter special events by system, route group and route 5.2.2.25 It should be possible to group special events that will have similar characteristics. Define Flight History 5.2.2.26 New flights should be detected immediately by the system 5.2.2.27 Users should be alerted that there are new flights without history for forecasting 5.2.2.28 It should be possible to point any board point, off point, day of week, and

departure time range (target) to another board point, off point, day of week, and departure time range (source) to find history from which to forecast

5.2.2.29 There should be a toggle switch relating to defining a flight‟s history. One setting should tell the system to use the source history defined in 5.2.2.30 regardless of whether or not enough history exists for a target flight. The other setting should tell the system to use the target flight‟s own history if enough of that history exists to generate a forecast

Audit trail 5.2.2.30 There should be an audit trail which shows all of the influences that apply to a

particular selection including all changes to inventory and by which user 5.2.2.31 This selection should be searchable by 5.2.2.31.1 Board and off point 5.2.2.31.2 Departure time range 5.2.2.31.3 Date range 5.2.2.31.4 Day of week 5.2.2.31.5 Days left range (where applicable) 5.2.2.31.6 Cabin/class/aircraft level 5.2.2.31.7 Cabins or classes depending on the level chosen 5.2.2.32 All tables should be searchable by the fields described in 5.2.2.32 where they

apply to the table. Error Checking and Messaging 5.2.2.33 The system should check entries to the forecasting influences to ensure that no

rules relating to the relevant table are broken. 5.2.2.34 All error messages should adequately describe the cause for error and action

required. 5.2.2.35 It should be possible to tailor the standard error messages to meet Biman'

requirements. 5.2.2.36 The system should provide the ability to reverse invalid and erroneous entries.

5.3 Optimization System

The business objective of the optimization system is to have a robust routine that will provide near optimal inventory recommendations from the forecasts it receives. This should be available for single and multi-leg flights and be able to handle aircraft with fixed and moveable cabins and Variable Geometric Seating. Users should also be able to impose rules, e.g., limits on upgrades, which will influence the optimization results. Optimization system should provide

4 different models

EMSR

EMSRa

EMSRb

Price Elasticity


10/9/2013 21

5.3.1 OPTIMISATION METHODOLOGY 5.3.1.1 The optimizer should be based on EMSR using serial availability 5.3.1.2 The optimizer should be able to handle the following 5.3.1.2.1 At least 26 inventory classes 5.3.1.2.2 Aircraft with fixed or moveable curtains and/or Variable Geometric Seating

through an Equipment Seat Map, i.e., to recommend a curtain position. 5.3.1.2.3 The optimizer should recommend equipment changes from a user defined set of

interchangeable equipment types. 5.3.1.2.4 Users should be able to specify only one aircraft type in this set, i.e., to disallow

recommending equipment changes. 5.3.1.2.5 Flights with hard block codeshares 5.3.1.2.6 Changes in nesting structure in the inventory system Supported Nesting Structures

Discrete Parallel Serial with protection concept Serial with bottom-up sales Sub-nests Hybrid nesting

5.3.1.2.7 Changes in inventory controls e.g., leg control to segment control 5.3.1.3 The optimizer should recommend Segment Closed Indicators (SCI) for classes.

This is a 1/0 variable that closes a class for sale regardless of the amount of seats available in the class.

5.3.1.4 The system should recommend a SCI where a higher valued class lower in the hierarchy has excess demand.

5.3.1.5 5.3.1.6 It should be possible to turn off the requirement in 5.3.1.5. 5.3.1.7 The optimizer should have a probabilistic, cost based overbooking model 5.3.1.8 The optimizer should plan for upgrades where such opportunity exists 5.3.1.9 The optimizer should plan for downgrades where such opportunity exists 5.3.1.10 The optimizer should plan for cancellations of individual demand 5.3.1.11 Users should be able to specify curtain position where empty seats are

forecasted, e.g., if the system is forecasting 50 empty seats on a flight, the user should be able to specify how many go into each cabin.

5.3.1.12 Flights should not be optimized until there is sufficient data to produce a forecast 5.3.1.13 The optimizer should be able to perform segment optimization 5.3.1.14 For multi-leg flights it should be possible to have the same recommended

overbooking profile for a cabin in each leg 5.3.1.15 It should be possible to enter non-linear costs for denied boarding by DB

occurrence. 5.3.1.16 Flights should be optimized when they are re-forecasted. 5.3.1.17 The system should calculate the revenue opportunity associated with each flight

that is optimized. This will be the extra revenue that will be gained by accepting the recommendations of the optimization

5.3.1.18 The system should calculate the revenue priority associated with each flight that is optimized. This will be the extra revenue that will be lost if the recommendations of the optimization are not accepted

5.3.1.19 When the optimizer looks for a fare value for a class, it should look at the forecasted average fare per class

5.3.1.20 If there is a user overridden fare for a class that applies to this date, the system should use this fare instead of the batch loaded fare

5.3.2 OPTIMISATION INFLUENCES Users should be able to influence the optimization process by adding the following influences. Upgrades 5.3.2.1 Upgrades allowed/not allowed toggle 5.3.2.2 Maximum number of upgrades as an absolute number 5.3.2.3 Maximum number of upgrades as a percentage of upper cabin 5.3.2.4 Scope of influence 5.3.2.4.1 Board and off point


10/9/2013 22

5.3.2.4.2 Booking class 5.3.2.4.3 Date range 5.3.2.4.4 Departure time range Downgrades 5.3.2.5 Downgrades allowed/not allowed toggle 5.3.2.6 Maximum number of Downgrades as an absolute number 5.3.2.7 Scope of influence 5.3.2.7.1 Board and off point 5.3.2.7.2 Booking class 5.3.2.7.3 Date range 5.3.2.7.4 Departure time range 5.3.2.8 Denied boarding allowed/not allowed toggle Denied Boarding 5.3.2.9 Maximum number of voluntary denied boarding per cabin. 5.3.2.10 Maximum number of involuntary denied boarding per cabin 5.3.2.11 Scope of influence 5.3.2.11.1 Board and off point 5.3.2.11.2 Booking class 5.3.2.11.3 Date range 5.3.2.11.4 Departure time range Segment Minimum and Maximum Authorizations 5.3.2.12 Minimum net authorization values by class. This should be a hard constraint

unless the number of seats booked makes it infeasible to fulfill. 5.3.2.13 Maximum net authorization values by class. This should be a hard constraint

unless the number of seats booked makes it infeasible to fulfill. 5.3.2.14 Scope of influence 5.3.2.14.1 Board and off point 5.3.2.14.2 Booking class 5.3.2.14.3 Date range 5.3.2.14.4 Departure time range 5.3.2.14.5 Day of week 5.3.2.14.6 Days left range Flight Exclusion 5.3.2.15 Users should be able to exclude a flight from the optimization process 5.3.2.16 It should be possible to exclude a date range from optimization 5.3.2.17 It should be possible to exclude flights by day of week SCI value 5.3.2.18 It should be possible to force the SCI value of a class to on or off 5.3.2.19 Scope of influence 5.3.2.19.1 Board and off point 5.3.2.19.2 Booking class 5.3.2.19.3 Date range 5.3.2.19.4 Departure time range 5.3.2.19.5 Day of week 5.3.2.19.6 Days left range Maintain Cabin Capacity 5.3.2.20 Users should be able to specify the cabins that must be for sale, i.e., to stop the

system from recommending all economy flights Error Checking and Messaging 5.3.2.21 The system should check entries to the optimization influences to ensure that no

rules relating to the relevant table are broken. 5.3.2.22 All error messages should adequately describe the cause for error and action

required. 5.3.2.23 It should be possible to tailor the standard error messages to meet Biman'

requirements. 5.3.2.24 The system should provide the ability to reverse invalid and erroneous entries. Audit trail 5.3.2.25 There should be an audit trail which shows all of the influences that apply to a

particular selection. 5.3.2.26 This selection should be searchable by


10/9/2013 23

5.3.2.26.1 Board and off point 5.3.2.26.2 Departure time range 5.3.2.26.3 Date range 5.3.2.26.4 Day of week 5.3.2.26.5 Days left range (where applicable) 5.3.2.26.6 Cabin/class/aircraft level 5.3.2.26.7 Cabins or classes depending on the level chosen 5.3.2.27 All tables should be searchable by the fields describes in 5.3.2.25.1 to 5.3.2.25.7

where they apply to the table. 5.3.3 GROUPS EVALUATION 5.3.3.1 There should be a module for evaluating the likely displacement cost caused by

accepting groups 5.3.3.2 Users should be able to enter the size of the group 5.3.3.3 Users should be able to enter the materialization rate of the group 5.3.3.4 Users should be able to enter the inventory class requested by the group 5.3.3.5 This module should use the unconstrained forecast to determine the expected

number of passengers turned away by accepting the group 5.3.3.6 The module should calculate the difference in revenue that would occur if the

group was accepted 5.3.3.7 The Groups Management system should perform economic analysis of group

requests based on weighing the cost of displacing passengers against the expected revenue to be gained from the group.

5.3.3.8 The Groups Management system should use unconstrained forecasts taken from the Revenue management system

5.3.3.8 The system should return the revenue effect (positive or negative) of accepting the group request.

5.3.3.9 Where the revenue effect is negative, the system should search for alternative routings or airports according to user set criteria. 5.3.3.10

5.6 Reporting System

The overall business objective of a reporting system is to have a comprehensive system that can produce reports on all aspects of a flight‟s inventory and reservations information over its entire history. The reporting system should also contain reports that provide Revenue Management performance measurement and contain forecasts from the Revenue management system. These reports are produced for many areas in the airline as well as Revenue Management. There are three broad types of reports General reports. These reports output all of the data in a specified scope. There are

different types of output required as detailed below. Exception reports: These reports output only that data which falls under user

specified exception criteria. Each report is designed with a different function in mind. Performance monitoring: These reports monitor and measure both system usage and

system performance. 5.5.1 OVERALL REPORTING SYSTEM REQUIREMENTS Infinite number of report types

Completely customizable from every variable in database Reports can be automatically generated

Daily, Weekly, Month or any interval Reports can be automatically distributed

Via email Multiple report formats

On screen, Excel, CSV, txt


10/9/2013 24

5.5.1.1 The reporting system database should contain every day of every flight‟s history as downloaded from the inventory system

5.5.1.2 All future flights contained in the reservations/inventory system should be stored 5.5.1.3 At least two years of historical data should be kept in the reporting database. 5.5.1.4 It should be possible to allow remote locations to access a limited set of reports

and variables possibly using a different reporting tool to that used in Revenue Management

5.5.1.6 These limits should be set by Revenue Management 5.5.1.7 A system administrator should be able to give an individual user from a remote

location access to a specific report 5.5.1.8 Users should be able to set up route and flight groups for reporting purposes 5.5.1.9 There should be public and private route groups, the public route groups should

be maintained by the system administrator and the private route groups by the individual users.

5.5.1.10 Users should specify the output of the report through selecting from the following scope fields. Some reports will require more fields. These will be defined in the relevant sections.

5.5.1.11 The scope should contain the flights to report on, the date ranges to search through and the level of detail

Flights to report on 5.5.1.11.1 Flight number 5.5.1.11.2 Flight group 5.5.1.11.3 Route one way 5.5.1.11.4 Route round trip 5.5.1.11.5 Route group 5.5.1.11.6 System 5.5.1.11.7 Leg or segment level Date of reports 5.5.1.11.8 Date range 5.5.1.11.9 Capture date. This will give the flight data as it was on the capture date. 5.5.1.11.10 Day of week to report on, users should be able to select any combination of days

of week 5.5.1.11.11 There should be a switch that specifies all days of week 5.5.1.11.12 Season (Users should be able to specify date ranges as seasons, e.g., Christmas

as 22 December to 7 January. Detail in output 5.5.1.11.13 It should be possible to combine these variables, e.g., to report by cabin level and

class level 5.5.1.11.14 Aircraft variables 5.5.1.11.15 Executive cabin variables 5.5.1.11.16 Economy cabin variables 5.5.1.11.17 Class level variables 5.5.1.11.18 Users should be able to specify a list of the classes to report on 5.5.1.11.19 There should be a switch that specifies all classes 5.5.1.11.20 Total passengers 5.5.1.11.21 Total revenue passengers 5.5.1.11.22 Individual passengers 5.5.1.11.23 Group passengers 5.5.1.11.24 Total non-revenue passengers 5.5.1.11.25 Total staff passengers (denoted by p/ in the PNR) 5.5.1.11.26 Total frequent flier passengers (denoted by t/ in the PNR) 5.5.1.12 Users should be able to sort the output of the reports at the following flight and

date levels. Flight levels 5.5.1.12.1 Flight number 5.5.1.12.2 Flight group 5.5.1.12.3 Route one way 5.5.1.12.4 Route return 5.5.1.12.5 Route group 5.5.1.12.6 System


10/9/2013 25

Date levels 5.5.1.12.7 Date 5.5.1.12.8 Day of week 5.5.1.12.9 Week 5.5.1.12.10 Month 5.5.1.12.11 Year 5.5.1.12.12 Season (Users should be able to define date ranges as seasons, e.g., 5.5.1.13 Users should be able to sort a report at a different level of detail (flight and date)

without having to re-run the report 5.5.1.14 Users should be able to remove variables without having to re-run the report 5.5.1.15 Users should be able to select arithmetic combinations of variables in reports 5.5.1.16 Users should be able to specify the variables in the reports and display the

following 5.5.1.16.1 Totals 5.5.1.16.2 Averages 5.5.1.16.3 Counts 5.5.1.16.4 Sub-totals (totals at each division in the output, e.g., in reporting by route round

trip and sorting by flight number, the sub-totals should give the total for each flight number that comprises the route round trip).

5.5.1.16.5 Sub-Averages 5.5.1.16.6 Sub-counts 5.5.1.17 Users should be able to add in totals, averages, etc. without having to re-run the

report 5.5.1.18 It should be possible to report different variables at different levels of detail (i.e.,

aircraft, cabin, or class) in a report, e.g., to report seats available by class and booking factor by cabin or aircraft.

5.5.1.19 It should be possible to report different variables by passenger type in a report, e.g., individual and group bookings and total revenue no shows.

5.5.1.20 It should be possible to have aircraft, cabin and class overrides for different passenger types, e.g., to report individual bookings by cabin and individuals and groups by aircraft.

5.5.1.21 It should be possible to run reports in a batch process 5.5.1.22 Users should be able to specify their choice of when a report should be run in the

batch 5.5.1.22.1 Once only 5.5.1.22.2 On a day of week 5.5.1.22.3 On a date each month 5.5.1.23 It should be possible to output reports to the computer screen 5.5.1.24 It should be possible to output reports to a printer 5.5.1.25 Users should be able to specify the print setup for individual reports 5.5.1.26 There should be a toggle switch that tells the system to use either the global print

setup or the report print setup 5.5.1.27 It should be possible to output reports to a file

5.5.1.28 It should be possible to enter date ranges in the form x days from current capture date

5.5.1.29 It should be possible to prioritize city pairs to allow users to produce reports in line with company standards on ordering of data.

5.5.1.30 There should be a way of entering Denied Boarding data manually 5.5.1.31 Where manually entered data differs from the data entered at check-in, the

manual data should be used. 5.5.1.32 When actual revenue data is to be reported on, the system should search for the

historic revenue per segment 5.5.1.33 If this is not available, the forecasted revenue per segment should be used 5.5.1.34 It should be possible to enter budget information by route and at the following

levels of detail 5.5.1.34.1 Aircraft 5.5.1.34.2 Cabin 5.5.1.34.3 Class 5.5.1.35 The budget data should comprise 5.5.1.35.1 Budget bookings


10/9/2013 26

5.5.1.35.2 Budget flown 5.5.1.35.3 Budget revenue 5.5.1.35.4 Budget Revenue 5.5.1.35.5 Budget capacity 5.5.1.35.6 Budget load factor

GENERAL REPORTS 5.5.2 LEG/SEGMENT REVIEW REPORT 5.5.2.1 The leg/segment review report should report on historical and future flight

departures by segment or leg according to the scope defined in section 5.5.1. 5.5.2.2 It should be possible to produce reports at all levels of detail from date to year

and from flight number to system 5.5.2.3 For multi-leg flights, it should be possible to set the scope of a report template to

report on one leg/segment of the flight. 5.5.3 BOOKING HISTORY REPORT 5.5.3.1 The booking history report should allow users to view data at any set of Days Left

(days prior to departure). 5.5.3.2 Users should be able to specify any set of days left in the scope of a booking

history report 5.5.3.3 Users should be able to specify the days left as a comma separated list, e.g.,

5,4,3,2,1,0 5.5.3.4 Users should be able to specify the days left as a range, e.g., 5 - 0 5.5.3.5 Users should be able to sort reports by days left 5.5.3.6 The booking history report should contain pickup in its output, i.e., the difference

between the value of the variable at the first and the last specified days left. 5.5.3.7 It should be possible to run it at a leg or segment level similarly to a Leg/Seg

Review. 5.5.3.8 All variables (pre and post departure) should be available to a bookings history

review 5.5.4 COMPARISON REPORT 5.5.4.1 The Comparison report should provide a means of comparing information in two

different sets of data 5.5.4.2 Users should enter the scope of the base report and the scope with which it will

be compared 5.5.4.3 When entering the scope with which to compare, there should be a button that

will copy the scope of the base report which users can then edit. 5.5.4.4 The scopes that can be compared should contain 5.5.4.4.1 The same flight level scope as in the base report 5.5.4.4.2 Departure date 5.5.4.4.3 Capture date 5.5.4.4.4 Day of week 5.5.4.4.5 Aircraft 5.5.4.4.6 Cabin 5.5.4.4.7 Class 5.5.4.5 It should be possible to enter class level details into the scope for comparison,

e.g., to compare Y, B, and H classes for Jan 2012 with M, L and K classes for Jan 2013, it should be possible to enter YBH in the scope of the report and MLK in the scope for the comparison.

5.5.4.6 It should be possible to compare two flights, routes, route groups, etc. for the same date range

5.5.4.7 It should be possible to compare a single flight, route, route group, etc. for one date range against another data range.

5.5.4.8 Absolute and percentage variations should be displayed in the report 5.5.4.9 The report should be leg or segment based and be useable for future or historic

flights. 5.5.4.10 It should be possible to compare two day of week reviews with the output being

the day of week in columns and the route data in rows. The columns for each


10/9/2013 27

variable and day of week should contain the base scope data, the comparison scope data, and the absolute and percentage difference between them

5.5.4.11 It should be possible to compare two booking history reports 5.5.4.12 It should be possible to set the scope of a comparison report to give bookings for

a particular date range this year as of the current capture date with bookings for the equivalent date range last year as of the equivalent capture date last year such that this report can be run regularly without having to change the scope.

5.5.4.13 Where there is no data relating to a route/flight in a comparison report, the output should default to zero. This will ensure that when several routes or flights are entered in a report that the correct comparisons will be made.

5.5.4.14 The default output should contain the base scope, the comparison scope and the absolute and percentage difference in four rows for each route or flight

5.5.4.15 It should be possible to put the comparison in columns, i.e., the columns for each variable should contain the base scope data, the comparison scope data, and the absolute and percentage difference between them

5.5.4.16 Comparisons across variables should be possible, e.g., it should be possible to compare overbooking percentage this year with net no-show rates last year.

5.5.5 DAY OF WEEK REVIEW 5.5.5.1 The day of week review should provide averages or totals for variables by day of

week. 5.5.5.2 The output should be in a matrix format with the day of week and variables in the

columns and the flights/routes/dates in the rows 5.5.5.3 Users should be able to report by week, month or year 5.5.5.4 It should be possible to include several variables in a day of week review. 5.5.5.5 The report can be leg or segment based and can be used for advance or historic

flights.

EXCEPTION REPORTS 5.5.6 DISCOUNT CONTROL 5.5.6.1 The discount control report should output flights based on a set of exception

criteria related to seat availability. 5.5.6.2 Users set the scope as for a leg/segment review as well as specifying the days

left to search through 5.5.6.3 The output of the report should be in the same format as a leg/segment review

sorted by flight number and date 5.5.6.4 Users specify the variables to view for the flights that fall into the exception

criteria from the pre-departure leg and segment variables available 5.5.6.5 Exception criteria should be user specified and should be possible to set them for

up to twelve Days Left ranges. 5.5.6.6 The exception criteria should be 5.5.6.6.1 Aircraft booking factor percentage 5.5.6.6.2 Class seats available 5.5.6.7 Users should be able to toggle between greater than and less than for the

exception criteria 5.5.6.8 The exception criteria should be combinable using AND or OR operators. 5.5.6.9 Users should be able to build up criteria and be able to have criteria across any

amount of classes on a flight 5.5.6.10 Subtotals for variables should be possible 5.5.6.11 The output should include an indicator saying if the criterion broken is at aircraft,

cabin or class level 5.5.6.12 The output should include an indicator saying what part of a row breached a

criterion, e.g., if a criterion is YBHK seats available < 0 and K class seats available is 0 then K class should be highlighted in this row of the report.

5.5.7 WAITLIST MONITOR 5.5.7.1 The waitlist monitor should identify future flights that have waitlists according to

exception criteria related to waitlists. 5.5.7.2 Users set the scope as for a leg/segment review as well as specifying the days

left to search through


10/9/2013 28

5.5.7.3 The output of the report should be in the same format as a leg/segment review sorted by flight number and date

5.5.7.4 Users specify the variables to view for the flights that fall into the exception criteria

5.5.7.5 Exception criteria should be user specified 5.5.7.6 The exception criteria should be 5.5.7.6.1 Aircraft waitlisted passengers 5.5.7.6.2 Cabin waitlisted passengers 5.5.7.6.3 Class waitlisted passengers 5.5.7.6.4 Aircraft, cabin, or class seats available 5.5.7.6.5 Cabin seats available 5.5.7.6.6 Class seats available 5.5.7.7 Users should be able to toggle between greater than and less than for the

exception criteria 5.5.7.8 The exception criteria should be combinable using AND or OR operators. 5.5.7.9 The output should include an indicator saying if the criterion broken is at aircraft,



5.5.8 NON-REVENUE MONITOR 5.5.8.1 The non-revenue monitor should identify future flights with exception criteria

related to non-revenue passengers. 5.5.8.2 Users set the scope as for a leg/segment review as well as specifying the days

left to search through 5.5.8.3 The output of the report should be in the same format as a leg/segment review

sorted by flight number and date 5.5.8.4 The non-revenue monitor should distinguish between Frequent Flier bookings

denoted by t/ in the PNR and Staff positive bookings denoted by p/ in the PNR. 5.5.8.5 Exception criteria are user specified 5.5.8.6 The exception criteria should be 5.5.8.6.1 Aircraft booking factor percentage 5.5.8.6.2 Cabin booking factor percentage 5.5.8.6.3 Projected aircraft booking factor percentage 5.5.8.6.4 Projected cabin booking factor percentage 5.5.8.6.5 Aircraft non-revenue bookings 5.5.8.6.6 Cabin non-revenue bookings 5.5.8.6.7 Aircraft seats available 5.5.8.6.8 Cabin seats available 5.5.8.6.9 Class seats available 5.5.8.6.10 Flight fact not present 5.5.8.7 Users should be able to toggle between greater than and less than for the

exception criteria 5.5.8.8 The exception criteria should be combinable using AND or OR operators. 5.5.8.9 The output should include an indicator saying if the criterion broken is at aircraft,



5.5.9 CANCEL MONITOR 5.5.9.1 The cancel monitor should identify flights which were cancelled prior to or on the

day of departure 5.5.9.2 Users specify 5.5.9.2.1 The flights to search through 5.5.9.2.2 The date range 5.5.9.2.3 The days of week 5.5.9.3 The variables for the cancel monitor should be 5.5.9.3.1 Equipment Type


10/9/2013 29

5.5.9.3.2 Date cancelled 5.5.9.3.3 Days left cancelled 5.5.9.3.4 Cancelled reason as captured from departure control 5.5.14 OVERBOOKING PROFILE MONITOR 5.5.14.1 The overbooking profile monitor should identify future flights with current

overbooking profiles at a certain level and group content or individual class booked at another level

PERFORMANCE MONITORING REPORTS 5.5.15 REVENUE OPPORTUNITY 5.5.15.1 The revenue opportunity report should report on revenue opportunities captured

and to be captured by Revenue Management 5.5.15.2 This should be based on a revenue opportunity model that uses unconstrained

demand 5.5.15.3 This should calculate the optimal revenue, the no control revenue and the actual

revenue from each flight. 5.5.15.4 Users set the scope as for a leg/segment review 5.5.15.5 Users should be able to report by 5.5.15.5.1 Flight number 5.5.15.5.2 Flight group 5.5.15.5.3 Route one way 5.5.15.5.4 Route round trip 5.5.15.5.5 Route group 5.5.15.5.6 System 5.5.15.5.7 Week 5.5.15.5.8 Month 5.5.15.5.9 Year 5.5.15.6 The variables should be 5.5.15.6.1 Booked 5.5.15.6.2 Unconstrained booked 5.5.15.6.3 Flown 5.5.15.6.4 Unconstrained flown 5.5.15.6.5 Optimal booked 5.5.15.6.6 No control booked 5.5.15.6.7 Optimal Revenue 5.5.15.6.8 Actual revenue 5.5.15.6.9 No Control revenue 5.5.15.6.10 Revenue captured 5.5.15.6.11 Revenue Opportunity 5.5.15.7 The revenue Opportunity should be specifiable by 5.5.15.7.1 Overbooking opportunity 5.5.15.7.2 Fare mix opportunity 5.5.15.7.3 Upgrade opportunity 5.5.16 OVERBOOKING CONTRIBUTION 5.5.16.1 The Overbooking Contribution report should calculate the revenue gained

through overbooking 5.5.16.2 This should be calculated by estimating the number of extra seats that are sold

through overbooking and estimating the revenue benefit that accrues from these extra seats.

5.5.16.3 It should be possible to report this at route level 5.5.17 SPOILAGE 5.5.17.1 The Spoilage report should identify flights which have incurred spoilage. 5.5.17.2 It should be possible to report this at route level 5.5.17.3 Exception criteria are user specified 5.5.17.4 Percentage spoilage rate 5.5.17.5 Number of flights with spoilage greater than a particular rate


10/9/2013 30

5.5.18 OPTIMISATION REPORT 5.5.18.1 The optimization report should provide statistics on the use of the Optimization

module 5.5.18.2 There should be at least six months historic data for this report 5.5.18.3 Users should be able to specify the scope by 5.5.18.3.1 Flight 5.5.18.3.2 Analyst 5.5.18.3.3 System 5.5.18.4 Users should be able to detail by 5.5.18.4.1 Flight 5.5.18.4.2 Analyst 5.5.18.4.3 System 5.5.18.4.4 Date 5.5.18.4.5 Day of week 5.5.18.4.6 Week 5.5.18.4.7 Month 5.5.18.4.8 Year 5.5.18.5 The variables should be 5.5.18.5.1 Flights optimized 5.5.18.5.2 Fixed days left flights optimized 5.5.18.5.3 Triggered days left flights optimized 5.5.18.5.4 Revenue Opportunity optimized 5.5.18.5.5 Revenue Priority optimized by Autopilot 5.5.18.5.6 Revenue Opportunity optimized by Autopilot 5.5.18.5.7 Revenue Priority optimized but not updated by Autopilot 5.5.18.5.8 Revenue Opportunity optimized but not updated by Autopilot 5.5.18.5.9 Revenue Priority optimized 5.5.18.5.10 Ad-Hoc flights 5.5.18.5.11 Flights reviewed 5.5.18.5.12 Percentage flights reviewed 5.5.18.5.13 Revenue Opportunity reviewed 5.5.18.5.14 Revenue Priority reviewed 5.5.18.5.15 Percentage Revenue Opportunity reviewed 5.5.18.5.16 Percentage Revenue Priority reviewed 5.5.18.5.17 Flights updated by Autopilot 5.5.18.5.18 Percentage flights updated by Autopilot 5.5.18.5.19 Revenue Opportunity updated by Autopilot 5.5.18.5.20 Revenue Priority updated by Autopilot 5.5.18.5.21 Percentage Revenue Opportunity updated by Autopilot 5.5.18.5.22 Percentage Revenue Priority updated by Autopilot 5.5.18.5.23 Flights updated manually 5.5.18.5.24 Percentage flights updated manually 5.5.18.5.25 Revenue Opportunity updated manually 5.5.18.5.26 Revenue Priority updated manually 5.5.18.5.27 Percentage Revenue Opportunity updated manually 5.5.18.5.28 Percentage Revenue Priority updated manually 5.5.18.5.29 Flights updated in total 5.5.18.5.30 Percentage flights updated manually in total 5.5.18.5.31 Revenue Opportunity updated manually in total 5.5.18.5.32 Revenue Priority updated manually in total 5.5.18.5.33 Percentage Revenue Opportunity updated manually in total 5.5.18.5.34 Percentage Revenue Priority updated manually in total 5.5.19 FORECAST MONITORING REPORT 5.5.19.1 The forecast monitoring report should allow the reporting of both system

forecasts and forecasts after user influences have been applied. 5.5.19.2 The report should allow forecasted values to be compared with actual values. 5.5.19.3 Forecasts should be stored at user defined capture dates 5.5.19.4 It should be possible to store each new forecast for a flight 5.5.19.5 Users set the scope as for a leg/segment review


10/9/2013 31

5.5.19.6 Users should be able to report by 5.5.19.6.1 Flight number 5.5.19.6.2 Flight group 5.5.19.6.3 Route one way 5.5.19.6.4 Route round trip 5.5.19.6.5 Route group 5.5.19.6.6 System 5.5.19.6.7 Week 5.5.19.6.8 Month 5.5.19.6.9 Year 5.5.19.7 The variables should include 5.5.19.7.1 Forecast booked 5.5.19.7.2 Forecast flown 5.5.19.7.3 Forecast no shows 5.5.19.7.4 Forecast go shows 5.5.19.7.5 Forecast cancellations 5.5.19.7.6 Booked 5.5.19.7.7 Flown 5.5.19.7.8 No shows 5.5.19.7.9 Go shows 5.5.19.7.10 Cancellations 5.5.19.8 These variables should be available for total revenue passengers 5.5.19.9 These variables should be available at individual level where applicable 5.5.19.10 These variables should be available at group level where applicable 5.5.19.11 The following forecasts should be available for these 5.5.19.11.1 System unconstrained forecast 5.5.19.11.2 System constrained forecast 5.5.19.11.3 User influenced forecast 5.5.19.12 The system should calculate

5.5.19.12.1 Mean deviation 5.5.19.12.2 Mean absolute deviation 5.5.19.12.3 Mean squared deviation

5.5.20 PNR LEVEL REPORTS The following report types should use PNR level information 5.5.20.1 Bookings by region (IATA number) 5.5.20.2 Flight connections, on-line and off-line 5.5.20.3 Booked versus ticketed passengers 5.5.20.4 Frequent flier activity 5.5.20.5 Cancellations by region, time after booking 5.5.20.6 Groups tracking 5.5.20.7 PNR activity, i.e. changes to PNRs. 5.5.21 VARIABLE FIELDS REQUIRED Leg Level Variables The following are the variables that are required for a report that is run at leg level. Users should be able to select any number of these variables for a report. 5.5.21.1 Actual Time of Departure

5.5.21.2 Capacity

5.5.21.3 Flown Capacity

5.5.21.4 Authorization

5.5.21.5 Net Authorization

5.5.21.6 Booked

5.5.21.7 Unconstrained Booked


10/9/2013 32

5.5.21.8 1st Segment SCI Status

5.5.21.9 Group Names Booked

5.5.21.10 Group PNRs Booked

5.5.21.11 Group Names To Be Advised

5.5.21.12 Group Name %

5.5.21.13 Waitlist

5.5.21.14 Flight Fact On

5.5.21.15 Flown

5.5.21.16 Unconstrained Flown (Unconstrained booked paying attention to capacity)

5.5.21.17 Seats Available

5.5.21.18 Net Seats Available

5.5.21.19 True Seats Available

5.5.21.20 Empty Seats

5.5.21.21 Booked Revenue 1st Segment

5.5.21.22 Flown Revenue 1st Segment

5.5.21.23 No-Shows

5.5.21.24 No-Show %

5.5.21.25 Net No-Shows

5.5.21.26 Net No-Show %

5.5.21.27 Earlier Flight No-Shows

5.5.21.28 Later Flight No-Shows

5.5.21.29 Go-Shows

5.5.21.30 Ticketed Later Go-Shows

5.5.21.31 Ticketed Earlier Go-Shows

5.5.21.32 Spoiled Seats

5.5.21.33 Spoiled Seat Cost

5.5.21.34 Average Spoiled Seats/Flight

5.5.21.35 Spoilage %

5.5.21.36 Average Spoiled Seats % per Flight

5.5.21.37 Denied Boarding

5.5.21.38 Voluntary Denied Boarding

5.5.21.39 Involuntary Denied Boarding

5.5.21.40 Denied Boarding Cost

5.5.21.41 Involuntary Denied Boarding Cost

5.5.21.42 Upgrades

5.5.21.43 Downgrades

5.5.21.44 Equipment Type

5.5.21.45 Flown Equipment Type

5.5.21.46 Overbooking %

5.5.21.47 Load Factor %

5.5.21.48 Booking Factor %

5.5.21.49 Budget Flown 1st Seg

5.5.21.50 Budget Flown Revenue 1st Segment

5.5.21.51 Budget Load Factor %


10/9/2013 33

5.5.21.52 Budget Capacity

5.5.21.53 Booked Average Fare 1st Segment

5.5.21.54 Flown Average Fare 1st Segment

5.5.21.55 Booked Revenue per ASK

5.5.21.56 Flown Revenue per ASK

5.5.21.57 No. Of Flight Legs

5.5.21.58 Average Capacity per Leg

5.5.21.59 Average Flown Cap per Leg

5.5.21.60 Average Flown per Leg

5.5.21.61 Average Booked per Leg

5.5.21.62 Average Booked Revenue per Leg

5.5.21.63 Average Flown Rev / 1st Seg

5.5.21.64 Average Authorization / Leg

5.5.21.65 Leg Number

5.5.21.66 Involuntary Denied Boarding Cash Paid

5.5.21.67 Voluntary Denied Boarding Cash Paid

5.5.21.68 Involuntary Denied Boarding OAL Costs

5.5.21.69 Voluntary Denied Boarding OAL Costs

5.5.21.70 Involuntary Denied Boarding Coupon Value

5.5.21.71 Voluntary Denied Boarding Coupon Value

5.5.21.72 Involuntary Denied Boarding Ground Cost

5.5.21.73 Voluntary Denied Boarding Ground Cost

5.5.21.74 Involuntary Denied Boarding Hotel Cost


5.5.21.76 Voluntary Denied Boarding Meal Cost

5.5.21.77 Involuntary Denied Boarding Misc. Cost

5.5.21.78 Voluntary Denied Boarding Misc. Cost

5.5.21.79 No. Of Broken Seats

5.5.21.80 No Splits

5.5.21.81 Projected Booked

5.5.21.82 Projected Flown

5.5.21.83 Projected cancellations

5.5.21.84 Projected Booked Revenue 1st Segment

5.5.21.85 Projected Flown Revenue 1st Segment

5.5.21.86 Projected Load Factor %

5.5.21.87 Projected Booking Factor %

5.5.21.88 Projected Seats Available

5.5.21.89 Projected Net Seats Available

5.5.21.90 Projected Booked Average Fare 1st Seg

5.5.21.91 Projected Flown Average Fare 1st Seg

5.5.21.92 Projected Net No-Shows

5.5.21.93 Projected Net No-Show %

5.5.21.94 Projected Empty Seats

5.5.21.95 Variation % (The percentage difference between the preceding two variable columns)


10/9/2013 34

Segment Level Variables The following are the variables that are required for a report that is run at segment level. Users should be able to select any number of these variables for a report. 5.5.21.96 Actual Time of Departure

5.5.21.97 Booked

5.5.21.98 Unconstrained Booked

5.5.21.99 Class SCI Status

5.5.21.100 Group Names Booked

5.5.21.101 Group PNRs Booked

5.5.21.102 Group Names To Be Advised

5.5.21.103 Group Name %

5.5.21.104 Waitlist

5.5.21.105 Flight Fact On

5.5.21.106 Flown

5.5.21.107 Unconstrained Flown (Unconstrained booked paying attention to capacity)

5.5.21.108 Seats Available

5.5.21.109 Net Seats Available

5.5.21.110 True Seats Available

5.5.21.111 Booked Revenue

5.5.21.112 Flown Revenue

5.5.21.113 Budget Average Fare

5.5.21.114 Estimated Average Fare

5.5.21.115 Historic Average Fare

5.5.21.116 No-Shows

5.5.21.117 No-Show %

5.5.21.118 Net No-Shows

5.5.21.119 Net No-Show %

5.5.21.120 Earlier Flight No-Shows

5.5.21.121 Later Flight No-Shows

5.5.21.122 Go-Shows

5.5.21.123 Ticketed Later Go-Shows

5.5.21.124 Ticketed Earlier Go-Shows

5.5.21.125 Denied Boarding

5.5.21.126 Voluntary Denied Boarding

5.5.21.127 Involuntary Denied Boarding

5.5.21.128 Denied Boarding Cost

5.5.21.129 Involuntary Denied Boarding Cost

5.5.21.130 Upgrades

5.5.21.131 Downgrades

5.5.21.132 Budget Flown

5.5.21.133 Budget Flown Revenue

5.5.21.134 Budget Average Fare

5.5.21.135 Booked Revenue per RPK


10/9/2013 35

5.5.21.136 Flown Revenue per RPK

5.5.21.137 Average Flown per segment

5.5.21.138 Average Booked per Segment

5.5.21.139 Average Booked Revenue per Segment

5.5.21.140 Average Flown Rev per Segment

5.5.21.141 Involuntary Denied Boarding Cash Paid

5.5.21.142 Voluntary Denied Boarding Cash Paid

5.5.21.143 Involuntary Denied Boarding OAL Costs

5.5.21.144 Voluntary Denied Boarding OAL Costs

5.5.21.145 Involuntary Denied Boarding Coupon Value

5.5.21.146 Voluntary Denied Boarding Coupon Value

5.5.21.147 Involuntary Denied Boarding Ground Cost

5.5.21.148 Voluntary Denied Boarding Ground Cost



5.5.21.151 Voluntary Denied Boarding Meal Cost

5.5.21.152 Involuntary Denied Boarding Misc. Cost

5.5.21.153 Voluntary Denied Boarding Misc. Cost

5.5.21.154 No Segment Traffic

5.5.21.155 Projected Booked

5.5.21.156 Projected Flown

5.5.21.157 Projected cancellations

5.5.21.158 Projected Booked Revenue

5.5.21.159 Projected Flown Revenue

5.5.21.160 Projected Demand

5.5.21.161 Projected Seats Available

5.5.21.162 Projected Net Seats Available

5.5.21.163 Projected Booked Average Fare

5.5.21.164 Projected Flown Average Fare

5.5.21.165 Projected Net No-Shows

5.5.21.166 Projected Net No-Show %

5.5.21.167 Variation % (The percentage difference between the previous two variables)

PNR level variables The following PNR level variables are required for reports that contain PNR level detail. 5.5.21.168 PNR Record Locator

5.5.21.169 Passenger Name

5.5.21.170 Creation Time

5.5.21.171 Creation Date

5.5.21.172 Creation DOW

5.5.21.173 Holiday (lookup from defined table)

5.5.21.174 Special Event (Fare Specials, etc.)

5.5.21.175 Airlines Code(s)

5.5.21.176 Origin Airport


10/9/2013 36

5.5.21.177 Origin City

5.5.21.178 Origin Country

5.5.21.179 Origin Continent

5.5.21.180 Destination Airport

5.5.21.181 Destination City

5.5.21.182 Destination Country

5.5.21.183 Destination Continent

5.5.21.184 Path Airport

5.5.21.185 Path City

5.5.21.186 Departure Date(s) all legs

5.5.21.187 Departure Time(s) all legs

5.5.21.188 Point of Sale City

5.5.21.189 Point of Sale Country

5.5.21.190 Point of Sale Continent

5.5.21.191 Booking Office

5.5.21.192 Group Identifier

5.5.21.193 Passenger Type (Freq Flier Type)

5.5.21.194 Frequent Flier Number

5.5.21.195 Fare Class(es) all legs

5.5.21.196 Number of Passengers

5.5.21.197 Number Protected

5.5.21.198 No Show Identifier

5.5.21.199 No Show Reason

5.5.21.200 Go Show Identifier

5.5.21.201 Go Show Booking Time before Departure

5.5.21.202 Connection from Airline

5.5.21.203 Connection to Airline

5.5.21.204 Original Point of Departure

5.5.21.205 Final Destination

5.5.21.206 Cancellation Identifier

5.5.21.207 Cancellation Time

5.5.21.208 Cancellation Reason

5.5.21.209 Flight Numbers all legs

5.5.21.210 Confirmation Codes all legs

5.5.21.211 Fare (Base, Airport Chg, Tax)

5.5.21.212 Currency (Type/Exchange Rate)

5.5.21.213 Fare Basis Code

5.5.21.214 Special Service

5.5.21.215 Passenger Address

5.5.21.216 OAL Booked by

5.5.21.217 Tour Segment

5.5.21.218 Hotel Segment

5.5.21.219 Car Segment

5.5.21.220 Group Name


10/9/2013 37

5.5.21.221 Number of Passengers in PNR

5.5.21.222 Ticket Type

5.5.21.223 Denied Boarding Code

5.5.21.224 Form of Payment Info

5.5.21.225 Agent IATA #

5.5.21.226 Telephone #

5.5.21.227 Other Supp. Info Messages

5.5.21.228 Protected History (all legs booked)

5.5.21.229 Received From (PNR modifying person)

5.5.21.230 Arrival Time all legs

5.5.22 INTERFACES The following are the interfaces with the Reporting System. Interfaces a) to e) are actual interfaces. Interfaces f) to o) are possible future interfaces.

a) Revenue management system b) Groups Management system c) Inventory system d) Reservations system e) Departure control system f) Budgetary system g) Pricing – ATPCo data h) Sales i) Distribution j) Resource Management k) Fleet Allocation l) Schedules Planning m) Integrated Planning System n) Cargo o) CRM

Indicate how it is proposed to handle these interfaces in terms of 5.5.22.1 Processes 5.5.22.2 Delivery Mechanism 5.5.22.3 Software 5.5.22.4 Content

6. Communications 6.5.1 Describe the telecommunications infrastructure. 6.5.2 State all of the communications protocols that the proposed solution supports? 6.5.2.1 Does it support generic digital communications links, e.g. ISDN?

6.5.2.2 Does it support TCP/IP? 6.5.2.3 Does it support MQ Series?

6.5.2.4 What business function services do you provide access to via IBM MQ Series? 6.5.2.5 Provide a specification of your MQ interface. 6.5.3 Describe the communications protocols required for remote access (i.e. for access

from Biman locations other than the HQ in Dhaka). 6.5.4 How are web enabled communications supported?


10/9/2013 38

6.5.4.1 If not currently supported, is there a plan to make them available shortly? 6.5.5 State any message formats that the proposed solution supports? 6.5.6 As part of the proposed system we may require that the solution link to external

companies (i.e., GDSs). Please specify how the technical links will be supported by the proposed solution. Provide details of any API‟s involved in the proposed solution. Advise what they are used for and where they are currently in use.

6.5.7 As part of the proposed system we require that the solution links to the corporate

applications listed below. For each of the following, specify how the technical links will be supported by the proposed solution? Provide details of any API‟s involved in the proposed solution. Advise what they are used for and where they are currently in use.

6.5.7.1 Airline Reservations System (SITA)

6.5.7.2 Airline Inventory System (SITA)

6.5.7.3 Airline Departure Control System (SITA DCS)

6.5.7.4 Revenue Accounting System (Mercator)

6.5.7.5 As part of the proposed system we would plan to introduce additional links to the

corporate applications listed below at a future date. For each of the following, specify how the technical links would be supported by the proposed solution. Provide details of any API‟s involved in the proposed solution. Advise what they are used for and where they are currently in use.

6.5.8.1 Integrated Planning System

6.5.8.2 Advanced Booking Information System 6.5.8.3 Resource Management System 6.5.8.4 FF program.

6.6 E-Business

6.6.1 What business documents do you produce in XML versions? 6.6.2 To what XML standards specifications do you provide document definitions? 6.6.3 What business-to-business messaging environments do you fully support? 6.6.4 What e-mail standards do you fully support for automatic generation/receipt of e-

mails? 6.6.5 What directory standards do you fully support? 6.6.6 What encryption standards do you fully support? 6.6.7 What web-server platforms do you fully support?


10/9/2013 39

6.7 Implementation and Maintenance

6.7.1 Indicate the estimated amount of effort required to customize the proposed solution

for Biman. 6.7.2 Indicate the level of Biman resources both business and technical required for

application and system implementation 6.7.3 Indicate the level of Biman resources, both business and technical, required for

ongoing application and system support. 6.7.4 Indicate what tools are provided or required to assist in ongoing maintenance and

system management. 6.7.5 Provide a schedule outlining the implementation timescale for the proposed solution. 6.7.6 Indicate the testing procedures and test tools that will be available to verify that the

data take-on (Sales data, Flown data, Revenue data, Budget data) and data transmission (Inventory updates) have been carried out successfully?

6.7.7 Confirm if a written warranty confirming the “fit for purpose” of all components of the

system will be provided prior to delivery of the proposed solution. 6.7.8 Indicate whether documentary evidence such as test scripts, error logs and

performance statistics can be supplied if requested to verify the above warranty? 6.7.9 Indicate the level of Help Desk facilities available during implementation, bedding

down of the system, and afterwards if required? 6.7.10 Detail any remote (i.e. dial-in etc.) support. 6.7.11 Specify the maintenance proposals required to support implementation of the

solution. 6.7.12 Indicate how resilience and self-recovery are addressed in the proposal. 6.7.13 Indicate how full continuity of service can be maintained in the event of a disaster

occurring at the Biman production Site. Provide details of alternate configurations that will allow for continuity of service within 4 hours, including requirements at our remote site.

6.7.14 State your policy with regard to maintenance and support of your solution throughout

its life, following acceptance by Biman and subsequent version releases of the product.

6.7.15 Provide full information about the level of service provided by your standard

maintenance agreement 6.7.15.1 Include a copy of the standard maintenance contract

6.7.15.2 Do you have a separate service level agreement (or is it part of your maintenance

agreement)?

6.7.15.3 If it is separate please supply a copy of SLA.

6.7.15.4 Include in detail all response times and fix times for faults Does it cover response times, call out and upgrades?


10/9/2013 40

6.7.15.5 Indicate how you will commit to the response time within which you will respond to faults detected or requests for support by Biman?

6.7.15.6 Do you operate a system of extended or out of hours support?

6.7.15.7 Are there any restrictions on your maintenance and support agreement relating to the location and environment of the system hardware?

6.7.16 If the proposed solution is package based, indicate the length of time for which a

release of the package is supported following the release of a new version. 6.7.17 If new versions of your system are released, under what conditions will Biman be

required to adopt the latest version and what is your upgrade policy for new releases? 6.7.18 How long will you continue maintenance and update of the current system? 6.7.19 Will you enter an escrow agreement whereby Biman receives a copy of the entire

necessary program source in case of failure of the Vendor? 6.7.20 Describe your implementation strategy. 6.7.21 Indicate if you have undertaken implementation of your package solution in

conjunction with a system integrator partner. 6.7.21.1 If so, indicate who your system integrator partners have been.

6.7.21.2 Indicate what implementations this partnership has been involved in.

6.7.21.3 Describe your implementation strategy when working with this partner.

6.8 Documentation and Training 6.8.1 Describe the standard documentation provided with the system. 6.8.2 Indicate the media on which documentation is provided. 6.8.3 Indicate whether the following are supplied – 6.8.3.1 Functional Specification including screen and report definitions, error messages and

actions, field definitions and validation, algorithms used, and a definition of all major processing activities.

6.8.3.2 Operations Guide containing all information required to support the operation of the system.

6.8.3.3 User Manuals appropriate to each level of user. 6.8.3.4 Is user online help included in the system, and if so it context sensitive?

6.8.3.5 A Data Dictionary reflecting the data structures and file design.

6.8.3.6 A Technical Specification of the software for the system. 6.8.4 Indicate any other relevant documentation that may be made available. 6.8.5 Specify the training courses that will be provided for both business users and

technical staff as part of your proposal. 6.8.6 Does the available training cover the following requirements?


10/9/2013 41

6.8.6.1 Routine use of the system

6.8.6.2 Routine running of the software.

6.8.6.3 The more advanced and complex features of the system.

6.8.6.4 Interfacing software to other Biman systems.

6.8.6.5 System administration procedures. 6.8.7 Indicate how knowledge transfer to Biman technical resources will be accomplished. 6.8.8 Indicate any known constraints in relation to the provision of training. e.g. dates,

numbers of attendees, etc. 6.8.9 Upon issue of a new release of the software, describe how your documentation is

updated and released to your clients? Indicate the time lag between the issue of a new release and issue of the updated documentation?

6.9 Quality Management

6.9.1 Confirm whether your company‟s software development process has been accredited

by any international standards certification organization (e.g. ISO 9001 or equivalent).

6.10 Security

The proposed solution should conform to the Biman IT security policy and standards which include the following: 6.10.1 Computer and Network Management 6.10.1.1 Operational procedures and responsibilities to ensure the correct and secure

operation of computer and network facilities.

6.10.1.2 System planning and acceptance to minimize the risk of systems failures.

6.10.1.3 Protection from malicious software to safeguard the integrity of software and data.

6.10.1.4 Housekeeping to maintain the integrity and availability of IT services.

6.10.1.5 Network management to ensure the safeguarding of information in networks and the protection of the supporting infrastructure.

6.10.1.6 Data and software exchange to prevent loss, modification or misuse of data. 6.10.2 System Access Control

6.10.2.1 Business requirement for system access

6.10.2.2 Access to the system should be controllable on the basis of business requirements.

6.10.2.3 User access management

6.10.2.4 Formal procedures to control allocation of access rights to IT services.


10/9/2013 42

6.10.2.5 Application access control to prevent unauthorized access to information held in computer systems.

6.10.2.6 Logical access controls must be available to control access to application systems and data.

6.10.2.7 Monitoring system access and use to detect unauthorized activities.

6.10.2.8 Systems must have an audit trail to ensure conformity to access and standards. 6.10.3 Systems Development and Maintenance 6.10.3.1 Security in application systems to prevent loss, modification or misuse of user data in

application systems. Appropriate security controls, including audit trails, must be designed into application systems.

6.10.3.2 Security of application system files. Apply appropriate controls to minimize the risk of corruption of operational systems.

6.10.3.3 Security in development and support environments, ability to control security in development, Quality assurance and live environments separately

7 Operational Requirements

8.1 Configuration

8.1.1 Specify all hardware components required for the proposed solution. 8.1.2 Is your application server architecture an in-house design or based on third party

Vendor frameworks? 8.1.3 If third party, what product? 8.1.4 If in-house, provide specifications of architecture (TP Monitor, etc.)

8.1.5 Describe the operating system required for the proposed solution and any other

supporting tools that may be required.

8.1.6 Describe whether the proposed configuration includes a development, quality assurance and live platform. If so, can any of these co-exist on the same server (e.g., development and quality assurance)?

8.1.7 Describe any constraints in the ability to increase the capacity of the system.

8.1.8 Describe any interfaces available to standard enterprise management tools? 7.1.9 Describe the methods used for distribution of reports

7.2 Performance

The proposed system will be required to be available 11 hours per day for agent interface (0700 to 1800 Local Time) and for 15 hours per day for reporting (from 0700–2200 Local Time).

7.2.1 What facilities exist to monitor performance of the system?


10/9/2013 43

7.2.2 Specify benchmarking process you would use to demonstrate performance criteria.

7.2.3 Specify the conditions under which performance of the system is guaranteed.

7.2.4 What is the average number of transactions processed per second? 7.2.5 What is the maximum number of transactions processed per second at peak times?

7.2.6 Confirm that any batch processes (including any system housekeeping, backups and

data loading) will not impinge on the online working day, as detailed above.

7.3 Network Management

7.3.1 Specify the network management and control facilities included in the proposed

solution.

7.3.2 Specify the diagnostics that exist to assist in problem resolution.

7.3.3 Does the proposed solution support centralized distribution of all network related software components?

7.4 Scheduling

7.4.1 Indicate how the proposed solution will utilize an integral scheduling facility. 7.4.2 If not, indicate a third party scheduling facility that is recommended and has been

proved to operate successfully with your solution in a live operational environment? 7.4.3 Indicate if a separate version of the scheduling facility required for each of our

environments – development, quality Assurance and Live? 7.4.4 Indicate if such a facility is required for system housekeeping tasks?

8 Costs

8.1 Equipment

8.1.1 What is the cost of system software?

8.1.3 What is the cost of the telecommunications infrastructure required?

8.1.4 What is the cost of the communications software?

8.1.5 Provide a breakdown of the costs of the application software including ongoing indicative licensing and maintenance charges?

8.1.6 Provide a breakdown of the costs of additional third party components?

8.2 Professional Fees

Specify the number of man-days and the cost per day per category for each of the following:


10/9/2013 44

8.2.1 To implement the base solution.

8.2.2 To project manage the implementation of the solution.

8.2.4 To support the solution once implemented.

8.3 Training

8.3.1 Detail the training included in your proposed solution? 8.3.2 What are the costs of required training per user? 8.3.3 What are the costs of required training per train the trainer session? 8.3.4 What are the costs of required training for technical staff?

8.7 Change Request Costs

8.4.1 Specify the additional cost to Biman should the need arise for additional

customizations to the Vendor solution either during, or following the completion of implementation.

8.7 Support Costs

8.6.1 Clearly detail the annual support and maintenance options and charges including

license fees.

8.7 Expenses

8.6.1 List in detail the expected expense costs that the Vendor expects to incur in the

course of the project.

8.7 Other

8.6.1 Are there any additional fees and expenses likely to be incurred in the implementation

of the proposed solution? If so specify

8.9 Application Server Provider (ASP) Solution

Due to the weakness currently of Biman‟s internet bandwidth and reliability we are not willing to entertain an ASP solution but require a system which can be supported locally on a server.

END

Request for Proposal (RFP) Schedule for „Revenue

Documents

Transcript of Request for Proposal (RFP) Schedule for „Revenue