旅行業界の ERP 導入: GDS、チャネル マネージャー、CRM

旅行会社に ERP を導入するには、商業世界で最も複雑な外部データ エコシステムのいくつかに接続する必要があります。 GDS システムは、数百万のフライト区間、ホテル、レンタカーのリアルタイムの在庫を保持しており、価格は 1 日に何千回も変更されます。チャネル マネージャーは、ホテルの在庫を数十のオンライン旅行代理店に同時に配布します。顧客データベースには、何十年にもわたって代理店に予約をしてきた顧客の旅行履歴と好みが保存されています。

各統合には、独自の技術標準、データ形式、およびパフォーマンス要件があります。 GDS 接続には、数十年前に開発された EDIFACT または XML ベースのメッセージング プロトコルが必要です。チャネル マネージャー API はベンダーによって異なります。 CRM の移行では、旅行代理店の最も貴重な競争上の資産である関係履歴を保存する必要があります。

このガイドでは、旅行 ERP 実装のための実務者レベルのフレームワークを提供し、旅行実装を他の業界と区別する外部システム統合に特に注意を払っています。

重要なポイント

• GDS 統合には、ネイティブ API 接続または直接サプライヤー API を介した GDS に依存しない予約のいずれかが必要です
• チャネル マネージャーの統合では、リアルタイムの在庫更新を数秒以内に双方向で処理する必要があります
• 顧客データの移行では、関係の質を維持するために数十年にわたる旅行履歴を保存する必要がある
• 新しいシステムで予約が作成される前に、複数通貨の財務設定を完了する必要があります
• サプライヤー契約と割り当てデータの移行には、デジタル入力の前に現在の条件の法的レビューが必要です
• ATOL および規制順守の構成は、最初の規制対象トランザクションの前に検証する必要があります
• 収益認識構成は会計年度末までに外部監査人によってレビューされる必要がある
• スタッフのトレーニングには、例外シナリオ (キャンセル、修正、苦情) を含む完全な予約ワークフローが含まれている必要があります。

---

実装前: システム エコシステム マッピング

ERP の導入を計画する前に、旅行業界が現在使用しているシステムの完全なエコシステムをマッピングします。

このマッピングにより、統合アーキテクチャとデータ移行の範囲が決まります。 「統合」とマークされたシステムには API 接続が必要です。 「交換」とマークされたシステムでは、完全なデータ移行が必要です。

---

フェーズ 1: 財務基盤と複数通貨の設定 (1 ～ 3 か月)

旅行勘定科目表

旅行会社の勘定科目表は以下をサポートする必要があります。

• 商品タイプ別の収益（パッケージ、航空券、ホテル、旅行、保険）
• 販売チャネル別の収益（直販、代理店、オンライン、法人）
• 預金および前払金の繰延収益
• 総収益と純収益 (サプライヤーの売上原価後)
• パッケージ収入とは別の手数料収入（小売代理店向け）
• 複数通貨操作を考慮した通貨換算

複数通貨構成

海外旅行業者にとって、複数通貨の設定は財務設定の最も重要なタスクです。これには以下が含まれます:

• 基本レポート通貨の定義
• 為替レートソースの構成 (毎日の手動入力、中央銀行フィード、または財務管理 API)
• 取引タイプごとの為替換算ルールの確立（予約日レート対支払日レート対期間平均レート）
• 複数通貨の銀行口座と支払い方法の設定
• 月末の外貨再評価プロセスの設定

予約入力後に通貨設定エラーが発見された場合、トランザクションを取り消して再入力しない限り、修正するのは非常に困難です。この構成は、実際の予約を作成する前に、サンプル トランザクションでテストおよび検証する必要があります。

繰延収益構成

繰延収益構成では、各予約タイプの認識スケジュールを定義する必要があります。

• デポジット: 旅行日までの負債として認識されます。
• 事前に受け取った最終支払い: サービスの提供に応じて段階的に認識されます
• ノーショー収益: 顧客がキャンセルせずにノーショーをした場合、収益をいつどのように認識するかは、会社の会計方針によって定義する必要があります。

この構成は、旅行収益の扱いが解釈の対象となる可能性があり、実装後に監査人と意見が相違すると混乱が生じるため、運用開始前に外部監査人によってレビューされる必要があります。

---

フェーズ 2: サプライヤーと製品カタログのセットアップ (2 ～ 5 か月目)

