自社の"今"を知り、顧客からの"情報やニーズ"を迅速に捉え、経営の舵取りを行う「リアルタイム経営」を実現できる企業こそが、２１世紀に勝ち残る企業の条件だといわれます。

ビジネスプロセス革新協議会（BPIA）は、この「リアルタイム経営」を実現する方法として、EAI（Enterprise Application Integration）に着目し、研究活動を行っております。BPIAは、EAIを「企業のリソースをリアルタイムで把握するために、既存のシステム間を統合するアーキテクチャ」であると理解しています。しかし、情報システム基盤としてのEAIは投資効果の把握が難しく、また、そのアプローチの考え方や方法にはまだ統一されたものはありません。

今回企画したセミナーでは、研究会の成果をもとに、EAIの考え方や適用エリアに関して解説を行い、EAI業界のリーディングカンパニー５社からの事例をご紹介いたします。また、EAIの投資効果のフレームワークを示し、EAIの効果の測り方の一手法を説明いたします。

ビジネスプロセス革新協議会（BPIA）のEAI研究会が２月から発足し、わたしはそのナビゲーターをしていますが、その中間発表という形でスピーチさせていただきます。話の順番としては、企業活動と経営モデルの変化、マネージメントシステムとその実現手段の比較、そしてEAIを使ったソリューションの特長を確認していきます。

　企業活動と経営モデルには、大きく見て四つの変化があると考えています。一つは、「部分最適から全体最適へ」。日本企業が非常に得意とした部分最適は、改善活動というTQCを使い、その中でのクオリティアップ、生産性向上という限られた中での最適化です。しかし、それだけでは企業として競争に勝っていけないということで、トータルなコストを下げ、トータルな競争力を上げる全体最適化が求められてきています。

　二つめに、「Make & SellからSense & Responseへ」。これは、どのような情報をSenseして、それにどう反応していくかという経営に変わっていくということです。

　三つめに、「Asset経営から非Asset経営へ」。インターネットでのｅビジネスが出てきたときから、工場、ビル、土地などすべての固定資産を企業中で持って経営していたAsset経営から、Assetを持たずにいかにアライアンスやネットワークを組みながらスピード経営やっていく非Asset経営に変化しつつあります。

　四つめは、「ビジネスのスピード化」。経営手法や考え方ではなく、もうビジネスのスピードが変わっているのです。コンビニエンスストアなどでは商品を３か月ごとに入れ替えなければならないほど、消費者の嗜好の変化はどんどんスピード化してきてきます。その中でどうやって切り替えるのか、何に切り替えるのか、今後どの方向にいくのかきちんとSenseしなければなりません。この四つの変化は一つの大きな流れの中で起こっているものですから、企業もその流れに対応していかなければいけないということです。

　経済産業省が出した『情報経済アウトルック』を見ると、ＩＴをどのように活用しているかで企業を四つのステージに分けています。

　ステージ(1) は「ＩＴ不良資産化企業群」と呼ばれており、情報システム、PC、サーバーなどは買ったものの、うまく活用できていません。アンケートでは約15％がそのような感触の会社です。ステージ(2) は「部門内最適化企業群」で、特定業務での最適化はやっているというものです。これがいちばんのマジョリティで、66％です。ステージ(3) は、「組織全体最適化企業群」です。今回言っている全体最適のいちばんのポイントになるのですが、ここは約17％です。最後のステージ(4) は「共同体最適化企業群」です。ここでは自社内の全体最適だけでなく、お客様から仕入先までの全体のバリューチェーンの中での最適化を行っています。日本でもわずか２％ではありますが、このような企業もあるのです。

　それぞれのステージにいる企業が将来の景気、もしくは自分の企業の業績についてどう思っているのかを、「上向き」「上向きだけれども将来は不透明」「横ばい」「悪化」という四つのカテゴリーで見ています。そうすると、ステージ(1) の企業は、ほとんどが「横ばい」か「悪化」と答えています。それに対してステージ(2) は、母数として非常に少ないのですが、半分が「上向き」、30％が「上向きだけれども将来は不透明」と答えています。要は、その企業がビジネスモデルとして、どれだけお客から仕入先までを取り込んでいるかが、先行き感や業績感になってくるということです。

　Sense & + Responseに関しては、企業活動が変わってきています。これまではマーケティングに基づいて年間計画を立て、こういう物をこれだけ売ろう、だからこれだけ作るのだというMake & Sellでした。これは部分最適に非常に適したやり方です。会社として幾ら売るのだ、だから何を作るのだと教えれば、あとは生産計画、製造計画、マーケティングに持っていけばいいわけです。

　ところが、世の中が変わってきて、１〜２年という緩やかな変化ではなく、どの企業でも何かやるとしたら半年以内にやらなければいけないといわれるように、どんどんスピードが速くなってきています。しかし、半年で物事をやるためには、市場のリアルタイムな変化をSenseし、それに適確に対応してダイナミックな資源再配分をしなければなりません。

　外資系の強いところは、一度走り始めたら止まれないところです。自分がある能力を出してパフォーマンスしようとすると、一度走り始めたらもう止まれませんから、止まりたければそのトラックから降りるしかありません。乗っているトラックから降りるということは、会社をつぶすという話になってしまいますから、走り続けなければいけません。そうすると、Make & Sellというやり方ではなく、市場にこたえていくSense & Responseというやり方に、どの企業も変わっていかなければなりません。それが今の企業活動の変化では出てきていると思います。

　ここでいちばん難しいのは、Market ShareからMind Shareへというところです。以前はマーケットを中心に、どれだけ売るかを考えて、その目標に対して皆さんがやっていきました。それに対して今の世界は目標を立てにくくなっていますから、自分たちがお客様に何を届けるのか、それぞれの社員が同じ方向を向いてそれに対してどうアクションをしなければいけないか、ResponseをどうとるかというところでMind Shareをしていかなくてはいけないという人の面の難しさがあります。

　三つ目の変化は、従来型企業の解体と再統合です。従来型の経営モデルはAsset経営と呼ばれていますが、いちばん持っているのは工場、生産機能、建物など物的資本です。不動産会社は、この変化でいちばん影響を受けました。Asset経営をしていて、含み資産がこんなにあるといっていたものが、大暴落したことによって、逆にそれが含み損になってしまい、経営を圧迫しています。物の価値は需要と供給に関連してきますから、バブルはどこかではじけるものだとすれば、物の価値でなくブランドや人に価値を置いた経営をしていかなくてはいけません。

　当然、物を作る会社はありますから、物的資本だけを買い集めて、それをベースに経営をし、ブランドカンパニーから物を作るところだけを請け負うのは、EMCSというエレクトリック業界での一つのモデルになっています。半導体のようなものは設備投資が非常に大きいので、会社がばらばらにやっていてもしょうがありません。それを一つにまとめて投資の有効化をしなければいけないところから、このようなモデルができています。しかし、それ以外はこういうものを目指していかなければいけないのではないかと思います。

　人の資本というと、昔はヒューマン・リソースといったものが、今はヒューマン・キャピタルに変わってきています。ブランド資本は、お客様に対してのカスタマー・レスポンス・マーケティングのような、マーケティング資本の変化があります。構造資本は、自社系列だけでやっていたものが、資本の系列関係がなくても、いかにいいところを取り入れて自分の企業の強みにしていくかという経営をしていこうというように変わってきています。このような変化がいちばん大きいと考えています。

　今のような変化があるものと、従来型の企業とどのように違ってくるのかを、マネージメントシステムを中心に見てみます。今、どの記事を読んでも経営とＩＴの融合がいわれていますが、必ずしも経営に追いついていないにしても、基本的に経営とＩＴは時代ごとに融合してきています。

　例えば1970年代はメインフレームの時代と呼ばれ、部門内統合、経営情報の統合などで、その時代に合った経営の要求には何とかこたえるように努力してきました。次はクライアントサーバの時代で、コストを削減しなければいけないという経営の要望になってきます。次はERPに関しては、システムよりもアプリケーション、業務を中心に物事を考えなければいけないというところに対応してきています。そして最近はWebベースです。

　今後は、これはわたしが勝手につけたのですが、Integrationです。これからは自社の中もそうですし、自社の外とも、業務、プロセスをIntegration（連携）しなければいけないことを考えると、アーキテクチャー的にもシステム的にもIntegrationの時代になってくるだろうと考えています。

　このようにＩＴと経営は融合してきたのですが、今はまだ残念ながら従来型のマネージメントシステムがいろいろなところで動いています。

　例えば普通の企業の中での生産の流れは、需要予測をして生産計画を立て、生産、在庫、販売、物流をしていきます。そこでやっていることは、販売データ、製品特性、競合製品、あるいは過去の市場を見て過去データをもとに需要予測をします。当然、将来のトレンドも取り入れますが、それは数値ではありません。

　その需要予測をもとに生産計画を立てます。これは、まず自分のところの資源を用いて生産できるかどうかをみます。資源とは、工場のラインの生産能力などをベースに考えます。そして、計画遂行のための改善、どのように組み直せばよりよく生産できるかという部分最適化をします。

