各プラットフォームの構造
それでは、各プラットフォームの構造を見ていきます。
まず、エンドユーザが業務処理や情報へのアクセスなどを行なうための入り口であるポータルがあります。また、ポータルは内外の関係者との情報交換や情報共有を行なう連携の場でもあります。
従って、連携の範囲により、Personal、Group、Companyに分かれ、情報の処理形態により、Business、Analysis、Knowledgeに分かれます。従来この領域はグループウエアと呼ばれるものが主流を占めていましたが、これからはCMSを使ったブログやHPのようなWebサイトがその機能を担うことでしょう。
次に、出力系であるレポート管理システムがあります。
いまは帳票レスの方向へどんどんシフトしていっていますが、法定帳票や一覧性を要求されるチェックリストの類などはなかなかなくなりません。
また、開発のとき意外と手間がかかるのも帳票ですし、運用における面倒臭さもつきまといます。このレポート管理はどちらかというと業務アプリケーションごとだったり、エリアごとだったりと個別の対応にまかされていて、またデータ形式もばらばらだったりと非効率的であることが多い。
ここでも、フォームのデザインを開発する機能、それを使って実際の帳票を作成する機能、できた帳票を仕分して配信する機能、また電子帳票化する機能などに構造化する必要がある。さらにそれらを統合的に管理する仕組みを持つことが望まれる。
最後にデータ活用という意味で全社的なデータウエアハウスの構築が必要になる。
データにもさまざまな性格をもったものがあり、また使われ方もまちまちであるため、それらに適したデータベースが配置され、各データベースが整合性をもって統合化された形を作ることが重要である。
会社のリソースとしてのマスタDB、業務アプリケーションを動かすためのトランザクションDB、そこから、情報活用に必要なデータを集約したセントラルデータウエアハウス、また用途に応じて使いやすいように抽出されたデータマートに整理される。さらに、最近では、ネット上（外部サーバー）にある各種データも使われるようになってきている。
