Cisco Prime Service Catalog 11.0 レポート ガイド
使用する前に
使用する前に

目次

使用する前に

この章は次のトピックで構成されています。

Cisco Prime Service Catalog レポート ソリューションについて

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 のワークフロー

Reporting のワークフローには、次のさまざまなフェーズがあります。

  1. レポート ソリューションのライセンスを購入します。 詳細については、『Cisco Prime Service Catalog Ordering Guide』を参照してください。
  2. 管理者が Reporting ソフトウェア モジュールをインストールし、Prime Service Catalog アプリケーションと統合します。 詳細については、『Cisco Prime Service Catalog Installation and Upgrade Guide』を参照してください。
  3. 管理者が Prime Service Catalog レポート ソリューションにアクセスするためのユーザ ロールおよび機能を作成し、Reporting コンポーネントを設定します。
  4. サービス設計者またはレポート設計者が、Ad-Hoc Reporting モジュールで「レポート可能」として指定したディクショナリおよびサービスから申請(フォーム データ)のデータ マートにデータを抽出できるようにします。 詳細については、「レポートの設計」を参照してください。
  5. 要件に合わせてレポートを生成できるようになります。 Reporting モジュールを使用したレポートへのアクセス方法またはレポートの表示方法については、「レポートの使用」を参照してください。
  6. 定期的なメンテナンス作業を実行します。

Reporting アーキテクチャおよびコンポーネント

Service Catalog には、ビジネス インテリジェンス用の専用レポート環境が備わっています。 レポート環境は、複数のコンポーネントから構成されていて、それぞれが特定のタスクや一連のユーザに対して最適化されています。 コンポーネントのリストを次に示します。 レポート環境は、複数のコンポーネントから構成されていて、それぞれが特定のタスクや一連のユーザに対して最適化されています。 コンポーネントのリストを次に示します。

  • 事前に作成されたレポートとは、一連の実稼働品質レポートで、サービス、申請、およびタスクそれぞれのレベルのパフォーマンスを分析します。
  • 主要業績評価指標(KPI)とは、アプリケーション ポータルで表示できる一連のグラフであり、システム内のトレンドに関するデータへの即時アクセスを可能にします。
  • Ad-Hoc Reports を使用すると、ビジネス ユーザは(タスク、サービス、および申請のパフォーマンスに関する)標準レポートで使用できるデータだけでなく、サイトのサービス フォームに含まれているカスタム設計のディクショナリ内のフィールドのデータにも基づいてクエリーを作成できます。
  • Report Designer を使用すると、ビジネス ユーザは申請、タスク、またはサービスに関連するデータだけでなく、サービスごとにカスタマイズされたサービスフォーム データ(個々のディクショナリおよびフィールド)も含むように標準レポートを変更したり新規レポートを作成したりできます。
  • カスタム Java プロバイダーを使用すると、Service Catalog 個人プロファイル情報を Cognos 名前空間として使用できます。 これにより、Service Catalog に登録済みでレポート権限を管理者から割り当てられているすべてのユーザは、すべてのレポート ツールに対して、統合されたシングル サインオン アクセスが可能になります。

これらのレポート機能は、Service Catalog フレームワークにシームレスに統合されていますが、IBM Cognos Series 10 Business Intelligence(BI)ソリューション ツールセットのツールを使用して実装されています。 次に、これらのツールの概要を示します。

  • IBM Cognos 10 Connect により、Service Catalog では Cognos レポートなどのレポート オブジェクトを表示できます。
  • IBM Cognos 10では、実稼働品質レポートをビジネス ユーザおよび非テクニカル ユーザに対して提供します。 このようなユーザは、Cognos 10 機能を使用してレポートを印刷したり、Office などのアプリケーションに適した形式で出力を保存できます。
  • IBM Cognos Query Studio(「Ad-Hoc Reports」としてユーザに提示される)により、ユーザはレポート データに対して Ad-Hoc クエリーを実行できます。
  • IBM Cognos Report Studio(「Report Designer」としてユーザに提示される)により、ユーザは既存のレポートを変更したり、新規レポートを作成したりできます。 これは、Service Catalog データベースに格納されている異なるタイプのデータ間の関係を理解できるテクニカル ユーザまたはパワー ユーザにお勧めです。
  • IBM Cognos Data Manager はシスコのエンジニアが使用するツールで、トランザクション データベースからデータを抽出して専用のレポート環境にロードするプログラムを作成します。
  • IBM Cognos Framework Manager はシスコのエンジニアが使用し、アドホック レポートおよびクエリーのエンド ユーザが使用できる情報のデータ レベルおよびビジネス レベル ビューを定義します。
  • IBM Cognos Event Studio では、レポート データベース内のデータの値によってトリガーされるイベントを定義します。 イベントが発生すると、電子メールまたは例外レポートの実行などによりユーザに通知できます。 アプリケーションには事前設定されたイベントはありませんが、Advanced Reporting ユーザはデータ マートの内容に基づいて独自のイベントを定義できます。