　生産のところでは、着実にその計画を実行していかなければいけません。細かい修正は起きますが、基本的には生産しろと言われたものをいかに作るか、足りなくなったらその翌月にどれだけそれを満たさなければいけないかということをベースに生産されています。

　在庫に至っては、何が届くかは分かりますから、その製品をきちんと保管しなければいけません。オーダーが入ったものは出荷しなければいけません。棚卸しをしなければいけません。在庫の役目としては、この在庫が多すぎて困るとは言いますが、今までの多くの企業ではそれがマネージメントシステムに反映されていませんでした。

　販売に関しても同じです。当然、物を作っているのだから、作った物を売れという範ちゅうからいくと、販売管理も製品ごとの売上目標を持ち、それに対しての予実を見なければいけません。このような営業をやっていると、「売れる物を売っているのだったら営業ではない」とどの会社でもよくいわれると思いますが、自分のところが作っている物を売るのだというやり方です。最終的には物流も、自分たちが管理している範ちゅうでの物流コストだけを最適化したい、安くしたいという部分最適のマネージメントシステムでした。

　これで何が起こったかというと、売れない在庫が山ほどあっても一体だれがアクションするのかはっきりしません。販売の人間にしても営業の人間にしても、売れる物があるのに、売れない物ばかりたくさん押しつけられてもどうするのだというようなところで、今のマネージメントシステムに破綻が来ているのではないかと思います。

　そのような状況がここ数年来あって、失われた10年といわれた中で、企業もアメリカが生み出したいろいろな手法を一生懸命入れようと考えました。

　まず、今までのAsset経営であれば含み益計算でいいのですが、今はキャッシュフロー経営だといわれていますから、管理会計をきっちりして、本当に今幾らキャッシュが回っているかを出さなければいけません（戦略的会計）。また、人が大事だといっていますから、Human Capital Management（HCM）で人材育成をどうやっていこうか。在庫があふれてきた場合には、Supply Chain Management（SCM）をどうやっていこうか。仕入れ先までいうと、Value Chain Management（VCM）をどうやっていこうか。

　先ほどの需要予測から、カスタマーの要求、デマンドに基づいたものを売らなければいけない、サービスをしなければいけないというところとから、Customer Relationship Management（CRM）が出てきて、その中でコストを下げるための戦略的購買、戦略的ロジスティックスが考えられてきます。ひいては、コア・コンピテンシーの経営から、自分のコア・コンピテンシーではないものはアウトソーシングで賄えばいいということで、Assetだったものを外に任せてしまって、非Asset化しようという動きが出てきます。

　アウトソーシング戦略の時代は、システムそのものと運用だけは任せるということでしたが、もう一歩進んでビジネスプロセスアウトソーシングになると、経理業務や人材育成・人事に関しても任せてしまうというような、プロセスごとアウトソーシングしてしまう経営手法になります。

　ただ、分断化されたマネージメントシステムでこれらを取り入れようとしても、情報が入ってきません。その中で、EAIを使った経営革新が一つのやり方として出てくるのではないかと考えています。

　「従来」に対して「未来型」というだけなので、あまり重くとらえてほしくないのですが、今言ったような経営手法をやっていこうと思うと、マネージメントシステムを変えなければいけません。

　サイクリックに物事が流れている中で、例えば販売からこういう物が売れているという情報が来た場合に、それをそれぞれの部門にきちん流したうえで、Responseをするような仕組みを作らなければいけません。先ほど言った経営手法は、この流す仕組みではなく、そういうデータを取ってどのようにアクションしなければいけないかが本に書かれています。では、そのデータをどうやって取るのかというところは、それはＩＴのマターだから経営コンサルタントの範ちゅうではないという書き方で終わっています。

　在庫が一定水準を超え、それでもどんどん作られてきてどうすればいいのかというのを、どこかがSenseして流してやります。そのSenseしたデータがあれば、生産計画を組み直したり、需要予測を変えたり、生産を変えるというアクションが本来は取れるはずです。しかし、先ほどのマネージメントシステムや目標において評価されるのは計画どおりに作ったかどうかなのに、それを作るなと言われたら生産部門は自分たちの目標を達成できません。そこがマネージメントシステムとして取り入れなければいけないところだと考えています。ですから、先ほどの経営手法をマネージメントシステムとして取り入れようとした場合、プロセスとデータのマネージメントシステムを支えるインフラストラクチャーが必要になってきます。

　先ほどの言葉と対比すると、在庫管理をするところは、在庫の保管や棚卸しだけでなく、在庫の過不足も送ってやらなければいけません。それをやらないと、来た製品を入れるために貸し倉庫を借りにいかなければいけません。そんなことがないように、このようなマネージメントシステムをやります。

　このようなマネージメントシステムを実現するためには、どのような手段があるのでしょうか。マネージメントシステムに求められる要件は、いちばんの根本は、リアルタイムでみんなが同じデータを見られることです。見てアクションするかどうかは、指標の問題やその人の能力の問題が出てきますが、まず同じデータが見えないことには、どんなに能力のある人がいてもアクションは取れませんし、違ったアクションを取ってしまう場合があります。そうすると、最低限、データのリアルタイム連携、プロセスの連携、アクティビティのモニタリングという三つの機能が新しいマネージメントシステムでは求められてきます。

　ビジネスのスピード化に関しては、変化への対応能力が求められます。一度作ったら３年間ほうっておけばいいというものではありません。そうすると、短い間でいかに変化に対応しなければいけないかという、変化に対応する迅速性が必要になります。また、幾らでもお金をかけられるかというと、経済性も必要です。そして、この二つを満足するためには柔軟性が求められます。

　要件としてあまり細かくてもしょうがないので、このぐらいのレベルでとどめておきますが、この六つがうまく取り入れられるシステムのインフラを考えなければいけません。

　従来型のレガシーシステムやパッケージをつないでいる基幹システムがあり、周りは本当の実行系のシステムです。お客様ごとに範囲が違いますが、ここに自分たちのコンピテンシーがあるというお客様もありますので、ここはある程度残さなければいけない部分があると思います。それを、ERPを使った場合、全部ＳＩ的にもう一度作り直した場合、あるいはEAIを使った場合の三つのパターンに分けます。

　まずERP型は、モジュール１個から全モジュールと非常に幅広いのですが、管理会計が入り、もう一つぐらい入ると、少なくとも２けた億円はいってしまいます。また、これのいちばん難しいのは、財務会計と管理会計とある業務との大福帳を作らなければいけないことです。今ばらばらになっている会計コード、配布コード、製品コード、原価コードなどを一つに合わせていくには、最低２年ぐらいかかります。

　ＳＩ型は、パッケージではない部分は手作りなので、同じように要件定義からしていって大福帳などを作ると、２けた億円、２〜５年は最低かかってくるでしょう。しかし、２年というスパンですら、今、要件定義したものが２年後に有効なのでしょうか。例えば管理会計を作るといっても、今求められている経営のための管理会計の指標と、２年後の指標が一緒であることはありません。

　では、どうしたらいいかというと、１年以内に作れるような仕組みにするしかありません。管理会計で今作っているものがだめになるのであれば、３か月でその指標を全部組み直せるような仕組みを作りましょう。「もう２年待ってください」ではなくて、３か月でやらなければいけません。ERPやSIのような完全に作り替えるところでそれをやろうとすると、全部のシステムを見直すだけで３〜４か月の時間と１〜２億のお金がかかってしまうことがあります。

　とはいえ、実現手段は幾らでもあります。今、ERPでやっていらっしゃる企業も多いと思います。そこはそこのビジネスモデルに合ったスパンで考えられていて、例えば２年かけて作っても、それが３年間もつようなビジネスモデルであればいいわけです。重厚長大な企業で、いまだに業績もM＆Aを繰り返しながら伸びているところではそのやり方でもいいでしょう。しかし、流通などより消費者に近いところに関しては、自社でどのようなモデルを選ぶかといった中で、EAIというやり方が一つあります。

　今言った話を実現手段として比較表にしてみます。ERPやSIは、完全に凸凹を合わせるように密結合密連携で、引き離そうとするとかなり大変です。当然、密連携はどの機能にも必要になります。データとビジネスプロセスをリアルタイムで連携させることに関しては密連携です。ただ、EAIの違いは、疎結合です。既存のシステムをベースにつなげることができます。データもプロセスも同じような形になります。

　アクティビティのモニタリングに関しては、ERPは、管理会計の数字などで今はアクティビティのモニタリングのためのモジュールが出てきています。SIに関しては、パッケージを買ってくるか、作り込まなければいけません。
　迅速性は、先ほどの２年は少しオーバーかもしれないので、少なくとも1.5年から5年ぐらいかかります。ここで単純に１対１の比較ができないのは、EAIはアプリケーションを作るわけではなく、つなげるためのインフラや仕組みを作って、アプリケーションは既存のものをできるだけ使う、もしくは合わないアプリケーションはパッケージやＳＩをやるからです。そういう観点からいくと、早いものでは半年ぐらいから、一部分ですが、こういうことが実現できます。ERPやSIは、一度に全部実現できるというメリットの差はあります。ただ、そこに払うお金と期間を考えた場合にどうしたらいいかということです。

