サービス レベル アグリーメントの作成

完了

サービス レベル アグリーメント (SLA) を作成する前に、SLA で使用する KPI を作成する必要があります。 SLA KPI を使用すると、フィールド技術者が作業指示書を完了するのにかかった時間や、技術者が現場に到着するまでの時間など、サービス プロセスの特定の側面を測定できます。 たとえば、作業指示書の到着時刻 KPI を使用すると、フィールド技術者が適切な時間に現場に到着したかどうかを測定できます。

既定では、Field Service application アプリケーションで定義されている SLA KPI はありません。 作業指示書の到着時刻作業指示書の解決など、どの KPI を追跡するか指定する必要があります。SLA KPI を定義したら、後に SLA 項目を定義する際に選択するためにそこから使用できます。

Field Service KPI を定義していますが、SLA KPI を作成するには、Customer Service 管理センターを使用し、オペレーション グループからサービス条件に移動して、SLA KPI セクションで管理を選択します。

詳細については、Customer Service 管理センターの概要を参照してください。

SLA KPI を定義するときには、次の詳細を指定する必要があります。

  • 名前 - SLA KPI の名前を指定します。これはアプリケーションで識別するために使用されます。

  • 所有者 - 項目の所有者を定義します。 既定では、項目の作成者に設定されますが、その側面は変更できます。

  • エンティティ名 - KPI が関連付けられる Dataverse テーブルを指定します。たとえば、作業指示書テーブルなどです。

  • KPI フィールド - 項目に使用される KPI フィールドを指定します。 たとえば、技術者が現場に到着するまでの時間を定義する SLA KPI を作成する場合は、一覧から作業指示書の到着時刻 KPI を選択します。 すぐに利用できる状態では、作業指示書テーブルには作業指示書の到着時刻 KPI作業指示書の解決 KPI の 2 つのオプションがあり、これらのいずれかを選択できます。

  • 適用開始日 - 警告時間と失敗時間を測定するために使用されるフィールドを定義します。

適用開始日フィールドは、そのエンティティに関連付けられている任意の日付フィールド (たとえば作成日変更日など) に設定できます。 このフィールドにより、SLA KPI の計算が開始される日が定義されます。

たとえば、到着期限 KPI として 3 時間が指定された SLA を作成するシナリオを考えます。 このシナリオでは、適用開始日フィールド の設定内容によって結果が異なります。

  • このフィールドを作成日に設定した場合、技術者は作業指示書が作成された日時から現場に到着するまで 3 時間あります。

  • このフィールドを修正日時に設定すると、作業指示書レコードが更新されるたびに、到着期限 KPI タイマーが再起動されます。

変更日フィールドを使用すると便利な場合もありますが、到着時刻 KPI を追跡するには最適なトリガーではありません。 適用開始日フィールドの設定は KPI の計算方法に大きな影響を与える可能性があるため、十分に注意する必要があります。

新しい SLA KPI エンティティのスクリーンショット。

SLA KPI を定義したら、アクティブ化してサービス レベル アグリーメントで使用し始められるようにします。 新しい KPI を作成した場合、その KPI は既定でアクティブ化されません。 最初にレコードを保存するとき、アクティブ化を選択してアクティブ化することをお勧めします。

SLA の作成

必要な SLA KPI と顧客サービス カレンダー祝日カレンダーなどの項目を作成したら、アプリケーションで SLA の作成を開始できます。サービス条件サービス レベル アグリーメント セクションで管理を選択します。

SLA は、個々の SLA 項目のコンテナーとして機能し、どの SLA KPI と成功の条件が使用されるかを指定します。 最初に SLA を定義する際には、以下の詳細を指定する必要があります。

  • 名前 - SLA の名前を指定します。

  • 主エンティティ - SLA が適用される Dataverse テーブルを定義します。

新しい SLA 定義を示すスクリーンショット。

SLA 項目の定義

SLA 項目を使用して、測定する KPI と、特定の SLA KPI 項目をいつ適用するかを定義できます。 通常の SLA では、複数の SLA 項目が定義されている場合があります。

たとえば、Field Service の SLA には、次の SLA 項目が含まれる場合があります。

SLA と KPI との関係を示す図。

  • 緊急の優先順位 - 到着時刻: 作業指示書の優先順位 = 緊急の場合、1 時間以内に到着

  • 緊急の優先順位 - 解決期限: 作業指示書の優先順位 = 緊急の場合、4 時間以内に作業指示書を解決

  • 高優先順位 - 到着時刻: 作業指示書の優先順位 = の場合、4 時間以内に到着

  • 高優先順位 - 解決期限: 作業指示書の優先順位 = の場合、1 日以内に作業指示書を解決

  • 標準の優先順位 - 到着時刻: 作業指示書の優先順位 = 標準の場合、8 時間以内に到着

  • 標準の優先順位 - 解決期限: 作業指示書の優先順位 = 標準の場合、2 日以内に作業指示書を解決

