Cisco Service Portal レポーティング ガイド リリース 9.3.2
Advanced Reporting データ マート
Advanced Reporting データ マート
発行日;2012/07/20 | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 2MB) | フィードバック

目次

Advanced Reporting データ マート

概要

この章の内容

Reporting および Advanced Reporting モジュール

Reporting

Advanced Reporting

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

概要

データ マート アーキテクチャ

Standard Reports Data Package

Custom Reports Data Package

Service Portfolio Reporting

データ マートの更新

Standard Reports Package

データベース テーブル

事前作成レポート

サービス KPI

Service Portal データ マート - Advanced Reporting

Request Center データ マート

Demand Center データ マート

レポートの実行

概要

レポート オプションへのアクセス

レポート

レポート タイトル バー

フォルダおよびレポート

レポートの実行

レポート ページ

レポート ビューの保存

レポート出力の保存

レポート出力の電子メール送信

その他のレポート オプション

ユーザ設定

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

Request Center レポート

Demand Center レポート

Request Center Advanced Reporting

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

ディメンション

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

要求:ServiceRequestFact

Task-Based ファクト

工数費用:TaskEffortEntry ファクト

Organizations

Data Mart ディメンション

Customer

Dictionary

Keyword

Performer

Queue

Requestor

Service

Service Bundles

TaskType

CalendarClosedDate

CalendarDueDate

CalendarScheduledDate

CalendarStartedDate

Data Mart ファクト

ServiceRequestFact(要求)

Task-Based クエリー サブジェクト

RequisitionTaskFact

ServiceTaskFact

TaskEffortEntryFact

[Organizations] フォルダ

Group

Person

Organizational Unit

[Service Bundle] フォルダ

Service Bundle

Service

メトリックと属性

タスク期間

タスク期日完了フラグ

タスク標準対応フラグ

サービス標準対応フラグ

サービス開始日時

タスクの再スケジュール

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

カスタム レポートおよびクエリーの実行

レポート作成におけるヒントおよびテクニック

要求およびタスクの日時

サービス設計とレポート作成に関するベスト プラクティス

項目を「レポート可能」にする効果

ディクショナリ

サービス

レポート可能にするオブジェクトの選択

ディクショナリ

サービス

Request Center データ マートの設定

ディクショナリおよびサービス テーブルの数

データ タイプの変換

ディクショナリおよびサービス テーブルのカラム数

文字フィールドの最大サイズ

計算の実行

ディクショナリ(およびサービス)の変更

レポート可能なディクショナリへのフィールドの追加

レポート可能な新しいディクショナリの追加

レポート可能なディクショナリからのフィールドの削除

レポート可能なディクショナリの削除

ディクショナリ名の変更

フィールド定義の変更

Service Bundle からの子サービスの削除

Demand Center Advanced Reporting

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

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

[Service Offerings] フォルダ

Service Offerings

Services

Start Dates

Periods

Objectives

Cost Drivers

Business Initiatives

Business Processes

Attributes

Cost Drivers for Service Offerings

Objectives for Service Offerings

Component Services for Service Offerings

[Service Agreements] フォルダ

Service Agreements

Accounts

Organizational Units

Start Dates

Service Offerings

Periods

Service Agreement Versions

Objectives

Services

Cost Drivers

Cost Drivers for Service Agreements

Objectives for Service Agreements

Component Services for Service Agreements

[Business Initiative Alignment] フォルダ

Service Offerings

Business Initiatives Attributes

Business Initiatives

[Business Process Alignment] フォルダ

Service Offerings

Business Process Attributes

Business Processes

主要業績評価指標(KPI)

Dashboards

KPI インベントリ

KPI 管理

Request Center メトリックおよび属性

メトリック

サービス量の測定:カスタマーとは

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

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

使用する期間

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

属性

標準レポート設計

人、ロール、グループ

サービス設計の詳細

要求管理

サービス量とアクティビティ

データ マートの管理

ロールベースのアクセス

Request Center データ マートのソース データ

サービス フォーム レポーティング メタデータ

DM_FDR_ETLDICTIONARYMETADATA

DM_FDR_DICTIONARYMETADATA

DM_FDR_ETLMETADATA

DM_FDR_ETLSERVICEMETADATA

DM_FDR_SERVICEMETADATA

動的定義ディメンション

DM_FDR_DICTIONARYTABLE_n

DM_FDR_SERVICETABLE_n

Request Center データ マート データベース オブジェクト

ファクトとディメンションの関係

組織データ内の関係

ファクト間の関係

Demand Center データ マート データベース オブジェクト

テーブル

ビュー

標準レポート パッケージの更新

Request Center データ マートの更新

カスタム レポート パッケージとサービス ポートフォリオ レポーティング

カスタム レポート パッケージのプロセス フロー

フォーム データ カスタム ETL

Data Manager ETL

Request Center データ マートのカスタマイズ

概要

この章では、Cisco Service Portal(Service Portal)に備えられている Reporting および Advanced Reporting 機能について説明します。

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

事前に作成されたレポート とは、一連の実稼動品質レポートで、サービス、要求、およびタスクそれぞれのレベルのパフォーマンスを分析します。

主要業績評価指標(KPI) とは、アプリケーション ポータルで表示できる一連のグラフであり、システム内のトレンドに関するデータへの即時アクセスを可能にします。

Ad-Hoc レポート を使用するとビジネス ユーザは、(タスク、サービス、および要求パフォーマンスに関する)標準レポートで使用できるデータだけでなく、サイトのサービス フォームに含まれているカスタム設計のディクショナリ内のフィールドのデータにも基づいてクエリーを作成できます。

Report Designer を使用するとビジネス ユーザは、要求、タスク、またはサービスに関連するデータだけでなく、サービスごとにカスタマイズされたサービスフォーム データ(個々のディクショナリおよびフィールド)も含むように標準レポートを変更したり新規レポートを作成したりできます。

Custom Java Provider を使用すると、Service Portal 個人プロファイル情報を Cognos 名前空間として使用できます。これにより、Service Portal に登録済みでレポート権限を管理者から割り当てられているすべてのユーザは、すべてのレポート ツールに対して、統合されたシングル サインオン アクセスが可能になります。

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

IBM Cognos 8 Connect により、Service Portal では Cognos レポートなどのレポート オブジェクトを表示できます。

IBM Cognos 8 では、実稼動品質レポートをビジネス ユーザおよび非テクニカル ユーザに対して提供します。このようなユーザは、Cognos 8 機能を使用してレポートの印刷または Office などのアプリケーションに適した形式で出力を保存できます。

IBM Cognos Query Studio (「Ad-Hoc レポート」としてユーザに提示される)により、ユーザはレポート データに対して Ad-Hoc クエリーを実行できます。

IBM Cognos Report Studio (「Report Designer」としてユーザに提示される)により、ユーザは既存のレポートを変更、または新規レポートを作成できます。これは、Service Portal データベースに格納されている異なるタイプ間のデータの関係を理解できるテクニカル ユーザまたはパワー ユーザにお勧めです。

IBM Cognos Data Manager はシスコのエンジニアが使用するツールで、トランザクション データベースからデータを抽出して専用のレポート環境にロードするプログラムを作成します。

IBM Cognos Framework Manager はシスコのエンジニアが使用し、Ad-Hoc レポートおよびクエリーのエンド ユーザが使用できる情報のデータ レベルおよびビジネス レベル ビューを定義します。

IBM Cognos Event Studio では、レポート データベース内のデータの値によってトリガーされるイベントを定義します。イベントが発生すると、電子メールや例外レポートの実行などの方法によってユーザに通知できます。アプリケーションには事前設定されたイベントはありませんが、Advanced Reporting ユーザはデータ マートの内容に基づいて独自のイベントを定義できます。

この章では、Cognos ツールセットの使い方の詳細については説明しません。代わりに、Service Portal のレポートおよびクエリー環境で提供されるデータについて、およびビジネス プロセスをサポートするためのレポート生成に Cognos ツールを使用する方法に焦点を当てます。Cognos ツールセットの詳細については、Cognos のトレーニング コースの履修を Service Portal ユーザに対して強くお勧めします。

この章の内容

 

説明

「概要」

この章の内容について説明します。

「レポートのアーキテクチャおよびコンポーネント」

Service Portal レポート ソリューションのコンポーネントについて説明します。

「レポートの実行」

Standard Reports Package の一部として提供されている事前に作成されたレポートの実行方法について説明し、レポート インベントリについても簡単に説明します。

「Request Center Advanced Reporting」

Custom Reports Package によって実装された Request Center データ マートについて、またフォーム データと要求およびタスク関連データを含むレポートの作成に使用できる Ad-Hoc レポートおよびクエリー機能について説明します。

「サービス設計とレポート作成に関するベスト プラクティス」

レポート可能ディクショナリやレポート可能サービスの設定、およびレポート可能オブジェクトの定義の変更に関するベスト プラクティスについて説明します。

「Demand Center Advanced Reporting」

Demand Center データ マートについて説明します。

「主要業績評価指標(KPI)」

主要業績評価指標について説明し、これらを Service Portal ダッシュボードに統合する方法について説明します。

「Request Center メトリックおよび属性」

レポート オプションで使用可能な測定および属性について説明し、サービス配信量およびタスク配信パフォーマンスを効果的に測定する方法についても説明します。

「標準レポート設計」

標準レポートおよび KPI の作成に使用するすべてのテーブルのデータベース設計について説明します。

「データ マートの管理」

Service Portal データ マートの管理および設定についての詳細を説明します。

Reporting および Advanced Reporting モジュール

Reporting および Advanced Reporting 機能は、別々に入手可能な 2 つのモジュールとしてパッケージされてライセンスされています。

Reporting

Reporting モジュールは、基本的な Request Center ライセンスにバンドルされています。Reporting モジュールでは、Request Center で処理されるサービス設計、組織エンティティ、およびトランザクション(要求およびタスク)に関する一連の事前に作成されたレポートを提供します。このモジュールでは、一連の主要業績評価指標(KPI)であるグラフも提供されます。これらは、各ユーザのレポート ダッシュボードで表示されるように設定できます。次の項では、Reporting モジュールによって提供される機能について説明します。

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

レポートの実行

主要業績評価指標(KPI)

Request Center メトリックおよび属性

標準レポート設計

Advanced Reporting

Advanced Reporting モジュールは、基本的な Request Center ライセンスへのアドオンとしてライセンス可能です。Advanced Reporting モジュールには、Request Center と Demand Center の両方のデータ マートと、これらのデータ マート内のデータに基づいて単純なクエリーおよびより複雑なレポートを作成するためのツールが含まれています。

次の項では、Advanced Reporting モジュールによって提供される機能について説明します。

Request Center Advanced Reporting

サービス設計とレポート作成に関するベスト プラクティス

Demand Center Advanced Reporting

Request Center メトリックおよび属性

データ マートの管理

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

概要

この項では、Service Portal レポート ソリューションのアーキテクチャについて説明します。ソリューション内での Cognos コンポーネントの使用方法およびそれぞれの役割について関心のあるユーザを対象読者とします。Standard Package で提供されている事前に作成されたレポート実行のための Service Portal レポート ソリューションの使用方法や、独自の Ad-Hoc レポートまたはクエリーの生成に主に関心のあるユーザはこの項を飛ばしても差し支えありません。

データ マート アーキテクチャ

Service Portal などのトランザクション システムが動作する同じ環境でユーザにレポートの実行を許可することは、一般的に「ベスト プラクティス」ではありません。レポート、Ad-Hoc クエリー、およびその他の詳細な分析を実行するためのリソース要件は、オンライン ユーザに適切に応答するトランザクション システムを実行するためのリソース要件とは大きく異なります。このため、レポートおよび詳細な分析の基盤を形成するデータは、トランザクション システムから抽出し、レポート専用に最適化された環境にロードするのが一般的です。

Service Portal のレポート専用環境は、2 つの「パッケージ」から構成されます。この章の残りの部分では、これらの内容および使用方法の詳細について説明します。

Standard Reports Data Package

Standard Reports Package は、事前に作成されたレポートおよび KPI をサポートしています。さまざまな出力オプションにより、タスク、サービス、および要求に基づく測定およびトレンドの情報が提供されます。また、個人、組織、サービス チーム、およびサービス グループを含む Service Portal データの構造に関するレポートも使用できます。事前に作成されたレポートで使用されるすべてのデータも Custom Reports パッケージで使用できます。将来的には、このパッケージは Custom Reports パッケージとマージされます。

Custom Reports Data Package

Custom Reports Data Package は、タスク、サービスおよび要求関連データに関する Ad-Hoc レポートを作成可能にする「ディメンション」モデルを提供します。Standard Reports パッケージで使用できる測定および属性に加えて、各サイトに設定されたカスタマイズされたサービス フォームにユーザが入力したデータも使用できます。この「Form Data Reporting」(FDR)により、サービス設計者が「レポート可能」として指定したすべてのディクショナリおよびサービスのすべての属性を把握できます。

Service Portfolio Reporting

Service Portfolio Reporting では、提供およびサービスなどの Demand Center データに関する Ad-Hoc レポートが作成可能です。

データ マートの更新

データ マートには、Extract-Transform-Load(ETL)プロセスで定期的にトランザクション システムからのデータがロードされている必要があります。つまり、データはトランザクション システムから抽出され、(オンライン トランザクション用ではなく)レポート用に最適な形式に変換されてから、データ マートにロードされます。

ETL プロセスは「差分」です。Service Portal は、トランザクション データベースの要素が変更または作成された時刻を記録します。最後にデータ マートが更新された後で変更または作成されたデータだけが次の ETL サイクルで処理されます。更新プロセスの実行中でも、ユーザは引き続きデータ マートにアクセスしたり、レポートを実行したりできます。しかし、レポートによっては応答時間に悪影響が及ぶ場合があります。ETL プロセスの実行が、トランザクション データベースの応答時間に及ぼす影響はまったくないか非常に限られています。

通常、更新プロセスは定期的な間隔で自動的に実行されるようにスケジュールを設定されています。データ マートが 24 時間ごとに、理想的にはユーザ アクティビティが制限されている期間に更新されるようにすることを推奨します。

ETL プロセスの一部として必要な実行ファイルおよびプロセス実行のスケジュール設定の詳細については、『Cisco Service Portal Installation Guide』に記載されています。このプロセスに関連する Cognos および Service Portal コンポーネントの詳細については、このマニュアルの「データ マートの管理」の項に記載されています。

Standard Reports Package

Standard Reports Package は、Service Portal で提供されている一連の事前に作成されたレポートおよび主要業績評価指標(KPI)ならびにこれらのレポート オブジェクトの生成をサポートするために必要なデータベース テーブルから構成されます。これらの事前に作成されたオブジェクトは、動作データから生成されるレポートに対する多くの営業部門要件を満たします。

データベース テーブル

Standard Reports Package をサポートするデータベースには、詳細テーブルと要約テーブルの両方が含まれます。

詳細テーブルは、データベースの「非正規化」ビューを提供します。各テーブルには、対応するレポートに表示されるすべてのデータがあります。つまり、実行する各レポートが最適化されているため、レポートがルックアップ テーブルで関連データにアクセスする必要はありません。しかしながら、テーブル間で関係がないため、これらのテーブルを他のテーブルとレポート内で結合できないことも意味します。各テーブルは、指定された詳細レベルの完全なビューであり、OLTP システムについての 1 つのタイプのファクトの非正規化ビューです。また、違う詳細レベルへのドリルアップまたはドリルダウンはできません。

要約テーブルには、集計または要約されたデータが含まれています。データを事前要約することによって、レポート要求への応答で、サマリー レポートがデータをリアルタイムで集計する必要がある場合に発生する処理遅延がなくなります。詳細テーブルの場合、各要約テーブルはその専用レポートまたは KPI に対してのみ使用される必要があります。Ad-Hoc レポート要件をサポートするため、要約テーブルを他のテーブルと結合できません。

事前作成レポート

Standard Reports Package に含まれる事前に作成されたレポートは、Report Studio ツールを使用して作成されて Reporting モジュールに含められています。これらのレポートは Service Portal に統合された IBM Cognos 8 を使用して実行されます。デフォルトのレポート表示形式は HTML に設定されていますが、この配信フォーマットおよび他のランタイム パラメータは、レポートの実行中に変更できます。レポート ソリューションに Report Designer が含まれている場合、ユーザは事前に作成されたレポートの定義を表示できます。また、必要に応じて、企業の要件をより満たすために定義を変更したり新規レポートを作成できます。

サービス KPI

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

Service Portal データ マート - Advanced Reporting

Advanced Reporting モジュールを使用すると、Service Portal データ マート(データは Request Center と Demand Center からキャプチャ)のデータからカスタム レポートおよびクエリーを作成できます。

Request Center データ マート

Request Center データ マートは、Custom Reports Data Model パッケージに基づいています。このパッケージによって、ユーザはデータ マートにアクセスできるようになります。データ マートには、タスクの実行者やタスクの期間などのサービス、タスク、要求、およびエフォート関連情報が含まれています。カスタム レポート パッケージは、標準パッケージと次の重要な点で異なります。

カスタム レポート パッケージには、事前に作成されたレポートまたは KPI が含まれていません。Ad-Hoc レポートおよびクエリー用に限定されます。

