ホテルBIを自作するか、専用ツール(SaaS)を導入するか【ホテルDX・分析基盤　第4回】

ホテル独自の判断基準をどこまでシステム化するのか

はじめに

第3回では、生成AIを使ってホテル独自の分析画面を試作する考え方を整理しました。第4回では、ホテルBIに必要な機能のうち、何を自作し、何を専用ツールに任せるのかを考えます。

なお、本記事でいう「自作」には、社内開発だけでなく、クラウドBIや生成AI、外部の開発支援を組み合わせて、自社独自の分析環境を構築する方法も含みます。

専用ツールには、BI SaaS、RMS、分析プラットフォーム等を含みます

「作れる」からこそ、何をシステム化するかを決める

分析画面を作れても、それだけでホテルの意思決定を支援できるわけではありません。売上、稼働率、ADR、競合価格などを確認した後、どの状態で何を判断し、どの業務へつなげるのか。この判断基準をシステムへどこまで反映するかが重要となります。

本記事では、ホテルBIの構成を検討する際に、専用ツールへ任せる領域と、自社で設計する領域をどう分けるかを整理します。自社の運用ルールを、データ、画面、アラート、業務フローのどこまで反映するかがポイントとなります。

本当の違いは「分析機能」より「判断基準」

ホテルによって、収益を生み出すために重視する指標や施策は異なります。価格、早期予約による稼働率の確保、販売チャネルの構成、高単価プランへの誘導など、何を重視するかが違えば、システムへ組み込みたい判断基準も変わります。

自社に必要な分析機能を整理する際は、第2回で公開した「ホテルBI分析一覧（Ver0.1）」も参考にしてください。国内外50社超のBI・RMS・PMS等から整理した58の分析パターンをもとに、自社で利用したい分析、必要なデータ、専用ツールに任せる領域、独自に構築する領域を検討できます。

分析機能を選ぶ際は、各画面で確認する状態、そこから判断する内容、判断後に行う業務を対応づけます。

「ホテルBI専用ツール」と「自作・組み合わせ型」では、判断基準を定義する主体と、導入後に変更できる範囲が異なります。比較する際は、製品の標準機能に合わせて業務を統一する領域と、自社の判断基準に合わせて設計する領域を分けて考えます。

専用ツール（SaaS）：整理された標準機能やロジックを利用しやすい

専用ツールやRMSは、製品が想定する分析目的に沿って、指標、画面、予測、アラート、価格提案などを提供します。標準機能が自社の運用に合う場合は、設計や開発を一から行わずに導入できる場合があります。また、保守や機能更新の一部をベンダーへ任せられるケースもあります。

対象機能や設定変更の範囲は、製品や契約内容によって異なります。

• 標準的なレベニューマネジメントや分析を短期間で始めたい
• 複数施設に共通の分析方法を展開したい
• 社内に開発やクラウド運用の担当者がいない
• 製品が対応する範囲で運用を標準化したい

利用できる指標、データ、判断ロジック、画面の変更範囲は、製品や契約内容によって異なります。自社固有の基準を反映する場合は、設定で対応できる範囲、追加開発の可否、変更後の保守条件を事前に確認します。

自作・組み合わせ型：自社の判断基準を反映しやすい

自作・組み合わせ型では、開発・保守体制を確保できる場合、自社で整理した判断基準や業務フローを分析画面やアラートへ反映できます。

自作・組み合わせ型では、生成AIの新しい機能を小規模に試し、自社の分析目的や業務フローに合うかを確認できます。試作の対象には、分析結果の要約、確認対象日の抽出、次のアクション候補の提示などがあります。試作前に、支援する判断、出力を確認する担当者、確認方法を決めておく必要があります。

• 競合価格と予約進捗を組み合わせた独自の判定条件を使いたい
• 自社で整理した業務フローやフレームワークを実装したい
• 施設やエリアごとに異なる運用ルールを反映したい
• 判定結果に応じて、次に確認する項目やアクション候補を表示したい

判断基準を独自に実装する場合は、判定条件の設計、実データによる検証、仕様変更への対応、障害時の切り分けを自社または委託先で担います。独自化する範囲は、この体制を継続できるかを含めて決めます。

ホテル独自の判断基準をシステム化する

自社で整理したフレームワークをシステムへ反映する場合、最初に「何を表示するか」ではなく、「どの状態をどのように判定し、その後に何を確認するか」を定義します。

例1：Forward RMにおける価格見直し候補

この例では、条件に合った日を確認対象として抽出し、担当者が価格、販売プラン、販売制限を確認します。価格変更そのものを自動化する例ではありません。

例2：業務フローや顧客接点の改善

カスタマージャーニーや業務フローを自社で整理し、顧客接点ごとの予約率、目標値、対応履歴を取得できる場合は、条件に合う接点と確認項目を画面に表示できます。実装時には、対象とする顧客層、集計期間、目標値の設定方法を別途定義します。

表の判定条件や確認項目は、運用後の結果を見ながら更新します。対象日や対象者、確認頻度、担当者の判断、実施した対応を記録し、抽出条件が実務上有効だったかを確認します。

自作と専用ツールを比較する

判断基準を軸に比較すると、違いは次のように整理できます。評価は一般的な傾向であり、実際には製品、契約、内製体制によって変わります。

実務では組み合わせるケースもある

標準機能を専用ツールで利用し、自社固有の分析や判断基準を別のBIや独自画面で補う構成もあります。

構成を決める際は、標準化する業務、施設ごとに残す判断、各システムが扱うデータ、保守の担当を分けて整理します。

どの方法を選んでも、市場データの調達は別に設計する

自作、専用ツール、組み合わせ型のいずれを選ぶ場合でも、競合価格・在庫を継続的に分析するには、市場データの取得・更新方法が必要です。

• 自社で取得処理を構築・運用する
• 外部の市場データサービスを利用する
• 利用可能なAPIを利用する
• 専用ツールに含まれる市場データ機能を利用する

取得対象、更新頻度、保存する履歴、データ形式、利用条件、保守負担を比較し、自社構築、API、外部サービス、専用ツール内の機能のどれで調達するかを決めます。分析画面を自作する場合も、市場データを継続して取得・整備する仕組みは別途必要です。

まとめ

重要なのは、自作か専用ツールかを先に決めることではありません。自社固有の判断基準と業務のうち、標準化する部分と独自に設計する部分を先に分けることです。そのうえで、比較する際は、どちらが優れているかではなく、自社の判断基準をどこまで反映したいのか、その運用を誰が維持するのかを整理することが判断材料になります。

標準機能が自社の運用に合い、開発や保守をベンダーへ任せたい場合は専用ツールが候補になります。独自の判断基準を反映し、設計、検証、保守を担える場合は自作が候補になります。両方の条件がある場合は、標準機能と独自機能の役割を分けて併用します。

次回「AWS・Microsoft Azure・Google CloudでホテルBIを構築」は、自社データと市場データを継続して取得・更新し、BIなどの分析環境で利用するためのクラウド上のデータ基盤を整理します。