Reporting アーキテクチャ

この項では、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 が含まれている場合、ユーザは事前に作成されたレポートの定義を表示できます。また、必要に応じて、企業の要件をより満たすために定義を変更したり新規レポートを作成できます。

サービス KPI

サービス主要業績評価指標は、JFreechart API(JFreechart は Cognos 製品スイートの一部ではなく、オープン ソース ソフトウェア)を使用して生成されます。 各 KPI 用に作成された要約データ テーブルを読み取ることによって、オンデマンドでグラフが生成されます。

Service Catalog データ マート:Advanced Reporting

Advanced Reporting モジュールを使用することで、Service Catalog データ マートのデータからカスタム レポートおよびクエリーを作成し、Service Catalog からデータを取り込むことができます。

Service Catalog データ マート

Service Catalog データ マートは、カスタム レポート データ モデル パッケージに基づいています。 このパッケージによって、ユーザはデータ マートにアクセスできるようになります。データ マートには、タスクの実行者やタスクの期間などのサービス、タスク、申請、および工数関連の情報が含まれています。 カスタム レポート パッケージは、標準パッケージと次の重要な点で異なります。

  • カスタム レポート パッケージには、事前に作成されたレポートや KPI が含まれていません。 アドホック レポートおよびクエリー用に限定されます。
  • カスタム レポート パッケージを使用すると、フォームベースのデータにアクセスできます。これは、ユーザ設定のサービス フォームに表示され、入力されたディクショナリおよび属性から取得されたデータです。
  • カスタム レポート パッケージは、異なるタイプのデータ間の関係を保持する柔軟なデータ モデルであるディメンション モデルとして分類され、アドホック レポートおよびクエリーの作成を支援します。 このモデルについて詳しくは、「カスタム レポートの作成」を参照してください。

メトリックと属性

メトリックとは、集約できる数量です。 これは、IT サービスのオーダー、提供の傾向および問題を特定して分析するために使用可能なデータを提供する手段です。

メトリックにより、以下のことが可能になります。

  • Service Catalog のアクティビティ、リソース使用状況、サービス提供パフォーマンスをモニタリングする
  • サービス提供のパフォーマンスに関する問題を理解して解決するための根本原因分析を行う

データ マート内のメトリックと属性は、次の表で説明する計算を使用して取得されます。

表 1 メトリックおよび属性の表

メトリック

説明

サービス ボリューム

定義された期間内のサービス要求の合計数として計算されます。

特定のレポートに応じて、このメトリックは、完了した要求またはさまざまな状態(進行中、キャンセル済みなど)の要求を具体的に意味します。

サービス コスト

特定のサービスに対して設定された価格から導き出されます。 価格 X 単位は、要求ごとに動的に調整できます。

サービス開始日または開始時刻

サービスの STARTEDATE および STARTEDDATETIME には、最初にカスタマーがサービス要求を送信した時間が設定されます。 承認が完了し、提供が開始されるとすぐに、STARTDATE 値および STARTEDDATTME 値が更新されます。 これは、STARTEDATE(TIME)が承認の完了前には要求が送信された時間を参照し、承認の完了後には配信が開始された日時を参照することを意味します。 標準対応とタスク期日に関するすべての計算には、実際の提供計画の開始日が使用されます。