サプライヤーマスターデータ

サプライヤー データベースには、クルーズ会社、ホテル、航空会社、地上管理者、保険会社、レンタカー会社、ビザ サービスなど、すべてのアクティブなサプライヤーを入力する必要があります。各サプライヤーに対して、ERP には以下が必要です。

• サプライヤーの連絡先情報と口座番号
• 支払い条件と優先支払い方法
• 請求書発行および支払いに使用する通貨
• 手数料率のスケジュールと上書きしきい値
• キャンセルおよび変更ポリシー (顧客の予約におけるキャンセル料の計算に影響します)

サプライヤー データは、非アクティブなサプライヤーを削除し、連絡先情報を更新するレビュー後に、既存のサプライヤー データベースから移行するのが最適です。

製品カタログの構成

製品カタログはツアー オペレーターの中核となる構成であり、エージェントが予約できるすべての販売可能な製品を定義します。中規模の旅行会社の場合、これには以下が含まれる場合があります。

• 50～200の主要なツアー商品（旅程、出発日、キャビン/部屋カテゴリー別の価格）
• 部屋タイプと季節料金を備えた 500 ～ 2,000 のホテル施設
• 目的地ごとに 20 ～ 50 の地上オペレーター サービス
• 10～25の旅行保険商品

このカタログを構成するには、各サプライヤー契約および割り当て契約からのデータが必要です。データ入力の労力は膨大であり、完全なカタログを入力して検証するには 1 人で 4 ～ 8 週間の予算がかかります。

割り当てと利回り管理の設定

割り当てを契約しているツアーオペレーターの場合、割り当て管理構成には次のものが含まれます。

• 割り当て契約条件（部屋/キャビンの数、カテゴリーごとの価格、リリース日）
• グループの最小サイズと最大サイズ
• 子供割引とシングル追加料金
• 販売停止日（在庫を提供できない期間）

---

フェーズ 3: GDS 統合 (3 ～ 7 か月目)

GDS 統合は、旅行 ERP 実装において技術的に最も複雑な統合です。 GDS は、業界標準の XML または EDIFACT メッセージ形式を使用して通信します。 ERP は、独自のデータ モデルと GDS メッセージ形式の間で変換を行う必要があります。

統合アーキテクチャのオプション

GDS 統合には 3 つのアーキテクチャ オプションが存在します。

1. GDS API への直接接続: ERP は、認定された API (SOAP/XML または REST) を介して GDS​​ に直接接続します。これにより最大限の制御が可能になりますが、GDS 認定が必要になります。これは正式なテストと承認のプロセスで、6 ～ 12 か月かかる場合があります。

2. ミドルウェア/アグリゲーター: サードパーティのミドルウェア プラットフォーム (Verteil、Duffel、Kiwi.com API) が ERP と GDS の間に位置し、複雑な GDS プロトコルを処理し、よりシンプルな API を ERP に提供します。これにより統合の労力は軽減されますが、予約ごとのコストが増加します。

3. 予約ポータルの統合: ERP は、GDS API ではなく GDS 端末予約システムと直接統合され、完了後に予約データをキャプチャします。これは技術的には簡単ですが、ERP 主導の予約ワークフローはサポートされていません。

ほとんどの旅行 ERP 実装では、ミドルウェア/アグリゲーター オプションが機能と実装速度の最適なバランスを提供します。

GDS データ マッピング

GDS は、フライトの空席状況と価格を構造化 XML または EDIFACT メッセージで返します。このデータを ERP 予約データ モデルにマッピングするには、以下が必要です。

• フライトセグメントデータ（航空会社、便名、出発/到着時刻、サービスクラス、停車地）
• 運賃データ（運賃基礎コード、合計運賃、税金内訳、発券期限）
• 予約クラスの空席状況（各運賃クラスの空席数）

ERP はこれらのメッセージを正しく解析して、予約エージェントに正確な価格と在庫状況を表示する必要があります。

発券の統合

フライトの予約が確認された後、航空券を発行する必要があります。これは、航空券の書類を作成し、航空会社に支払いを送信するプロセスです。発券は、電子その他の文書 (EMD) または従来の航空券番号を使用して GDS​​ を通じて実行されます。 ERP チケット発行ワークフローは以下を処理する必要があります。