カスタム レポート パッケージを使用すると、フォームベースのデータにアクセスできます。これは、ユーザ設定のサービス フォームに表示され、入力されたディクショナリおよび属性から取得されたデータです。

カスタム レポート パッケージは、異なるタイプのデータ間の関係を保持する柔軟なデータ モデルである「ディメンション モデル」で分類され、Ad-Hoc レポートおよびクエリーの作成を支援します。このモデルの詳細については、「Request Center Advanced Reporting」で説明されています。

Demand Center データ マート

Demand Center データ マートは、Service Portfolio Reporting パッケージに基づいています。このパッケージを使用すると、ユーザは提供サービスおよび契約関連情報を含むデータ マートにアクセスできます。カスタム レポート パッケージは、標準パッケージと次の重要な点で異なります。

Service Portfolio Reporting パッケージには、事前に作成されたレポートまたは KPI が含まれていません。Ad-Hoc レポートおよびクエリー用に限定されます。

Service Portfolio Reports パッケージは、異なるタイプのデータ間の関係を保持する柔軟なデータ モデルである「ディメンション モデル」で分類され、Ad-Hoc レポートおよびクエリーの作成を支援します。このモデルの詳細については、「Demand Center Advanced Reporting」の項で説明されています。

レポートの実行

概要

この項では、レポートの実行方法、および KPI を表示するために Service Portal ダッシュボードを設定する方法に関する基本的な情報について説明します。レポートの実行手順は、標準の(事前に作成された)レポートおよび Advanced Reporting オプションを使用して開発され、パブリックまたはプライベート フォルダに公開されたカスタム レポートの両方に適用されます。

レポート オプションへのアクセス

すべてのレポート オプションは、[Service Portal] メニューに統合されています。[Reporting] および [Advanced Reporting] オプションは、これらのオプションを実行する許可を与える権限がユーザに付与されている場合に、ユーザのドロップダウン メニューに表示されます。ロールベース アクセスの詳細については、「データ マートの管理」に記載されています。

[Reporting] オプションには、[Service Portal] メニューからアクセスできます。

 

[Reporting] メニュー オプションには、次のオプションがあります。

[Reports]:すべての事前に作成されたレポートを実行する機能、およびレポートの変更またはコピー、あるいは(各ユーザの権限に応じて)その両方を行う機能

[Dashboards]:指定した KPI を含めるように各ユーザのポータルに表示されるダッシュボードを設定する機能

レポート

次に示す Reports ホーム ページを表示するには、[Reporting] オプションを選択してから [Reports] タブを選択します。

 

レポート タイトル バー

[Reports] ページの上部にあるタイトル バーには、次の表にまとめたユーザ オプションがあります。詳細については、以降の項で説明します。

オプション
説明

 

現在のページを更新します。

 

レポートの名前に入力されたテキストを検索します。

 

[Home]:Reports ホーム ページに戻るか、現在のページをユーザのホーム ページに設定します。

 

[My Area]:ユーザの監視項目、環境設定、またはスケジュールを表示または変更します。

 

Event Studio(レポート管理者の場合は、Cognos Administration モジュール)を開始する、またはレポート ドリルダウンを定義します。

フォルダおよびレポート

[Public Folders] フォルダでは、すべてのレポート オプションが使用できます。ホーム ページには、Business Value Reports(Demand Center データ用)および Service Performance Reports(Request Center データ用)の最上位から 2 つのレポート フォルダが表示されます。

ページは、「List」ビューで最初は表示され、レポート オプションにアクセスできる [More...] リンクとともにフォルダのタイトルだけが表示されます。特に新規ユーザの場合、[Reporting] ページを「Details」ビューで表示して、各フォルダまたはレポートの簡単な説明を表示することによって、より一般的なオプションの一部をすぐに使えるようにした方が実用的になります。ビューを切り替えるには、ページの右上にあるアイコン バーの左から 2 番目の [Details View] アイコンを単にクリックします。(環境設定についての項で説明するとおり、表示および他の環境設定を保存できます。)

 

各フォルダ名は、ハイパーリンクで表示されます。このリンクをクリックすると、フォルダの内容が表示されます。フォルダには、フォルダとレポート自体の両方が含まれている場合があります。必要なレポートを見つけるために、フォルダをクリックしていくと、「ブレッド クラム」([Public Folders] タブの直下にある)がナビゲーション パスを反映するように更新されます。たとえば、次に示すように、「Authorization: On-time % by Customer」レポートは「Service Authorization Performance」フォルダ内にあります。

 

レポートの実行

必要なレポートが表示されるまで、レポート フォルダをドリルダウンします。レポート名をクリックして、レポートをデフォルト出力形式(HTML)で実行します。

また、次のレポート オプションがレポート名および [More] リンクの直下のアイコンから使用できます。

レポート オプション
説明

 

レポートのプロパティを変更します。レポート管理者([Public Folders] の場合)または [My Folders] のレポート ビューのオーナーだけが使用できます。

 

レポートの実行前にオプション ページを表示します。オプション ページでは、印刷出力形式の調整ができます。

 

以前保存されたレポートの出力を表示します。レポートに保存された出力がある場合だけ使用できます。

 

保存されたレポートの最新の出力を表示します。レポートに保存された出力がある場合だけ [More...] ページで使用できます。

 

レポートを Report Studio(Report Designer)で開いて、レポート定義を変更または確認します。Report Designer を実行する権限のあるレポート管理者またはレポート オーナーだけが使用できます。

 

レポートが自動的に実行されるようにスケジュールを設定します。レポート管理者またはレポート オーナーだけが使用できます。その他のユーザは、スケジュールを表示できます。

 

[More...] オプションからだけ使用できます。書き込み権限のある任意のフォルダにあるレポートへのショートカットを作成します。

 

レポートのビューを作成して、ユーザのプライベート フォルダに保存します。これにより、ユーザはレポートのプロパティの変更、レポートのスケジュールの設定、または出力バージョンの保存ができるようになります。

 

パブリック レポートまたはフォルダを変更できるのは、レポート管理者だけです。ただし、レポート ユーザは、レポートをプライベート フォルダにコピーするか、レポートのプライベート ビューを作成してから、レポートを操作できます。

 

[More...] オプションからだけ使用できます。ブラウザのお気に入りに現在のレポートへのブックマークを追加します。

レポートを実行すると、常にパラメータ画面が表示され、レポートに含めるデータの条件を指定できます。フィルタ条件は、レポートによって異なります。パラメータ画面は次の例のように表示されます。

 

1

レポートのタイトル

3

パラメータ

2

キーワード検索(すべての場合は %)

4

アクション ボタン

レポートを実行するには、次の手順に従います。


ステップ 1 レポートにすべての適用可能なデータを表示するように指定するには、「%」を入力します。レポートおよびレポートのフィルタ/パラメータに精通している場合は、ここに値を入力できますが、必須ではありません。「%」を入力すると、すべての使用可能なフィルタ オプションが下の [Results] ボックスに表示されます。たとえば、Service by Service Teams のレポートでは、[Results] ボックスにすべてのサービス チームのリストが表示されます。

ステップ 2 レポートの内容を指定するには、レポートに含める [Results](この場合はサービス チーム)を選択して、[Insert] ボタンをクリックします。これにより、これらのオプションが [Choices] ボックスに移動されます。アスタリスクは、最低でも 1 つの選択が必要なことを示しています。

ステップ 3 このレポートに対するオプション選択が完了したら、画面の下部の [Finish] ボタンがイネーブルになります。[Finish] をクリックして、レポートを実行します。

ステップ 4 または、レポートによっては複数のフィルタが必要になります。たとえば、人別に分類されたレポートの場合、まずレポートに表示する組織を指定してから、これらの組織中で必要な人を指定するように求められる可能性があります。この場合、[Next] および [Previous] ボタンはイネーブルになります。[Next] をクリックして次の一連の選択肢を表示し、[Results] から必要な項目を選択します。すべてのフィルタのパラメータが指定されると、[Finish] ボタンがイネーブルになります。[Finish] をクリックして、レポートを実行します。


 

レポート ページ

レポートは一連のページに表示されます。各ページの下部にあるハイパーリンクを使用すると、これらのページを移動できます。ページに表示される行数は、対応するレポート プロパティを設定することによって変更できます。レポート ページの上部にあるアイコン バーに使用できるオプションが表示されます。

 

これらのオプションを次の表にまとめます。詳細については、以降の項で説明します。

レポート オプション
説明

 

レポートを電子メールで送信する、レポート出力を保存する、またはレポートのビューを作成することによって、レポート出力を保存します。

 

レポートを再度実行します。

 

ドリルダウン/ドリルアップです。これらのリンクはイネーブルではありません。

 

このレポートに定義された任意の関連リンクに移動します。レポート管理者またはオーナーがリンクを追加できます。デフォルトでは何も定義されていません。

 

レポートの現在の出力形式を示しています。また、代替形式にレポートを戻すこともできます。デフォルト形式は HTML です。PDF、XML、および Excel 形式も使用できます。

 

このレポートにユーザのプライベート ページへのショートカットを追加する、またはユーザのブラウザでレポートへのブックマークを作成します。

 

このレポートの出力が保存されるたびに、電子メール アラートがユーザ(レポート オーナー)に送信されるように指定できます。以前保存されたレポート出力がある場合だけ使用できます。

 

Reports ホーム ページに戻ります。

 

このレポートを起動したページに戻ります。

レポートを選択したページに戻るには、ページの右上の [Return] をクリックします。レポートを再度実行するには、[Run] アイコンをクリックします。

レポート ビューの保存

「レポート ビュー」とは、レポートのコピーのことです。ユーザが編集権限を持つレポートに対してだけカスタマイズを適用できます。デフォルトでは、事前に作成されたレポートに対する編集権限を持つのはレポート管理者のみです。このため、レポートのプライベート コピーを作成して、主にユーザのカスタマイズを適用できるように、レポート ビューを作成します。一般的なカスタマイズでは、以前に入力したレポート フィルタ条件(パラメータ)の保存、レポートのスケジュールの設定(1 回または繰り返し実行)、レポート出力の以前実行したバージョンの保存、およびデフォルト出力形式などのレポート プロパティの変更ができます。

レポート ビューとしてレポートを保存するには、[Keep this version] をクリックしてから、[Save as Report View] をクリックします。レポート ビューを保存すると、自動的に現在のレポート出力が保存されます。

 

レポート出力の保存

レポートに対する編集権限を持つ場合、またはプライベート レポート ビューを作成した場合は、生成されたレポート出力を保存できます。レポート配信フォーマットは、レポートの実行時に [Run with options] を使用して設定するか、レポート プロパティの一部として設定できます。レポートを電子メールで送信するには、レポート出力が保存されている必要があります。レポート出力は、レポートが後で実行されるようにスケジュールを設定されている場合にも保存されています。

[View Saved Reports] アイコンは、保存されたレポート出力が存在する場合に、レポートに対して使用可能な一連のアイコンに追加されます。保存されたレポート出力は、レポートが実行された日時によって識別されます。[Manage versions] リンクを使用すると、不要になったバージョンを削除できます。

 

レポート プロパティには、各レポートの [Run history](保持する保存されたレポートの数)および [Report output versions](各保存されたレポートの異なる出力形式の数)に対するエントリが含まれます。

 

レポート出力の電子メール送信

使用可能な 2 つの電子メール配信オプションは、次のとおりです。

レポートを(添付ファイルとして)電子メールに含めます。これは、レポート プロパティが [Send the report to me] に設定されている場合のデフォルト動作であり、オプションは提供されません。

[Include a link to the report in the email]:受信者がレポートの実行権限を持つ Service Portal ユーザである必要があります。

レポートを実行する個人と追加の参加者の両方にレポート出力を電子メールで送信するには、複数の方法があります。

[Run with options] をクリックして、[Send me the report by email] を選択します。追加の受信者を指定するには、[advanced options] をクリックして、[Delivery] オプションの下で [Send the report by email] オプションの [edit the options] をクリックします。

レポートを実行して、[Keep this version] > [Email this report] をクリックします。

 

受信者はセミコロンで区切って直接入力するか、またはレポート ユーザのリストから選択できます。受信者を選択する場合は、次の手順に従います。

[Select the recipients...] をクリックします。[Select recipients (Navigate)] ページが表示されます。

 

[Show users in the list] をオンにして、ページの左側の [Available entries] のリストに表示される Service Portal 名前空間(ディレクトリ)をクリックします。

(関連付けられたレポート機能を持つ)ロールおよび(これらのロールのいずれかの権限を付与されている)個々のユーザのリストが [Available entries] カラムに表示されます。このリストを参照して電子メールの受信者を選択してから、[To]、[Cc]、または [Bcc] をクリックして受信者としてこれらのエントリを選択します。

または、特定のユーザを検索するには、ページの右上の [Search] リンクをクリックします。[Select recipients (Search)] ページが表示されます。

 

[Find text in:] オプションは、[Name field] のままにします。他のオプション(説明を含む)は、Service Portal ディレクトリでは動作しません。また、デフォルト以外の [Advanced] オプションでも一切動作せず、デフォルトが自動的に有効になります。

個人の名の全体または一部を入力し、[Search] をクリックします。指定した条件に一致するすべての人が表示され、受信者として選択可能になります。

その他のレポート オプション

その他の使用可能なレポート オプションでは、たとえば、レポートを PDF、HTML または Excel などのその他の出力形式で配信したり、定期的にレポートを実行するようにスケジュールを設定できます。これらのオプションの詳細については、IBM Cognos 8 に関する資料を参照してください。

ユーザ設定

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

 

Details View」は、各レポートの簡単な説明から構成されます。

 

List View」がデフォルトのビューです。レポート、フォルダ、およびそれらの内容に精通すると、このビューに切り替える必要が生じることがあります。このビューでは、次に示すように現在のフォルダの内容を単にリスト表示します。

 

このビューを手動で設定する代わりに、[Preferences] ページを使用して、Reporting モジュールの使用時に必ず使用する環境設定を設定できます。環境設定を設定するには、メニュー バーの右上の [My Area] リンクをクリックして、[My Preferences] をクリックします。

 

[Set Preferences] ページの [General] タブが表示されます。

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

 

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

 

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

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

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

Request Center レポート

Service Authorization および Service Delivery レポートには、それぞれ承認およびサービスの提供の時点で開始された Ad-Hoc タスクが含まれます。これらのレポートには、要求の配信をキャンセルするユーザまたはサービス チーム マネージャのいずれかによってキャンセルされた要求の一部であるタスクは含まれません。

レポートのタイトル
フォルダ
説明

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

確立した予算に対するサービスの支出の管理に効果的

Demand Center レポート

次の表に、Demand Center レポート(最上位のパブリック フォルダの Business Value Reports で入手可能)、および各レポートが格納されているフォルダをまとめます。

レポートのタイトル
フォルダ
説明

Agreements by Account

Service Level Agreements

組織単位/アカウントごとの契約リスト

Service Objectives by Agreement

Service Level Agreements

各契約のサービス目標

Variable Cost Report - Component Service by Agreement

Service Level Agreements

契約ごとに提供されるサービス

SLA Violations by Customer-Agreements in Force

Service Level Compliance

現在アクティブなすべての契約の SLA 違反

Service Portfolio Details

Service Portfolio Details

各サービス ポートフォリオの定義の詳細

Organizational Units by Account

People, Roles and Accounts

すべてのカスタマー アカウントに関連付けられた組織単位、および各組織単位のメンバー数

Agreements by Account

People, Roles and Accounts

すべてのカスタマーのアカウントに関連付けられている契約

Request Center Advanced Reporting

Advanced Reporting モジュールには、Ad-Hoc クエリーおよびレポートを記述する機能があります。モジュールには、次の 3 つのオプションがあります。

[Home] ページは、[Service Portal] ドロップダウン メニューから [Reporting] モジュールを選択することなく Standard レポートを実行するショートカットを提供します。

[Ad-Hoc Reports] タブでは、IBM Cognos Query Studio にアクセスして、Request Center データ マートまたは Demand Center データ マートに対するクエリーを書き込むことができます。

[Report Designer] タブでは、IBM Cognos Report Studio にアクセスして、Request Center データ マートまたは Demand Center データ マートに対する非常に高品質のレポートを書き込むことができます。

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

このセクションでは、Advanced Reporting モジュールへのアクセス方法と、Request Center データ マートの内容および構造の詳細について説明します。Demand Center データ マートの詳細については、「Demand Center Advanced Reporting」を参照してください。

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

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

 

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

[Reports] フォルダは、[Reporting] モジュールの一部としてアクセスできる、事前作成レポートへの代替パスを提供します。カスタム設計されたレポート ビュー、および [Ad-Hoc Reports] または [Report Designer] で作成された新しいレポートも、通常 [Reports] フォルダのサブフォルダに格納されます。

残りのフォルダ([Custom Reports Data Model]、[Standard Reports Data Package]、および [Service Portfolio Reporting])は、Report Designer および Ad-Hoc Reporting で使用される「パッケージ」です。このフォルダを使用して、Request Center データ マートおよび Demand Center データ マートに対するクエリーおよびレポートを作成できます。

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

 

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

Request Center データ マートは「ディメンション モデル」として構成されています。