　柔軟性に関しても、導入後、ERPはパッケージですので、SIと違って非常にメンテナンスが楽なのです。自分たちが作り込んだところのバグは考えなければいけませんが、パッケージ自身のバグはパッケージベンダーが必ずサポートします。ですから、今までＳＩで作っていたお客様がERPに変えると、システムの保守は楽になったと言われます。ただ、新しい要求にこたえられるかというと、そのERPのコンサルタントを連れてきて、今乗っているビジネスプロセスを見直してもらって、新しいプロセスをどう乗せるか考えると、やはり時間とお金がかかってしまいますので、EAIのメリットはそこにあると考えています。

　EAIソリューションの特長は、データの統合に関しては、HUBを設けることによってそれぞれのアプリケーション、データベースと統合できます。ただ、単純にプロセス連携、データ連携したいといっても、今のバッチ型のアプリケーションがそのまま本当にリアルタイムでつなげられるかというと、そのままではいきません。データベースは簡単に連携できるのですが、アプリケーションの連携の部分では難しいので、そこは一つのチャレンジとしては残ります。しかし、そのような機能をEAIは提供しています。

　プロセスの連携に関しても、在庫からデータを飛ばして、どこにどういう形で送らなければいけないかを、データのフォーマットを変えたり、データのプロセスを変えたりしながら送れます。今はここだけだけれども、物流まで行くという話になれば、EAI上でマッピングを少し変えれば、物流のシステムに飛ばすことができます。そこにアダプターを作ってやれば物流システムに取り込むことができるというように、比較的柔軟性に富んだ形でやっていけるのではないかと考えています。

　今日の最後のセッションで投資対効果の話がありますが、EAIも決して安くはありません。最初の取っかかりでいうと、ライセンスとハードを買えばいいという話ですが、それだけではうまくいかない部分もありますから、やはり１けた億円の下から中ぐらいまでは場合によってはかかることをご認識いただきたいと思います。そのようなものをソリューションとして用いることが、自社の今あるビジネスモデルが変わっていく中で経営革新に役立つのではないかと考えています。

　EAIを使った活用パターンは、いろいろなところで皆さんもごらんになっていると思います。特にテレコム（電話会社）は、全世界でｅTOMというテレコムオペレーションモデルを作られて、プロセスバス・アーキテクチャーを中心に置いてリアルタイムでのデータのやり取りをしています。サービスを１個追加したら、ユーザーに対して、それからそのサービスの課金のためのデータ、経理システムにまで瞬時に反映させなければいけませんので、こういうアーキテクチャーがもともと考えられています。

　もっと簡単な例で、ある販売系の受注DBとERPのレガシーの受注ホストがあり、今の会社でレガシーがなかなか置き換えられなくて、受注データが即座に見られないという場合、受注を一度Webで受けて流すようにすれば見られるようになります。そのときのintegrationに、まずEAIを入れ、それをベースに次から次へと連携をしていきます。先ほどのような大きなアーキテクチャーよりも、こちらのほうが各企業においては取っかかかりやすいのではないかと思います。

　岡村製作所は、1945年、横浜市磯子区岡村町に創業し、現在全国に95支店を展開しており「よい品は結局おトクです」をモットーとして、製品をお届けしてまいりました。現在では、快適な空間創造を目指すソリューション企業として、オフィス環境、商環境、物流システム、セキュリティなどの四つの柱で事業を展開しています。

　弊社では、各事業のシステムや商環境のシステム等を入れて、メインフレーム中心のシステムになっています。また、最近はERPのパッケージや各工場単位での仕組みが増えています。社外環境においても、弊社販売店等、配送、取り引き会社、お客様からの受発注情報が電子化されており、短期間で対応しなければなりません。

　このような状況で、現在Point to Point、FTP中心に個別対応のシステムを作ってきましたが、同じようなプログラムが増え、全体としてシステムのメンテナンス工数に時間と費用がかかり、システムそのものの本数が増えることで管理レベルも属人的になり、思わぬ不具合も発生しています。このような状況を打開し、システムの運用コスト、および開発コストを50％に削減し、多様なシステムの連携をスピーディに行える環境を目指して今回EAIを導入しました。

　EAIツールを幾つかのポイントに絞って検討しました。まず、弊社のメインフレームにあるたくさんの資産を有効活用できるという点についていちばんに挙げています。接続形態も多種多様に存在していますので、多様な機能を持っている点も選ぶポイントでした。また、新規に言語を覚えることなく、簡単に操作できるためのＧＵＩ機能を持っている点も重要です。その結果、弊社では今回、ウェブメソッドをツールとして選定し、導入しました。

　STEP１として、５月から着手して８月までを、導入フェーズととらえています。今回、EAIを初めて導入するので、EAIの適用、インターフェースの仕様や開発のしかたについてもこだわって作成しています。STEP２として、９月から12月を開発標準推進フェーズと位置づけ、STEP１のプロジェクトをよりレベルアップすることを目標に現在活動しています。2004年１月以降はSTEP３として、これまで蓄積してきたノウハウをもとに、入り組んだ仕組みをEAIを使ってインフラ統合するというフェーズに充てていきたいと思っています。

　今回のプロジェクトは、情報システム内の開発および運用コストの削減を第一の目標としています。そのため、システムオーナーとしては弊社情報システム部の部長とし、また、レビュアーという形で、各販売系、生産系、物流系の企画担当を入れ、プロジェクトリーダーとして私が入っています。そして、テクニカルサポート、アーキテクチャー、インフラ、インターフェース設計という四つのグループで作業をしています。

　弊社ではアイツーパッケージによるSCMプロジェクトを２月ごろから始めていましたが、今回はそのプロジェクトをインターフェースのパイロットプロジェクトとし、開発手順の策定、インターフェースの技術検証、スキルの習得を目的として活動してきました。弊社にはシステム開発標準フローがありますので、そのフローに基づいてどのフェーズで、どんな仕様書を作成し、レビュー上の注意ポイントはどうかということを中心に検討を行いました。

　ここでは、まず使用するコンポーネントを規定するためのサービスフローを作りました。そして、その中にどういう機能のコンポーネントを配置するのかを定義しています。新規に作らなくてはいけないものについては、ウェブメソッドインターフェースの詳細仕様ということで作っています。これらの仕様をもとにして実装フェーズにつなげています。

　まず、新規業務設計のフェーズでは、先ほどのインターフェース仕様や要件をもとにして標準メッセージを作ります。これのレビューに当たっては、関連しそうな担当を集め、本当にこのレイアウトが全社を意識して作られているのか、このメッセージはこれで本当にいいのかを検討し、チェックしています。

　また、物理設計のフェーズでは、ここで使われるサービスフローとインターフェース仕様をもとにして、このサービスの中に使われているコンポーネントが本当に既存のものがきちんと使われているか、新規に作る部分のインターフェース仕様書がきちんと次の人のことを考えて標準化できているかをメインにチェックする局面を入れています。それを最終的にはコンポーネントのリポジトリーに保管します。

　今回の技術検証はトランザクション連携ということで、ORACLEのメインフレームのアプリケーションを使っています。次に、データベース連携でDB2とORACLEとの連携をしています。もう一つ、FTP連携ということでファイル転送の部分も作っています。簡単に接続についてご説明すると、SCMサーバとしてアイツーのパッケージのサーバがあり、一方にS390のメインフレームを入れ、真ん中にウェブメソッドという今回のEAIのツールを入れて連携するような仕組みになっています。

　今回のSCM側の要件としては、なるべく今作ろうとしているアプリケーションを変更せずにできないかということで、仕組みとしてタイムスケジュールという形で管理しています。スケジュールを使うことによって、一定間隔の情報でSCMサーバのORACLEを監視し、変更分があればそのデータのみをウェブメソッド側から取得し、ブローカーを経由して実際のメインフレームを起動するようなサービスにデータを渡し、IMSコネクト経由で既存のアプリケーション・トランザクションを使用しています。このとき、エラー発生時の処理のため、進捗管理テーブルを新たに作成して状態を管理しています。

　データベースについては、メインフレームのDB2とSCMサーバのORACLEとをダイレクトにつなぐというパターンで作成しました。これについても、先ほどと同様に進捗用のテーブルで接続状態を管理しています。FTPについては、トリガーサービスを使用して受信側の情報を受け、SCMサーバもデータを送る仕組みに作っています。このとき、データをすべて送り終わったらバッチをキックしてほしいという要件がありましたので、この進捗テーブルが正しくデータを送られたかどうかを管理し、すべてのデータが送られた場合にキックする仕組みに作っています。

　今回はコンポーネントの開発にこだわっています。また、接続方法の組み合わせが自由にできるということで、今まで使用できなかったメインフレームのオンライン・トランザクションを直接使用することが可能になりました。それによって接続部分を作る工数がなくなり、コンポーネントの再利用を合わせて半分ぐらいになりました。

　運用面については、単一機能でスキルが習得できるので非常に便利になっています。今回の開発で、約４日間の専門教育を受けた人間が、キヤノンソフトウエア様のサポートを受けて、37本ほどのインターフェースをこの期間内に作成することができました。また、エラー処理をカスタマイズできますので、事象ごとにどんなエラーになったのかも簡単に管理できるようになりました。

