 |
||||||||||||||||||||
|
||||||||||||||||||||
| 前のページ 1 2 3 | ||||||||||||||||||||
|
||||||||||||||||||||
| 統合型の選択 | ||||||||||||||||||||
|
開発時間／開発コスト／運用コストの3つのコストに関して、代表的な4つの型（併存型／組合せ統合型／片寄せ型／新規開発型）を比較する。
表3：代表的なシステム統合の型についての比較 これらの3つの観点から、時間とコストに関するグラフをイメージ化したものが図3である。  図3：システム統合におけるコスト − 時間図（山本修一郎による、一部改変） 図3を例として用いて説明する。 例として、統合後の企業情報システムがt1時刻までに稼動し、t1時刻までの開発コストと運用コストの上限がc1で与えられているとしよう（ケース1）。この時、図2にあるどの過渡的形態を採用してもt1時刻までに稼動することは可能であるが、t1の時点でのコストは片寄せ型がもっとも小さいことがわかる。 ここで稼動時までのコストの上限がc2まで減額されたとすると、この時にt1時刻までに統合後の情報システムを構築するためには、併存型か片寄せ型しかありえないことがわかる（ケース2）。 一方、ケース1において、t2時刻までは過渡的形態のままで対応したいとすると、組合せ統合型がもっともコストが低いことがわかる（ケース3）。このように、図3は直観的にどのような型が現状において望ましいかを考えるための1つの手がかりとして有効であると思われる。 |
||||||||||||||||||||
| 統合型は過渡的形態 | ||||||||||||||||||||
|
しかしながらここで重要なことは、これらの型はあくまでも経過措置であり、最終的には統合されたビジネスシステムを支援するものとしての情報システムが新たに構想されなければならないということである。 図4に示すように、システム統合とはそのシステムが支援する対象となるビジネスシステムの統合が前提にある。したがって、統合後にどのようなビジネスシステムとなり、それを支えるビジネスアーキテクチャがどのようなものであるかが固まってから、はじめて対応する情報システムアーキテクチャができあがり、それにもとづく情報システムが開発できるのである。  図4：統合におけるビジネスシステムとそれを支えるビジネス情報システム（BIS） |
||||||||||||||||||||
| 次回の予告 | ||||||||||||||||||||
|
次回は「システムの失敗分析」の枠組みを拡張した「システム統合における失敗分析」の枠組みについて説明する。またそれを用いて、「システム統合における障害発生の原因」について事例に基づき分析する。そして、ビジネスアーキテクチャと情報システムアーキテクチャの整合性が重要であることを明らかにする。 |
||||||||||||||||||||
| 経営情報学会の研究活動について | ||||||||||||||||||||
|
経営情報学会では、社会的に重要なテーマに関する先端的な研究を、2年間の時限で行い、その結果を学会から社会に向けて発信することを目的とした、トップダウンの研究部会（特設研究部会と呼ばれる）を、数年前から設立している。その1つに、筆者が主査をした「システム統合」特設研究部会がある。 「システム統合」特設研究部会では、平成15年4月〜平成17年3月の2年間の研究活動をまとめ、昨年10月に報告書（経営情報学会システム統合特設研究部会 編「成功に導くシステム統合の論点 — ビジネスシステムと整合した情報システムが成否の鍵を握る」）を出版している。この連載についてさらに深く知りたい場合には、これを参照されたい。 |
||||||||||||||||||||
|
前のページ 1 2 3 |
||||||||||||||||||||
|
|
||||||||||||||||||||
|
|
||||||||||||||||||||
|
||||||||||||||||||||
|
|
||||||||||||||||||||
|
||||||||||||||||||||
|
|
||||||||||||||||||||
|
||||||||||||||||||||
-
人気記事ランキング
-
-
連載
