ERP データのクリーンアップ: 移行前の重要な手順

重要なポイント

• データ クリーンアップは、移行スケジュール全体の 30 ～ 40% を消費する必要があります。プロジェクト スケジュールで明示的に計画します。
• トランザクション データの前にマスター データ (顧客、製品、ベンダー) から開始します。マスター データ エラーは連鎖します。
• 完全一致、あいまい一致、ビジネス ルール一致を組み合わせた重複検出アルゴリズムにより、重複の 95% を検出します
• 孤立レコード (削除されたマスター データを参照するトランザクション) がインポート失敗の最も一般的な原因です
• データ品質スコアリングにより、クリーンアップの進行状況を追跡し、「完了」基準を定義するための客観的な指標が得られます。
• 削除ではなくアーカイブ — 税金、コンプライアンス、または傾向分析のために履歴データが必要になる場合があります
• エンティティ タイプごとにデータ所有者を割り当てる - 所有権のないクリーンアップは責任追及に発展する

---

クリーンなデータが思っている以上に重要である理由

新しい ERP 内のダーティ データのコストは理論上のものではありません。具体的な結果は次のとおりです。

財務上のエラー 顧客記録が重複すると、請求書の重複、支払いの分割申請、および不正確な年齢レポートが発生することになります。顧客は、実際には 2 つのレコードで 25,000 ドルの負債があるにもかかわらず、50,000 ドルの負債を負っているように見えます。回収チームは幻の残高を追いかけて時間を無駄にしています。

在庫の不正確さ 名前がわずかに異なる重複した製品レコードは、在庫がレコード間で分割されていることを意味します。実際には同じ製品が 25 ユニットある場合でも、システムには「ウィジェット ブルー、ラージ」が 10 ユニット、「ブルー ウィジェット - LG」が 15 ユニットと表示されます。並べ替えポイントが正しくトリガーされません。

自動化が壊れています。 ERP 自動化ルールは特定のレコードを参照します。支払い期限を過ぎた請求書を持つ顧客に支払いリマインダーを送信するワークフローでは、重複したレコードを持つ顧客に 2 つのリマインダーが送信されます。自動再注文ルールは重複する商品ごとにトリガーされます。

レポートの歪み。 販売レポートには顧客数が水増しされて表示されます。製品レポートには断片的な在庫が表示されます。財務報告書では、重複した記録に関連する収益または費用が二重にカウントされます。

ユーザーの不満。 ERP の導入を阻止する最も手っ取り早い方法は、ユーザーが新しいシステム内の汚いデータを目にすることです。営業担当者が顧客を検索し、ほぼ同一のレコードを 3 つ見つけた場合、システムと移行プロジェクトに対する顧客の信頼は即座に失われます。

---

ステップ 1: 重複の検出

3 レベルの重複検出

レベル 1: 完全一致。 キー フィールド全体で同一のレコード。検出は簡単ですが、最も明らかな重複のみを検出します。

• 同じメールアドレス
• 同一電話番号（フォーマット正規化後）
• 同じ納税者番号/法人登録番号
• 同じSKU/製品コード

レベル 2: あいまい一致。 類似しているが同一ではないレコード。レーベンシュタイン距離、Soundex、Jaro-Winkler 類似度などのアルゴリズムが必要です。

• 「ECOSIRE Pvt Ltd」対「ECOSIRE Private Limited」対「Ecosire Pvt. Ltd」
• 「123 メイン ストリート」対「123 メイン ストリート」 vs. 「123 Main St、スイート 100」
• 「青ウィジェット (大)」対「ウィジェット - 青、L」対「BLU-WDGT-LG」

レベル 3: ビジネス ルールの一致。 見た目は異なっていても、ビジネス コンテキストに基づいて同じエンティティを表すレコード。

• 同じ会社名 + 同じ都市 (住所が異なっていても同じ顧客である可能性が高い)
• 同じ製品寸法 + 同じ素材 (名前が異なる同じ製品である可能性があります)
• 同じベンダー + 同じ銀行口座 (ベンダー記録が重複している可能性があります)

重複検出プロセス

エンティティ タイプ別のマージ ルール

顧客結合ルール:

• 最新の取引アクティビティの記録を保持します。
• すべての住所を統合します (プライマリとしてマークし、他の住所を配送/請求先の代替として保持します)
• 残っている記録の下にすべての連絡先担当者を統合します
• すべての注文、請求書、支払いを残っている記録に再割り当てします
• 最も古い作成日を保存します (顧客の保有期間の計算用)

