システム移行とは
システム移行とは、現行の旧システムに代る新システムの開発が完了してから、新システムの稼働を開始し、旧システムを廃棄するまでのプロセスです。
次のような場合もシステム移行ではありますが、通常は異なる用語を使います。
- 旧システムが人手処理だったとき→システム導入
- 新旧の違いが少ないとき(効率を向上した、機能を追加したなど)→システム保守
典型的なシステム移行(ここでのシステム移行)は、次のようなものです。
- 企業合併など経営環境の変化に対応するため、全く新しいシステムにした。
- 旧システムは当社独自のカスタム仕様で開発したが、新システムはERPパッケージで開発。アドオンを極力少なくした。
- 従来は自社コンピュータで処理していたが、クラウドコンピューティング環境にして、できるだけベンダが提供しているソフトウェアを使うことにした。
- 従来は基本的にバッチ処理であったが、全面的にオンライン処理にした。
システム移行方式
現行システムから新システムに移行する代表的な方式を列挙します。
- 一斉移行方式(一括移行方式)
- ある時点で現行システムを休止し,新システムへ一斉に切り替える方式です。
利点:並列稼働が不要。新旧システム間のデータ交換ソフトが不要
欠点:新システムにトラブルがあると影響大。短期間移行作業になる
そのため、事前に全部門との間で詳細な計画を立てるとともに,新システムに高い信頼性が要求されます。
- 順次移行方式(段階移行方式)
- 業務や機能などで分割し、その単位ごとに現行システムを休止し,段階的に移新システムに切り替る方式です。
新旧システムを比較しながら運用し、問題がなくなった時点で、新システムに移行します。
利点と欠点は、一斉移行方式の逆になります。新システムと残っている現行システムのインタフェースが単純な場合は、運用部門の負荷が少なく,問題が発生しても当該サブシステム内に抑えることができる利点があります。
逆に、インタフェースが複雑な場合は、新旧システム間でデータ受渡しのためにインタフェース用の一時的ソフトウェアやEAIソフトが必要になるのが大きい欠点です。
- パイロット移行方式
- 順次移行方式に似ていますが、特定の業務あるいは部門をパイロットとして移行してから十分な観察をした後に、他の業務・部門の移行をする方式です。移行に関する問題発生への対策がとれること、発生しても影響範囲を局所化できる利点がありますが、全体を移行するのに長期間かかる欠点があります。
-
- 並行運用移行方式
- 現行システムと新システムを同時並行で稼働させ,結果を比較検証しながら、新システムに問題がないと分かった時点で現行システムを停止する方式です。
並行稼動させるので,新システムで問題が発生しても業務への影響を最小にできる利点がありますが、両システムを運用するため、データの二重入力や、両システム間でデータを同期させるEAIソフトが必要になる欠点があります。-
(注)EAI(Enterprise Application Integration)
異なる複数のシステム間のデータ連携をスムーズにする仕組み。企業内アプリケーション統合)は、企業内にバラバラに存在しているシステムを相互に連携させて、全体としてビジネスの効率を高めるための技術。
マイグレーションとコンバージョン
システム移行に関する言葉にマイグレーションとコンバージョンがあります。
マイグレーションとは「移行」や「移転」を意味する言葉ですが、狭義には現状の設計からコードまで変えずに新しい環境に載せ変えて適合させていく手法のことを指します。
それに対してコンバージョンは「転換」を意味し、データやファイルを別の形式に転換することです。ダウンサイジングなどでは、これらが必須であり、多様なツールがあります。
システム移行の問題点
システム移行では、旧システムが稼働していること、業務の継続が求められることから、システム導入と比較して、次のような特徴があります。これらに留意することが大切です。
- 並行運用期間の短縮
- 新システムが安定するまで、業務を継続するために旧システムも稼働させる必要があります。この期間中は、両方のシステムにデータ入力をする作業が生じますし、旧システムで稼働しているハードウェアを撤去できません。
並行運用期間中は、労力や費用がかさみますので、期間を短縮することが求められます。
- データの同期
- 新システムへの切替時点で、データファイルの内容が、旧システムでは最新状態になっているのに、新システムでは数日前の状況になっていると、大きなトラブルが生じます。同期がとれていることを確認することが大切なのですが、かなり複雑な作業になります。
- 過去データの新システム対応
- 旧システムで長年蓄積している保管データを、新システムで扱うためには、データやファイルの形式を変換する必要がありますが、大量のデータ、多様なファイルがあると膨大な作業量になります。
- 利用者の誤認回避
-
- 利用者は旧システムに慣れています。それが新システムでは異なると、多様なトラブルが生じます。回避するための説明や訓練が必要になります。
- これまで経理部門で入力していたデータを、そのイベントが発生した部門で入力することに変更した場合、データが入力されない/重複して入力されることがあります。
- バッチ処理をオンライン処理に変えたとき、以前は締切時刻までにまとめて入力すればよかったのが、イベント発生時に即時に入力する必要があります。入力と同時にデータベースが更新されることが理解されていないために、思わぬトラブルが生じることがあります。
- 画面操作が微妙に異なり誤操作をすることがあります。「確認」ボタンと「終了」ボタンを間違えるなどです。
- 新旧システムで用語(概念)が異なることもあります。これまで倉庫から出すときはすべて「出荷」だったのが、得意先への「納入」と、社内での「転送」に区分したなどです。入力で誤操作したり出力を誤解したりします。
システム移行計画
新システムの企画段階までも含む全工程を対象にすることもありますが、ここでは新システム開発以降の工程を対象にします。
すなわち、上述の「システム移行」を適切に行うための体制、スケジュール、リスク対応などを整理して明示することです。
このプロセスでの成果物が「システム移行計画書」です。その内容は、項目としては「システム導入計画書」や「システム運用計画書」と同じことが多いのですが、システム移行の特徴を留意した内容になります。
システム移行計画書の記載内容
システム移行計画書の記述内容は、移行環境や対象システムにより大きく異なります。また、移行作業はシステム開発者と利用者の共同作業が多いので、全体を一つの契約書の形式にするのは不適切です。
それでここでは、「このような内容を記述するすることが望まれる」事項を列挙しました。
- 移行システムの定義と移行方法
移行プロセスで対象とする新システムの範囲、一斉に移行するのか/段階的に移行するのか、旧システムとの並行運用をするのか/しないのかなど
- データの扱い
並行運用期間での新旧システム間でのデータ同期の方法(双方個別に入力するのか/一方の入力から他方の入力データを自動作成するのか)、過去データの保管方法(新システムに合わせて変換するのか/しないのか)などを明確にします。これらは移行作業量を大きく左右します。
- 移行スケジュール
並行運用期間をどう見積もるかがポイントになります。短縮が求められるが、思わぬトラブルのリスクに対処することも重要です。具体的な期日を示すとともに、変更への考え方を示すことが望まれます。
- 移行体制
単に新システムの開発者や利用者だけでなく、旧システムの担当者、新旧システム間のインタフェースの担当者など、関係者が多様なのが特徴です。
- 移行関連資材
移行のために必要なハードウェアやソフトウェア(新旧システム併存で必要なもの、移行のために一時的に必要となるもの)、利用者への説明書類などを列挙します。
(新システムの操作マニュアルなどは計画書とは切り離すのが適切です。計画書では必要となるマニュアル類の列挙、教育訓練の体制やスケジュールなどを記述します。)
- 移行の検証
「新システムが安定し、旧システムが不要になった」ことをどのようにして確認するのか。どのレベルに達したらよいのかなどを記述します。
日次処理の部分は比較的短期間で検証できるが、月末処理や年度処理の確認には長時間かかる。それをどう切り離すのかもポイントになります。
- 移行失敗時の措置
「移行スケジュール」が過ぎたのに「移行の検証」が不十分なときの措置です。完全移行を遅らせるのか/リスク承知で決行するのか/とりあえず旧システムで運用するのかなどについて、基本的な考え方を明示します。それぞれにおけるリスク低減策も望まれます。
クラウド環境への移行プロセス
自社運営のシステムをクラウド環境に移行する(クラウドマイグレーション)の代表的な方式を列挙します。
- リフト&シフト
リフト(lift)では、既存システムをそのままクラウドに持ち込みます。現状のアプリケーションやデータなどはなるべくそのままにしておき、サーバやOSなど動作環境をクラウド環境へ移行します。
シフト(shift)は、漸進的に最適化を進める段階です。
既存資産を最大限に再利用でき、業務への影響を抑えて移行できる利点がありますが、旧システムの制約を超えるシフトが不十分になりクラウドのメリットを最大限に活かすことが進まない欠点があります。
- リファクタリング(再設計)
現行システムを、クラウド環境に適合するよう見直して再設計してから移行する方法です。
- ドロップアンドショップ(再購入)
現行システムの移行をあきらめ、クライド環境に最適なシステムを新規に作成(購入)する方式です。
新環境に最適化したシステムができますが、多くのコストや労力が必要になります。