ERP 数据清理：任何迁移之前的基本步骤

要点

• 数据清理应占用总迁移时间的 30-40% — 在项目时间表中明确规划
• 在交易数据之前从主数据（客户、产品、供应商）开始 - 主数据错误级联
• 结合精确匹配、模糊匹配和业务规则匹配的重复检测算法可捕获 95% 的重复项
• 孤立记录（引用已删除主数据的事务）是导入失败的最常见原因
• 数据质量评分提供客观指标来跟踪清理进度并定义“完成”标准
• 存档而不是删除 - 您可能需要历史数据进行税务、合规性或趋势分析
• 为每个实体类型分配数据所有者——没有所有权的清理工作会变成相互指责

---

为什么清洁数据比您想象的更重要

新 ERP 中脏数据的成本并不是理论上的。具体后果如下：

财务错误。 重复的客户记录意味着重复的发票、拆分付款申请和不正确的账龄报告。客户在两条记录中似乎欠了 50,000 美元，而实际上他们欠了 25,000 美元。您的收款团队浪费时间去追寻虚拟余额。

库存不准确。 名称略有不同的重复产品记录意味着库存分散在多个记录中。当您实际拥有 25 件相同产品时，您的系统显示 10 件“Widget Blue，Large”和 15 件“Blue Widget - LG”。重新排序点触发不正确。

自动化遭到破坏。 ERP 自动化规则引用特定记录。向具有逾期发票的客户发送付款提醒的工作流程将向具有重复记录的客户发送两个提醒。每个重复产品都会触发自动重新订购规则。

报告失真。 销售报告显示客户数量夸大。产品报告显示分散的库存。财务报告重复计算与重复记录相关的收入或支出。

用户感到沮丧。 阻止 ERP 采用的最快方法是用户在新系统中看到脏数据。如果销售人员搜索客户并找到三个几乎相同的记录，他们对系统以及迁移项目的信心会立即消失。

---

步骤 1：重复检测

三个级别的重复检测

级别 1：完全匹配。 关键字段中相同的记录。易于检测，但仅捕获最明显的重复项。

• 相同的电子邮件地址
• 相同的电话号码（标准化格式后）
• 相同的税号/公司注册号
• 相同的 SKU/产品代码

级别 2：模糊匹配。 相似但不相同的记录。需要 Levenshtein 距离、Soundex 或 Jaro-Winkler 相似度等算法。

• “ECOSIRE Pvt Ltd”与“ECOSIRE Private Limited”与“Ecosire Pvt. Ltd.”
• “123 Main Street”与“123 Main St.”与“123 Main St，Suite 100”
• “蓝色小部件（大）”与“小部件 - 蓝色，L”与“BLU-WDGT-LG”

级别 3：业务规则匹配。 看起来不同但根据业务上下文表示相同实体的记录。

• 相同的公司名称+相同的城市（即使地址不同也可能是同一客户）
• 相同的产品尺寸+相同的材料（可能是相同的产品但命名不同）
• 相同的供应商+相同的银行账户（可能是重复的供应商记录）

重复检测过程

按实体类型合并规则

客户合并规则：

• 保留最近的交易活动记录
• 合并所有地址（标记主要地址，保留其他地址作为运输/计费替代地址）
• 合并幸存记录下的所有联系人
• 将所有订单、发票和付款重新分配到幸存记录
• 保留最早的创建日期（用于客户任期计算）

产品合并规则：

• 保留与您的目录相匹配的活动 SKU 的记录
• 合并重复记录中的库存数量
• 将所有订单行和发票行重新分配给剩余记录
• 归档重复的 SKU，并附上指向幸存记录的注释

供应商合并规则：

• 保留当前银行详细信息和付款条件的记录
• 将所有采购订单和账单合并到幸存记录下
• 整合供应商联系方式
• 验证现有记录中的税务信息是否最新

---

步骤 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）

电子邮件字段：

• 恰好包含一个@符号
• 域@后至少有一个点
• 电子邮件地址中不能有空格
• 小写（电子邮件地址不区分大小写）
• 不是占位符（[email protected]、[email protected]）