前の例では、サービス レベル階層ごとに追跡する各 KPI は、独自の SLA 詳細項目として SLA に追加されます。 緊急優先順位の作業指示書への応答とその解決の進捗状況を追跡するには、2 つの独立した詳細項目を定義します。 この場合、SLA 全体で 6 つの SLA 項目が定義されます。

SLA に追加する各 SLA 項目について、次の情報を指定する必要があります。

  • 名前 - SLA 項目の名前を指定します。 (このフィールドは必須です。)

  • KPI - 測定している SLA KPI を指定します。 たとえば、既に定義した到着時刻作業指示書の解決期限の SLA KPI を選択できます。

  • 一時停止と再開を許可 - SLA タイマーを一時停止および再開できるかどうかを指定します。 タイマーが再開された後、一時停止された時間は SLA タイマーに影響を与えません。

  • 営業時間 - SLA 項目に適用する顧客サービス カレンダーがあり、項目の計算方法に影響を与える場合に指定します。

  • 次の場合に適用可能 - SLA の実行対象レコードまたはレコード (緊急に設定される作業指示書優先順位など) に適用される特定の SLA 項目の関連レコードのいずれかに存在する必要がある条件を定義します。

    • 次の場合に適用可能の条件の定義時には、頻繁に変更する可能性のあるフィールドの使用に注意してください。システムのパフォーマンスに影響を与える可能性があります。

    • 条件またはアクションの引数として選択できるのは、アクティブなレコードのみです。

  • 成功条件 - 定義された KPI で成功した解決の状態を定義します (現在のレコードや関連レコードの特定のフィールドが更新されるなど)。

SLA の成功基準の定義のスクリーンショット。

SLA の警告と失敗

SLA 項目の履行の成功とはどのようなものかを定義した後、推定される失敗の警告までの、成功の条件が満たされずに持続できる期間を定義する必要があります。 さらに、項目が失敗と見なされるまでの期間を決定する必要があります。 このタスクを完了するには、SLA 項目の失敗と SLA 項目の警告を設定する必要があります。 それぞれに時間が関連付けられており、それらは互いに独立して動作します。

SLA 警告および失敗期間設定のスクリーンショット。

Actions

アクションを使用すると、成功条件が満たされているかどうかに応じて、特定のタスクを実行できます。 たとえば、技術者が作業指示書の状態を 30 分の警告時間内に移動中に更新しない場合、ディスパッチャーに警告する通知がトリガーされる場合があります。 ディスパッチャーは、何が発生しているのかを確認し、必要に応じて別の技術者に項目を割り当てます。 アクションを定義する前に、詳細項目を保存する必要があります。 保存したら、アクションを定義するには、Actions の構成ボタンを選択します。これにより、Microsoft Power Automate が開きます。 SLA 項目のアクションは Power Automate でサポートされます。

初期状態では、Power Automate フローに 2 つのステップが含まれています。 どちらのステップにも削除または更新しないというラベルが付きます。 これらのステップを変更しないでください。変更すると、Power Automate フローを正しい SLA 項目に関連付けることができなくなるからです。

最初のステップは、SLA KPI インスタンスの変更に関連しています。 このステップがトリガーされるのは、この SLA 項目に関連付けられている SLA KPI インスタンスが変更された場合です。たとえば、成功条件が満たされた場合や、失敗または警告の条件が満たされた場合です。 前述のように、このステップには何もしないでください。

2 つめのステップは、3 つのアクションを含む、切り替えステップです。 この切り替えステップを直接削除または更新することはできませんが、メインの切り替えの下の個々の切り替えステップを編集することができます。 これらのステップは、実行できるアクションを表しています。

次のような 3 つの種類のアクションを定義できます。

  • ほぼコンプライアンス非準拠 - 成功の条件が指定した警告時間内に満たされない可能性がある場合に実行する必要のあるアクションを定義します。

    成功アクションは、拡張 SLA でのみ使用できます。

  • 成功した - 成功の条件が満たされた場合に開始する必要のあるアクションを定義します。

  • コンプライアンス非準拠 - 指定した失敗時間内に成功の条件が満たされない場合に開始する必要のあるアクションを定義します。

Power Automate アクションを使用して、各ステップで実行するアクションを定義できます。 たとえば、次の図は、コンプライアンス非準拠ステップは、最初に SLA 項目がトリガーされた作業指示書レコードの詳細を取得してから、作業指示書レコードの詳細を更新することを示しています。

非準拠によってトリガーされた Power Automate アクションのスクリーンショット。

多くの場合、作業指示書レコードの特定のフィールド (作業指示書の状態フィールドなど) が、SLA 項目が成功したかどうかを判断するための成功の条件として使用されます。

詳細については、サービス レベル アグリーメントの構成を参照してください。