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