ERP知識シリーズ データ移行②:実践的な準備

前回の「データ移行①:データ移行の重要性とリスクの理解」では、データ移行の方針策定やリスクの認識、そして業務部門を含めたデータ移行チームの重要性について解説しました。今回は、その続編として、データ移行の具体的な準備手順や注意点について詳しく解説します。特に、ETLCプロセス(抽出、変換、ロード、検証)を活用した移行準備の方法や、データ精度を向上させるポイントに焦点を当てます。

データ移行の難易度を表す方程式

データ移行計画を立てる際、難易度を数値化すると理解が深まります。

難易度=複雑性×データボリューム

データ量が増えるほど、移行時間やエラー対応にかかる労力は増大しますが、特に課題となるのは「複雑性」です。たとえば、コード体系の見直しやレガシーシステムの制約(バッチ処理のタイミング)などが複雑性を引き上げます。「ERP知識シリーズ The品目マスター」で品目マスター再定義の必要性を挙げましたが、同時に複雑性が増す可能性があります。これらの課題は、APIやデータ移行ツールの活用、エラー検知と修正ロジックの設計によって部分的に軽減できますが、根本的な解決には「データ移行方針」に立ち返る必要があります。

ETLCプロセスによるデータ移行準備の進め方

データ移行準備では、ETL(抽出、変換、ロード)に「C(チェック)」を加えたETLCのプロセスを適用します。それぞれの工程について説明と注意点をまとめます。

Extract 抽出:データをソースシステム(例:レガシーシステム、データベース、ファイルストレージなど)から取り出す工程です。

  • 複数システムからのデータ抽出:販売管理、生産管理など、異なるシステムから必要なデータを収集します。
  • データ更新と抽出タイミングの調整:レガシーシステムのデータ更新と抽出タイミングにタイムラグが生じないようにします。
  • データクレンジングと抽出対象の明確化:不必要なデータを排除し、必要なデータのみを抽出します。
  • 抽出責任者の決定とチェックリストの活用:各データ項目ごとに責任者を定め、チェックリストで管理します(特に外部倉庫の在庫情報など)。
  • 抽出処理時間の測定と目標設定:処理時間を計測し、移行期間内で完了するための目標を設定します。

Transform 変換:抽出したデータをターゲットシステム(新しいERPシステム)の要件に合わせて加工・変換する工程です。

  • データ項目のマッピングとコード統一:異なるシステム間でのデータ項目を対応付け、コード体系を統一します。
  • システム間のデータ紐付け:変換エラー時に追跡しやすいよう、レガシーシステムと新システムのデータをリンクします。
  • 既存オーダー番号の関係性保持:オーダー番号などの重要な識別子の関連性を維持します。
  • 現場でのコード差し替え:倉庫の棚ラベルや工程カンバンに記載されたコードも新しいものに更新します。
  • 変換処理時間の測定と目標設定:変換に要する時間を計測し、移行期間内で完了するための目標を設定します。

Load ロード:変換したデータをターゲットシステムにロードする工程です。新システムに不整合となるデータはこの段階でエラーとして検出されます。

  • 移行ツールの準備:適切なデータ移行ツールを選定・準備します。
  • 直接登録の検討:データ量が少ない場合は、ERPの画面で直接登録する方法もあります。
  • ロード順序の最適化:データ間の依存関係を考慮し、適切な順序でロードします(後述します)。
  • ロード処理時間の測定と目標設定:ロードに要する時間を計測し、移行期間内で完了するための目標を設定します。

Check 検証:新システムの運用モデルに適合したデータ移行が行われているかを確認する工程です。データの組み合わせや業務プロセスにおける整合性をチェックし、エラーや不適合を検出します。特に、レガシーシステムで管理されていなかった管理コードや、新たな業務ルールが原因でエラーが発生することが予想されます。