ディメンション モデル内の基本トランザクション データは「ファクト」と呼ばれます。Request Center データ マート内のファクトには、タスク、要求、および工数エントリが含まれます。各ファクトには、複数の単位(数量)が含まれる場合があります。たとえば、要求の推定処理時間は、実際の期間を示す 1 つの尺度になります。

各ファクトは、1 つ以上の「ディメンション」(関連するファクト内の行を選択またはフィルタリングするために使用できる説明属性)と関係しています。たとえば、Task-Based ファクトを説明するディメンションには、タスクの実行者とその完了した日付が含まれます。一方、ディメンションは通常、複数のファクト間で共有されます。たとえば、サービス ディメンションはタスクと要求の両方を説明している場合があります。

各ファクトはその関連するディメンションとともに、「スター スキーマ」を構成します。

スター スキーマに加えて、Custom Reports パッケージには、フォームベース、ディクショナリベース、およびサービスベースのデータについてユーザが策定する必要があるレポートおよびクエリーをすべてカバーする別のテーブル、およびサイトにおける組織構造が含まれます。

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

 

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

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

 

 

 

属性

 

メトリック

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

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

ディメンション

Custom Reports パッケージには、次のディメンションのタイプが含まれます。

スタティック ディメンションはすべてのインストールで利用でき、[Dimensions] フォルダの直下にあります。これらのディメンションは、カスタマー、実行者、日付などのタスクおよび要求に関連する情報を説明します。

[DictionaryData] フォルダには、「レポート可能」として指定され、データ マートにロードされたディクショナリに基づくすべてのディメンションが存在します。レポート可能な各ディクショナリは、[DictionaryData] フォルダに配置されます。ディクショナリの各クエリー サブジェクトには、各サービスまたはすべてのサービスにおいて非表示になっているかどうかに関係なく、ディクショナリのすべてのフィールドが含まれます。任意のファクトに 1 つ以上のディクショナリ ディメンションに接続でき、柔軟なレポート作成とフィルタリングを実現します。

[ServiceData] フォルダには、「レポート可能」として指定され、データ マートにロードされたすべてのサービスが含まれます。各サービスのクエリー サブジェクトには、各サービスで許可されているフィールド数を超過していない限り、サービスで使用されるすべてのディクショナリ内のすべてのフィールドが含まれます。許可されているフィールド数を超過している場合、ディクショナリおよび/またはフィールドはサービスから除外されます。厳密に言えば、サービスのクエリー サブジェクトはディメンションではありません。このため、レポート作成の目的でファクトと組み合わせないでください。代わりに、サービスのクエリー サブジェクトをレポート オブジェクトとして使用することで、サービス内のすべてのディクショナリおよびフィールドに関するレポートを迅速に作成できます。

[Service Bundles] フォルダには、すべてのサービス バンドルと、サービス バンドルに関連付けられた子サービスが含まれます。パッケージで利用可能なファクトやディメンションに、これらのディメンションを接続することはできません。

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

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

要求:ServiceRequestFact

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

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

図 1-1 ServiceRequest ファクトのスター スキーマ図

 

Task-Based ファクト

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

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

次に、Task-Based ファクトの概要を示します。

ファクト
使用方法および説明

All Tasks

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

Authorization Tasks

すべての承認および確認タスク。

Delivery Tasks

アドホック タスクを含む、すべての配信タスク。

RequisitionTaskFact

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

ServiceTaskFact

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

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

 

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

図 1-2 Task-Based ファクトのスター スキーマ図

 

次のファクトおよびこれらのファクトは推奨しません。レポート デザイナーは他のファクトを使用して、すべてのカスタム レポートを作成することを推奨します。

ServiceTaskFact

RequisitionTaskFact

工数費用:TaskEffortEntry ファクト

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

Organizations

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

Data Mart ディメンション

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

Customer

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

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

クエリー項目
説明

CustomerID

カスタマーの ID

Customer Full Name

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

CustomerFirstName

カスタマーの名

CustomerLastName

カスタマーの姓

CustomerOUID

カスタマーのホーム OU の Organizational Unit ID

CustomerOUName

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

CustomerBuilding

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

CustomerBuildingLevel

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

CustomerOffice

カスタマーのオフィス

CustomerCubic

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

CustomerStreet1

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

CustomerStreet2

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

CustomerCity

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

CustomerStateProvince

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

CustomerZip

カスタマーの郵便番号

CustomerCountry

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

CustomerLoginName

カスタマーのログイン名

CustomerEmailAddress

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

Work Phone

カスタマーの業務用電話

Cust_SupervisorID

カスタマーの上司の ID

Supervisor Full Name

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

Cust_SupervisorFirstName

カスタマーの上司の名

Cust_SupervisorLastName

カスタマーの上司の姓

Cust_SupervisorEmail

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

Cust_SupervisorLoginName

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

Customer Status

カスタマーのステータスで、有効値は「Active」および「Inactive」

Dictionary

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

クエリー項目
説明

DictionaryID

ディクショナリ ID

DictionaryName

ディクショナリの名前

DictionaryGroupID

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

DictionaryGroupName

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

DictionaryServiceItemFamily

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

Is Reportable

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

Keyword

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

クエリー項目
説明

KeywordID

キーワードの固有識別子

Keyword

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

Performer

Performer ディメンションはタスクを実行する個人を説明します。これには、配信タスク、アドホック タスク、承認タスクおよび確認タスクが含まれます。

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

クエリー項目
説明

PerformerID

タスクを実行した個人の ID

Performer Full Name

実行者の氏名(First Name Last Name 形式)

PerformerFirstName

実行者の名

PerformerLastName

実行者の姓

PerformerOUID

実行者のホーム OU の Organizational Unit ID

PerformerOUName

実行者のホーム OU の名前

PerformerBuilding

実行者の建造物の番号または名前

PerformerBuildingLevel

実行者の建造物の中での高さまたは階数

PerformerOffice

実行者のオフィス

PerformerCubic

実行者の仕事スペースの番号

PerformerStreet1

実行者の住所の 1 行目

PerformerStreet2

実行者の住所の 2 行目

PerformerCity

実行者が位置している都市

PerformerStateProvince

実行者が位置している州

PerformerZip

実行者の郵便番号

PerformerCountry

実行者が位置している国

PerformerLoginName

実行者のログイン名

PerformerEmailAddress

実行者の電子メール アドレス

Work Phone

実行者の業務用電話

Per_SupervisorID

実行者の上司の ID

Supervisor Full Name

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

Per_SupervisorFirstName

実行者の上司の名

Per_SupervisorLastName

実行者の上司の姓

Per_SupervisorEmail

実行者の上司の電子メール アドレス

Per_SupervisorLoginName

実行者の上司のログイン名

Performer Status

実行者のステータス(「Active」または「Inactive」)

Queue

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

クエリー項目
説明

QueueID

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

QueueName

キューの名前

Queue Status

キューのステータス(「Active」または「Inactive」)

QueueOUID

キューにサービスを提供する組織単位の ID

QueueOUName

キューの組織単位の名前

Work Phone

キューの業務用電話

Email Address

キューの電子メール アドレス

Requestor

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

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

クエリー項目
説明

RequestorID

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

Requestor Full Name

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

RequestorFirstName

要求者の名

RequestorLastName

要求者の姓

Requestor Status

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

Work Phone

要求者の業務用電話

RequestorOUID

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

クエリー項目
説明

ServiceID

サービス ID

ServiceName

サービスの名前

Description

サービスの簡単な説明

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 クエリー サブジェクトでは、アプリケーション リポジトリ内のすべてのサービス バンドルにアクセスできます。

クエリー項目
説明

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 ディメンションは、タスク タイプの説明を提供するために使用できます。

クエリー項目
説明

TaskTypeID

タスク タイプの ID

TaskTypeName

タスク タイプの説明

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

ID
タスク タイプ

0

配信タスク

1

財務承認

2

部門確認

3

部門承認

4

サービス グループの承認

5

サービス グループの確認

6

配信用のアドホック タスク

7

承認用のアドホック タスク

8

確認用のアドホック タスク

CalendarClosedDate

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 は、オーダーされたサービスに関する情報を提供します。フォルダにより、On-Time および Request Status Counts 用のメトリックがグループ化されています。

クエリー項目
説明

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

要求が送信された日付

Task-Based クエリー サブジェクト

All Tasks、Authorizations Tasks、および Delivery Tasks ファクトは同じコンポーネント クエリー項目を保持しています。

All Tasks は、サービス要求を処理するために実行されるすべての配信タスク、確認および承認を含む、すべてのタスクに関する情報を提供します。

Delivery Tasks は、アドホック タスクを含む配信タスクに関する情報を提供します。

Authorization Tasks は、確認および承認に関する情報を提供します。

 

クエリー項目
説明

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 は、タスクの実行にかかる工数に関する情報を提供します。

クエリー項目
説明

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

Group は、権限またはタスクを各グループ メンバーに割り当てるのではなく 1 つのグループに割り当てることができる、別の個人または組織セット用のコンテナを提供します。グループのメンバーを表示するか、個人が関連付けられているグループを表示するために、レポートに Group および Person クエリー サブジェクトからの項目を含めることができます。

クエリー項目
説明

Group Name

グループの名前

Group Status

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

Parent Group Name

グループの親

Description

グループの説明

Person

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

クエリー項目
説明

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

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 Bundle

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 クエリー サブジェクトでは、サービス バンドルの一部であるすべての子サービスにアクセスできます。

クエリー項目
説明

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)ことを示すフラグ

メトリックと属性

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

タスク期間

Task-Based ファクト テーブルでは、タスク期間を測定する 3 つの方法があります。

ActualDuration は、カスタマーのカレンダーに従って、タスクの実行に要した作業経過時間数を測定します。

PerformerActualDuration は、実行者のカレンダーに従って、タスクの実行に要した作業経過時間数を測定します。

DefaultDuration はサービス デザイナーによって指定される数値で、タスクに要する時間を指定します。

たとえば、次の前提があるとします。

実行者のカレンダーでは 1 日 9 時間の作業日が指定されている

タスクは月曜日(作業日)の午前 9 時にアクティブになった

実行者は次の日の午前 10 時にタスクを完了した

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

タスク期日完了フラグ

タスクが完了した時刻(CompletedDateTime)を、タスクが完了する予定の時刻(ScheduledDateTime)と比べることで、タスクが期日どおりであることを判断します。期間(実際またはデフォルトの期間)はもちろん、元々は期限となる日時を計算するために使用されていましたが、この計算では直接使用されません。

タスク標準対応フラグ

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

サービス標準対応フラグ

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

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

サービス開始日時

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

タスクの再スケジュール

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

タスクの新しい(再スケジュールされた)期日は、そのタスクの期日完了判断の計算に使用されます。

サービスの期日および期日完了判断の計算には影響ありません。

タスクの新しい期間は、タスクの標準対応判断の計算に使用されます。

タスクの新しい期間は、サービスの標準対応判断の計算には使用されません。

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

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

両方のツールとも、カスタム パッケージ内に公開されているクエリー サブジェクトおよびクエリー項目に同等にアクセスできます。項目をページの左側にある [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 されます。このため、レポートに含まれる行はすべての条件を満たす必要があります。)

カスタム レポートおよびクエリーの実行

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

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

レポートは 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>']
 

レポート作成におけるヒントおよびテクニック

以下のヒントおよびテクニックは、Service Portal データ マートのデータおよび関係に適用されます。上記で述べたとおり、IBM Cognos レポート作成ツールを使用する際の一般的な手順については、適切な IBM Cognos マニュアルまたは IBM Cognos Business Intelligence ソリューションに関するサードパーティの書籍を参照してください。

要求およびタスクの日時

Request Center トランザクション データベースでは、すべての日付は GMT/UTC 形式で格納されています。ただし、日付は My Services や Service Manager などのモジュールで表示される際に、自動的にユーザが設定したタイム ゾーンに変換されるため、このことを意識していないユーザがほとんどです。

Request Center データ マートも、すべての日付を GMT/UTC で保持しています。このタイム ゾーンはほとんどのユーザが表示されたデータを見るのに慣れているタイム ゾーンではないため、最初は少し不快に感じると思います。レポート デザイナーには 2 つのオプションがあります。

ユーザに GMT/UTC の日付を見ても驚かないように説明しておく。

Report Studio で利用できる演算式を使用して、日付をより一般的に知られているタイム ゾーンに変換する。(Cognos は各ユーザ設定を認識できないため、1 つのタイム ゾーンのみを選択できます)。

2 つ目のオプションの例として、本社が米国の中央時間帯に属しているカスタマーがいるとします。格納されている日時から 6 時間を引く演算式を使用して、期待されるタイム ゾーンの日時カラムを表示します。演算式は次のようになります。

[Query].[DUEDATETIME] - 000 06:00:00.000
 

サービス設計とレポート作成に関するベスト プラクティス

Ad-Hoc Reporting モジュールでは、デザイナーが「レポート可能」として指定したディクショナリおよびサービスから、要求のデータ マートへの抽出(フォーム データ)ができます。ディクショナリおよびサービスの設計に関するサービス設計手順では、次の項目を考慮する必要があります。

レポート可能として指定するサービスおよびディクショナリを決定する基準

レポート可能なオブジェクトに関する設計ガイドライン

これらの設計に関する決定事項をサポートするデータ マートの設定

ディクショナリおよび/またはサービス設計の変更がデータ マートに与える影響

項目を「レポート可能」にする効果

任意のディクショナリまたはサービスをレポート可能として指定できます。

ディクショナリ

「レポート可能」なディクショナリは、Service Portal データ マートの [DictionaryData] フォルダにクエリー サブジェクトとして表示されます。ディクショナリ フィールドは、ディクショナリ内で指定した順序でディクショナリ ディメンションに表示されます。各フィールド タイプ(Character、Date、Number)の制限数を超過しているフィールドは、データ マートから除外されます。データ マートのクエリー項目名は、ディクショナリが定義されるときに指定したフィールド名と一致します。

ディクショナリをレポート可能にすることで、複数のサービスで使用されるディクショナリに基づいたレポートを非常に柔軟に作成できます。ディクショナリ、必要なファクト テーブル、および任意の関連するディメンションのデータを含むレポートを自由に作成できます。

レポート可能なディクショナリとそのコンポーネント フィールドの名前を付ける際は、次のガイドラインに従います。

ディクショナリ名とフィールド名はより多くのユーザに公開されることになるため、これらの名前を標準化します。

大文字と小文字の使用方法およびスタイルに関するサイト全体の基準を作成し、この基準を忠実に守ります。

複数のフォームで使用されるディクショナリのフィールド ラベルは一貫している必要があります。実際に、フィールド ラベルはフィールド名に非常に近い名前にする必要があります。フィールド名はディクショナリ ディメンションに公開されます。フィールド ラベルを使用している場合は、サービス ディメンションに公開されます。

ディクショナリをレポート可能になるように構築するには、次のガイドラインに従います。

ディクショナリがレポート可能である場合は、さまざまなサービスで非表示になっているフィールドを含めて、すべてのコンポーネント フィールドがデータ マートに表示されます。すべてのコンテキストにおいて、非表示になっているフィールドをユーザに対して非表示のままにする必要がある場合は、レポート可能ではない別のディクショナリにフィールドを配置してください。

必ず、予約済みのディクショナリ(Customer および Initiator)がサービスで使用されるフィールドのみを含むように設定してください。これらのディクショナリに含まれているフィールドはすべてデータ マートに表示されます。

フィールド名はその内容と一致させてください。たとえば、フィールドが「date」という名前の場合、データ タイプは Date とし、有効な日付または日時のみをフィールド値として許容するようにしてください。そうしないと、わかりにくいユーザ インターフェイスになります。たとえば、フィールドに無効な日付値が存在すると、ユーザは Cognos レポート作成およびクエリー ツールで日付の計算を適用できなくなります。

同様に、数値を含むフィールドは Number データ タイプとして格納し、適切なサイズと 10 進数精度を適用する必要があります。これにより、確実に数値計算を適用することができ、レポート作成またはクエリー ツールでフィールドをフォーマットする必要がなくなるため、使いやすく一貫した表示を実現できます。

ディクショナリがレポート可能になると、Service Designer には編集不可として最初に表示されます。ディクショナリの定義を編集するには、[Reportable] 値を [No] に変更します。この動作は、レポート可能になったディクショナリの定義を変更する際の影響を確実に認識してもらうための再確認です。

追加されたフィールドはデータ マートのディクショナリ データに追加されます。フィールドが追加される前に送信されたサービス要求には、そのフィールドの値は存在しません。

削除されたフィールドは、データ マートの対応するクエリー サブジェクトに残ります。フィールドの削除後の日付に送信した要求では、フィールド値は空欄になります。

任意のフィールドに割り当てられたフィールド長を自由に変更できます。

フィールドに割り当てられたデータ タイプは変更できません。データ タイプが変更されると、データ マートをロードする ETL プロセスが失敗します。どうしてもデータ タイプを変更する必要がある場合は、データ マートのフォーム データ コンポーネントを再作成し、すべてのデータをリロードする必要があります。この手順については、Cisco Technical Assistance Center(TAC)から入手できます。

サービス