タスク ボリューム 承認タスクまたは提供計画タスクの合計数。 承認タスクまたは提供計画タスクの合計数として計算されます。
オンタイム % タスクが完了した時刻(CompletedDateTime)を、タスクが完了する予定の時刻(ScheduledDateTime)と比べることで、タスクが期日どおりであることを判断します。 この計算には期間(実際またはデフォルトの期間)が直接使用されませんが、期限となる日時を最初に計算する際には、当然のこととして期間が使用されました。
  • 計算された期日どおりまたは期日前に完了したサービスまたはタスクの割合。
  • カスタマーが [注文(Order)] ボタンをクリックした時点で、Service Catalog はすべてのタスクの期日を計算します。
  • タスクの期日はそのタスクに設定されている時間に基づいて計算されます。 これは、そのタスクの運用レベル契約(OLA)です。
  • サービス期日は、そのサービスの提供計画で最後のタスクの期限となっている日付です。
  • これは、そのサービスのサービス レベル契約(SLA)です。
  • 提供計画では複数の遅延タスクを許容できます。タスクが遅れていても、その SAL を達成することは可能です。
標準対応 % 設定された期間内に完了したサービスまたはタスクの割合。
タスク期間

承認タスクまたは提供計画タスクの開始から終了までの経過時間(時間単位)。

タスクまたは提供計画タスク。 タスク期間は、実行者のカレンダーに基づく作業時間で算出されます。 レポートでは、期間は時間単位で表示されます。

タスクベースのファクト テーブルでは、タスク期間を測定する 3 つの方法があります。
  • ActualDuration は、カスタマーのカレンダーに従って、タスクの実行に要した作業経過時間数を測定します。
  • PerformerActualDuration は、実行者のカレンダーに従って、タスクの実行に要した作業経過時間数を測定します。
  • DefaultDuration はサービス設計者によって指定される数値で、タスクに要する時間を指定します。
たとえば、次の前提があるとします。
  • 実行者のカレンダーでは 1 日 9 時間の作業日が指定されている
  • タスクは月曜日(作業日)の午前 9 時にアクティブになった
  • 実行者は次の日の午前 10 時にタスクを完了した

この場合、PerformerActualDuration は 10 時間になります。

計画上の工数 特定の計画タスクの [工数(Effort)] フィールドに設定された時間から導き出されます(時間単位で計測)。
実際の工数 特定のタスクに対してタスクの実行者によって入力された時間([工数(Effort)] エントリ)から計算されます
計画の有効性 設定された作業時間内に完了したタスクの割合として計算されます。
タスクの標準対応 %

実行者の実際の期間(タスクが開始された時刻からタスクが完了としてマークされた時刻までの作業時間数)を、タスクに指定されたデフォルトの期間と比べることで、タスクが運用レベル契約(OLA)を満たしていることを判断します。 実際の期間がデフォルトの期間よりも短い場合、タスクは条件を満たしたことになります(StandardComplianceFlag は 1 になります)。

設定された期間内に完了したサービスまたはタスクの割合。 標準対応 % は、標準期間またはタスク期間のいずれかを使用して計算されます。

経過時間のパフォーマンスからオンタイム パフォーマンスを切り分けるために、根本原因分析で使用します。

以前のタスクの完了日に基づき、個々のタスクがその OLA を違反していても、計画上の期間内に実行されるという場合もあります。

サービスの標準対応 %

すべてのコンポーネント タスクの実際の期間を合計し、この合計をサービスに指定されたデフォルトの期間と比べることで、サービスがそのサービス レベル契約(SLA)を満たしていることを判断します。 (デフォルトの期間は、サービス設計者がサービスの [一般(General)] タブで設定する [標準期間(Standard Duration)] です)。 実際の期間がデフォルトの期間よりも短い場合、サービスは条件を満たしたことになります(StandardComplianceFlag は 1 になります)。

