---
sourceDocument: Xanadu プラットフォームアナリティクス
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/ja-JP/xanadu/now-intelligence

 Release :

    - xanadu

ft:locale :

    - ja-JP

ft:publication_title :

    - Xanadu プラットフォームアナリティクス

ft:clusterId :

    - par

bundleId :

    - par

workflow :

    - Platform


---

# インジケーターを作成するためのワークフロー

# インジケーターを作成するためのワークフロー {#ariaid-title1}

* リリースバージョン: Xanadu
* 
* 更新日 2024年08月01日
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 所要時間：7分

Now Platformテーブルから始めて、ダッシュボードで共有できるスコアコレクションを使用して、完成したインジケーターまで作業します。

## 始める前に

KPI を作成する前に設計してください。KPI Composerを使用して、パフォーマンスアナリティクスで達成したいビジネスゴールを決定することから始めます。各ビジネスゴールについて、そのゴールの重要な成功要因を決定します。最後に、これらの重要な成功要因の進捗状況を確認するために行う必要がある測定を決定します。これらの測定値は、実装する必要がある KPI に対応しています。パフォーマンス分析ソリューションの設計の詳細については、「 [を使用した パフォーマンスアナリティクス ソリューションの設計 KPI Composer](https://servicenow-prod.fluidtopics.net/PC9Rq4BHbZZto_d_dfBQwQ "KPI Composer パフォーマンス管理戦略がビジネスゴールと一致し、エグゼクティブスポンサーからのサポートが得られるようにします。KPI Composerを使用して、パフォーマンス測定戦略を定義することと、パフォーマンスアナリティクス内からその戦略を実現することの間のギャップを埋めます。ビジネスゴールから始めて、インジケーターから最終的なダッシュボードまでのすべてのコンポーネントを計画します。")」を参照してください。

PA インジケーターを設計したら、ServiceNow から入手可能なパッケージ済みプラットフォームアナリティクスソリューションの 1 つがニーズを満たしているかどうかを確認します。一般的に言えば、これらのパッケージ済みソリューションの 1 つをカスタマイズする方が、ゼロから構築するよりもはるかに簡単です。詳細については、「[アナリティクスソリューション](https://servicenow-prod.fluidtopics.net/yJGN7VZ0X5IRE6p6wItybQ "パッケージ済みソリューションには、データの可視化や重要業績評価指標 (KPI) を備えた プラットフォームアナリティクス ダッシュボードが搭載され、多くの ServiceNow 製品で利用できます。これらのソリューションを使用して簡単に始めることができます。")」を参照してください。

必要なロール：なし

## このタスクについて

必要な KPI がわかったら、インジケーターとブレークダウン、および必要に応じてそれらのデータソースの作成を開始できます。次のワークフローは、Now Platformデータベーステーブルからスコアを収集する KPI の実装である自動インジケーターに適用されます。( 式インジケーターでは、操作を組み合わせて自動インジケーターに適用できることに注意してください。また、Now Platformデータベースをまったく参照しない手動インジケーターと外部インジケーターを使用することもできます。  
重要:  
Performance Analytics は、資格のある担当者が実装する必要があります。こちらで説明しているように、いくつかのトレーニングコースが利用可能です [ServiceNow Community article](https://community.servicenow.com/community?id=community_article&sys_id=44c3a3ecdbf43f84d82ffb24399619c2). このドキュメントは、トレーニングの代わりになるものではありません。

パフォーマンスアナリティクスの KPI の設計はトップダウンのプロセスですが、インジケーターの技術的な実装はボトムアップのプロセスです。

## 手順

1. 分析するデータがあるテーブルを特定します。  
   最小ロール:pa_data_collector

   KPI はどのテーブルを参照していますか? たとえば、KPI がインシデントに関するものである場合、情報はインシデント \[incident\] に含まれます。KPI が変更要求に関するものである場合、テーブルは変更要求 \[change_request\] です。KPI Composerを使用して KPI を設計する場合、この情報は既にあります。
2. KPI に関連するレコードのサブセットを決定します。  
   最小ロール:pa_data_collector

   ほぼ確実に、テーブルのすべてのレコードを参照する KPI はありません。代わりに、オープンインシデントの数、少なくとも 1 回再アサインされたオープンインシデント、オープン日に解決されたインシデントなど、レコードのサブセットを参照する KPI があります。テーブルごとに、レコードの関連するサブセットを定義するために使用できる条件 (「オープン」、「少なくとも 1 回は再アサイン」、「解決済み」、「ステータス\>オープン日に解決済み」など) をメモします。

   繰り返しになりますが、 KPI Composer を使用して KPI を設計する場合、この情報は既にあります。
3. KPI に関連するレコードのサブセットを定義する条件に基づいて、必要なインジケーターソースを決定します。  
   最小ロール:pa_data_collector

   インジケーターソースは、ServiceNow テーブルとそのテーブルのレコードをフィルタリングする 1 つ以上の条件を参照するデータソースです。インジケーターソースはできるだけ少なくする必要があります。この倹約の主な理由は効率です。データ収集では、各インジケーターではなく、インジケーターソースを共有するインジケーターのセットをデータベースにクエリします。インジケーターソースの数を最小限に抑えると、インジケーター全体で信頼できる唯一の情報源を維持するのにも役立ちます。条件を変更する必要がある場合は、インジケーターソースで条件を変更し、この変更を関連するすべてのインジケーターに自動的に伝播できます。

   インジケーターソースを設計するときに、複数のインジケーターに適用できる共通の条件を探します。次の KPI を考慮してください。
   * オープン中のインシデントの数。

   * 少なくとも 1 回再アサインされたオープンインシデントの数。

   * 30 日以上オープンになっているインシデント。

   * 「解決済み」とマークされたインシデント。

   * オープン日に解決されたインシデント。

   {#workflow-automated-indicators__ul_hcb_hgt_rkb}

   これらすべての KPI についてスコアを収集する 2 つのインジケーターソースを作成できます。
   * 1 つは \[インシデント\] テーブルで、オープンなインシデントをフィルタリングします。

   * もう 1 つはインシデントテーブルで、解決されたインシデントをフィルタリングします。

   {#workflow-automated-indicators__ul_icb_hgt_rkb}
4. ニーズに合った既存のインジケーターとインジケーターソースを検索します。  
   最小ロール:pa_data_collector、pa_power_user (インジケーターのみ)。

   冗長なインジケーターとインジケーターソースは一般的な問題です。適切なインジケーターまたはインジケーターソースが存在しないことを確認した場合にのみ、インジケーターおよびインジケーターソースを作成します。

   ニーズを満たすインジケーターソースが見つかった場合は、設計した KPI に一致するインジケーターがそれらのソースに既に存在するかどうかを確認します。  
   注:  
   KPI Composer 適切な既存の パフォーマンスアナリティクス インジケーターの検索を設計プロセスに組み込みます。
5. 必要な不足しているインジケーターソースを作成します。  
   最小ロール:pa_data_collector
6. 必要な KPI に一致する、不足している自動インジケーターを作成します。  
   最小ロール:pa_power_user

   インジケーターソースを入手した後、ビジネスアナリストなどのpa_power_userロールを持つユーザーが自動インジケーターを作成できます。

   インジケーターを作成するときは、 条件を追加します。これらの条件は 1 つまたは 2 つのインジケーターにのみ適用され、インジケーターソースのレベルで適用するのは効率的ではありません。インジケーターソースとインジケーターの間で条件を効率的に分割した場合、インジケーターソースの一部のインジケーターには追加の条件がありません。これらのインジケーターは、インジケーターソースの列の単なる集計です。
7. 関連するブレークダウンを新しいインジケーターに関連付けてマッピングします。  
   最小ロール:pa_power_user

   インジケーターを設計するときに、インジケーターに適用するブレークダウンも設計する必要があります。ブレークダウン設計は KPI Composerに含まれています。場合によっては、新しいブレークダウンまたはブレークダウン ソースを作成する必要がありますが、それはこのワークフローの範囲外です。
8. ブレークダウンのマトリクスを収集して管理します。  
   最小ロール:pa_power_user

   優先度とカテゴリ別の両方によるブレークダウンなど、複数のレベルのブレークダウンを収集する場合は、ブレークダウンマトリクスを設定します。不必要または無意味なブレークダウンの組み合わせは除外してください。
9. インジケーターのジョブを編集します。  
   最小ロール:pa_data_collector

   1 つのスケジュール設定済みデータ収集ジョブと 1 つの (通常は) スケジュール設定されていないデータ収集ジョブをインジケーターに追加します。履歴データが存在する場合は、スケジュールされていないジョブを実行してインジケーターの履歴データを収集します。通常、このジョブはインジケーターの作成時にのみ実行し、二度と実行しません。スケジュール済みジョブをアクティブ化して、通常はインジケーターの頻度に続いて定期的なデータを収集します。1 つの期間のみ収集します。たとえば、頻度が \[日次\] のインジケーターがある場合、前 (最後に完了した) 日を毎日収集するようにスケジュール済みジョブを設定します。
{#workflow-automated-indicators__ol_z4r_tdt_rkb}

## タスクの結果

このワークフローの最後に、データが入力された自動インジケーターが作成されます。この自動インジケーターは、KPI Composer で設計した測定、重要な成功要因、またはサポートインジケーターに対応しています。

## 次のタスク

このインジケーターを式インジケーターに含めることができます。また、インジケーターを可視化するウィジェットを設計し、ダッシュボードを作成して、これらの可視化を適切なステークホルダーと共有することもできます。