サービスを「レポート可能」にすることで、サービスは [ServiceData] フォルダにクエリー サブジェクトとして表示されます。サービス レコードは、サービスのすべてのレポート可能なディクショナリから構成されます。各フィールド タイプ(Character、Date、Number)の制限数を超過しているフィールドは、データ マートから除外されます。データ マートのクエリー オブジェクト名は、サービス用のフォームを設計するときに指定したフィールド ラベルから取得されます。レポート可能なサービスに 2 つの同じラベルのフィールドが含まれている場合、ETL プロセスはディクショナリ フィールドを Dictionary_Label_1、Dictionary_Label_2 などのクエリー項目名を含むデータ マートに追加します。

サービス バンドルはレポート可能として指定できます。サービス バンドルをレポート可能にすることで、サービス バンドルは [ServiceData] フォルダにクエリー サブジェクトとして表示されます。サービス バンドル レコードは、子サービスとサービス バンドル自体に関連付けられたすべてのディクショナリから構成されます。

また、サービス バンドルに接続された子サービスがレポート可能である場合、子サービス レコードは各子サービスに関連付けられたディクショナリから構成されます。

サービスをレポート可能になるように構築する際は、レポート可能なディクショナリに関するガイドラインに加えて、次のガイドラインに従います。

同じサービスの異なるディクショナリにある 2 つのフィールドに同じラベルを割り当てないでください。ラベルはデータ マートの対応するクエリー項目の名前を付けるのに使用されるため、同じサービスで使用されるフィールドのラベルは一意である必要があります。

レポート可能にするオブジェクトの選択

カスタマーの各サイトは当然異なるディクショナリおよびサービスのセットを持っているため、これらの中からレポート可能にするオブジェクトを決定する方法について厳格なルールは存在しません。ただし、データ マートに含めるオブジェクトを決定する際は、次のガイドラインが役立つ場合があります。

ディクショナリ

日付または数値を含むディクショナリは、データ マートに含めるのに適した候補になります。

説明を保持するために設計された、ディクショナリのすべて、または一部を非常に大きなサイズのテキスト フィールドが占めるディクショナリは、データ マートに含めるのに適した候補ではありません。このようなフィールドは、データ マートが作成されるときに指定した最大文字サイズで切り捨てられます。

ビジネス ニーズにとって重要だと考えられるディクショナリは含める必要があります。このため、対応する個人ベースのディメンションには存在せず、Organization Designer に存在した情報よりも新しい情報を含んでいる Customer ディクショナリおよび Initiator ディクショナリを含めるのが一般的です。

サービス

サービスを含めることで、基本的に各ディクショナリを識別することなく(つまり、個別のディメンションまたはクエリー サブジェクトとして)サービス内のすべてのディクショナリに関してレポートを作成できるショートカットが提供されます。これは特に 1 つのサービスのみを取り扱うユーザや、クエリー ツールの使用頻度が低く、対象の項目に関するレポートを手っ取り早く必要としているユーザにとって役立ちます。

サービスをレポート可能にすることには、データ マートのサービスからディメンションを取得するハードルを下げる可能性がある、次の欠点があります。

サービスに(異なるディクショナリにある)同じ名前の 2 つのフィールドが含まれている場合は、サービスに基づくクエリー サブジェクトに Dictionary1_FieldName および Dictionary2_FieldName として表示されます。紛らわしくない名前のフィールドには、フィールド名が設定されます。

非常に多くのフィールドが存在する非常に多くのディクショナリを含むサービスでは、許容されているデフォルトのフィールド数から、サービスディメンションの設定を大幅に調整する必要があります。通常、この調整により、サービスをレポート可能にするために必要な文字、日付、または数値フィールドの数が非常に大きくなってしまいます。SQLServer マニュアルでは、これにより「行の連鎖」が引き起こされるため、パフォーマンスに悪影響が生じる可能性を警告しています。

Request Center データ マートの設定

Request Center データ マートはカスタマイズ不要でインストールできます。ただし、「最小の共通特性」によるアプローチでは、ほとんどのサイトのレポート作成要件を満たすことができなくなります。このため、推奨される手順は、上記で説明したベスト プラクティスを、サイトのディクショナリおよびサービス設定と組み合わせて確認することです。次のセクションをワークシートとして使用することで、アナリストはサイトに対して必要なデータ マート設定を決定できます。これらの設定パラメータは Request Center Advanced Reporting の設定に使用できます。

これらのパラメータは、データ マートをインストールする際に指定する必要がある多くのプロパティに対応しています。データ マートの設定とそのインストールのカスタマイズに使用されるインストールおよび設定パラメータの詳細については、『Cisco Service Portal Installation Guide』を参照してください。

ディクショナリおよびサービス テーブルの数

データ マートを作成するときに、データ マートが保持するディクショナリおよびサービス ディメンションの最大数を指定します。これらの各ディメンションはデータ マートの個別のテーブルに対応します。ディクショナリまたはサービスの数は、データ マートをインストールした後に増やすことができます。ただし、この手順を避けるためには、必ず直近の導入に対して計画されている現在の要件および機能向上に対応できる十分なテーブルでデータ マートを作成してください。

作成する必要がある各タイプのテーブル数を決定するための「特効薬」はありません。一部のガイドラインは前のセクションで説明されています。サービス デザイナーはすべてのディクショナリを確認し、データ マートに含めるディクショナリを決定して、それらを [Service Designer] > [Dictionaries] コンポーネントの [Reportable] ドロップダウン メニューで [Yes] を選択することで、レポート可能なディクショナリとして指定する必要があります。

Service Portal は、レポート可能として指定され、データ マートに作成されたサービスおよびディクショナリ テーブルの数が指定された数を超過しないように追跡します。次にディクショナリ(またはサービス)をレポート可能にしないと決定した場合は、対応する [Reportable] フィールドを [No] に変更します。これにより、データ マートをロードする ETL ジョブからソース ディクショナリまたはサービスが削除されます。レポート作成フレームワークでは、クエリー サブジェクトをまだ利用できます。ただし、ディクショナリまたはサービス データを保持するテーブルを別のディクショナリまたはサービスとともに使用することはできず、使用中のテーブル数の 1 つとしてカウントされます。

パラメータ
デフォルト値
サイト値

NUMBER_OF_SERVICE_TABLES

100

NUMBER_OF_DICTIONARY_TABLES

100

データ タイプの変換

データ マート内のすべてのデータは文字(テキスト)列、数値、または日付(時間コンポーネントを含む)として格納されます。内部ディクショナリからのデータは、次の表で示すように、適切なタイプに変換されます。

データ マート カラムのデータ タイプ
内部ディクショナリのデータ タイプ
データベース固有の実装

Number(Numeric)

Number

Money

Oracle:NUMBER

SQL Server:FLOAT

Date

Date

Date and Time

Oracle:DATE

SQL Server:DATETIME

Character(Varchar:可変長文字列)

Text

Person

URL

Account

Phone

SSN

Boolean

Oracle:VARCHAR2

SQL Server:VARCHAR

Person データ タイプは、サービス フォーム上の [Select a Person] ウィンドウで示されるように、個人の名と姓の組み合わせとしてデータ マート内に表されます。Boolean データ タイプは、データ タイプのオプション ボタン表現で示されるように、「yes」および「no」に対応する文字列で表されます。

外部ディクショナリからのデータは適切なタイプに変換されます。たとえば、すべての数値フィールドはその大きさや精度に関係なく、上記の表に示すターゲット データベースの Number タイプに変換されます。外部ディクショナリ テーブルの Graphic および Large OBject(LOB)データ タイプはサポートされていないため、データ マートの作成時や ETL プロセスによるデータのロード時には無視されます。

ディクショナリおよびサービス テーブルのカラム数

データ マート設定の一環として、デザイナーはディクショナリおよびサービス テーブルに作成される各タイプのカラム(Character、Numeric、または Date)の数を指定します。すべてのディクショナリ テーブルは、許容される各タイプのカラム数について、同一の構成である必要があります。これは、サービス テーブルについても同様です。


) SQLServer では、テーブルの行の長さを 8k(8192)バイトよりも大きくしないよう警告しています。これにより、サービス ディメンション テーブルのサイズには大幅な制限が課されることになります。このような制限は Oracle には存在しないため、各データ タイプのカラム数とテキスト カラムのサイズを合計行サイズ制限の 32k まで増やすことができます。


ディクショナリおよびサービス テーブルのカラム数を増やすオプションの 1 つは、文字(VARCHAR)カラムのサイズを(次に説明する DATA_STRING_MAX_SIZE プロパティで指定されている)デフォルト値の 200 文字から減らす方法です。文字カラムの最大サイズはすべてのディクショナリ(およびサービス)に適用されるため、この値を減らす場合は注意してください。指定されたサイズよりも長いテキスト データは切り捨てられます。

テーブルがインストール プロセスによって作成された後に、各タイプのカラム数を変更することはできません。

パラメータ
デフォルト値
サイト値

NUMBER_OF_DICTIONARY_VARCHAR_FIELDS

40

NUMBER_OF_DICTIONARY_NUMERIC_FIELDS

10

NUMBER_OF_DICTIONARY_DATE_FIELDS

10

NUMBER_OF_SERVICE_VARCHAR_FIELDS

80

NUMBER_OF_SERVICE_NUMERIC_FIELDS

20

NUMBER_OF_SERVICE_DATE_FIELDS

20

文字フィールドの最大サイズ

データ マート ディクショナリおよびサービス テーブル内の文字フィールドの最大サイズは、デフォルトで 200 文字に設定されています。これは、ディクショナリおよびサービスにおける、すべてのテーブル内のすべての文字(テキスト)フィールドのサイズです。このプロパティは、最初のデータ マートのインストール後に、Cisco Technical Assistance Center(TAC)から入手できるスクリプトを実行することでのみ変更できます。

文字フィールドには、1 行(テキスト)および複数行(テキストエリア)のフィールドとしてサービス フォームに表されるデータと、オプション ボタンとして表されるデータが格納されています。チェックボックスおよび複数選択のドロップダウン リストで 1 つ以上のオプションをオンにした場合は、オプションがカンマで区切られた状態で、オンにしたすべてのオプションが同じデータ マート文字フィールドに含まれます。文字フィールドの最大サイズを設定する際は、注意が必要です。サイズが小さすぎると、データは大幅に切り捨てられる場合があるため、一般的に説明フィールドおよびコメント フィールドが影響を受けます。サイズが大きすぎると、ETL プロセスおよびレポートの生成の両方のパフォーマンスに悪影響が生じる場合があります。

パラメータ
デフォルト値
サイト値

DATA_STRING_MAX_SIZE

200

計算の実行

次の手順に従って、サイトのレポート可能なディクショナリおよびサービスをサポートするデータ マートの設定方法を決定します。

レポート作成要件を確認して、レポート可能にする必要があるディクショナリとサービスの数を決定します。

選択したディクショナリ(およびサービス)を確認して、必要となる各タイプのフィールド(Character、Numeric、Date)の最大数を決定します。

ディクショナリ(またはサービス)ごとのフィールド数の要件がデフォルトを超過している場合は、各タイプのフィールド数にデータ タイプに割り当てられているサイズ(文字データの場合は DATA_STRING_MAX_SIZE、日付フィールドの場合は 7 バイト、数値フィールドの場合は 20 バイト)を掛けます。結果がターゲット データベースの行サイズ制限を超過している場合は、要件を確認します。

設定を書き留め、システム管理者が Advanced Reporting のインストール時にこのデータにアクセスできることを確認してください。

ディクショナリ(およびサービス)の変更

サービス設計手順では、以前に導入したディクショナリおよびサービスの変更を収容するのに最適な方法も検討する必要があります。これらの考慮事項には、Service Portal トランザクション システムへの影響と、データ マートへの影響の両方が含まれている必要があります。

次の前提があるとします。

ディクショナリはレポート可能で、オーダーされたサービスで使用されている。

データ マート(およびそのメタデータ)はすでに作成され、要求に対する設定が完了している。

ディクショナリへの変更がデータ マートの設定に与える影響にはどのようなものがあるでしょうか。これらの影響は次の 2 つの形で現れます。

レポート作成メタデータへの変更。つまり、Ad-Hoc Reports および Report Designer でクエリー サブジェクトおよびクエリー オブジェクトとして利用できるディクショナリベースおよびサービスベースのディメンション、およびそのコンポーネント フィールドへの変更。

Extract-Transform-Load(ETL)プロセスによってデータ マートにロードされるデータへの変更。

レポート可能なディクショナリへのフィールドの追加

データ マートのロード プロセスが次回実行されるときに、レポート作成モデル(メタデータ)を作成するジョブは、フィールドをクエリー項目としてディクショナリに対応するクエリー サブジェクトに追加します。ETL プロセスはそのフィールドを含めるようになります。ディクショナリに変更が加えられた後に送信された要求に対してはフィールド値が設定され、変更される前の日付に送信されたすべての要求に対しては空欄が設定されます。

このシナリオの唯一の注意点は、ディクショナリがディクショナリベースまたはサービスベースのディメンション内の各データ タイプに割り当てられたフィールドの最大数を超過している場合に、フィールドを追加できないという点です。(フィールド数は Advanced Reporting がインストールされる際に指定されます。システム管理者は、各ディクショナリのデフォルト値である 60 個の文字フィールド、10 個の日付フィールド、および 10 個の数値フィールド、および各サービスのデフォルト値である 80 個の文字フィールド、20 個の日付フィールド、および 20 個の数値フィールドをカスタマイズできます。確信がない場合は、必ずシステム管理者に確認してください)。

いずれの場合も、現在のソフトウェアは、ディクショナリまたはサービスを表すクエリー サブジェクト内の最後のクエリー項目としてフィールドを追加します。これは、サービス フォーム上にフィールドが表示される箇所には対応しません。

レポート可能な新しいディクショナリの追加

ディクショナリは新しいクエリー サブジェクトとなり、そのすべてのフィールドはクエリー項目になります。ディクショナリがレポート可能になった日付の時点から、データはディクショナリにロードされます。

既存のサービスに対して、ディクショナリの追加をまたがる期間の要求に関するレポートを作成することは困難です。レポートに新しいディクショナリのフィールドを含める場合は、そのディクショナリを含む要求のみが含まれます。新しいディクショナリおよび変更の期間をまたがる古いディクショナリからのデータを含むレポートを生成するには、サービスベースのクエリー サブジェクトを使用するしかありません。これとは逆に、既存のディクショナリにフィールドを追加した場合は、変更よりも前から存在する要求もレポートに表示され、新しいフィールドには空欄が表示されます。

レポート可能なディクショナリからのフィールドの削除

データ マートのビジネス ビューは変化しません。つまり、フィールドはディクショナリに対応するクエリー サブジェクト内でクエリー項目として引き続き表示されます。ただし、ETL プロセスでは、そのフィールドにデータがロードされなくなります。

データ マートに与える影響は、フィールドの非表示と同じ影響になります。サービス要求にはデータ値が提供されなくなり、データ マートにも表示されなくなります。ただし、フィールドの削除は、サービス設計の観点(ディクショナリを新しいサービスに含めるたびにフィールドを非表示にする必要がなくなる)およびデータ マートの観点(ETL プロセスがデータをフィールドにロードする必要がなくなる)では、効率性を高める場合があります。もちろん、フィールドをディクショナリから削除する前に、副作用がないことを確認するために十分なテストを実施する必要があります。たとえば、ISF コードがそのフィールドを参照していないことや、Service Link エージェント パラメータが削除されるフィールドにバインドされていないことを検証する必要があります。

レポート可能なディクショナリの削除

結果は、フィールドをディクショナリから削除する際に見られる結果と同じです。ディクショナリはクエリー サブジェクトとして引き続き表示されます。ただし、行は基盤ディメンションには追加されません。そのディクショナリからのデータに関するレポートを作成しようとすると、論理的にはサービス定義にそのディクショナリが含まれていたときにオーダーされた要求のみが含まれます。

レポート可能なディクショナリ数は、Advanced Reporting 設定の一環として指定した最大数を超過することはできません。この数はデータ マートを作成するときに入力しますが、データ マートが動作している間はシステム管理者によって増やすことができます。ただし、レポート可能なディクショナリを削除してもデータ マートからディクショナリは削除されないため、このディクショナリは許可されているディクショナリの 1 つとしてカウントされます。ディクショナリを使用する要求がデータ マートに一度ロードされると、データ マートからディクショナリを削除することはできなくなります。

ディクショナリ名の変更

通常、ディクショナリ名は、いったんディクショナリをレポート可能として指定した後で変更しないでください。データ マートの対応するクエリー サブジェクトの名前が変更されてしまいます。また一方で、ディクショナリのフィールドを使用して保存されたレポートまたはクエリーは、無効になって実行されなくなります。(パブリック フォルダ内のレポートの書き込み権限を持つレポート オーナーまたはユーザは、このようなレポートを修復するためにレポート定義を編集する必要があります)。

フィールド定義の変更

フィールド名の変更

フィールド名の変更は、ディクショナリ名の変更に似ています。変更はできますが、いったんフィールドがレポート可能ディクショナリまたはレポート可能サービスに含められた後の変更は推奨されません。データ マートの対応するクエリー項目の名前が変更されてしまいます。また一方で、前のフィールド名を使用して保存したレポートまたはクエリーは無効になります。

フィールド タイプの変更