サービスのデフォルト期間は手動で入力および管理され、サービスのコンポーネント タスクに対する検証は実施されません。 サービス設計者はデフォルトの期間を確認し、サービスに対して予想される実行タスクとその期間について、デフォルトのワークフローをデフォルトの期間に正しく反映させる必要があります。

タスク カウント 個々のタスク レベルでは、この値は 1 または 0 になります。 たとえば、メトリックの名前が完了済みオンタイム タスク数である場合、期日どおりに完了したタスクのカウントは 1 になります。 進行中のタスクの値は 0 になります。 タスクをグループにまとめている場合、すべてのカウントが集計されるので、カウントは、期日どおりに完了したタスクの合計数になります。
完了済みオンタイム % または標準対応 %

これらのパーセンテージは、値が 0 または 100 の個々のタスク レベルで示されます。 タスクをグループにまとめている場合、パーセンテージは平均化されて、タスク グループ全体のオンタイム % または標準対応 % が示されます。

遅延未完了タスク カウント

このカウントは、個々のタスク レベルで割り当てられます。 タスクが遅延しているか、進行中の状態にある場合、その値は 1 になります。 そうでない場合は、値は 0 になります。 タスクのグループのカウントを集計することで、そのうちいくつのタスクが遅延または進行中であるかを確認できます。 レポートでは、カウントはデフォルトで合計されます。 一般に、遅延未完了タスク カウントの値が大きい場合、それは提供プロセスに問題があることを意味し、カスタマーの不満につながります。

タスクの再スケジュール

タスクが再スケジュールされる場合の動作は、次のとおりです。

  • タスクの新しい(再スケジュールされた)期日は、そのタスクの期日完了判断の計算に使用されます。
  • サービスの期日および期日完了判断の計算には影響ありません。
  • タスクの新しい期間は、タスクの標準対応判断の計算に使用されます。
  • タスクの新しい期間は、サービスの標準対応判断の計算には使用されません。

サービス ボリュームの測定:カスタマーとは

多くのカスタマー サービスの実装方法のように、サービス提供のエンド カスタマーである個人の名前は、サービスのオーダー フォームに保存されています。 この情報は、標準レポート パッケージおよびその事前に作成されたレポート内からはアクセスできません。 このため、サービス提供のカスタマーを登録するには、2 つのオプションがあります。

  • 多くのレポートが、[CUSTOMERFIRSTNAME] および [CUSTOMERLASTNAME] フィールドを参照しています。 サービスのエンド カスタマーがオーダー フォームに保存されている場合、これらのフィールドはサービスを要求した個人を参照していますが、この個人を対象にサービスが実行されたとは限りません。 一方で、これが個人をカスタマーとして識別するための唯一のオプションです。
  • コストが割り当てられている場合、[ORGANIZATIONALUNITNAME] フィールドは、サービス提供に対する請求先の組織単位を参照します。 これは、カスタマーとは誰かについての別の考え方です。

カスタマーに基づいて、サービス提供オプションを選択できます。

タスク提供パフォーマンスの測定

ここでは、ユーザのパフォーマンスを測定する方法について説明します。

個人のパフォーマンスの測定

タスクは個人に割り当てるか、または個人が作業を引き出せるキューに割り当てられます。 標準レポート パッケージおよび事前に作成されたレポートで使用できるデータ(特に、DM_SERVICETASKDETAIL および DM_AUTHORIZATIONTASKDETAIL 内の [PERFORMERID]、[PERFORMERFIRSTNAME]、[PERFORMERLASTNAME]、[PERFORMEROUID] および [PERFORMEROUNAME] フィールド)は、次の 3 つのいずれかの条件下で個人を参照できます。

  • タスクは直接その個人に割り当てられ、他の人はそのタスクの作業をしたことがない。
  • タスクはキューに割り当てられ、実行者だけがそのタスクの作業をしたことがある。
  • タスクはキューに割り当てられ、最後にそのタスクの作業を行ったのは実行者だが、他の人も以前に作業した可能性がある。 この場合、レポートにリストされた個人のパフォーマンスは、その個人だけのものではなく、以前にそのタスクに関わったすべての人の影響を受けます。 このため、名前を挙げられた個人のパフォーマンスを測定する公平な基準とはなりません。