电话字段：

• 一致的格式（选择一项：+1-555-123-4567 或 +15551234567）
• 包含国际号码的国家/地区代码
• 除+、-、(、) 之外，不能有任何字母或特殊字符
• 国家/地区的有效长度

日期字段：

• 一致的格式（ISO 8601：YYYY-MM-DD）
• 没有逻辑上不可能的未来日期（例如 2030 年的发票日期）
• 没有不合理的旧日期（例如，订单日期 1900-01-01，许多系统的默认值）
• 日期范围符合逻辑（开始日期早于结束日期）

数字字段：

• 数字字段中没有文本（逗号作为千位分隔符会导致导入失败）
• 一致的小数精度（货币2位，小值单价4位）
• 逻辑上不可能的情况下没有负值（数量、价格）
• 货币值在预期范围内（除非您是波音公司，否则不会开具 999,999,999 美元的发票）

必填字段：

• 客户名称不能为空
• 产品名称和 SKU 不能为空
• 发票号码不能为空且不能重复
• 所有外键引用都指向现有记录

交叉记录验证

除了单独的字段检查之外，还验证相关记录之间的一致性：

• 发票行金额总和等于发票总额
• 应用于发票的付款总额不超过发票总额
• 现有库存不显示负数量（除非系统允许）
• 员工开始日期早于任何关联的时间表条目
• 产品创建日期早于任何关联的销售订单行

---

步骤 4：归档策略

并非所有数据都需要迁移。定义平衡合规性要求、业务需求和迁移复杂性的归档策略。

归档决策框架

存档格式建议

对于您在 ERP 外部存档的数据：

1. 导出为 CSV，具有清晰的列标题和 UTF-8 编码
2. 包含一个数据字典，定义每一列、其数据类型和有效值
3. 存储在版本控制的、不可变的位置（具有版本控制或加密备份的 S3）
4. 设定保留期限（大多数司法管辖区的财务数据保留期限为 7 年，某些行业的保留期限更长）
5. 在合规记录中记录存档，包括内容、日期范围和保留政策

---

步骤 5：主数据治理

数据清理不是一次性事件。如果没有治理，您闪亮的新 ERP 将在 12-18 个月内积累相同的数据质量问题。

数据所有权矩阵

数据输入标准

记录并执行每个实体的标准：

客户创建标准：

• 公司名称：官方法定名称（根据注册文件核实）
• 商号：如果与法定名称不同，则单独存储
• 地址：使用该国家/地区的邮政服务格式
• 主要联系人：姓名+电子邮件+电话必填
• 付款条件：创建时默认设置，需要批准才能更改
• 信用额度：由财务而非销售设定

产品创作标准：

• 产品名称：[品牌] [产品] [款式] [尺寸]（例如“ECOSIRE Widget Blue Large”）
• SKU：[类别]-[序列]-[变体]（例如“WDG-001-BL”）
• 描述：最少 50 个字符，描述中无 HTML 格式
• 类别：必须从现有类别中选择（无自由文本类别）
• 计量单位：必须使用批准列表中的标准计量单位
• 图片：最少一张图片，最大尺寸 2048x2048，白色背景

自动化数据质量规则

在新 ERP 中配置这些规则，从一开始就防止脏数据：

• 重复预防：如果已存在具有相同电子邮件、电话或税号的记录，则在保存时发出警告
• 必填字段强制：如果必填字段为空，则创建块
• 格式验证：拒绝无效的电子邮件格式、电话格式和日期格式
• 批准工作流程：新客户和供应商的创建需要经理批准
• 定期审查：自动报告突出显示 12 个月以上未更新的记录

---

步骤 6：数据质量评分

评分方法

在四个维度上对每个数据实体进行评分，每个维度评分为 1-5：

评分过程

