Cisco Prime Service Catalog 11.0 レポート ガイド
レポートの生成
レポートの生成

目次

レポートの生成

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

レポートを Excel 形式で表示するクライアント ブラウザの設定

レポートを Excel 形式で表示して、問題を報告することもできます。 Excel 画面は一瞬表示され、すぐに閉じます。 この問題に対処するには、Cognos Server URL をクライアント ブラウザのローカル イントラネット ゾーンに追加します。


    ステップ 1   クライアント ブラウザ ウィンドウを開きます。
    ステップ 2   [ツール(Tools)] > [インターネットオプション(Internet Options)] を選択します。
    ステップ 3   [セキュリティ(Security)] をクリックします。
    ステップ 4   ローカル イントラネット ゾーンを選択します。
    ステップ 5   [サイト(Sites)] をクリックします。
    ステップ 6   [詳細設定(Advanced)] をクリックします。
    ステップ 7   Cognos Server URL を入力します。
    (注)      Cognos Server URL を確認するには、いずれかの Excel 形式の表示機能を Reporting モジュールで実行してみて、自動的に閉じる前に一瞬表示されるウィンドウのタイトル バーに示されている URL を参照します。 この URL を入力する必要があります。 表示時間が短すぎて URL を確認できない場合、スクリーン キャプチャ アプリケーションをロードして、画面のスナップショットをとります。
    ステップ 8   [追加(Add)] をクリックします。

    レポートの表示に対するユーザ環境設定の変更

    Cognos では、レポートおよびフォルダの表示方法が 2 つあり、各ページの右上のアイコンによって表されています。 選択したビューが強調表示されます。



    「詳細ビュー」には、各レポートの簡単な説明が表示されます。



    「リスト ビュー」がデフォルトのビューです。 レポート、フォルダ、およびそれらの内容を十分理解した後は、このビューに切り替えることを推奨します。このビューでは、次に示すように現在のフォルダの内容が単純にリスト表示されます。

    図 1. リスト ビュー

    このビューを手動で設定する代わりに、[環境設定(Preferences)] ページを使用して、Reporting モジュールの使用時に常に使用する環境設定を行えます。 環境設定を行うには、メニュー バーの右上の [マイエリア(My Area)] リンクをクリックして、[自分の環境設定(My Preferences)] をクリックします。

    図 2. [マイエリア(My Area)]

    [環境設定の設定(Set Preferences)] ページの [一般(General)] タブが表示されます。

    ページの上部にあるエントリを使用して、デフォルト ビュー(リスト ビューまたは詳細ビュー)を変更したり、そのビューをさらにカスタマイズできます。

    図 3. [自分の環境設定(My Preferences)] の [一般(General)] タブ

    ページの下部にあるエントリは、ユーザの場所/ロケールに関係しています。 時間帯はレポートのスケジュールを設定するときに使用されます。 デフォルトの時間帯は、レポート サーバがある場所の時間帯です。 分散型の実装では、実行するレポートのスケジュールを容易に設定するために、ユーザの現在の場所に時間帯を設定する必要があります。

    図 4. [自分の環境設定(My Preferences)] の [一般(General)] タブの地域オプション

    英語以外のフォーム データまたはファクト テーブルの内容の表示は現時点ではサポートされていません。 製品およびコンテンツの言語は、デフォルト言語である英語に設定する必要があります。

    事前に作成されたレポートのインベントリ

    次の表に、Service Catalog レポート(最上位のパブリック フォルダ [サービスパフォーマンスレポート(Service Performance Reports)] で入手可能)、および各レポートが格納されているフォルダをまとめます。

    「サービス承認(Service Authorization)」および「サービス提供(Service Delivery)」レポートには、それぞれ承認およびサービスの提供の時点で開始された追加タスクが含まれます。 これらのレポートには、要求の提供をキャンセルすることによって、ユーザまたはサービス チーム マネージャによってキャンセルされた要求の一部となっているタスクは含まれません。

    表 1 Service Catalog レポートの表

    レポートのタイトル

    フォルダ

    説明

    実行者別要求エージング(Aging of Requests by Performer)

    日次要求管理(Daily Request Management)

    個人の未完了タスク数および遅延タスク数の調査またはレポートに有効

    キュー別要求エージング(Aging of Requests by Queue)

    日次要求管理(Daily Request Management)

    キューにある未完了タスク数および遅延タスク数の調査またはレポートに有効

    承認:カスタマー別オンタイムパーセンテージ(Authorization: On-time % by Customer)

    サービス承認パフォーマンス(Service Authorization Performance)

    カスタマー(OU)別のオンタイム承認パフォーマンスの調査またはレポートに有効

    承認:実行者別オンタイムパーセンテージ(Authorization: On-time % by Performer)

    サービス承認パフォーマンス(Service Authorization Performance)

    個人別のオンタイム承認パフォーマンスの調査またはレポートに有効

    承認:キュー別オンタイムパーセンテージ(Authorization: On-time % by Queue)

    サービス承認パフォーマンス(Service Authorization Performance)

    キュー別のオンタイム承認パフォーマンスの調査またはレポートに有効

    ディクショナリ別サービス(Services by Dictionary)

    サービス設計詳細(Service Design Details)

    ディクショナリの使用の管理に関する管理レポート

    役職(Functional Positions)

    人、ロール、グループ(People, Roles & Groups)

    すべての役職をリスト表示する管理レポート

    組織単位別グループ(Groups by Organizational Unit)

    人、ロール、グループ(People, Roles & Groups)

    グループをリスト表示し、各グループが所属する組織単位を示す管理レポート

    人員別グループ(Groups by People)

    人、ロール、グループ(People, Roles & Groups)

    人員をリスト表示し、各人員が所属するグループを示す管理レポート

    グループ別組織単位(Organizational Units by Group)

    人、ロール、グループ(People, Roles & Groups)

    グループとその組織単位に関する管理レポート

    人員別組織単位(Organizational Units by People)

    人、ロール、グループ(People, Roles & Groups)

    人員とその組織単位に関する管理レポート

    キュー別組織単位(Organizational Units by Queues)

    人、ロール、グループ(People, Roles & Groups)

    キューとその組織単位に関する管理レポート

    グループ別人員(People by Groups)

    人、ロール、グループ(People, Roles & Groups)

    人員とそのグループをリスト表示する管理レポート

    組織単位別人員(People by Organizational Unit)

    人、ロール、グループ(People, Roles & Groups)

    人員とその組織単位をリスト表示する管理レポート

    組織単位別キュー(Queues by Organizational Unit)

    人、ロール、グループ(People, Roles & Groups)

    キューを組織単位ごとにリスト表示する管理レポート

    サービス提供:実行者別オンタイムパーセンテージ(Service Delivery: On-time % by Performer)

    サービス提供パフォーマンス(Service Delivery Performance)

    作業の実行に関する個人のパフォーマンスの評価または比較に有効

    サービス提供:キュー別オンタイムパーセンテージ(Service Delivery: On-time % by Queue)

    サービス提供パフォーマンス(Service Delivery Performance)

    作業の実行に関するキューのパフォーマンスの評価または比較に有効

    サービス提供:サービス別オンタイムパーセンテージ(Service Delivery: On-time % by Service)

    サービス提供パフォーマンス(Service Delivery Performance)

    サービスとそれに関連するタスクのオンタイム パフォーマンスの評価に有効

    サービス価格設定の詳細(Service Pricing Details)

    サービス設計詳細(Service Design Details)

    サービスの価格設定情報の管理に関する管理レポート

    サービスボリューム:サービス別要求アクティビティ(Service Volume: Request Activity by Service)

    サービスボリュームおよびアクティビティ(Service Volumes & Activity)

    サービス グループ内のサービス要求アクティビティ合計の測定およびモニタリングに有効

    サービスボリューム:要求アクティビティの詳細(Service Volume: Request Activity Details)

    サービスボリュームおよびアクティビティ(Service Volumes & Activity)

    個々のサービス提供トランザクションのステータスの調査またはレポートに有効

    サービスボリューム:要求アクティビティの要約(Service Volume: Request Activity Summary)

    サービスボリュームおよびアクティビティ(Service Volumes & Activity)

    特定のレポート期間内のサービス要求アクティビティ合計の測定およびモニタリングに有効

    サービスボリューム:サービス別要求トレンド(Service Volume: Request Trend by Service)

    サービスボリュームおよびアクティビティ(Service Volumes & Activity)

    サービス グループおよびカレンダー四半期ごとのサービス要求アクティビティ トレンドの測定およびモニタリングに有効

    サービスチーム別サービス(Services by Service Team)

    サービス設計詳細(Service Design Details)

    確定した予算に対するサービスの支出の管理に有効

    レポートおよびクエリーの作成

    Query Studio および Report Studio を使用する際の詳細な手順については、IBM/Cognos から提供されているユーザ ガイドを参照してください。このガイドはベンダーの Web サイトから入手できます。 このセクションでは、Service Catalog データ マートと、クエリーおよびレポート作成者がこのデータ マートにアクセスするための使用するフレームワークに固有の懸念事項について説明します。

    いずれのツールでも、カスタム パッケージ内に公開されているクエリー サブジェクトおよびクエリー項目に同等にアクセスできます。 ページの左側にある [挿入可能オブジェクト(Insertable Objects)] ペインの項目を [Reporting] ペインにドラッグするだけで、レポートまたはクエリーを簡単に作成できます。 各項目がレポートに追加されるたびに、Cognos はレポート用のデータを取得する際に使用される、基礎となる SQL を自動的に調整します。 この調整を行うために、Cognos はデータ マートの公開に使用しているカスタム パッケージで定義されている関係を利用します。 このパッケージには、動的に定義されたディクショナリベースのディメンションとすべてのファクト テーブルとの間の関係が含まれています。 これらの関係はデータベースの内部結合を利用しています。(対応するファクト クエリー サブジェクトからの)タスクまたは申請に関する情報は、申請またはタスクによる適用先のサービスでディクショナリが使用されている場合のみ、ディクショナリベースの情報を含んだ状態でレポートに表示されます。

    特に新規ユーザにとって、Query Studio は Report Studio よりも簡単に使用できるツールであるため、まず Query Studio から使用することをお勧めします。 Query Studio で必要なレポートの機能を実装できない場合は、クエリーを保存してから、Report Studio で編集して拡張することができます。Query Studio で作成されたすべてのクエリーには Report Studio との上位互換性があります。

    特に、次のタイプの要件は Report Studio を使用して実装する必要があります。

    • 合計に対するパーセントを表示する必要があるレポート。たとえば、期日どおりに完了した、または期日より遅くなった特定タイプのタスクのパーセンテージなど。
    • ディクショナリ データを含めて申請を表示する必要があり、ディクショナリが使用されていなかった場合はサービスに対するディクショナリ データを空欄にしておく必要があるレポート。このレポートは Report Designer のマスター詳細レポートを利用して実装できます。
    • 複雑なフィルタを含むレポート。たとえば、レポートに含まれるデータに、条件によって異なるフィルタが適用されるレポートなど。 (Query Studio では、すべてのフィルタに論理 AND が適用されます。このため、レポートに含まれる行はすべての条件を満たす必要があります)。

    標準レポートの使用

    標準レポート パッケージには、非正規化ベース データ テーブルが含まれています。 これらのテーブルは、事前に作成されたレポートの基礎として、また KPI に入力するデータ概要テーブルを提供するために使用されます。

    これらのテーブルはそれぞれスタンドアロン エンティティです。新規レポートの作成や既存レポートの変更のためにテーブルを別のテーブルと結合させることはできません。 標準レポートに修正を加える必要がある場合、確実な方法は Service Catalog データ マートとカスタム レポート パッケージを使用して必要なレポートを最初から作成することです。 ここでは、一部のレポートでの実行方法のヒントを紹介します。クエリーの作成にはアドホック クエリー(Query Studio)を使用します。

    人、ロール、グループ

    [人、ロール、グループ(People, Roles, and Groups)] フォルダ内のレポートは、[組織(Organizations)] フォルダ(個人、グループ、組織単位)内のクエリー サブジェクトと Queue ディメンションを使用して複製できます。 レポートは非常に使いやすく、適切な項目をレポートに挿入して、必要に応じてグループ化することで生成できます。

    たとえば、「人員別組織単位(Organizational Units by People)」レポートの組織単位は次のようになります。

    図 5. サンプル レポート

    このレポートを作成するためのレポート定義(Query Studio の [ファイルの管理(Manage File)] から参照可能)は、次の図のようになります([Person Full Name] で指定したグループと「Search and Select」フィルタとして定義されたフィルタを使用)。

    図 6. 標準フィルタ オプションを使用したレポート定義

    同じクエリー項目が、異なるフィルタのセットで、「組織単位別人員(People by Organizational Unit)」レポートに使用されています。

    図 7. フィルタ オプションが変更されたレポート定義

    サービス設計詳細

    [人、ロール、グループ(People, Roles, and Groups)] フォルダ内のレポートと同じく、[サービス設計詳細(Service Design Details)] フォルダ内のレポートも簡単に生成できます。 Dictionary および Service ディメンションから必要な項目を選び、必要に応じてグループ化するだけです

    以下に、Ad-Hoc クエリーによって作成される [ディクショナリ別サービス(Services by Dictionary)] レポートの例を示します。

    図 8. サンプル ディクショナリ

    標準レポートの外観と動作を正確に複製するには、Report Designer で次のアクティビティを行う必要があります。

    • レポートのタイトルを左寄せに変更します。
    • プロンプト ページでディクショナリ用に Search-and-Select フィルタを含めます。

    要求管理

    [要求管理(Request Management)] フォルダには、2 つのエージング レポートが含まれ、遅延日数に基づいてタスクをバケットに振り分けます。 バケットは、1 ~ 3 日の遅れ、3 ~ 7 日の遅れ、1 ~ 2 週の遅れ、2 週間以上の遅れと定義されています。 レポートでは、遅延タスクがキュー別または実行者別のいずれかでグループ化されます。

    図 9. エージング レポート

    このレポートは、基本的にピボット レポートです。 ピボットの基準は、未完了タスクの寿命です。 このレポートを作成するには、次の手順に従います。

    • レポートの作業領域に、キュー組織、キュー名、Delivery Tasks ファクトのタスク名などの該当する属性やディメンションを配置します。
    • 現在の日付とタスク期日の差(日数)を求めて、タスクの寿命を計算します。
    • 4 つのエージング バケットのカスタム グループを設定します。
    • カスタム グループ(寿命)を基準としてレポートをピボットします。

    サービス ボリュームおよびアクティビティ

    サービス ボリュームおよびアクティビティに関するレポートは、特定の期間内に開始されたサービス要求の数と、それらの要求の現在のステータスについての情報の概要を示します。 以下に、[サービス ボリューム:サービス別要求アクティビティ(Service Volume: Request Activity by Service)] の一例を示します。

    図 10. サービス別要求アクティビティの例

    計算が複雑なので(要求のステータスに基づいて件数を集計)、このレポートは Report Designer で実装する必要があります。

    カスタム レポートの作成

    Advanced Reporting モジュールには、アドホック クエリーおよびアドホック レポートを作成する機能があります。 このモジュールには、次の 3 つのオプションがあります。

    • [ホーム(Home)] ページでは、[Service Catalog] ドロップダウン メニューから [Reporting] モジュールを選択することなく、ショートカットを使用して標準レポートを実行できます。
    • [Ad-Hoc Reports] タブでは、データ マートに対するクエリーを作成するための IBM Cognos Query Studio にアクセスできます。
    • [Report Designer] タブでは、データ マートに対する専門的な品質レポートを作成するための IBM Cognos Report Studio にアクセスできます。

    [Ad-Hoc Reports] オプションおよび [Report Designer] オプションにアクセスするには、ユーザに適切な権限が与えられている必要があります。

    この項では、Advanced Reporting モジュールにアクセスする方法および Service Catalog データ マートの内容と構造の詳細について説明します。

    Advanced Reporting モジュールへのアクセス

    Service Catalog のドロップダウン メニューから Advanced Reporting 機能を使用するには、Advanced Reporting モジュールを選択します。

    Advanced Reporting オプションのホーム ページには、事前に定義された 3 つのパブリック フォルダが表示されます。

    • [レポート(Reports)] フォルダには、Reporting モジュールの一部としてアクセスできる、事前作成レポートへの代替パスがあります。 カスタム設計されたレポート ビュー、および Ad-hoc Reports や Report Designer で作成された新しいレポートも、通常は [レポート(Reports)] フォルダのサブフォルダに格納されます。
    • 残りのフォルダ([カスタムレポートデータモデル(Custom Reports Data Model)]、[標準レポートデータパッケージ(Standard Reports Data Package)])は、Report Designer および Ad-Hoc Reporting で使用するパッケージです。これらのフォルダを使用して、Service Catalog データ マートに対するクエリーおよびレポートを作成できます。

    通常、Ad-Hoc Reports または Report Designer オプションに対応するタブをクリックします。 これらのオプションにより、それぞれ Cognos Query Studio および Report Studio コンポーネントが開始されます。 このとき、使用するレポート パッケージを 2 つの中から選択するように求められます。

    データ マートにアクセスするには、[カスタムレポートデータモデル(Custom Reports Data Model)] をクリックして選択します。 Report Designer を使用している場合は、作成するレポート タイプを指定するように求められます。 リストを指定します(これが、最も簡単に作成できるレポートのタイプです)。 Ad-Hoc Reports を使用している場合は、Query Studio が自動的に開き、リスト レポートが表示されます。 カスタム レポート パッケージは、左側のペインに「挿入可能オブジェクト(Insertable Objects)」というラベル付きで表示されます。

    データ マートはディメンション モデルとして設定されます。

    • ディメンション モデル内の基本トランザクション データはファクトと呼ばれます。 データ マートのファクトには、タスク、申請、および工数エントリが含まれます。 各ファクトには、複数の単位(数量)が含まれる場合があります。 たとえば、申請の推定処理時間は、実際の期間を示す 1 つの尺度になります。
    • 各ファクトは、1 つ以上のディメンション(関連するファクト内の行を選択またはフィルタリングするために使用できる説明属性)と関係しています。 たとえば、タスクベースのファクトを説明するディメンションには、タスクの実行者とその完了した日付が含まれます。 一方、ディメンションは通常、複数のファクト間で共有されます。 たとえば、サービス ディメンションはタスクと申請の両方を説明している場合があります。
    • 各ファクトはその関連するディメンションとともに、スター スキーマを構成します。
    • スター スキーマに加えて、カスタム レポート パッケージには、フォームベース、ディクショナリベース、およびサービスベースのデータについてユーザが策定する必要があるレポートおよびクエリーをすべてカバーする別のテーブル、およびサイトにおける組織構造が含まれます。

    ディメンションおよびファクトは、対応するフォルダ内にグループ化されています。 また、[組織(Organizations)] フォルダには、サイトで使用されている組織、グループ、および個人に関するデータが格納されます。 [サービスバンドル(Service Bundles)] フォルダには、サービス バンドルと、バンドルを構成するために親サービスに関連付けられた子サービスに関するデータが格納されます。

    図 11. カスタム レポート データ モデルのツリー ビュー



    フォルダを展開すると、すべてのディメンションとファクトが表示されます。 アイコンで示された各オブジェクトは、クエリー サブジェクトです。クエリー サブジェクトとは、関連する一連のフィールドまたはクエリー項目をグループ化したものです。 クエリー サブジェクトを展開すると、そのクエリー項目が表示されます。

    クエリー項目は、固有識別子、属性または測定基準/メトリックの場合があり、これは項目名の左側にアイコンで示されています。

    図 12. サービス ツリー ビュー



    属性



    メトリック

    メトリックとは、演算式で使用できる数値です。 項目をメトリックとして定義することで、レポートまたはクエリーに複数のレベルまたはグループが存在する場合に、項目の値を集約(平均、合計、計算など)して、レポートの合計や小計を算出できます。 また、メトリックは Report Designer で指定され、Cognos ツールで提供されている、さまざまな演算、分析、および割合の計算に使用できます。

    すべてのクエリー サブジェクト、および各サブジェクトを構成するクエリー項目とその説明のリストは、このセクションの最後の表に記載されています。

    寸法

    カスタム レポート パッケージには、次のタイプのディメンションが含まれます。

    • 静的ディメンションはすべてのインストールで利用でき、[ディメンション(Dimensions)] フォルダの直下にあります。 これらのディメンションは、カスタマー、実行者、日付などのタスクおよび申請に関連する情報を説明します。
    • [ディクショナリデータ(DictionaryData)] フォルダには、レポート可能として指定され、データ マートにロードされたディクショナリに基づくすべてのディメンションが存在します。 レポート可能な各ディクショナリは、[ディクショナリデータ(DictionaryData)] フォルダに配置されます。 ディクショナリの各クエリー サブジェクトには、各サービスまたはすべてのサービスにおいて非表示になっているかどうかに関係なく、ディクショナリのすべてのフィールドが含まれます。 任意のファクトに 1 つ以上のディクショナリ ディメンションを接続して、柔軟なレポート作成およびフィルタリング メカニズムを用意することができます。
    • [サービスデータ(ServiceData)] フォルダには、レポート可能として指定され、データ マートにロードされたすべてのサービスが含まれます。 サービスの各クエリー サブジェクトには、サービスごとの許容フィールド数を超過していない限り、サービスで使用されるすべてのディクショナリ内のすべてのフィールドが含まれます。許容フィールド数を超過している場合、ディクショナリおよびフィールドはサービスから除外されます。 厳密に言えば、サービスのクエリー サブジェクトはディメンションではありません。このため、レポート作成の目的でファクトと組み合わせないでください。 代わりに、サービスのクエリー サブジェクトをレポート オブジェクトとして使用することで、サービス内のすべてのディクショナリおよびフィールドに関するレポートを迅速に作成できます。
    • [サービスバンドル(Service Bundles)] フォルダには、すべてのサービス バンドルと、サービス バンドルに関連付けられた子サービスが含まれます。 パッケージで利用可能なファクトやディメンションに、これらのディメンションを接続することはできません。

    通常、ディメンションはファクト テーブルと組み合わせて使用され、ファクトに関するデータをクエリーやレポートに追加したり、詳細条件によってクエリーやレポートの出力をフィルタリングしたりできます。

    ファクトおよびスター スキーマ

    ここでは、ファクトおよびスター スキーマについて説明します。

    申請:ServiceRequestFact

    ServiceRequest ファクトには、申請および要求されたサービスに関するデータが保持されます。 ファクトに含まれている日付および期間属性はサービス要求で利用され、申請(複数のサービス要求を含むことができるショッピング カート)では利用されません。 このファクトには、パフォーマンスに関するメトリックが含まれます。これらのメトリックには、要求が SLA を満たしているかどうか、実際または推定の処理時間、要求に関するすべてのディメンションの情報(要求のイニシエータ、カスタマー、オーダーされたサービスに含まれているレポート可能なディクショナリなど)へのリンクなどがあります。

    次に、ServiceRequest ファクトと関連するディメンションを示すスター スキーマ図を示します。

    図 13. ServiceRequest ファクトのスター スキーマ図

    タスクベースのファクト

    Service Catalog データ マートには、タスクベースのファクトの 5 つのビューがあります。 これらのビューの 2 つ(RequisitionTaskFact および ServiceTaskFact)は、主に以前のバージョンの Advanced Reporting との下位互換性を保つために提供されています。 これらのビューは自由に使用できますが、多くのレポートで役立つ一部のメトリックまたは計算が含まれていません。

    各ビューは特定のタスク セットをグループ化することで最適化されています。 タスクを調査する必要があるレポートおよびクエリーは、レポートの要件に最も合うタスクベースのファクトに基づいている場合に最高のパフォーマンスを発揮します。

    次に、タスクベースのファクトの概要を示します。

    表 2 タスクベースのファクト

    ファクト

    使用方法/説明

    すべてのタスク

    サービス要求の履行中に実行されるすべてのタスク。

    承認タスク

    すべての承認およびレビュー タスク。

    提供タスク

    追加タスクを含む、すべての提供タスク。

    RequisitionTask ファクト

    申請レベルで実行され、各サービス タスク レベルでは実行されないすべてのタスク。 これらのタスクには、ファイナンシャル承認、部門承認、および部門レビューが含まれます。 サイトがこれらの承認タイプを使用してない場合、このファクト テーブルは空になります。 このクエリー サブジェクトは、主に以前のバージョンの Service Catalog データ マートとの下位互換性を保つために提供されています。

    ServiceTask ファクト

    サービスレベル タスクに関するデータ。 これらには、サービス グループ承認とレビュー、サービス提供タスク、および追加タスクが含まれます。 このクエリー サブジェクトは、主に以前のバージョンの Service Catalog データ マートとの下位互換性を保つために提供されています。

    レポートやクエリーを作成するときは、レポートに含まれるタスクのタイプに最も合う内容のファクト テーブルを常に使用してください。 次の表に、ファクト テーブルの内容の概要を示します。

    表 3 ファクト テーブル

    ファイナンシャル承認

    部門承認

    部門レビュー

    サービス グループ

    許可

    サービス グループ

    レビュー

    提供タスク

    追加タスク

    すべてのタスク

    承認タスク

    提供タスク

    ServiceTask ファクト

    RequisitionTask ファクト

    RequisitionTask ファクトに関係しない「サービス」を除く、すべてのタスクベースのファクトが同じディメンションに関連しています。 次に、関係を示すスター スキーマ図を示します。

    図 14. タスクベースのスター スキーマ図

    ServiceTaskFact および RequisitionTaskFact の両ファクトは非推奨となりました。 レポート設計者は他のファクトを使用して、すべてのカスタム レポートを作成することを推奨します。

    工数費用:TaskEffortEntry ファクト

    TaskEffortEntry ファクトは、各タスクの所要工数に関するデータを保持します。 工数エントリは、人件費や材料などのカテゴリ別に利用できます。 一部の実装では工数エントリが不要であるため、このファクトで利用できるデータがない場合があります。

    組織

    [組織(Organizations)] フォルダには、サイトで設定されているグループ、組織、および個人に関する情報が含まれます。 ディメンション データやファクト データにこのフォルダ内のクエリー サブジェクトを接続することはできません。クエリー サブジェクト同士の接続のみ可能です。 対応するクエリー項目は、[ディメンション(Dimensions)] フォルダおよび [ファクト(Facts)] フォルダ内のクエリー サブジェクトにあります。

    Data Mart ディメンション

    この項の表で、カスタム レポート パッケージの [ディメンション(Dimensions)] フォルダにあるすべてのクエリー項目(ファクトとディメンションの両方の属性)の概要を示します。 このリストには、ディクショナリベースおよびサービスベースのフォーム データは含まれていません。それらのフォーム データは当然、サイトごとに異なります。

    カスタマー

    Customer ディメンションは、オーダーされたサービスの受信者について説明しています。

    ディレクトリ統合の一環として Person 属性へのカスタム マッピングが適用されている場合、このクエリー サブジェクトを構成するクエリー項目の動作は変更される場合があります。 次に記載されている説明は、Organization Designer で想定されるデフォルトです。 これらのフィールドの一部は、特定のサイトで使用されていない場合には空欄になる場合があります。

    表 4 Customer クエリー テーブル

    クエリー項目

    説明

    CustomerID

    カスタマー ID

    Customer Full Name

    カスタマーの氏名(First Name Last Name 形式)

    CustomerFirstName

    カスタマーの名

    CustomerLastName

    カスタマーの姓

    CustomerOUID

    カスタマーのホーム OU の組織単位 ID

    CustomerOUName

    カスタマーのホーム組織単位の名前

    CustomerBuilding

    カスタマーが位置している建造物

    CustomerBuildingLevel

    カスタマーが位置している建造物の中での高さまたは階数

    CustomerOffice

    カスタマーのオフィス

    CustomerCubic

    カスタマーの仕事スペースの番号

    CustomerStreet1

    カスタマーの住所の 1 行目

    CustomerStreet2

    カスタマーの住所の 2 行目

    CustomerCity

    カスタマーが位置している市区町村

    CustomerStateProvince

    カスタマーが位置している都道府県

    CustomerZip

    カスタマーの郵便番号

    CustomerCountry

    カスタマーが位置している国

    CustomerLoginName

    カスタマーのログイン名

    CustomerEmailAddress

    カスタマーの電子メール アドレス

    職場の電話

    カスタマーの業務用電話

    Cust_SupervisorID

    カスタマーの上司の ID

    Supervisor Full Name

    カスタマーの上司の氏名(First Name Last Name 形式)

    Cust_SupervisorFirstName

    カスタマーの上司の名

    Cust_SupervisorLastName

    カスタマーの上司の姓

    Cust_SupervisorEmail

    カスタマーの上司の電子メール アドレス

    Cust_SupervisorLoginName

    カスタマーの上司のログイン名

    Customer Status

    カスタマーのステータス(有効な値は「Active」および「Inactive」)

    ディクショナリ

    Dictionary ディメンションは、フォーム フィールドが入力されたディクショナリについて説明するために使用できます。

    表 5 Dictionary クエリー テーブル

    クエリー項目

    説明

    DictionaryID

    ディクショナリ ID

    DictionaryName

    ディクショナリの名前

    DictionaryGroupID

    このディクショナリが属するディクショナリ グループの ID

    DictionaryGroupName

    ディクショナリ グループの名前

    DictionaryServiceItemFamily

    特定のディクショナリのサービス項目ファミリ名

    Is Reportable

    ディクショナリがレポート可能として指定されている(1)、または指定されていない(0)ことを示すフラグ レポート可能なディクショナリには、対応するクエリー サブジェクトが [ディクショナリデータ(DictionaryData)] フォルダの下に配置されます。

    キーワード

    Keyword ディメンションは、特定のサービスに関連付けられたキーワードを一覧表示するために使用できます。

    表 6 Keywords クエリー テーブル

    クエリー項目

    説明

    KeywordID

    キーワードの固有識別子

    Keyword

    カタログ ユーザがオーダーするサービスを検索するための 1 つ以上の単語

    実行者

    Performer ディメンションはタスクを実行する個人を説明します。 タスクには、提供タスク、追加タスク、承認タスクおよびレビュー タスクが含まれます。

    ディレクトリ統合プロセスの一環として Person 属性へのカスタム マッピングが適用されている場合、このクエリー サブジェクトを構成するクエリー項目の動作は変更される場合があります。 次に記載されている説明は、Organization Designer で想定されるデフォルトです。

    キュー(Queue)

    Queue ディメンションは、タスクが割り当てられているキューを説明します。

    表 7 キュー クエリー テーブル
    クエリー項目 説明
    QueueID タスクが割り当てられたキューの ID
    QueueName キューの名前
    Queue Status キューのステータス(「Active」または「Inactive」)
    QueueOUID キューを担当する組織単位の ID
    QueueOUName キューの組織単位の名前
    Work Phone キューの業務用電話
    Email Address キューの電子メール アドレス

    要求元(Requestor)

    Requestor ディメンションはサービスをオーダーした個人を説明します。

    ディレクトリ統合の一環として Person 属性へのカスタム マッピングが適用されている場合、このクエリー サブジェクトを構成するクエリー項目の動作は変更される場合があります。 次に記載されている説明は、想定されるデフォルトです。

    表 8 要求者クエリー テーブル

    クエリー項目

    説明

    RequestorID

    サービスを要求した個人の ID

    Requestor Full Name

    要求者の氏名(First Name Last Name 形式)

    RequestorFirstName

    要求者の名

    RequestorLastName

    要求者の姓

    Requestor Status

    要求者のステータス(「Active」または「Inactive」)

    Work Phone

    要求者の業務用電話

    RequestorOUID

    要求者のホーム OU の組織単位 ID

    RequestorOUName

    要求者のホーム OU の名前

    RequestorBuilding

    要求者がいる建造物の番号または名前

    RequestorBuildingLevel

    要求者の建造物の中での高さまたは階数

    RequestorOffice

    要求者のオフィス

    RequestorCubic

    要求者の仕事スペースの番号

    RequestorStreet1

    要求者の住所の 1 行目

    RequestorStreet2

    要求者の住所の 2 行目

    RequestorCity

    要求者がいる都市

    RequestorStateProvince

    要求者がいる州

    RequestorZip

    要求者の郵便番号

    RequestorCountry

    要求者がいる国

    RequestorLoginName

    要求者のログイン名

    RequestorEmailAddress

    要求者の電子メール アドレス

    Req_SupervisorID

    要求者の上司の ID

    Supervisor Full Name

    上司の氏名(First Name Last Name 形式)

    Req_SupervisorFirstName

    要求者の上司の名

    Req_SupervisorLastName

    要求者の上司の姓

    Req_SupervisorEmail

    要求者の上司の電子メール アドレス

    Req_SupervisorLoginName

    要求者の上司のログイン名

    サービス

    Service ディメンションには、申請でオーダーされるサービスや実行されるタスクの対象となるサービスに関連するデータを整理するための階層(サービス チーム、サービス グループ、サービス)が含まれます。 Service 属性は、ファクト データに条件を課したり、ファクト データをフィルタリングしたりするためのファクト テーブルと組み合わせて使用できます。

    表 9 サービス項目クエリー テーブル

    クエリー項目

    説明

    ServiceID

    サービス ID(Service ID)

    ServiceName

    サービスの名前

    説明

    サービスの簡単な説明

    ServiceGroupID

    サービスが属するサービス グループの ID

    ServiceGroupName

    サービスが属するサービス グループの名前

    ServiceTeamID

    サービスを担当するサービス チームの ID

    ServiceTeamName

    サービスを担当するサービス チームの名前

    ServiceStandardDuration

    サービス定義で指定されている標準期間

    ServiceDurationUnits

    表示されている標準期間の単位

    ServiceHoursPerBusDay

    1 営業日あたりの時間数

    EstimatedCost

    サービスの推定コスト

    PublicationDate

    サービスの公開日

    ExpirationDate

    サービスの有効期限日

    IsInactive

    サービスがアクティブ(0)または非アクティブ(1)であることを示すフラグ

    Is Reportable

    サービスがレポート可能として指定されている(1)、または指定されていない(0)ことを示すフラグ。 レポート可能なサービスには、対応するクエリー サブジェクトが [サービスデータ(ServiceData)] フォルダの下に配置されます。

    Is Orderable

    サービスがオーダー可能として指定されている(1)、または指定されていない(0)ことを示すフラグ

    Price

    サービスの集計価格

    Service Bundles

    Service Bundles クエリー サブジェクトでは、アプリケーション リポジトリ内のすべてのサービス バンドルにアクセスできます。

    表 10 Service Bundles クエリー テーブル

    クエリー項目

    説明

    Service Bundle ID

    サービス バンドルの固有識別子

    Service Bundle Name

    サービス バンドルの名前

    Description

    サービス バンドルの簡単な説明

    Service Group Name

    サービス バンドルが属するサービス グループの名前

    Service Team Name

    サービス バンドルを担当するサービス チームの名前

    Standard Duration

    サービス バンドル定義で指定されている標準期間

    Durations Units

    表示されている標準期間の単位

    Hours per Business Day

    1 営業日あたりの時間数

    Price

    サービス バンドルの価格

    Service Bundle Status

    サービス バンドルのステータス

    Is Reportable

    サービス バンドルがレポート可能として指定されている(1)、または指定されていない(0)ことを示すフラグ。 レポート可能なサービスには、対応するクエリー サブジェクトが [サービスデータ(ServiceData)] フォルダの下に配置されます。

    Is Orderable

    サービス バンドルがオーダー可能として指定されている(1)、または指定されていない(0)ことを示すフラグ

    TaskType

    TaskType ディメンションは、タスク タイプの説明を提供するために使用できます。

    表 11 TaskType テーブル

    クエリー項目

    説明

    TaskTypeID

    タスク タイプの ID

    TaskTypeName

    タスク タイプの説明

    タスク タイプは以下のとおりです。

    ID

    タスク タイプ(Task Type)

    0

    提供タスク(Delivery Task)

    1

    ファイナンシャル承認

    2

    部門レビュー

    3

    部門承認

    4

    サービス グループの承認

    5

    サービス グループ レビュー

    6

    提供用の追加タスク

    7

    承認用の追加タスク

    8

    レビュー用の追加タスク

    CalendarClosedDate

    CalendarClosedDate ディメンションは、申請やタスクが完了した日付に関するクエリーを構成するための階層を提供します。 完全な日付を選択し、式を使用して、任意の月や週などを抽出するよりも、このディメンション内のクエリー項目を使用する方が、より簡単に日付でフィルタリングまたはグループ化できます。

    表 12 CalendarClosedDate クエリー テーブル

    クエリー項目

    説明

    ClosedDateID

    タスクまたは申請が完了した日付(YYYYMMDD 形式。例:20081225)。

    Full Date

    日付を dd-Mon-yyyy 形式で入力します(例:25-Dec-2008)。

    Day Month Name

    月と日(例:Dec-25)。

    Week of Year

    1 年における週(Weekn-yy 形式。例:Week1-08)。

    Calendar Year Month

    暦年における月(yyyy-nn 形式。yyyy は 4 桁の年で、nn は 1 ~ 12 の数を表します。例:2008-12)。

    Calendar Year Quarter

    暦年における四半期(yyyy-Qn 形式。yyyy は 4 桁の年で、n は 1 ~ 4 の数を表します。例:2008-Q4)。

    ClosedWeekDay

    項目が完了した曜日(1=Sunday、7=Saturday)。

    Day of Week Name

    項目が完了した曜日(Sunday ~ Saturday)。

    ClosedDateWeekStartDate

    項目が完了した週の開始日(Sunday)。

    ClosedDateWeekEndDate

    項目が完了した週の終了日(Sunday)。

    ClosedDateMonth

    項目が完了した月。

    ClosedDateMonthName

    項目が完了した月名。

    ClosedDateQuarter

    項目が完了した暦四半期。

    ClosedDateYear

    項目が完了した暦年(YYYY)。

    CalendarDueDate

    CalendarDueDate ディメンションは、申請やタスクの期日に関するクエリーを構成するための階層を提供します。 CalendarClosedDate ディメンションでも同じ日付形式が利用できます。

    CalendarScheduledDate

    CalendarScheduledDate ディメンションは、スケジュールされた開始日を許可されているタスクが実際に開始するようにスケジュールされた日付に関するクエリーを構成するための階層を提供します。 明示的にスケジュールされた開始日が指定されていない場合、スケジュールされた日付は開始日と同じになります。

    CalendarClosedDate ディメンションでも同じ日付形式が利用できます。

    CalendarStartedDate

    CalendarStartedDate ディメンションは、申請やタスクが開始された日付に関するクエリーを構成するための階層を提供します。 これは実際の開始日を表します。

    CalendarClosedDate ディメンションでも同じ日付形式が利用できます。

    Data Mart ファクト

    [ファクト(Facts)] フォルダ内のクエリー サブジェクトは、アプリケーション サービス カタログを利用してログに記録されたタスクおよびサービス要求に関する情報を提供します。

    ServiceRequestFact(申請)

    ServiceRequestFact は、オーダーされたサービスに関する情報を提供します。 フォルダにより、オンタイム カウントと要求ステータス カウント用のメトリックがグループ化されています。

    表 13 ServiceRequestFact クエリー テーブル

    クエリー項目

    説明

    RequisitionEntryID

    サービス要求の固有 ID

    RequisitionID

    サービスが要求された申請(ショッピング カート)の固有 ID

    ServiceID

    サービスのサービス ID

    Service Bundle ID

    サービス バンドルのサービス ID

    Requestor ID

    サービス要求者(サービス要求のイニシエータ)の固有 ID

    Customer ID

    要求のカスタマー(受信者)の固有 ID

    Status

    サービス要求の現在のステータス

    Quantity

    要求されたサービスの数量

    Price

    サービスの価格

    Started Date

    サービス要求が開始された日付

    Due Date

    サービス要求の期日

    Closed Date

    サービス要求が完了した日付

    Started DateTime

    サービスが要求された日時

    Due DateTime

    サービス提供の期限となる日時

    Closed DateTime

    サービス要求が完了した日時

    Default Duration

    サービスの提供に必要とされる設定上の期間(時間単位で指定)

    ActualDuration

    サービスの提供に要した実際の期間

    ServiceOntimeFlag

    サービス要求が期日どおりに完了した(1)か、期日に遅れた(0)かを示すフラグ

    ServiceStandardComplianceFlag

    サービス要求の標準対応を示すフラグ

    Completed On-Time Request Count

    現在の要求が期日どおりに完了した場合は 1、完了しなかった場合はゼロ(0)になります。これらの数値は、要求がレポート上でグループ化されるときに自動的に合計されます

    Completed On-Time Percentage

    期日どおりに完了した要求のパーセンテージ

    Standard Compliance Percentage

    SLA を満たした状態で完了した要求のパーセンテージ

    Submitted Count

    送信された要求数。要求は送信されて初めてデータ マートに追加されるため、この数は常に要求数と一致します

    Cancelled Count

    ユーザによってキャンセルされた要求数

    Completed Count

    提供プランが完了した要求数

    Ongoing Count

    送信されたが完了していない要求数

    Rejected Count

    承認者によって拒否された要求数

    Delivery Cancelled Count

    サービス マネージャによって提供がキャンセルされた要求数

    Service Request Status

    サービス要求の現在のステータス

    Billed Organizational Unit

    サービスの課金先組織単位

    Submitted Date

    要求が送信された日付

    タスクベースのクエリー サブジェクト

    All Tasks、Authorizations Tasks、および Delivery Tasks ファクトのコンポーネント クエリー項目は同じです。

    • All Tasks は、サービス申請を処理するために実行されるすべての提供タスク、レビューおよび承認を含む、すべてのタスクに関する情報を提供します。
    • Delivery Tasks は、追加タスクを含む提供タスクに関する情報を提供します。
    • Authorization Tasks は、レビューおよび承認に関する情報を提供します。

    表 14 タスクベースのクエリー テーブル

    クエリー項目

    説明

    Task ID

    サービス タスク ID

    Task Name

    サービス タスクの名前。

    Display Order in Service

    サービスのワークフロー内でタスクが実行される順序

    Task Type ID

    タスクのタイプ ID

    Requisition ID

    タスクの対応する申請 ID

    Requisition Entry ID

    タスクの対応する申請エントリ ID

    Service Bundle ID

    このタスクが実行されるサービス バンドルの固有 ID(サービス バンドルが子サービスの一環として実行された場合)

    Service ID

    タスクの実行対象となるサービスの固有 ID。特定のサービスに関連していない申請レベルの承認の場合にはヌル(空欄)になります。

    Performer ID

    タスクを実行した実行者の固有 ID

    Queue ID

    タスクが割り当てられているキューの ID

    Status

    タスクの現在のステータス

    Started Date Time

    タスクが開始される(または開始された)日時

    Due Date Time

    タスクの期限となる(または期限だった)日時

    Completed Date Time

    タスクが完了する(または完了した)日時

    Scheduled Date Time

    タスクが完了する予定の(予定だった)日時

    Planned Effort (Hours)

    サービス定義内のタスクに指定されている計画上の工数

    Planned Duration (Hours)

    サービス設計者によって指定される、タスクを実行する設定上の期間(時間単位)

    Actual Duration (Hours)

    カスタマーのカレンダーに基づいてシステムで計算された、タスクの実行に要した実際の時間(時間単位)

    Performer’s Actual Duration (Hours)

    実行者のカレンダーに基づいてシステムで計算された、タスクの実行に要した実際の時間(時間単位)

    Completed Task Count

    タスクが完了したかどうかを示します。タスクが完了している場合は 1、完了していない場合は 0 になります。

    Completed On-Time Task Count

    タスクが期日どおりに完了したかどうかを示します。タスクがスケジュールされた完了日よりも前に完了した場合は 1、完了しなかった場合は 0 になります

    Completed On-Time Percentage

    期日どおりに完了したタスクのパーセンテージ。完了した各タスクでは、100 % または 0 % になります。タスクが集計されると計算が適用されます。

    Late Open Task Count

    期日より遅れており、まだ完了していないタスクの数

    Standard Compliance Percentage

    指定された期間内に完了したタスクのパーセンテージ

    RequisitionTaskFact

    RequisitionTaskFact は、サービス要求を処理するために実行される、申請レベルの承認および確認タスクに関する情報を提供します。 このクエリー サブジェクトはレガシー システムとの上位互換性を保つためだけに提供されています。必要に応じて、All Tasks、Service Delivery Tasks、Authorizations Tasks クエリー サブジェクトを使用してください。

    ServiceTaskFact

    ServiceTaskFact は、サービス申請を処理するために実行される配信タスク、追加タスク、サービス グループ承認およびサービス グループ レビューに関する情報を提供します。 このクエリー サブジェクトはレガシー システムとの上位互換性を保つためだけに提供されています。必要に応じて、All Tasks、Service Delivery Tasks、Authorizations Tasks クエリー サブジェクトを使用してください。

    TaskEffortEntryFact

    TaskEffortEntryFact は、タスクの実行に要した工数に関する情報を提供します。

    表 15 TaskType テーブル

    クエリー項目

    説明

    EffortEntryID

    工数エントリの固有 ID

    ServiceTaskID

    この工数を要したタスクを識別する固有 ID

    EnteredDate

    工数がログに記録された日付

    Description

    工数の説明

    Category

    工数を要したカテゴリ

    ContributorID

    工数エントリを要したタスクを実行した個人の個人 ID

    Contributor Full Name

    貢献者の氏名(First Name Last Name 形式)

    ContributorFirstName

    工数エントリを要したタスクを実行した個人の名

    ContributorLastName

    工数エントリを要したタスクを実行した個人の姓

    EffortQuantity

    要した工数の単位数

    EffortCost

    工数エントリの合計(拡張)コスト(単位コスト X 量)

    EffortUnitCost

    各工数単位の単価

    UnitType

    工数エントリの測定単位

    [組織(Organizations)] フォルダ

    [組織(Organizations)] フォルダには、組織、グループ、個人、およびこれらのエンティティ間の関係に関するレポートを作成できるクエリー サブジェクトが含まれます。 これらのクエリー サブジェクトをトランザクション(ファクト)データに接続することはできません。 代わりに、タスクまたはサービス要求のデータを含むレポートに組織情報や個人情報といった項目も含めるには、これらの情報を適切なディメンション(Customer、Performer、または Requestor)で使用してください。

    グループ

    グループは、一連の個人や組織用のコンテナーとなります。グループを使用することで、権限やタスクを個々のグループ メンバーに割り当てる代わりに、グループ単位で割り当てることができます。 グループのメンバーを表示するか、個人が関連付けられているグループを表示するために、レポートに Group および Person クエリー サブジェクトからの項目を含めることができます。

    表 16 Group クエリー テーブル

    クエリー項目

    説明

    Group Name

    グループの名前

    Group Status

    グループのステータス(Active または Inactive)

    Parent Group Name

    グループの親

    Description

    グループの説明

    Person

    Person クエリー サブジェクトでは、サービス要求の処理におけるロール(カスタマー、実行者、要求元)に関係なく、リポジトリ内のすべての個人にアクセスできます。

    表 17 Person クエリー テーブル

    クエリー項目

    説明

    Person ID

    サービスを要求した個人の ID

    Person Full Name

    個人の氏名(First Name Last Name 形式)

    First Name

    個人の名

    Last Name

    個人の姓

    Home Organization Unit Name

    個人のホーム OU の名前

    Building

    個人が位置している建造物の番号または名前

    BuildingLevel

    個人の建造物の中での高さまたは階数

    Office Number

    個人のオフィス

    Cubicle Number

    個人の仕事スペースの番号

    Street Address1

    個人の住所の 1 行目

    Street Address2

    個人の住所の 2 行目

    City

    個人が位置している市区町村

    State or Province

    個人が位置している都道府県

    Zip or Postal Code

    個人の郵便番号

    Country

    個人が位置している国

    Login Name

    個人のログイン名

    Email Address

    個人の電子メール アドレス

    Supervisor ID

    個人の上司の ID

    Supervisor Full Name

    上司の氏名(First Name Last Name 形式)

    Supervisor First Name

    個人の上司の名

    Supervisor Last Name

    個人の上司の姓

    Supervisor Email

    個人の上司の電子メール アドレス

    Supervisor LoginName

    個人の上司のログイン名

    組織

    Organizational Unit クエリー サブジェクトでは、リポジトリ内のすべての組織にアクセスできます。

    表 18 Organizational Unit クエリー テーブル

    クエリー項目

    説明

    Organizational Unit Name

    組織単位(OU)の名前

    Description

    OU の説明

    Organizational Unit Typ0e

    OU のタイプ(Service Team または Business Unit)

    Organizational Unit Status

    OU のステータス(Active または Inactive)

    Parent Organizational Unit

    OU の親(組織単位の階層が設定されている場合)

    [サービスバンドル(Service Bundle)] フォルダ

    [サービスバンドル(Service Bundle)] フォルダには、サービス バンドル、関連付けられている子サービス、およびこれらのエンティティ間の関係に関するレポートを作成するために使用できるクエリー サブジェクトが含まれています。 サービス バンドルは 1 つの親サービスと 1 つ以上の子サービスから構成されています。

    Service Bundles

    Service Bundles クエリー サブジェクトでは、アプリケーション リポジトリ内のすべてのサービス バンドルにアクセスできます。

    表 19 Service Bundles クエリー テーブル

    クエリー項目

    説明

    Service Bundle ID

    サービス バンドルの固有識別子

    Service Bundle Name

    サービス バンドルの名前

    Description

    サービス バンドルの簡単な説明

    Service Group Name

    サービス バンドルが属するサービス グループの名前

    Service Team Name

    サービス バンドルを担当するサービス チームの名前

    Standard Duration

    サービス バンドル定義で指定されている標準期間

    Durations Units

    表示されている標準期間の単位

    Hours per Business Day

    1 営業日あたりの時間数

    Price

    サービス バンドルの価格

    Service Bundle Status

    サービス バンドルのステータス

    Is Reportable

    サービス バンドルがレポート可能として指定されている(1)、または指定されていない(0)ことを示すフラグ。 レポート可能なサービスには、対応するクエリー サブジェクトが [サービスデータ(ServiceData)] フォルダの下に配置されます。

    Is Orderable

    サービス バンドルがオーダー可能として指定されている(1)、または指定されていない(0)ことを示すフラグ

    Service

    Service クエリー サブジェクトでは、サービス バンドルの一部であるすべての子サービスにアクセスできます。

    表 20 Service クエリー テーブル

    クエリー項目

    説明

    Service Bundle ID

    サービス バンドルの固有識別子

    Service ID

    サービス バンドルの親サービスの固有識別子

    Service Name

    サービスの名前

    Description

    サービスの簡単な説明

    Service Group Name

    サービスが属するサービス グループの名前

    Service Team Name

    サービスを担当するサービス チームの名前

    Standard Duration

    サービス定義で指定されている標準期間

    Durations Units

    表示されている標準期間の単位

    Hours per Business Day

    1 営業日あたりの時間数

    Price

    サービスの価格

    Display order in Bundle

    サービス バンドルの表示順序

    Service Status

    サービスのステータス

    Is Reportable

    サービスがレポート可能として指定されている(1)、または指定されていない(0)ことを示すフラグ。 レポート可能なサービスには、対応するクエリー サブジェクトが [サービスデータ(ServiceData)] フォルダの下に配置されます。

    Is Orderable

    サービスがオーダー可能として指定されている(1)、または指定されていない(0)ことを示すフラグ

    カスタム レポートおよびクエリーへのアクセス

    レポート設計者がカスタム レポートまたはクエリーを作成する際は、パブリック フォルダ([Reports] フォルダがルートのパブリック フォルダ)またはプライベート フォルダ([My Folder])のいずれかに保存できます。 プライベート フォルダに保存されているレポートは、そのレポートを作成した個人のみが実行およびアクセスできます。

    パブリック フォルダに保存されているレポートは、レポートへのアクセスが許可されるロールを割り当てられたすべての個人がアクセスおよび実行できます。 これらの継承された権限は Cognos の管理オプションで上書きできます。このオプションを使用すると、レポート管理者は標準ロールからレポートを実行する権限を削除し、レポートを実行するアクセス権限を持つ個人ロールまたはカスタム ロールにその権限を割り当てることができます。

    レポートは Reporting モジュールのフォルダから実行できるほか、ハイパーリンクからレポートにアクセスすることもできます。 サービス設計者は、アプリケーションのサービス説明、電子メール通知などの領域に適切なリンクを埋め込むことができます。 リンクの形式は次のとおりです。

    http://<CognosServer Name>/crn/cgi-bin/cognos.cgi?CAMNamespace=TrustedSignOn&b_action=xts.run &m=portal/report-viewer.xts&method=execute &m_obj=/content//report[@name='<ReportName>']

    詳細については、レポートの使用を参照してください。