豚吐露@wiki

問56回答

最終更新:

ohden

- view
管理者のみ編集可


【移行計画書】
①移行概要
移行の前提となる制約条件を要件として洗い出し、移行の全体的な方針や方式、業務への影響などを記述する。
初期段階の移行計画書では特に、移行方式の妥当性(それで移行できるか)が最大の焦点になる。
できるだけ早い時点で詳細化し、移行計画書それ自体はもちろん、移行関連のドキュメントや実施作業の確定を容易にしたい。
②移行対象
現行システムから新システムに移行する対象物を明記する。
対象物ごとの移行方法も、できるだけ具体的に記述する。
③移行中の影響
移行期間中にシステムや業務にどんな影響があり、それをどう吸収・調整するのかを具体的に記述する。
④移行テスト
移行テストの方法、実施範囲、実施環境などを明確に書く。
移行テストには、データ移行や移行検証などに使う移行関連ツールのテストと、移行作業のリハーサルが含まれている。
移行計画書の記述内容が“机上の空論"でないことを確かめるために必ず記述し、実施する必要がある。
⑤移行スケジュール
移行完了までの大工程と、タスクを細分化したWBS(Work Breakdown Structure)を洗い出し、作業期間を見積もって記述する。
作業を前倒ししたり、作業が遅延したりした場合の影響を見極めやすくするため、タスクの開始条件やタスク間の依存関係も明記しておく必要がある。
⑥移行体制
新システムの設計・開発とは別に、移行専任のチームを編成し、役割分担を記述する。

【一斉移行方式】
ある時点で旧システムから新システムへ一斉に切り替える方式。
新旧両方のシステムを同時に稼働することがないので、経済的な負担が軽くなる。

【順次移行方式】
パイロット移行とも呼ぶ。
旧システムから新システムに段階的に移行する方式。
新旧システムを比較しながら運用し、問題がなくなった時点で、新システムに移行する。
経済的負担は若干あるが、新システムの完成度が高いというメリットがある。

【拠点別移行】
段階移行方式とも呼ぶ。
システム移行の区域を限定し、残りの区域は従来のシステムを用いるという方式。
新旧システムを共存を図るようにする。
また、拠点別に行う段階移行とは別に、業務別に行う段階移行も存在する。



移行するデータ量が多いほど、切替え直前に一括してデータの移行作業を実施すべきである。
⇒ データ量が多いほど、一気に移行することは難しくなる。

新旧両システムで環境の一部を共有することによって、移行の確認が容易になる。
⇒ 修正対象のモジュールを新旧両システムで共有することによって確認の難易度は増す。

新旧両システムを並行運用することによって、移行に必要な費用が低減できる。
⇒ 並行運用することでコストは倍となる。



更新日: 2010年01月04日 (月) 19時43分22秒
記事メニュー
目安箱バナー