ERPのデータ移行とマスタ整備｜対象・品質・照合をどう決めるか
KXSfourthERPのデータ移行は、旧システムのデータを新しい形式へ変換して取り込むだけではありません。移す範囲と意味を決め、業務で使える品質を確認する活動です。本記事では、マスタ、開始残高、未完了取引、履歴の整理と、責任分担・移行テストの進め方を説明します。
この記事の要点
- 何を移すかに加え、移さないデータの参照・保存方法も決める
- 変換と取込の成功だけでなく、業務上の正しさを照合する
- 本番移行前に、所要時間・依存関係・責任者を検証する
Agenda（この記事の内容）
- 移行対象をデータの種類で分ける
- マスタの意味と管理責任を揃える
- 項目の対応と変換ルールを定義する
- 照合基準を先に決める
- 移行テストと本番の手順を揃える
- 移行の不一致を説明できる記録を残す
- よくある質問
移行対象をデータの種類で分ける
移行対象は、取引先や商品などのマスタ、業務を動かす設定、開始残高、未完了取引、過去履歴などに分けます。すべてを同じ方式で移す必要はありません。新システムで何を実行・参照したいかから対象を決めます。
開始残高だけ移すのか、請求や受注の明細も移すのかによって、その後の消込や出荷、問い合わせの方法が変わります。業務の途中にある取引をどうつなぐかを確認します。件数の少なさだけで省略を決めないことが重要です。
移さない履歴は、誰がどこで参照し、必要な期間どう保存するかを決めます。保存要件は自社の担当者と確認します。旧システムを残す場合の費用、アクセス、検索方法も移行計画の対象です。
マスタの意味と管理責任を揃える
マスタ整備では、重複や空欄を修正するだけでなく、コードと属性の意味を揃えます。同じ取引先を部門別のコードで管理していた場合、統合するのか、用途別に残すのかを決めます。単純な名寄せで取引条件を失わないようにします。
管理責任者は、登録・変更・廃止のルールと承認を定めます。移行直前だけデータを整えても、稼働後に同じ問題が再発する場合があります。新しい業務で誰が品質を維持するかまで考えます。
架空の例として、商品コードを統合するなら、在庫、単位、価格、過去取引との関係を確認します。コード一覧だけを変えると、他システムや帳票へ影響する可能性があります。参照される範囲を確認して判断します。
| データ | 主な確認 |
|---|---|
| マスタ | 重複・定義・管理責任 |
| 残高 | 基準日・集計単位・明細 |
| 未完了取引 | 残る作業と新システムでの継続 |
| 履歴 | 移行の必要性・参照・保存 |
| 移行手順 | 順序・時間・再実行・承認 |
項目の対応と変換ルールを定義する
旧データの項目と新しい項目を対応させ、値の変換、初期値、桁、日付、通貨、単位などのルールを記録します。該当する値がない場合や、不明なデータがある場合の扱いも決めます。担当者の判断で埋めると、後で理由を追えなくなります。
移行では、取込順序と依存関係があります。取引先や商品を先に準備しなければ、取引を作れない場合があります。設定とマスタ、残高と明細などの関係を整理し、実行順を計画します。
データの抽出担当、修正担当、変換担当、取込担当、承認者を分けて明示します。パートナーが取込ツールを用意しても、元データの正しさと業務上の意味は自社側の確認が必要です。
照合基準を先に決める
取込の成功メッセージだけでは移行完了と判断できません。件数、金額、数量などの合計と、重要な明細を照合します。業務で使う一覧や帳票から、必要な状態になっているかも確かめます。
例えば売掛金では、全体の合計が合っていても、取引先や通貨、期日への配分が違う可能性があります。合計と明細を組み合わせ、何をどの単位で照合するかを決めます。差額や不一致の扱いも記録します。
照合には、移行元の基準時点と新システム側の基準を揃えます。抽出後に旧システムの取引が動けば、差が生まれます。凍結、差分抽出、最終更新の手順を含め、どの時点の正しさを確認するかを明らかにします。
移行テストと本番の手順を揃える
移行テストでは、処理の正しさに加え、所要時間、エラー、再実行、照合の工数を測ります。本番で使う手順に近づけ、担当者が交代しても実行できるかを確認します。成功した一回の結果だけで判断しません。
本番の切替時間に収まるかを確認し、遅れた場合の判断時刻を決めます。途中で失敗したとき、どこから再開し、重複をどう防ぐかも必要です。移行をやり直す場合には、前の取込結果の扱いを製品の方式に従って決めます。
完了時には、照合結果、残る問題、業務責任者の承認、参照データの場所を残します。移行の終了はファイルを渡した時点ではなく、新システムで業務を開始できる状態を確認した時点です。
移行の不一致を説明できる記録を残す
売掛金の残高が移行前後で一致しない場合、合計値だけを並べても原因はわかりません。基準日、取引先、通貨、請求番号、消込状態などへ分けて差を探します。旧システムの残高と新システムの集計条件が同じか、移行対象外の取引がないかを確認します。
対応では、元データの修正、変換ルールの修正、取込方式の修正のどれかを区別します。取り込んだ後の値だけを手で合わせると、再移行で再発する可能性があります。修正理由と対象、再実行の結果を記録し、同じ手順で再現できる状態へ戻します。
照合結果には、集計の条件と証拠を添え、業務責任者が承認します。差があるまま受け入れる場合は、影響と対応方針を明示します。移行後に問題が見つかったときにも、誰が何を確認したかを追えることが、調査と復旧の助けになります。
本番直前の変更は、元データを直しただけでも再検証が必要な場合があります。データと変換ルール、手順の版を揃え、リハーサルで確認した条件が本番でも有効かを見ます。
本番の照合には実施者と確認者、確認時刻を残します。問題を見つけたときに次の処理を止める連絡経路も決めます。データの正しさを確認する作業が、他の作業の時間に押されて省略されない計画にすることが重要です。
照合の基準日も明記します。
よくある質問
過去の全データを移すべきですか？
業務、参照、保存の要件から判断します。移行しない履歴も、必要な期間、適切な権限で参照できる方法を決めます。
合計金額が一致すれば完了ですか？
全体合計だけでは、取引先や期日、通貨などの誤りを検知できない場合があります。集計単位と明細、実際の業務処理を組み合わせて確認します。
次に確認すること
データごとに移行・参照のみ・不要の区分を付け、業務責任者と照合基準を決めてください。
- ERPの要件定義とは？選定時の要件を具体化する進め方
- ERPのテストと受入判定｜業務シナリオ・合否基準・残る問題の扱い
- ERPの本番切替と稼働判定｜開始条件・切戻し・初動支援の考え方
- ERPの導入範囲をどう決めるか｜対象業務・拠点と段階導入の考え方
参考情報・編集方針
本文の手順・評価例はERP選定ラボによる整理です。事例・数値例は説明用の仮定です。製品固有の機能・条件は各社の最新資料で確認してください。
参考情報の確認日：2026年10月28日。運営方針・プロフィール
