この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
目次
この章は次のトピックで構成されています。
Cisco Prime Service Catalog には、ビジネス インテリジェンス向けの専用のレポート作成環境が付属しています。 Reporting を使用することで、レポートを実行し、選択したデータを表形式またはグラフとして表示することができます。 Cisco Prime Service Catalog レポート ソリューションでは、ビジネス インテリジェンス向けの 2 つのモジュールを提供しています。
Reporting モジュールは、基本的な Service Catalog ライセンスにバンドルされています。 Reporting モジュールでは、Service Catalog で処理されるサービス設計、組織エンティティ、およびトランザクション(申請およびタスク)に関する一連の事前に作成されたレポートを提供します。 このモジュールでは、一連の主要業績評価指標(KPI)であるグラフも表示できます。このグラフは、各ユーザのレポート ダッシュボードで表示されるように設定できます。 次の項では、Reporting モジュールによって提供される機能について説明します。
Reporting を使用することで、レポートを実行し、選択したデータを表形式またはグラフとして表示することができます。 概要レポートには、より詳細なビューにドリルダウンできるように複数のレベルが含まれるようになりました。
Advanced Reporting モジュールは、基本的な Service Catalog ライセンスへのアドオンとしてライセンス可能です。 Advanced Reporting モジュールには、Service Catalog のデータ マート、ならびにデータ マートのデータに基づく単純なクエリーや複雑なレポートを作成するためのツールが含まれています。
Advanced Reporting は、IT ビジネス管理の理解および制御を強化するための完全な分析機能、ユーザ定義レポート、事前に作成されたデータ マートを提供します。 ビジネス価値のメトリックは、IT サービスおよび財務データの品質に関するより深い洞察を提供します。
Advanced Reporting を使用して、独自のレポート コンテンツを定義したり、カスタマイズしたりすることもできます。 ビジネス アナリストは、アドホック レポートを作成するための単純なクエリーを作成できます。一方、レポート開発者は、Advanced Reporting アプリケーションを使用して、より詳細な技術レポートを設計できます。
Reporting のワークフローには、次のさまざまなフェーズがあります。
Service Catalog には、ビジネス インテリジェンス用の専用レポート環境が備わっています。 レポート環境は、複数のコンポーネントから構成されていて、それぞれが特定のタスクや一連のユーザに対して最適化されています。 コンポーネントのリストを次に示します。 レポート環境は、複数のコンポーネントから構成されていて、それぞれが特定のタスクや一連のユーザに対して最適化されています。 コンポーネントのリストを次に示します。
これらのレポート機能は、Service Catalog フレームワークにシームレスに統合されていますが、IBM Cognos Series 10 Business Intelligence(BI)ソリューション ツールセットのツールを使用して実装されています。 次に、これらのツールの概要を示します。
この項では、Service Catalog レポート ソリューションのアーキテクチャについて説明します。 この項の対象読者は、ソリューション内での Cognos コンポーネントの使用方法およびそれぞれの役割について関心のあるユーザです。 Service Catalog レポート ソリューションを使用して、標準パッケージで提供されている事前に作成されたレポートを実行する方法や、独自のアドホック レポートまたはクエリーの生成に主に関心のあるユーザはこの項を飛ばしても差し支えありません。
Service Catalog などのトランザクション システムが動作する同じ環境でユーザにレポートの実行を許可することは、一般的にベスト プラクティスではありません。 レポート、アドホック クエリー、およびその他の詳細な分析を実行するためのリソース要件は、オンライン ユーザに適切に応答するトランザクション システムを実行するためのリソース要件とは大きく異なります。 このため、レポートおよび詳細な分析の基盤となるデータは、トランザクション システムから抽出し、レポート専用に最適化された環境にロードするのが一般的です。
Service Catalog 専用のレポート作成環境は、2 つのパッケージから構成されます。この章の残りの部分では、これらの内容および使用方法の詳細について説明します。
標準レポート パッケージは、事前に作成されたレポートおよび KPI をサポートしています。 さまざまな出力オプションにより、タスク、サービス、および申請に基づく測定およびトレンドの情報が提供されます。 また、個人、組織、サービス チーム、およびサービス グループを含む Service Catalog データの構造に関するレポートも使用できます。 事前に作成されたレポートで使用されるすべてのデータは、カスタム レポート パッケージでも使用できます。 将来的には、このパッケージは カスタム レポート パッケージとマージされます。
カスタム レポート データ パッケージが提供するディメンション モデルを使用して、タスク、サービスおよび申請関連のデータに関するアドホック レポートを作成できます。 標準レポート パッケージで使用できる測定および属性に加え、各サイトにカスタマイズして設定されたサービス フォームにユーザが入力したデータも使用できます。 この「Form Data Reporting」(FDR)により、サービス設計者が「レポート可能」として指定したすべてのディクショナリおよびサービスのすべての属性を把握できます。
標準レポート パッケージは、Service Catalog で提供されている一連の事前に作成されたレポートおよび主要業績評価指標(KPI)ならびにこれらのレポート オブジェクトの生成をサポートするために必要なデータベース テーブルで構成されています。 これらの事前に作成されたオブジェクトは、動作データから生成されるレポートに対する多くの営業部門要件を満たします。
標準レポート パッケージをサポートするデータベースには、詳細テーブルと要約テーブルの両方が含まれます。
詳細テーブルは、データベースの非正規化ビューを提供します。 各テーブルには、対応するレポートに表示されるすべてのデータがあります。 つまり、実行する各レポートが最適化されているため、ルックアップ テーブルで関連データにアクセスしなければならないレポートはありません。 ただし、テーブル間の関係がないため、これらのテーブルを他のテーブルとレポート内で結合することはできません。各テーブルは、指定された詳細レベルの完全なビューであり、OLTP システムに関する 1 つのタイプのファクトの非正規化ビューです。 また、違う詳細レベルへのドリルアップまたはドリルダウンはできません。
要約テーブルには、集計または要約されたデータが含まれています。 データを事前要約することによって、レポート要求への応答で、サマリー レポートがデータをリアルタイムで集計する必要がある場合に発生する処理遅延がなくなります。 詳細テーブルの場合、各要約テーブルはその専用レポートまたは KPI に対してのみ使用される必要があります。アドホック レポート要件をサポートするため、要約テーブルを他のテーブルと結合することはできません。
標準レポート パッケージに含まれる事前に作成されたレポートは、Report Studio ツールを使用して作成されて Reporting モジュールに組み込まれています。 デフォルトのレポート表示形式は HTML に設定されていますが、この配信フォーマットおよび他のランタイム パラメータは、レポートの実行中に変更できます。 レポート ソリューションに Report Designer が含まれている場合、ユーザは事前に作成されたレポートの定義を表示できます。また、必要に応じて、企業の要件をより満たすために定義を変更したり新規レポートを作成できます。
サービス主要業績評価指標は、JFreechart API(JFreechart は Cognos 製品スイートの一部ではなく、オープン ソース ソフトウェア)を使用して生成されます。 各 KPI 用に作成された要約データ テーブルを読み取ることによって、オンデマンドでグラフが生成されます。
Advanced Reporting モジュールを使用することで、Service Catalog データ マートのデータからカスタム レポートおよびクエリーを作成し、Service Catalog からデータを取り込むことができます。
Service Catalog データ マートは、カスタム レポート データ モデル パッケージに基づいています。 このパッケージによって、ユーザはデータ マートにアクセスできるようになります。データ マートには、タスクの実行者やタスクの期間などのサービス、タスク、申請、および工数関連の情報が含まれています。 カスタム レポート パッケージは、標準パッケージと次の重要な点で異なります。
メトリックとは、集約できる数量です。 これは、IT サービスのオーダー、提供の傾向および問題を特定して分析するために使用可能なデータを提供する手段です。
メトリックにより、以下のことが可能になります。
データ マート内のメトリックと属性は、次の表で説明する計算を使用して取得されます。
メトリック |
説明 |
---|---|
サービス ボリューム |
定義された期間内のサービス要求の合計数として計算されます。 特定のレポートに応じて、このメトリックは、完了した要求またはさまざまな状態(進行中、キャンセル済みなど)の要求を具体的に意味します。 |
サービス コスト |
特定のサービスに対して設定された価格から導き出されます。 価格 X 単位は、要求ごとに動的に調整できます。 |
サービス開始日または開始時刻 |
サービスの STARTEDATE および STARTEDDATETIME には、最初にカスタマーがサービス要求を送信した時間が設定されます。 承認が完了し、提供が開始されるとすぐに、STARTDATE 値および STARTEDDATTME 値が更新されます。 これは、STARTEDATE(TIME)が承認の完了前には要求が送信された時間を参照し、承認の完了後には配信が開始された日時を参照することを意味します。 標準対応とタスク期日に関するすべての計算には、実際の提供計画の開始日が使用されます。 |
タスク ボリューム | 承認タスクまたは提供計画タスクの合計数。 承認タスクまたは提供計画タスクの合計数として計算されます。 |
オンタイム % | タスクが完了した時刻(CompletedDateTime)を、タスクが完了する予定の時刻(ScheduledDateTime)と比べることで、タスクが期日どおりであることを判断します。 この計算には期間(実際またはデフォルトの期間)が直接使用されませんが、期限となる日時を最初に計算する際には、当然のこととして期間が使用されました。 |
標準対応 % | 設定された期間内に完了したサービスまたはタスクの割合。 |
タスク期間 | 承認タスクまたは提供計画タスクの開始から終了までの経過時間(時間単位)。 タスクまたは提供計画タスク。 タスク期間は、実行者のカレンダーに基づく作業時間で算出されます。 レポートでは、期間は時間単位で表示されます。 この場合、PerformerActualDuration は 10 時間になります。 |
計画上の工数 | 特定の計画タスクの [工数(Effort)] フィールドに設定された時間から導き出されます(時間単位で計測)。 |
実際の工数 | 特定のタスクに対してタスクの実行者によって入力された時間([工数(Effort)] エントリ)から計算されます |
計画の有効性 | 設定された作業時間内に完了したタスクの割合として計算されます。 |
タスクの標準対応 % | 実行者の実際の期間(タスクが開始された時刻からタスクが完了としてマークされた時刻までの作業時間数)を、タスクに指定されたデフォルトの期間と比べることで、タスクが運用レベル契約(OLA)を満たしていることを判断します。 実際の期間がデフォルトの期間よりも短い場合、タスクは条件を満たしたことになります(StandardComplianceFlag は 1 になります)。 設定された期間内に完了したサービスまたはタスクの割合。 標準対応 % は、標準期間またはタスク期間のいずれかを使用して計算されます。 経過時間のパフォーマンスからオンタイム パフォーマンスを切り分けるために、根本原因分析で使用します。 以前のタスクの完了日に基づき、個々のタスクがその OLA を違反していても、計画上の期間内に実行されるという場合もあります。 |
サービスの標準対応 % | すべてのコンポーネント タスクの実際の期間を合計し、この合計をサービスに指定されたデフォルトの期間と比べることで、サービスがそのサービス レベル契約(SLA)を満たしていることを判断します。 (デフォルトの期間は、サービス設計者がサービスの [一般(General)] タブで設定する [標準期間(Standard Duration)] です)。 実際の期間がデフォルトの期間よりも短い場合、サービスは条件を満たしたことになります(StandardComplianceFlag は 1 になります)。 サービスのデフォルト期間は手動で入力および管理され、サービスのコンポーネント タスクに対する検証は実施されません。 サービス設計者はデフォルトの期間を確認し、サービスに対して予想される実行タスクとその期間について、デフォルトのワークフローをデフォルトの期間に正しく反映させる必要があります。 |
タスク カウント | 個々のタスク レベルでは、この値は 1 または 0 になります。 たとえば、メトリックの名前が完了済みオンタイム タスク数である場合、期日どおりに完了したタスクのカウントは 1 になります。 進行中のタスクの値は 0 になります。 タスクをグループにまとめている場合、すべてのカウントが集計されるので、カウントは、期日どおりに完了したタスクの合計数になります。 |
完了済みオンタイム % または標準対応 % | これらのパーセンテージは、値が 0 または 100 の個々のタスク レベルで示されます。 タスクをグループにまとめている場合、パーセンテージは平均化されて、タスク グループ全体のオンタイム % または標準対応 % が示されます。 |
遅延未完了タスク カウント | このカウントは、個々のタスク レベルで割り当てられます。 タスクが遅延しているか、進行中の状態にある場合、その値は 1 になります。 そうでない場合は、値は 0 になります。 タスクのグループのカウントを集計することで、そのうちいくつのタスクが遅延または進行中であるかを確認できます。 レポートでは、カウントはデフォルトで合計されます。 一般に、遅延未完了タスク カウントの値が大きい場合、それは提供プロセスに問題があることを意味し、カスタマーの不満につながります。 |
タスクの再スケジュール | タスクが再スケジュールされる場合の動作は、次のとおりです。 |
多くのカスタマー サービスの実装方法のように、サービス提供のエンド カスタマーである個人の名前は、サービスのオーダー フォームに保存されています。 この情報は、標準レポート パッケージおよびその事前に作成されたレポート内からはアクセスできません。 このため、サービス提供のカスタマーを登録するには、2 つのオプションがあります。
カスタマーに基づいて、サービス提供オプションを選択できます。
ここでは、ユーザのパフォーマンスを測定する方法について説明します。
タスクは個人に割り当てるか、または個人が作業を引き出せるキューに割り当てられます。 標準レポート パッケージおよび事前に作成されたレポートで使用できるデータ(特に、DM_SERVICETASKDETAIL および DM_AUTHORIZATIONTASKDETAIL 内の [PERFORMERID]、[PERFORMERFIRSTNAME]、[PERFORMERLASTNAME]、[PERFORMEROUID] および [PERFORMEROUNAME] フィールド)は、次の 3 つのいずれかの条件下で個人を参照できます。
最初の条件は、標準レポート パッケージのデータで判別できます。 しかし、2 番目、3 番目についてはその限りではありません。 これはつまり、個人のパフォーマンスの測定を意図したレポートが実際のパフォーマンスを公平に反映した結果となるのは、タスクの責任を共有しないという明確で一貫したルールをサービス チームが持っている場合に限られるということです。 このため、個人のパフォーマンスを測定する、事前に作成されたすべてのレポートに免責事項が表示されます。
サービス提供中に実行されたタスクの期間についての事前作成レポートは、尺度として PERFORMERACTUALDURATION を使用します。 この尺度では、実行者の作業カレンダーを考慮に入れるため、週末とその他業務外の時間はタスク作業時間に計上されません。 逆に、CUSTOMERDURATIONOFSERVICE を尺度とするとカスタマーのカレンダーが考慮に入れられるため、実行者作業の尺度としては不正確になります。
提供チームがタスク実行の優劣を評価する方法は 2 つあります。 両方とも有効ですが、意味合いや使用方法は異なります。
カスタマー中心の確実な測定制度には、両方の基準が必要です。 すべてをタスク期間ベースで考えるならば、実際には「内部基準さえ満たしていれば、カスタマーとの約束はどうでもよい」と言っていることになります。逆に、日付だけに注目していると、チーム メンバーのパフォーマンスを正確に把握できず、カスタマーに対するパフォーマンス向上のために必要となる効果的なリソース決定を行うことができません。
レポート パッケージで使用されるディメンション属性は、Service Catalog OLTP データベースに保持されるデータから取得されます。 以下に、属性について要約します。
属性 |
説明 |
---|---|
顧客* |
サービスの受け手になる個人(本人が直接オーダーする場合と、カスタマーのためにサービスがオーダーされる場合がある)およびカスタマーのホーム組織単位 |
Billed* |
サービスの課金対象組織。 オーダーが確認されるとき(要求を保存した後、送信よりも前)に [課金先:カスタマー(Bill To: Customer)] として別の組織が選択されない限り、サービスのカスタマーと同一です。[課金先:カスタマー(Bill To: Customer)] として選択可能なのは、[課金可能(Billable)] と指定された組織単位だけです。 |
Performer* |
タスクを実行する人(および対応するホーム OU)。 詳細については、個人のパフォーマンスの測定を参照してください。 |
目次
この章は次のトピックで構成されています。
Cisco Prime Service Catalog には、ビジネス インテリジェンス向けの専用のレポート作成環境が付属しています。 Reporting を使用することで、レポートを実行し、選択したデータを表形式またはグラフとして表示することができます。 Cisco Prime Service Catalog レポート ソリューションでは、ビジネス インテリジェンス向けの 2 つのモジュールを提供しています。
Reporting モジュールは、基本的な Service Catalog ライセンスにバンドルされています。 Reporting モジュールでは、Service Catalog で処理されるサービス設計、組織エンティティ、およびトランザクション(申請およびタスク)に関する一連の事前に作成されたレポートを提供します。 このモジュールでは、一連の主要業績評価指標(KPI)であるグラフも表示できます。このグラフは、各ユーザのレポート ダッシュボードで表示されるように設定できます。 次の項では、Reporting モジュールによって提供される機能について説明します。
Reporting を使用することで、レポートを実行し、選択したデータを表形式またはグラフとして表示することができます。 概要レポートには、より詳細なビューにドリルダウンできるように複数のレベルが含まれるようになりました。
Advanced Reporting モジュールは、基本的な Service Catalog ライセンスへのアドオンとしてライセンス可能です。 Advanced Reporting モジュールには、Service Catalog のデータ マート、ならびにデータ マートのデータに基づく単純なクエリーや複雑なレポートを作成するためのツールが含まれています。
Advanced Reporting は、IT ビジネス管理の理解および制御を強化するための完全な分析機能、ユーザ定義レポート、事前に作成されたデータ マートを提供します。 ビジネス価値のメトリックは、IT サービスおよび財務データの品質に関するより深い洞察を提供します。
Advanced Reporting を使用して、独自のレポート コンテンツを定義したり、カスタマイズしたりすることもできます。 ビジネス アナリストは、アドホック レポートを作成するための単純なクエリーを作成できます。一方、レポート開発者は、Advanced Reporting アプリケーションを使用して、より詳細な技術レポートを設計できます。
Reporting のワークフローには、次のさまざまなフェーズがあります。
Service Catalog には、ビジネス インテリジェンス用の専用レポート環境が備わっています。 レポート環境は、複数のコンポーネントから構成されていて、それぞれが特定のタスクや一連のユーザに対して最適化されています。 コンポーネントのリストを次に示します。 レポート環境は、複数のコンポーネントから構成されていて、それぞれが特定のタスクや一連のユーザに対して最適化されています。 コンポーネントのリストを次に示します。
これらのレポート機能は、Service Catalog フレームワークにシームレスに統合されていますが、IBM Cognos Series 10 Business Intelligence(BI)ソリューション ツールセットのツールを使用して実装されています。 次に、これらのツールの概要を示します。
この項では、Service Catalog レポート ソリューションのアーキテクチャについて説明します。 この項の対象読者は、ソリューション内での Cognos コンポーネントの使用方法およびそれぞれの役割について関心のあるユーザです。 Service Catalog レポート ソリューションを使用して、標準パッケージで提供されている事前に作成されたレポートを実行する方法や、独自のアドホック レポートまたはクエリーの生成に主に関心のあるユーザはこの項を飛ばしても差し支えありません。
Service Catalog などのトランザクション システムが動作する同じ環境でユーザにレポートの実行を許可することは、一般的にベスト プラクティスではありません。 レポート、アドホック クエリー、およびその他の詳細な分析を実行するためのリソース要件は、オンライン ユーザに適切に応答するトランザクション システムを実行するためのリソース要件とは大きく異なります。 このため、レポートおよび詳細な分析の基盤となるデータは、トランザクション システムから抽出し、レポート専用に最適化された環境にロードするのが一般的です。
Service Catalog 専用のレポート作成環境は、2 つのパッケージから構成されます。この章の残りの部分では、これらの内容および使用方法の詳細について説明します。
標準レポート パッケージは、Service Catalog で提供されている一連の事前に作成されたレポートおよび主要業績評価指標(KPI)ならびにこれらのレポート オブジェクトの生成をサポートするために必要なデータベース テーブルで構成されています。 これらの事前に作成されたオブジェクトは、動作データから生成されるレポートに対する多くの営業部門要件を満たします。
標準レポート パッケージをサポートするデータベースには、詳細テーブルと要約テーブルの両方が含まれます。
詳細テーブルは、データベースの非正規化ビューを提供します。 各テーブルには、対応するレポートに表示されるすべてのデータがあります。 つまり、実行する各レポートが最適化されているため、ルックアップ テーブルで関連データにアクセスしなければならないレポートはありません。 ただし、テーブル間の関係がないため、これらのテーブルを他のテーブルとレポート内で結合することはできません。各テーブルは、指定された詳細レベルの完全なビューであり、OLTP システムに関する 1 つのタイプのファクトの非正規化ビューです。 また、違う詳細レベルへのドリルアップまたはドリルダウンはできません。
要約テーブルには、集計または要約されたデータが含まれています。 データを事前要約することによって、レポート要求への応答で、サマリー レポートがデータをリアルタイムで集計する必要がある場合に発生する処理遅延がなくなります。 詳細テーブルの場合、各要約テーブルはその専用レポートまたは KPI に対してのみ使用される必要があります。アドホック レポート要件をサポートするため、要約テーブルを他のテーブルと結合することはできません。
Advanced Reporting モジュールを使用することで、Service Catalog データ マートのデータからカスタム レポートおよびクエリーを作成し、Service Catalog からデータを取り込むことができます。
Service Catalog データ マートは、カスタム レポート データ モデル パッケージに基づいています。 このパッケージによって、ユーザはデータ マートにアクセスできるようになります。データ マートには、タスクの実行者やタスクの期間などのサービス、タスク、申請、および工数関連の情報が含まれています。 カスタム レポート パッケージは、標準パッケージと次の重要な点で異なります。
メトリックとは、集約できる数量です。 これは、IT サービスのオーダー、提供の傾向および問題を特定して分析するために使用可能なデータを提供する手段です。
メトリックにより、以下のことが可能になります。
データ マート内のメトリックと属性は、次の表で説明する計算を使用して取得されます。
メトリック |
説明 |
---|---|
サービス ボリューム |
定義された期間内のサービス要求の合計数として計算されます。 特定のレポートに応じて、このメトリックは、完了した要求またはさまざまな状態(進行中、キャンセル済みなど)の要求を具体的に意味します。 |
サービス コスト |
特定のサービスに対して設定された価格から導き出されます。 価格 X 単位は、要求ごとに動的に調整できます。 |
サービス開始日または開始時刻 |
サービスの STARTEDATE および STARTEDDATETIME には、最初にカスタマーがサービス要求を送信した時間が設定されます。 承認が完了し、提供が開始されるとすぐに、STARTDATE 値および STARTEDDATTME 値が更新されます。 これは、STARTEDATE(TIME)が承認の完了前には要求が送信された時間を参照し、承認の完了後には配信が開始された日時を参照することを意味します。 標準対応とタスク期日に関するすべての計算には、実際の提供計画の開始日が使用されます。 |
タスク ボリューム | 承認タスクまたは提供計画タスクの合計数。 承認タスクまたは提供計画タスクの合計数として計算されます。 |
オンタイム % | タスクが完了した時刻(CompletedDateTime)を、タスクが完了する予定の時刻(ScheduledDateTime)と比べることで、タスクが期日どおりであることを判断します。 この計算には期間(実際またはデフォルトの期間)が直接使用されませんが、期限となる日時を最初に計算する際には、当然のこととして期間が使用されました。 |
標準対応 % | 設定された期間内に完了したサービスまたはタスクの割合。 |
タスク期間 | 承認タスクまたは提供計画タスクの開始から終了までの経過時間(時間単位)。 タスクまたは提供計画タスク。 タスク期間は、実行者のカレンダーに基づく作業時間で算出されます。 レポートでは、期間は時間単位で表示されます。
タスクベースのファクト テーブルでは、タスク期間を測定する 3 つの方法があります。
たとえば、次の前提があるとします。
この場合、PerformerActualDuration は 10 時間になります。 |
計画上の工数 | 特定の計画タスクの [工数(Effort)] フィールドに設定された時間から導き出されます(時間単位で計測)。 |
実際の工数 | 特定のタスクに対してタスクの実行者によって入力された時間([工数(Effort)] エントリ)から計算されます |
計画の有効性 | 設定された作業時間内に完了したタスクの割合として計算されます。 |
タスクの標準対応 % | 実行者の実際の期間(タスクが開始された時刻からタスクが完了としてマークされた時刻までの作業時間数)を、タスクに指定されたデフォルトの期間と比べることで、タスクが運用レベル契約(OLA)を満たしていることを判断します。 実際の期間がデフォルトの期間よりも短い場合、タスクは条件を満たしたことになります(StandardComplianceFlag は 1 になります)。 設定された期間内に完了したサービスまたはタスクの割合。 標準対応 % は、標準期間またはタスク期間のいずれかを使用して計算されます。 経過時間のパフォーマンスからオンタイム パフォーマンスを切り分けるために、根本原因分析で使用します。 以前のタスクの完了日に基づき、個々のタスクがその OLA を違反していても、計画上の期間内に実行されるという場合もあります。 |
サービスの標準対応 % | すべてのコンポーネント タスクの実際の期間を合計し、この合計をサービスに指定されたデフォルトの期間と比べることで、サービスがそのサービス レベル契約(SLA)を満たしていることを判断します。 (デフォルトの期間は、サービス設計者がサービスの [一般(General)] タブで設定する [標準期間(Standard Duration)] です)。 実際の期間がデフォルトの期間よりも短い場合、サービスは条件を満たしたことになります(StandardComplianceFlag は 1 になります)。 サービスのデフォルト期間は手動で入力および管理され、サービスのコンポーネント タスクに対する検証は実施されません。 サービス設計者はデフォルトの期間を確認し、サービスに対して予想される実行タスクとその期間について、デフォルトのワークフローをデフォルトの期間に正しく反映させる必要があります。 |
タスク カウント | 個々のタスク レベルでは、この値は 1 または 0 になります。 たとえば、メトリックの名前が完了済みオンタイム タスク数である場合、期日どおりに完了したタスクのカウントは 1 になります。 進行中のタスクの値は 0 になります。 タスクをグループにまとめている場合、すべてのカウントが集計されるので、カウントは、期日どおりに完了したタスクの合計数になります。 |
完了済みオンタイム % または標準対応 % | これらのパーセンテージは、値が 0 または 100 の個々のタスク レベルで示されます。 タスクをグループにまとめている場合、パーセンテージは平均化されて、タスク グループ全体のオンタイム % または標準対応 % が示されます。 |
遅延未完了タスク カウント | このカウントは、個々のタスク レベルで割り当てられます。 タスクが遅延しているか、進行中の状態にある場合、その値は 1 になります。 そうでない場合は、値は 0 になります。 タスクのグループのカウントを集計することで、そのうちいくつのタスクが遅延または進行中であるかを確認できます。 レポートでは、カウントはデフォルトで合計されます。 一般に、遅延未完了タスク カウントの値が大きい場合、それは提供プロセスに問題があることを意味し、カスタマーの不満につながります。 |
タスクの再スケジュール | タスクが再スケジュールされる場合の動作は、次のとおりです。 |
多くのカスタマー サービスの実装方法のように、サービス提供のエンド カスタマーである個人の名前は、サービスのオーダー フォームに保存されています。 この情報は、標準レポート パッケージおよびその事前に作成されたレポート内からはアクセスできません。 このため、サービス提供のカスタマーを登録するには、2 つのオプションがあります。
カスタマーに基づいて、サービス提供オプションを選択できます。
ここでは、ユーザのパフォーマンスを測定する方法について説明します。
タスクは個人に割り当てるか、または個人が作業を引き出せるキューに割り当てられます。 標準レポート パッケージおよび事前に作成されたレポートで使用できるデータ(特に、DM_SERVICETASKDETAIL および DM_AUTHORIZATIONTASKDETAIL 内の [PERFORMERID]、[PERFORMERFIRSTNAME]、[PERFORMERLASTNAME]、[PERFORMEROUID] および [PERFORMEROUNAME] フィールド)は、次の 3 つのいずれかの条件下で個人を参照できます。
最初の条件は、標準レポート パッケージのデータで判別できます。 しかし、2 番目、3 番目についてはその限りではありません。 これはつまり、個人のパフォーマンスの測定を意図したレポートが実際のパフォーマンスを公平に反映した結果となるのは、タスクの責任を共有しないという明確で一貫したルールをサービス チームが持っている場合に限られるということです。 このため、個人のパフォーマンスを測定する、事前に作成されたすべてのレポートに免責事項が表示されます。
サービス提供中に実行されたタスクの期間についての事前作成レポートは、尺度として PERFORMERACTUALDURATION を使用します。 この尺度では、実行者の作業カレンダーを考慮に入れるため、週末とその他業務外の時間はタスク作業時間に計上されません。 逆に、CUSTOMERDURATIONOFSERVICE を尺度とするとカスタマーのカレンダーが考慮に入れられるため、実行者作業の尺度としては不正確になります。
提供チームがタスク実行の優劣を評価する方法は 2 つあります。 両方とも有効ですが、意味合いや使用方法は異なります。
カスタマー中心の確実な測定制度には、両方の基準が必要です。 すべてをタスク期間ベースで考えるならば、実際には「内部基準さえ満たしていれば、カスタマーとの約束はどうでもよい」と言っていることになります。逆に、日付だけに注目していると、チーム メンバーのパフォーマンスを正確に把握できず、カスタマーに対するパフォーマンス向上のために必要となる効果的なリソース決定を行うことができません。
レポート パッケージで使用されるディメンション属性は、Service Catalog OLTP データベースに保持されるデータから取得されます。 以下に、属性について要約します。
属性 |
説明 |
---|---|
顧客* |
サービスの受け手になる個人(本人が直接オーダーする場合と、カスタマーのためにサービスがオーダーされる場合がある)およびカスタマーのホーム組織単位 |
Billed* |
サービスの課金対象組織。 オーダーが確認されるとき(要求を保存した後、送信よりも前)に [課金先:カスタマー(Bill To: Customer)] として別の組織が選択されない限り、サービスのカスタマーと同一です。[課金先:カスタマー(Bill To: Customer)] として選択可能なのは、[課金可能(Billable)] と指定された組織単位だけです。 |
Performer* |
タスクを実行する人(および対応するホーム OU)。 詳細については、個人のパフォーマンスの測定を参照してください。 |