一括物件管理ソフトのユーザーアクセス：複数ホテルを運営するためのロール設計

週末だけホテルBの応援に入るフロントスタッフに、グループ全体への恒久的なアクセス権限が自動的に付与されるべきではありません。経理担当者には3施設の記録が必要でも、客室料金の変更や管理者の作成を行う権限までは必要ない場合があります。

一括物件管理ソフトのユーザーアクセスは、オーナーがスタッフの職務と、その職務を担当するホテルを分けて考えることで、適切に管理できます。まず担当業務を整理し、利用可能な制御機能を設定したうえで、実際に付与されたアクセス権限を検証しましょう。

対象施設の範囲と操作権限を分ける

対象施設の範囲とは、スタッフがアクセスできるホテルやユニットを指します。操作権限とは、その範囲内で閲覧、変更、承認、エクスポート、管理できる内容を指します。

施設の選択機能があるだけでは、施設間のアクセスが分離されている証拠にはなりません。メインカレンダーでホテルCを非表示にしても、同じアカウントで検索から宿泊者情報を閲覧したり、売上をエクスポートしたりできるなら不十分です。関連するすべての機能を通じて、実際にアクセスできる範囲を確認してください。

同様に、決済記録の閲覧と、決済の受付、返金の実行、精算情報の変更は、それぞれ異なる操作です。料金の閲覧と編集も異なります。「マネージャー」といった大まかな名称ではなく、こうした業務上の判断を軸に権限を設計しましょう。

担当範囲は短い文で明記します。例えば、「リアはホテルAの到着対応と部屋割りを管理できる。ただし、返金、グループ全体の宿泊者リストのエクスポート、ユーザー管理はできない」とします。承認された一時的な応援先の施設と、その終了日は別途追記してください。

制御機能の名称や設定できる細かさは、ホテル管理システム、つまり一括物件管理ソフトによって異なります。承認された担当業務を、実際に利用できる設定に対応付けてください。機密性の高い操作を技術的に分離できない場合、承認に関するメモを残すだけでアクセスが制限されると考えてはいけません。権限を絞ったアカウントや、管理者の支援のもとで実行する管理された業務フローを使い、その制約を文書化しましょう。

ログイン情報を共有していると、こうした設計の徹底や確認が難しくなります。全員がオーナーのアカウントを使っている場合、ロールの定義だけでは誰が予約を変更したかを特定できません。Smart OrderのホテルPMSでは、スタッフごとに担当業務に合ったロールを設定して利用しましょう。運用開始前に利用可能な権限設定を確認し、日々の業務で管理者のログイン情報を共有する必要がないようにしてください。

スタッフが実際に行う判断を軸にロールを定義する

以下はロール設計の出発点となる概要であり、どのシステムにも共通する標準ロール名ではありません。担当の割り当てごとに、対象施設の範囲と例外を記録してください。

フロントデスク

担当施設で必要となる予約、到着対応、部屋割り、宿泊者とのコミュニケーションに関する業務を許可します。予約のキャンセル、合意済み料金の変更、割引の適用、決済の受付、宿泊者情報のエクスポートを許可するかどうかは、個別に判断してください。

グループ内の複数施設を担当するフロントスタッフには、担当する施設を明示します。一時的な応援体制を適切に整える代わりに、すべてのホテルへのアクセス権限を付与することは避けましょう。

ハウスキーピングと設備保守

担当業務に必要な客室、作業、受け入れ準備状況の情報と、必要最小限の宿泊者対応情報を提供します。業務に関係のない財務集計へのアクセスや、宿泊者情報の一括エクスポートは避けてください。作業完了の登録、点検の合格判定、設備保守に伴う販売停止の解除を誰が行えるかを決めましょう。これらの判断をすべて同じ人に任せる必要はありません。

収益管理と予約

承認された担当施設の範囲と、客室料金、空室状況、予約制限、予約変更を管理する権限を定義します。影響の大きい変更のうち、どの変更にマネージャーの確認が必要かを決めてください。グループ全体の料金へのアクセス権限に、ユーザー管理や決済の認証情報へのアクセスまで自動的に含めるべきではありません。

経理

担当する事業体に必要な予約、請求、決済、返金、レポートへのアクセス権限を付与します。システム上で区別できる場合は、返金の確認と実行の権限を分けてください。エクスポート権限と、ダウンロードした記録の取り扱いも定めましょう。ホテル管理システムへのアクセス権限を失っても、すでにエクスポートされたファイルを回収できるわけではありません。

