English
Tiếng Việt午前2時、給水ポンプが異常を知らせます。制御室の画面に赤いランプが点灯します。それで、どうなるでしょうか。ビル管理システム（BMS）やIoTからの設備アラートは、検知は得意ですが、たいていそこで止まります。担当者と期限のある仕事にはならないのです。
結論から言うと、BMSがAPIでアラートを出力できれば、SalesforceでCaseを自動作成し、それをField ServiceのWork Orderに変換できます。仕事は、正しい設備、場所、技術者に紐づき、技術者はスマートフォンのアプリで受け取り、写真を撮って検収します。
【ご注意】これはBMSのベンダーと、各ビルのシステム構成に依存するため、約束する前に事前調査が必要です。この記事は、特定のベンダーとの連携が可能であるとは主張しません。Field Serviceは別ライセンスです。記事中のビルや場面は説明用の仮定であり、実在のお客様ではありません。
BMSとIoTのアラートから、Case、Work Order、検収までの流れ。設備アラートが制御室で止まってしまう理由
ビル管理システム（BMS）やIoTセンサーは、信号を集めて異常を検知するために作られています。信号を、担当者のいる仕事に変えることは、たいていその役割の範囲外です。
そのため、実際の運用は人に頼ることになります。当直の担当者が赤いランプを見て、誰かに電話やメッセージを送り、その後はすべて記憶頼りになります。仕事の番号も期限もなく、シフトの終わりには、作業が終わったのか誰も確信できません。
経営層にとっては3つの影響があります。インシデントが期限内に処理されたことを証明しにくい。どの設備が繰り返し故障するかが見えにくい。そしてテナントから問い合わせがあっても、答えるための記録がない。これは技術だけの問題ではなく、運用の問題です。早期検知は、誰かが動いて初めて価値を持ちます。
アラートからWork Orderまでの4ステップ
アラートをBMSの外に出す
- BMSやIoTがAPIでアラートを出力できる場合、連携レイヤーがそれを受け取り、Salesforceに渡せる
- アラートには、設備ID、場所、異常の種類、時刻を含める必要がある
Service CloudでCaseを作成する
- 条件を満たすアラートごとに、番号、Priority、Ownerを持つCaseとして記録する
- CaseをAsset（設備）に紐づけ、その設備固有の故障履歴と保守履歴を確認できるようにする
CaseをField ServiceのWork Orderに変換する
- Work Orderは何をすべきかを、Service Appointmentはいつ、どこでをそれぞれ表す
- 必要なSkillと、適切な技術者グループ（たとえば電気や給排水）が仕事に紐づく
技術者が仕事を受け取り、検収する
- 技術者はスマートフォンのアプリで仕事を受け取り、設備情報と対応履歴を確認する
- 対応後、検収用の写真とメモを残し、仕事を完了にする
- CaseとWork Orderに、すべてが記録され、検索やレポートに使える
Caseと Priority の部分は、Repair Tickets: 4 Priority Levels, No Request Forgotten（英語）で詳しく説明しています。
連携を約束する前の現実的な条件
この流れは単純に聞こえますが、各ステップには条件があります。下の表は、お客様にコミットする前に、事前調査で答えておくべき質問の一覧です。
| 条件 | 重要な理由 | 確認する質問 |
|---|---|---|
| BMSにAPIがあるか | アラートを出力する手段がなければ、自動化できない | BMSベンダーはどの出力方法に対応しており、費用や制限はあるか |
| アラートに十分な情報があるか | 設備IDや場所がなければ、仕事を正しく紐づけられない | 各アラートにはどの項目が含まれるか |
| 設備リスト（Asset） | BMSの設備とSalesforceの設備を対応づける必要がある | 現在の設備リストは整理されており、IDは統一されているか |
| Field Service ライセンス | 別ライセンスで、ユーザー単位の課金 | 何人の技術者とディスパッチャーが必要か |
| ノイズとなるアラートの絞り込み | 誤報が多いと、仕事が増えすぎる | どのアラートが仕事の作成対象になるか |
仮の例：午前2時にポンプが異常を知らせたら
仮の例：オフィスビルの屋上に給水ポンプがあります。午前2時に、センサーが異常な圧力を知らせます。BMSがAPIでアラートを出力できる場合、流れは次のようになり得ます。
| ステップ | 何が起きるか |
|---|---|
| アラートを受信 | システムが、ポンプIDと場所つきのアラートを受け取る |
| Caseを作成 | Salesforceが、ポンプに紐づくCaseを作成する。Priorityは運営会社のルールに従う |
| Work Orderを作成 | Caseが、給排水のSkillを必要とするWork Orderに変わる |
| 仕事を割り当てる | 適切な技術者が、スマートフォンのアプリで仕事を受け取る |
| 検収 | 技術者が、対応後に写真を撮り、仕事を完了にする |
翌朝、ビル管理側には明確な記録が残ります。誰が受け、何をし、いつ行い、写真つきで確認できます。これはプロセスの例であり、実際のお客様の所要時間や効果の数値はありません。
自社のビルに適用する際の注意点
先に調査し、約束は後で。連携の程度は、BMSのベンダー、バージョン、構成に依存します。お客様や経営層にコミットする前に、現状を調査してください。
すべてのアラートで仕事を作らない。誤報が頻繁に出ると、技術者は疲れ、次第に無視するようになります。本当に対応が必要なアラートを選びましょう。
緊急のインシデントは、引き続き直接連絡が必要。Work Orderは安全手順の代わりにはなりません。人の閉じ込めや漏電のような危険なインシデントでは、当直チームにすぐ連絡する必要があります。
Field Serviceは別ライセンス。Salesforceのドキュメントによると、Field Serviceはユーザー単位の課金で、Service Cloudのライセンスが少なくとも1つ必要です。新しいドキュメントでは、製品名はAgentforce Field Service and Operationsとなっています。EditionとコストはSalesforceまたは導入パートナーに確認してください。こうしたワークフローを取り巻くAIの全体像は、Einstein AI in Salesforce: What Can AI Actually Do for Your Sales & Marketing Team?（英語）をご覧ください。
設備データを整理しておく。設備リストが散らかっていると、仕事が誤った設備に紐づきます。何かを接続する前に、リストを見直しましょう。
設備アラートとWork Orderをつなぐ前のチェックリスト
コミットする前に、次の短いリストで、この流れが自社のビルで実現可能か確認しましょう。
☐ BMSがAPIでアラートを出力できるか確認した
☐ 各アラートに含まれる項目（設備ID、場所、種類）を洗い出した
☐ 設備リストとIDを見直した
☐ 仕事の作成対象とするアラートの種類を選んだ
☐ 種類ごとのPriorityと担当者を決めた
☐ Field Serviceのライセンスとコストを確認した
☐ 緊急のインシデントでは当直チームに直接連絡する手順を用意した
あなたの現場のBMSは、APIを公開していますか？下のコメント欄でぜひ教えてください。Sonixチームがお待ちしています。
Salesforce Service Cloud
デジタルトランスフォーメーション
業界トレンド
ビジネス
Smart Building
ビル管理
Field Service
Sonixにご相談ください。BMSと設備リストを一緒に調査し、アラートから検収までの流れを設計します。
Sonix: Your success is our happiness.
コメントを残す