レポート戦略の定義

組織では、意思決定を行うために、レポートやビジネスインテリジェンスを必要としています。 時には、政府や業界の標準によって、レポート作成のニーズが高まることもあります。 例えば

• 経営陣は、ビジネスの戦略的意思決定を行い、組織のパフォーマンスをモニタリングし、そのデータに基づいて行動を起こすために、ダッシュボードレポートと主要業績評価指標（KPI）を必要とします。
• ラインマネージャーは、チームが業務のサービスレベルアグリーメント（SLA）を満たしていることを確認するレポートを必要とします。

レポーティング戦略を定義して、全体的なレポーティング戦略を決定する際は、企業で重要な意思決定を行うために使用するレポートをリストアップすることが役立ちます。

レポートをリストアップできたら、ユーザーの役職とそれぞれの役職でビジネス上の意思決定に使用するレポートを分類したマトリックス表を作成します。 たとえば、様々なユーザーのスループットレポートを作成できます。

• ラインマネージャーは、チームメンバーのスループットを示すレポートを使用します。
• マネージャーは、レポートを使ってアサインメントのルーティングを最適化します。
• 経営陣は、特定の期間におけるスループットのサマリーを見たいと思うかもしれません。 このレポートにより、経営陣は個々の部門の業績を詳しく調べ、今後数か月にわたって必要になる人員の配置を計画できます。
• 個々のチームメンバーは、自分のスループットの指標を見て、自分の目標達成にどれだけ近づいているか把握し、インセンティブの獲得を目指して努力できます。

どのくらいの頻度でデータを配信する必要があるかを特定します。 調査結果に基づいてレポートのスケジューリング設定、エージェントのスケジュール、データページの更新戦略などの設定が決定されます。 また、通貨要件などのその他の要因も、戦略に影響を与える可能性があります。 たとえば、為替レートを掲載しているデータページがある場合を考えます。 このデータは1時間ごとに更新する必要があります。 また、データページのソースとなるレポートには、リフレッシュストラテジが必要です。

頻度に関連して、データストレージや可用性の問題があります。 その対応次第では、データアーカイブやテーブルパーティショニングのアプローチの設計が変わります。 データアーカイブ戦略を導入し、テーブルのパーティションを分割することで、レポートの長期的なパフォーマンスを向上させることができます。

この質問には、誰がそのデータを必要としているのか、何のためにレポートを作成するのか、という点が関係します。 既存のレポート要件により、レポートにどのようなデータを含めるかが決まります。 各レポートの必要性について調査していくうちに、レポートデータがまったく必要でないことが分かるかもしれません。 下記のような例があります。

• 調査の結果、組織の中で誰もそのレポートを見ていない、またはそのレポートを判断材料にはしていないことが判明するかもしれません。

一方で、新しいレポートを導入する機会ともなる可能性があります。 下記のような例があります。

• 現在のビジネスプロセス管理システムでデータを抽出できていないため、部門で必要なレポートを作成できないのかもしれません。

Pega Platform™には、アプリケーション内でレポートデータを収集するためのオプションがいくつか用意されています。 どの戦略が推奨されるかは、実行するレポートに依存します。

• トレンドレポートやビジネスインテリジェンス（BI）レポートが必要な場合は、データウェアハウスの方が適しているかもしれません。
• アプリケーション内のダッシュボードに仕事の割り当て状況を表示したい場合は、チャート機能を備えたレポートディフィニッションが適切です。

レポートのデータにアクセスする場合、どのテーブルにデータがあるか、どのようにマッピングされているかを把握しておく必要があります。 状況によっては、複数のテーブルを結合してデータにアクセスする場合もあるかもしれません。 Pegaでは、データの結合、関連付け、インデックスの宣言、サブレポートのオプションなど、さまざまなオプションが提供されています。 リードシステムアーキテクト（LSA）としては、必要な情報を引き出すために、どの結合メカニズムがより効果的かを判断する必要があります。 たとえば、次のような例が考えられます。

• ケースとサブケースの関係で、親ケースのデータとともにサブケースのデータを表示する。
  • 購入リクエストの発注書をリストする。 親Purchase Orderクラスのケース識別子と子ケースのPurchase Requestクラスのケース識別子を照合します。
• ケースとアサインメントの関係で、システムが特定のケースやサブケースのアサインメントをどのように処理するかを表示する。
  • 特定のケースに対応するオペレーターを表示する。 ケースデータベーステーブルのオペレーター識別子と、アサインメントテーブルのオペレーターID列を照合します。
• ケースと履歴の関係で、パフォーマンスをモニタリングする。
  •  たとえば、特定のケースの完了に要した時間の合計を表示する。 ケースデータテーブルのケース識別子と、履歴テーブルのケース識別子を照合します。
• サブレポート
  • サブレポートは、メインレポートとは異なるクラスで定義できます。
  • サブレポートは、結果のフィルタリングに使用できます。 この方法で、データを含めたり除外したりすることができます。
  • サブレポートは、リストレポートの特定の行に対する集計結果を表示するために使用できます。

Pegaでは強力なレポート機能が提供されていますが、従来のレポートやデータウェアハウスに代わるアプローチも検討できます。 新しいアプローチがレポート作成の要件を満たす最適な方法となる場合もあります。 たとえば、ロボティックオートメーションを使って、外部のデスクトップアプリケーションからデータを収集することができます。 また、データを分析に利用する場合は、適応型および予測型の意思決定機能の利用を検討できます。 ダイナミックなクエリーが必要な場合は、レポートディフィニッションを設定してデータを収集するのではなく、Elasticsearchなどのテキストに対するフリーフォーム検索を利用することもできます。 ビッグデータやNoSQLデータベースの普及に伴い、自由形式の検索が一般的になりつつあります。