1. 样本：随机5%的记录（最少100条，最多500条）
2. 检查完整性：将空白必填字段计算为百分比
3. 检查一致性：检查文本、日期、电话和电子邮件字段的格式合规性
4. 检查准确性：根据外部来源（网站、注册数据库、实际库存计数）验证抽样记录
5. 检查唯一性：对完整数据集运行重复检测，计算比率

迁移的最低质量阈值

对于任何得分低于最低阈值的实体，不要继续迁移。导入后清理数据的成本比导入前清理的成本高3-5倍。

---

数据清理时间线模板

---

工具和资源

开源数据清理工具

• OpenRefine：强大的数据清理工具，用于聚类、分面和转换杂乱数据
• dedupe.io：基于机器学习的 Python 重复数据删除库
• 远大的期望：用于自动质量检查的数据验证框架
• pandas (Python)：自定义清理脚本的灵活数据操作
• csvkit：用于 CSV 检查和验证的命令行工具

商业数据质量平台

• Informatica 数据质量：企业级清理和匹配
• Talend 数据质量：分析、清理和标准化
• Melissa 数据：地址验证、电子邮件验证、重复检测
• IBM InfoSphere QualityStage：主数据匹配和标准化

---

常见问题

数据清理需要多长时间？

对于中型企业（5,000–50,000 条客户记录、1,000–10,000 个产品），计划 6–10 周的专门工作。这假设每个部门都有一名全职数据分析师以及数据所有者的兼职参与。拥有数十万条记录或复杂的多系统环境的大型企业可能需要 12-16 周。

我们应该清理旧系统中还是暂存文件中的数据吗？

在临时文件（导出的 CSV 或临时数据库）中进行清理，而不是在实时系统中进行清理。这可以保留您的生产数据作为后备，允许多人并行清理，并避免中断日常运营。您的实时系统将继续运行而不受影响，直到干净的数据导入到新的 ERP 中。

如果我们达不到最低质量阈值怎么办？

如果特定实体无法达到最低分数，请调查根本原因。如果是数据量问题（记录太多而无法手动清理），请考虑仅导入最新或最活跃的子集，并将其余部分归档。如果这是一个结构性问题（数据的设计从来都不是为了支持新 ERP 的需求），您可能需要从外部源丰富数据，或者接受某些记录在迁移后需要人工关注的事实。

谁应该负责数据清理？

数据清理是业务责任，而不是 IT 责任。 IT 提供了工具和基础设施，但业务用户必须做出决定：保留哪些重复记录、孤儿订单是否应重新连接或存档，以及正确的产品名称格式应该是什么。分配每个部门的数据所有者，并让他们对其实体质量得分负责。

我们可以自动化数据清理吗？

部分地。自动化工具处理格式标准化（电话号码、地址、日期）、精确匹配重复数据删除和验证规则检查。但合并模糊匹配重复项、解决孤立记录以及验证数据准确性需要人为判断。计划 60% 自动化/40% 手动工作。

迁移后发现数据质量问题怎么办？

迁移后清理的成本比迁移前清理的成本高 3-5 倍，因为您现在处理的是实时系统，其中的更改会影响活动工作流程。如果您在上线后发现问题，请按业务影响确定优先级：首先修复影响财务准确性的记录，然后是面向客户的记录，最后是内部运营记录。

ECOSIRE 是否有助于数据清理？

是的。数据清理是 ECOSIRE 的迁移服务 的核心组件。作为每个迁移项目的一部分，我们提供数据分析、自动重复数据删除、质量评分和清理脚本。我们的团队与您的数据所有者合作，确保业务环境推动每个清理决策。 联系我们 讨论您的数据质量挑战。

---

从数据质量评估开始

任何迁移的第一步都是了解数据的当前状态。数据质量评估需要 3-5 天，并生成一份详细报告，显示每个主要实体的重复率、完整性分数、格式不一致和孤立记录计数。

ECOSIRE 提供免费数据质量评估，作为我们的迁移规划服务 的一部分。我们将分析您当前的数据，确定影响最大的清理任务，并提供现实的时间表和工作量估计，以实现迁移就绪的质量。

请求免费数据质量评估 并迈出实现干净、成功迁移的第一步。