 |
||||||||||||
|
||||||||||||
| 前のページ 1 2 3 次のページ | ||||||||||||
|
||||||||||||
| システム統合における障害発生分析モデル | ||||||||||||
|
次に、この連載のテーマであるシステム統合に話を移そう。2002年4月に誕生したみずほフィナンシャルグループ（以下、みずほFG）の障害発生に代表されるように、ビジネスにおける情報システムの重要性を考えた時に、情報システムにおける障害発生は、1つの部門や企業内にとどまらずに顧客など社会に対して影響を与えることが多い。 サウアーモデルではこの点があまり考慮されていない。また、サウアーモデルにおける支援者は経営者だけでなく、当該企業の情報システムのユーザ部門も含まれるが、それぞれの役割は異なっている。 これらを踏まえて、サウアーのモデルを次の3点について拡張する。
表1：拡張されたサウアーのモデル
これにより、図2に示すようにシステム統合における障害発生分析モデルが得られる。  図2：システム統合における障害発生分析モデル 図2はA社とB社の統合を想定して、システム統合に関わる主なステークホルダーを描いたものである。図2の中心に情報システムを取り囲む形で描かれているのは、システム統合の推進委員会（統合プロジェク本部、統合準備委員会など）である。システム統合においては、通常このような統合に関わる委員会が設置され、システム統合に関する様々な問題について協議して統合プロジェクトを進めている。 |
||||||||||||
| システム統合プロジェクトにおける障害発生分析モデル | ||||||||||||
|
一般的に、システム統合における障害発生の原因を1つに絞ることは難しい。「統合の発端において当事者間に統合後の姿に対する明確な共通認識がなかった」「意思決定部署と作業部隊との間の意思疎通がうまくはかられていなかった」「統合後のIT戦略がはっきりしていなかった」「本番稼動直前での確認作業がうまくいかなかった」など様々なものがある。 そこで、「システム統合におけるステークホルダーとその間の関係」といった空間的な観点だけでなく、「統合プロジェクト全体を通じてその障害発生を分析する」という時間的な観点も必要となる。 |
||||||||||||
| プロジェクトマネジメント | ||||||||||||
|
プロジェクトマネジメントでは、プロジェクトのプロセスが5つのグループに大別されている。それらは、立ち上げのプロセス／計画のプロセス／遂行のプロセス／コントロールのプロセス／終結のプロセスであり、PMBOKでは次のように説明されている。
そこで次に、これら5つのプロセスと、先に述べた、障害発生分析のモデルとを組み合わせたモデルを考えてみる。  図3：システム統合プロジェクトにおける障害発生分析モデル （画像をクリックすると別ウィンドウに拡大図を表示します） 図3は図2に示した障害発生分析モデルを5つのプロセスグループごとに並べ、その関係について時間的な要素も加味して分析しようというものである。 |
||||||||||||
|
前のページ 1 2 3 次のページ |
||||||||||||
|
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
-
人気記事ランキング
-
-
連載
