この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
• 「概要」
• 「Request Center Advanced Reporting」
• 「サービス設計とレポート作成に関するベスト プラクティス」
この章では、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 ユーザに対して強くお勧めします。
Reporting および Advanced Reporting 機能は、別々に入手可能な 2 つのモジュールとしてパッケージされてライセンスされています。
Reporting モジュールは、基本的な Request Center ライセンスにバンドルされています。Reporting モジュールでは、Request Center で処理されるサービス設計、組織エンティティ、およびトランザクション(要求およびタスク)に関する一連の事前に作成されたレポートを提供します。このモジュールでは、一連の主要業績評価指標(KPI)であるグラフも提供されます。これらは、各ユーザのレポート ダッシュボードで表示されるように設定できます。次の項では、Reporting モジュールによって提供される機能について説明します。
• レポートの実行
• 標準レポート設計
Advanced Reporting モジュールは、基本的な Request Center ライセンスへのアドオンとしてライセンス可能です。Advanced Reporting モジュールには、Request Center と Demand Center の両方のデータ マートと、これらのデータ マート内のデータに基づいて単純なクエリーおよびより複雑なレポートを作成するためのツールが含まれています。
次の項では、Advanced Reporting モジュールによって提供される機能について説明します。
• Request Center Advanced Reporting
この項では、Service Portal レポート ソリューションのアーキテクチャについて説明します。ソリューション内での Cognos コンポーネントの使用方法およびそれぞれの役割について関心のあるユーザを対象読者とします。Standard Package で提供されている事前に作成されたレポート実行のための Service Portal レポート ソリューションの使用方法や、独自の Ad-Hoc レポートまたはクエリーの生成に主に関心のあるユーザはこの項を飛ばしても差し支えありません。
Service Portal などのトランザクション システムが動作する同じ環境でユーザにレポートの実行を許可することは、一般的に「ベスト プラクティス」ではありません。レポート、Ad-Hoc クエリー、およびその他の詳細な分析を実行するためのリソース要件は、オンライン ユーザに適切に応答するトランザクション システムを実行するためのリソース要件とは大きく異なります。このため、レポートおよび詳細な分析の基盤を形成するデータは、トランザクション システムから抽出し、レポート専用に最適化された環境にロードするのが一般的です。
Service Portal のレポート専用環境は、2 つの「パッケージ」から構成されます。この章の残りの部分では、これらの内容および使用方法の詳細について説明します。
Standard Reports Package は、事前に作成されたレポートおよび KPI をサポートしています。さまざまな出力オプションにより、タスク、サービス、および要求に基づく測定およびトレンドの情報が提供されます。また、個人、組織、サービス チーム、およびサービス グループを含む Service Portal データの構造に関するレポートも使用できます。事前に作成されたレポートで使用されるすべてのデータも Custom Reports パッケージで使用できます。将来的には、このパッケージは Custom Reports パッケージとマージされます。
Custom Reports Data Package は、タスク、サービスおよび要求関連データに関する Ad-Hoc レポートを作成可能にする「ディメンション」モデルを提供します。Standard Reports パッケージで使用できる測定および属性に加えて、各サイトに設定されたカスタマイズされたサービス フォームにユーザが入力したデータも使用できます。この「Form Data Reporting」(FDR)により、サービス設計者が「レポート可能」として指定したすべてのディクショナリおよびサービスのすべての属性を把握できます。
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 は、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 が含まれている場合、ユーザは事前に作成されたレポートの定義を表示できます。また、必要に応じて、企業の要件をより満たすために定義を変更したり新規レポートを作成できます。
サービス主要業績評価指標は、JFreechart API(JFreechart は Cognos 製品スイートの一部ではなく、オープン ソース ソフトウェア)を使用して生成されます。各 KPI 用に作成された要約データ テーブルを読み取ることによって、オンデマンドでグラフが生成されます。
Advanced Reporting モジュールを使用すると、Service Portal データ マート(データは Request Center と Demand Center からキャプチャ)のデータからカスタム レポートおよびクエリーを作成できます。
Request Center データ マートは、Custom Reports Data Model パッケージに基づいています。このパッケージによって、ユーザはデータ マートにアクセスできるようになります。データ マートには、タスクの実行者やタスクの期間などのサービス、タスク、要求、およびエフォート関連情報が含まれています。カスタム レポート パッケージは、標準パッケージと次の重要な点で異なります。
• カスタム レポート パッケージには、事前に作成されたレポートまたは KPI が含まれていません。Ad-Hoc レポートおよびクエリー用に限定されます。
• カスタム レポート パッケージを使用すると、フォームベースのデータにアクセスできます。これは、ユーザ設定のサービス フォームに表示され、入力されたディクショナリおよび属性から取得されたデータです。
• カスタム レポート パッケージは、異なるタイプのデータ間の関係を保持する柔軟なデータ モデルである「ディメンション モデル」で分類され、Ad-Hoc レポートおよびクエリーの作成を支援します。このモデルの詳細については、「Request Center Advanced Reporting」で説明されています。
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] ページの上部にあるタイトル バーには、次の表にまとめたユーザ オプションがあります。詳細については、以降の項で説明します。
|
|
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] リンクの直下のアイコンから使用できます。
レポートを実行すると、常にパラメータ画面が表示され、レポートに含めるデータの条件を指定できます。フィルタ条件は、レポートによって異なります。パラメータ画面は次の例のように表示されます。
|
|
||
|
|
ステップ 1 レポートにすべての適用可能なデータを表示するように指定するには、「%」を入力します。レポートおよびレポートのフィルタ/パラメータに精通している場合は、ここに値を入力できますが、必須ではありません。「%」を入力すると、すべての使用可能なフィルタ オプションが下の [Results] ボックスに表示されます。たとえば、Service by Service Teams のレポートでは、[Results] ボックスにすべてのサービス チームのリストが表示されます。
ステップ 2 レポートの内容を指定するには、レポートに含める [Results](この場合はサービス チーム)を選択して、[Insert] ボタンをクリックします。これにより、これらのオプションが [Choices] ボックスに移動されます。アスタリスクは、最低でも 1 つの選択が必要なことを示しています。
ステップ 3 このレポートに対するオプション選択が完了したら、画面の下部の [Finish] ボタンがイネーブルになります。[Finish] をクリックして、レポートを実行します。
ステップ 4 または、レポートによっては複数のフィルタが必要になります。たとえば、人別に分類されたレポートの場合、まずレポートに表示する組織を指定してから、これらの組織中で必要な人を指定するように求められる可能性があります。この場合、[Next] および [Previous] ボタンはイネーブルになります。[Next] をクリックして次の一連の選択肢を表示し、[Results] から必要な項目を選択します。すべてのフィルタのパラメータが指定されると、[Finish] ボタンがイネーブルになります。[Finish] をクリックして、レポートを実行します。
レポートは一連のページに表示されます。各ページの下部にあるハイパーリンクを使用すると、これらのページを移動できます。ページに表示される行数は、対応するレポート プロパティを設定することによって変更できます。レポート ページの上部にあるアイコン バーに使用できるオプションが表示されます。
これらのオプションを次の表にまとめます。詳細については、以降の項で説明します。
レポートを選択したページに戻るには、ページの右上の [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 つあり、各ページの右上のアイコンによって表されています。選択されたビューが強調表示されます。
「List View」がデフォルトのビューです。レポート、フォルダ、およびそれらの内容に精通すると、このビューに切り替える必要が生じることがあります。このビューでは、次に示すように現在のフォルダの内容を単にリスト表示します。 |
このビューを手動で設定する代わりに、[Preferences] ページを使用して、Reporting モジュールの使用時に必ず使用する環境設定を設定できます。環境設定を設定するには、メニュー バーの右上の [My Area] リンクをクリックして、[My Preferences] をクリックします。
[Set Preferences] ページの [General] タブが表示されます。
ページの上部にあるエントリを使用して、デフォルト ビュー(List または Details)を変更したり、そのビューをさらにカスタマイズできます。
ページの下部にあるエントリは、ユーザの場所/ロケールに関係しています。時間帯はレポートのスケジュールを設定するときに使用されます。デフォルトの時間帯は、レポーティング サーバがある場所の時間帯です。分散型の実装では、実行するレポートのスケジュールを容易に設定するために、ユーザの現在の場所に時間帯を設定する必要があります。
英語以外のフォーム データまたはファクト テーブルの内容の表示は現時点ではサポートされていません。製品およびコンテンツの言語は、デフォルト言語である英語に設定する必要があります。
次の表に、Service Portal レポート(最上位のパブリック フォルダの Service Performance Reports で入手可能)、および各レポートが格納されているフォルダをまとめます。
Service Authorization および Service Delivery レポートには、それぞれ承認およびサービスの提供の時点で開始された Ad-Hoc タスクが含まれます。これらのレポートには、要求の配信をキャンセルするユーザまたはサービス チーム マネージャのいずれかによってキャンセルされた要求の一部であるタスクは含まれません。
|
|
|
次の表に、Demand Center レポート(最上位のパブリック フォルダの Business Value Reports で入手可能)、および各レポートが格納されているフォルダをまとめます。
|
|
|
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 機能を使用するには、[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] フォルダには、すべてのサービス バンドルと、サービス バンドルに関連付けられた子サービスが含まれます。パッケージで利用可能なファクトやディメンションに、これらのディメンションを接続することはできません。
通常、ディメンションはファクト テーブルと組み合わせて使用され、ファクトに関するデータをクエリーやレポートに追加したり、詳細条件によってクエリーやレポートの出力をフィルタリングしたりできます。
ServiceRequest ファクトでは、要求および要求されたサービスに関するデータを保持しています。ファクトに含まれている日付および期間属性はサービス要求で利用され、要求(複数のサービス要求を含むことができるショッピング カート)では利用されません。このファクトには、パフォーマンスに関するメトリックが含まれます。これらのメトリックには、要求が SLA を満たしているかどうか、実際または推定の処理時間、要求に関するすべてのディメンションの情報(要求のイニシエータ、カスタマー、オーダーされたサービスに含まれているレポート可能なディクショナリなど)へのリンクなどがあります。
次に、ServiceRequest ファクトと関連するディメンションを示すスター スキーマ図を示します。
図 1-1 ServiceRequest ファクトのスター スキーマ図
Request Center データ マートは、Task-Based ファクトに関する 5 つのビューを提供します。これらのビューの 2 つ(RequisitionTaskFact および ServiceTaskFact)は、主に以前のバージョンの Advanced Reporting との下位互換性を保つために提供されています。これらのビューは自由に使用できますが、多くのレポートで役立つ一部のメトリックまたは計算が含まれていません。
各ビューは特定のタスク セットをグループ化することで最適化されています。タスクを調査する必要があるレポートおよびクエリーは、レポートの要件に最も合う Task-Based ファクトに基づいている場合に最高のパフォーマンスを発揮します。
レポートやクエリーを作成するときは、レポートに含まれるタスクのタイプに最も合う内容のファクト テーブルを常に使用してください。次の表に、ファクト テーブルの内容の概要を示します。
RequisitionTask ファクトに関係しない「サービス」を除く、すべての Task-Based ファクトが同じディメンションに関連しています。次に、関係を示すスター スキーマ図を示します。
図 1-2 Task-Based ファクトのスター スキーマ図
次のファクトおよびこれらのファクトは推奨しません。レポート デザイナーは他のファクトを使用して、すべてのカスタム レポートを作成することを推奨します。
TaskEffortEntry ファクトでは、各タスクにかかる工数に関するデータを保持しています。工数エントリは、人件費、材料などのカテゴリ別に利用できます。一部の実装では工数エントリが不要であるため、このファクトで利用できるデータがない場合があります。
[Organizations] フォルダには、サイトで設定されているグループ、組織、および個人に関する情報が含まれます。ディメンション データやファクト データにこのフォルダ内のクエリー サブジェクトを接続することはできません。クエリー サブジェクト同士の接続のみ可能です。対応するクエリー項目は、[Dimensions] フォルダおよび [Facts] フォルダ内のクエリー サブジェクトにあります。
このセクションの表に、Custom Reports パッケージの [Dimensions] フォルダにあるすべてのクエリー項目(ファクトとディメンションの両方の属性)の概要を示します。このリストにはもちろん、サイトごとに異なるディクショナリベースおよびサービスベースのフォーム データは含まれていません。
Customer ディメンションは、オーダーされたサービスの受益者を説明しています。
ディレクトリ統合の一環として Person 属性へのカスタム マッピングが適用されている場合、このクエリー サブジェクトを構成するクエリー項目の動作は変更される場合があります。次に記載されている説明は、Organization Designer で想定されるデフォルトです。これらのフィールドの一部は、特定のサイトで使用されていない場合には空欄の場合があります。
|
|
Dictionary ディメンションは、フォーム フィールドが入力されたディクショナリを説明するために使用できます。
|
|
ディクショナリがレポート可能として指定されている(1)、または指定されていない(0)ことを示すフラグ レポート可能なディクショナリには、対応するクエリー サブジェクトが [DictionaryData] フォルダの下に配置されます。 |
Keyword ディメンションは、特定のサービスに関連付けられたキーワードを一覧表示するために使用できます。
|
|
Performer ディメンションはタスクを実行する個人を説明します。これには、配信タスク、アドホック タスク、承認タスクおよび確認タスクが含まれます。
ディレクトリ統合プロセスの一環として Person 属性へのカスタム マッピングが適用されている場合、このクエリー サブジェクトを構成するクエリー項目の動作は変更される場合があります。次に記載されている説明は、Organization Designer で想定されるデフォルトです。
|
|
Queue ディメンションは、タスクが割り当てられたキューを説明します。
|
|
|
Requestor ディメンションはサービスをオーダーした個人を説明します。
ディレクトリ統合の一環として Person 属性へのカスタム マッピングが適用されている場合、このクエリー サブジェクトを構成するクエリー項目の動作は変更される場合があります。次に記載されている説明は、想定されるデフォルトです。
|
|
Service ディメンションには、オーダーされる要求や実行されるタスクの対象となるサービスに関連するデータを整理するための階層(サービス チーム、サービス グループ、サービス)が含まれます。Service 属性は、ファクト データに条件を課したり、ファクト データをフィルタリングしたりするためのファクト テーブルと組み合わせて使用できます。
|
|
サービスがレポート可能として指定されている(1)、または指定されていない(0)ことを示すフラグ。レポート可能なサービスには、対応するクエリー サブジェクトが [ServiceData] フォルダの下に配置されます |
|
Service Bundles クエリー サブジェクトでは、アプリケーション リポジトリ内のすべてのサービス バンドルにアクセスできます。
|
|
サービス バンドルがレポート可能として指定されている(1)、または指定されていない(0)ことを示すフラグ。レポート可能なサービスには、対応するクエリー サブジェクトが [ServiceData] フォルダの下に配置されます |
|
TaskType ディメンションは、タスク タイプの説明を提供するために使用できます。
|
|
|
|
CalendarClosedDate ディメンションは、要求やタスクが完了した日付に関するクエリーを構築するための階層を提供します。ディメンション内のクエリー項目を使用することで、完全な日付を選択して、たとえば対象の月または週だけを演算式を使用して抽出するよりも簡単に日付でフィルタリングまたはグループ化できます。
|
|
暦年における月(yyyy-nn 形式。yyyy は 4 桁の年で、nn は 1 ~ 12 の数を表します。例:2008-12)。 |
|
暦年における四半期(yyyy-Qn 形式。yyyy は 4 桁の年で、n は 1 ~ 4 の数を表します。例:2008-Q4)。 |
|
CalendarDueDate ディメンションは、要求やタスクの期日に関するクエリーを構築するための階層を提供します。CalendarClosedDate ディメンションでも同じ日付形式が利用できます。
CalendarScheduledDate ディメンションは、スケジュールされた開始日を許可されているタスクが実際に開始するようにスケジュールされた日付に関するクエリーを構築するための階層を提供します。明示的に開始日が指定されていない場合、スケジュールされた日付は開始日と同じになります。
CalendarStartedDate ディメンションは、要求やタスクが開始された日付に関するクエリーを構築するための階層を提供します。これは実際の開始日を表します。
[Facts] フォルダ内のクエリー サブジェクトは、アプリケーション サービス カタログを利用してログに記録されたタスクおよびサービス要求に関する情報を提供します。
ServiceRequestFact は、オーダーされたサービスに関する情報を提供します。フォルダにより、On-Time および Request Status Counts 用のメトリックがグループ化されています。
|
|
現在の要求が期日どおりに完了した場合は 1、完了しなかった場合はゼロ(0)になります。数は、要求がレポート上でグループ化されるときに自動的に合計されます |
|
All Tasks、Authorizations Tasks、および Delivery Tasks ファクトは同じコンポーネント クエリー項目を保持しています。
• All Tasks は、サービス要求を処理するために実行されるすべての配信タスク、確認および承認を含む、すべてのタスクに関する情報を提供します。
• Delivery Tasks は、アドホック タスクを含む配信タスクに関する情報を提供します。
• Authorization Tasks は、確認および承認に関する情報を提供します。
RequisitionTaskFact は、サービス要求を処理するために実行される、要求レベルの承認および確認タスクに関する情報を提供します。このクエリー サブジェクトはレガシー システムとの上位互換性を保つためだけに提供されています。必要に応じて、All Tasks、Service Delivery Tasks、Authorizations Tasks クエリー サブジェクトを使用してください。
ServiceTaskFact は、サービス要求を処理するために実行される配信タスク、アドホック タスク、サービス グループ承認およびサービス グループ確認に関する情報を提供します。このクエリー サブジェクトはレガシー システムとの上位互換性を保つためだけに提供されています。必要に応じて、All Tasks、Service Delivery Tasks、Authorizations Tasks クエリー サブジェクトを使用してください。
TaskEffortEntryFact は、タスクの実行にかかる工数に関する情報を提供します。
|
|
[Organizations] フォルダには、組織、グループ、個人、およびこれらのエンティティ間の関係に関するレポートを作成できるクエリー サブジェクトが含まれます。これらのクエリー サブジェクトをトランザクション(ファクト)データに接続することはできません。代わりに、タスクまたはサービス要求のデータを含むレポートに組織情報や個人情報といった項目も含めるには、これらの情報を適切なディメンション(Customer、Performer、または Requestor)で使用してください。
Group は、権限またはタスクを各グループ メンバーに割り当てるのではなく 1 つのグループに割り当てることができる、別の個人または組織セット用のコンテナを提供します。グループのメンバーを表示するか、個人が関連付けられているグループを表示するために、レポートに Group および Person クエリー サブジェクトからの項目を含めることができます。
|
|
Person クエリー サブジェクトでは、サービス要求の処理におけるロール(Customer、Performer、Requestor)に関係なく、リポジトリ内のすべての個人にアクセスできます。
|
|
Organizational Unit クエリー サブジェクトでは、リポジトリ内のすべての組織にアクセスできます。
|
|
[Service Bundle] フォルダには、サービス バンドル、関連付けられている子サービス、およびこれらのエンティティ間の関係に関するレポートを作成できるクエリー サブジェクトが含まれています。サービス バンドルは 1 つの親サービスと 1 つ以上の子サービスから構成されています。
Service Bundles クエリー サブジェクトでは、リポジトリ内のすべてのサービス バンドルにアクセスできます。
|
|
サービス バンドルがレポート可能として指定されている(1)、または指定されていない(0)ことを示すフラグ。レポート可能なサービスには、対応するクエリー サブジェクトが [ServiceData] フォルダの下に配置されます |
|
Service クエリー サブジェクトでは、サービス バンドルの一部であるすべての子サービスにアクセスできます。
|
|
サービスがレポート可能として指定されている(1)、または指定されていない(0)ことを示すフラグ。レポート可能なサービスには、対応するクエリー サブジェクトが [ServiceData] フォルダの下に配置されます。 |
|
Task-Based ファクト テーブルでは、タスク期間を測定する 3 つの方法があります。
• ActualDuration は、カスタマーのカレンダーに従って、タスクの実行に要した作業経過時間数を測定します。
• PerformerActualDuration は、実行者のカレンダーに従って、タスクの実行に要した作業経過時間数を測定します。
• DefaultDuration はサービス デザイナーによって指定される数値で、タスクに要する時間を指定します。
• 実行者のカレンダーでは 1 日 9 時間の作業日が指定されている
タスクが完了した時刻(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 モジュール フォルダから実行する以外に、ハイパーリンクからアクセスすることもできます。サービス デザイナーは、アプリケーションのサービス説明、電子メール通知などの領域に適切なリンクを埋め込むことができます。リンクの形式は次のとおりです。
以下のヒントおよびテクニックは、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 時間を引く演算式を使用して、期待されるタイム ゾーンの日時カラムを表示します。演算式は次のようになります。
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 Advanced Reporting の設定に使用できます。
これらのパラメータは、データ マートをインストールする際に指定する必要がある多くのプロパティに対応しています。データ マートの設定とそのインストールのカスタマイズに使用されるインストールおよび設定パラメータの詳細については、『Cisco Service Portal Installation Guide』を参照してください。
データ マートを作成するときに、データ マートが保持するディクショナリおよびサービス ディメンションの最大数を指定します。これらの各ディメンションはデータ マートの個別のテーブルに対応します。ディクショナリまたはサービスの数は、データ マートをインストールした後に増やすことができます。ただし、この手順を避けるためには、必ず直近の導入に対して計画されている現在の要件および機能向上に対応できる十分なテーブルでデータ マートを作成してください。
作成する必要がある各タイプのテーブル数を決定するための「特効薬」はありません。一部のガイドラインは前のセクションで説明されています。サービス デザイナーはすべてのディクショナリを確認し、データ マートに含めるディクショナリを決定して、それらを [Service Designer] > [Dictionaries] コンポーネントの [Reportable] ドロップダウン メニューで [Yes] を選択することで、レポート可能なディクショナリとして指定する必要があります。
Service Portal は、レポート可能として指定され、データ マートに作成されたサービスおよびディクショナリ テーブルの数が指定された数を超過しないように追跡します。次にディクショナリ(またはサービス)をレポート可能にしないと決定した場合は、対応する [Reportable] フィールドを [No] に変更します。これにより、データ マートをロードする ETL ジョブからソース ディクショナリまたはサービスが削除されます。レポート作成フレームワークでは、クエリー サブジェクトをまだ利用できます。ただし、ディクショナリまたはサービス データを保持するテーブルを別のディクショナリまたはサービスとともに使用することはできず、使用中のテーブル数の 1 つとしてカウントされます。
|
|
|
データ マート内のすべてのデータは文字(テキスト)列、数値、または日付(時間コンポーネントを含む)として格納されます。内部ディクショナリからのデータは、次の表で示すように、適切なタイプに変換されます。
|
|
|
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 文字から減らす方法です。文字カラムの最大サイズはすべてのディクショナリ(およびサービス)に適用されるため、この値を減らす場合は注意してください。指定されたサイズよりも長いテキスト データは切り捨てられます。
テーブルがインストール プロセスによって作成された後に、各タイプのカラム数を変更することはできません。
|
|
|
データ マート ディクショナリおよびサービス テーブル内の文字フィールドの最大サイズは、デフォルトで 200 文字に設定されています。これは、ディクショナリおよびサービスにおける、すべてのテーブル内のすべての文字(テキスト)フィールドのサイズです。このプロパティは、最初のデータ マートのインストール後に、Cisco Technical Assistance Center(TAC)から入手できるスクリプトを実行することでのみ変更できます。
文字フィールドには、1 行(テキスト)および複数行(テキストエリア)のフィールドとしてサービス フォームに表されるデータと、オプション ボタンとして表されるデータが格納されています。チェックボックスおよび複数選択のドロップダウン リストで 1 つ以上のオプションをオンにした場合は、オプションがカンマで区切られた状態で、オンにしたすべてのオプションが同じデータ マート文字フィールドに含まれます。文字フィールドの最大サイズを設定する際は、注意が必要です。サイズが小さすぎると、データは大幅に切り捨てられる場合があるため、一般的に説明フィールドおよびコメント フィールドが影響を受けます。サイズが大きすぎると、ETL プロセスおよびレポートの生成の両方のパフォーマンスに悪影響が生じる場合があります。
|
|
|
次の手順に従って、サイトのレポート可能なディクショナリおよびサービスをサポートするデータ マートの設定方法を決定します。
• レポート作成要件を確認して、レポート可能にする必要があるディクショナリとサービスの数を決定します。
• 選択したディクショナリ(およびサービス)を確認して、必要となる各タイプのフィールド(Character、Numeric、Date)の最大数を決定します。
• ディクショナリ(またはサービス)ごとのフィールド数の要件がデフォルトを超過している場合は、各タイプのフィールド数にデータ タイプに割り当てられているサイズ(文字データの場合は DATA_STRING_MAX_SIZE、日付フィールドの場合は 7 バイト、数値フィールドの場合は 20 バイト)を掛けます。結果がターゲット データベースの行サイズ制限を超過している場合は、要件を確認します。
• 設定を書き留め、システム管理者が Advanced Reporting のインストール時にこのデータにアクセスできることを確認してください。
サービス設計手順では、以前に導入したディクショナリおよびサービスの変更を収容するのに最適な方法も検討する必要があります。これらの考慮事項には、Service Portal トランザクション システムへの影響と、データ マートへの影響の両方が含まれている必要があります。
• ディクショナリはレポート可能で、オーダーされたサービスで使用されている。
• データ マート(およびそのメタデータ)はすでに作成され、要求に対する設定が完了している。
ディクショナリへの変更がデータ マートの設定に与える影響にはどのようなものがあるでしょうか。これらの影響は次の 2 つの形で現れます。
• レポート作成メタデータへの変更。つまり、Ad-Hoc Reports および Report Designer でクエリー サブジェクトおよびクエリー オブジェクトとして利用できるディクショナリベースおよびサービスベースのディメンション、およびそのコンポーネント フィールドへの変更。
データ マートのロード プロセスが次回実行されるときに、レポート作成モデル(メタデータ)を作成するジョブは、フィールドをクエリー項目としてディクショナリに対応するクエリー サブジェクトに追加します。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 に対応するクエリー サブジェクトのクエリー項目として引き続き表示されます。ただし、ETL プロセスは、削除された子サービスに対応するフィールド内にデータをロードしません。
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 機能を使用するには、[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] フォルダには、次のクエリー サブジェクトが含まれます。
• Cost Drivers for Service Offerings
Service Offering ディメンションには、各会計年度用に作成された提供サービスの詳細が含まれます。提供サービスは、ビジネス カスタマーに提供された組織固有の IT サービスの集合です。
|
|
Services ディメンションには、アプリケーションで定義されたサービスに関する情報が含まれます。
|
|
サービスがレポート可能として指定されている(1)、または指定されていない(0)ことを示すフラグ。レポート可能サービスには、Request Center データ マートの [ServiceData] フォルダの下に対応するクエリー サブジェクトがあります。 |
|
Start Dates ディメンションでは、提供が開始された日の階層構造が提供されています。これにより、レポートおよびクエリー作成者は、さまざまな日付間隔で容易にフィルタリングしたり、さまざまな形式を使用して日付データを表示できます。このディメンションは、01-Jan-1995 ~ 31-Dec-2025 のすべての日付であらかじめ入力されています。
|
|
Periods ディメンションには、1995 ~ 2025 のすべての会計年度のすべての期間が含まれます。
|
|
Objectives ディメンションには、提供サービスに関連付けられた目標に関する情報が含まれます。
|
|
Cost Drivers ディメンションには、システムで定義されたコスト ドライバに関する情報が含まれます
|
|
Business Initiatives ディメンションには、システムで定義されたビジネス イニシアチブに関する情報が含まれます
|
|
Business Processes ディメンションには、システムで定義されたビジネス プロセスに関する情報が含まれます
|
|
Attributes ディメンションには、提供サービスに関連付けられた属性に関する情報が含まれます。
|
|
このファクトには、会計年度の各期間の提供サービスに関連付けられたコスト ドライバの予測および実際のコストに関する情報が含まれます。
|
|
このファクトには、各期間の提供サービスに関連付けられた実際の提供サービス目標に関する情報が含まれます。
|
|
このファクトには、提供サービスの各コンポーネント サービスに指定された予測および実際の量に関する情報が含まれます。量は期間ごとに分割されます。
|
|
[Service Agreements] フォルダには、次のクエリー サブジェクトが含まれます。
• Cost Drivers for Service Agreements
Service Agreements ディメンションには、特定の提供サービスの IT とビジネス カスタマー間の契約に関する情報が含まれます。
|
|
Accounts ディメンションには、アカウントに関する情報が含まれます。アカウントは、IT が契約を確立するために使用される Demand Center 内のビジネス エンティティです。1 つ以上の組織単位(OU)で構成されています。
|
|
Organizational Units ディメンションには、組織単位(OU)に関する情報が含まれます。
|
|
このディメンションのクエリー項目は、[Service Offerings] フォルダの「Start Dates」ディメンションのクエリー項目と同じです。
このディメンションのクエリー項目は、[Service Offerings] フォルダの「Service Offerings」ディメンションのクエリー項目と同じです。
このディメンションのクエリー項目は、[Service Offerings] フォルダの「Periods」ディメンションのクエリー項目と同じです。
Service Agreement Versions ディメンションには、契約バージョンに関する情報が含まれます。
|
|
Objectives ディメンションには、サービス契約に関連付けられた目標に関する情報が含まれます。この構造は、[Service Offerings] フォルダの Objectives ディメンションと似ています。
このディメンションは、[Service Offerings] フォルダの「Services」ディメンションと似ています。
このディメンションは、[Service Offerings] フォルダの「Cost Drivers」ディメンションと似ています。
このファクトには、期間レベルで契約に関連付けられた予測および実際のコスト ドライバに関する情報が含まれます
|
|
このファクトには、期間レベルでサービス契約に関連付けられた実際のサービス契約目標に関する情報が含まれます。
|
|
このファクトには、期間レベルでサービス契約に関連付けられた予測および実際のコンポーネント サービスに関する情報が含まれます。
|
|
Business Initiative Alignment 名前空間には、次のクエリー サブジェクトが含まれます。
• Business Initiatives Attributes
前述のクエリー サブジェクト間の関係を示す図を次に示します。提供サービスは、0 以上のビジネス イニシアチブを持てます。各ビジネス イニシアチブは、そのまた下に 0 以上の属性を持てます。
このディメンションは、[Service Offerings] フォルダの「Services Offerings」ディメンションと似ています。
このディメンションは、[Service Offerings] フォルダの「Business Attributes」ディメンションと似ています。
このディメンションは、[Service Offerings] フォルダの「Business Initiative」ディメンションと似ています。
Business Process Alignment 名前空間には、次のクエリー サブジェクトが含まれます。
前述のクエリー サブジェクト間の関係を示す図を次に示します。提供サービスは、0 以上のビジネス プロセスを持てます。各ビジネス プロセスは、そのまた下に 0 以上の属性を持てます。
このディメンションは、[Service Offerings] フォルダの「Services Offerings」ディメンションと似ています。
このディメンションは、[Service Offerings] フォルダの「Business Attributes」ディメンションと似ています。
このディメンションは、[Service Offerings] フォルダの「Business Initiative」ディメンションと似ています。
主要業績評価指標(KPI)では、Service Portal サービスの管理に重要と見なされるトレンドまたは統計情報をトレースする早くて便利な方法を提供します。
[Dashboard] オプションは、Reporting モジュールの一部です。これを使用すると、最大 4 つの KPI を表示するようにポータルを設定できます。
次に示すように、使用できる KPI のリストを表示するには、[Configure Dashboard] ボタンを使用します。
KPI 名の右側にあるボタンをクリックして、含める KPI を指定します。次に、[Order] 選択リストを使用して、KPI を表示する順序を選択します。設定が終了したら、[Save] をクリックします。
Request Center または Demand Center パフォーマンスのいずれを KPI が計測するかを指定できます。インストールしていないモジュールの KPI を選択した場合、「No data available」の表示がグラフの代わりに表示されます。
[KPI Administration] オプションは、「Analytics Administrator」のロールを持つユーザが Advanced Reporting モジュールで使用できます。[KPI Administration] オプションを使用すると管理者は、KPI の表示または動作を調整できます。
変更が必要な KPI プロパティは、KPI の表示を定義するプロパティのみです。次の作業を行います。
9 つのメトリックが、Standard Reports Package で使用できるレポート全体で使用されています。これらのメトリックを次の表にまとめ、次の項で説明します。
|
|
多くのカスタマー サービスの実装方法のように、サービス配信のエンド カスタマーである個人の名前は、サービスのオーダー フォームに保存されています。この情報は、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 データベースに保持されるデータから取得されます。属性の概要を次に示します。
|
|
サービスの受け手になる個人(本人が直接オーダーする場合と、カスタマーのためにサービスがオーダーされる場合がある)およびカスタマーのホーム組織単位 |
|
サービスの課金対象組織。オーダーが確認されるとき(要求を保存した後、送信よりも前)に [Bill To: Customer] として別の組織が選択されない限り、サービスのカスタマーと同一です。[Bill To: Customer] として選択可能なのは、[Billable] と指定された組織単位だけです。 |
|
タスクを実行する人(および対応するホーム 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 で次のアクティビティを行う必要があります。
[Request Management] フォルダには、2 つのエージング レポートが含まれ、遅れの日数をもとにタスクを「バケット」に振り分けます。1 ~ 3 日の遅れ、3 ~ 7 日の遅れ、1 ~ 2 週の遅れ、2 週間以上の遅れというバケットが定義されています。レポートは、遅延タスクをキューごとと実行者ごとのいずれかでグループ化します。
このレポートは、基本的にピボット レポートです。ピボットの基準は、開いているタスクの「寿命」です。このレポートを作成するには、次の手順に従います。
• レポートの作業領域に、キュー組織、キュー名、Delivery Tasks ファクトのタスク名といった属性やディメンションを適宜配置します。
• 現在の日付とタスク期日の差(日数)を求めて、タスクの寿命を計算します。
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 機能にアクセスできる基本ロールの概要を次に示します。
データ マート内のデータが正確で、欠落がないことは非常に重要です。これらの品質を測定するためには、データ マート内のデータのソースについて文書化しておくことが大切です。カスタム データ マート内で使用できるクエリー サブジェクトに見られるデータのための OLTP データベース内テーブルを次の表に示します。
|
|
データ マート ETL プロセスは、データ マート データベース内のテーブルのセットを使用して、Ad-Hoc レポートと Report Designer オプションでユーザから見える ServiceData および DictionaryData ディメンションを設定します。これらのテーブルは、カスタム レポート パッケージがインストールされるときに作成され、データがデータ マートにロードされたときに入力されます。
これらのメタデータ テーブルは、Cognos フレームワークでは公開されません。これらのテーブルの内容は、カスタム レポート プロジェクト内のデータのビジネス ビューとして表示される、動的に定義されるディクショナリ ベースおよびサービス ベースのディメンションを指定するために使用します。
次の部分でこれらのテーブルについて説明します。各カラムの説明には抽象化されたデータ タイプを使用します。実際のデータ タイプは、データ マートが置かれたデータベース(Oracle または SQLServer)によって異なります。
DM_FDR_ETLDICTIONARYMETADATA テーブルは、特定のレポート可能ディクショナリ(DictionaryID で識別)を、ディクショナリ データが格納される DM_FDR_DICTIONARY_n テーブル(DictionaryTableName)にマッピングします。また、ディクショナリ内および対応するデータ マート テーブル内で使用されている日付型、数値型、Varchar 型のフィールドの数を追跡します。
|
|
|
DM_FDR_DICTIONARYMETADATA テーブルは、個別のディクショナリ フィールド(属性)(DictionaryID および DictionaryAttributeName で識別)と、ディクショナリ テーブルの特定のカラムとをマッピングします。たとえば、ディクショナリ RC_REQUESTEDBY の属性「LastName」を、データ マート テーブル DM_FDR_DICTIONARYTABLE_10, のフィールド「Field2」にマッピングする(実際には、格納する)ことができます。
|
|
|
DM_FDR_ETLMETADATA テーブルには、レポーティング オプションのインストール時に指定されたカスタム レポート パッケージ設定についての情報、さらにデータ抽出プロセス(ETL)および ETL プロセスのスケジュール実行用の最終更新情報が保持されます。
DM_FDR_ETLSERVICEMETADATA テーブルは、各レポート可能サービスについての情報の格納に使用するテーブルに関する情報を保持します。
|
|
|
DM_FDR_SERVICEMETADATA テーブルは、サービス テーブルのどのカラムでどのサービス属性が入力されたかについてのメタデータ情報、および各カラムの使用名を保持します。
|
|
|
カスタム レポート パッケージに追加されるディクショナリの性質と数、およびその属性は、動的に決定され、Service Portal のインストールごとに大きく異なる場合があります。必要とされる柔軟性をサポートするために、カスタム レポート パッケージをサポートするデータベースには、ディクショナリとその属性およびディクショナリ(フォーム)データを使用したサービス設定に対応するディメンショナル データを保持する、抽象的データ構造が含まれています。ディクショナリの内容は、前述の DM_FDR メタデータ テーブルによってこれらのテーブルにマッピングされます。
アプリケーション内の各レポート可能ディクショナリの属性(フィールド)をキャプチャする、一連のテーブルです。これらのテーブルの数、および各データ型(文字、数値、日付と時刻)のカラム数は、アプリケーション インストールの一部として設定可能です。
各テーブルは、DM_FDR_DICTIONARYTABLE(またはインストール手順で指定された別のパターン)に数値サフィクス「_n」が付された名前になります。各テーブルには、1 から順に番号が付けられます。このテーブルの各インスタンスが、レポート可能ディクショナリを表します。
DM_FDR_DICTIONARYTABLE は、レポーティング ツールでは [DictionaryData] フォルダ内のディメンションのセットとして表示されます。各ディメンションの名前は、対応するディクショナリのキャプションです。(キャプションのないディクショナリではディクショナリの名前が使用されます)。ディメンションの属性は、ディクショナリを構成するフィールドです。フィールドには、1 から順に番号が付けられます。各データ型のフィールド(文字、数値、日付と時刻)の数は、アプリケーション インストール手順で指定します。
|
|
|
レポート可能と指定された各サービスのデータをキャプチャする、一連のテーブルです。このテーブルは、サービスで使用されるすべてのディクショナリ内のフィールドすべてを含みます。これらのテーブルの数、および各データ型(文字、数値、日付と時刻)のカラム数は、アプリケーション インストールの一部として設定可能です。各テーブルには、1 から順に番号が付けられます。
各テーブルは、DM_FDR_SERVICETABLE(またはインストール手順で指定された別のパターン)に数値サフィクス「_n」が付された名前になります。このテーブルの各インスタンスが、レポート可能サービスを表します。
DM_FDR_SERVICETABLE は、レポーティング ツールでは [ServiceData] フォルダ内のディメンションのセットとして表示されます。各ディメンションの名前は、対応するサービスの名前です。ディメンションの属性は、サービス内のディクショナリすべてを構成するフィールドです。フィールドは、サービス内でディクショナリが出現する順に追加されます。各テーブルで変更されたフィールドの数は限られているため(インストール手順で指定するが、物理的にはデータベース制約の制限を受ける)、サービス テーブルは不完全な場合があり、一部のフィールド、実際には一部のディクショナリが切り詰められている場合があります。このため、DM_FDR_SERVICETABLE の扱いには注意が必要です。特に、大量のフィールドを持つディクショナリがレポート可能と指定されている場合や、同一サービス内で多数のディクショナリが使用されている場合には注意が必要です。
|
|
|
レポート可能グリッド ディクショナリなしと設定されたサービスの場合、サービスに対する各要求(要求エントリ)は ETL プロセスによってキャプチャされ、対応する DM_FDR_SERVICETABLE に 1 行のデータとして挿入されます。しかし、1 つ以上のレポート可能グリッド ディクショナリが設定されたサービスの場合、ETL プロセスは DM_FDR_SERVICETABLE テーブルに複数行のデータを挿入します。挿入される行の数は、レポート可能グリッド ディクショナリのうち最大の行数に対応します。
たとえば、レポート可能ノン グリッド ディクショナリ 1 つ(Employee)と、レポート可能グリッド ディクショナリ 2 つ(Contact、Address)を持つサービスがあるとします。このサービスに対する要求が、Contact 内のデータ 3 行、Address 内のデータ 2 行、Employee ディクショナリ内のいくらかのデータを持つと仮定します。このサービスに対してサービス テーブル内にキャプチャされたフォーム データは、次のように見えます。
|
|
|
|
|
|
|
|
|
次のテーブルに、Request Center データ マートに使用され、カスタム レポート パッケージによってユーザに公開されるデータベース テーブルとビューの一覧を示します。テーブルやビューは、対応するクエリー サブジェクトに直接マッピングされます。
|
|
|
サービス(要求エントリ)レベルで実行されるタスク(配信タスク、Ad-Hoc タスク、サービス グループの承認や確認を含む) |
||
データ マートを構成するテーブルは、複数のクエリー サブジェクトからデータを取得するクエリーやレポートのパフォーマンス最適化のためインデックス化されています。ディクショナリ ベースとサービス ベースのディメンションは、これらのテーブルの動的特性のために、インデックスの追加は行われません。
静的に定義されたファクトおよびディメンション テーブルに準備されたインデックスの概要を次に示します。
|
|
|
要求(ServiceRequestFact)は、関連するすべてのディメンション(先に含まれていたスター スキーマに表示)に「内部結合」されます。これは、要求とディメンションの両方からのクエリー項目の使用を試みると、ディメンション内に対応する行を持つ要求だけが表示されることを意味しています。一般に、静的に定義されたディメンションすべてについて、これは要素とはなりません。これらはすべての要求に必要であるためです。たとえば、要求にはカスタマーとイニシエータ、要求されるサービス、要求の提供に関するすべての日付が本質的に必要です。
これは、レポートの作成に密接に関係しています。たとえば、レポートの定義を開始して、カスタマーのセットを選択してから特定期間でフィルタした要求データを追加する場合、その期間にサービスをオーダーしていないカスタマーはレポートから「消える」ことになります。
動的に定義される、ディクショナリ ベースのディメンションでは、これは非常に重要になります。あるディクショナリが特定のサービスで使用されていない場合、そのディクショナリ ベースのディメンションからのクエリー項目を含むレポートには、そのサービスに対する要求が表示されません。
同様に、配信タスク(ServiceTaskFact)およびサービス レベルの承認(RequisitionTaskFact)の場合、内部結合によってファクトがキューを除くすべてのディメンション テーブルに関連付けられます。これらのファクトは、自由な関連付けをサポートする「外部結合」によってキュー ディメンションに結合されます。これにより、サービス設計者はタスクをキューではなく特定の個人や役職に割り当てることができます。タスクがキューに割り当てられなかった場合、レポートには引き続き表示されるものの、キューは空白になります。
要求レベルの承認(AuthTaskFact)の場合も、キューはオプションです。また、承認は要求を構成する個別のサービスに対してではなく要求レベルで実行されるため、サービスは無関係です。
[Organizations] フォルダでは、人、組織、グループについてのレポートを作成できます。Request Center はこれらのエンティティ間の多対多の関係をサポートしています。たとえば、1 人の人が複数の組織(営業部門や複数のサービスチーム)のメンバーになることがあり、1 つの組織は多数の人で構成されています。これらの関係はデータ マート設計に反映されるため、レポート上でこれらのエンティティ 2 つを組み合わせ、いずれかのエンティティでグループ化できます。たとえば、すべての組織についてメンバーをリストするレポートを作成できますし、ある人が所属する組織をすべてリストすることも可能です。
|
|
|
この項では、Service Portfolio Reporting パッケージのクエリー サブジェクト作成に使用されているデータ マート データベースのテーブルとビューの一覧を示します。複数のクエリー サブジェクトからデータを取得するクエリーとレポートのパフォーマンスを最適化するためのデータ マート インデックスの詳細も示しています。
次の表に、ビジネス ビューの作成に使用されるテーブルの一覧を示します。これらのビューは Service Portfolio Reporting パッケージによってユーザに公開されます。
|
|
[Service Offerings] フォルダのクエリー サブジェクト作成に使用されるビューの概要を次に示します。
|
|
|
Business Initiative Alignment 名前空間のクエリー サブジェクト作成に使用されるビューの概要を次に示します。
|
|
|
Business Process Alignment 名前空間のクエリー サブジェクト作成に使用されるビューの概要を次に示します。
|
|
|
[Service Agreements] フォルダのクエリー サブジェクト作成に使用されるビューの概要を次に示します。
|
|
|
標準レポート パッケージをサポートするレポーティング データベース内の全テーブルは、毎回の ETL サイクルで切り捨てられ、すべて更新されます。レポートの内容は、ETL サイクル完了後すぐに更新され、表示可能になります。ETL の処理中、事前作成されたレポートの実行はできません。
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
カスタム Java プログラムは、フォーム データをレポート可能ディクショナリおよびサービスからデータ マート内の対応するディメンションへのロードに加え、ロードされたディクショナリとサービスの追跡も行います。このプログラムの最初の実行では、トランザクション データベース内のデータすべてを、データ マートをサポートする分析的データベースにロードします。後続のサイクルでは、データの増分をロードします。つまり、トランザクション データベース内の新しいデータや変更されたデータだけが、データ マート内で挿入または更新されます。
このプログラムは、実際のデータのロードに加え、新しいレポート可能ディクショナリおよびサービスをチェックし、オブジェクトのリストを更新します。前掲の図で「...マッピングするためのメタデータ」と書かれているこの情報は、その後別のカスタム プログラムで使用されます。このプログラムは、Framework Manager API を使用して Report Designer と Ad-Hoc レポーティングでユーザが使用可能なデータのビジネス ビューを作成します。これにより、レポート可能ディクショナリに割り当てられた名前とその属性がレポーティング ツール内で正確に表示されるようになります。
DataManager ETL は、静的に定義された(ディメンションまたはファクト)データを OLTP データベースから、データ マート内の対応するディメンションとファクトへロードします。ロード プロセスは増分によります。最初にこのプロセスが実行される場合、トランザクション データベースから使用可能なデータすべてがロードされます。後続の実行では、前回の ETL 実行以降に挿入されたまたは変更されたデータだけがロードされます。
OLTP データベースのソース テーブルにはすべて、タイム スタンプ カラムがあります([CreatedOn]/[ModifiedOn])。これらのカラムは、新しいレコードの挿入時または既存のレコードの変更時に更新されます。ETL プロセスは、ソース テーブルのタイム スタンプ カラムを、ETL プロセスの最終実行日時と比較することにより、新規データと更新データをキャプチャします。
ETL プロセスは、データマート内で新しい行の挿入および既存の行の更新の両方を処理するよう最適化されています。たとえば、サービス要求が送信されると、要求およびそのタスクすべてがデータ マート内に作成されます。その後、タスクが更新されると、既存のタスク ファクトは新しい情報を反映するよう更新されます。
OLTP データベースから新規データや更新データを選択します。この選択は、データマートに必要なカラムを含み、ソース データのタイム スタンプと ETL プロセスの最終実行日時でフィルタされる抽出ビューに基づきます。
OLAP データベースのステージング テーブル(プレフィックス STG で判別)が、OLTP データベースからの新規データや更新データを一時的に保持します。ステージング テーブルは、OLTP テーブルと一対一の対応関係を持ちます。これらのテーブルは、ETL の実行ごとに切り捨てられるため、新規データと更新データだけを含むことになります。
OLAP データベース内の作業領域テーブル(プレフィックス WRK で判別)は、抽出されたデータを保持し、それ以前の ETL 実行分からデータを特定します。作業領域テーブルは、トランザクション データベース内の複数のテーブルから取得されたデータを持つディメンションのためにデータを変換する場合にだけ使用されます。ソースからターゲットへのマッピングについては、「Request Center データ マートのソース データ」を参照してください。
ETL では、ステージングおよび作業テーブルの両方を使用して、新規データや更新データをデータマート内の適切なディメンション テーブルやファクト テーブルに挿入します。ビジネス ビューはこれらのテーブルのトップに作成され、パッケージ内のクエリー サブジェクトとして公開されます。
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 サイクルによって生成される新規ビジネス ビューに組み込まれることになります。このようなカスタマイズは、アプリケーションのアップグレードの後、必ず再適用される必要があります。