• 予約確認時の自動発券（即時支払い取引の場合）
• 発券期限追跡による延期発券
• 航空券の変更と払い戻し（適切な航空料金控除あり）
• 航空会社の決済を差し引いた航空券販売の収益会計

---

フェーズ 4: チャネル マネージャーの統合 (3 ～ 8 か月目、ホテル)

ホスピタリティ ビジネス (ホテル、B&B、宿泊施設を備えた小規模ツアー オペレーター) の場合、チャネル マネージャーの統合により、すべての流通チャネルで在庫と価格が一貫していることが保証されます。

チャネル マネージャーのアーキテクチャ

チャネル マネージャー (SiteMinder、RateGain、Cloudbeds) は、ホテルのプロパティ管理システムと OTA チャネル (Booking.com、Expedia、Airbnb) の間のハブとして機能します。 ERP は次の目的でチャネル マネージャーと統合する必要があります。

• 部屋の在庫と価格の更新をチャネル マネージャーにプッシュします (OTA に配布します)。
• チャンネルマネージャーから予約通知を受け取る（OTAから予約を受信した場合）
• 予約が確認されると、すべてのチャネルで部屋を完売としてマークします

リアルタイムの在庫更新要件

チャネル マネージャーの統合は、ほぼリアルタイムである必要があります。部屋が 1 つのチャネルを通じて販売され、他のチャネルへの更新に数分以上かかる場合、需要のピーク時にオーバーブッキングが発生する可能性があります。統合では、スケジュールされたポーリング (ERP が一定の時間間隔で新しい予約をチェックする) ではなく、Webhook コールバック (予約が受信されるとすぐにチャネル マネージャーが ERP に通知する) を使用する必要があります。

レートパリティ管理

多くのホテルは OTA と料金同等契約を結んでおり、OTA を通じて独自の直接チャネルを通じて提供する料金と同じかそれより低い料金を提供することを約束しています。チャネル マネージャーの統合では、ERP の価格変更が接続されているすべてのチャネルに同時に正しく送信されるようにすることで、レート パリティを強制する必要があります。

---

フェーズ 5: CRM と顧客データの移行 (5 ～ 9 か月目)

顧客データベースの移行

旅行会社の顧客データ移行は、その奥深さと価値において独特です。創業 20 年の旅行代理店には、2004 年のカリブ海クルーズ、2009 年のアフリカ サファリ、2015 年のライン川クルーズなど、20 年前に遡る完全な旅行履歴を含む顧客記録がある可能性があります。この履歴は関係ベースの販売の原材料となります。

移行範囲

顧客の移行には以下を含める必要があります。

• 連絡先情報（名前、住所、電子メール、電話番号、パスポート情報）
• 旅行履歴 (日付、目的地、商品、支出を含む完了したすべての予約)
• 好み（キャビンカテゴリー、食事制限、優先航空会社、記念日）
• ロイヤルティ残高とティアステータス
• コミュニケーション設定とオプトイン履歴
• 財務情報 (記録されている支払い方法、与信限度額、未払い残高)

データ品質の準備

移行前に、顧客のデータ品質レビューを実施します。

• 重複する顧客レコードを特定してマージします (同じ顧客が複数回入力された場合)
• パスポートの有効期限を検証します（期限切れのパスポートにはフラグを立て、最新のものとして移行しないでください）
• ロイヤルティ ポイント残高を調整する (システムが示すよりも多くのポイントを保有していると信じている顧客)
• 非アクティブな顧客 (7 年以上予約がない) を移行せずにアーカイブします。

関係の価値を維持する

旅行コンサルタントと長期顧客との関係履歴は、旅行代理店の最も貴重な資産です。新しいシステムが顧客の連絡先を希望のコンサルタントに正しくルーティングできるように、旅行コンサルタントの割り当てが各顧客レコードとともに移行されていることを確認します。

---

フェーズ 6: トレーニングと本番稼働の準備

役割ベースのトレーニング

出張 ERP トレーニングは役割別に行う必要があります。

• 旅行コンサルタント: 完全な予約ワークフロー - 検索、価格設定、予約、修正、キャンセル - に加え、顧客プロファイル管理とロイヤルティ プログラム管理
• 財務スタッフ: 繰延収益管理、サプライヤー支払いスケジュール設定、手数料調整、通貨再評価
• 運行スタッフ (DMC、ツアーオペレーター): 地上運行のスケジュール設定、ガイド管理、車両の配車
• 管理: レポートと分析 — 製品別の予約数、チャネル別の収益、顧客維持指標