商品結合ルール:

• カタログに一致するアクティブな SKU の記録を保持します
• 重複レコード全体の在庫数量を統合する
• すべての注文明細と請求書明細を存続するレコードに再割り当てします。
• 残っているレコードを指すメモを付けて、重複した SKU をアーカイブします。

ベンダー結合ルール:

• 現在の銀行口座の詳細と支払い条件を記録してください。
• すべての注文書と請求書を残っているレコードにマージします。
• ベンダーの連絡先を統合する
• 残っている記録に税務情報が最新であることを確認する

---

ステップ 2: 孤立レコードの識別

孤立レコードは、存在しなくなったか、誤ってリンクされたマスター データを参照するトランザクションです。これらは、重複に次いでインポート失敗の 2 番目に一般的な原因です。

一般的な孤立パターン

孤立検出クエリパターン

トランザクション エンティティごとに、その親マスター データに対して相互参照チェックを実行します。

For every sales order line:
  → Does the customer_id exist in the customers table?
  → Does the product_id exist in the products table?
  → Does the salesperson_id exist in the employees table?

For every invoice:
  → Does the customer_id exist in the customers table?
  → Does each line's product_id exist in the products table?
  → Does the payment_term reference exist in the payment terms table?

For every purchase order:
  → Does the vendor_id exist in the vendors table?
  → Does each line's product_id exist in the products table?

孤立した解決戦略

戦略 1: 再接続。 マスター レコードが削除されたが存在するはずである場合は、マスター レコードを再作成し、孤立したトランザクションをリンクします。これは、製造中止になったが注文履歴がある製品によく見られます。

戦略 2: 再分類。 孤立したトランザクションをキャッチオール マスター レコードに割り当てます。 「従来の顧客」連絡先または「アーカイブされた製品」レコードを作成し、そこに孤立者を再割り当てします。これにより、データ品質の問題を認識しながら財務総額が維持されます。

戦略 3: アーカイブ。 孤立したトランザクションを移行範囲外のアーカイブ テーブルに移動します。これらを参照用に別の履歴データ エクスポートに含めますが、新しい ERP にはインポートしません。

---

ステップ 3: データ検証ルール

フィールドレベルの検証

エクスポートする前に、次の検証ルールをすべてのレコードに適用します。

テキストフィールド:

• 先頭または末尾の空白なし
• テキスト内にダブルスペースは使用できません
• 一貫した大文字化 (名前の場合はタイトルの大文字、コードの場合は大文字)
• 英数字である必要があるフィールドに特殊文字を使用しないでください (SKU、コード)
• 文字エンコーディングは一貫しています (全体的に UTF-8)。

電子メールフィールド:

• @ 記号が 1 つだけ含まれます
• ドメインには @ の後に少なくとも 1 つのドットが必要です
• メールアドレスにスペースは含まれません
• 小文字 (メールアドレスでは大文字と小文字が区別されません)
• プレースホルダーではありません (noemail@example.com、test@test.com)

電話番号フィールド:

• 一貫した形式 (+1-555-123-4567 または +15551234567 のいずれかを選択)
• 国際番号に含まれる国コード
• +、-、(、) 以外の文字または特殊文字は使用できません
• 国の有効な長さ

日付フィールド:

• 一貫した形式 (ISO 8601: YYYY-MM-DD)
• 論理的に不可能な将来の日付はありません (例: 2030 年の請求日)
• 不当に古い日付は使用しないでください (例: 多くのシステムのデフォルトである注文日 1900-01-01)
• 日付範囲は論理的です (開始日が終了日より前)

数値フィールド:

• 数値フィールドにテキストはありません (桁区切り文字としてカンマを使用すると、インポートが失敗します)
• 一貫した小数精度 (通貨の場合は 2 桁、小さい値の単価の場合は 4 桁)
• 論理的に不可能な場合には負の値は使用できません (数量、価格)
• 通貨値が予想範囲内 (ボーイングでない限り、9 億 9,999 万 999 ドルの請求書は発行されません)

必須フィールド:

• 顧客名が空白になることはありません
• 製品名と SKU が空白になることはありません
• 請求書番号が空白になることはなく、重複することもありません
• すべての外部キー参照は既存のレコードを指します

レコード間の検証

個々のフィールドのチェックを超えて、関連するレコード間の一貫性を検証します。

