ERP 数据录入前，最容易被低估的不是“能不能找出相同名称”，而是“系统判定为同一条后，谁有权把两条记录合并”。客户名称多一个空格，通常只是格式差异；客户名称相同但税号不同，则可能是不同法律主体。把这两类记录都交给同一条自动去重规则，工具越快，错误扩散也越快。我的判断是：去重工具选型必须从业务规则和误合并风险开始，而不是从功能清单或产品排名开始。
ERP 数据去重不是单一的字符串查找任务。实际落地时，至少要分清完全重复、格式差异和疑似重复。完全重复通常是多个关键字段一致、记录来源也能解释的重复；格式差异是空格、大小写、全半角、标点或地址简称不同，但业务主体可能相同；疑似重复则是部分字段相似，需要业务人员判断。
这三类记录的处理权限不应相同。完全重复可以在备份、规则明确、结果可回滚的条件下批量处理；格式差异适合先标准化，再重新匹配；疑似重复应进入人工复核，不能因为相似度分数高就直接合并。工具负责提供证据和执行流程，业务规则负责定义“同一个”的含义。
比较工具时，别只看它是否支持模糊匹配、批量处理或自动合并。更关键的是：规则能否按客户、供应商、物料等对象分别配置；疑似记录是否能进入待审核队列；合并前后是否保留映射关系；错误合并能否撤销；操作记录能否追溯到人、时间和规则版本。
我通常把选型问题压缩成三个判断：规则是否表达得出来，风险是否控制得住，结果是否能够解释和恢复。如果其中任何一项没有答案，增加自动化程度并不会让项目更成熟，只会缩短错误从导入到影响业务的时间。
明确本次处理的数据对象、来源、范围和业务负责人。
为每类对象定义唯一标识、辅助字段和不可自动合并的条件。
准备脱敏样本，覆盖完全重复、格式差异、近似但不同和字段缺失等情况。
让候选工具用同一批样本演示匹配、复核、审批、日志和回滚。
先以只读或试运行方式执行规则，复核结果后再决定是否批量处理。
正式导入后，为新增记录建立持续校验，不让历史清洗成为一次性项目。
这套顺序看起来比直接比功能多几步，但它把选型从“销售演示哪个更顺眼”变成“哪个方案更能通过同一组业务测试”。对 ERP 项目而言，后者更有决策价值。
在 ERP 上线、系统迁移或组织整合时，重复记录常常不是某个人“录错了一次”造成的，而是多个历史流程叠加的结果。同一客户可能来自销售表格、旧业务系统、财务系统和经销商名单；每个来源都可能有不同编码、字段习惯和更新周期。
例如，销售表里写“华东精密设备有限公司”，财务表里写“华东精密设备有限 公司”，旧系统里则只保留“华东精密”。如果没有税号、客户编码或地址等字段作辅助，工具只能识别文字相似，不能代替业务判断。相反，如果把相似名称直接当成同一主体，也可能把集团下不同法人、分支机构或独立结算单位错误合并。
客户、供应商、联系人和物料不能照搬同一套规则。客户名称可能对应法律主体，也可能对应门店、项目客户或内部账户；供应商名称需要结合税务信息、结算账户和组织关系；物料名称相近，却可能因规格、材质、单位或版本不同而完全不能合并。
因此，数据字典里写“名称唯一”通常不够。更实用的做法是明确：名称是主判定字段还是辅助字段；税号、编码、规格、单位等字段分别承担什么作用；字段为空时匹配规则如何降级；哪些业务关系必须保留为独立记录。
历史数据清洗解决的是存量问题，新数据校验解决的是持续产生的问题。两者使用的控制方式不必一样：存量清理可以经过批次分析、人工复核和审批；日常录入则适合在保存时提示潜在重复，由录入人确认是否继续创建。
如果只在上线前做一次批量去重，之后没有新增校验，同样的数据问题很可能再次出现。反过来，如果只依赖录入时提示，历史数据中已经存在的多套编码和重复主体又不会自动消失。完整方案必须同时覆盖“存量治理”和“增量预防”。
并非所有重复记录都需要在上线前以同样力度处理。对会影响开票、付款、库存、采购和权限分配的数据，应优先核验；对只影响搜索体验、短期内不参与关键业务的记录，可以进入分批治理计划。清理范围越大，不代表上线准备越充分，关键是高风险数据是否有明确处理结论。
优先级可以按“业务影响、错误合并代价、出现频率、确认难度”综合判断。举例来说，两个物料名称相似但计量单位不同，可能直接影响采购和库存；两个联系人电话相同但所属客户不同，则可能只是共享总机。工具选型也要服从这个优先级：先保证高风险对象可审、可控，再考虑低风险场景的自动化覆盖率。
这是最常见、也最容易被自动化放大的误区。名称相同可能是简称重复、门店名称相同、集团成员企业共用品牌，也可能是历史数据录入时被错误复用。名称差异也不必然代表主体不同，可能只是标点、空格、繁简体或组织形式写法不同。
所以名称适合作为检索入口，却不一定适合作为唯一判定条件。对于高风险对象，应当组合至少一个强识别字段与若干辅助字段，并把强字段冲突定义成阻断条件。例如名称相似但税号冲突，应进入复核，而不是用模糊分数覆盖冲突信息。
许多工具会给记录对打相似分或标注高、中、低风险。这个分数通常表达的是算法对字段相似程度的计算结果，不等于“这两条记录有某个百分比的概率属于同一主体”，更不等于合并之后不会产生业务问题。
如果规则只按名称计算，名称越像分数越高；但它可能没有考虑税号冲突、组织层级、有效状态或业务用途。试用时要问清分数的组成、字段权重、缺失值处理方式和阈值配置方法，再用本企业的边界样本检验。分数是排序和筛查工具，不是责任转移工具。
演示里展示几十组“成功发现的重复记录”，容易让人产生工具已经可靠的印象。但只检查命中项，会看不到格式变体、关键字段缺失和冷门业务场景中的漏检。反过来，只关注召回，也可能把大量不同主体标成疑似重复，增加人工复核负担。
试跑样本应同时包含已知重复、已知非重复和暂时无法确认的记录。让业务人员提前标注“应该匹配、不能匹配、需要更多信息”，然后比较工具输出。样本不是为了证明工具好，而是为了找出它在哪些条件下会失败。
自动合并条数多，不一定代表效率高。如果合并动作无法恢复，或没有保留旧编码与新主记录之间的映射关系，批量自动化可能把后续对账、追溯和业务修复成本推高。对有财务、库存或采购影响的数据，人工确认不是低效的同义词，而是控制风险的必要步骤。
更合理的效率指标包括：每百组候选记录的复核耗时、人工确认后实际合并比例、错误合并数、漏检抽样数、回滚处理耗时，以及从发现问题到完成处置的周期。指标必须和业务后果一起看，不能只统计“处理了多少行”。
数据去重的真实成本还包括规则梳理、字段标准化、接口配置、历史映射、业务复核、操作培训和后续维护。某个方案看起来采购费用低，但需要团队长期维护脚本、手工导入结果或反复修复字段映射，整体成本可能并不低。
比较报价时，应把一次性费用和持续费用分开，确认按用户、数据量、环境、接口还是模块计费；还要问清测试环境、实施支持、版本升级、日志留存和数据导出是否包含在内。报价表中没写明的能力，不应默认供应商会免费提供。
选型前，为每类主数据准备一张规则卡。规则卡不用追求复杂，但必须让业务、数据和实施团队理解一致。建议包括：对象定义、主键或候选唯一标识、可用于匹配的字段、字段优先级、缺失字段处理、不可合并条件、人工确认条件、合并后的保留字段及责任人。
以客户数据为例，规则卡可以写明：税号相同且状态有效时进入强候选；名称近似但税号不同则阻断自动合并；没有税号时，客户编码、地址和电话只能生成待复核候选；同一集团不同法人默认不合并。注意，这只是规则设计示意，企业需要按自身法律主体、结算和销售组织架构确认。
强规则用于识别证据明确的记录对，例如内部唯一编码完全一致，且没有关键字段冲突。弱规则用于发现疑似记录，例如名称标准化后相似、地址相近或联系方式部分一致。阻断规则则用于明确不应自动合并的情况，例如税号不同、物料规格冲突、单位不一致或组织主体不同。
在工具演示中，不要只展示“匹配成功”的路径，也要专门演示阻断路径。真正成熟的工具方案，应该能解释为什么两条记录进入候选、为什么被阻断、由谁确认，以及确认结果是否会沉淀为后续规则。
试跑样本应从真实数据中抽取并脱敏，同时补入业务人员已知的典型边界。建议分为四组：明确相同、明确不同、格式不同但可能相同、信息不足无法判断。每组都要注明业务预期结果，避免试跑后只凭主观印象评价工具。
如果数据量较大，可以按来源系统、业务部门、数据年代、记录状态和字段完整度分层抽样。样本中只抽“干净数据”，会高估规则效果；只挑最脏的数据，又可能不能代表日常处理负担。目标不是把样本做得漂亮，而是覆盖真实的数据复杂度。
识别能力回答“工具能否找到值得检查的记录对”；处置能力回答“发现候选后，流程是否让正确的人以可追溯的方式完成确认”。两者要分开测试。某工具匹配能力不错，但没有分派、审批、批注和回滚能力，可能适合生成候选清单，却不适合直接承担端到端治理。
对已人工标注的样本，可以计算候选命中情况。若预先标注的同主体记录被找出，可以计入匹配召回；若系统给出候选但业务判断不是同主体，可以计入误报。测试集规模较小时，不必包装成精确的产品准确率，应公开样本数量、标注规则和限制，避免把一次试跑结论推广到全部数据。
自动化门槛不应由供应商统一给定，也不适合所有数据对象使用同一个阈值。错把两个物料合并，可能导致库存、采购和计划信息混淆；漏掉一组联系人重复，可能主要增加查询负担。错误的代价不同，自动处理边界也应不同。
我会先列出误合并和漏检分别造成的后果，再确定哪些情形可以自动执行、哪些只能推荐、哪些必须拦截。对于影响付款、开票、存货或权限的数据，建议把业务审批和回滚验证作为上线门槛，而不是在项目后期再补。
工具输出最好能够展示命中字段、规则名称、规则版本、处理时间和操作人。若只给出一个“疑似重复”标签，业务人员就难以判断系统依据，也不容易复盘规则是否需要调整。
还要确认结果是否能够以可用格式导出，是否能保留原记录编码、新主记录编码和被合并记录的映射关系。即使工具部署在 ERP 内，也需要确认数据备份、审计、环境迁移和供应商服务结束后的数据可用性。选型不只是在买匹配算法，也是在决定数据治理过程由谁掌握。
表格适合字段少、数据批次有限、业务人员熟悉数据内容的场景。团队可以用筛选、标准化列、重复值检查和人工标注快速形成候选清单。优点是启动成本低、过程容易理解；局限是规则容易散落在个人文件中，版本控制、权限管理、协同审核和回滚通常需要额外设计。
如果用表格试跑，应保留只读原始文件，另建处理副本；将清洗规则、公式、操作人和日期记录在表头或配套说明中；避免多人同时修改同一个版本。数据量和协作复杂度上升后，表格可以继续作为抽样复核载体，但未必适合作为唯一的生产治理平台。
自建脚本或数据库规则适合有稳定数据工程能力、规则需要高度定制、并且能持续维护的团队。它通常能把标准化、匹配、结果导出和重复执行串成明确流程，但也把测试、监控、权限、日志和升级责任留给企业自己。
评估此类方案时，要看规则是否有版本管理、任务是否可重复执行、异常是否有告警、结果是否保留处理前快照，以及维护人员更换后能否理解逻辑。不要只展示一段脚本在样本上跑通；还要测试字段新增、编码变化、空值增加和任务中断时会发生什么。
这类工具可能覆盖数据抽取、标准化、匹配、审批、主记录维护和系统同步等环节，适合多个来源持续汇入、需要重复运行并由不同角色协作的项目。但产品类别名称不能代表实际能力，具体支持的对象、匹配方式、工作流、部署环境和接口都需要核实。
采购前应让供应商按企业字段和样本演示，不要只看通用样例。还要确认规则是否可由业务人员配置，复杂逻辑是否必须依赖供应商；任务失败是否可以续跑；对 ERP 当前版本、数据库和部署环境是否有明确适配说明。
ERP 自带校验或实施方提供的清洗方案，优势可能是与现有数据结构和流程衔接较直接，也可能减少额外系统接入。但“系统支持去重”并不能说明它覆盖了历史数据分析、模糊匹配、人工审批、映射保留和批量回滚等全部环节。
应确认功能是否包含在当前许可和版本中，是否需要额外模块或定制；规则由客户、实施方还是供应商维护；升级后配置是否保留；导入失败如何恢复；历史映射是否可导出。演示环境与生产环境的权限、数据量和接口条件也可能不同，不能以演示成功替代上线验证。
以下表格用于确定核验重点，不代表某一类别必然优于另一类别。实际选择取决于数据规模、规则复杂度、团队能力、治理周期和风险承受度。
| 方案类型 | 更适合的场景 | 主要优势 | 主要边界 | 试用或采购时重点核验 |
|---|---|---|---|---|
| 表格处理 | 小批次、少字段、人工复核为主 | 启动快、业务人员容易检查 | 协作、留痕、版本和回滚需要额外管理 | 原始数据保护、规则文档、复核记录、文件权限 |
| 脚本或数据库方案 | 有技术维护团队、规则需要定制 | 可按业务逻辑编排并重复执行 | 测试、监控、文档和长期维护由企业承担较多 | 规则版本、异常处理、幂等执行、日志和人员交接 |
| 数据质量或主数据工具 | 多来源、持续治理、多人协同 | 可能覆盖规则、审核和持续同步流程 | 能力、成本和实施复杂度因产品与配置差异明显 | 实际字段演示、工作流、部署、接口、授权及维护费用 |
| ERP 自带或实施方案 | 希望在现有 ERP 流程内处理 | 可能更贴近现有数据模型和权限体系 | 功能范围受版本、模块和实施方式影响 | 版本适配、许可范围、回滚、映射留存和责任归属 |
让候选方案使用同一份脱敏样本、同一套规则说明和同一组测试问题。要求每家方案都演示：完全重复如何识别；格式差异如何标准化；关键字段冲突如何阻断；缺字段记录如何进入复核；合并后如何追溯；出现误合并时如何恢复。
同一场演示应记录步骤、结果和未满足项。若一个方案用“自动匹配率”作展示，另一个方案只展示“候选生成数量”，两组数字不能直接比较。先统一统计口径，再比较成本、工作量和风险控制能力。
首先确认本次处理包含哪些对象、哪些来源、哪个时间范围，以及哪些记录不进入清洗。每类数据都要指定业务责任人，IT 或实施团队可以搭建规则和工具，但不能独立决定客户、供应商或物料在业务上是否属于同一对象。
保留原始快照，并记录文件或批次标识、导出时间、来源系统、字段定义和记录数量。原始数据应设置只读权限，处理结果放在独立工作区。若没有备份、权限或恢复方案，不建议直接在生产主数据表上做批量更新。
统计关键字段的空值、格式差异、编码重复、字段长度异常和非法字符。检查客户、供应商、物料编码是否存在多个生成规则，旧系统编码是否会在新系统中继续使用，历史记录的失效状态是否明确。
字段标准化要先于相似匹配，但标准化本身也需要留痕。例如统一空格和标点后，应保留原始字段与标准化字段的对应关系；地址简称、单位换算和名称别名通常带有业务语义，不能只靠通用字符串清理。
样本至少覆盖明确重复、明确不同、格式差异、关键字段冲突、关键字段缺失和历史状态异常等情况。标注结果由熟悉业务的人确认，并记录判定依据。若一组记录存在争议，不要强行标成“重复”或“不重复”，可以单独设为待业务确认。
对于规模较大的数据，可按来源、部门、年份和完整度分层抽样。每个样本组都保留原始记录标识，确保工具输出能回到来源记录进行检查。试跑的目标是检验规则，不是挑选最容易成功的案例做展示。
对字段做可逆或可追溯的标准化，保存原始值和标准化值。
先按强标识和完全匹配规则生成明确候选，检查是否存在关键字段冲突。
再按名称、地址、联系方式等辅助字段生成疑似候选，并说明命中依据。
按风险级别将结果分为可自动处理、业务复核、阻断待查三类。
记录审核意见、责任人、时间、规则版本及后续处置结果。
批量处理前应先比较“原始记录，候选关系，业务确认，目标主记录”四类信息。不能只导出合并后的最终表，否则后续发现问题时，很难判断记录从哪里来、为什么被合并、哪些下游系统可能受影响。
两条记录确认属于同一主体后，还要决定保留哪条作为主记录。判断可以依据有效状态、主数据维护责任、业务使用情况、编码规则和数据完整度，但规则要提前明确，不能由操作人员临时挑选。
字段冲突也不能简单采用“非空优先”或“最新值优先”。客户名称、地址、付款条件、物料规格等字段的权威来源可能不同。应按字段指定数据来源优先级，无法自动决策的字段由责任人确认，并记录最终取值与依据。
导入后检查新增、更新、合并和跳过记录的数量是否与预期一致；抽样核对关键字段；确认历史单据、库存交易、采购记录、发票信息和联系人关系仍指向正确主体。若目标系统维护旧编码映射，还应验证旧编码能否查询到新主记录。
对于高风险对象，不要只做总量核对。可以按记录状态、组织、数据来源和关键字段冲突分层抽查。若发现异常，暂停后续批次，先判断问题来自源数据、规则、接口映射还是人工审核，再决定回滚或修复，避免把局部错误继续复制到其他系统。
正式上线后，应在新建或导入入口配置重复提示、必填校验、编码唯一性和人工确认流程。提示信息要给出可理解的依据，例如显示相似记录的编码、主体信息和命中字段，而不是只弹出“可能重复”。
定期查看新增候选、人工放行记录、重复创建和规则例外，发现同一类误报或漏报时，再调整规则。每次调整都要记录生效日期、影响对象和验证样本，避免新旧规则混用后无法解释结果。
下面是一个情景模拟案例，不是某家企业的实测结果，也不代表任何工具的性能。假设一家企业准备迁移 12,000 条客户记录和 8,000 条物料记录，来源包括旧 ERP、财务导出表和销售部门维护文件。团队发现同一名称存在空格、简称和组织形式差异，同时有部分客户缺少税号。
项目组没有先批量合并，而是把数据拆成客户与物料两组。客户组重点查看税号、内部编码、名称、地址和有效状态；物料组重点查看编码、规格、单位、版本和状态。业务负责人分别确认主体边界与物料识别规则，避免用客户名称规则处理物料记录。
客户组将内部编码一致且关键字段无冲突的记录列为强候选；名称相似但税号不同的记录进入阻断队列；缺少税号且名称、地址都相似的记录进入人工复核。物料组把规格或计量单位冲突设为阻断条件，名称近似但编码、规格完整的记录只生成待审核关系。
每一组候选都保留命中字段和规则版本。试跑人员同时抽查未命中记录，专门寻找简称、地址变更、历史编码和字段缺失导致的漏检。这样得到的结果不只是“工具找到了多少”，还包括“规则在哪些场景不应该自动处理”。
假设对上述数据运行后，系统输出 520 组候选关系；业务人员复核其中 310 组，确认 220 组属于同一主体，70 组明确不同，另有 20 组因资料不足暂缓决定。该组数字只是用于说明统计口径的情景模拟，不是实际测试数据，也不能据此推断某类工具的平均表现。
此时，团队不应把 520 组都称为“重复数据”，更不能直接把 220 组的确认结论推广到未审核候选。对于暂缓的 20 组，下一步应补充税务资料、业务合同或物料技术信息；对于 70 组明确不同的记录，应把冲突类型写入规则复盘，降低同类误报再次占用复核资源。
这个案例的关键不在于候选数量，而在于每组结果都能解释：为什么命中、由谁确认、最终如何处置、未决记录需要什么补充证据。若工具只输出相似分，没有业务复核和映射记录，团队仍然需要自己建立一套外部台账。
对项目负责人来说，最终验收应看四类结果：高风险数据是否有明确结论；错误合并是否能发现并恢复；暂缓记录是否有责任人和后续动作；上线后新增记录是否会触发相应校验。只有这几项都闭环，才算完成数据录入准备，而不是仅完成了一次文件处理。
如果数据规模有限、字段较少、业务人员能够逐条复核，可以先使用现有表格和明确的检查规则完成试跑。把原始文件设为只读，单独保存标准化字段、候选关系、审核结果和最终映射。此时不一定需要采购独立平台，但应把手工流程写下来，并确保后续能复现。
取舍在于低启动成本与较弱的协同、追溯能力。若只有一次小批次且误合并影响有限，人工控制可能更合算；若同一任务要跨部门、多轮更新，或者一旦误合并会影响付款、库存等关键流程，就应升级治理和审批能力。
如果 ERP 长期接收多个来源的数据，且客户、供应商或物料持续新增，单次表格清洗很难解决根因。应优先设计统一编码、数据责任人、接口校验和新增记录复核流程，再比较能否承担持续任务的工具方案。
取舍在于前期投入与持续维护成本。流程化平台可能增加采购和实施成本，但如果能减少重复导入、重复建档与人工协调，就有机会降低长期负担。最终仍要用企业自己的数据量、人工处理时间和错误修复成本核算，不能依据“自动化程度高”直接认定投入一定划算。
对影响开票、付款、库存、采购价格或监管记录的数据，应将人工确认、审批留痕、主记录选择规则和回滚验证列为硬性条件。可以用自动匹配缩小候选范围，但不建议仅凭相似度自动合并关键主体。
取舍在于处理速度与错误代价。复核会增加短期工时，却可能避免后续跨部门查账、修复编码关系和重新导入。这里不应简单比较“自动处理了多少行”，而要明确一次错误合并可能影响哪些下游单据，以及恢复需要哪些责任人和证据。
如果企业有成熟的数据工程团队、明确的代码审查和运行监控能力，自建规则可能更贴合业务，也更容易与现有数据流程结合。建议将规则代码、字段字典、样本测试、日志和异常处理纳入同一套维护机制，并指定备用维护人。
取舍是定制能力与内部责任。脚本方案不等于没有成本，开发完成后仍要维护依赖、处理字段变化、验证结果并追踪失败批次。若团队人员流动大或文档薄弱，短期灵活可能转化为长期不可维护。
如果客户、供应商或物料的归属定义尚未统一，不要急于购买“自动合并”能力。先组织业务、财务和 IT 确认数据所有权、唯一性定义、例外情形和最终审核人；可先用低风险样本验证规则，保留争议记录，不以清空候选池作为目标。
取舍是先治理流程，还是先上工具。规则尚未稳定时，工具只能更快地执行不断变化的判断。暂缓自动合并并非项目停滞，而是在避免把组织层面的分歧固化进系统。
预算紧张时，可以先从高风险对象和高频来源做小范围治理，采用现有系统、表格或脚本组合，但要优先保留原始快照、处理记录、规则版本和旧新编码映射。与其一次性覆盖所有字段，不如先把关键链路做得可审计。
取舍是覆盖率与控制深度。分阶段处理会留下待治理数据，但每一批都能明确状态和责任人；一次性追求全量完成，如果缺少复核与恢复机制，表面覆盖更广，实际风险也可能更高。
比较表里的每个能力都要有对应证据：实际演示、合同条款、产品说明、接口测试或样本结果。供应商口头说明可以作为问题线索，但不应替代正式确认。对于“支持回滚”这样的说法，还要问清回滚粒度、保留期限、权限要求以及是否能恢复关联记录。
| 比较事项 | 需要问的问题 | 建议验证方式 | 不可忽略的风险 |
|---|---|---|---|
| 数据对象与字段 | 客户、供应商、物料等是否能分别设置规则？字段映射是否可维护？ | 用企业脱敏字段现场配置并运行 | 通用字段模板可能不能表达企业特有的主体边界 |
| 匹配方式 | 是否支持完全匹配、标准化后匹配、规则组合和疑似候选？ | 提供强匹配、弱匹配及字段冲突样本 | 仅展示模糊分数，无法说明命中逻辑 |
| 阻断与例外 | 能否配置关键字段冲突时禁止自动合并？ | 测试税号、规格、单位或组织冲突 | 高相似分可能覆盖业务上必须保留的差异 |
| 人工复核 | 能否分派、批注、审批、退回和记录理由？ | 模拟业务人员与管理员协同处理 | 候选只能导出后线下确认，容易丢失过程记录 |
| 主记录与字段冲突 | 如何选择保留记录？不同字段能否采用不同来源优先级？ | 准备存在字段冲突的同主体样例 | “最新值”或“非空优先”可能覆盖权威数据 |
| 日志和映射 | 是否保存处理人、规则版本、旧新编码关系和处理时间？ | 完成一次试跑后检查日志和导出结果 | 无法追溯历史交易所引用的旧编码 |
| 回滚与恢复 | 误合并能否恢复？恢复是否涉及关联单据？ | 在测试环境执行错误合并和恢复演练 | 只恢复主记录、不恢复关联关系或引用记录 |
| 安全与部署 | 数据存储、权限、传输、备份和删除机制是什么？ | 核对技术文档、合同和安全评审要求 | 敏感数据处理方式与企业合规要求不一致 |
| 成本与维护 | 许可、实施、接口、培训、升级和持续服务分别如何计费？ | 要求提供覆盖全周期的费用清单 | 初始报价未包括接口、环境或后续规则维护 |
评分适合比较可优化的差异，例如规则配置便利程度、复核工作量和接口适配程度；否决条件则用于判断方案是否满足基本控制要求。例如无法保留原始数据、关键操作没有日志、误合并不能恢复、数据部署方式不符合企业要求，都可以列为不能进入下一轮的条件。
先过否决条件，再进行加权评分，比把所有能力加总成一个总分更安全。否则某个方案可能因为界面好用或匹配速度快而取得较高总分，却在回滚或数据安全上存在无法接受的缺口。
如果企业的主数据影响付款、开票和库存，日志、审批与回滚权重应更高；如果数据持续从多个系统同步，接口稳定性和规则维护能力更重要；如果团队以业务人员为主，规则可解释性和复核体验就不能忽略。
评分表应保留“证据链接或测试记录”“未满足项”“风险责任人”三列。没有证据的高分只是印象分，未满足项也不能因为总分漂亮就自动消失。选型结论应说明哪些能力已验证、哪些仍需补充合同约定或上线测试。
数据对象、来源、范围和业务责任人已经明确。
原始数据已备份并设置只读，处理批次可识别。
强规则、弱规则、阻断规则和例外条件均有书面说明。
样本覆盖明确重复、明确不同、格式差异和字段缺失等情况。
命中项与未命中项都经过抽样检查，并保留判断依据。
主记录选择、字段冲突处理和旧新编码映射已有明确规则。
操作日志、审批权限、回滚步骤和异常处置责任人已验证。
批量导入的增量记录、失败记录和重试方式已在测试环境演练。
新增数据校验流程已经确定，不会在历史清洗后重新积累重复。
验收前先定义指标口径。可以关注候选记录量、人工复核比例、确认重复比例、误报类型、漏检抽样数、处理耗时、回滚演练结果和未决记录数量。每个指标都要写明分母、样本来源和统计时间范围。
如果样本不足或人工标注存在争议，应明确说明限制，不要把一次试跑的结果称为全量准确率。更重要的是，当确认出现误合并时，团队是否能定位来源、停止后续处理、恢复映射并通知相关业务；这是系统和流程是否可控的直接验证。
试跑时若发现关键字段冲突仍被自动合并、处理日志缺失、回滚无法完成、主记录来源无法解释，建议停止批量处理并先修正规则或流程。对于格式标准不一致、候选复核量偏大等问题，可以评估调整字段权重和阈值后再试跑。
不同级别的问题应有不同负责人和关闭标准。风险问题由业务和项目负责人确认，接口问题由技术团队验证，合同和数据安全问题由相应管理部门审核。没有关闭证据的问题，不应以“上线后再观察”替代明确处理。
每批处理结束后，归纳误报、漏报、字段缺失、来源差异和人工争议。复盘不只是调整算法参数，也可能暴露编码规范不统一、部门责任不清、历史状态未维护等治理问题。
复盘结果要进入数据字典、导入模板、日常录入提示和培训材料。若同一类问题反复出现，说明需要改流程或数据责任，而不只是继续加一条匹配规则。这样才能让去重从清理旧数据，变成持续改善数据质量的机制。
ERP 数据去重的成熟度，不应按自动合并比例排序。一个谨慎地把高风险记录交给人工确认、但能清楚说明理由并完整保留映射的方案，可能比“自动处理很多记录、事后难以追溯”的方案更可靠。
我更看重三件事：每条候选能否解释，关键决策能否找到责任人，错误发生后能否恢复。工具比较的重点不是谁的功能列表更长，而是谁能在企业真实规则下，减少人工盲查，同时不扩大错误后果。
先选一个高风险、数据范围可控的对象，例如客户或物料，不要一开始就覆盖所有主数据。
由业务负责人写出对象边界、关键字段、冲突条件和不可自动合并的例外。
从真实数据中准备脱敏样本，标注明确相同、明确不同和待确认记录。
让候选方案使用同一批样本演示匹配、复核、日志、映射和回滚。
根据误合并代价确定自动化边界，先试跑和抽查，再分批正式处理。
上线后建立新增校验、定期复盘和问题责任机制，防止重复数据重新累积。
真正可落地的去重方案，不是把所有相似记录合并，而是让每一次合并都有证据、每一次保留都有理由、每一次调整都能追溯。在比较工具之前，先把这三项要求写进规则和验收清单，才能让 ERP 数据录入从“导入成功”走向“业务可信”。
读者评论
把完全重复、格式差异和疑似重复分开处理很关键，尤其税号冲突时不应只凭名称相似度自动合并。
客户、供应商和物料的识别字段确实不能通用。物料的规格和计量单位如果不同，名称再接近也可能是不同库存对象。
试跑时同时检查漏检、误报和复核耗时，比只看工具找出了多少候选更有参考价值；样本也应覆盖字段缺失的情况。
文中强调回滚和操作留痕很实用。历史清洗之外，还要设置新增数据校验，否则后续录入仍可能再次产生重复。