フィールドのデータ タイプ(数値、日付、文字など)は、変更しないでください。ディクショナリに対応するディメンションが初めて作成されると、すべてのディクショナリ フィールドが適切なデータ タイプのカラムにマッピングされます。このマッピングは変更できません。

新規フィールドを適切なタイプの同じディクショナリ内に作成して、場合によっては古いフィールドを削除する方法が可能です。変更前後の両方のデータが必要なレポートには、両方のフィールドを含める必要があります。

フィールドの HTML 表現(表示タイプ)の変更に制限はありません。たとえば、最初に一連のチェックボックスとして表示されていたテキスト フィールドは、データ マートに影響を及ぼすことなくドロップダウン リストとして表示できます。

フィールドの長さの変更

数値フィールドの長さの変更は、データ マートで対応しています。副作用の可能性は最小限です。たとえば、レポートの項目に以前割り当てられていた形式を新規に許可したフィールド値に対応するように調整する必要がある場合があります。

テキスト フィールドの長さを変更することによる影響は最小限です。長さが増加されて、データ マート内のテキスト フィールドに割り当てられた文字数(デフォルトでは 200)を超過した場合、フィールド内のデータが切り捨てられます。テキスト フィールドを短くした場合の副作用として、ユーザが別の形式で以前入力された値を省略する、あるいはそうでなくとも短くする可能性があります。レポートまたはクエリーがそのフィールドに基づいたグループまたはセクション見出しを使用して設計されている場合は、行が期待どおりにグループ化されない可能性があります。

フィールド キャプションの指定

アクティブ フォーム コンポーネントにディクショナリが追加されると、サービス設計者は、アクティブ フォーム コンポーネント内のディクショナリの各フィールドに対してキャプションを指定できます。これらのキャプションはサービス フォームのフィールド ラベルとして表示されます。Service Designer は、フィールド キャプションの一意性の制約を強制しません。これは、Service Portal サービス フォーム内で許可されているためです。しかし、サービスをレポート可能にする場合は、同じキャプションを同じディクショナリ内の複数のフィールドに使用しないでください。結果として、同じ名前のクエリー項目が 2 つになります。これはサポートされていません。

Service Bundle からの子サービスの削除

データ マートのビジネス ビューは変更されません。つまり、子サービスのフィールドは、Service Bundle に対応するクエリー サブジェクトのクエリー項目として引き続き表示されます。ただし、ETL プロセスは、削除された子サービスに対応するフィールド内にデータをロードしません。

Demand Center Advanced Reporting

Demand Center データ用のデータ マートは、Advanced Reporting モジュールで使用できます。このデータ モデルを使用すると、Query Studio や Report Studio でトレーニングを受けたレポート作成者は、補足データを使用してより良い戦略決定をするために、データの独自のビューを生成するための適切なレポートを作成できます。

Advanced Reporting モジュールには、Ad-Hoc クエリーおよびレポートを記述する機能があります。モジュールには、次の 3 つのオプションがあります。

ホーム ページには、[Service Portal] ドロップダウン メニューから [Reporting] モジュールを選択する必要なく、標準レポートを実行するためのショートカットがあります。

[Ad-Hoc Reports] タブでは、Request Center または Demand Center データに対するクエリーを記述するために IBM Cognos Query Studio にアクセスできます。

[Report Designer] タブでは、Request Center または Demand Center データに対するプロ品質のレポートを記述するために IBM Cognos Report Studio にアクセスできます。

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

この項では、Advanced Reporting モジュールにアクセスする方法の手順および Demand Center データ マートの内容および構造の詳細について説明します。Request Center データ マートの詳細については、「Request Center Advanced Reporting」を参照してください。

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

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

 

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

[Reports] フォルダは、[Reporting] モジュールの一部としてアクセスできる、事前作成レポートへの代替パスを提供します。

残りのフォルダ([Custom Reports Data Model]、[Standard Reports Data Package]、および [Service Portfolio Reporting])は一切クリックしないでください。これらは、Report Designer および Ad-Hoc Reporting によって使用される「パッケージ」です。これらを使用すると、Request Center および Demand Center データ マートに対するクエリーおよびレポートが作成できます。

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

 

Demand Center データ マートにアクセスするには、名前をクリックして「Service Portfolio Reporting」を選択します。次に、Report Designer を使用している場合は、作成するレポート タイプを指定するように求められます。リストを指定します(これが最も簡単な方法です)。[Ad-Hoc Reports] を使用している場合は、Query Studio が自動的に開いてリスト レポートが表示されます。Service Portfolio Reporting パッケージが左側のペインに「Insertable Objects」というラベル付きで表示されます。Business View を展開すると 4 つのフォルダが表示されます。フォルダの 1 つ(たとえば、[Service Offerings])を展開すると、「クエリー サブジェクト」のリストが表示されます。各クエリー サブジェクトは、関連する一連のフィールドである「クエリー項目」をグループ化したものです。

 

最上位の各フォルダ内のすべてのクエリー サブジェクトにモデルが含まれていて、モデルからレポートおよびクエリーを生成できます。

各モデルには中心「ファクト」があります。[Service Offerings] フォルダ内の中心ファクトは Service Offering です。[Service Agreements] フォルダ内の中心ファクトは Service Agreement です。

各ファクトは 1 つ以上の「ディメンション」と関係を持っています。これは、属性のグループで、ファクトを説明するためや関連するファクト内の行を選択またはフィルタリングするため、またファクトに関するメトリックを提供するために使用します。たとえば、Service Offering を説明するディメンションには、提供が適用されるサービスおよび提供が開始された日付が含まれます。

同じディメンションを複数のモデル間で共有できます。たとえば、サービス ディメンションで提供と契約の両方を説明できます。

各ファクトはファクトに関連するディメンションとともに「スター スキーマ」を構成します。

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

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

 

 

 

固有識別子

 

属性

 

メトリック

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

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

Service Offering のファクトおよび関連するディメンションを示すスター スキーマ図を次に示します。

図 1-3 Service OFFERING スター スキーマ図

 

Service Agreement ファクトおよび関連するディメンションを示すスター スキーマ図を次に示します。

図 1-4 Service AGREEMEET スター スキーマ図

 

すべてのクエリー サブジェクトのリスト(ディメンションとファクトの両方)ならびに各サブジェクトを構成するクエリー項目、および各クエリー項目の説明については、以降の項で説明します。

[Service Offerings] フォルダ

[Service Offerings] フォルダには、次のクエリー サブジェクトが含まれます。

Service Offerings

Services

Start Dates

Periods

Objectives

Attributes

Cost Drivers

Business Initiatives

Business Processes

Cost Drivers for Service Offerings

Objectives for Service Offerings

Component Services for Service Offerings

Service Offerings

Service Offering ディメンションには、各会計年度用に作成された提供サービスの詳細が含まれます。提供サービスは、ビジネス カスタマーに提供された組織固有の IT サービスの集合です。

クエリー項目
説明

Offering ID

提供の固有識別子

Offering Status

提供のステータス

Offering Name

提供の名前

Description

提供の説明

Price Description

価格の説明

Service Level Description

サービス レベルの説明

Fiscal Year

提供の会計年度

Creation Date

提供が作成された日時

Start Date

提供の開始日時

Expiration Date

提供の期限が切れる日時

Business Category

提供のビジネス カテゴリ

Internal Category

提供の内部カテゴリ

Business Process

提供のビジネス プロセス

Component Services Description

提供サービスのコンポーネント サービスの説明

Header HTML

提供サービスのヘッダー HTML

Footer HTML

提供サービスのフッター HTML

Services

Services ディメンションには、アプリケーションで定義されたサービスに関する情報が含まれます。

クエリー項目
説明

Service ID

サービスの固有識別子。

Service Name

サービスの名前。

Service Description

サービスが属するサービス グループの固有識別子。

Service Group Name

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

Service Team Name

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

Service Status

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

Service Duration

サービス定義に指定された標準期間(時間単位)。

Service Duration Units

標準期間が表示される単位。

Service Summary Price

サービス定義に指定された概要価格。

Expiration Date

サービスの有効期限日。

Is Active

サービスがアクティブ(0)か非アクティブ(1)かを示すフラグ。

Is Orderable

サービスの指定がオーダー可能(1)かオーダー不可能(0)かを示すフラグ。

Is Reportable

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

Publication Date

サービス送信日。

Service Hours Per Day

Estimated Cost

Start Dates

Start Dates ディメンションでは、提供が開始された日の階層構造が提供されています。これにより、レポートおよびクエリー作成者は、さまざまな日付間隔で容易にフィルタリングしたり、さまざまな形式を使用して日付データを表示できます。このディメンションは、01-Jan-1995 ~ 31-Dec-2025 のすべての日付であらかじめ入力されています。

クエリー項目
説明

Full Date

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

Day of Week

曜日(1= 日曜日、7= 土曜日)

Day of Week Name

曜日(例、Sunday)

Day of Week Short Name

曜日の短縮名(例、Sun)

Day of Month

日付の日の部分

Day of Year

年内の日付のシーケンス(1 ~ 366 の数値)

Month Name

月の名前(例、January)

Month Short Name

月の短縮名(例、Jan)

Month Day Name

月の短縮名の後に日付(例、Jan-25)

Week of Year

年の週(1 ~ 52 の数値)

Month of Year

年の月(1 ~ 12 の数値)

Calendar Quarter

カレンダー四半期(1 ~ 4)

Calendar Year

YYYY 形式のカレンダー年(例、2007)

Calendar Year Month

YYYY-MM 形式のカレンダー年の後に月(例、2008-12)

Calendar Year Quarter

カレンダー年の後に四半期(例、2009-Q1)

Calendar Seven Day Week

年の週(例、Week 6)

Calendar Week Begin Date

DD-MMM-YYYY 形式の週の最初の曜日(日曜日)がくる日付

Calendar Week End Date

DD-MMM-YYYY 形式の週の最後の曜日(土曜日)がくる日付

Month Begin Date

DD-MMM-YYYY 形式の月の最初の日がくる日付

Month End Date

DD-MMM-YYYY 形式の月の最後の日がくる日付

Quarter Begin Date

DD-MMM-YYYY 形式のカレンダー四半期の最初の日がくる日付

Quarter End Date

DD-MMM-YYYY 形式のカレンダー四半期の最後の日がくる日付

Year Begin Date

DD-MMM-YYYY 形式の年の最初の日がくる日付

Year End Date

DD-MMM-YYYY 形式の年の最後の日がくる日付

Periods

Periods ディメンションには、1995 ~ 2025 のすべての会計年度のすべての期間が含まれます。

クエリー項目
説明

Period ID

期間の固有識別子

Fiscal Year

YYYY 形式の期間の会計年度(例、2008)

Period

期間番号(1 ~ 12 の数値)

Period Start Date

期間の開始する日付(例、 Apr 1,2009)

Period End Date

期間の終了する日付(例、Apr 30, 2009)

Fiscal Year Begin Date

現在の期間の会計年度の開始日(例、Jan 1,2009)

Fiscal Year End Date

現在の期間の会計年度の終了日(例、Dec 31, 2009)

Objectives

Objectives ディメンションには、提供サービスに関連付けられた目標に関する情報が含まれます。

クエリー項目
説明

Objective ID

目標の固有識別子。

Objective Name

目標の名前。

Objective Description

目標に関する簡単な説明。

Metric Type

目標達成の成功を測定するメトリック。

Category

Internal Benchmark

この目標の業界標準のメトリック。IT グループによる目標とベンチマーク値の間でのより大規模な比較が可能になります。

Objective Target

適切なメトリック タイプに応じた、この目標の予測数量。

Consequence Description

目標を達成しないために生じる結果。

Cost Drivers

Cost Drivers ディメンションには、システムで定義されたコスト ドライバに関する情報が含まれます

クエリー項目
説明

Cost Driver ID

コスト ドライバの固有識別子

Cost Driver Name

コスト ドライバの名前

Business Initiatives

Business Initiatives ディメンションには、システムで定義されたビジネス イニシアチブに関する情報が含まれます

クエリー項目
説明

Business Initiative ID

ビジネス イニシアチブの固有識別子

Business Initiative Name

ビジネス イニシアチブの名前

Business Initiative Description

ビジネス イニシアチブの説明

Business Initiative Status

ビジネス イニシアチブのステータス

Start Date

ビジネス イニシアチブの開始日

End Date

ビジネス イニシアチブの終了日

Revenue Impact

生じた収益への影響

Priority

ビジネス イニシアチブのプライオリティ

Business Processes

Business Processes ディメンションには、システムで定義されたビジネス プロセスに関する情報が含まれます

クエリー項目
説明

Business Process ID

ビジネス プロセスの固有識別子

Business Process Name

ビジネス プロセスの名前

Business Process Description

ビジネス プロセスの説明

Business Process Domain

ビジネス プロセスのドメイン

Business Process Category

ビジネス プロセスのカテゴリ

Business Process Group

ビジネス プロセス グループ

Attributes

Attributes ディメンションには、提供サービスに関連付けられた属性に関する情報が含まれます。

クエリー項目
説明

Attribute ID

属性 ID

Attribute Name

属性の名前

Attribute Description

属性の簡単な説明

Attribute Value

この提供サービスの属性の値

Cost Drivers for Service Offerings

このファクトには、会計年度の各期間の提供サービスに関連付けられたコスト ドライバの予測および実際のコストに関する情報が含まれます。

クエリー項目
説明

Offering ID

提供の固有識別子

Cost Driver ID

コスト ドライバの固有識別子

Period

会計年度の期間(1 ~ 12)

Period Status

期間のステータス(Active または Closed)

Unit Price Internal Benchmark

コスト ドライバの単価の内部ベンチマーク

Unit Price External Benchmark

コスト ドライバの単価の外部ベンチマーク

Cost Driver Unit Price

コスト ドライバの単価

Cost Driver Margin %

コスト ドライバのマージンの割合

Cost Driver Units Estimate

コスト ドライバの予測課金が測定された単位

Cost Driver Cost Estimate

コスト ドライバの予測コスト

Cost Driver Charge Estimate

コスト ドライバの予測課金

Cost Driver Units Actual

コスト ドライバの実際の課金が測定された単位

Cost Driver Cost Actual

コスト ドライバの実際のコスト

Cost Driver Charge Actual

コスト ドライバの実際の課金

Objectives for Service Offerings

このファクトには、各期間の提供サービスに関連付けられた実際の提供サービス目標に関する情報が含まれます。

クエリー項目
説明

Offering ID

提供の固有識別子

Objective ID

目標の固有識別子

Period

目標が適用される期間(1 ~ 12)

Period Status

期間のステータス(open または closed)

Objective Actual

期間の目標の実際の値

Component Services for Service Offerings

このファクトには、提供サービスの各コンポーネント サービスに指定された予測および実際の量に関する情報が含まれます。量は期間ごとに分割されます。

クエリー項目
説明

Service ID

サービスの固有識別子

Offering ID

提供の固有識別子

Period

コンポーネント サービスが提供に関連付けられた期間

Period Status

期間のステータス(open または closed)

Included Quantity Per Agreement

1 つの契約当たりに含まれるコンポーネント サービスの数量

Total Included Quantity Estimate

含まれるコンポーネント サービスの予測合計数量

Service Included Quantity Actual

コンポーネント サービスの実際の数量

Service Additional Quantity Actual

追加サービスの実際の数量

Service Total Quantity Actual

コンポーネント サービスの実際の合計数量

Service Charge Actual

コンポーネント サービスの実際の課金

[Service Agreements] フォルダ

[Service Agreements] フォルダには、次のクエリー サブジェクトが含まれます。

Service Agreements

Accounts

Organizational Units

Start Dates

Service Offerings

Periods

Service Agreement Versions

Objectives

Services

Cost Drivers

Cost Drivers for Service Agreements

Objectives for Service Agreements

Component Services for Service Agreements

Service Agreements

Service Agreements ディメンションには、特定の提供サービスの IT とビジネス カスタマー間の契約に関する情報が含まれます。

クエリー項目
説明

Agreement ID

契約 の固有識別子

Offering ID

契約が属する提供の固有識別子

Agreement Name

契約の名前

Agreement Description

契約の説明

Offering Name

契約が属する提供の名前

Agreement Status

契約のステータス。有効なステータスは次のとおりです。

Draft

Submitted

Approved

Active

Inactive

Expired

Start Date

契約の開始日時またはスケジュール設定された開始日時

Expiration Date

契約の期限が切れる日時

Fiscal Year

契約が有効な会計年度

Effective Date

契約が有効になる日付

Accounts

Accounts ディメンションには、アカウントに関する情報が含まれます。アカウントは、IT が契約を確立するために使用される Demand Center 内のビジネス エンティティです。1 つ以上の組織単位(OU)で構成されています。

クエリー項目
説明

Account ID

アカウントの固有識別子

Account Name

アカウントの名前

Account Description

アカウントの説明

Account Status

アカウント ステータス

Organizational Units

Organizational Units ディメンションには、組織単位(OU)に関する情報が含まれます。

クエリー項目
説明

Organizational Unit ID

組織単位の固有識別子

Organizational Unit Name

組織単位の名前

Organizational Unit Description

OU の説明

Parent Organization

親組織単位の名前

Organization Type

組織単位のタイプ(営業部門またはサービス チーム)

Organization Status

組織単位のステータス(Active または Inactive)

Start Dates

