フライト遅延時の乗り継ぎ便の手配をリアルタイム化。顧客満足度を向上させ、数百万ドルを節約する某航空会社

最初にお断りしておくが、当ブログの開始以来はじめて、このSAP HANA事例はまだ稼働していない。現在あるお客様にて「開発中」である。したがってあまり詳細なディテールに触れることもできないし、写真などもないが、ご容赦いただきたい。

■乗り継ぎ遅延の悪夢

みなさんは飛行機が遅延して、乗り継ぐはずの便に乗れなくなった経験をお持ちだろうか？

筆者はアメリカ勤務中、何度か経験があるのだが、これは非常にフラストレーションの溜まる、ちょっとした悪夢なのである。以下はそのイメージ。

-----

2日間の出張が終わり、シアトル発、デンバー乗り換えでヒューストンへ。

そもそも出発の時点で2時間遅れており、おそらく乗り継げないことは出発の時点ですでにほぼ分かっているのだが、機内にいる数時間は状況のアップデートもなくカンヅメ状態なので、降りてみないと状況はわからない。

悪天候に揺られて、やっとのことでデンバー空港に降り立ち、表示ボードを見ると、、、乗り継ぐはずだった便は「Cancelled（欠航）」。ああ、やっぱり、、、

傍らに立つ地上係員が「Transfer（乗り継ぎ客）はこちら」の札を示しているので、そちらに向かうと... ああ、なんてこと。10箇所かそこらしかないカウンターの前には、すでに長蛇の列。

客も係員も疲れているが、日本人と違ってアメリカ人はこういうところでは感情的になったり居丈高に叫んだりする客はいない。ただ黙々と、順番が回ってくるのを待っている。が、列の進みは遅い...

1時間半が経過したころ、やっと自分の順番になり、カウンターにたどりつく。この1時間半の間にも、すでに次々に飛び立っていった機が見えた。

カウンターの職員はキーボードを叩きまくって、私の乗り継げる便を探してくれているが、なんでこんなに手間がかかるんだろう？ひと便ずつ空席照会でもしているのか？「今からヒューストンへ行ける便」で検索したら、瞬間的に候補が提示されてよさそうなものではないか？

それでも5分くらいかかってどうやら見つけてくれたのは、もともと私が乗るはずだった便から約5時間後の最終便（しかもさらに2時間遅れ）。出発まではさらに4時間ちかく待たなくてはならない。

このぶんだと... 帰宅は深夜1時は回るな... それでも、今日中に帰宅できるだけ、まだマシか... やれやれ...

しっかしこのオンライン時代に、カウンターに行列とは。なんとかならんのか？「私」という乗客が乗り継げないことは、少なくとも私が降機する何時間も前から分かっていたではないか。今は運行も予約もすべてIT化されているはずだ。私が飛んでいる何時間もの間に準備をこなしておけないものか？（怒）

-----

国土の広いアメリカでは、国内線が網の目のように発達し、主要都市をカバーしている。最近は直行便も多くなったが、ハブ空港を経由して一度乗り継ぎせざるをえないことも多い。そして悪天候にぶつかると、上記のような苦行が発生するわけだ。

機体の故障などによる一機の遅延やキャンセルは、たまたま当たってしまえば腹は立つが、少なくとも他の便には影響しない。航空会社側も、対処する余裕がある。

いっぽう悪天候による航空機の遅延および欠航はいっせいに発生するから、乗り継げなくなった客もまた同時に・大量に発生する。多くの機体がピストン運行しているから、遅延がさらなる遅延を呼び、後のスケジュールをますます狂わせていく。

しかし予約していた便に乗り継げなくなった多数の乗客は、降機後にカウンター前に行列させ、係員が手作業でオンライン予約システム（基幹系）に照会して処理するしかなかった。ただでさえ遅延に怒っている顧客を、時には1時間以上並ばせることになり、顧客満足度はさらに下がるうえ、手間取っている間に出発してしまう便もある。

結果的に乗り継げなかった乗客にはホテル宿泊料などを提供することもあり※、悪天候1回あたり数千万円ものコストがかかっているそうだ（悪天候による遅延は航空会社の責任ではないから、本来はそうする義務はないのだが）。

■リアルタイムに乗り継げる便をシミュレーション

そこで、航空会社X社は、リアルタイム乗り継ぎ手配アプリケーションをSAP HANA上で開発することにした。

主なコンポーネントは、既存の各システムとのリアルタイムのインターフェースである。

• (A)各運行システムからの離着陸状況データ。どの便が、いつ離陸→着陸し、次に飛び立てるのはいつか
• (B)各座席予約システムからの、今日の便を予約または搭乗している旅客のデータ。誰がどの便に乗り継ぐことになっているのか。
• (C)おなじく各座席予約システムからの、空席状況データ。どの便にいくつ空席があるのか。
• (D)各顧客管理（CRM）システムからの、顧客ごとのプライオリティ。優先すべきVIP顧客は誰か。

そして、それらのデータをリアルタイムに計算して得られる、「乗り継ぎ最適化」データである。

• (E)上記AとBを掛け合わせることで得られる、「乗り継げなくなる顧客」のリスト。
• (F)上記AとCとDとEを掛け合わせることで得られる、「誰をどの便に乗り継がせるべきか」のデータ。 

なるほど、ひとくちに「オンライン化」と言っても、IT的に見ればこれはオオゴトだということは察しがつく。

しかも、「各」の文字に注目いただきたい。航空会社はどこも、大小の合併を繰り返しており、一部のシステムは統合されていない。その場合には、接続先となるシステムはひとつとは限らないのである。

そして悪天候が原因の場合、遅延の状況も刻々とリアルタイムに変わる。この客はこの便に乗せよう、といったん手配がついても、そのなかの一つが予定よりさらに遅延すれば、シミュレーションはすべて崩れ、やりなおしになる。

数百の飛行機（その多くは空中にある）、数万の乗客、手荷物の載せ替えにかかる時間。そしてさらに足を引っ張るのは乗務員（パイロットとCA）の手配だという。連続勤務時間に関する規則と労働組合協定に縛られた乗務員は、遅延したからそのまま残業してこなしてくれ、というわけにもいかないらしい。

こうした多数の変数を瞬時に解析し、できるだけ多くの乗客を（しかもゴールドカードを持つVIP客を優先的に）乗り継がせる。なるほど、超高速インメモリDBならではのユースケースである。

■稼働後（イメージ）

X社が開発中のリアルタイム乗り継ぎ手配アプリケーションが稼働するとどうなるか？以下は想像上の(笑)シナリオである。

-----

悪天候に揺られて、やっとのことでデンバー空港に降り立つと、、、係員が「ヒューストン」の札を持って立っている。

名前を言うと、「Mr. Murata？どうぞ、これが新しいボーディングパスです。62番ゲートへ急いでください。25分後には出発します。手荷物の手配もできてますから」

なんとすばらしい！デンバーまでの便は2時間遅れているというのに、ヒューストン着は1時間遅れで済むではないか！

やっぱりX航空にしてよかった。次回も出張はX航空にしよう...

-----

X社はこのリアルタイム乗り継ぎ手配アプリケーションによって、乗客の満足度を大幅に改善しつつ、年間数百万ドルのコストが節約できるものと期待しているとのことである。稼働が待ち遠しい。

※当記事は公開可能な情報に基づき筆者が構成したものであり、X社のレビューを受けたものではありません。