ERP里出现两条名称相似的客户记录，最容易做的事是把其中一条删掉；最危险的事，也可能正是把其中一条删掉。真正有效的数据去重，不是追求“清掉多少行”，而是先判断两条记录是否代表同一个业务主体，再决定自动合并、人工复核、停用还是保留。本文给出一套从划定范围、设计规则、试跑验证到正式处置的决策方法，并用明确标注的模拟案例说明：怎样比较漏去重与误合并的代价，怎样设定可回退的处理边界。
我判断一项去重方案是否可靠，首先不看它能识别多少相似记录，而看它能否回答三个问题：这些记录是否属于同一业务主体？如果是，哪条作为主记录？处理之后，关联业务与历史记录还能否追溯？这三个问题没有答案，自动化做得越快，风险可能越大。
数据清理中常把“字段相同”“名称相似”和“业务主体相同”混为一谈。字段相同只是一个线索：两家供应商可能共用总机号码；同一客户也可能因为更名、迁址或简称而出现多种写法。记录相似度不是身份结论，身份结论必须结合稳定标识、业务关系和必要的人工确认。
因此，我建议把方案分成三个层级：稳定标识明确、关联简单且已通过试跑的记录，可以考虑自动处理；有相似线索但关键字段不一致的记录，进入人工复核；信息冲突、业务主体不明或涉及重要历史关系的记录，先保留并调查，不以“去重完成率”为理由强行合并。
客户、供应商、物料、员工等主数据，描述的是“谁”或“什么”；订单、发票、收付款、库存流水等交易数据，描述的是“发生了什么”。主数据可能需要识别同一主体的多条档案，交易数据则通常需要依据单据状态、业务规则和审计要求单独检查。
把两类数据放进同一条规则，是常见的设计错误。客户名称重复，不代表两张订单可以合并；物料描述相近，也不代表库存流水可以删除。对于交易数据，任何修改或清理都应先确认系统功能、业务审批和留痕要求。主数据去重规则不能直接复制成交易数据清理规则。
记录数量下降，只说明发生了处理，不说明处理正确。方案评估至少要同时观察候选记录的人工确认结果、误合并风险、人工耗时、关联关系完整性和回滚能力。若处理后记录更少，却找不到被合并记录的原始编号，或者销售与财务无法确认历史归属，这不是成功清理，而是把问题藏进了系统。
我更愿意把目标写成可核验的业务条件，例如：“在指定组织和客户档案范围内，对明确重复项完成经责任人确认的合并；对无法确定的候选项全部保留并标记；抽查关联业务无异常，且保留处理记录。”这类目标不追求一个漂亮的删除数字，却能告诉团队什么时候可以停止。
重复数据并不总是录入人员粗心。客户档案可能分别来自销售手工建档、线上线索导入、历史系统迁移和财务客户清单；供应商信息可能由采购部门、财务部门或区域组织分别维护。入口一多，字段口径、命名习惯和必填要求就会分散。
例如，销售录入“华东精密科技”，财务导入“华东精密科技有限公司”，旧系统迁移后又保留“华东精密科技（集团）”。只看名称，可能是同一法人名称的几种写法，也可能是集团公司与子公司。若缺少统一社会信用代码、内部主体编号或业务确认，仅凭文本相似就合并，可能把不同合同对象混成一条档案。
全角与半角字符、空格、标点、括号、简称和地址格式，都会影响精确匹配。电话可能含区号或分机，编码可能带前导零，名称中可能混有历史别名。做判重前，先做规范化检查，往往比直接放宽相似度阈值更稳妥。
但标准化不是把所有差异抹平。例如，删除名称中的“分公司”“门店”等组织后缀，可能会把总部与分支机构混在一起；把地址中的楼栋信息清除，可能会让同一园区内不同企业看起来一致。规范化规则要从业务含义出发，不能只为了提高匹配数量。
很多企业不是一个平面数据池。不同法人、区域、事业部可能有独立编码和维护权限；同一客户在不同组织下也可能有合法的业务档案。因此，“全系统是否重复”与“某组织内是否重复”是两个问题。
迁移项目尤其容易出现范围误判：旧系统字段与新系统字段映射不同，历史停用档案可能被重新导入，旧编码与新编码也可能同时保留。启动清理前，应明确系统、组织、数据状态、时间范围和责任人，而不是先导出全库再凭表格筛选。
作为项目管理上的做法，我会先画出数据进入路径：谁创建、从哪里导入、谁审核、哪些系统会同步、哪些部门消费这条数据。这个图能帮助团队区分“重复记录的症状”和“重复产生的入口”。若只删现存记录，却没有收紧新增入口，重复很可能重新出现。
名称是人类很容易理解的字段，却不总是可靠的唯一标识。企业可能有分公司、门店、事业部或关联法人；同一行业也可能存在近似名称。即使名称完全一致，还要确认组织范围、注册地址、税务标识、付款账户或合同关系等信息是否吻合。
反过来，名称不同也不必然代表不同主体。同一企业可能更名、使用品牌简称或历史旧名。判断时应把名称作为候选线索，而不是唯一裁决条件。能否用某个字段作为强标识，应由业务对象特点、数据完整度和维护制度共同决定。
多字段组合通常能增加判断信息，但字段缺失、过期或维护不一致时，组合规则也可能漏掉真正重复项。若规则要求名称、地址、电话和联系人全部一致，一条记录只要换了联系人就可能逃过识别；如果规则只要求其中两项相似，又可能把同园区的不同企业拉进候选池。
因此，规则不是字段数量竞赛，而是证据权重设计。稳定标识、辅助字段和弱线索应分别处理；发生冲突时，也应有明确优先级。规则设计最好输出“为什么命中”的原因码，而不是只给团队一个无法解释的相似度分数。
模糊匹配可以帮助发现拼写差异和格式变化，但相似度分数只能描述文本相似程度，不会自动理解组织关系、法人边界或业务历史。两个名称相似度很高的供应商，可能只是同一地区、同一行业；两条名称差异明显的客户档案，也可能因更名而属于同一主体。
如果使用相似度分数，建议把它用于分层筛选：高置信度候选仍先在小范围复核；中间区间进入人工队列；低分候选不自动认定为不同主体，而是结合数据质量判断是否需要抽样检查。具体阈值必须用本企业样本验证，不能把通用数字当成行业标准。
直接删除往往会丢掉创建人、来源、历史编码或关联线索。许多场景更适合保留一条主档案、将另一条标记为停用或已合并，并记录替代关系；也有场景适合只标注疑似重复，等业务部门确认后再处置。
合并、删除、停用、标记和保留各有用途，不能用一种动作覆盖所有风险。系统是否支持关联迁移、历史单据追溯、撤销合并和审计记录，也会改变最合适的选择。操作前务必在实际系统中确认功能边界，而不是依据其他 ERP 的菜单或经验假设。
数量下降只能说明规则触发了操作。更关键的是，命中项中有多少经核验确属同一主体，多少需要撤销或调整，处理后的引用关系是否完整。没有人工抽检和业务核对，团队可能把误合并当作高效率。
如果把候选项分成“确认重复、疑似重复、非重复”三类，并保留人工复核结果，就能逐步校准规则。每次调整规则后，最好与上一版结果对照，记录新增命中、取消命中和仍未判断的对象，避免只看总数量。
在配置规则之前，我会先让业务负责人把判定对象说清楚。客户档案可能按法人主体识别，也可能按门店、收货点或结算账户管理；物料可能按规格型号识别，也可能因包装、单位或供应来源不同而需要保留多条记录。
一份可执行的定义至少包含：对象边界、唯一性判断依据、允许存在多条档案的情况、需要升级审批的例外。比如“同一法人可以有多个收货地址”与“同一地址一定对应同一法人”并不等价。定义写清楚，才能避免技术团队独自替业务做身份判断。
强标识通常是业务认可、相对稳定并且有明确维护责任的字段；例如适用于特定对象的法定标识、内部主数据编号或经过核实的主体编码。具体用哪个字段，必须根据数据对象与制度确认，不能假设所有企业都有完整、可靠的统一标识。
辅助证据可以包括规范化后的名称、地址、联系人、电话、银行账户或历史别名。它们有助于判断，但可能发生变化或被多个主体共用。弱线索则包括描述文本相似、简称接近或录入人相同等信息，适合生成候选，不宜单独触发合并。
字段之间出现冲突时，规则也要有处理方式。强标识一致但地址不同，可能意味着迁址，也可能涉及组织变更；名称高度相似但法定标识不同，通常应暂停自动合并并交由业务确认。把冲突定义清楚，比不断增加匹配条件更重要。
精确匹配适合稳定字段完全一致的情况，解释性强、执行简单，但容易受录入缺失和格式差异影响。组合匹配可同时使用多个字段，提高候选筛选能力，却需要处理字段权重、缺失值和相互矛盾的情况。
相似匹配适合辅助发现名称拼写差异、简称或格式变化，但会带来更多误报。它的价值通常是扩大“人工值得看一眼”的候选范围，而不是替代身份认定。对于涉及重要业务关系的对象，自动化应止步于候选生成，最终决定留给有业务责任的人。
判重规则可以分成自动处理区、复核区和暂缓区。自动处理区要求身份依据强、字段冲突少、处理后果可控并且有回退手段；复核区包含有一定匹配证据但仍有歧义的候选；暂缓区则包括关键字段冲突、信息不完整、涉及重要交易关系或系统处理能力不明确的记录。
划分边界时，我会同时问四个问题：误合并会影响什么？漏掉重复会造成什么后果？人工复核一条需要多少时间？一旦处理错了能否恢复？当误合并成本高而复核成本可承受时，扩大人工复核通常更合理；当身份明确、数量很大且回退可靠时，才有理由进一步提高自动处理比例。
建议至少区分候选命中率、确认重复比例、误报比例、漏报抽查发现率、人工复核耗时和处理后关联异常数。每个指标要写清分母、统计范围和记录时间，否则团队之间比较的可能不是同一件事。
例如，“确认重复比例”可以按人工判定为确实重复的候选数除以已复核候选数计算；“人工复核耗时”可以记录从领取候选到完成结论的实际工时。漏报则不能只从已命中列表中计算，需要另外抽查未命中记录或利用已知重复样本测试。
这些指标不是越高越好。放宽规则可能提升候选命中数量，却增加误报与审核工作；收紧规则可能让自动处理更安全，却漏掉更多格式差异。方案目标应结合业务代价设定，而不是只优化某个单项数字。
正式开始前，先写明本次处理的对象、组织、数据状态、时间范围和负责人。例如，只处理某组织下仍在使用的客户主数据，不包含已封存历史档案与交易单据。边界越清楚，越容易复核结果，也越容易在发现问题时停止。
同时记录处理前的基线：档案总数、字段缺失情况、可能的重复候选数、停用记录数量，以及关键关联对象的抽样情况。基线不是为了制造一个成果数字，而是帮助团队解释变化来自哪里，并在处理后做前后核对。
备份应包含能够识别原始记录的主键、关键字段、状态、创建来源和必要的关联信息。若系统提供操作日志或数据导出机制，应确认备份能否用于恢复，而不是只确认“文件已经下载”。对于关键对象，最好先在测试环境验证恢复流程。
规则本身也需要留档：匹配字段、字段规范化方式、例外条件、规则版本、审批人和生效时间。这样一旦某一批处理结果有争议，团队可以还原当时的判断依据，而不必凭记忆猜测。
试跑样本不要只挑最容易识别的记录。应覆盖强标识完整、强标识缺失、名称相近但主体不同、名称不同但可能同主体、跨组织和历史迁移等不同情形。若样本只包含“明显重复”，规则的真实边界就没有经过验证。
对每个候选，保存系统命中的理由与人工结论。例如命中是因为内部编码一致、名称规范化后相同，还是多个辅助字段共同吻合。这样可以识别规则究竟依赖了什么证据，也便于处理人员指出某条规则是否把组织后缀、地址或联系人误当成决定性条件。
确认重复：有足够证据证明是同一主体，并已确认主记录选择和关联处理方式。
疑似重复：存在多个相似线索，但强标识缺失、冲突或业务关系尚未确认。先进入审核队列，设置责任人和后续状态。
确认不同：虽然名称或其他字段相近，但业务主体、组织关系或关键标识不同。应保留判断理由，避免下一轮清理时再次被同一规则命中。
这三类结果还应保留来源和复核记录。若系统无法直接保存这些信息，可以通过经过权限控制的工作表或任务记录承接，但要确保最终结论能回写或关联到系统记录，避免工作表与 ERP 状态长期不一致。
同一主体有多条记录时，选哪条保留为主记录，需要考虑字段完整性、使用状态、历史业务关联、创建来源和业务部门认可度。最新记录不一定最好，字段最多的记录也不一定适合做主记录；如果一条旧档案承担大量历史关联，简单保留新记录可能增加迁移复杂度。
主记录确定后，逐项确认旧记录关联如何处理：相关业务单据是否需要重新指向主记录？旧编码是否保留为别名？停用记录是否仍允许查询？下游报表或接口是否会继续读取旧编号？不同 ERP 产品对合并和引用迁移的支持差异较大，不能预设系统会自动完成这些工作。
即使小范围试跑通过，也应按可控批次执行。每批都有处理清单、审批记录、执行人、开始与结束时间，以及遇到异常时的停止条件。对于关键数据对象，可以先处理数量有限的一批，完成业务核验后再扩大范围。
核对不能只看记录数。至少检查主记录字段、被处理记录状态、主要业务引用、历史单据查询、接口同步和报表结果。任何一项出现异常，都应暂停后续批次，查清影响范围后再继续。
回滚方案应说明谁有权限执行、如何定位受影响记录、怎样恢复字段和关联、恢复后怎样验证。备份文件如果没有经过恢复演练，不能证明实际可回滚。对于系统不支持撤销合并的情况，团队要在动作前评估是否改用停用、标记或人工处理。
建议给每批处理设置停止阈值，例如出现未预期的关联断开、跨组织记录被合并或关键标识冲突时立即暂停。阈值不必是一个通用百分比，关键是事先明确哪些异常不可接受、由谁决定继续或回退。
以下是为说明判断过程而设计的模拟案例，不代表真实企业或实际处理成果。某企业在客户主数据中发现两条记录：A记录名称为“澄海精工有限公司”，登记地址为甲市工业园，联系人为王女士；B记录名称为“澄海精工”，登记地址同为甲市工业园，联系人为赵先生。两条记录都出现过销售往来，创建时间相差一年。
如果只按名称相似度，系统很可能把两条记录放进候选列表；但现有信息还不足以证明它们是同一主体。简称可能对应同一法人，也可能是集团内另一家企业；联系人不同既可能是岗位变化，也可能说明业务对象不同。接下来要看强标识、合同抬头、付款或开票信息、历史别名和组织范围，而不是直接点合并。
检查稳定标识：若两条记录对应的法定标识一致，进入强候选；若缺失或冲突，不能自动下结论。
核验业务凭据：查看已审核合同、发票抬头或经授权确认的主体资料，判断是否指向同一法人。不要把未经核实的备注当作最终凭据。
确认组织范围：检查两条记录是否分别属于不同业务组织，是否存在合法的分支或结算档案。
查看历史关联：确认订单、回款、服务记录分别关联哪条档案，并核实是否需要迁移或保留原引用。
请业务责任人给出结论：记录确认人、证据、处理动作和日期。若证据不足，标记待核实并保留两条记录。
若稳定标识一致、合同主体一致且业务部门确认属于同一法人，才可以进入合并方案评估。合并前还要确定哪条记录作为主记录、历史编码如何留存、相关单据是否迁移，以及系统是否支持恢复。
若法定标识不同，或者合同和结算关系显示为两个主体，即使名称接近，也应判为不同主体。此时应补充规范名称、主体标识或组织说明，降低下一轮规则重复命中的概率，而不是为了减少档案数合并。
若稳定标识缺失、历史资料不足或各部门说法不一致，应进入待核实状态。可以限制新增相似档案、暂时指定业务责任人，但不应把“没有证据”解释成“已经证明重复”。在重要数据上，保留不确定性通常比制造一个错误确定性更安全。
为了比较方案，假设本次试跑产生100条候选，其中60条经复核确认重复，25条确认是不同主体，15条仍待核实。再假设自动化规则只对其中证据最强的候选提出处理建议，但所有自动建议仍由人工抽查。这里的数量只用于演示统计口径，实际比例会因数据质量、对象类型和规则设计而变化。
如果团队把100条候选全部当成重复，可能把确认不同的25条和待核实的15条一并处理；如果只处理60条确认项，则仍需规划另外40条的去向。后者看起来不够“彻底”，却能把确定结论与未决问题分开，让负责人知道哪些风险尚未消除。
这个案例说明，名称相似适合触发检查，不适合单独触发合并；也说明“待核实”应当是一个有责任人、有期限、有后续动作的状态，而不是清理团队的废纸篓。把不确定项显式留下，能减少为了赶进度而作出未经证实判断的压力。
案例不能证明某种字段组合适用于所有客户档案，也不能用模拟比例推算实际准确率。不同组织的数据来源和维护制度不同，规则必须在自己的样本上验证。对供应商、物料或员工档案，判定字段和误合并后果也会改变。
如果候选量不大，但每条记录都关联合同、结算、项目或历史服务，人工核验的成本通常可以接受，误合并却可能带来较大影响。此时可用规则生成候选清单，按业务部门分派，由责任人确认身份和处理方式。
人工并不等于没有标准。应给复核人员提供统一的字段视图、证据来源、判断选项和升级渠道。否则，不同审核人可能对同一候选给出相反结论，后续也无法追溯为什么合并。
当强标识覆盖率较高、数据来源较稳定、例外规则清楚且系统可以留存关系时，可以让系统自动识别高置信度候选，再由人工处理冲突与边界项。先自动生成候选，比直接自动改变主数据更容易控制风险。
如果试跑结果稳定，且恢复与审计流程验证通过，才逐步考虑自动执行部分低风险动作。每次扩大范围，都应保留抽查样本、规则版本和停止条件。数据量大并不自动等于适合全自动；数据质量和回退能力才是边界。
当名称、地址、编码和来源信息大量缺失时，匹配规则无法凭空创造可信证据。先梳理字段定义、缺失比例、维护责任和可补充来源，可能比调高相似度阈值更有效。对无法补齐的信息，可把候选列为待核实，避免规则把不完整数据误判为唯一主体。
补数也要遵守权限和来源要求。不能为了提高匹配效果，随意抓取、拼接或使用未经授权的个人信息。应优先使用企业批准的数据来源，并明确谁负责核验与更新。
交易类记录与主数据存在关联，但关联存在不代表可以随意改写。任何清理动作都应确认业务审批、审计追踪、系统限制和适用制度；如果目标是纠正主数据映射，也要判断历史单据是否应保留原样、是否能通过受控流程调整。
在不确定系统行为时，先咨询系统管理员或实施服务方，使用测试环境验证影响。不要在生产环境通过批量脚本直接删除或改写关键记录。能否处理、如何处理，应由业务制度和系统能力共同决定。
项目时间紧时，最容易被删掉的是抽样复核和回滚演练；这往往是最不该删的环节。可以先限定一个组织、一类对象或一个时间范围，以较小批次完成完整闭环，而不是对全库采用未经验证的宽松规则。
如果某些记录风险高、信息不足，就把它们留在待处理清单中，明确负责人和后续期限。清理范围小但结论可靠，通常比范围大却无法解释结果更有价值。
| 场景 | 优先方案 | 需要检查 | 不建议的做法 |
|---|---|---|---|
| 强标识完整，关联简单 | 规则筛选、抽样复核后分批处理 | 规则命中原因、关联迁移、恢复能力 | 未经试跑直接全量自动合并 |
| 名称相似但标识缺失 | 人工核实并补充证据 | 合同主体、组织范围、数据来源 | 只按名称相似度决定身份 |
| 字段冲突或业务关系复杂 | 暂缓处理，指定业务负责人 | 冲突来源、历史引用、审批要求 | 为了减少记录数强行合并 |
| 交易或财务历史记录 | 专项影响评估与受控审批 | 审计留痕、系统限制、制度要求 | 直接套用主数据删除规则 |
| 数据量大且维护规范稳定 | 先候选自动化，再逐步扩大自动动作 | 分层准确性、异常率、停止阈值 | 把初筛命中量当作处理准确率 |
自动合并速度快，适用于证据充分、规则稳定并且系统支持可靠关联迁移的情形；短板是误判可能影响多个业务环节，且撤销成本可能较高。
人工复核能处理复杂上下文，适合歧义候选和高风险对象；代价是人力投入较多，审核标准需要统一，还要避免队列积压。
停用或标记有利于保留历史和减少误删，适合无法立即确认、但需要防止继续使用的记录；短板是旧记录仍然存在，需要明确查询、引用和后续处置规则。
暂不处理不是放弃治理，而是承认当前证据不足。若同时设置责任人、补充证据路径和复查时间，它比错误合并更可控；若没有跟进机制，待核实状态则会变成长期堆积。
要降低重复产生，先明确每类数据由谁创建、谁审核、哪些字段必须填写、编码由谁分配。字段说明不能只写“名称”“地址”，还要解释允许的格式、别名如何保存、组织分支如何建档以及哪些情况必须走例外审批。
创建权限也需要与业务责任匹配。若多个部门都能自由新建客户，却没有统一的候选检查或审核机制，清理结束后仍可能持续产生重复档案。可以根据业务量和风险设置分级权限，避免所有创建请求都堆在一个人手中，也避免无人负责。
新增前的重复提示可以展示相似名称、关键标识和组织范围，让使用者先检查已有档案。提示应说明相似原因，并允许用户解释“确属不同主体”的情况；否则，过于严格的拦截可能促使员工选择错误记录或绕开流程。
系统提示不等同于业务裁决。对于低风险对象，可以要求提交前确认；对于高风险对象，可以增加审批；对合理例外则保留理由和审核记录。好的录入控制会帮助用户做判断，而不是把模糊规则伪装成绝对答案。
建议保存处理前记录标识、候选来源、规则版本、命中理由、人工结论、审批人、执行动作和处理时间。若系统支持合并关系或别名管理，应确认这些信息可以被后续查询；若借助外部表格，则要设置访问权限、更新责任与归档方式。
每次调整判重规则，都应写明改变了什么、为何改变、会影响哪些对象，以及验证结果如何。没有版本管理，规则调整后出现问题时，很难判断变化来自数据、阈值还是人工操作。
如果清理后同一类重复持续出现，不要只延长清理周期。应检查重复是否集中在某个入口、某个组织、某一类字段或某一批迁移数据。集中出现往往提示录入规范、接口映射、权限设计或字段校验存在问题。
复查频率不必设成对所有企业都通用的固定周期。业务增长快、入口多、主数据变更频繁的场景，可能需要更频繁的监测；数据量小且新增流程稳定的场景，可以根据实际风险安排。关键是设定触发条件，例如异常候选突然增加、关键字段缺失上升或某入口重复明显聚集。
是否定义了数据对象、组织范围、状态范围和排除项？
是否由业务负责人确认了“同一主体”的判断标准与例外情形？
是否区分强标识、辅助证据和弱线索，并说明字段冲突时怎么处理？
是否在具有代表性的样本上试跑，包含容易误判的边界记录？
是否把候选分为确认重复、疑似重复和确认不同，而非一律处理？
是否确定主记录选择规则，并检查历史关联、编码和下游引用？
是否确认备份可以恢复、处理结果可以追溯，且有人负责审批？
是否预先约定异常停止条件、回滚责任人和处理后的核对步骤？
如果尚未确定相似度阈值或自动化范围，不必从通用数字中寻找答案。选取一个数据对象和一个业务范围，建立一批人工确认样本，记录规则命中、确认重复、误报、漏报抽查和审核耗时。样本应包含常见格式差异，也要包含容易被误合并的相似主体。
试点完成后，比较不同规则版本的收益与代价：更宽松的规则多找到了多少确认重复？增加了多少人工复核？有没有命中关键标识冲突的记录？这些问题比“相似度调到多少”更能决定适用边界。规则阈值是基于本企业样本的操作参数，不是可以脱离数据背景复制的标准答案。
出现以下情形时，建议立即暂停自动动作并转人工：强标识冲突；候选跨越不同组织或法人边界；主记录关联无法确认；系统不支持可靠回退；处理后发现历史单据、报表或接口异常；实际抽查结果明显偏离试跑预期。
停止并不意味着项目失败，而是控制风险的一部分。真正成熟的流程不仅定义何时执行，也定义何时不执行。团队能在证据不足时保留数据、记录原因并升级核验，说明治理机制正在发挥作用。
建议先选一种边界相对清楚的主数据对象，确定一个组织范围和一组判重字段；由业务负责人确认定义，数据管理员准备样本，系统管理员验证关联与恢复能力。先跑候选清单，再由责任人抽查确认，最后才讨论是否扩大自动处理范围。
记录每一次命中为什么成立、为什么被排除，以及哪些候选仍然无法判断。经过一轮试点后，团队就能得到属于自己的审核耗时、规则误报和例外类型，而不是依赖未经验证的行业比例。数据治理的起点不是一次性清空重复项，而是让每个处理结论都能解释、复核和撤回。
我对 ERP 数据去重的核心判断是：先用规则发现候选，再用证据确认身份；先控制误合并，再追求处理速度；先验证回退，再扩大自动化。记录数量少了，不一定代表数据更可信；留下一部分待核实记录，也不意味着方案不完整。
对用户而言，最实用的第一步不是打开系统寻找“合并”按钮，而是选一小批真实候选，列出每条记录的证据、冲突和关联，再决定哪些能自动处理、哪些必须人工确认。只有当规则在本企业数据上经得起抽查，操作可以追溯，错误可以停止或恢复，去重才真正从一次清理变成可持续的数据治理。
我整理客户资料时发现，公司名称相同不一定是同一主体，名称不同也可能指向同一家企业。我该优先看名称、税号、电话还是地址，怎样组合字段才不容易误判？
先按数据对象选字段，不要把“名称相同”直接等同于“主体相同”。对客户或供应商，可先确认系统中哪些字段经过业务验证、相对稳定，再考虑用统一社会信用代码、税号等强标识做精确匹配；名称、电话、地址更适合作为辅助线索。建议把规则分层：强标识一致且关键业务信息不冲突，列为高置信候选；
名称相似但强标识不同，进入人工复核；关键信息缺失或互相矛盾，暂缓自动处理。物料则要结合企业编码、规格、型号、单位等字段判断，不能直接套用客户规则。还要区分“数据标准化”和“判定重复”：去除多余空格、统一全半角、规范电话格式，可以减少表面差异，但不能证明两条记录属于同一主体。
标准化后的结果仍应按业务规则核验。
我担心直接删除会让订单或历史往来记录找不到对应对象，但保留重复记录又会让同事继续选错。我该怎么判断处理方式，尤其是已有业务关联的数据？
不要把删除设为默认选项。先确认重复记录是否已经关联订单、发票、收付款、库存或其他历史业务，再检查系统是否支持合并、关联迁移、停用和操作追溯。不同系统能力与企业制度不同，不能只凭一条通用步骤决定。可以按风险选择：主体相同、关系简单且验证过关联迁移的记录，评估合并或保留一条主记录；
暂时无法确认是否同一主体的，标记待核实并限制新增使用；确属重复但需要保留历史追溯的，可评估停用旧记录，而不是物理删除。正式处理前，明确主记录由谁确认、关联如何迁移、谁审批以及如何回退。若涉及财务或库存历史数据，应先按企业的业务与审计要求评估，必要时交由相关负责人确认。
我不想一上来就对全库执行自动去重，怕规则看起来合理，实际却把不同客户合在一起。试跑时应该检查哪些数据，怎样判断这条规则适不适合扩大范围？
先备份原始数据，固定试跑范围，并把候选结果分为“确认重复、疑似重复、非重复”。不要只看系统命中了多少条，还要抽查未命中的记录；否则只能观察误报，无法发现规则漏掉的重复项。
例如，以下数字仅用于说明计算方法：某次抽取1000条客户记录，规则产生63组候选，经业务人员复核，其中49组确认重复、14组并非重复。候选确认率为49÷63，约77.8%；它不是整体准确率，也不能说明漏报情况，还需要用人工标注的样本检查规则没有命中的重复记录。
扩大范围前，先看误合并的影响、误报带来的审核成本、漏报的业务影响和回退是否可行。若一次误合并就可能影响交易或财务追溯，即使候选确认率较高，也更适合先采用“系统筛选、人工确认”，而不是无人复核的自动合并。
我担心清完一次后，员工还是按旧习惯新增客户或物料，过几个月又出现相似记录。除了定期查重，我还应该在录入流程里设置哪些规则，才更能防止问题复发？
把治理放回新增环节：明确字段口径、编码规则、必填项和数据维护责任人；创建记录前提供相似项提示，让录入人先确认是否已有可用记录。提示应作为检查线索，不应仅凭名称相似就自动阻止所有新增。为疑似重复设置清晰的处置路径：谁负责核实、需要补充哪些信息、多久内处理，以及确认非重复后如何允许新增。
对税号、物料编码等适用的稳定字段，可在系统能力允许且业务确认后设置校验；对名称、地址等易变化字段，应保留必要的人工判断空间。清理后记录处理规则、确认人、例外情况和回退方式，并结合业务量与风险安排复查。比起追求固定的清理周期，更重要的是观察重复记录从哪里产生，再针对流程薄弱点调整录入校验和责任分工。
读者评论
把“名称相似”当作候选线索而不是合并依据，这一点很重要，尤其是集团与子公司并存的情况。
文章区分了主数据和交易记录，能避免把客户档案去重规则误用到订单、发票等历史单据上。
建议先明确组织范围和数据来源再筛查，跨区域或跨法人档案未必是重复记录。
处理动作不只有删除，保留主档、停用旧档并记录关联关系，确实更利于后续追溯。
试跑后不能只看记录减少了多少，还要抽查误合并、关联完整性和回滚能力，这些指标更能说明规则是否可靠。