このディメンションのクエリー項目は、[Service Offerings] フォルダの「Start Dates」ディメンションのクエリー項目と同じです。

Service Offerings

このディメンションのクエリー項目は、[Service Offerings] フォルダの「Service Offerings」ディメンションのクエリー項目と同じです。

Periods

このディメンションのクエリー項目は、[Service Offerings] フォルダの「Periods」ディメンションのクエリー項目と同じです。

Service Agreement Versions

Service Agreement Versions ディメンションには、契約バージョンに関する情報が含まれます。

クエリー項目
説明

Agreement Version ID

契約バージョンの固有識別子

Is Latest Flag

契約バージョンが最新か否かを示すフラグ

Version Update Date

契約バージョンの更新日時

Submitted By First Name

契約を送信した個人の名

Submitted By Last Name

契約を送信した個人の姓

Submitter Full Name

契約を送信した個人の氏名

Reviewed By First Name

契約を確認した個人の名

Reviewed By Last Name

契約を確認した個人の姓

Reviewer Full Name

契約を確認した個人の氏名

Version Status

このバージョンの契約のステータス

Objectives

Objectives ディメンションには、サービス契約に関連付けられた目標に関する情報が含まれます。この構造は、[Service Offerings] フォルダの Objectives ディメンションと似ています。

Services

このディメンションは、[Service Offerings] フォルダの「Services」ディメンションと似ています。

Cost Drivers

このディメンションは、[Service Offerings] フォルダの「Cost Drivers」ディメンションと似ています。

Cost Drivers for Service Agreements

このファクトには、期間レベルで契約に関連付けられた予測および実際のコスト ドライバに関する情報が含まれます

クエリー項目
説明

Agreement ID

契約の固有識別子

Cost Driver ID

契約に割り当てられたコスト ドライバの固有識別子

Period

コスト ドライバが適用される期間番号

Period Status

期間のステータス(open または closed)

Cost Driver Unit Price

コスト ドライバの単価

Cost Driver Units Estimate

コスト ドライバの予測単位

Cost Driver Cost Estimate

コスト ドライバの予測コスト

Cost Driver Charge Estimate

コスト ドライバの予測課金

Cost Driver Units Actual

コスト ドライバの実際の単位

Cost Driver Cost Actual

コスト ドライバの実際のコスト

Cost Driver Charge Actual

コスト ドライバの実際の課金

Objectives for Service Agreements

このファクトには、期間レベルでサービス契約に関連付けられた実際のサービス契約目標に関する情報が含まれます。

クエリー項目
説明

Agreement ID

契約の固有識別子

Objective ID

契約が関連付けられた目標の固有識別子

Period

期間番号

Period Status

期間ステータス

Objective Actual

実際の目標

Component Services for Service Agreements

このファクトには、期間レベルでサービス契約に関連付けられた予測および実際のコンポーネント サービスに関する情報が含まれます。

クエリー項目
説明

Agreement ID

契約の固有識別子

Service ID

契約が関連付けられたサービスの固有識別子

Period

この契約が適用される会計期間の番号(1 ~ 12)

Period Status

期間のステータス(open または closed)

Service Included Quantity

含まれるコンポーネント サービスの数量

Service Unit Price Estimate

コンポーネント サービスの予測単価

Service Additional Quantity Estimate

コンポーネント サービスの予測追加数量

Service Total Quantity Estimate

コンポーネント サービスの予測合計数量

Variable Charge Estimate

コンポーネント サービスの予測可変課金

Service Unit Price Actual

コンポーネント サービスの実際の単価

Service Additional Quantity Actual

コンポーネント サービスの実際の追加数量

Service Total Quantity Actual

コンポーネント サービスの実際の合計数量

Variable Charge Actual

コンポーネント サービスの実際の可変課金

[Business Initiative Alignment] フォルダ

Business Initiative Alignment 名前空間には、次のクエリー サブジェクトが含まれます。

Service Offerings

Business Initiatives

Business Initiatives Attributes

前述のクエリー サブジェクト間の関係を示す図を次に示します。提供サービスは、0 以上のビジネス イニシアチブを持てます。各ビジネス イニシアチブは、そのまた下に 0 以上の属性を持てます。

 

Service Offerings

このディメンションは、[Service Offerings] フォルダの「Services Offerings」ディメンションと似ています。

Business Initiatives Attributes

このディメンションは、[Service Offerings] フォルダの「Business Attributes」ディメンションと似ています。

Business Initiatives

このディメンションは、[Service Offerings] フォルダの「Business Initiative」ディメンションと似ています。

[Business Process Alignment] フォルダ

Business Process Alignment 名前空間には、次のクエリー サブジェクトが含まれます。

Service Offerings

Business Processes

Business Process Attributes

前述のクエリー サブジェクト間の関係を示す図を次に示します。提供サービスは、0 以上のビジネス プロセスを持てます。各ビジネス プロセスは、そのまた下に 0 以上の属性を持てます。

 

Service Offerings

このディメンションは、[Service Offerings] フォルダの「Services Offerings」ディメンションと似ています。

Business Process Attributes

このディメンションは、[Service Offerings] フォルダの「Business Attributes」ディメンションと似ています。

Business Processes

このディメンションは、[Service Offerings] フォルダの「Business Initiative」ディメンションと似ています。

主要業績評価指標(KPI)

主要業績評価指標(KPI)では、Service Portal サービスの管理に重要と見なされるトレンドまたは統計情報をトレースする早くて便利な方法を提供します。

Dashboards

[Dashboard] オプションは、Reporting モジュールの一部です。これを使用すると、最大 4 つの KPI を表示するようにポータルを設定できます。

 

次に示すように、使用できる KPI のリストを表示するには、[Configure Dashboard] ボタンを使用します。

 

KPI 名の右側にあるボタンをクリックして、含める KPI を指定します。次に、[Order] 選択リストを使用して、KPI を表示する順序を選択します。設定が終了したら、[Save] をクリックします。

Request Center または Demand Center パフォーマンスのいずれを KPI が計測するかを指定できます。インストールしていないモジュールの KPI を選択した場合、「No data available」の表示がグラフの代わりに表示されます。

KPI インベントリ

次の KPI を使用できます。

KPI
説明

Service Delivery: On-Time % Trend

過去 6 ヵ月にサービスが時間どおりに提供された割合を示します。

Cost, Quality, Target Quadrants

実際の目標メトリックと実際の単価の両方の、それぞれのコストおよび品質の目標や予測からの偏差を表示します。四分円に沿った各点は、各集計のコスト ドライバからの偏差と目標メトリックからの偏差の交点を示します。

Cost, Quality, Benchmark Quadrants

実際の目標メトリックと実際の単価の両方の、それぞれのコストおよび品質のベンチマークからの偏差を表示します。四分円に沿った各点は、各集計のコスト ドライバからの偏差と目標メトリックからの偏差の交点を示します。

5 Most Requested Component Services for an Agreement

契約に含まれる 5 つの最も要求されたサービスを示します。

Performance Objective Indicators

Performance Objective Trends

実際の目標メトリック値の、目標メトリックの目標およびベンチマーク値からの偏差のトレンドを示します。

Account Total Charge Rankings

コスト ドライバに対する、上位と下位 5 つのアカウントの合計課金値の集計を表示します。

5 Least Requested Component Services for an Agreement

契約に含まれる 5 つの最も要求されなかったサービスを示します。

Total Charge Comparison

コスト ドライバに対する、実際の合計課金値の予測値からの偏差のスナップショットを表示します。グラフには、この予測課金値も参照用に表示されます。

Service Volume: Request Trend

過去 6 ヵ月にオーダーされたサービス要求のトレンドを示します。

5 Worst Performing Component Services for an Agreement

契約の 5 つの最悪の要求されたサービスを示します。

Unit Price Trends

実際の単価値の、コスト ドライバの予測およびベンチマーク値からの偏差のトレンドを示します。

Authorization: On-time % Trend

過去 6 ヵ月に承認タスクが時間どおりに実行された割合を示します。

5 Best Performing Component Services for an Agreement

契約に含まれる 5 つの最良の要求されたサービスを示します。

KPI 管理

[KPI Administration] オプションは、「Analytics Administrator」のロールを持つユーザが Advanced Reporting モジュールで使用できます。[KPI Administration] オプションを使用すると管理者は、KPI の表示または動作を調整できます。

 

KPI を選択すると、そのプロパティが表示されます。

 

変更が必要な KPI プロパティは、KPI の表示を定義するプロパティのみです。次の作業を行います。

[Type]:グラフのタイプで、オプションには、棒、縦棒、横棒、円、およびバブルがあります

[Data Color Param 1] から [Data Color Param 6]:グラフを描く色

Request Center メトリックおよび属性

メトリック

9 つのメトリックが、Standard Reports Package で使用できるレポート全体で使用されています。これらのメトリックを次の表にまとめ、次の項で説明します。

メトリック名
説明

Service Volume

サービス要求の合計数で、通常は定義された期間内のもの

Service Cost

特定のサービスに対して設定された価格から導き出されます。価格 * 単位

Task Volume

承認タスクまたは提供計画タスクの合計数

Task Duration

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

Planned Effort

特定の計画タスクの [Effort] フィールドに設定された時間から導き出されます(時間単位で計測)

Actual Effort

特定のタスクに対してタスクの実行者によって入力された時間([Effort] エントリ)から計算されます

Planning Effectiveness

設定されたエフォート時間内に完了したタスクの割合として計算されます

On-Time %

計算された期日どおりまたは期日前に完了したサービスまたはタスクの割合

Standard Compliance %

設定された期間内に完了したサービスまたはタスクの割合

サービス量の測定:カスタマーとは

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

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

コストが割り当てられている場合、[ORGANIZATIONALUNITNAME] フィールドは、サービス配信に対して「請求された」組織単位を参照します。これは、カスタマーとは誰かについての別の考え方です。

選択権はユーザにあります。ここでは、この選択肢の意味が明確になるように説明したにすぎません。

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

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

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

タスクは直接その個人に割り当てられ、他の人はそのタスクの作業をしたことがない。

タスクはキューに割り当てられ、実行者だけがそのタスクの作業をしたことがある。

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

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

使用する期間

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

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

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

カスタマーに対する約束(期日)と比べてタスクは遅れているか
このアセスメントを行う場合、レポートは尺度として TASKONTIMEFLAG、TASKDUEDATE、TASKCOMPLETEDDATE を含めます。これは、絶対日付という条件から、キューまたはサービス チームがカスタマーへの約束を守れているかを判断するのに有効です。しかし、個人のパフォーマンスを測る尺度としては適切ではありません。A、B、C という個人が行う 3 つのタスクが必要なサービスを実行するとします。個人 C のパフォーマンスを測定する場合、個人 A や B の遅れのために自分のタスクが遅れてしまう場合があります。そのため、この測定方法はチームやキュー全体のカスタマー サービスを評価する場合にだけ使用します。

このタスクは、この種のタスクの標準的な想定時間内に実行されているか
このアセスメントを行う場合、標準レポートでは尺度として TASKSTDCOMPLIANCEFLAG、TASKPROJECTEDDURATION、PERFORMERACTUALDURATION を使用します。タスクの実行に費やされた実際の期間と、この種のタスクの標準プランの期間とを比較できます。この方法のほうが、個々のチーム メンバーのパフォーマンス評価に適しています。期間に注目することで、上流作業の影響から切り離せるからです。あるタスクが、期日から見れば遅れて完了したものの、期間の長さから見れば標準的な期間かそれ未満だということは、十分にありえます。これはつまり、ある人は自分の担当業務をよく実行したが、上流作業の影響で遅れてしまったことを示しています。

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

属性

レポート パッケージで使用される次元属性は、Service Portal OLTP データベースに保持されるデータから取得されます。属性の概要を次に示します。

属性
説明

Customer*

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

Billed*

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

Performer*

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

標準レポート設計

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

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

人、ロール、グループ

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

たとえば、Organizational Units by People レポートの組織単位は次のようなものになります。

 

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

 

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

 

サービス設計の詳細

[People、Roles、Groups] フォルダ内のレポートと同様、Service Design Details フォルダ内のレポートもとても容易に作成できます。Dictionary および Service ディメンションから必要な項目を選び、必要に応じてグループ化するだけです。

たとえば、Ad-Hoc クエリーによって作成される「Services by Dictionary」レポートは次のようなものです。

 

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

レポートのタイトルを左寄せに変更します。

プロンプト ページでディクショナリ用に Search-and-Select フィルタを含めます。

要求管理

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

 

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

レポートの作業領域に、キュー組織、キュー名、Delivery Tasks ファクトのタスク名といった属性やディメンションを適宜配置します。

現在の日付とタスク期日の差(日数)を求めて、タスクの寿命を計算します。

4 つのエージング バケットをカスタム グループに設定します。

カスタム グループ(寿命)を基準としてレポートをピボットします。

サービス量とアクティビティ

Service Volumes and Activity レポートは、特定の期間内に開始されたサービス要求の数と、それらの要求の現在のステータスについての情報の概要を示します。たとえば、Service Volume: Request Activity by Service は次のようになります。

 

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

データ マートの管理

この項は、Service Portal レポーティング ソリューションの技術的実装の詳細について知る必要がある方を対象としたものです。これには、レポーティング環境に責任を持つレポート管理者、Cisco TAC に問題をレポートするサポート担当者、レポーティング オプションのカスタマイズや機能強化のためのコンポーネントのオプションについて調査する分析担当者や設計者が含まれます。

ロールベースのアクセス

Service Portal は、レポーティング機能すべてに対するロールベースのアクセスを備えています。ユーザ プロファイルは、Service Portal 名前空間によってデータベース内で直接アクセスされます。

Service Portal には、レポーティング機能へのアクセス用に基本的なロールのセットが準備されています。さらに、管理者はカスタム ロール(基本ロールとカスタム ロールのいずれも組み込みが可能)を定義することで、それぞれの責任に適した権限を持つユーザの追加とメンテナンスを容易にできます。各ユーザは、基本ロールに基づいてレポーティング モジュールにアクセスできるようになります。基本ロールは、ユーザまたはユーザが所属するグループまたは組織に直接割り当てられるか(Site Administration モジュールによる)、ユーザやグループに割り当てられているカスタム ロールに含まれているかのいずれかです。

Reporting および詳細な Advanced Reporting 機能にアクセスできる基本ロールの概要を次に示します。

凡例

DC = Demand Center、RC = Request Center

ロール
機能
説明

Service Operations Report User

RC レポートの表示

KPI ダッシュボードの表示および Reporting モジュールでの RC(Service Performance)レポート実行が可能

Service Strategy and Design Report user

DC レポートの表示

KPI ダッシュボードの表示および Reporting モジュールでの DC(Business Value)レポート実行が可能

Advanced Reporting:Business Author

RC レポートの表示

DC レポートの表示

Ad-Hoc レポート

KPI ダッシュボードの表示および Reporting モジュールのレポートすべての実行が可能

Advanced Reporting モジュールの [Ad-Hoc Reports] セクションへのアクセス

Advanced Reporting:Professional Author

RC レポートの表示

DC レポートの表示

Ad-Hoc レポート

Report Designer

KPI ダッシュボードの表示および Reporting モジュールのレポートすべての実行が可能

Advanced Reporting モジュールの [Ad-Hoc Reports] セクションへのアクセス

Advanced Reporting モジュールの [Report Designer] へのアクセス

Reporting Administrator

RC レポートの表示

DC レポートの表示

KPI ダッシュボードの表示および Reporting モジュールのレポートすべての実行が可能

Advanced Reporting モジュールの [Ad-Hoc Reports] セクションへのアクセス

Advanced Reporting モジュールの [Report Designer] へのアクセス

Advanced Reporting モジュールのツールを使用して公開フォルダの内容を操作可能

Relationship Manager

RC レポートの表示

DC レポートの表示

Reporting モジュールのレポートすべてを実行可能

Service Level Manager

RC レポートの表示

DC レポートの表示

Reporting モジュールのレポートすべてを実行可能

Service Team Manager

RC レポートの表示

KPI ダッシュボードの表示および Reporting モジュールでの RC(Service Performance)レポート実行が可能

Service Team Administrator

RC レポートの表示

KPI ダッシュボードの表示および Reporting モジュールでの RC(Service Performance)レポート実行が可能

Portfolio Designer および Administrator

DC レポートの表示

KPI ダッシュボードの表示および Reporting モジュールでの DC(Business Value)レポート実行が可能

Portfolio Manager

DC レポートの表示

KPI ダッシュボードの表示および Reporting モジュールでの DC(Business Value)レポート実行が可能

Analytics Administrator

RC レポートの表示

DC レポートの表示

Ad-Hoc レポート

Report Designer

KPI 管理者

レポート管理者

KPI ダッシュボードの表示および Reporting モジュールのレポートすべての実行が可能

Advanced Reporting モジュールの [Ad-Hoc Reports] へのアクセス

Advanced Reporting モジュールの [Report Designer] へのアクセス

公開 Reporting フォルダ、ダッシュボード、Cognos を管理可能

Advanced Reporting モジュールの [KPI Administration] へのアクセス

Site Administrator

すべて

Reporting および Advanced Reporting モジュールの Service Portal および Cognos 機能すべて

Request Center データ マートのソース データ

