プロジェクト概要

　各企業において情況が異なることから、一律に定めることはできないが、情報系データの整備が整っていないケースを想定して具体的な作業工程を確認してみる。 　まず、データの可視化という意味では、主たるプロジェクトとして企業価値を高めることが見込めるDWH／DMの構築が考えられる。DWHとDMはそれぞれ目的は異なるが、データの蓄積場所であることには変わりがない。しかし、実際にDWH／DMは直接的に企業価値を高める施策ではないため、プロジェクトの計画段階で企業にとって必要な情報に対しステークホルダーや分析対象ごとにKPIを設定することから始まる。その後、各KPIが必要とするデータ項目をグラニュアリティに留意を払って定義する（構築後のイメージは図4）。

図1　IT戦略として備えるべき要素

　似た作業ではあるが、情報系システム構築（DWH／DM）においては帳票イメージのみで要件を確定し蓄積場所に格納してはならない。なぜならば、将来帳票は変わる可能性があり、帳票はあくまでKPIを選定していく中で使用する材料の1つに過ぎず、網羅性を鑑みていないからである。
　つまり、企業が社内リソースの各階層に必要なKPIを定義することにより、KPIを算出するためのデータ項目がグラニュアリティを伴って定義され、企業の自己診断である各KPIから必要データの項目、レベルを定義することができることになる。

　よって、この工程を踏むことにより、企業にとって価値のあるデータを収集し分析する土台を準備作業のみならず即効性のあるソリューションと同時に実装することが可能になる。しかしながら、ここで留意すべきことは情報系で必要とするデータを定義した場合、そのデータを業務系、業務アプリケーションが提供できることが前提になっていることである。つまり、収集対象に選ばれた業務系、業務アプリケーションについては、データ抽出の可否の判断と将来業務側の変更が生じた場合、情報系への影響を最小限に留める工夫を行っておくことが望まれる。それには、業務系でのデータモデリング作業と情報系でのメタデータ管理が有効だ。メタデータ管理については、変更箇所の特定を含めツールによって効果を高めることができるが、それに先立ち、業務系データモデリングを行うべきである。手順としては、次のようになる。

ステップA　画面や業務帳票／プルーフの項目分析
ステップB　各マスターのコード標準化ルール／管理用属性要素の確認
　 ステップC　ER図の作成（可能データ／従属データまで意識し、データの関連性及び一意識別性が定義できる）
ステップD　情報系への出力口の定義と情報系で定義されたグラニュアリティとのフィットギャップ確認、となるが情報系構築を伴わない場合は、ステップDは省くことになる。

　最後にまとめとして、プロセス∥業務系、データ∥情報系と定義し、自社のシステムを可視化し柔軟性を持たせることが、統合のみならず企業価値向上においても業務との融合においても必須である。ただし、幅広い意味でEA〈※注7〉の考え方にもつながるが、これらの投資対効果が直接的に測定し難いため、自社の情況を理解し改革プログラムに照らし合わせ実施することが望ましく、該当するものがない場合は、業務系の整備は業務への変革インパクトが大きいため、情報系の整備から行うべきであると結論付ける。

〈※注7〉 エンタープライズ・アーキテクチャ。構造を体系化し全体と構成要素の相互関係を明確化し、基本理念・設計思考を含めて企業活動の全体最適を実現するアーキテクチャモデルを設定することにより、業務やITシステムなどの標準化を進めること。