最初の条件は、標準レポート パッケージのデータで判別できます。 しかし、2 番目、3 番目についてはその限りではありません。 これはつまり、個人のパフォーマンスの測定を意図したレポートが実際のパフォーマンスを公平に反映した結果となるのは、タスクの責任を共有しないという明確で一貫したルールをサービス チームが持っている場合に限られるということです。 このため、個人のパフォーマンスを測定する、事前に作成されたすべてのレポートに免責事項が表示されます。

使用する期間

サービス提供中に実行されたタスクの期間についての事前作成レポートは、尺度として PERFORMERACTUALDURATION を使用します。 この尺度では、実行者の作業カレンダーを考慮に入れるため、週末とその他業務外の時間はタスク作業時間に計上されません。 逆に、CUSTOMERDURATIONOFSERVICE を尺度とするとカスタマーのカレンダーが考慮に入れられるため、実行者作業の尺度としては不正確になります。

日付を使用する場合と 期日ベースで計算する場合

提供チームがタスク実行の優劣を評価する方法は 2 つあります。 両方とも有効ですが、意味合いや使用方法は異なります。

  • カスタマー対する約束(期日)比べてタスクれて このアセスメントを行う場合、レポートには尺度として TASKONTIMEFLAG、TASKDUEDATE、TASKCOMPLETEDDATE を含めます。 これは、絶対日付という条件から、キューまたはサービス チームがカスタマーへの約束を守れているかを判断するのに有効です。 ただし、個人のパフォーマンスを測る尺度としては適切ではありません。 サービスを実行する際に、A、B、C という個人が行う 3 つのタスクが必要だとします。 個人 C のパフォーマンスを測定する場合、個人 A や B の遅れのためにそれらのタスクが遅れてしまう場合があります。 そのため、この測定方法はチームやキュー全体のカスタマー サービスを評価する場合にだけ使用します。
  • このタスクこの種のタスク標準的な想定時間内に実行されている このアセスメントを行う場合、標準レポートでは尺度として TASKSTDCOMPLIANCEFLAG、TASKPROJECTEDDURATION、PERFORMERACTUALDURATION を使用します。 タスクの実行に費やされた実際の期間と、この種のタスクの標準プランの期間とを比較できます。 この方法のほうが、個々のチーム メンバーのパフォーマンス評価に適しています。期間に注目することで、上流作業のタスク パフォーマンスから切り離せるからです。あるタスクが、期日から見れば遅れて完了したものの、期間の長さから見れば標準的な期間かそれ未満だということは、十分にありえます。 これはつまり、ある人は自分の担当業務を適切に実行したものの、上流作業の影響で遅れてしまったことを示しています。

カスタマー中心の確実な測定制度には、両方の基準が必要です。 すべてをタスク期間ベースで考えるならば、実際には「内部基準さえ満たしていれば、カスタマーとの約束はどうでもよい」と言っていることになります。逆に、日付だけに注目していると、チーム メンバーのパフォーマンスを正確に把握できず、カスタマーに対するパフォーマンス向上のために必要となる効果的なリソース決定を行うことができません。

属性(Attributes)

レポート パッケージで使用されるディメンション属性は、Service Catalog OLTP データベースに保持されるデータから取得されます。 以下に、属性について要約します。

表 2 OLTP データベースからの属性

属性

説明

顧客*

サービスの受け手になる個人(本人が直接オーダーする場合と、カスタマーのためにサービスがオーダーされる場合がある)およびカスタマーのホーム組織単位

Billed*

サービスの課金対象組織。 オーダーが確認されるとき(要求を保存した後、送信よりも前)に [課金先:カスタマー(Bill To: Customer)] として別の組織が選択されない限り、サービスのカスタマーと同一です。[課金先:カスタマー(Bill To: Customer)] として選択可能なのは、[課金可能(Billable)] と指定された組織単位だけです。

Performer*

タスクを実行する人(および対応するホーム OU)。 詳細については、個人のパフォーマンスの測定を参照してください。