プロパティ管理技術の導入は、組織が実装を単なるソフトウェアのインストールではなく、運用の変更として扱うときに成功します。チームは、変更されるワークフロー、関与するデータとシステム、責任者、成功した展開を定義する条件を理解する必要があります。
クラウドソフトウェア、ワークフローの自動化、統合、AIは、プロパティ運営の一部を管理しやすくします。それらのいずれも、実装計画、データ準備、ガバナンス、トレーニング、または変更管理の必要性を取り除くものではありません。
新しいプロパティ管理技術を導入する際に最も重要なことは何ですか？
- 機能リストではなく、ワークフローやビジネスの問題から始めてください。
- ソフトウェアのコストを実装に必要な総努力から分離してください。
- アーキテクチャにコミットする前に、データ移行と統合の要件を確認してください。
- 最終的なワークフローが承認される前に、実際のユーザーを巻き込んでください。
- 基礎となるプロセスと例外ルールが理解されてから自動化を導入してください。
- ゴーライブ後に人々が新しいワークフローを実際に使用しているかどうかを測定してください。
なぜプロパティ管理技術プロジェクトは苦労するのか？
技術導入の問題はしばしば変化への抵抗として説明されますが、実際の原因はプロジェクトのかなり早い段階に存在する可能性があります。
チームは、誰もがどの既存のプロセスを変更すべきか、どの情報を移動させる必要があるか、または例外をどのように処理すべきかを明確に定義する前に、新しいシステムを使用するように求められることがあります。
| 導入障壁 | 通常その下にあるもの | 解決すべきこと |
|---|---|---|
| 不明確なビジネスケース | 組織は新しいソフトウェアを望んでいることは知っていますが、運用上の問題を正確に定義していません。 | 改善が必要なワークフロー、制限、決定、または情報の問題を述べてください。 |
| コストの懸念 | サブスクリプション価格は、実装、移行、統合、トレーニング、および内部の努力から別々に評価されています。 | 完全な実装と運用コストのビューを構築してください。 |
| ユーザーの抵抗 | スタッフは、ワークフローが変更される理由を理解していないか、新しいプロセスが追加のステップを生み出すことを見ているかもしれません。 | プロセス設計にユーザーを巻き込み、実際のシナリオでワークフローをテストしてください。 |
| 統合の不確実性 | 重要な会計、CRM、支払い、アクセス、またはその他のシステムは、依然として情報を交換する必要があります。 | システム、API、データの所有権、方向、タイミング、認証、および例外処理を定義してください。 |
| データの準備不足 | 既存の記録は重複している、不完全である、一貫性がない、または将来のシステムとは異なる構造を持っている可能性があります。 | 何を移行すべきか、どのようにマッピングされるか、何がクリーンアップまたは検証を必要とするかを決定してください。 |
| 過剰な実装範囲 | あまりにも多くのプロセスが同時に再設計されています。 | 最小限の一貫した初回リリースを特定し、後のフェーズを意図的に順序付けてください。 |
| 弱い所有権 | 誰もが参加しますが、誰もが決定、受け入れ、トレーニング、またはローンチ後の導入を所有していません。 | ビジネス、技術、データ、および運用の所有者を割り当ててください。 |
なぜ実装はソフトウェアではなくワークフローから始めるべきなのか？
機能リストはプラットフォームが何をできるかを教えてくれますが、組織がそれをどのように使用すべきかは教えてくれません。
技術を構成する前に、現在の運用シーケンスを文書化してください。
- プロセスを開始するのは何ですか？
- 各ステージを所有するのは誰ですか？
- どの記録が作成または更新されますか？
- どの承認が必要ですか？
- どのシステムが参加しますか？
- それらの間でどの情報が移動しますか？
- 通常のプロセスが失敗したときはどうなりますか？
- どの結果がプロセスを完了と見なしますか？
そのシーケンスが可視化されると、実装チームは何が手動のままで、何が標準化され、何が合理的に自動化できるかを決定できます。
Booking Ninjas' ワークフローとプロセス管理 Salesforce内で構成可能なルーティング、承認、割り当て、通知、エスカレーション、および構造化されたワークフローの実行を提供します。
すべての既存のシステムを一度に置き換える必要がありますか？
いいえ。技術の近代化プロジェクトは、現在使用されているすべてのアプリケーションを即座に置き換える必要はありません。
一部の既存のシステムは、会計、ERP、支払い、アクセス制御、マーケティング、コミュニケーション、分析、またはその他の専門的な機能にとって重要なままである可能性があります。
したがって、実装の質問は次のとおりです： どのシステムが各記録とプロセスを所有すべきか、残りのシステムはどのように接続すべきか？
Booking Ninjas' 統合 アーキテクチャは、API、ミドルウェア、およびその他の統合パターンを通じて外部プラットフォームとの接続をサポートします。正確な努力は外部システム、その利用可能なインターフェース、データの質、認証、および必要なデータフローに依存します。
プロパティマネージャーは新しい技術のビジネスケースをどのように構築すべきですか？
想定されるROIのパーセンテージから始めることは避けてください。
現在の運用上の問題を測定可能な用語で定義し、改善を示す証拠が何であるかを決定することから始めてください。
| ビジネスケースの質問 | 何を文書化すべきか |
|---|---|
| 今日の課題は何ですか？ | 重複入力、切り離されたデータ、手動承認、報告の遅延、サービス調整、または他の明確に観察可能な問題。 |
| 現在のプロセスには何が必要ですか？ | 人々、システム、手動ステップ、ハンドオフ、例外、および内部管理。 |
| 実装にはどのくらいのコストがかかりますか？ | ソフトウェア、構成、移行、統合、トレーニング、外部サービス、および内部プロジェクトの時間。 |
| 何を変更すべきか？ | 実装後に期待されるワークフローまたは情報の改善を定義してください。 |
| 組織はどのようにしてそれを知るのでしょうか？ | 元の問題に関連する導入、プロセス、データ品質、サービス、財務、または運用の指標を定義してください。 |
ビジネスケースは、期待される結果が測定可能であるが、保証されたソフトウェアの結果として提示されない場合に強化されます。
なぜデータ移行はしばしば導入の問題であり、単なるITの問題ではないのか？
ユーザーは、新しいシステムを部分的に、内部の記録を信頼できるかどうかで判断します。
顧客、プロパティ、予約、支払い、メンテナンス、または他の記録が不完全または重複して到着した場合、スタッフは古いスプレッドシートやアプリケーションに戻るかもしれません。なぜなら、それらのソースは依然としてより信頼できると感じるからです。
したがって、移行計画は次の質問に答える必要があります：
- どの記録を移動する必要がありますか？
- 実際に役立つ履歴記録はどれですか？
- どのフィールドが直接マッピングされますか？
- どの値が変換を必要としますか？
- どの重複を解決する必要がありますか？
- 誰が移行された記録を検証しますか？
- どのソースが権威を持ち続けますか？
- 記録がクリーンに移行できない場合はどうなりますか？
データの検証は、ユーザーが本番環境で新しいワークフローを信頼することが期待される前に行われるべきです。
新しいプロパティ管理システムへのスタッフの抵抗をどのように減らしますか？
抵抗は、実施チームが三つの異なる原因を分けると理解しやすくなります。
人々はなぜ変化が起こるのか理解していません。
新しいプロセスを、スタッフがすでに認識している特定の問題に結びつけるべきであり、ソフトウェア自体を変化の理由として提示すべきではありません。
人々は目標を理解していますが、新しいワークフローを好みません。
実際のユーザーでプロセスをテストしてください。技術的に有効な構成でも、不要なクリック、重複作業、不明瞭な所有権、または不十分な例外処理を引き起こす可能性があります。
人々はもっと練習が必要です。
トレーニングは、プラットフォームのすべての機能を示すのではなく、各役割が実際に行うことに焦点を当てるべきです。
テクノロジートレーニングは何をカバーすべきですか？
トレーニングは役割、ワークフロー、例外に基づくべきです。
| トレーニングレイヤー | ユーザーが理解する必要があること |
|---|---|
| コンテキスト | プロセスがなぜ変更されたのか、そして新しいワークフローが解決しようとしている問題。 |
| 日常のワークフロー | 特定の役割が定期的に使用する記録、画面、アクション。 |
| 例外 | データが欠落している場合、承認が失敗した場合、支払いが調整されない場合、または他の異常なケースが発生した場合に何をすべきか。 |
| 責任 | 各段階をどの役割が所有し、作業が別の人や部門に渡るのはいつか。 |
| サポート | ユーザーが設計されたプロセスを完了できない場合にどこに行くべきか。 |
Booking Ninjasは現在、プラットフォームに関する実装、オンボーディング、トレーニング、ドキュメント、サポートリソースを提供しています。 ナレッジセンター 実装およびサポートプロセスに加えて、セルフサービスのリファレンスレイヤーを提供します。
段階的な展開は、すべてを一度に変更するよりも良いですか？
しばしばそうですが、最初の段階が完全で使えるワークフローを形成する場合に限ります。
プロジェクトを段階に分けることで、ユーザーと実施チームが一度に検証しなければならない変更の数を減らすことができます。ただし、未完成のシステムにわたってワークフローを断片化すると、追加の混乱を引き起こす可能性があります。
有用な最初の段階は、明確な開始、終了、所有者、運用記録、および受け入れ基準を持つべきです。
その後の段階では、最初の運用モデルが安定した後に、プラットフォームを追加のワークフロー、統合、自動化、または報告に拡張できます。
実用的なプロパティ管理テクノロジー採用プロセスとは何ですか？
- 運用上の問題を定義します。 何を変更する必要があり、なぜ現在のワークフローが不十分であるのかを述べます。
- 現在のプロセスをマッピングします。 ユーザー、記録、システム、承認、ハンドオフ、例外、および報告要件を特定します。
- ターゲットワークフローを定義します。 どのステップを残すべきか、変更すべきか、消えるべきか、自動化されるべきかを決定します。
- データと統合を在庫します。 移行する必要があるものと、どの外部システムが接続されたままである必要があるかを特定します。
- 制御された実装範囲を定義します。 すべてのプロセスを同時に再設計しようとするのではなく、一貫した最初のリリースを選択します。
- 実際のシナリオを構成し、テストします。 通常のワークフローだけでなく、キャンセル、修正、承認の失敗、異常な支払い、その他の例外を含めます。
- 役割ごとにユーザーをトレーニングします。 人々が行う作業と、彼らに関連する例外を処理する方法を教えます。
- 明確な所有権で本番稼働します。 システムの質問、ワークフローの決定、技術的な問題、緊急の運用上の例外を誰が扱うかを確立します。
- 採用を測定し、洗練します。 実際のシステム使用、プロセスパフォーマンス、サポートパターン、データ品質、および未解決のワークフロープロブレムをレビューします。
クラウドベースのソフトウェアを選択することで採用が容易になりますか？
クラウド配信は、アプリケーションをローカルサーバーにインストールおよび維持する必要を取り除くことができますが、運用上の実装を排除するわけではありません。
クラウドシステムでも必要な場合があります：
- ワークフロー構成
- データ移行
- 統合作業
- ユーザー権限
- テスト
- トレーニング
- プロセスの所有権
- 変更管理
クラウドアーキテクチャと実装の準備状況を関連するが別の質問として評価します。
AIと自動化はテクノロジー採用にどのようにフィットしますか？
自動化は、組織が自動化したいプロセスを理解した後に最も有用です。
ルール駆動の自動化は、ルーティング、通知、承認、割り当て、その他の予測可能なワークフローステップなどのタスクをサポートできます。
AIは、適切なデータとワークフローが存在する場合に、要約、パターン検出、予測、分類、または推奨などの分析を追加できます。
どちらも不明確な運用プロセスを隠すために使用すべきではありません。
基盤となるプラットフォームアーキテクチャが重要な理由は何ですか？
テクノロジーの決定は、最初の実装以上の影響を及ぼします。将来の要件には、新しい記録、ワークフロー、ユーザー役割、統合、レポート、自動化、または追加の運用モデルが含まれる場合があります。
Booking Ninjasは、 予約と運用のためのSalesforceネイティブプラットフォームです。 .
その運用アプリケーションは、データ関係、権限、自動化、報告、および統合のために、より広範なSalesforce基盤を使用できます。
これにより、Salesforceがすでに組織のテクノロジー環境で重要な役割を果たしている場合に、別の孤立した運用アプリケーションを作成するリスクを減らすことができます。
重要な新しい要件でも、設計、構成、開発、統合、テスト、および実装作業が必要になる場合があります。 Booking Ninjasの背後にある Salesforce基盤についてもっと知る
.
| 新しいプラットフォームを選択する前に評価すべきことは何ですか？ | 評価エリア |
|---|---|
| 尋ねるべき質問 | ワークフローの適合性 |
| ベンダーは、例外を含む私たちの実際のプロセスを示すことができますか？ | 構成 |
| どの要件が標準、構成可能、統合済み、またはカスタムですか？ | データ |
| 何が移行され、何が移行されず、誰が結果を検証しますか？ | 統合 |
| どのシステムが残り、どの情報がそれらの間で移動し、失敗はどのように処理されますか？ | ユーザー |
| どの役割がプラットフォームを使用し、どの権限が必要で、どのトレーニングが必要ですか？ | 実装 |
| 段階、依存関係、責任、および受け入れ基準は何ですか？ | サポート |
| ユーザーが問題を見つけたり、ワークフローの調整が必要になったりした場合、稼働後に何が起こりますか？ | 拡張 |
将来のプロセスを追加することは、基盤となるプラットフォームをすぐに置き換えることなく可能ですか？
Booking Ninjasは運用テクノロジー採用にどのようにアプローチしていますか？
Booking NinjasはSalesforceネイティブプラットフォームで、予約と運用を行います。このプラットフォームは、運用記録をSalesforceのワークフロー、権限、報告、自動化、統合機能と接続します。
Booking Ninjasがどのようにセールスフォースを基盤として使用しているかを見てみましょう。 業務記録、ワークフロー、レポート、権限、そして 拡張性について。
セールスフォースを探る →オンボーディング、プラットフォーム、クライアントポータル、そしてセールスフォース組織に関する Booking Ninjasの体験に関するガイダンスを確認してください。
ナレッジセンターを探る →実装、データ移行、トレーニング、サポート、統合、価格設定、そしてプラットフォームの使用に関する 現在の回答を確認してください。
Booking NinjasのFAQを探る →よくある質問
プロパティ管理技術の採用における最大の障壁は何ですか？
すべての組織に共通する障壁はありません。一般的な問題には、要件の不明確さ、ワークフローデザインの弱さ、統合の不確実性、データ品質の低さ、実装コスト、限られたユーザーの関与、不十分なトレーニング、そして 本稼働後の所有権の不明確さが含まれます。
プロパティマネージャーは新しいソフトウェアへの抵抗をどのように減らすことができますか？
ワークフローを実行する人々を巻き込み、変更の業務上の理由を説明し、現実的なシナリオをテストし、不必要なステップを簡素化し、役割に応じてユーザーをトレーニングし、ローンチ後に明確なサポートパスを維持します。
プロパティマネージャーはすべてのレガシーシステムを一度に置き換えるべきですか？
必ずしもそうではありません。既存の会計、ERP、CRM、支払い、アクセス、またはその他の専門システムは、アーキテクチャの一部として残る場合があります。 重要な決定は、どのシステムが各プロセスと記録を所有し、必要な情報がシステム間でどのように移動するかです。
クラウドソフトウェアは実装の必要性を取り除きますか？
いいえ。クラウドソフトウェアはローカルインフラの要件を減らすことができますが、組織は依然としてワークフローの設定、データ移行、統合、権限、テスト、トレーニング、そして 変更管理が必要になる場合があります。
自動化はソフトウェアの採用を容易にしますか？
自動化は、組織がプロセス、ルール、所有権、例外を定義した後に予測可能なワークフローステップを簡素化できます。曖昧なプロセスを自動化すると、実装の問題を特定するのが難しくなる場合があります。
AIはプロパティ管理業務にどのように導入すべきですか？
定義されたユースケースとそれをサポートするために必要なデータから始めます。 AIは、要約、分類、予測、パターン検出、優先順位付け、または適切なデータとワークフローが存在する場合の推奨などのタスクを支援できます。 例外や高影響の決定には人間のレビューが必要な場合があります。
Booking Ninjasはセールスフォース上に構築されていますか？
はい。Booking Ninjasは、予約と業務のためのセールスフォースネイティブプラットフォームです。 その業務アプリケーションは、接続されたデータ、ワークフロー、権限、自動化、レポート、そして統合のためにセールスフォースの基盤を使用しています。
改善が必要なワークフローから始める
Booking Ninjasに現在の業務がどのように機能しているか、障壁がどこにあるか、どのシステムが接続されたままである必要があるかを示してください。 その後、議論は一般的な機能のデモンストレーションではなく、必要な実装に焦点を当てることができます。
.jpg)
