コーポレートDBという考え方がある。これは前々回述べた共用ＤＢを企業単位、あるいは企業グループ単位に拡張し、経営情報の共有化をはかるものといえる。但し、単なる共用DBではなく、検索する人の属性、すなわち、役職や部署などによって、検索することのできる範囲も異なってくる。コーポレートＤＢは、個々の適用業務システムに支えられ、業務分野横断の企業全体に関わるデータを格納し、経営者を含め、範囲やレベルの違いはあれ、企業の各階層の人がその情報の恩恵に浴するものである。
それに対して、適用業務システムそのものを、そのシステム間の垣根を取り払い、統合的に連携させる仕組みが、ＥＲＰ（Enterprise Resource Planning)である。

＜コーポレートＤＢの概念図＞

ＥＲＰパッケージが最近また注目されている。新しい情報インフラとしてＥＲＰパッケージを活用していこうという動きが、欧米を発信源として、日本国内にもひろがっている。
　すでにＥＲＰパッケージを実際に導入し、効果をあげている企業もでてきており、導入中または導入を検討している企業も増えてきている。もちろん、他社の動向をウォッチしているだけの企業も多いが、ＥＲＰって何？さっぱり分からんという企業人は少なくなっているであろう。つまり、ＥＲＰパッケージをよく知っているかどうかは別として、認知度は確実にあがってきている。
　ＥＲＰパッケージが日本で市場拡大してきているが、これは欧米での市場の広がりを追いかけるような形で拡大している。ＥＲＰベンダで代表的なＳＡＰ社（本国はドイツ）が日本で法人化したのは１９９２年であり、それを嚆矢として１９９６年頃にはじまる１次ブーム、２０００年問題対応に各社が追われた１９９８、１９９９年頃の停滞期を経て、最近は再びブーム化している観があるが、ＳＣＭやＣＲＭといった関連システム、あるいはＢｔｏＢに代表される電子商取引と連携する、企業内から企業間にわたる統合業務パッケージとしてあらわれている。


＜ＥＲＰ適用の例＞

ＥＲＰ市場が拡大している背景としては、バブル経済崩壊以降の産業・経済動向の変化、つまり企業の統廃合、Ｍ＆Ａの活発化や外資の参入、ＩＴ産業の急速な発展と軌を一にしたコンピュータシステム・インフラの日進月歩の進歩などがある。
　情報システムの構築においても、従来のオーダメイド方式、つまりウォーターフォール型で全て手作りでシステム構築するより、パッケージを使い、早くしかも安くシステム構築することが求められるようになってきた。従来型であれば、急速に変わる経営状況の変化を背景に、限られた予算で変化しやすい業務ニーズなど不確定要素の多いシステム要件に対応することが難しく、ややもすれば予算超過や納期遅れを招き、また手作りゆえの膨大な保守作業の負担を強いられることになる。
　このところのＩＴ技術の急速な進歩により、従来のホスト中心、メインフレームによる大艦巨砲から、クライアント・サーバシステム、さらにはＷｅｂシステム、つまりＪＡＶＡのような言語を使用し、Ｗｅｂをベースに開発するインターネット、イントラネット利用のシステムへと急激な転換がなされてきた。
　そうした新技術に対し、対応すべき情報システム要員への教育遅れも指摘されている。


　　　　　　　　　　　　　　　＜ＥＲＰで実現される業務統合＞

さて、ＥＲＰパッケージ導入のメリットは何であろうか？

経営的な観点ではＢＰＲを支援するといったことがあげられ、個々の業務機能単位でも、いろいろなメリットが想定される。
情報システムとしての観点でみると、以下の点に整理できる。

１．短期間で導入できる
　カスタム開発では、ＤＢ設計からアプリケーションの設計、開発、テストを手順に従って行わねばならず、大きなプロジェクトでは２，３年かかることも多い。ＥＲＰパッケージであれば、標準機能を最大限活用すれば、プロトタイプを数回まわして、追加開発分の設計・開発と全体のテストを行えばすむので、期間が短縮される。規模や複雑度にもよるが、１年以内のカットオーバも珍しくない。

２．バージョンアップを継続的に受けることができる
　標準機能に関しては、ベンダー責任でバージョンアップされる。これは機能追加やプラットホームの進化に伴う対応などを含み、メジャーなもので２年に１回程度、マイナーなものは年数回とされる。

３．機能の不足分を追加開発しても、オーダメイドに比べて安く構築しうる
（但し、どの程度追加開発するかなどによる）。また、メンテナンスは標準機能部分でなく、基本的に追加開発部分のみ発生するので、メンテナンス費用が少なくて済む。

逆に、考慮事項としては、以下の点があげられる。

１．パッケージに業務を合わせる部分がある
　ＥＲＰパッケージは、固有の思想によって作られており、また標準機能として提供されているものが、全世界の全業種のユーザに対応している訳でもないので、一部業務のほうをパッケージの機能にあわせることが、追加開発などの費用面を抑えるといった理由から必要になる場合がある。
　パッケージの側にも、ある程度の融通性はあるが、運用の原則や業務手順が存在し、ユーザの要望と合わないことがありうる。

２．実務担当者はパッケージ内容を熟知し、業務設計をしなければならない。
　パッケージの機能に制約をうけることがあるためで、パッケージの標準機能外の機能を盛り込もうとすれば、必然的に追加開発が多くなる。システム化企画の段階では、それほどパッケージ機能は意識しなくてよいが、業務設計を完了するまでには何らかの折り合いをつける必要がある。

追加開発が多くなると、オーダメイドとコスト的に変わらないか、場合によってはコスト増になる。特にパッケージの基本思想にあわないような追加開発、改造は厳禁である。