検証すべき主なポイント:

  • 品目コードと品目属性の整合性(例:原材料の品目が最終製品の品目タイプとして登録されている)
  • 購買品で購買単価マスター無し(例:購買品に対して購買単価マスターが登録されていない)
  • 製品で販売単価マスター無し(例:製品に対して販売単価マスターが登録されていない)
  • BOM(部品表)における製品と原材料の関係(例:製品に含まれる原材料が登録されていない)
  • 製造品の工順の有無(例:製造品に対して工順が設定されていない)
  • 工順の内製品・外注品フラグの誤り(例:内製品なのに外注品としてフラグが設定されている)
  • 在庫評価方法の一致(例:総平均法から移動平均法に変更した場合、新しい評価方法に沿って在庫金額が計上されているか)
  • 在庫評価額の一致(例:在庫サブシステムと財務システムの在庫評価額が一致しているか)
  • 標準原価の新旧システム間の差異(例:旧システムで計算された標準原価と新システムで計算された標準原価の差異が許容範囲内か)
  • ロケーションコードと在庫品目の一致(例:指定の倉庫に存在しない品目が割り当てられている)
  • 発注品目と供給元の適合性(例:国内品目に海外仕入先が指定されている)
  • 輸入品で輸入倉庫からの物流経路の未登録(例:輸入品の輸入デポから自社倉庫までの物流経路が設定されていない)
  • 製造スケジュールと工場カレンダーの一致(例:非稼働日にスケジュールが設定されている)
  • 顧客タイプと取引条件の一致(例:法人顧客に個人向け条件が適用されている)
  • 顧客住所と配送ルートの整合性(例:顧客住所が対象外エリアである)
  • 出荷納期の実現性(例:納品に2日かかるにもかかわらず、受注データの納期が明日になっている)
  • 通貨換算の正確性(例:海外取引や外貨建て在庫の場合、通貨換算レートが正しく適用されているか)
  • 債権債務額の一致(例:販売・購買サブシステムと財務システムの債権債務額が一致しているか)

中でも時間がかかるのが、原価積み上げ結果の整合性の確認です。原価は、原材料の購入価格、単位、BOMの精度、作業時間など、多岐にわたるデータに依存します。また、工場ごとにBOMが異なる場合は、生産技術部門が登録した後、工場担当者の確認が必要になるなど、部門を横断したチームワークが重要です。このチームワークによって原価データの精度を高めることができ、それが移行データ全体の品質向上につながります。

データ移行の順序

ERPのマスターデータは100から300種類ほど存在し、それらの登録順序はマスター間の関係性に基づいて決まっています。例えば、品目マスターは価格表データより先に登録する必要があります。この順序を無視すると、後続のデータ登録時にエラーが発生し、移行作業の効率が大きく損なわれます。そこで、適切な順序に従い、事前にWBS(Work Breakdown Structure:作業分解構成図)にマスターデータ移行のタスクを順序通りに登録することで、手順ミスを防ぎ、進捗管理も容易になります。WBSについての詳細は、「ERPを初めて導入される方でも安心のプロジェクト運営をWrikeで実現」をご参照下さい。プロジェクト管理のポイントや具体的な活用方法を解説しています。

移行回数に応じたゴール設定とマスターデータメンテナンスの継続

初回のマスターデータ移行では、エラーの完全修正を目指すのではなく、まずはエラーの検出を目的とします。エラーが残っていても、一通りのマスターデータを移行することで、全体的なエラーの原因を網羅的に把握できます。

また、一度移行したマスターデータは、その後も定期的にメンテナンスを行い、レガシーシステムとの同期を維持します。この継続的なメンテナンスは手間がかかりますが、以下のメリットがあります。

  • トランザクションデータの検証がスムーズに行える
  • 本稼働直前にマスターデータを再度移行する必要がないため、データ移行の時間を節約できる。

この方法を「ハイブリッドデータ移行」と呼びます。これを実現するためには、データ移行方針の段階でプロセスを明確に定義し、計画段階で業務部門との連携を強化することが重要です。

一通りのマスターデータが登録できたら、データ移行リハーサルに進む前にバックアップを取得しておくと良いでしょう。これにより、トランザクションデータの移行リハーサルを短いサイクルで何度も繰り返すことが可能となり、移行の精度と効率を大幅に向上させることができます。

これでデータ移行の準備は整いました。次回の第3回では、いよいよ本稼働に向けた最終ステップとして、「データ移行③: ソフトランディングに本稼働を迎える」をテーマに、具体的な取り組みについて詳しく解説します。(※12月12日投稿予定)