　４か月ほど活動してきましたが、常に順調というわけではありませんでした。まず、今回初めてEAIを導入し、当然EAIを導入する知識があまりなかったので、どうしても今までのPoint to Pointの仕組みで設計してしまい、せっかく導入したEAIツールの適用範囲を狭めてしまったこともありました。そこで、まず認識レベルを上げようということで、開発や企画の各担当を集めて説明会を実施しています。この問題もすぐに解決できませんので、アーキテクチャーグループを中心に啓蒙活動を行っていきたいと思っています。また、データボリュームを見込み違いのまま設計・開発をしてしまい、実際に動かしてみると通信時間が異常にかかったりメモリ不足を起こしたりしこともありました。この辺も認識の甘さがあったと思っています。

　最新バージョンでメインフレーム資産を使うことも初めてのケースだったので、オンラインの漢字コードに不具合を生じたり、オンライン・トランザクションで不具合が発生したときの異常処理についても、様々な試行錯誤を繰り返しながら設定をしましたが、何とか期間内に目標を達成することができました。

　まず、標準化では、標準メッセージの推進を挙げています。また、開発のレベルアップということで、コンポーネントに着目し、設計方法のガイド、コンポーネントの再利用のための情報整備を考えていきたいと思っています。メンテナンス時の影響分析についてもきちんと規定してもう少しレベルアップしたいと思います。

　既存システムも統合化しなくては効果が薄れてきますので、現状のプログラムを再度調査しています。そして、メインフレーム資産を有効に活用することを考慮しながら、管理工数を削減するという動きに持っていきたいと思っています。それから、お客様の情報は非常に電子化されており、最近、受発注情報が非常に増えています。この辺の機能をまず標準化し、ある程度のメッセージ化をして、今後システムを作るときにサンプルとして、スピードを上げたいと思っています。

　最後に、今回の仕組みを導入することにより、システムの構成としては、何もかもメインフレームにつなげていた仕組みを、EAIを中心とした集中管理ができるような環境に持っていきたいと思っています。また、プログラム構成も、今までPoint to Pointで直接データをつなげていましたが、これもコンポーネント化することによって管理する資産を圧縮したいと思っています。それにより、運用コストも削減され、メンテナンスするときも非常に早く対応できるのではないかと思っています。

わたしどもEAIセンタは、EAIに関して４年以上前から取り組み、多数の実績を構築させていただいています。本日は、わたしどもの20件ほどの案件の中で、どのぐらいの効果があったのかをご紹介させていただきます。

　もともとEAIやBPMはインフラやシステム基盤ですから、特にエンドユーザー様から見ると、導入効果が非常に分かりにくいのです。既存のシステムで業務がすでに回っていれば、あまり導入の必要性を感じていただけません。しかも最近の投資が冷え込んだ情勢から、さらにこういったソリューションはプライオリティを下げられてしまいます。

　ここ１〜２年、やっとEAI＋BPMの国内事例も多数出てきてはいるのですが、本当の効果がなかなか紹介されていません。されていても、システム開発上の費用効果、開発の期間の効果といったところに着眼されています。しかし、我々はEAI＋BPMを大きくビジネスを変革するソリューションと位置づけ、ビジネスでの効果をしっかり測定していかなくてはならないと考えており、今日はそのご紹介をさせていただきます。

　平均的な開発は半年ぐらいで、多くのEAI＋BPMの案件は３か月から半年ぐらいとご理解いただければいいと思います。長期間かかる開発は、EAIそのものの開発でなく、それをつなぐためのシステム開発のスケジュールに合わせているので長いレンジとなるのです。

　もう一つの着眼点は、非常にリピータブルに開発が進んでいくことです。EAIは最初は接続先数も優先順位が高い、限定したところを中心に統合します。それがうまく効果が出てきますと、徐々にシステム全体、企業全体に波及していくという効果がありますので、２年、３年と継続して開発をやっていただくようになるのがEAI＋BPMの特徴です。

　事例分析の前に、お客様がどのようなところにソリューションを適用しているかを簡単に分類しておきます。ここでは既存の社内システムとつなぐ機能をEAIと呼び、パートナー企業やブラザー企業と接続する部分をBtoBと呼んでいます。さらに、ワークフローだけでなくビジネスプロセス管理機能もBPMと定義します。それから、実際のプロセスの監視をするBAM（ビジネス・アクティビティ・モニタリング）機能があります。この四つの機能で分類し、さらにEAIの中ではフロントオフィスとの結合、バックシステムとの結合といった分類をしています。

　ご紹介する19のお客様の事例は、EAIでバックオフィスのみの統合、EAIでフロントのみの統合、EAIを使ってフロントとバックの統合、EAIとBtoBの機能を使うもの、EAIを使ってシステムを統合し、それらのプロセスを管理するEAIとBPMの組み合わせで使う案件があります。さらには、社内・社外にまたがるビジネスプロセスをBPMでコントロールするような適用もあります。

　導入されたお客様がどのような目的を持ち、実際にその効果があったかどうかを、◎は「非常に大きな効果だった（もしくは期待される）、○は「それなりの効果は期待される」という２段階で表しています。

　◎の多い項目を見ると、シングルインプットを目的に、今まで複数のクライアントや複数の画面から同じようなデータを入力していたのを解消することによって、作業コスト、オペレーションのコストを大幅に削減していると言えます。今までバッチ処理をしていたので作業が遅れていましたが、リアルタイムにできるようになったので、全体として非常に作業効率が上がった事例も多数あります。また、オペレーションの自動化により、注文の内容のチェックを今まで人手でやっていたものを自動化することで大幅にミスが削減でき、ミスのチェックや補正の稼働も削減されたという項目が多くなっています。

　さらに多いのが、注文の手配のスピードアップです。今まではフロントはフロント、バックはバックで個別最適化を進めてきて、組織をまたがると急に効率が悪くなっていましたが、そこに非常に効果を挙げることがこの実績から分かります。同時に、オペレーションコストも削減できます。総じて効果が大きいと言えるのは、BPMを導入している事例と数字的には出ています。

　具体例の一つめは、ＮＴＴグループのOCN様の事例です。こちらはインターネットサービスプロバイダとADSLの申し込みとセットで注文が入ってきますが、その中のADSLの注文部分を複数あるADSL事業者会社に振り分けて注文を出していく社内のEAIとBtoBをBPMでプロセス統合している事例です。

　まず、インターネット、もしくはオペレーターが受け付けて注文が入ってきますと、EAIで注文を取り込みます。そのあと、注文を分割します。分割とはＩＳＰと、ADSLの注文部分を別に取り出すということです。そして、注文を既存のOMS（オーダー・マネージメント・システム）に登録します。この部分でもすでにBPMが入っています。さらに、OMSからADSLの注文だけを取り出し、今度はBtoBでADSL事業者様向けの文字コードや注文フォーマットに変換して注文を送信します。

　さらに、エンドユーザーからも工事の進捗状況の問い合わせが多数くるので、それに対応してADSL事業者の進捗状況をセミリアルに取り込み、既存の進捗管理システムに統合します。場合によっては二つの注文に分けたものを待ち合わせて、両方が完了したら開通という形で処理をすることもEAI＋BPMの機能を使って実現しています。

　実際の効果としては、一つはADSL注文流通の稼動と時間を削減します。今までは１日１回のバッチ処理であったものが自動的かつリアルタイム化され、ファイル出力をして手作業で流通していた部分も自動化され、手作業での不備もなくなり、そのための莫大な修正稼動もなくなります。これがビジネスでの業務的なメリットになります。

　開発コストについては、すべてが既存システムですので、影響は非常に極小化されたもので済みました。開発生産性としては、EAIを導入せずカスタムで作るときに比べて、３割ぐらいは削減されました。

　ここで注目すべきところは、この業務的なメリットは非常に膨大なオペレーションコストを削減していますので、場合によっては億単位レベルの効果が出ています。併せて、リアルタイム化のメリットとして、サービス提供時間が非常に短縮されることによってCSが向上します。新規の顧客を獲得するには膨大なコストがかかりますので、いかに既存の顧客をきちんとケアしていくかというためにも、CSの向上は重要なアプローチではないかと考えています。

　開発のコストはたかだか３割で、総コストが１億円であれば3000万円にすぎません。それに対して、業務的なメリットは億単位レベルにいくので、最初からそこにフォーカスして計画していくことが重要です。

　もう一つは、新光証券様の事例です。新光証券様は、債権のフロントシステムの刷新に伴い、既存のシステムと連携しつつ、また既存の中でメインフレームも徐々に新しいシステムに段階的にマイグレーションしていこうということでした。刷新したフロントとバックのオフィスを従来のようにメッシュで統合すると、また大きなコストがかかるということで、EAI＋BPMの機能を導入いただきました。

　新光証券様は現在開発中ということで、予定の効果となりますが、まず想定される効果としては、最新の約定情報をリアルタイムに取得することによってリスク管理業務の効率化を実現します。さらには、フロント業務の効率化ということで、最新のコンプライアンスチェック情報をバックから持ってくることによって、フロントで最新の情報でチェックができます。さらには、業務全体の最適化が図れます。フロントとバックの役割を明確にして疎結合させることによって重複機能を排除し、開発上の効果も先ほどのOCN様と同じような効果が期待されます。

