業務のシステムの移行は、①移行の範囲を決める、②データを整えて移す、③新旧を試して比べる、④切り替えの日を決めて移る、⑤移った後に古いシステムを止める、の順で進めます。移行でよく起きる失敗は、データを移す作業を軽く見積もること、新旧のシステムに二重に入力する期間が終わらないこと、切り替えの後に困ったときの手順を決めていないことです。新しいシステムの機能を選ぶことに比べ、移行の計画は後回しにされがちですが、移行の成否は、この計画でほぼ決まります。
移行の計画に入れる項目
| 項目 | 決めること |
|---|---|
| 範囲 | どの業務を、どの部署から移すか。移さない業務はどうするか |
| データ | どのデータを、どの期間の分まで移すか。移さないデータの保管の方法 |
| 日程 | データ移行の試し、並行の期間、切り替えの日、古いシステムを止める日 |
| 体制 | 移行の責任者、部署ごとの担当者、システムの提供元との窓口 |
| 試し | 何をどう試して、何ができれば切り替えてよいとするか |
| 戻す手順 | 切り替えの後に大きな問題が起きたときに、どう対応するか |
| 教育 | 使う人への説明の時期と方法、手順書 |
データ移行の進め方
手順 1：移すデータを決める
移すデータを、取引先や商品のような基本の情報（マスタデータ）と、受注や請求のような取引の記録に分けて考えます。基本の情報は、今使っているものを移します。取引の記録は、進行中のものと、新しいシステムで見る必要がある期間の分に絞ります。
手順 2：データを整える
古いシステムのデータには、重複、誤り、使われていない情報が含まれていることが多くあります。そのまま移すと、新しいシステムでも同じ問題が続きます。移す前に、重複をまとめ、使っていない取引先や商品を外し、表記をそろえます。整え方は、マスタデータ管理とはで説明しています。
手順 3：項目の対応を決める
古いシステムの項目と、新しいシステムの項目の対応表を作ります。項目の名前が同じでも、意味や書き方が違うことがあります（例えば、日付の形式、取引先の番号の桁数、税の区分）。対応表は、項目ごとに、古い側の値をどう変えて新しい側に入れるかまで書きます。
手順 4：試しに移して確かめる
本番の前に、データの一部か全部を、試しの環境に移します。移した後、件数が合っているか、金額の合計が合っているか、いくつかの取引先や商品を選んで中身が正しいかを確かめます。試しの移行は、問題が無くなるまで繰り返します。
切り替えの方式の選び方
| 方式 | 中身 | 向いている場合 |
|---|---|---|
| 一斉に切り替える | 決めた日に、全部の業務を新しいシステムに移す | 業務の範囲が小さい、新旧の並行が難しい |
| 並行して動かす | 一定の期間、新旧の両方で処理し、結果を比べる | 会計のように誤りの影響が大きい業務 |
| 段階的に切り替える | 部署や業務ごとに、順番に移す | 部署が多い、業務ごとに準備の進み具合が違う |
並行して動かす方式は、新しいシステムの結果を古いシステムと比べて確かめられるため安全ですが、その間は二重に入力することになり、現場の負担が大きくなります。並行の期間は、業務の周期に合わせて必要な分だけに絞り、終わりの日を最初に決めておきます。
二重入力を長引かせないための決まり
移行の後によく起きるのが、新しいシステムに入力しながら、慣れた表計算のファイルや古いシステムにも入力し続けることです。二重入力が続くと、現場の負担が増え、どちらのデータが正しいのかも分からなくなります。
これを防ぐために、次のことを決めておきます。
- 古いシステムを止める日：切り替えの日とあわせて、古いシステムへの入力を止める日と、閲覧だけにする日を決める
- 正とするデータ：切り替えの日以降は、新しいシステムのデータを正とすることを全社に伝える
- 表計算での管理の扱い：新しいシステムで管理する情報を、表計算で別に管理しないことを決める。必要な集計は、新しいシステムから出す
- 困ったときの窓口：新しいシステムの使い方で困ったときに聞く相手を決める
移行の前に業務のやり方を見直す
新しいシステムに移るときは、古いシステムでのやり方をそのまま再現しようとしがちです。しかし、古いやり方を再現するために新しいシステムに手を加えると、費用がかさみ、将来の更新のたびに手直しが必要になります。古いやり方の中には、古いシステムの制約のために生まれた手順や、今は必要の無い確認も含まれています。
移行の計画を立てる段階で、今の業務の手順を書き出し、新しいシステムの標準の機能で置き換えられる手順、やめられる手順、どうしても残す必要がある手順に分けます。残す必要がある手順だけを、新しいシステムの設定や手直しで実現します。手順を見直す判断は、現場の担当者だけでは難しいことが多いため、部署の責任者が加わって決めます。
使う人への説明の進め方
使う人への説明は、切り替えの日の直前にまとめて行うより、試しの段階から少しずつ行うほうが定着しやすくなります。部署ごとに、先に新しいシステムに触れてもらう人を決め、その人たちに試しの段階から使ってもらいます。先に触れた人は、切り替えの後に、部署の中で質問に答える役を担えます。
説明の資料は、機能の一覧ではなく、業務の場面ごとの手順にまとめます。「受注を登録する」「請求書を出す」のように、担当者が日々行う作業の順に書くと、切り替えの後にすぐ使えます。業務マニュアルの書き方は、業務マニュアルの作り方が参考になります。
移った後に確かめること
切り替えの後、最初の 1〜2 か月は、次の点を確かめます。月次の締めが期限までに終わったか、取引先への請求に誤りが無かったか、現場からの問い合わせが減ってきているか、二重入力が残っていないか、です。問い合わせの内容は記録し、よくある質問は手順書に書き足します。
移行の後に業務の手順がどう変わったかは、業務の流れの図に反映しておきます。業務の流れの図の書き方は、業務フロー図の書き方で扱っています。
実行時の落とし穴
データの移行を軽く見積もる
データの整理と試しの移行には、思った以上に時間がかかります。計画の段階で、試しの移行を複数回行う時間を取っておきます。
現場の担当者を計画に入れない
移行を情報システムの担当者とシステムの提供元だけで進めると、現場の業務の例外が見落とされます。部署ごとに担当者を決め、試しの段階から加わってもらいます。
古いシステムを止めない
古いシステムがいつまでも使える状態だと、慣れた古いシステムに戻る人が出てきます。止める日を決め、その日を過ぎたら閲覧だけにします。