予約ワークフローのテスト

本番稼働前に、現実的なシナリオでエンドツーエンドの予約ワークフロー テストを実施します。

• 航空券、ホテル、送迎付きの FIT (海外個人旅行) 予約を完了する
• 団体予約（予約金、分割払い、最終支払いあり）
• 違約金計算および返金処理を伴うキャンセル
• 修正（予約後の出発日の変更、料金の再計算）
• 苦情処理（サービス品質に関する苦情の記録と解決）

各シナリオは、実装チームだけでなく、運用環境で実行するスタッフによってテストされる必要があります。

---

よくある質問

実装のカットオーバー時にサイクルの途中にある過去の予約データはどのように処理すればよいですか?

カットオーバー時にアクティブな予約 (確認済みだがまだ移動していない) は、すべての関連データ (予約ステータス、コンポーネントの詳細、支払い履歴、未払い残高、サプライヤーの支払いスケジュール) とともに新しいシステムに移行する必要があります。これらの「機内」予約では、エラーが差し迫った旅行を予定している顧客に影響を与えるため、最も慎重な移行が必要です。本番移行に取り組む前に、レガシー システム レコードに対してアクティブな予約のサンプルの移行をテストします。

新しい ERP における ATOL コンプライアンスの規制への影響は何ですか?

ATOL 準拠では、ATOL で保護されたすべての予約が正しく識別されること、ATOL 徴収金 (現在は乗客 1 人あたり £2.50) が計算および考慮されること、CAA に返される年間 ATOL に正確な乗客数が含まれることが必要です。 ERP は、どの予約が ATOL で保護されているか (通常は英国で販売されるフライトを含むパッケージ) を識別し、それぞれの課税額を計算して報告し、年次 ATOL 収益データを生成するように構成する必要があります。この構成は、最初の保護された予約が新しいシステムで処理される前に、既知の ATOL で保護された予約シナリオに対してテストする必要があります。

GDS 認定にはどれくらいの時間がかかりますか?また、完了する前に公開することはできますか?

直接 API 統合のための GDS 認定 (Amadeus、Sabre、Travelport) には通常 6 ～ 12 か月かかり、技術テスト、セキュリティレビュー、GDS による正式な承認が含まれます。認定期間中、エージェントは他の ERP 機能が稼働している間も、フライト予約に従来の GDS 端末を引き続き使用できます。あるいは、GDS を直接統合する代わりにミドルウェア アグリゲーターを使用すると、認証要件がなくなり、より迅速な稼働が可能になります。

実装では、リモートで働く旅行コンサルタントをどのように処理しますか?

最新のクラウド ERP プラットフォームは、インターネットに接続されたあらゆるデバイスから完全にアクセスできるため、追加のインフラストラクチャなしでリモート作業が可能になります。在宅勤務の旅行コンサルタントは、Web ブラウザを通じて ERP にアクセスします。モバイル アクセスにより、コンサルタントはどこからでもクライアントのリクエストに対応できます。セキュリティ制御 (MFA、IP 制限、セッション タイムアウト) により、リモート作業環境で顧客データが保護されます。

各顧客の旅行履歴について、どのデータを移行する必要がありますか?

各顧客について移行する最低限の旅行履歴データには、予約参照番号、旅行日、目的地、商品タイプ、乗客数、予約金額合計、支払いステータス、割り当てられた旅行コンサルタントが含まれます。理想的には、完全な予約の詳細 (コンポーネントの内訳、サプライヤー名、キャビン/部屋のカテゴリー) も移行して、関係ベースの販売会話に必要な完全なコンテキストを提供する必要があります。

---

次のステップ

ERP 導入を計画している旅行会社は、統合と移行要件の全範囲を理解するために、システム エコシステムのマッピングとサプライヤー データの監査から始める必要があります。 ECOSIRE の Odoo 実装プラクティスは、GDS 統合の専門知識、チャネル マネージャーの接続、および複数通貨の財務管理を備えた旅行および観光業の ERP 実装を提供します。

ECOSIRE の Odoo ERP 導入サービスを探索 して、当社の旅行業界の専門知識が予約管理から財務報告に至るまでの ERP 変革をどのように導くことができるかをご覧ください。