　弊社の試算では、例えば１件当たりの注文やトランザクションに対して、10〜15分の効率化ができます。それにそれぞれの案件でのトランザクション量をかけると、大きなお客様では年間億単位のオペレーションコスト効果があると考えられます。さらに、顧客の利便性向上、CSの向上（例えば今まで顧客の申し込みに対して、工事日などは後日電話で対応したところが、その場で確認し、その場で対応できるようになる）などは定量的には評価できませんが新規顧客を獲得するコストは既存顧客を維持するコストに比べて何倍もかかることを考慮しますと、ビジネス面での効果が非常に大きいことが分かります。

　一方で、開発のコストは、EAIのみの案件ですと１億を中心としてプラスマイナス5000万ぐらいが平均的な案件です。これに対して、BPMも導入しますと、中心値が２億円ぐらいになってしまいますので、平均でいっても倍ぐらいになります。実質、EAIだけですと、データのインターフェースを設計するのが中心になりますが、BPMもとなると、業務フロー、アクティビティまできちんと設計していく必要がありますのでコストもかかります。しかし、BPMを中心にインテグレーションをすると、２億かかってもビジネスの効果が、例えば年間１〜２億挙がってくればROI的には容易に達成しやすいモデルとなります。

　EAI＋BPMは非常にインテグレーション性が高いため、部品やノウハウの蓄積、開発標準の準備、エンジニアのスキル、さらには業務毎のテンプレートなどソリューションとして提供することがリスクを抑え、価格を抑えることに大きく影響します。従って、コムウェアも実績を積むに従って、必然的に多くの品揃えを行い、今日では当初とは比べ物にならない生産性向上を果たしております。

　EAI導入に関して皆様が失敗しないためにも、まず、ＩＴ戦略としてのゴールは開発コストの削減ではなく、ビジネスでどう効率化をするかであることをしっかり明確にする必要があると思います。そして、実際のビジネスプロセスの改善効果を予測し、開発して運用に入ったあとに実際の効果が測定できる準備もしておく必要があります。さらに、その結果をもとにフィードバックし、スパイラルに改善していくようなＩＴ戦略も必要になります。加えて、ツールとしてはBPMが非常に重要であることから、標準装備をしていること、EAIと別製品を組み合わせるとしてもシームレスであること、さらにはライセンスが安価であることが重要です。

　また、戦略があり、ツールがあり、それを組み立てるインテグレーションでは、開発標準の準備、部品やノウハウの蓄積、エンジニアなどが非常に重要になってくると思います。すべてがうまく同じベクトルでシームレスに融合することで、やっとこのソリューションの効果が発揮でき、このソリューションの真髄はここにあるのではないかと考えています。ぜひ皆様にもご参考にしていただければと思います。

従来、月次ベースの計画を基本的には週次、さらに日次の生産計画の見直しを始めています。もちろん、一つの仕組みで全世界をカバーするという性格上、システムは24時間365日休みなしで動かしています。このために、日本が夜の間もきちんとサポートができるように、ヘルプデスクも一部海外に置いたり、これまでにないような試みを施しまして、何とか24時間運転というハードルも越えています。

　最も重要なのは、システムを一つにした結果として、いろいろな経営データがリアルタイムに入ってくることです。これは後ほどもう少しご説明いたしますが、リアルタイムなデータに基づく経営が、わたしどものねらいのいちばん大きなところでした。それに対してどうなっているのかというところで、ここではKPI、指標の達成状況、それからROIについて少しお話しさせていただきます。

　何項目か書いていますけれども、まず実現しなければいけないのは、お客様にきちんとデリバリーできているかどうかということで、お客様からいただいた要求納期に対しての遵守率です。「11月10日に持ってきなさい」と言われたら、「11月10日にお届けいたします」と、きちんとミートできているかどうかということです。これにつきましては、まだ満足いただけるレベルまではいっていませんが、一生懸命努力しているところです。

　それから、納期回答遵守率というのは、お客様から「11月10日に持ってきてください」と言われまして、「申し訳ありませんけれども、１週間遅れて11月15日になります」と回答を差し上げます。そのいったん回答したことに対してきちんと遵守できているかということが、納期回答遵守率です。

　このほか、リードタイムやサプライチェーンコストがあります。このようなわたしどもの半導体のオペレーションに要する販売費および一般管理費といわれる経費がどのぐらいかかっているかということも、対売上比で何とか落とそうと一生懸命努力しているところで、一つの大きな指標です。もちろん棚卸しについても、内部的に見れば非常に大きな指標です。

　今言ったような指標は、わたしどもの仕組みの中で、達成状況がリアルタイムに分かるようになっています。そのほか、これは社内で実際に使っている画面ですが、例えば全世界の在庫が、どこの拠点に、どういう製品が、どのぐらいあるのか。しかも、在庫鮮度といってどのぐらい滞留しているか。どのぐらいのリードタイムでお納めできているか。あるいは、納期遵守率がどうなっているか。また、品質の情報等々含めて、わたしどもの半導体のオペレーションに関係するトランザクション情報については、基本的にはほとんどみんなリアルタイムに、この仕組みの中で把握できるようになっています。

　それがどうなっているかというところですが、一般的にＩＴ投資に対しての投資効果をどうやるかというのは、各社さんとも非常に悩みだと思われます。わたしどもについても、この仕組みに約200億円投じたと申しましたが、これに対してリターンは何なのかというと、なかなか数字的に表すのは難しいのです。

　いろいろ考えた末にどうするのかというと、売上からサプライチェーンに関係するコストを引きます。これを在庫で割ります。これは何が残るかというと、結局、ＩＴ投資の効果といえば、オペレーションの効率をいかに上げるかというのがいちばん大きなポイントだと思います。この数字はそれを表しているのではないかと、わたしどもは思っています。

　売上が伸びれば、この指標は上がります。在庫が下がれば、指標は上がります。コストが下がれば、この指標は上がります。売上マイナスSCMコストで残るのは、いわゆる販売原価、製造原価です。この差額は利益と原価です。利益はどうかというと、これに直接的にＩＴが貢献するというのはなかなか難しいかもしれません。製造コストあるいは販売コストも、なかなか直接的な効果は出しにくいところです。この売上マイナスSCMコストは、オペレーションの健全性を表す指標ではないかということで、社内的にもいろいろ説明しています。

　「有価証券報告書」にすでに公表されているいろいろな会社のデータを比較してみますと、ＩＴの構築によってこの指標が少しずつよくなってきているというのが何となく分かるという感じです。

　全世界を一つにまとめて、一つの仕組みで動かすと申しますが、各地域、各国で、社内的にはユーザーの要求が多岐多様にわたっています。しかし、基本的にはわたしどものアプローチとしては、この仕組みに合わせましょう、標準的な仕組みに合わせましょう、過去のやり方は捨てましょうということで、かなり徹底的にやりまして、完全にトップダウンアプローチで、わたしどもの「Global-One」という仕組みを導入しています。

大きくいって二つのレガシーシステム（既存の仕組み）があります。一つは製造装置の管理の仕組み、もう一つはロジスティックスの仕組みです。この二つのレガシーの仕組みとうまく連携しながら、このグローバル需給システムを動かそうというアプローチです。

　ここに、本日のテーマにありますように、リアルタイムにデータ交換ができ、しかも既存の仕組みは変更しなくていいという高度な要求を満たすツールとして、TIBCOのEAIが非常に役立っていると思っています。

　それでも、システム導入で道半ばと考えています。わたしどもも、実際にＩＴシステムを導入して約３年かかっていますが、さらに本当にこれが戦力となって効果を出して、うまく使えるようになるには、まだまだかかると思います。導入・稼動で道半ば、これで半分であり、稼動後がまた半分という感じではないかと思います。それと、特に定期的なトレーニング、やはりこれが必須だという感じがしています。

　それから、ＩＴシステムと人間の業務処理能力の乖離があります。リアルタイムにデータが集まっていますが、それを経営者が見てリアルタイムにデシジョンメーキングするかといえば、そんなことはできません。

　データに基づいた意思決定というのは、我々日本人は割と苦手なところでして、まだ社内的にもこれをきちんと使いこなせている人間はそれほど多くありません。常にトレーニングして、リアルタイムに集まってくるデータをもとに適確な判断をするトレーニングというのが、今後もかなり力を入れてやっていかなければいけない大きな課題です。

　結局は、膨大なデータから役に立つデータをいかに作るかということです。今、いろいろなデータがリアルタイムに入ってきます。在庫情報から生産の状況、各製造ラインの進捗状況、歩留まり情報、このような情報が全部リアルタイムに入ってきます。しかし、この膨大なデータをリアルタイムに解析することも難しいですし、リアルタイムに判断するという環境にもありません。

　ですから、今後リアルタイムに集まってくるデータをもとに、適確なタイミングで判断するという社内的な仕組み、カルチャーを醸成していこうと考えています。以前と比べればかなり改善はされていますが、今後とも力を入れてやらなければいけないところだと思っています。
　簡単ですが、以上で説明を終わらせていただきます。ご清聴どうもありがとうございました。