施設マネージャーとシステム管理者

施設マネージャーには1つのホテルの運営を監督する権限が必要な一方、システム管理者はユーザーや設定を管理します。小規模な事業で1人が両方を担当する場合でも、それぞれの責任を区別できるようにしておきましょう。

利用可能なアカウントセキュリティ機能と、文書化した復旧手順で管理者アクセスを保護します。アクセスを復旧するための、別途承認された手段を確保してください。ただし、すべてのシフトで使い回す、利用者を特定できない共有アカウントは作成しないでください。

ロール名だけでなく、実際に有効なアクセス権限を検証する

スタッフには複数のロールや追加の権限が付与される場合があります。最終的な組み合わせを確認してください。1つのロールを削除しても、別のロールなどで付与された操作権限が残ることがあります。制限の厳しいロールが、より広い権限を持つロールより常に優先されるとは限りません。

承認されたテスト用アカウントと架空のデータを使用します。権限を検証するためだけに、実際の返金、本番環境での料金変更、他施設の宿泊者の滞在情報の変更を行うことは避けてください。

1. 重要な権限の境界ごとに、許可する業務と禁止する業務を1つずつ書き出します。そのアカウントがアクセスしてはいけない施設も検証対象に含めてください。
2. 正式に認められた管理手順に従い、提案したロールと対象施設の範囲を設定します。設定内容と承認者を記録してください。
3. 変更が反映された後、スタッフが通常使う経路からログインします。メニューを開くだけでなく、許可された業務を最後まで実行できるか検証してください。
4. 検索、レポート、エクスポート、モバイルなど、関連する対応済みの経路から、禁止された閲覧や操作ができないか検証します。意図せず実データが表示された場合は中止し、アクセス権限の修正に必要な最小限の証拠だけを、機密情報を伏せて保存してください。
5. アカウントに付与されたロールの組み合わせ全体と操作履歴を確認します。権限の過不足を修正し、影響する項目を再度検証してください。

例えば、2日間の応援勤務では、リアにホテルBの到着対応を許可し、ホテルCの到着対応は許可しない場合があります。両方の条件を検証したうえで、合意した応援期間の終了後にホテルBへのアクセス権限が解除されることも確認してください。勤務表に終了日を記載することと、アクセス権限の有効期限を実際に適用することは別です。

デスクトップだけでなく、モバイルからのアクセスも確認します。Smart Orderのホテル管理アプリには、メインのホテル管理システムの権限が適用されるため、ロールを検証する際はスマートフォンでの業務フローも対象に含めてください。デスクトップでの検証が成功しただけで、スタッフが実際に使う経路の確認を済ませたことにしてはいけません。

入社・異動・退職時にアクセス権限を見直す

新しく入社するスタッフについては、本人専用のアカウント、職務、担当施設、承認者、利用開始日、必要な研修を確認します。付与するアクセス権限は必要なものに限定してください。勤続年数の長いスタッフのアカウント設定をコピーすると、長年にわたる一時的な例外まで引き継いでしまう場合があります。

異動や一時的な応援勤務では、新たに付与する権限だけでなく、従来の権限も見直します。有効期限による自動解除が利用できない場合は、誰が例外設定を解除するかを記録してください。ロール変更後は、保存した設定がすべての経路に即座に反映されたと思い込まず、実際に有効なアクセス権限を確認しましょう。

退職時は、承認された手順でアカウントを無効化し、対応機能がある場合は有効なセッションや関連システムにも対処したうえで、担当業務を引き継ぎます。ホテル管理システムへのアクセス権限を削除しても、別途付与されたOTA、決済事業者、メール、端末へのアクセスまで解除されるとは限りません。該当する各アカウントについて、それぞれの正式な手順で対応してください。

スタッフ一覧と権限は定期的に見直し、人員や施設に大きな変更があった後にも確認します。休眠アカウント、広範な管理者権限、期限切れの応援勤務設定、重複する権限、理由を説明できないエクスポートや機密性の高い変更に注目してください。

設計が整えば、オーナーは各スタッフのアクセス権限を、対象施設、許可された業務、重要な制限を含む1文で説明できるはずです。承認された例外を把握・検証できる状態に保ち、昨日の緊急対応用のアクセス権限が、明日の標準設定として残らないようにしましょう。