ERP知識シリーズ データ移行①：データ移行の重要性とリスクの理解
ERP導入において、データ移行が本稼働判定に大きく影響する作業であることは、誰もが認めるところでしょう。本稼働時にデータ移行に失敗すると、大量のエラーと共に発注データ不備による仕入先からの問い合わせ。在庫不整合による現場の混乱、データ修正がさらに間違いを誘発し、その混乱は短くても1週間、場合によっては数ヶ月に及ぶこともあります。最悪の場合、出荷停止に追い込まれ、旧システムに切り戻すこともあるのです。今回のERP知識シリーズでは、そのデータ移行に焦点を当て、具体的な問題とその対策について、3回に分けて解説します。
初めに、データ移行問題の原因とそのメカニズムを探る
ERP導入プロジェクトにおいて、データ移行のプロセスは「データ移行方針」「データ移行計画」「データ移行準備」「データ移行リハーサル」「本番データ移行」という段階を経て進行します。しかし、多くの問題の起因は最初の「データ移行方針」の段階で既に発生しています。たとえば、「過去5年間の実績データをすべて移行する」といった要求がその典型例です。この要求の背景には需要予測や品質管理、分析の必要性などが考えられます。しかしながら、過去データの統合はサイロ化しているレガシーシステムの複雑さを巻き込むため、整合性の検証に膨大な時間がかかることになるでしょう。同様に、「仕掛かり中のトランザクションデータ移行」を要求するケースも多いのですが、これもトランザクションデータのステータスが保てなくなり、不整合を引き起こしやすくなります。トランザクションデータのステータスとは、受注データを例にすると、登録、在庫引当、出庫指示、梱包指示、出荷完了、請求済…のことです。
さらに、「ビッグバンデータ移行」を取ることもリスクを高めます。ビッグバンデータ移行とは、本番稼働直前にマスターデータとトランザクションデータを一括移行する手法です。この手法については後ほど詳しく触れますが、準備不足で行うと失敗につながりやすい手法です。
データ移行方針の策定時には、自動倉庫や外部倉庫などの他システムへの影響も考慮する必要があります。また、VMI（ベンダー管理在庫）や支給品といった特殊な在庫管理形態も含めて検討を行います。
既存マスターデータのコード体系を変更する場合は、ERPと連携するシステムをすべて洗い出し、早い段階でそれらのシステムベンダーと対応方針を決めておくことが不可欠です。特に、在庫データの更新タイミングがバッチ処理で日を跨ぐ場合は、データ移行の難易度がさらに高まるため、入念な計画が求められます。
レガシーシステムでの在庫管理が棚卸に依存している場合、入出庫をバックフラッシュ（みなし計上）で処理している運用が該当します。この方法では、在庫の実際の動きを正確に記録しないため、在庫誤差が生じやすくなり、新システムにその誤差が引き継がれてしまいます。この問題を回避するために、本稼働前の棚卸しをデータ移行方針に必ず組み込むことを強く推奨します。棚卸しによって在庫データの精度を向上させることで、移行後の混乱を最小限に抑え、スムーズなERP本稼働を実現することが可能です。
データ移行のリスク対応の重要性
前述のように、データ移行を成功させるためには、リスク対応の適切な評価と管理が欠かせません。これが不十分であると、本稼働時に混乱を招く可能性が高まります。
たとえば、データ移行中にトラブルが発生するリスクを受容する場合、データ修正に時間がかかることを前提にし、通常業務の負荷を減らす必要があります。このような「発生時リスク対応（コンティンジェンシープラン）」としては、以下のような策が考えられます：
- 仕入を前倒しして在庫を積み上げておく
- 本稼働初日には仕入れを一時停止し、混乱を抑える
これらの対応を実行するには、経営層と業務部門の理解と協力が不可欠です。ただし、経営層からは「顧客や仕入先に迷惑をかけられない」「年度末に在庫を増やせない」といった反対意見が出ることもあります。しかし重要なのは、迷惑や混乱が「1日で終わるのか、何週間にも及ぶのか」を冷静に判断し、適切なリスク対応を講じることです。
データ移行チームの編成：業務部門を加える理由
これらの取り組みは、データ移行チームが中心となって推進します。データ移行は情報システム部門が担当すると思われがちですが、効果を最大化するためには、業務部門をチームに加えることが重要です。
データ移行は単なるシステム移行ではなく、運用移行も伴います。さらに、レガシーシステムのデータの用途や意味を最も理解しているのは業務部門であり、その知識が新システムへのデータマッピングに不可欠だからです。業務部門の協力により、データ移行の精度と効率が格段に向上します。
次回は「データ移行②:実践的な準備」について詳しく解説します。
