ドキュメントの検索
karat

+

K

APIリファレンス ↗

注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。

公共安全停電(PSPS)の範囲設定

業界セクター:ユーティリティ

ビジネス機能:オペレーション

電力会社は、強風による火災発生の危険性が高い場合に公共安全停電(PSPS)を実行することがあります。PSPSは、データを取り込み、処理し、ユーザーの非行動を可能にし、それを外部システムに書き込むための時間との競争であり、誤りに対する寛容度はゼロです。Foundryは、これらのPSPSイベントを始めから終わりまで計画し、実行するために使用され、精度、タイムリー性、可監査性を提供し、将来のオペレーションを改善するための学習ループを提供します。

課題

電力会社は、強風による火災発生の危険性がある地元の厳しい天候イベントにさらされています。暑く乾燥した環境では、これが急速に広がる火災、壊滅的な環境影響、死亡につながる可能性があります。最後の手段として、電力会社は公共安全停電(PSPS)イベントを実行し、特定の"期間の懸念"に対して選ばれた"監視回路"の電源を切ります。

このプロセスは、データを取り込み、処理し、ユーザーの非行動を可能にし、それを外部システムに書き込むための時間との競争であり、誤りに対する寛容度はゼロです。複数のチームが必要な共同作業、内部と外部のシステムからの各ステップでの大量の統合は、このユースケースにさらなる課題をもたらしました。

解決策

Foundryは、これらのPSPSイベントを始めから終わりまで計画し、実行するために使用されます。これらの緊急事態を高精度、高速度、可監査性、透明性を持って運営することが重要であり、彼らはこれを地元の規制者に報告し、公共の安全に対する準拠を評価する必要があります。

PSPSイベントが予見されると、ユーティリティは顧客に対して可能な停電について警告する一連のコミュニケーションを開始します。この一連のコミュニケーションは、イベントの72時間前に始まり、電力が復旧してから8時間後に終了します。イベントが近づくと、天候予報が鮮明になり、影響を受ける回路の範囲が変わるため、顧客は通知の連続に追加/削除する必要があるという事態になります。このユースケースでは、Foundryは顧客サービス担当者がFoundryを離れることなく全プロセスを運営します。

公共安全停電(PSPS)の範囲設定

影響

  • 通知を生成するまでの時間:停電が差し迫った通知については、ユーティリティは顧客が電力を失う前に数分で通知する必要があります。
  • 通知の精度:消費者の利益を代表する規制者によって検討される指標 -- 適切なメッセージを適切なタイミングで影響を受ける顧客に配信する。
  • 通知の配信と成功したコンタクトエスカレーション。
  • PSPSの知識ベースを開発し、将来のオペレーションを改善する。
  • 不正確なソースデータを訂正する能力、例えば、回路に誤ってマップされた顧客。
  • 決定作成プロセスの透明性と可監査性。

作り方

Foundryは、通知フローを生成するための複数のトリガーを使用します:

  • 事前に停電が予測された監視回路リスト。
  • ライブで観察された天候の閾値違反による直前の停電。
  • プログラム的なニーズに対する手動トリガー。

Foundryはこれらのトリガーを処理し、配布管理システム(DMS)をクエリして、現在運用されているグリッドの状態(グリッドの設定 -- スイッチなど -- が顧客が電力を得ている回路を変更します)でスコープ内の回路に接続されている顧客のリストを引き出します。

Foundryは影響を受ける顧客を事前にテンプレート化されたキャンペーンにまとめ、一連のビジネスルール(Foundry Rulesで定義されている)を適用して、可能性のある誤って含まれた顧客を除外します。

  • 承認が必要ない場合、Foundryはキャンペーンと通知ペイロードを直接顧客通知およびメッセージングシステム(SFTP経由)に送信し、顧客に即座に放送します。
  • 承認が必要な場合、顧客サービス担当者はキャンペーンのリリースを承認します。承認後、Foundryは通知ペイロードを処理し、それを顧客メッセージングシステムに送信し、即時放送します。

顧客サービス担当者は、プログラム的に除外された顧客のリストを見直し、特定のイベントの通知の残り全体で強制的に含める/除外するためにマーキングします。送信後、Foundryは放送によって返された通知結果(例えば、配信済み、未配信)を受け取ります。ハイプリオリティの顧客が正常に連絡されなかった場合、Foundryレポートは更新され、顧客サービス担当者が再度連絡を試みることができます。連絡が成功しないままの場合、顧客サービス担当者は特定の顧客を消費者問題チームへのエスカレーションのためにマークします。このチームは、連絡が取れなかった重要な顧客のドアをノックするために派遣されます。

消費者問題のユーザーは、Foundryでエスカレーションプロセスを記録し、顧客サービス担当者はイベント中の全通知プロセスを監視します。これには以下が含まれます:

  • 影響を受ける顧客の数とその性質、
  • キャンペーンの成功(配信済み、未配信など)イベントの接近をマーキング(h-72, h-48, h-24など)、
  • 除外プロセス、および
  • エスカレーションプロセス。

類似のユースケースを実装する

このユースケースは、以下のパターンを実装します。特定のパターンについて詳しく知りたい場合や、Foundryでの実装方法を学びたい場合は、以下のリンクをフォローしてください。

このユースケースについて詳しく知りたいですか?何か類似のことを実装したいですか?Palantirで始めてみましょう。