テーブルから Now Platform 始めて、ダッシュボードで共有できるスコアコレクションを使用して、完了したインジケーターまで作業します。
始める前に
KPI を作成する前に設計してください。を使用して KPI Composer、まず、 で パフォーマンスアナリティクス達成するビジネス目標を決定します。各ビジネス目標について、その目標の重要な成功要因を決定します。最後に、これらの重要な成功要因の進捗状況を確認するために、どのような測定を行う必要があるかを決定します。これらの測定値は、実装する必要がある KPI に対応しています。Performance Analytics ソリューションの設計の詳細については、次を参照してください を使用したソリューションの設計パフォーマンスアナリティクスKPI Composer。
PA インジケーターを設計したら、からServiceNow入手可能なプラットフォームアナリティクスソリューションパッケージ済みインジケーターの 1 つがニーズを満たしているかどうかを確認します。一般的に言えば、これらのパッケージ済みソリューションの 1 つをカスタマイズする方が、ゼロから構築するよりもはるかに簡単です。詳細については、「分析ソリューション」を参照してください。
必要なロール：なし
このタスクについて
必要な KPI がわかれば、インジケーターとブレークダウン、および必要に応じてそれらのデータソースの作成を開始できます。次のワークフローは、データベース テーブルからNow Platformスコアを収集する KPI の実装である自動インジケーターに適用されます。( 式インジケーターでは、自動インジケーターに操作を組み合わせて適用することができます。また、データベースをNow Platformまったく参照しない手動インジケーターと外部インジケーターを使用することもできます。
重要: Performance Analytics は、資格のある担当者が実装する必要があります。以下で説明しているように、いくつかのトレーニングコースが利用可能です
ServiceNow Community article. このドキュメントは、トレーニングの代わりになるものではありません。
Performance Analytics の KPI の設計はトップダウンのプロセスですが、インジケーターの技術的な実装はボトムアップのプロセスです。
手順
-
分析するデータがあるテーブルを特定します。
最小ロール:pa_data_collector
KPI はどのテーブルを参照していますか? たとえば、KPI がインシデントに関するものである場合、情報はインシデント [incident] にあります。KPI が変更要求に関するものである場合、テーブルは変更要求 [change_request] です。を使用して KPI Composer KPI を設計する場合、この情報は既にあります。
-
KPI に関連するレコードのサブセットを決定します。
最小ロール:pa_data_collector
ほぼ確実に、テーブルのすべてのレコードを参照する KPI はありません。代わりに、オープンインシデントの数、少なくとも 1 回再アサインされたオープンインシデント、オープン日に解決されたインシデントなど、レコードのサブセットを参照する KPI があります。テーブルごとに、レコードの関連サブセットを定義するために使用できる条件 (「オープン」、「少なくとも 1 回再アサイン」、「解決済み」、「オープン日に解決されたステータス」など>メモします。
繰り返しになりますが、KPI の設計に使用している KPI Composer 場合は、この情報はすでに得られています。
-
KPI に関連するレコードのサブセットを定義する条件に基づいて、必要なインジケーターソースを決定します。
最小ロール:pa_data_collector
インジケーターソースは、ServiceNow テーブルとそのテーブルのレコードをフィルタリングする 1 つ以上の条件を参照するデータソースです。インジケーターソースはできるだけ少なくしたい。この倹約の主な理由は効率です。データ収集では、各インジケーターではなく、インジケーター ソースを共有するインジケーターのセットをデータベースにクエリする必要があります。インジケーターソースの数を最小限に抑えることは、インジケーター全体で信頼できる唯一の情報源を維持するのにも役立ちます。条件を変更する必要がある場合は、インジケーター ソースで条件を変更し、この変更を関連するすべてのインジケーターに自動的に伝播できます。
インジケーター ソースを設計するときに、複数のインジケーターに適用できる共通の条件を探します。次の KPI を検討します。
これらすべての KPI のスコアを取得する 2 つのインジケーターソースを作成できます。
-
ニーズに合った既存のインジケーターとインジケーターソースを検索します。
最小ロール:pa_data_collector、pa_power_user (インジケーターのみ)。
冗長なインジケーターとインジケーターソースは一般的な問題です。適切なインジケーターまたはインジケーター ソースが存在しないことを確認した場合にのみ、インジケーターとインジケーター ソースを作成します。
ニーズを満たすインジケーターソースが見つかる場合は、設計した KPI に一致するインジケーターがそれらのソースに既に存在するかどうかを確認します。
注: KPI Composer 適切な既存の パフォーマンスアナリティクス インジケーターの検索を設計プロセスに組み込みます。
-
必要な不足しているインジケーターソースを作成します。
-
必要な KPI に一致する欠落している自動インジケーターを作成します。
最小ロール:pa_power_user
インジケーター ソースを入手した後、ビジネス アナリストなどのpa_power_userロールを持つユーザーが自動インジケーターを作成できます。
インジケーターを作成するときは、 条件を追加します。これらの条件は 1 つまたは 2 つのインジケーターにのみ適用され、インジケーター ソースのレベルで適用するのは効率的ではありません。インジケーター ソースとインジケーターの間で条件を効率的に分割した場合、インジケーター ソースの一部のインジケーターには追加の条件がありません。これらのインジケーターは、インジケーター ソースの列の集計にすぎません。
-
関連するブレークダウンを新しいインジケーターに関連付けてマッピングします。
最小ロール:pa_power_user
インジケーターを設計するときは、インジケーターに適用するブレークダウンも設計する必要があります。ブレークダウン設計は に含まれています KPI Composer。新しいブレークダウンまたはブレークダウン ソースを作成する必要がある場合がありますが、それはこのワークフローの範囲外です。
-
ブレークダウンのマトリクスを収集して管理します。
最小ロール:pa_power_user
優先度とカテゴリの両方によるブレークダウンなど、複数のレベルのブレークダウンを収集する場合は、ブレークダウン マトリクスを設定します。不必要または無意味なブレークダウンの組み合わせは除外してください。
-
インジケーターのジョブを編集します。
最小ロール:pa_data_collector
スケジュール設定済みのデータ収集ジョブと (通常は) スケジュール設定されていないデータ収集ジョブを 1 つずつインジケーターに追加します。履歴データが存在する場合は、スケジュール設定されていないジョブを実行してインジケーターの履歴データを収集します。通常、このジョブはインジケーターの作成時にのみ実行し、今後は実行しません。スケジュール設定済みジョブを有効にして、今後 (通常はインジケーターの頻度に従って) 定期的なデータを収集します。1 期間のみ収集します。たとえば、インジケーターの頻度が日次である場合は、前 (最終完了) 日分を毎日収集するようにスケジュール設定済みジョブを設定します。
タスクの結果
このワークフローの最後には、データが入力された自動インジケーターが作成されます。この自動インジケーターは、KPI Composer で設計した測定、重要な成功要因、またはサポートインジケーターに対応します。
次のタスク
このインジケーターを式インジケーターに含めることができます。インジケーターを可視化するウィジェットを設計し、ダッシュボードを作成してこれらの可視化を適切なステークホルダーと共有することもできます。