ふだんはベンダーの立場ですが、今日はユーザーの立場で、富士通におけるEAIの活用についてご説明します。話の大きな流れとしては、一つは、どのようなEAIの利用シーンが考えられるか、次に、その利用シーンの中で弊社にどのような導入事例があるか、最後にまとめとして、現状のEAI技術や製品に対しての考察、評価をしてみたいと思います。

　EAIの機能という観点で見ると、大きく四つの利用シーンがあると思います。いちばん下に「接続／通信データマッピング」で、ここはアダプター、フォーマット変換、マッピングなどいろいろなコミュニケーションをやっていく世界です。その上に「コンテンツ制御」があり、EDIやBtoBなどある程度のルールが存在します。その上に「プロセスの統合と自動化」で、ここはモデリングやフローによって業務を実行させていく世界です。その上に「プロセス分析」で、モニタリングをしたり、その結果を受けてボトルネックを検出したり、プロセスをコンポーネントにして再利用できるようにしていこうという世界です。

　非常に限定された中での情報化要件から、EAIがどこに使えるかを見てみます。現在使っているシステムは、ある意味でレガシーを中心に、DBを中心に置いて集中して使われています。あとはEDIや対外系のサーバがあり、この中の業務の一部がWebで切り出されてフロントに置かれています。

　対外系という世界から見ていくと、例えばネットワークをＩＰ化していくとか、取引先との関係でいろいろなBtoBの仕組みを入れていかなければいけないという要件が一つあると思います。そして、こういう世界に対して、EAIは新しい対外系のサーバというとらえかたで利用できていくというのが一つあるでしょう。それから、いちばん代表的な話としては、業務システムを再構築していく一環で、インターフェースをつかさどるサーバという格好で使っていきます。

　もう一つは、大きな課題になりますが、データ情報の利用をどんどん広げていくということです。そのときに、例えば公開サーバという格好でこの情報を利用していくという形態があります。一つはETLという考え方もありますし、最近ではWebサービスとして、情報そのものではなくサービスという形に変えて利用を広げていく世界に使えていくでしょう。

　また、現行のシステムを変えていこう、よくしていこうという業務改革は一朝一夕にはなかなかいけないと思います。そのときにフロント系のシステムに着目し、ワークフローシステムという形で、電子化や改善をやっていくところに利用シーンがあるでしょう。サプライチェーンなどいろいろな物流系のシステムにEAIを持っていくというのは、ある意味でこのような世界を広げた中でとらえていくものではないかと見ています。

　このような中で、弊社がどのような使い方をしているかをご説明します。富士通の社内システムとしてあちこちで導入しています。先ほど言ったインターフェースサーバ、ワークフローサーバ、対外系などで使っています。ただ、今日お持ちした内容は最近の事例というよりも、実質は去年稼動している事例で、そのいろいろな局面のものをご説明しようと思います。社内で使っていますので、富士通の製品を使っています。

　国内、北米・欧州の販社をEAIでリアルタイムに直結していき、いろいろなパートナーシップを強化していきます。国内の販社は従来からありましたから、ここは非常にＩＴ化が進んでいます。ところが、海外系についてはそれぞれで立ち上がってきたという背景があり、全体としては統一された形になっていないので、ここにEAIを入れてシステムを一つ作っています。

　大きなねらいとしては、簡単にいうと三つです。一つは、マスターデータを統合しよう、それから注文データを国内外同じレベルで処理できるようにしてやろう、もう一つは、在庫情報の一元管理をしようということです。

　生産管理、販売管理のシステムを国外と海外両方で使います。新しく統合データウェアハウス的なものを展開していき、ここで全体を見ていこうとうのが大きなシステムの形態になります。国内販社は業務システムに直結した形でできており、海外にあるシステムにEAIツールを入れて、国内と同レベルでシステムが共有できる格好になっています。

　初期の成果当初としては、所要見積もりなどの短縮ができ、従来週単位だったものがデイリーにやれます。なおかつ、それが国内であろうが海外であろうが同じレベルで対応できます。もう一つは、新しい販路、例えば今でいうとロゼッタネットのようなネットワークの世界をこの先から作っていき、従来の販社とは別に、取引先との直結したパスを広げていくという目的のためのインフラにも使っていくことができます。

　もう一つは、ワークフローサーバとしての利用です。我々が実際に使っていますが、届出・伝票処理のシステム、単純にいうと事務処理システムなのです。その後ろにある各サブシステム、ヒューマン系の業務の流れなどをEAIの技術を使って全体を統合していく世界にEAIを使っています。

　こんなところになぜEAIかという議論がありますが、どうしてもグループウェアといっているようなワークフローツールですと、規模の問題、外部との連携性が非常に弱いといえます。富士通と関連会社の従業員約10万人が使うシステムで、平均すると2000〜3000人が同時に使っている全社的なシステムです。そういう意味で、それぞれに作ってきたワークフローのシステムを、一つの大きな全社的なフローシステムに育てていくときに、EAIツールは使いでが出てくるのではないかと思います。

　三つ目の例は、対外系サーバとしての利用です。富士通の場合、資材調達のASPサービスを、ProcureMARTという名前で提供しています。これは簡単にいうと、富士通の中にIDCセンターを置き、バイヤーとサプライヤーの間をそれぞれ最適な手段でつないでやって、電子部品などいろいろな装置、原料、材料の調達の場を提供しているサービスです。これは2001年９月で、サプライヤー4000社という仕組みになっています。最新ですとロゼッタネットのようなインターフェース、あるいは昔からあるWebEDIのよう世界、そして来型のEDIがここに用意されています。

　このASPサービスを、EAIツールを使って実現しています。先ほどはバイヤー、サプライヤーという表現でしたが、取引先と自社のシステムという形です。取引先にはロゼッタネットやWebEDI、あるいは従来からあるファイル転送型のEDIを、インターネットやクローズドネットワークを通してつなぎ、ここでプロトコル変換のような処理をし、それを業務データに加工して社内のシステムにつないでいきます。ここはお客様のシステムであったり、あるいはアウトソーシングされたセンターのシステムであったりするわけですが、ここの部分をEAIツールを使って構築しています。効果としては、基本的にペーパーレス、スピードアップというところが出てきています。

　今、三つほど使い先をご説明しましたが、それらを構築してきた結果として、現状のEAIツールはこのように考えられます。一つは、やはり技術要件が非常に広いことです。使うにしても、勉強しなければいけない技術が非常に多いということが一つあります。それがある意味で扱いにくい、とっつきにくい、使うまでに非常に時間のかかる、評価がしづらいというところになってきているのではないかと思います。

　もう一つ、これがいちばん大きい問題ではないかと思っていますが、システムトータルとしての構築手法が未確立です。EAIツールはEAIツールとしての構築手段があり、パッケージはパッケージとしての構築手段があり、レガシーは当然昔から作ってきた作法があります。EAIを使ってシステムを組むときには、この三つのそれぞれの最適なバランスがいちばん問題になってきます。そのときに、製品の都合やお客様の要件がかなり影響してきます。

　例えばパッケージのカスタマイズをやりたくないという要件があれば、それをレガシーやEAIの中で吸収することを考えるわけです。そうすると、コスト面や構築までの時間に影響してきて、その幅が非常に大きいことが今後クリアしていかなければならない問題だと思います。

　もう一つは、バックエンド、基幹系の業務を中心とした連携はほとんど１対１なのです。ｎ対ｍの連携も表面上から見るとありますが、きちんと見ていくとやはり１対１なのです。そうすると、EAIツールが持っているいい面や応用機能的なところがなかなか実業務で生きてこないところがあります。ですから、EAIツールを入れたときに、スピードアップや効率化が表に出てきて、データの動きを変えていくところは少し難しいところがあると思います。これは製品など外部から利用する側で考えなければいけないところです。

　そうかといって、EAIはそんなものなのかといと、やはり有効なＩＴの技術であるといえますので、まずは入れてみて一度使っていくと、こういうことにも使える、ああいうことにも使えるということで、非常に可能性を秘めた一つの技術ととらえています。特定の局面に限定せず幅広く適用検討をやっていくと、期待効果もより具体的に広がってくるような感触を持っています。ヒューマン系の処理や電子データ化もほとんど実業務ではできていないという認識をしています。それを広げていく道具としてEAIツールを考えていくと、また利用の範囲が広がっていくのではないかと考えます。

　今まで三つほど事例を見ていただきましたが、ああいうものを使っていったあとの考察ということになります。今日はさわりをご説明しただけなので、中身の浅い議論になったかもしれませんが、富士通の中でどういう使い方をしているかという一つの利用形態のパターンとして見ていただければと思います。それに対して、我々は今このような認識をしているというご紹介です。

　弊社は、ベネッセコーポレーションのＩＴ分野を担う子会社です。ベネッセコーポレーションは、赤ペン先生や進研ゼミなど教育を中心としたサービスを提供する企業です。弊社のベネッセグループでの位置づけは、ベネッセグループに対して情報システムの構築、運用にかかわるパートを担い、サポートを行うことです。ベネッセ以外に対しても各種のサービスを提供しており、事業の内容としては、入力から出力までのトータルとしてのアウトソーシング事業、インターネットを中心としたASP事業、各種の開発・システム構築を担うデータセンター事業を三つの柱として事業を展開しています。