• 請求書品目の金額の合計が請求書の合計と等しい
• 請求書に適用される支払いの合計が請求書の合計を超えない
• 手持在庫にはマイナスの数量が表示されません (システムで許可されている場合を除く)
• 従業員の勤務開始日が、関連するタイムシート エントリよりも前です。
• 製品の作成日は、関連する販売注文明細行より前です。

---

ステップ 4: アーカイブ戦略

すべてのデータを移行する必要があるわけではありません。コンプライアンス要件、ビジネス ニーズ、移行の複雑さのバランスを取るアーカイブ ポリシーを定義します。

アーカイブの決定フレームワーク

アーカイブ形式の推奨事項

ERP の外部でアーカイブするデータの場合:

1. 明確な列ヘッダーと UTF-8 エンコードを使用して CSV にエクスポート
2. 各列、そのデータ型、有効な値を定義する データ ディクショナリを含める
3. バージョン管理された不変の場所に保存します (バージョン管理のある S3、または暗号化されたバックアップ)
4. 保存スケジュールを設定します (ほとんどの管轄区域では財務データの場合は 7 年、一部の業界ではそれ以上)
5. アーカイブをコンプライアンス記録に文書化します。これには、内容、日付範囲、保存ポリシーが含まれます。

---

ステップ 5: マスター データ ガバナンス

データのクリーンアップは 1 回限りのイベントではありません。ガバナンスがなければ、ピカピカの新しい ERP でも 12 ～ 18 か月以内に同じデータ品質の問題が蓄積されてしまいます。

データ所有権マトリックス

データ入力標準

各エンティティの基準を文書化して施行します。

お客様の作成基準:

• 会社名: 正式な法人名 (登録書類と照合して確認してください)
• 商号：法人名と異なる場合は別途記載
• 住所: その国の郵便サービス形式を使用します。
• 主な連絡先: 名前 + メール + 電話番号が必要です
• 支払い条件: デフォルトは作成時に設定されており、変更するには承認が必要です
• 与信限度額: 販売ではなく財務によって設定されます

商品作成基準：

• 商品名：【ブランド】【品名】【バリエーション】【サイズ】（例：「ECOSIRE Widget Blue Large」）
• SKU: [カテゴリ]-[シーケンス]-[バリアント] (例: "WDG-001-BL")
• 説明: 最小 50 文字、説明に HTML 形式は使用できません
• カテゴリ: 既存のカテゴリから選択する必要があります (自由記述カテゴリはありません)
• 測定単位: 承認されたリストの標準単位を使用する必要があります
• 画像: 最小 1 つの画像、最大サイズ 2048x2048、白背景

自動化されたデータ品質ルール

新しい ERP で次のルールを構成して、最初からダーティ データを防止します。

• 重複防止: 同じ電子メール、電話番号、または納税者 ID を持つ記録がすでに存在する場合、保存時に警告します。
• 必須フィールドの強制: 必須フィールドが空の場合、作成をブロックします。
• 形式の検証: 無効な電子メール形式、電話形式、および日付形式を拒否します。
• 承認ワークフロー: 新規顧客とベンダーの作成にはマネージャーの承認が必要です
• 定期的なレビュー: 12 か月以上更新されていない記録を強調表示する自動レポート

---

ステップ 6: データ品質スコアリング

採点方法

各データ エンティティを 4 つの次元でスコア付けし、それぞれ 1 ～ 5 で評価します。

採点プロセス

1. サンプル: レコードのランダムな 5% (最小 100、最大 500)
2. 完全性のチェック: 空白の必須フィールドをパーセンテージとしてカウントします。
3. 一貫性の確認: テキスト、日付、電話、電子メールの各フィールドの形式の準拠性を確認します。
4. 精度の確認: サンプリングされた記録を外部ソース (Web サイト、登録データベース、実地在庫数) と照合して検証します。
5. 一意性のチェック: データセット全体に対して重複検出を実行し、レートを計算します。

移行の最小品質しきい値

スコアが最小しきい値を下回るエンティティについては、移行を続行しないでください。インポート後のデータのクリーニングにかかる​​コストは、インポート前のクリーニングに比べて 3 ～ 5 倍高くなります。

---

データ クリーンアップ タイムライン テンプレート

---

ツールとリソース

オープンソース データ クリーンアップ ツール

• OpenRefine: 乱雑なデータをクラスタリング、ファセット化、変換するための強力なデータ クリーニング ツール
• dedupe.io: Python 用の機械学習ベースの重複排除ライブラリ
• 大きな期待: 自動品質チェックのためのデータ検証フレームワーク
• pandas (Python): カスタム クリーンアップ スクリプトのための柔軟なデータ操作
• csvkit: CSV の検査と検証のためのコマンドライン ツール

