 |
||||||||||||
|
||||||||||||
| 1 2 3 次のページ | ||||||||||||
|
||||||||||||
| 2つのアーキテクチャの整合性 | ||||||||||||
|
第1回で述べたように、システム統合において重要なことは業務機能だけでなく、組織構造や顧客、取引先など外部環境の関係、提供する商品やサービスの内容などについて、統合後のビジネスシステムを念頭においたビジネス・アーキテクチャを構築し、そのビジネス・アーキテクチャに整合した情報システム・アーキテクチャにもとづいて、情報システムを構築することである。 これら2つのアーキテクチャが整合することがシステムを成功に導く第一歩である。では、これらのアーキテクチャが整合しないと、どのようなことが起こるのだろう。ここでは2つの事例をとりあげて考えてみる。 |
||||||||||||
| ビジネス・アーキテクチャと情報システム・アーキテクチャの不整合による失敗事例：J社の場合 | ||||||||||||
|
製造業におけるこれら2つのアーキテクチャの不整合による次の失敗事例は、『成功に導くシステム統合の要因』（第4章）からの引用（一部加筆）である（注1）。
※注1：
経営情報学会システム統合特設研究部会編、『成功に導くシステム統合の論点—ビジネスシステムと整合した情報システムが成否の鍵を握る』、日科技連出版社、2005．ISBN4-8171-9157-0
J社では販売会社の注文にもとづいて販売設備機器を製造していた。販売会社はチェーン展開しているため、ある程度の台数はまとまるが、基本的にJ社は個別注文にもとづいて製品を設計し、チェーン店の拡大に対応して生産・納入するビジネスを展開していた。 コンピュータを利用しはじめた初期（1960年代後半）、工場に定着していた製番管理方式（製品の1台ごとに製造番号を設定し、全ての部品や材料を製造番号に紐付けして購買・加工手配する）をそのまま情報システム仕様に取り込んでいた。遅れて参入したビジネスではあったが、製品1台ごとにきめ細かな設計変更への対応が可能なため、巨大な販売会社数社を顧客として獲得でき、ビジネスは順調に伸展していた。 1980年代前半には業界第1位のF社にほぼ業績が並び、F社を抜くのは時間の問題と推測されていた。ただしソースコードがつぎはぎだらけになり、変更や拡張の遅れが問題視されていた。80年代後半に、ようやく構造改革の機会が与えられた。しかし、情報システムの構造改革は思いがけない結果を招いた。経営管理論で有名な外資系のコンサルティング・ファームが指導し、市場対応の組織編成に変え、米国で広く利用されているMRPパッケージを基幹系情報システムに導入した。 導入後1年経たないうちに業績が低下し始めたが、情報システムの効果が近い内に出はじめるに違いないと経営者は情報システムを放置した。90年代半ばには売り上げが大幅に下がり経営者が交代した。2000年代前半にJ社の親会社は事業を諦め、工場をF社に売却した。 J社は、MRPパッケージを導入することにより、J社の持つ顧客満足に関する強みが失われ、短納期生産の能力に関してF社より劣ることになった。J社の業績が悪化したのは当然のことである。これに対しF社は、MRPパッケージを採用していたが、これに合うようビジネスの仕組みを変え、規格品の短納期生産体制を作り上げていた。J社に比べて顧客満足度は低いが、価格と納期において強みを持つ方策として情報システムは貢献している。 MRPパッケージを利用すれば、容易にこの事業分野に参入できることから、いまでは多数のライバルが出現し、F社の優位性は失われている。こうした中、労務費が比較的に安い地場産業を利用して参入したS社が力を着け、F社に迫ろうとしている。S社はかつてのJ社のような強みを自社に追加したいと、2004年現在、情報システムの再構築を企画中である。一方、F社はMRPパッケージを用いたシステム構築力を活かしてシステム・インテグレータ事業で収入増加を目指している。 |
||||||||||||
|
1 2 3 次のページ |
||||||||||||
|
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
-
人気記事ランキング
-
-
連載
