インシデントについてのスウォームを作成する
学習の目的
この単元を完了すると、次のことができるようになります。
- インシデントについてのスウォームをいつどのように行うかを説明する。
- インシデント、問題、変更要求をいつどのように作成するかを説明する。
- 問題の根本原因を特定する手順を実行する。
インシデント発生
Ada がカスタマーサービスインシデント管理をテストする機会ができました。ソーラーパネルにつながるケーブルから煙が出てシャットダウンしたという複数のケースを受信したのです。5 件のケースが来ており、更に増える恐れがあります。
彼女のこれまでのキャリアでは、ソーラーパネルから煙が出たというのは 1 件しか見たことがありません。そのクローズ済みケースについて自分が作成したナレッジ記事を読みましたが、ここでは関連性がないように思われます。そのケースでは、誰かがパネルにぶつかってコンポーネントが故障したのでした。5 か所の別々のお客様の施設で同時に偶然の破損が起こる可能性は低いため、この問題は何か新しいもののようです。
いずれにしても、ソーラーパネルコンポーネントから煙が出るのはいつでも重大であり、5 件のお客様に影響しているため、この問題はインシデントになります。
インシデントを作成する
Ada はこれらのケースを広範囲のお客様インシデントとして追跡したいと考えます。そこで、サービスコンソールの [Incidents (インシデント)] を使用してインシデントを作成し、関連ケースを追加します。S-1000 ソーラーパネルが問題のある納入商品であるため、この納入商品もインシデントレコードに追加します。
最後に、Slack メッセージをカスタマーサポートチームチャンネルに送信して、煙が出たソーラーパネルに関するケースはすべて自分に送信するようにエージェントに指示します。そのメッセージ内で、ソーラーパネル設備の停止に関するナレッジ記事をリンクし、エージェントが記事をすばやく見つけられるようにします。
根本原因を特定するためのスウォーム
Ada はこの問題に関するナレッジ記事を探しましたが、関連性があるものは見つけられませんでした。問題の根本原因はわかりませんが、回避策がないことはわかっているため、インシデントについて Slack でスウォームを開始して、この問題の解決のために社内のエキスパートの協力を得ます。
彼女はスウォームを作成するときにエキスパートファインダーを使用して、適切な専門知識を持つ対応可能なチームメンバーを見つけます。このインシデントへの対応を進める中で、すべてのカスタマーサービスレベル契約を満たしていることを確認するために、Ursa Major のシニアサービスレベル契約マネージャーをスウォームに含めます。
Slack のスウォームチャンネルで、Ada はソーラーパネルのエキスパートである James C. とこの問題について話します。すると、この種類のソーラーパネルの第一人者である Gertrude Stone を含めることを提案されました。
Gertrude はチャンネルに参加し、メッセージとインシデント情報にすばやく目を通します。彼女は、これはまれな問題だが根本原因について持論があると投稿します。それは記録的な高温によってパネルのオーバーヒートが発生しているというものです。オーバーヒートが発生すると、ソーラーパネルはシャットダウンします。
Ada は発見事項を追跡するために問題レコードを作成します。まず、彼女はお客様に連絡してパネルの温度の計測値を見てもらい、Gertrude の理論が正しいかどうかを確認します。次に、お客様の屋上の温度がおおよそ華氏 130 度 (摂氏 54 度) であることをスウォームに報告します。ソーラーパネル自体の温度はおおよそ華氏 180 度 (摂氏 82 度) です。彼女はこの情報を使用して問題レコードを更新します。
Slack チャンネルで、Gertrude はその温度はこのパネルの承認された動作温度の範囲外であると言います。該当のパネルは古いため、いずれかのコンポーネントでオーバーヒートが発生した恐れがあると彼女は考えています。そこで、持論を確認するために最も近いお客様施設に行ってパネルの損傷を調査します。パネルを分解すると、オーバーヒートしたコンポーネントが見つかりました。
屋上の他の S-1000 ソーラーパネルも熱すぎたため、彼女は帰る前にすべてのパネルが電源から切断されていることを確認します。彼女は Slack チャンネルにメッセージを送信し、Ada は問題レコードの [Root Cause Summary (根本原因概要)] 項目を更新して発見事項を追加します。
原因がわかったため、チームは問題の修正に取りかかることができます。
問題の修正を開始する
Gertrude は問題の修正に必要な手順を保存するために変更要求を作成します。次に、問題の修正に必要な基本要件を含む改善プランを作成します。
- 関連納入商品を特定し、お客様に連絡する。
- 不具合のある温度調節器を交換する。
- 保証返金のためにメーカーに連絡する。
- 対象のパネルをサービスから除外する計画を作成する。
新しい変更要求レコードで、Gertrude は各基本要件への対応に必要な手順を具体的に説明した既存の作業プランを選択します。そのような作業プランが存在しない場合は、作成する必要があります。
最後に、Gertrude は変更要求レコードをインシデントにリンクします。これで、問題に関するすべての情報がインシデントレコードに含まれ、全員が何をすべきかを把握できるようになりました。
完了してケースをクローズする
Ada はインシデントレコードの作業プランの手順を実行します。まず、まだ S-1000 パネルを使用しているお客様を特定します。各パネルの作業指示を作成します。フィールドサービス技術者が通常業務から外されて、すぐに新しい温度調節器を持ってお客様施設に派遣されます。数時間のうちにすべてのソーラーパネルが修理されてオンラインに戻りました。
Ada はすべての関連ケースにメールを送信し、影響を受けたお客様は新しいソーラーパネルに交換するか暑い日には電源から切り離すことを推奨します。その後、ケースをクローズします。
最後に、保障チームのメンバーをスウォームの Slack チャンネルに追加します。彼女は S-1000 を製造したソーラーパネルメーカーに交換部品の返金を求めることをチームに推奨し、インシデントレコードを参照するように伝えます。
Ada は忙しい 1 日を過ごしました。お客様のためにインシデントを特定し、それを修正しました。その過程でインシデントレコードを作成し、チームと協力することで問題を解明して解決しました。カスタマーサービスインシデント管理を使用することでこのインシデントへの取り組みはエージェントとお客様の双方にとってより容易になりました。