企業(yè)の全面的な情報(bào)化時(shí)代の到來――創(chuàng)造価値を集積し、集積して知能を生み出す（6）

ERP、CRMおよびSCMを単一のデータベースに構(gòu)築できるかどうかは、非常に重要である。

ビジネスの場面があるので、特に無視されがちです。

例えばCRMの終端としての「見積書の問い合わせ」や「契約」の一環(huán)として、ERP注文の処理の前段となります。

企業(yè)が孤立したCRMやERPシステムを持っているなら、「市場活動－マーケティング－見積もり協(xié)議－契約書－注文書－運(yùn)送－明細(xì)書－アフターサービス」の完全な流れは人為的に引き裂かれ、一方のデータベースの変化はまったく別の方向の同期変化を誘発することができない。

管理層が見ているのはいつもお客様の関係の不完全な部分だけで、360°の理解ではありません。

同じ理屈で、SCMは共同ビジネス管理部分としても、ERP、CRMと同じデータベースに構(gòu)築してこそ、情報(bào)の同期化が可能となる。

Oracleシステム構(gòu)造において、いずれかのアプリケーションのユーザがデータベース更新のための操作を?qū)g施した場合、中央データベースの一つの関連データベーステーブルまたは複數(shù)の関連データベーステーブルに該當(dāng)する更新が行われ、これらの更新された情報(bào)は直ちにこれらの情報(bào)を必要とする他のアプリケーションに提供される。

このシステムはOracle Trading Communnity Architecture（Oracle取引コミュニティ構(gòu)築）であり、取引コミュニティのメンバーに統(tǒng)一した記録構(gòu)造を提供するように指示します。これらのメンバーは取引先、従業(yè)員、サプライヤー、ビジネスパートナーを含みます。

互いに関連しないアプリケーションを組み合わせて作られたハイブリッドシステムの構(gòu)造の中で、物事はそんなに簡単ではありません。

このシステム構(gòu)成では、一人の販売員がCRMマーケティングアプリケーションを使ってデータを入力することを想定し、これらのデータは一枚または複數(shù)の販売データテーブルを更新する。

しかし、事件はここで終わったわけではない。

例えば、これらのデータが連絡(luò)先に関係している場合、ハイブリッドシステムは、連絡(luò)先データを含むすべての他のデータテーブルに対応する更新を有効にしなければならず、これらのデータテーブルがどのアプリケーション（あるいはERP）に屬するかに関わらず、またはそれらのデータテーブルを同期から逸脫させて、信頼できなくなる2つの困難な狀況に直面するだろう。

さらに、このようなデータテーブルの中には、各連絡(luò)先に屬性Aが記録されているものがあると想定していますが、他のデータテーブルにはこの記録がありません。

今、システムはどのようなデータテーブルが更新されるかを知る必要があります。

このような複雑さが解決できるとしても、一部のデータテーブルはすでに更新されていて、他のデータが更新されていない場合は、まだ一定の危険があります。

このような更新システムが改善されるとしても、メッセージ仲介器が必要となり、忙しい時(shí)間をかけて、メッセージを繰り返したり、更新したりする必要があります。また、このプロセスにおいて、貴重な処理時(shí)間を優(yōu)先的に占用する必要があります。

一方、Oracleのようなシステムでは、これらの処理時(shí)間は他の目的で利用できる。

もちろん、これらの複雑さは理論的には避けられます。

しかし、このようにすれば、システムが仕事を始める前に、必ず大きな費(fèi)用を払って、長い時(shí)間を遅らせます。

私たちはERP、CRMまたはSCMのようなすべての部分の応用は実はすべてその管理対象が一致しているため、全體として扱われるべきだと思います。

Oracleは自分のすべてのアプリケーションを単一のデータベースに構(gòu)築し、「電子商取引用スイート」と呼んでいます。その目的はもちろん、企業(yè)がより簡単に完全なビジネスプロセスを?qū)g現(xiàn)できるようにすることです。