　EAIの導入に関しては、ベネッセでのERPの導入がきかっけとなっています。ERPの適用範囲は、「新・経営情報システム」という会計のシステムで、財務会計、管理会計、原価、販売などを含む領域となっています。また、その周辺として個別の販売管理、購買管理、人事などのシステムの連携を対象としています。この時点での連携のシステムは、16の周辺システムがありました。旧来の経営情報システムは、従来はIBMのメインフレーム、汎用機で18年間稼動していましたが、これをSAP社のR/3にリニューアルを行いました。

　ERP導入のプロジェクトのスケジュールとしては、1999年後半に企画の部分から入り、2001年１月、予算機能を先行稼動させ、同年の４月にビッグバン形式にて全面稼動を行っています。

　旧経営情報システムは、IBMのメインフレームで動いており、すべて手作りのインターフェースで行われていました。その当時は、何がどのような頻度で、どんなインターフェースが流れているのか、正直いって分からない状況でのスタートとなっています。それが起因して、システム運用の部分でも非常に負荷が高い状況でした。今回のERPの導入に併せて、このインターフェース部分の課題解決を行うことが目的の一つとなっています。

　まず、450本ものインターフェースを手作りで行うには莫大な時間がかかってしまうところが一つの課題として挙がっていました。また、メインフレームとR/3とのリアルタイムな接続を構築する必要があり、それ以外にも多種多様な接続形態を実現し、その技術力の確保が課題でした。そして、日に70万件というインターフェース上のトラフィックも懸念事項の一つであり、これらがリソースの競合を起こさない仕組みを実現する必要に迫られていました。

　とにかく時間がありませんでした。ERPの全体のスケジュールから考えますと、１年半ありましたが、インターフェースの部分に着手したのは、リリースまでにあと１年を切っていました。何よりも、今回のERP導入だけでなく、その後の運用でも負荷削減が一つの課題として挙がっていました。これらの要求を満たすために、当時注目されていたEAIのツール、中でもシービヨンド社の「e*Gate」を選定しました。

　EAI （e*GATE） によって、周辺のシステムへの影響を最小限にとどめよう、その修正をEAIのほうで吸収することによってプロジェクト全体の工数削減を図ろうと考えました。また、接続コンポーネントを選択することにより、さまざまなシステムの形態へ接続し、それによってIBMのメインフレームとSAP R/3とのリアルタイム接続を実現しようと考えていました。さらに、将来的なグループ情報の統合を含めて負荷分散を図ろうと考えました。

　続いて、ＧＵＩを用いたマッピングでの開発による高生産性を目指しました。そして、その体制を専任化することによって、さらに工期短縮を図ろうと考えました。次に、運用上の管理を集中管理することによって、インターフェースのブラックボックス化を防ぎ、どんなインターフェースが、いつ流れているかを、このツールによって可視化しようと考えました。ちなみに、e*GATEは集中管理だけでなく分散的な管理もできます。我々はシステムの運用の形態に合わせて集中管理を採用しました。

　インターフェース構築のスケジュールは、2001年１月の予算機能の先行リリース、４月の全面稼動に合わせて、計画立案、要件定義・基本設計、詳細設計・製作・単体テスト、そして結合テスト・移行という四つのフェーズに大きく分けて開発を行ってきました。リリースしたあとは、システム運用・保守とEAIの利用拡大が起こっています。これら全部で五つのフェーズに分け、それぞれのフェーズにおける成功ポイントをご紹介します。

　まず、方針決定のフェーズでは、インターフェースの構築を最初からEAIありきとは考えておらず、手作りかパッケージかを検討しました。そして、インターフェース自体の実現方法も検討し、EAIツールでの課題解決の目的を明確化しています。その結果、EAIツールを使うことになり、数多くあるEAIツールの中で何を選択するかというところで、パッケージのFIT & GAPを行い、課題解決、将来性、ベンダーを見ながら最終的にe*GATEを決定しています。その後、プロトタイプ的にそのツールに問題はないか、懸案事項はないか、このフェーズにおいて確認を行っています。この工程においては、EAI導入でのツールの決定と事前課題のクリアがポイントとなっています。

　続いて、要件定義と基本設計のフェーズでは、実際にe*GATEに対してまず標準の作成に着手し、開発の標準ルール、その後の運用時のルールもここで決めています。そして、インターフェースのパターンごとにテンプレートを作成し、それを見ながら開発していく手法をとっています。また、大量の一括バッチのインターフェースに対するテンプレートルールもここで決定しています。体制面では、当初インターフェース構築のチームと、旧システムから新システムへのデータ移行のチームを一つのチームとしていたのですが、チームを分離し、インターフェース構築のチームを立ち上げることにより、さらに開発の生産性を上げることができました。次のフェーズの製造の工程において、EAIベンダーからどのような支援を受けるのかをベンダーと協議し、具体化することもこのフェーズで行っています。

　次に、製造フェーズでは、各工程でのルール化、標準化が成功し、手戻りが少ない非常にスムーズで滑らかな開発ができています。そして、EAIの持つGUIでの開発で生産性を上げています。機能として、インターフェースのルーチン化でさらに生産性を高く開発することが実現できています。周辺システムの連携での影響をEAIで吸収することにより、プロジェクト全体の工数を大幅に削減し、現状の資産を有効利用することに成功しました。周辺システムの側にもe*GATEの製造部隊の体制を随時確保し、負荷分散を図ることによってERPの構築に専念することが実現できています。ここでは、各工程の事前準備が成功したことと、e*GATE自身の持つ生産性の高さがポイントだと考えています。

　続いて、テスト検証・移行フェーズでは、データ生成をEAIで吸収し、各周辺システムでの工数削減を実現しています。また、データ移行でデータのレイアウト変換やコードの変換をe*GATEでやることにより工数を削減しています。このように、開発の各工程において十分な準備をし、当初想定していなかった問題に関してe*GATEが柔軟にそれを吸収していったことが最大の成功のポイントだったと評価しています。

　続いて、リリース後の運用とEAIの利用拡大というフェーズでは、パッケージに対する修正パッチに対して迅速に計画的に実施することにより早期に安定運用を実現し、運用負荷とコストの大幅な削減をしています。開発時にいろいろなルールを作りましたが、システムの連携先が増え、業務が変化するところで、そのルールもそれに合わせて順次変更していきます。さらに、ＳＥレベルのノウハウが必要な部分とルーチンワークを明確に作業の中で切り分け、リリース後の拡大における開発面でコスト削減を実現しています。利用拡大で、システムをどう連携させるかという検討をベンダーと共同で行うシーンもあり、長期にわたるＩＴビジネスの戦略において、共同で検討できるパートナーを得ることができ、それによってベネッセグループ全体でのビジネスをより加速することができたと考えています。

　e*GATE の導入の結果として、開発フェーズにおいては、短期間・高品質で大量なインターフェースを構築できたと評価しています。周辺の16システム、インターフェース数450本に対して、初期障害を３件で立ち上げ、その３件も業務に支障がないもので稼動している点、IMSとSAP R/3のリアルタイムな連携が実現できた点、既存システムの影響を最小限にとどめて、周辺システムの有効利用を図れた点、結果として開発工数の削減ができた点が評価理由です。

　開発時の実績として、１インターフェースは１〜３時間という生産性で実現しています。製造の部分だけですと、開発期間３か月間で450本ものインターフェースを立ち上げました。e*GATEは、プロジェクト全体のリスクを大幅に削減できたという部分で評価しています。

　運用とその後のEAI利用の拡大においては、障害の管理を集中化できています。障害発生時に即リカバリーできるので、何よりもシステムが停止しても業務は停止していないところが最大の評価理由です。また、従来のインターフェースでは４人の専任体制で監視していましたが、現状は２人の担当の体制で、従来に比べて８分の１の運用コストを実現しています。負荷分散や拡張性にもすぐれた将来性のあるインターフェースの基盤を得ることができ、開発・改訂の費用を削減できました。

　最初、EAIを導入した時点では、SAP R/3とのインターフェース基盤を目的として導入をしたのですが、現状は利便性や可搬性が認められ、ベネッセグループ全体でのインターフェース基盤という地位を獲得しています。これから発生するOSやDBの種類、バージョンアップに対して適用力の高さを手に入れ、将来性において非常に有利な基盤を手に入れたと考えています。結果として、その運用とその後の利用拡大、開発・改定で大幅に費用を削減し、単なるERP導入の成功事例の一つだけでなく、その後の運用や将来性で評価しています。

　EAIという言葉だけが知れ渡って、まだ導入している会社がないところで我々は導入を決定しており、先見の明はあったと考えています。実際の開発では、e*GATEに関して国内ではほぼファーストユーザーということもあり、開発の標準化、テンプレートに注力し、多大な時間をかけたこと、また、専任化など内外の体制作りを十分に行い、ネゴシエーションを行ったことが成功のポイントです。

　問題解決を自らの問題としてとらえるマネージメントを行い、パッケージの不具合に対して、ベンダーも我々も同じ課題としてできる範囲を明確化し、ＩＴビジネス戦略において将来性のあるパートナーをお互いに確立できました。さらに、従来までの運用を改善・刷新し、負荷削減、楽にしたいとの強い思いが重要だったと思います。
　今回のプロジェクトの成功要因を一言で集約すると、有るべき姿を追求し、それにこだわり、それを実現させるといったところだと考えています。

