Now Platformテーブルから始めて、ダッシュボードで共有できるスコア収集を使用して完成したインジケーターまで作業します。
始める前に
KPI を作成する前に設計してください。KPI Composerを使用して、パフォーマンスアナリティクスで達成したいビジネスゴールを決定することから始めます。ビジネスゴールごとに、そのゴールの重要成功要因を決定します。最後に、これらの重要な成功要因の進捗状況を確認するために必要な測定を決定します。これらの測定値は、実装する必要がある KPI に対応しています。パフォーマンスアナリティクスソリューションの設計の詳細については、「 を使用した パフォーマンスアナリティクス ソリューションの設計 KPI Composer」を参照してください。
PA インジケーターを設計したら、ServiceNow から入手できるパッケージ済みプラットフォームアナリティクスソリューションのいずれかがニーズを満たしているかどうかを確認します。一般的に言えば、これらのパッケージ化されたソリューションの 1 つをカスタマイズする方が、ゼロから構築するよりもはるかに簡単です。詳細については、「アナリティクスソリューション」を参照してください。
必要なロール：なし
このタスクについて
必要な KPI がわかったら、インジケーターとブレークダウン、および必要に応じてそれらのデータソースの作成を開始できます。次のワークフローは、Now Platformデータベーステーブルからスコアを収集する KPI の実装である自動インジケーターに適用されます。( 計算式インジケーターの自動インジケーターに操作を組み合わせて適用できることを覚えておいてください。また、Now Platform データベースをまったく参照しない手動インジケーターと外部インジケーターを使用することもできます)。
重要: Performance Analytics は、資格のある担当者が実装する必要があります。この説明のように、いくつかのトレーニングコースが利用可能です
ServiceNow コミュニティ 記事. このドキュメントは、トレーニングに代わるものではありません。
パフォーマンスアナリティクスの KPI の設計はトップダウンプロセスですが、インジケーターの技術的実装はボトムアッププロセスです。
手順
-
分析するデータを含むテーブルを特定します。
最小ロール:pa_data_collector。
KPI はどのテーブルを参照していますか? たとえば、KPI がインシデントに関するものである場合、情報はインシデント [incident] にあります。KPI が変更要求に関するものである場合、テーブルは変更要求 [change_request] です。KPI Composer を使用して KPI を設計する場合、この情報は既にあります。
-
KPI に関連するレコードのサブセットを決定します。
最小ロール:pa_data_collector。
ほぼ確実に、テーブルのすべてのレコードを参照する KPI はありません。代わりに、オープンインシデントの数、少なくとも 1 回再アサインされたオープンインシデント、オープン日に解決されたインシデントなど、レコードのサブセットを参照する KPI があります。各テーブルについて、関連するレコードのサブセットを定義するために使用できる条件 (「オープン」、「少なくとも 1 回再アサイン」、「解決済み」、「オープン日のステータス>解決済み」など) をメモします。
繰り返しになりますが、 KPI Composer を使用してKPIを設計する場合、この情報はすでにあります。
-
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 つのスケジュール設定されていないデータ収集ジョブをインジケーターに追加します。履歴データが存在する場合は、スケジュールされていないジョブを実行してインジケーターの履歴データを収集します。通常、このジョブはインジケーターを作成するときにのみ実行し、今後は実行しません。スケジュール済みジョブをアクティブ化して、通常はインジケーターの頻度に従って、今後の定期的なデータを収集します。1 期間のみ収集します。たとえば、頻度が [日次] のインジケーターがある場合、前日 (最後に完了した) 日を毎日収集するようにスケジュール済みジョブを設定します。
タスクの結果
このワークフローの最後には、データが入力された自動インジケーターが作成されます。この自動インジケーターは、KPI コンポーザーで設計した測定、重要成功要因、またはサポートインジケーターに対応します。
次のタスク
このインジケーターは、式インジケーターに含めることができます。インジケーターを可視化するウィジェットを設計し、ダッシュボードを作成してこれらの可視化を適切なステークホルダーと共有することもできます。