Kein Folientitel

1
Good Things Take Time Building up an
OD-Forecaster
Stefan Poelt Presentation to the AGIFORS RES YM
Study Group Berlin, 16 - 19 April 2002
2
Agenda

• How does a perfect project look like ?

• Whats the scope of our OD project ?

• Some traps to watch

• OD Forecaster system overview

• Whats the current status ?

• Happy end !

3
How does a perfect project look like ?

• A perfect project
• Is in time
• Is in budget
• Covers the scope
• Delivers quality

• Our project
• Is not quite in time
• Is in budget
• Scope has been adjusted
• Delivers quality

4
Whats the scope of our OD project ?
5
Simple vs. complex forecast method

• Separation of individual and group bookings
• Separation of gross bookings and cancellations
• Flexible aggregation of low demand traffic flows
• Complex methods are more difficult to calibrate
• Complex methods can better model reality
• Trade-off between accuracy and stability

6
Better no-show forecasts allow better overbooking

• Traditional no-show forecasts are based on
  booking class and routing
• PNR is a richer data source (e.g. ticketing info,
  special service request etc.)

• Theres gold in the PNR data mine (Louis
  Busuttil, PROS Conference 1997)
• PNR-based no-show forecast (Klaus Weber,
  AGIFORS Conference 2000)
• PNR-based methods can be applied to booked
  passengers only - they must be mixed with
  traditional no-show forecasting
• PNR-based methods (e.g. decision trees) can also
  be applied to cancellation forecasting

7
OD forecasting without OD optimization

• Intermediate step OD forecasts aggregated to
  leg-level and used in leg-optimization
• Better quality of leg demand forecasts
• Better quality of (PNR-based) no-show forecasts ?
  lower overbooking risk
• OD information, better understanding of travel
  flows
• Better communication and co-operation with
  Pricing and Scheduling / Flight Planning

8
Reasons for delay

• Too optimistic project plan
• Internal staffing (6-7 project members, 4 users
  part-time)
• Under-estimation of noise in PNR data
• Frequent change of project management
• Scientific driven project late involvement of
  users
• Research and calibration effort for new topics
  (e.g. cancellations)
• Re-organizations
• 11. September 2001

9
Renaming the project does not help

• Project name Bid Price 2
• Original scope was adjusted, OD-optimization was
  stopped after 11. September 2001

• There were plans to rename the project to
  OD-Forecaster
• This might help to confuse controllers but does
  not help to solve the problems

10
Shit happens

• There are many situations where something can go
  wrong
• The business processes havent been addressed at
  the beginning
• Later on we realized that important
  functionalities are missing
• Noise and complexity of PNR data have been
  under-estimated
• Aggregation of no-show information from OD to
  leg is problematic

11
A precise specification avoidscomplaints later-on

• Innovative IT-projects require a lot of research
• Alternation of research and prototyping /
  implementation
• We decided to refine the specification during the
  project
• Problems keeping specification and documentation
  up to date
• Testing with fuzzy specification is challenging

12
A good documentation is important

• Documentation often is prioritized down
• Good documentation improves users confidence
• 3 documents
• system administration
• user manual / online help
• process / workflow

13
In a perfect project Project managers have the
right perspective

• Focusing on the most important topics
• Understanding the subject (RM and Forecasting)
• Good communication and motivation skills

• Currently 2 project managers, one focusing on
  management, the other focusing on methods -
  learning from each other

14
In a perfect project Motivation of the project
team is not an issue

• Working for years on the same thing is boring
• We are the 4. generation of project managers
• The project survived 2 re-organizations
• Increase motivation by changing responsibilities
• Success is the best motivator !

15
Our new toy
16
Aggregation solves the small numbers problem

• There are many low traffic ODs
• 2090 rule - 20 of all ODs cover 90 of the
  traffic
• Flexible aggregation of low traffic ODs is a key
  factor

17
Effects of schedule changes are handled
automatically

• A major schedule change can affect thousands of
  ODs
• Concept of Lufthansa Systems Berlin handles new,
  moved and cancelled flights
• Demand is automatically adjusted based on
  neighbored flights/paths
• Distance to neighbored flights mainly depends
  on departure and arrival times
• Approximation of market (passenger choice) model

18
This year we will take the last hurdle

• Forecast quality (aggregated to leg-level) is
  better than for current system
• Data loading performance is o.k.
• Business processes have been re-designed and
  matched with the tool
• Flight by flight migration of new forecast system
  (Jun - Nov 2002) minimizes risk
• Business re-organization will go hand in hand
  with migration

• Parallel project of OD-reporting is started
• Married Segments Control is implemented in
  Amadeus and Galileo

19
The forecast results are very promising

• Validation of OD-forecaster at representative
  test flights
• Distinction of open and closed flights to
  separate unconstraining effects
• Open flights are less important but have reliable
  actual values

20
Happy end !

• The OD forecaster will be completely in
  operation this year
• Very good cooperation with Lufthansa Systems
  Berlin
• OD not always means Odd Delayed !