　皆さんがいちばん興味のあるのは、投資対効果をどう考えるかだと認識していますが、５社のご講演を聞き、それぞれの会社が導入しようという意志を持ち、それに対してどうしていかなければならないかというところが、問題点を解決しながら効果を出していったいちばんの点ではないかと思います。

　これからお見せするのはフレームワーク的なもので、あくまでもテンプレートとしてお使いいただき、実際に皆様がたがどこで効果を出していきたいかという思いと、それだけでは足りないところを、ほかのどこにそういう効果を求められるのかを見つけていくようなものをご提供していきたいと思っています。

　投資効果を見る場合に、EAIというツールをどうとらえるかという話をまずさせていただきます。すでにいろいろな会社のお話の中で、標準を決める、やり方を統一するという話があったと思います。共通インフラストラクチャーとは、そういうものをやろうというお話です。

　最初にお話した経営手法が、現状どのように取り入れられているかを見ます。大きい会社に行くと、大抵インフラを管理されている部門があり、そこにEAIなどの話を持っていくと、自分たちがやりたいと言っても自分の予算ではできないし、プロジェクトの個々の予算の中で共通インフラを作ろうと言っても受け入れてもらえないという話になってしまいます。

　大抵の場合、サプライチェーンであればアプリケーションを統合するといった中でのインフラを考えています。ほかのところへ行くと、CRMの中でインフラを考えていく。管理会計は管理会計で、全体を見越したうえでのインフラを考えるという形で、かなりの複数投資をされています。しかし、投資は決してパッケージが別のものがあるから投資なのではなくて、そこにかかる人、スキル、運用など全部考えて投資ですから、それらを統一するだけでもかなり楽になります。ミドルウェアとしてEAIというツールを使った場合、標準化をすることによってのメリットも出てくると考えています。

　それをどこでどういうものをやっていくかを考えればいいわけです。ネットワークレイヤーはいいとして、インテグレーションレイヤーでトランザクションのハンドリングをするエンジンと、ワークフローをハンドリングするエンジンがあります。データにはいろいろなタイプがありますし、アプリケーションのインターフェースもあります。それから、データだけの連携の場合には、データのインターフェースの標準化もします。

　ＩＴ戦略というと大きいですから、ＩＴアーキテクチャーはその一部であり、上から落としていくといった場合に、ＩＴ戦略をやる場合にはビジネス戦略がなければいけません。ビジネス戦略は、いろいろな会社があると言うのですが、ＩＴ戦略のインプットになるようなビジネス戦略はなかなかありません。逆に、事業戦略まで落ちないとＩＴ戦略に落ちてこないというところもあり、どちらが先かという議論をし出すときりがありません。

　であれば、まず自分たちがどういう運用をしているか、どういうところに困っているというのをベースに何を標準にしていったらいいかというインフラストラクチャーを定義しなければいけないと思います。

　アーキテクチャーを決めて、標準を決めたとしても、インターフェースの方針はどうするか。例えばコードを標準化するのか、コード変換の標準をどうやって決めるか。それから、例外処理（エラーハンドリング）のしかたを一定にしないと、複数のアプリケーションが動いた場合に、どこで問題が起きたかという問題判別に大変時間がかかります。こういう標準を決めることにはコストがかかりますから、ある意味では投資です。

　それから、ガバナンスとして、決めたものを守らせるためのプロセス、管理サイクルとしてどういうものを用いるかという決め事も出てきます。これらを考えると非常にコストがかかりますが、それに勝るだけのメリットを出すために、こういうことが必要になってくると考えます。

　EAIを単なるインターフェースツールとして使っても、けっこう効果は出ます。ただ、それだけでやっては、インターフェースのEAIは共通インフラという話にはなりません。やり方として共通インフラを目指して、それを最初のインターフェースとして使うことはありますが、基本的には今考える範ちゅうでは、共通のインフラストラクチャーとしての活用を前提として効果をみるように考えます。

　直接の効果だけでなく、共通インフラストラクチャーをサプライチェーンやCRMというエリアまで広げて入れた場合に、どのような項目で効果が挙がるのかというところまで見ます。

　効果項目としては、定量的なものと非定量的なものと、直接的なものと間接的なものがあります。非定量的というのは、定性的ではありません。対応スピードが向上したというのは、測りようがないという部分で定性的なのですが、測れるけれどもうまく測るツールを持っていないところを今回は非定量的という形で入れています。

　従来のように、EAIの効果を保守コスト、開発コスト、運用コスト、品質の向上などだけで測ると、高いツールに見えてしまいます。データ連携をしていくわけですから、サプライチェーンのエリアであれば在庫が減るでしょう。生産計画のところでは、計画時間が減り、納期の短縮にもなります。そこもきちんとステートメントしていきます。

　非定量的なもの、例えばプロセスコストの削減といっても、実際にプロセスコストを今測って、入れたあとどうなったかというのをやろうとすると、かなりお金がかかります。機会損失なども見えません。顧客満足度も非定量的には上がってきます。このような項目をきちんと洗い出してやります。

　今度は、投資の考え方です。同じようにEAIを単一ツールではなく、共通インフラストラクチャーとして考えます。その際に、直接費用だけではないというところをきちんと考えます。

　ダイレクトの部分に関しては、お金がそこでキャッシュアウトしていくものがすぐに見えるものです。ライセンス、ハードウェア、保守料金、スキルのトレーニングや要員を雇うことも出てきます。間接的には、標準化はお金がかかる部分です。人が要るかもしれません。体制・組織の確立、それから新技術に対するリスク、新しいものを取り入れることに関しては抵抗があります。それをどうマネージするかというリスクもあります。これらを全部洗いざらい出そうというのが、EAI研究会でのフレームワークの概要です。

　基本的にはバランスシート的な表を作っていこうとしています。効果と投資という項目があり、定量的なもの、非定量的なもの、直接効果、間接効果を見ていきます。当然ＩＴ関連がほとんどの場合直接効果になり、間接効果としては業務関連になります。例えば在庫管理のエリアか、販売のエリアか、経営管理のエリアか、それとも生産計画か生産管理かというのを出して、その細かい項目をもう少し出します。

　在庫管理であれば、データのリアルタイム化をすることによって在庫が削減できます。その削減は、死蔵在庫が削減できるのか、適正在庫を維持できるようになるのか、それとも適正在庫レベルを下げることができるのかというところを見ていく項目を挙げていこうとしています。これはできる限り網羅的にやっていって、あとはお客様の中で固有のものを付け加えていただいたり、要らないところは削っていただければいいということで、シートを用意しています。

　具体的には、このような使い方を考えています。共通インフラは一度には入りませんから、フェーズごとに何を目的にしてやっていくかを考えなければいけないということで、フェーズを切ってあります。どのフェーズで何をしていくか、どこに効果があることをしようとしているのかを明らかにしていこうと考えています。 ○は効果はあるのだけれども積算のワークフローをかけるほど大きくはない、◎はかなり大きそうなので積算してきちんと削減の見積もり金額を出そうというエリアです。それを計算して、フェーズごとに幾ら効果があるかを見積もりとして出します。

　同じように、投資側でもこういうものを書いて、そこにかかるコストを書きます。非定量的な直接のところで、ガバナンスのための費用がかかってくると思いますが、そこはできるだけ定量化をある程度見越した見積もりが必要です。経営から見れば、どこまで網羅的に物事を見て、お金がどれだけかかってどれだけ利益が出るかを考えたかというのがいちばんのポイントになります。そこまで考えて効果が出るという判断をしたのか、それとも見えいところは目をつぶったまま走っているのかで、判断材料として一つ問題が出るでしょう。

　実際に、あのときやったものは本当に効果が出ているのかと言われたときに、ここにかかったコストが、見積もりでは２だったものが３になったというのと、０だったものが２出てしまったというのでは、説明責任という意味で全然違ってきます。なぜ２が３になったかというのは言えますが、０が２になったら「おまえたちは考えていなかったんだろう」という世界になります。そのようなところを全部網羅的に書けるようなシートをご用意して、これをダウンロードできるような形にします。

　現実的には、この辺のシートができますと、コンサルタントに頼んで１〜２か月かけて調べてもらったのと、自分たちがこのシートをベースに計算値を入れていったもので、当然誤差は出ると思いますが、コンサルタントも基本的にはお客様に聞いてこういう項目を埋めていくだけですから、あまりギャップは少ないのではないかと思います。これである程度の効果が見えてくれば、導入がより進められるのではないかということを望んで作っています。

　皆様がEAIを導入するに当たってバリアになるのは、経営者のかたがEAIに対してどう考えているかと、今導入されている各社は自分たちのやられているエリアで投資対効果を出そうとしているけれども、本当にそういう考え方でいいのか、もう少し全体的な考え方がないのかというところだと思います。わたしどもの研究会は、その仮説のもとでこのようなシートを開発してきました。最終的には、このシートをアップロードしていったん研究会のファーストクールは終わりますが、皆様がこれからされようとしていることに何かお役に立てば幸いです。