データ マート内のデータが正確で、欠落がないことは非常に重要です。これらの品質を測定するためには、データ マート内のデータのソースについて文書化しておくことが大切です。カスタム データ マート内で使用できるクエリー サブジェクトに見られるデータのための OLTP データベース内テーブルを次の表に示します。

データ マートのクエリー サブジェクト
OLTP データベース テーブル

Dictionary Data
(ユーザ専用のレポート可能ディクショナリ)

DefDataDictionary

DefObjectDictionaries

TxRequisitionEntry

Service form Data
(ユーザ専用のレポート可能サービス)

DefService

DefServiceExtension

DefDataDictionay

DefObjectDictionaries

DefData

TxRequisionEntry

Service

DefService

DefArea

DirOrganizationalUnit

Dictionary

DefDataDictionary

DefDictionaryGroup

Keyword

DefKeyword

Group

DirGroup

Organization

DirOrganizationalUnit

Customer

Requestor

Performer

Person

Queue

DirPerson

DirOrganizationalUnit

DirNetworkInfo

DirLocation

DirAddress

ServiceRequestFact

TxRequistionEntry

TxRequisition

ServiceTaskFact

TxRequisitionEntry

TxActivity

RequisitionTaskFact

TxRequisition

TxActivity

TaskEffortEntryFact

TxBilling

DefExpenditureType

DefBillingClass

DefUnitType

DirOrganizationalUnit

DirPerson

サービス フォーム レポーティング メタデータ

データ マート ETL プロセスは、データ マート データベース内のテーブルのセットを使用して、Ad-Hoc レポートと Report Designer オプションでユーザから見える ServiceData および DictionaryData ディメンションを設定します。これらのテーブルは、カスタム レポート パッケージがインストールされるときに作成され、データがデータ マートにロードされたときに入力されます。

これらのメタデータ テーブルは、Cognos フレームワークでは公開されません。これらのテーブルの内容は、カスタム レポート プロジェクト内のデータのビジネス ビューとして表示される、動的に定義されるディクショナリ ベースおよびサービス ベースのディメンションを指定するために使用します。

次の部分でこれらのテーブルについて説明します。各カラムの説明には抽象化されたデータ タイプを使用します。実際のデータ タイプは、データ マートが置かれたデータベース(Oracle または SQLServer)によって異なります。

DM_FDR_ETLDICTIONARYMETADATA

DM_FDR_ETLDICTIONARYMETADATA テーブルは、特定のレポート可能ディクショナリ(DictionaryID で識別)を、ディクショナリ データが格納される DM_FDR_DICTIONARY_n テーブル(DictionaryTableName)にマッピングします。また、ディクショナリ内および対応するデータ マート テーブル内で使用されている日付型、数値型、Varchar 型のフィールドの数を追跡します。

カラム名
データ型
説明

DictionaryID

Integer

ディクショナリの固有識別子。

DictionaryTableName

Varchar(50)

ディクショナリ データが格納されるデータ マート テーブルの名前。

LastDictionaryDateField

Integer

ディクショナリ テーブル内で使用された最後の日付時刻型フィールド。

LastDictionaryNumericField

Integer

ディクショナリ テーブル内で使用された最後の数値型フィールド。

LastDictionaryVarcharField

Integer

ディクショナリ テーブル内で使用された最後の文字型フィールド。

DM_FDR_DICTIONARYMETADATA

DM_FDR_DICTIONARYMETADATA テーブルは、個別のディクショナリ フィールド(属性)(DictionaryID および DictionaryAttributeName で識別)と、ディクショナリ テーブルの特定のカラムとをマッピングします。たとえば、ディクショナリ RC_REQUESTEDBY の属性「LastName」を、データ マート テーブル DM_FDR_DICTIONARYTABLE_10, のフィールド「Field2」にマッピングする(実際には、格納する)ことができます。

カラム名
データ型
説明

DestinationColumnName

Varchar(100)

この属性が格納される、テーブルのカラム名

DestinationTableName

Varchar(200)

ディクショナリ情報が格納されるテーブルの名前

DictionaryAttributeName

Varchar(100)

ディクショナリ内の属性の名前

DictionaryAttributeType

Varchar(100)

ディクショナリ内の属性のデータ型

DictionaryID

Integer

ディクショナリ ID

DictionaryName

Varchar(200)

ディクショナリの名前

DictionaryAttributeID

Integer

ディクショナリ属性 ID

DM_FDR_ETLMETADATA

DM_FDR_ETLMETADATA テーブルには、レポーティング オプションのインストール時に指定されたカスタム レポート パッケージ設定についての情報、さらにデータ抽出プロセス(ETL)および ETL プロセスのスケジュール実行用の最終更新情報が保持されます。

カラム名
データ型
説明

DictionaryTablePattern

Varchar(50)

ディクショナリ テーブルの名前用パターンで、デフォルトでは「DM_FDR_DICTIONARY_」。Advanced Reporting のインストールにより指定されます。ディクショナリ テーブルは、指定された名前に数値の付いた名前を持つことになります

Field Pattern

Varchar(50)

ディクショナリとサービス テーブルの両方で使用するフィールド パターン。デフォルトでは、「FIELD_」です

LastDictionaryTableSequence

Integer

現在データ マートで使用された最後のディクショナリ テーブルのシーケンス番号。

LastDictRequisitionID

Integer

データがディクショナリ テーブルに書き込まれた最後の要求 ID。

LastProcessedTime

Datetime

カスタム レポート パッケージをロードする ETL が最後に実行された日付と時刻。

LastServiceTableSequence

Integer

データ マートで使用された最後のサービス テーブルのシーケンス番号。

LastSvcRequisitionID

Integer

サービス データの最後の要求 ID。

ServiceTablePattern

Varchar(50)

サービス テーブルの名前用パターンで、デフォルトでは「DM_FDR_SERVICE_」。Advanced Reporting インストールにより指定されます

DictionaryTotalDateField

Integer

ディクショナリおよびサービス テーブルに使用された日付型フィールドの総数。

DictionaryTotalNumericField

Integer

ディクショナリおよびサービス テーブルに使用された数値型フィールドの総数。

DictionaryTotalVarcharField

Integer

ディクショナリおよびサービス テーブルに使用された文字型フィールドの総数。

ServiceTotalDateField

Integer

サービス テーブルに使用された日付型フィールドの総数。

ServiceTotalNumericField

Integer

サービス テーブルに使用された数値型フィールドの総数。

ServiceTotalVarcharField

Integer

サービス テーブルに使用された文字型フィールドの総数。

DM_FDR_ETLSERVICEMETADATA

DM_FDR_ETLSERVICEMETADATA テーブルは、各レポート可能サービスについての情報の格納に使用するテーブルに関する情報を保持します。

カラム名
データ型
説明

LastServiceDateField

Integer

サービス テーブル内で使用された最後の日付時刻型フィールド。

LastServiceNumericField

Integer

サービス テーブル内で使用された最後の数値型フィールド。

LastServiceVarcharField

Integer

サービス テーブル内で使用された最後の文字型フィールド。

ServiceID

Integer

サービスに割り当てられた固有識別子。

ServiceTableName

Varchar

サービス データが格納されるデータ マート データベース テーブルの名前。

DM_FDR_SERVICEMETADATA

DM_FDR_SERVICEMETADATA テーブルは、サービス テーブルのどのカラムでどのサービス属性が入力されたかについてのメタデータ情報、および各カラムの使用名を保持します。

カラム名
データ型
説明

DestinationColumnName

Varchar(100)

この属性が格納される、テーブルのカラム名

DestinationTableName

Varchar(200)

サービス情報が格納されるテーブルの名前。

ServiceAttributeName

Varchar(100)

サービス内の属性の名前。

ServiceAttributeLabel

Varchar(200)

サービス内の属性のキャプション。

ServiceAttributeType

Varchar(100)

属性タイプ。

ServiceAttributeID

Integer

サービスの属性の ID。

ServiceID

Integer

サービス ID

ServiceName

Varchar(200)

サービスの名前

動的定義ディメンション

カスタム レポート パッケージに追加されるディクショナリの性質と数、およびその属性は、動的に決定され、Service Portal のインストールごとに大きく異なる場合があります。必要とされる柔軟性をサポートするために、カスタム レポート パッケージをサポートするデータベースには、ディクショナリとその属性およびディクショナリ(フォーム)データを使用したサービス設定に対応するディメンショナル データを保持する、抽象的データ構造が含まれています。ディクショナリの内容は、前述の DM_FDR メタデータ テーブルによってこれらのテーブルにマッピングされます。

DM_FDR_DICTIONARYTABLE_n

アプリケーション内の各レポート可能ディクショナリの属性(フィールド)をキャプチャする、一連のテーブルです。これらのテーブルの数、および各データ型(文字、数値、日付と時刻)のカラム数は、アプリケーション インストールの一部として設定可能です。

各テーブルは、DM_FDR_DICTIONARYTABLE(またはインストール手順で指定された別のパターン)に数値サフィクス「_n」が付された名前になります。各テーブルには、1 から順に番号が付けられます。このテーブルの各インスタンスが、レポート可能ディクショナリを表します。

DM_FDR_DICTIONARYTABLE は、レポーティング ツールでは [DictionaryData] フォルダ内のディメンションのセットとして表示されます。各ディメンションの名前は、対応するディクショナリのキャプションです。(キャプションのないディクショナリではディクショナリの名前が使用されます)。ディメンションの属性は、ディクショナリを構成するフィールドです。フィールドには、1 から順に番号が付けられます。各データ型のフィールド(文字、数値、日付と時刻)の数は、アプリケーション インストール手順で指定します。

カラム名
データ型
説明

DictionaryID

Integer

ディクショナリ ID

RequisitionID

Integer

要求 ID

RequisitionEntryID

Integer

要求エントリ ID

Field1 ~ Field n

Varchar(200)

ディクショナリ データを保持する Varchar フィールド

Field n+1 n+m

Numeric

ディクショナリ データを保持する数値型フィールド

Field n+m+1

Datetime

ディクショナリ データを保持する日付時刻型フィールド

DM_FDR_SERVICETABLE_n

レポート可能と指定された各サービスのデータをキャプチャする、一連のテーブルです。このテーブルは、サービスで使用されるすべてのディクショナリ内のフィールドすべてを含みます。これらのテーブルの数、および各データ型(文字、数値、日付と時刻)のカラム数は、アプリケーション インストールの一部として設定可能です。各テーブルには、1 から順に番号が付けられます。

各テーブルは、DM_FDR_SERVICETABLE(またはインストール手順で指定された別のパターン)に数値サフィクス「_n」が付された名前になります。このテーブルの各インスタンスが、レポート可能サービスを表します。

DM_FDR_SERVICETABLE は、レポーティング ツールでは [ServiceData] フォルダ内のディメンションのセットとして表示されます。各ディメンションの名前は、対応するサービスの名前です。ディメンションの属性は、サービス内のディクショナリすべてを構成するフィールドです。フィールドは、サービス内でディクショナリが出現する順に追加されます。各テーブルで変更されたフィールドの数は限られているため(インストール手順で指定するが、物理的にはデータベース制約の制限を受ける)、サービス テーブルは不完全な場合があり、一部のフィールド、実際には一部のディクショナリが切り詰められている場合があります。このため、DM_FDR_SERVICETABLE の扱いには注意が必要です。特に、大量のフィールドを持つディクショナリがレポート可能と指定されている場合や、同一サービス内で多数のディクショナリが使用されている場合には注意が必要です。

カラム名
データ型
説明

ServiceID

Integer

サービス ID

RequisitionID

Integer

要求 ID

RequisitionEntryID

Integer

要求エントリ ID

Field1 ~ Field n

Varchar(200)

サービス データを保持する Varchar フィールド

Field n+1 n+m

Numeric

サービス データを保持する数値型フィールド

Field n+m+1

Datetime

サービス データを保持する日付と時刻型フィールド

レポート可能グリッド ディクショナリなしと設定されたサービスの場合、サービスに対する各要求(要求エントリ)は ETL プロセスによってキャプチャされ、対応する DM_FDR_SERVICETABLE に 1 行のデータとして挿入されます。しかし、1 つ以上のレポート可能グリッド ディクショナリが設定されたサービスの場合、ETL プロセスは DM_FDR_SERVICETABLE テーブルに複数行のデータを挿入します。挿入される行の数は、レポート可能グリッド ディクショナリのうち最大の行数に対応します。

たとえば、レポート可能ノン グリッド ディクショナリ 1 つ(Employee)と、レポート可能グリッド ディクショナリ 2 つ(Contact、Address)を持つサービスがあるとします。このサービスに対する要求が、Contact 内のデータ 3 行、Address 内のデータ 2 行、Employee ディクショナリ内のいくらかのデータを持つと仮定します。このサービスに対してサービス テーブル内にキャプチャされたフォーム データは、次のように見えます。

RequisitionEntryID
Employee.FirstName
Employee.LastName
Contact.Type
Contact.Details
Address.Line
Address.City
Address.State
Address.Country

NNN

John

Smith

Cell

650-123-4567

3333 Third St.

San Mateo

CA

USA

NNN

(NULL)

(NULL)

Work

408-765-4321

1111 First St.

San Jose

CA

USA

NNN

(NULL)

(NULL)

Email

jsmith@company.com

(NULL)

(NULL)

(NULL)

(NULL)

Request Center データ マート データベース オブジェクト

次のテーブルに、Request Center データ マートに使用され、カスタム レポート パッケージによってユーザに公開されるデータベース テーブルとビューの一覧を示します。テーブルやビューは、対応するクエリー サブジェクトに直接マッピングされます。

データ マート テーブル/ビュー
プライマリ キー
クエリー サブジェクト/説明

DM_DEFSERVICE

ServiceID

サービス情報(サービス グループおよびサービス チームの情報を含む)

DM_DEFDICTIONARY

DictionaryID

ディクショナリ情報

DM_PERSON

PersonID

個人の情報

DM_DATE

DateID

カレンダー情報

VIEW_CUSTOMER

CustomerID

カスタマー情報

VIEW_REQUESTOR

RequestorID

要求元(イニシエータ)情報

VIEW_PERFORMER

PerformerID

タスクを実行する個人についての情報

VIEW_QUEUE

QueueID

タスクが割り当てられたキュー

VIEW_CALENDARCLOSED
DATE

ClosedDateID

タスクまたは要求がクローズされた日付および付属する日付階層

VIEW_CALENDARDUEDATE

DueDateID

タスクまたは要求が期日となる日付および付属する日付階層

VIEW_CALENDAR
SCHEDULEDDATE

ScheduledDateID

タスクまたは要求を開始するようスケジュールされた日付および付属する日付階層

VIEW_CALENDARSTARTEDDATE

StartedDateID

タスクまたは要求が開始された日付および付属する日付階層

DM_REQUISITIONENTRY
FACT

RequisitionEntryID

オーダーされた個別の要求エントリ(サービス)

DM_SERVICETASKFACT

ServiceTaskID

サービス(要求エントリ)レベルで実行されるタスク(配信タスク、Ad-Hoc タスク、サービス グループの承認や確認を含む)

DM_REQUISITONTASKFACT

RequisitionTaskID

要求レベルで実行されるタスク(財務承認、組織単位の承認と確認を含む)

DM_TASKEFFORTENTRY
FACT

EffortEntryID

配信タスクの実行に費やされた工数

DM_FDR_DICTIONARY_n
(n=1, 2, 3, ...)

RequisitionEntryID

対応するディクショナリ属性情報

DM_FDR_SERVICE_n

(n=1, 2, 3, ...)

RequsitionEntryID

対応するサービス フォーム データ属性情報

データ マートを構成するテーブルは、複数のクエリー サブジェクトからデータを取得するクエリーやレポートのパフォーマンス最適化のためインデックス化されています。ディクショナリ ベースとサービス ベースのディメンションは、これらのテーブルの動的特性のために、インデックスの追加は行われません。

静的に定義されたファクトおよびディメンション テーブルに準備されたインデックスの概要を次に示します。

データ マート テーブル/ビュー
プライマリ キー
追加インデックス

DM_DEFSERVICE

ServiceID

SERVICENAME

DM_DEFDICTIONARY

DictionaryID

DICTIONARYNAME

DM_PERSON

PersonID

PERSONFIRSTNAME
PERSONLASTNAME

ISQUEUE

DM_DATE

DateID

(なし)

DM_REQUISITIONENTRYFACT

RequisitionEntryID

SERVICEID

REQUESTORID

CUSTOMERID

STARTEDDATE

CLOSEDDATE

DUEDATE

DM_SERVICETASKFACT

ServiceTaskID

REQUISITIONENTRYID

PERFORMERID

SERVICEID

STARTEDDATE

COMPLETEDDATE

DUEDATE

QUEUEID

DM_REQUISITONTASKFACT

RequisitionTaskID

PERFORMERID

STARTEDDATE

COMPLETEDDATE

DUEDATE

QUEUEID

ファクトとディメンションの関係

要求(ServiceRequestFact)は、関連するすべてのディメンション(先に含まれていたスター スキーマに表示)に「内部結合」されます。これは、要求とディメンションの両方からのクエリー項目の使用を試みると、ディメンション内に対応する行を持つ要求だけが表示されることを意味しています。一般に、静的に定義されたディメンションすべてについて、これは要素とはなりません。これらはすべての要求に必要であるためです。たとえば、要求にはカスタマーとイニシエータ、要求されるサービス、要求の提供に関するすべての日付が本質的に必要です。