商用データ品質プラットフォーム

• Informatica Data Quality: エンタープライズ グレードのクレンジングとマッチング
• Talend Data Quality: プロファイリング、クレンジング、標準化
• Melissa データ: アドレス検証、電子メール検証、重複検出
• IBM InfoSphere QualityStage: マスター データのマッチングと標準化

---

よくある質問

データのクリーンアップにはどれくらいの時間がかかりますか?

中規模企業 (5,000 ～ 50,000 の顧客レコード、1,000 ～ 10,000 の製品) の場合は、6 ～ 10 週間の専用の取り組みを計画してください。これは、フルタイムのデータ アナリストが 1 名いることに加えて、各部門のデータ所有者がパートタイムで関与することを前提としています。数十万のレコードや複雑なマルチシステム環境を抱える大企業の場合は、12 ～ 16 週間かかる場合があります。

古いシステムまたはステージング ファイルのデータをクリーンアップする必要がありますか?

ライブ システムではなく、ステージング ファイル (エクスポートされた CSV またはステージング データベース) でクリーンアップします。これにより、本番データがフォールバックとして保存され、複数人による並行クリーンアップが可能になり、日常業務の中断が回避されます。クリーンなデータが新しい ERP にインポートされるまで、稼働中のシステムはそのまま稼働し続けます。

品質の最低しきい値に到達できない場合はどうすればよいですか?

特定のエンティティが最小スコアに到達できない場合は、根本原因を調査します。データ量の問題 (手動でクリーニングするにはレコードが多すぎる) の場合は、最新または最もアクティブなサブセットのみをインポートし、残りをアーカイブすることを検討してください。それが構造的な問題である場合 (新しい ERP が必要とするものをサポートするようにデータが設計されていない場合)、外部ソースからデータを強化するか、一部のレコードには移行後に手動での対応が必要になることを受け入れる必要があるかもしれません。

データ クリーンアップの責任者は誰ですか?

データのクリーンアップはビジネスの責任であり、IT の責任ではありません。 IT 部門はツールとインフラストラクチャを提供しますが、ビジネス ユーザーは、どの重複レコードを保持するか、孤立した注文を再接続するかアーカイブするか、正しい製品名の形式をどうするかなどを決定する必要があります。各部門からデータ所有者を割り当て、エンティティ品質スコアに対する責任を負わせます。

データのクリーンアップを自動化できますか?

部分的に。自動化ツールは、形式の標準化 (電話番号、住所、日付)、完全一致重複排除、および検証ルールのチェックを処理します。ただし、あいまい一致の重複のマージ、孤立したレコードの解決、データの正確性の検証には人間の判断が必要です。 60% が自動化され、40% が手動で行われるように計画します。

移行後にデータ品質の問題が見つかった場合はどうすればよいですか?

変更がアクティブなワークフローに影響を与えるライブ システムを扱うことになるため、移行後のクリーンアップは移行前のクリーンアップよりも 3 ～ 5 倍の費用がかかります。稼働後に問題が見つかった場合は、ビジネスへの影響に基づいて優先順位を付けます。最初に財務上の正確性に影響を与える記録を修正し、次に顧客向けの記録、次に内部の運用記録の順に修正します。

ECOSIRE はデータのクリーンアップに役立ちますか?

はい。データ クリーンアップは、ECOSIRE の 移行サービス の中核コンポーネントです。当社は、すべての移行プロジェクトの一環として、データ プロファイリング、自動重複排除、品質スコアリング、クリーンアップ スクリプトを提供します。私たちのチームはデータ所有者と協力して、ビジネスの状況があらゆるクリーンアップの決定を確実に推進するように努めます。データ品質に関する課題については、お問い合わせ してください。

---

データ品質評価から始める

移行の最初のステップは、データの現在の状態を理解することです。データ品質評価には 3 ～ 5 日かかり、すべての主要エンティティの重複率、完全性スコア、形式の不一致、孤立レコード数を示す詳細なレポートが作成されます。

ECOSIRE では、移行計画サービス の一環として、無料のデータ品質評価を提供しています。現在のデータを分析し、最も影響の大きいクリーンアップ タスクを特定し、移行に備えた品質を達成するための現実的なタイムラインと労力の見積もりを提供します。

無料のデータ品質評価をリクエストして、クリーンで成功した移行への第一歩を踏み出しましょう。