これは、レポートの作成に密接に関係しています。たとえば、レポートの定義を開始して、カスタマーのセットを選択してから特定期間でフィルタした要求データを追加する場合、その期間にサービスをオーダーしていないカスタマーはレポートから「消える」ことになります。

動的に定義される、ディクショナリ ベースのディメンションでは、これは非常に重要になります。あるディクショナリが特定のサービスで使用されていない場合、そのディクショナリ ベースのディメンションからのクエリー項目を含むレポートには、そのサービスに対する要求が表示されません。

同様に、配信タスク(ServiceTaskFact)およびサービス レベルの承認(RequisitionTaskFact)の場合、内部結合によってファクトがキューを除くすべてのディメンション テーブルに関連付けられます。これらのファクトは、自由な関連付けをサポートする「外部結合」によってキュー ディメンションに結合されます。これにより、サービス設計者はタスクをキューではなく特定の個人や役職に割り当てることができます。タスクがキューに割り当てられなかった場合、レポートには引き続き表示されるものの、キューは空白になります。

要求レベルの承認(AuthTaskFact)の場合も、キューはオプションです。また、承認は要求を構成する個別のサービスに対してではなく要求レベルで実行されるため、サービスは無関係です。

組織データ内の関係

[Organizations] フォルダでは、人、組織、グループについてのレポートを作成できます。Request Center はこれらのエンティティ間の多対多の関係をサポートしています。たとえば、1 人の人が複数の組織(営業部門や複数のサービスチーム)のメンバーになることがあり、1 つの組織は多数の人で構成されています。これらの関係はデータ マート設計に反映されるため、レポート上でこれらのエンティティ 2 つを組み合わせ、いずれかのエンティティでグループ化できます。たとえば、すべての組織についてメンバーをリストするレポートを作成できますし、ある人が所属する組織をすべてリストすることも可能です。

ファクト間の関係

 

ファクト 1
ファクト 2
関係の種類

ServiceRequestFact

ServiceTaskFact

左外部結合

ServiceRequestFact

DeliveryTaskFact

内部結合

ServiceRequestFact

AuthTaskFact

左外部結合

ServiceRequestFact

AllTaskFact

左外部結合

AllTaskFact

TaskEffortEntryFact

左外部結合

DeliveryTaskFact

TaskEffortEntryFact

左外部結合

ServiceTaskFact

TaskEffortEntryFact

左外部結合

Demand Center データ マート データベース オブジェクト

この項では、Service Portfolio Reporting パッケージのクエリー サブジェクト作成に使用されているデータ マート データベースのテーブルとビューの一覧を示します。複数のクエリー サブジェクトからデータを取得するクエリーとレポートのパフォーマンスを最適化するためのデータ マート インデックスの詳細も示しています。

テーブル

次の表に、ビジネス ビューの作成に使用されるテーブルの一覧を示します。これらのビューは Service Portfolio Reporting パッケージによってユーザに公開されます。

データ マート ビュー
データ マート テーブル

V_DM_ACCOUNT

DM_DEFACCOUNT

V_DM_ORGUNIT

DM_DIRORGANIZATIONALUNIT

V_DM_OFFERING

DM_BVDEFBUSINESSSERVICE

V_DM_AGREEMENT

DM_BVDEFAGREEMENT

V_DM_DATE

DM_DATE

V_DM_PERIOD

DM_PERIOD

V_DM_ SERVICE

DM_DEFSERVICE

V_DM_COSTDRIVER

DM_BVDEFCOSTDRIVERTYPE

V_DM_OFFERINGOBJECTIVE

DM_BVDEFBSOBJECTIVE

V_DM_AGREEMENTOBJECTIVE

DM_BVDEFAGMTOBJECTIVE

V_DM_AGREEMENTVERSIONS

DM_BVDEFAGREEMENTLOG

V_DM_AGREEMENTOBJECTIVE

DM_BVDEFAGMTOBJECTIVE

V_DM_BUSINESSINITIATIVE

DM_BVDEFBUSINESSINITIATIVE

V_DM_OFFERINGATTRIBUTE

DM_BVDEFBSATTRIBUTE

V_DM_OFFERINGOBJECTIVEFACT

DM_BSOBJECTIVEFACT

V_DM_AGEEMENTOBJECTIVEFACT

DM_AGMTOBJECTIVEFACT

V_DM_OFFERINGCOSTDRIVERFACT

DM_BSPRICEELEMENTFACT

V_DM_AGREEMENTCOSTDRIVERFACT

DM_AGMTPRICEELEMENTFACT

V_DM_OFFERINGSERVICEEFACT

DM_BSSERVICESFACT

V_DM_AGEEMENTSERVICEEFACT

DM_AGMTSERVICESFACT

V_DM_BUSINESSPROCESS

DM_BVDEFBUSINESSPROCESS

V_DM_BIZINITIATIVEATTRIBUTE

-

V_DM_BIZPROCESSATTRIBUTE

-

ビュー

[Service Offerings] フォルダのクエリー サブジェクト作成に使用されるビューの概要を次に示します。

データ マート ビュー
プライマリ キー
クエリー サブジェクト

V_DM_OFFERING

OfferingID

Service Offerings

V_DM_DATE

DayID

Start Date

V_DM_PERIOD

PeriodID

Periods

V_DM_OFFERINGOBJECTIVE

BSObjectiveID

Objectives

V_DM_SERVICE

ServiceID

Services

V_DM_COSTDRIVER

CostDriverTypeID

Cost Drivers

V_DM_BUSINESSINITIATIVE

BusinessInitiativeID

Business Initiatives

V_DM_OFFERINGATTRIBUTE

BSAttributeID

Attributes

V_DM_OFFERINGOBJECTIVE
FACT

BSObjectiveID,
PeriodNo

Objectives for Service Offerings

V_DM_OFFERINGCOSTDRIVER
FACT

BSPriceElementID, PriodNo

Cost Drivers for Service Offerings

V_DM_OFFERINGSERVICEE
FACT

BSServiceID,
PeriodNo

Component Service for Service Offerings

V_DM_BUSINESSPROCESS

BusinessProcessID

Business Process

Business Initiative Alignment 名前空間のクエリー サブジェクト作成に使用されるビューの概要を次に示します。

データ マート ビュー
プライマリ キー
クエリー サブジェクト

V_DM_OFFERING

OfferingID

Service Offerings

V_DM_BUSINESSINITIATIVE

BusinessInitiativeID

Business Initiatives

V_DM_ BIZINITIATIVEATTRIBUTE

BSAttributeID

Business Initiatives Attributes

Business Process Alignment 名前空間のクエリー サブジェクト作成に使用されるビューの概要を次に示します。

データ マート ビュー
プライマリ キー
クエリー サブジェクト

V_DM_OFFERING

OfferingID

Service Offerings

V_DM_BUSINESSPROCESS

BusinessProcessID

Business Process

V_DM_ BIZPROCESSATTRIBUTE

AttributeID

Business Process Attributes

[Service Agreements] フォルダのクエリー サブジェクト作成に使用されるビューの概要を次に示します。

データ マート ビュー
プライマリ キー
クエリー サブジェクト

V_DM_ACCOUNT

AccountID

Accounts

V_DM_ORGUNIT

OUID

Organizational Units

V_DM_AGREEMENT

AgreementID

Service Agreements

V_DM_DATE

DayID

Start Date

V_DM_OFFERING

OfferingID

Service Offerings

V_DM_PERIOD

PeriodID

Periods

V_DM_AGREEMENT
VERSIONS

AgreementLogID

Service Agreement Versions

V_DM_AGREEMENT
OBJECTIVE

AgreementObjctiveID

Objectives

V_DM_SERVICE

ServiceID

Services

V_DM_COSTDRIVER

CostDriverTypeID

Cost Drivers

V_DM_ORGUNIT

OUID

Organizational Units

V_DM_AGEEMENT
OBJECTIVEFACT

AgreementObjectivID, PeriodNo

Objectives for Service Agreements

V_DM_AGREEMENTCOST
DRIVERFACT

AgreementPriceElementID, PeriodNo

Cost Drivers for Service Agreements

V_DM_AGEEMENTSERVICE
FACT

AgreementServiceID, PeriodNo

Component Service for Service Agreements

標準レポート パッケージの更新

標準レポート パッケージをサポートするレポーティング データベース内の全テーブルは、毎回の ETL サイクルで切り捨てられ、すべて更新されます。レポートの内容は、ETL サイクル完了後すぐに更新され、表示可能になります。ETL の処理中、事前作成されたレポートの実行はできません。

Request Center データ マートの更新

Request Center データ マートのビジネス ビューを提供するカスタム レポート パッケージのデータベース コンテンツの更新には、いくつかの Cognos および Service Portal コンポーネントが必要です。

全パッケージの Service Portal ETL プロセスは、アプリケーションのインストール手順の一部として、Cognos データ マネージャ ランタイム コンポーネントを使用してレポーティング サーバに展開される実行ファイルを生成します。これらのスクリプトは、 Cognos SQL を使用して OLTP ソースからのデータを読み取り、異なるデータベース環境間で、さらに優れたカタログのポータビリティを実現します。Oracle や SQL Server 専用のコードは、OLTP ソースで作成されるビューに抽象化されます。Data Manager スクリプトには、Service Portal データベース(ソフトウェアの国際化をサポートしている)内に格納された特殊形式文字列の変換を扱うための User Defined Function(UDF)も含まれています。UDF はまた、HTML タグがディクショナリのキャプションやフィールド ラベルに含まれている場合に、データからクリーンアップします。HTML ページのヘッダーやフッターのように Demand Center データに含まれる HTML タグは変更されません。

Service Portal 要求レコード(OLTP パフォーマンス最適化のために圧縮された独自形式で格納されている)からのサービス フォーム フィールド レベル データを標準のリレーショナル形式に抽出するには、カスタム プログラムが必要になります。このプログラムは Service Portal アプリケーション サーバで動作します。

カスタム レポート データ プロジェクトの作成と保守には、別にカスタム プログラムが必要です。このスクリプトは、Cognos Framework Manager SDK を使用して、各カスタマー サイトが Reportable と選択されたサービスとディクショナリをもとにしたカスタム レポート プロジェクトを動的に作成します。この動的構造とコンテンツは、標準データ マート ファクトとディメンションに追加され、カスタム レポート プロジェクトで使用可能なデータ マートを作成します。

生成された実行可能ファイルは、バッチ実行のジョブ ストリームに並べられるはずです。ジョブ ストリームの詳細な構造は、インストールと設定がなされているレポーティング コンポーネントによって異なります(事前作成済みレポートと KPI、およびカスタム レポート データ マート)。

レポーティングのインストールを、データ マートの 1 日 1 回の更新とともに開始するよう推奨します。これは通常トランザクション処理のスローな時間にスケジュールされています。しかし、データ マートの更新は、Service Portal のオンライン使用と同時に、または 1 日に複数回スケジュールされている場合があります。データベース サーバ負荷に影響がある場合、オンライン トランザクション ユーザ向けのパフォーマンスも影響を受けます。インデックスの再作成に伴って一部のレポーティング ユーザがパフォーマンスの一時的な低下を報告する可能性がありますが、通常影響は一時的なものです。

カスタム レポート パッケージとサービス ポートフォリオ レポーティング

Request Center および Demand Center の Advanced Reporting で使用可能なデータ マートをサポートするテーブルはすべて、ETL サイクルごとに増分更新されます。そのため、基本的に、ETL サイクルの間もデータ マートはオンラインのままです。しかし、データベースのアクティビティが増加し、テーブルのインデックスが一時的に使用できなくなるために、パフォーマンスに悪影響が生じる場合があります。

カスタム レポート パッケージのプロセス フロー

カスタム レポート パッケージ作成に使用されるプロセス フローでは、前述のコンポーネントを使用します。根本的な違いとして、追加の Cognos コンポーネントおよびシスコ製のカスタム コードを使用して、データマートで動的に定義されたフォームデータ(レポート可能サービスおよびディクショナリ形式)の包含を扱うことです。

データは、Cognos(Data Manager)ETL スクリプトとカスタム Java プログラムの 2 つの方法でカスタム レポート パッケージにロードされます。次の図に示すとおりです。

図 1-5 カスタム レポート パッケージのプロセス フロー:パート 1

 

フォーム データ カスタム ETL

カスタム Java プログラムは、フォーム データをレポート可能ディクショナリおよびサービスからデータ マート内の対応するディメンションへのロードに加え、ロードされたディクショナリとサービスの追跡も行います。このプログラムの最初の実行では、トランザクション データベース内のデータすべてを、データ マートをサポートする分析的データベースにロードします。後続のサイクルでは、データの増分をロードします。つまり、トランザクション データベース内の新しいデータや変更されたデータだけが、データ マート内で挿入または更新されます。

このプログラムは、実際のデータのロードに加え、新しいレポート可能ディクショナリおよびサービスをチェックし、オブジェクトのリストを更新します。前掲の図で「...マッピングするためのメタデータ」と書かれているこの情報は、その後別のカスタム プログラムで使用されます。このプログラムは、Framework Manager API を使用して Report Designer と Ad-Hoc レポーティングでユーザが使用可能なデータのビジネス ビューを作成します。これにより、レポート可能ディクショナリに割り当てられた名前とその属性がレポーティング ツール内で正確に表示されるようになります。

Data Manager ETL

DataManager ETL は、静的に定義された(ディメンションまたはファクト)データを OLTP データベースから、データ マート内の対応するディメンションとファクトへロードします。ロード プロセスは増分によります。最初にこのプロセスが実行される場合、トランザクション データベースから使用可能なデータすべてがロードされます。後続の実行では、前回の ETL 実行以降に挿入されたまたは変更されたデータだけがロードされます。

OLTP データベースのソース テーブルにはすべて、タイム スタンプ カラムがあります([CreatedOn]/[ModifiedOn])。これらのカラムは、新しいレコードの挿入時または既存のレコードの変更時に更新されます。ETL プロセスは、ソース テーブルのタイム スタンプ カラムを、ETL プロセスの最終実行日時と比較することにより、新規データと更新データをキャプチャします。

ETL プロセスは、データマート内で新しい行の挿入および既存の行の更新の両方を処理するよう最適化されています。たとえば、サービス要求が送信されると、要求およびそのタスクすべてがデータ マート内に作成されます。その後、タスクが更新されると、既存のタスク ファクトは新しい情報を反映するよう更新されます。

ETL プロセスは次のように動作します。

トランザクション データベースからのデータの選択

OLTP データベースから新規データや更新データを選択します。この選択は、データマートに必要なカラムを含み、ソース データのタイム スタンプと ETL プロセスの最終実行日時でフィルタされる抽出ビューに基づきます。

増分データのステージング領域テーブルへの挿入

OLAP データベースのステージング テーブル(プレフィックス STG で判別)が、OLTP データベースからの新規データや更新データを一時的に保持します。ステージング テーブルは、OLTP テーブルと一対一の対応関係を持ちます。これらのテーブルは、ETL の実行ごとに切り捨てられるため、新規データと更新データだけを含むことになります。

作業領域テーブルの構成

OLAP データベース内の作業領域テーブル(プレフィックス WRK で判別)は、抽出されたデータを保持し、それ以前の ETL 実行分からデータを特定します。作業領域テーブルは、トランザクション データベース内の複数のテーブルから取得されたデータを持つディメンションのためにデータを変換する場合にだけ使用されます。ソースからターゲットへのマッピングについては、「Request Center データ マートのソース データ」を参照してください。

ディメンション テーブルやファクト テーブルからのデータ ロード

ETL では、ステージングおよび作業テーブルの両方を使用して、新規データや更新データをデータマート内の適切なディメンション テーブルやファクト テーブルに挿入します。ビジネス ビューはこれらのテーブルのトップに作成され、パッケージ内のクエリー サブジェクトとして公開されます。

Request Center データ マートのカスタマイズ

Service Portal には、Request Center データ マートの入力に使用する Framework Manager および Data Manager ツールのランタイム ライセンスだけが含まれています。Cognos enterprise development license を持つ Service Portal ユーザは、追加のクライアント専用データを含め、データ マートの内容のカスタマイズを希望する場合があります。

カスタマイズを成功させる鍵は、Framework Manager によって設定され、静的動的両方のコンポーネントを含む、データのビジネス ビューを考慮に入れることです。ユニバーサル ファクトおよびディメンションを特定する静的コンポーネントは、レポーティング サーバ上で次のファイル

<App_Home>¥cognos¥Reports¥CustomReportsDataModel¥ CustomReportsDataModel.cpf

に格納されます。ETL はこのファイルをビジネス ビューの基礎として使用し、その後追加の DictionaryData および ServiceData ディメンションを生成します(どちらのオブジェクトがレポータブルとマークされているかによります)。静的コンポーネントに対するクライアント カスタマイズは、IBM Cognos Framework Manager を使用して適用されます。このようなカスタマイズは、次の ETL サイクルによって生成される新規ビジネス ビューに組み込まれることになります。このようなカスタマイズは、アプリケーションのアップグレードの後、必ず再適用される必要があります。