ERP 里出现两条名称相近的客户档案，最省事的办法似乎是删掉一条；但如果两条记录分别关联历史订单、发票或收款，删错的代价可能远高于多留一条重复记录。ERP 数据录入要落地，关键不是把表格“清干净”，而是先定义什么算同一条业务对象，再明确谁来判断、怎么处置、如何防止新重复继续产生。
很多企业谈数据标准化，首先想到的是统一名称格式、补齐必填字段、规定编码长度。这些工作都重要，但如果员工面对两条相似记录时仍不知道该选哪条、该不该新建、出错后找谁处理，标准就还没有进入业务流程。
我判断 ERP 数据录入是否真正落地，通常先看一个具体问题：业务人员能不能在新增之前识别潜在重复，并且知道遇到疑似重复时该如何处理。如果答案是否定的，那么再完整的字段规范，也可能只存在于制度文件里。
去重会同时暴露四类管理问题：数据对象的定义是否一致，唯一识别依据是否明确，新增和修改权限是否合理，业务责任人是否愿意承担审核。它不是数据治理的全部，却很适合用来检验治理规则是否可执行。
要求所有 ERP 数据绝对没有重复，听起来明确，实际往往不够可操作。不同系统、不同业务对象和不同历史时期的数据质量差异很大，某些对象可能没有稳定的唯一识别字段，某些重复也只能通过人工核实发现。
更可执行的目标，是把重复管理拆成三件事：尽量在录入时发现，发现之后由明确责任人判定，处理之后留有能够复查的记录。这样做不是放弃数据质量，而是把质量要求变成可以分配、检查和改进的工作。
实际项目不宜一开始就追求复杂的自动识别。先把客户、供应商、物料等高频对象的判定规则说清，再决定哪些规则适合自动化、哪些情况必须人工确认，通常更稳妥。
没有基线，就很难判断治理有没有进展。建议先抽取一段时间内的新增和变更记录，分别统计重复候选数、人工确认的重复数、资料完整率、审核退回率和异常处理时长。统计时要说清楚口径，例如“重复候选数”是系统匹配出来的条数，还是经过业务人员确认的重复对象数。
企业之间的业务规模、数据来源和系统配置并不相同，不宜拿未经核验的行业平均值直接作为目标。可以先测量自身现状，再按业务影响设定阶段目标。例如，先要求高风险对象全部有责任人，再逐步提高录入校验覆盖率。
| 管理目标 | 建议观察的指标 | 统计时需要说明的口径 |
|---|---|---|
| 减少重复新增 | 新增记录中的确认重复率 | 按新增时间、对象类型和确认规则统计 |
| 提高资料可用性 | 关键字段完整率 | 只统计该业务对象真正要求的关键字段 |
| 缩短异常处理 | 疑似重复平均关闭时长 | 从进入待办到完成判定，不混入等待时间定义不清的数据 |
| 明确治理责任 | 有明确责任人的主数据对象占比 | 以责任人有效且已确认职责为准，不只看字段是否填写 |
销售可能按客户常用简称建档，财务按开票名称维护，采购或客服则可能从邮件、合同和历史表格复制名称。每个部门都觉得自己录入的是“正确名称”，但系统里出现多个看似不同、实际可能指向同一对象的记录。
这种情况未必是员工不认真。更常见的原因是企业没有明确规定：哪些字段用于识别对象，显示名称是否允许简称，历史名称如何保存，新增之前由谁检索。要求员工“注意不要重复”，却不给判断方法，最后通常只能靠经验和运气。
从旧系统、电子表格或多个业务平台迁移数据时，字段名称相同不代表业务含义相同。旧表中的“客户名称”可能是开票主体，也可能是门店名称；“物料编码”可能是供应商编码，也可能是内部库存编码。
如果迁移前只做格式整理，没有确认字段含义和对象边界，重复数据可能以不同编码进入新系统。后续员工在 ERP 中检索不到熟悉的记录，便再次新增，形成“历史重复”和“新增重复”叠加的局面。
迁移的关键检查不是只看字段是否对齐，而是确认一条旧记录在新系统里究竟代表什么对象。遇到一对多、多对一关系时，需要先确定转换规则，不能默认一条旧记录必然对应一条新记录。
客户可能更名、合并、搬迁或停止合作；供应商可能更换结算主体；物料可能升级、替代或停止采购。如果系统没有约定如何更新、停用或保留历史名称，员工可能通过“再建一条”解决眼前问题。
所以，重复治理不能只讨论新增。还要规定哪些变化属于同一对象的资料更新，哪些变化意味着业务对象发生改变，哪些记录应停用但保留历史关系。没有生命周期规则，旧数据会持续制造新的录入歧义。
当报价、下单或入库流程被时效要求推动，而新建档案又不需要审核，业务人员通常会优先让流程继续。即使知道可能有旧记录，也可能因为搜索不方便、权限不足或无法判断而选择新增。
这时，重复并不只是数据问题，还反映出系统控制和业务效率之间存在冲突。如果新增一条记录比查找、确认旧记录更快，员工就会沿着最省时间的路径行动。治理方案必须同时考虑输入控制和业务响应速度，不能把所有责任都压给录入者。
下图为情景模拟，用于帮助梳理重复产生的来源，不是对某一企业或行业的抽样调查。企业可以用自己的新增记录和异常记录替换示意数据。
名称是检索线索，不一定是唯一身份依据。不同法人主体可能使用相似名称，同一业务对象也可能在合同、发票、系统录入中存在简称、历史名称或拼写差异。
如果只按名称自动合并，可能把不同主体的交易记录混到一起；如果完全依赖精确名称匹配，又会漏掉简称、空格、标点或录入错误造成的重复。正确做法是按对象类型组合识别字段，并把自动判断和人工确认分开。
编码往往是系统内部标识，不一定能够证明业务对象不同。历史数据迁移、不同部门独立编码或重复建档，都可能导致同一对象拥有多个编码。编码唯一，只能说明系统记录不同，不能自动证明业务实体不同。
对物料等对象，编码可以是强识别线索，但仍要明确编码是内部编码、供应商编码还是规格版本编码。若同一物料因包装、尺寸或工艺差异需要区分，仅凭名称相似也不能轻率合并。
匹配规则适合筛出“值得复核”的候选，不适合替代所有业务判断。相似度高可能源于常见名称、相同地址或统一格式；相似度低也可能是简称、错别字或历史名称造成的。
建议至少把结果分为三类：确认不是重复、确认重复、暂时无法判定。第三类不能被忽略，应有待补资料的责任人和处理期限。把不确定性记录下来，比强行归类更安全。
ERP 记录常常关联业务单据、库存、往来余额、价格和审批历史。直接删除可能破坏查询链路，也可能让后续人员无法解释历史业务。具体影响取决于系统的数据关系、删除机制和企业的审计要求，不能在不了解系统行为时先做批量删除。
很多情况下，处置方式更可能是确定主记录、将其他记录停用、通过系统支持的方式建立关联或迁移引用，并保留操作痕迹。哪些方式可用，需要在测试环境验证，不能把“合并”理解成所有 ERP 都具有同一种自动合并功能。
客户、供应商、物料、员工和仓库的识别方式不同。客户可能需要区分法人主体与收货地点；物料可能需要区分规格、单位和替代关系；供应商可能需要区分企业主体、结算账户和供货地点。
用一张通用规则表规定所有对象“名称必填、编码唯一”，看起来统一，实际上会把不同业务问题压平。标准化不是字段越多越好，而是每类对象都有足够的识别信息和明确的维护责任。
上线前清洗处理的是存量问题；上线后仍会发生新增、修改、更名、停用和跨部门协作。没有录入前检查、关键字段审核和异常复核机制，数据会随着业务继续变化。
把治理安排成一次性项目，常见结果是上线验收时数据看起来整齐，数月后又出现新重复。更稳妥的做法，是将规则嵌入日常流程，并根据异常记录定期调整规则。
| 误区 | 容易造成的后果 | 替代做法 |
|---|---|---|
| 按名称直接自动合并 | 不同对象被错误合并，历史关系难以复核 | 多字段筛查，疑似记录交业务责任人判断 |
| 重复记录直接删除 | 关联业务和历史追溯可能受影响 | 先评估关联，再按系统支持方式处置并留痕 |
| 只清理历史数据 | 日常新增继续制造重复 | 建立新增检查、变更审核和周期复核 |
| 只要求员工“认真录入” | 责任模糊，执行情况难以检查 | 明确字段规则、权限、审核人和异常处理路径 |
设计判重规则之前，我会先把数据对象的业务边界写出来。以客户为例，一条记录究竟代表企业法人、门店、收货地点，还是一个具体的业务关系？如果不同部门对“客户”指向不同对象，任何唯一键规则都可能产生冲突。
对象边界可以用一句话描述，并补充常见反例。例如：“客户主档代表签约或结算主体，门店和收货地址作为其下级信息维护。”这只是示意，实际定义要由业务、财务和系统负责人共同确认。
识别字段应从业务定义出发，而不是从系统里“刚好有的字段”出发。企业可以先列出强识别字段、辅助识别字段和展示字段，再确定它们分别用于自动校验、疑似提示还是人工复核。
| 对象类型 | 可能使用的识别信息 | 需要避免的简单化判断 | 建议复核角色 |
|---|---|---|---|
| 客户 | 企业登记信息、合同主体、结算主体、内部客户关系 | 只按简称或联系人判断同一对象 | 销售负责人、财务或主数据责任人 |
| 供应商 | 企业主体信息、结算信息、供货关系、采购范围 | 把相同品牌或相似名称当成同一供应主体 | 采购负责人、财务或供应商管理人员 |
| 物料 | 规格、型号、单位、用途、内部编码及版本关系 | 只按名称相似或供应商描述合并 | 工程、仓储、采购或物料主数据负责人 |
| 员工 | 内部员工号、组织关系、任职状态 | 只按姓名判断，忽略同名和离职再入职等情况 | 人事或组织管理责任人 |
表中的字段是识别思路，不是所有企业都适用的标准模板。尤其涉及个人信息、财务资料或受监管业务时，应按企业的数据管理制度和适用要求确定字段范围与访问权限。
对于稳定、可靠且业务上确实唯一的字段，可以考虑设置强校验；对于格式差异明显、误判风险较高的字段，更适合做疑似提示；对于涉及主体关系、规格替代或历史变更的问题，应由业务人员判断。
自动化程度越高，不一定越好。误拦截会让业务绕开流程，误合并则可能造成更难修复的问题。规则上线前应拿历史样本回测，查看“命中多少、误报多少、漏掉多少”，再决定适用范围。
两条候选记录被判定为同一对象之后，仍要回答保留哪一条、哪些字段采用哪边的数据、冲突由谁决定。不能简单规定“信息较多的记录优先”，因为字段完整不等于业务有效，旧记录也可能包含已经失效的联系人或地址。
建议按字段指定来源和维护责任。例如，结算信息由财务确认，物料规格由工程或产品责任人确认，客户业务归属由销售管理角色确认。某些字段可以设定权威来源，其他字段则需要个案裁决。
每次合并、停用、修正和解除疑似关系，都应至少能追溯处理时间、处理人、判定依据、受影响记录和相关业务确认。留痕不是为了增加文书工作，而是为了让后续人员知道为什么这么处理，并能在争议出现时复核。
如果 ERP 本身不支持所需的关联或审计功能，可以先通过受控流程保存处理单和审批记录，再评估系统配置或配套管理方式。不要未经验证地承诺某个系统一定支持自动合并、自动回溯或完整审计。
下面的判断表适合在规则评审会上使用。它不替代企业的数据字典，而是帮助团队区分“可以自动处理”和“必须人工决定”的边界。
为了展示规则如何应用，下面构造一个小型示意案例：某企业整理客户主档时，发现名称相近、地址相同和联系人重复等候选情况。案例中的数量、比例和名称均为情景模拟，不对应真实企业，也不代表行业平均水平。
模拟数据包括三条客户记录：一条使用企业全称，一条使用常用简称，另一条名称相近但登记主体不同。三条记录都可能被名称匹配规则标记，但只有前两条在补充核对后被确认属于同一客户主体。
| 记录 | 名称表现 | 识别信息 | 初步判断 | 下一步动作 |
|---|---|---|---|---|
| A | 客户甲科技有限公司 | 合同主体信息完整，存在有效业务单据 | 可能作为主记录 | 核对当前有效状态和字段来源 |
| B | 客户甲科技 | 简称与 A 相似，部分联系方式相同 | 疑似重复 | 核实主体关系及关联单据，不直接删除 |
| C | 客户甲科技集团子公司 | 名称相似，但主体识别信息不同 | 可能是不同对象 | 确认其业务关系，保留独立记录或建立关系说明 |
在示意流程中，系统或数据处理人员先用名称相似、联系方式重合等条件筛出候选。筛查的目的，是缩小需要检查的范围，而不是让规则代替最终判定。记录 B 与 A 命中相似条件后，业务责任人需要核对合同主体、历史单据、当前往来和资料来源。
如果核对结果证明 A 和 B 是同一对象，就要决定保留哪条主记录、哪些字段更新到主记录、历史单据如何继续关联，以及原记录是否可以停用。如果证据不足，就标记为待补资料，而不是强行合并。
在真正操作之前，建议导出候选记录的关键字段及其关联业务，至少检查当前有效单据、历史交易、未结事项和相关审批记录。要检查哪些关系，取决于企业使用的模块和业务流程，不能假设所有 ERP 的关联方式都一致。
对存在历史业务的记录，优先在测试环境验证拟采用的处理方式。操作前保存原始数据快照或受控备份，记录验证人、验证步骤和结果。若无法确认合并后对历史查询的影响，应先咨询系统管理员或实施人员，而不是在正式环境直接试错。
假设核查后确认 A 与 B 属于同一客户，企业决定 A 作为当前主记录，B 停止新增使用，并在处理记录中说明依据、关联业务核对结果和批准人。C 则因识别信息不同而保留为独立记录，同时补充与 A 的业务关系说明。
这个过程没有追求“把名称相似的都合并”。它做的是把结论、依据和后续使用方式固定下来，减少下一位录入人员再次遇到同样问题时重新猜测。
如果企业计划上线重复提示，可以先抽取已确认重复和已确认非重复的历史记录做回测。检查规则能否找到已知重复，也检查它是否把不同主体误判为重复。样本要覆盖常见简称、历史名称、同名对象、地址变更和规格差异等情况。
回测不必追求复杂算法，关键是把错误分类型记录。漏掉重复，可能说明规则过窄或数据字段不足；误报太多，可能说明规则过宽或名称相似被过度使用。两种问题的解决方式不同，不能只靠调整一个相似度阈值。
先列出需要管理的对象类型、当前数据来源、录入部门、维护部门和业务使用环节。不要试图一次盘点所有字段，可以先从影响交易、库存、结算和关键统计的对象开始。
盘点时应同时记录数据是从哪里来的，例如旧系统导入、批量模板、接口同步或人工新增。不同来源的错误机制不同：模板可能重复导入，接口可能缺少唯一校验，人工新增则可能受搜索习惯和权限影响。
数据字典不是把所有字段堆成一份表，而是解释字段的含义、格式、必填条件、责任角色和变更规则。一个字段如果没有明确的业务含义，即使设置为必填，也可能只是让员工随便填一个值。
建议先为关键对象建立精简版字段字典，再通过实际录入和异常处理不断补充。字段标准应区分“系统必填”和“业务必需”，并说明缺少信息时如何暂存、审批或升级处理。
| 字段规则项 | 需要回答的问题 | 落地示例 |
|---|---|---|
| 业务含义 | 这个字段代表什么，不代表什么？ | 区分签约主体与收货地点，避免名称相同但层级不同 |
| 格式规则 | 允许哪些字符、单位、日期或编码格式？ | 统一日期格式和计量单位，明确格式转换责任 |
| 必填条件 | 什么业务场景下必须填写？ | 某类交易必须填写结算信息，其他场景可按规则暂缓补齐 |
| 维护责任 | 谁可以新增、谁确认、谁有权修改？ | 新增由业务发起，关键识别字段由授权角色审核 |
| 生命周期 | 更名、停用、替代或合并时怎么处理？ | 停用旧记录但保留历史引用，并说明新旧关系 |
存量清理建议分批进行，不必先把所有历史记录都追求到同一质量水平。可以按当前业务使用频率、交易风险、金额影响或后续流程依赖度划分优先级。排序依据应由企业确认，并形成透明的处理标准。
每个候选对象可以设置处理状态：待筛查、待业务复核、已确认重复、已确认不同、已处置、暂缓处理。状态字段的价值在于明确下一步动作，而不是为了增加一张报表。
清理过程中应保留原始导出、筛查规则版本、人工判定记录和处置结果。规则发生变化时，也要记录变化时间和适用范围，否则不同批次的结果无法公平比较。
员工新增记录之前，应该能以合理成本查看已有记录。搜索入口是否方便、结果是否能显示关键识别信息、权限是否允许查看，都会影响员工是否愿意先查再建。
若 ERP 支持重复提示，可先从高频对象和高可信字段开始配置；若系统不支持相应能力，可先通过新增申请表、受控批量模板或人工审核流程管理。具体实现要结合系统功能核实，避免把流程建议误写成系统已有特性。
提醒信息应足够具体。只显示“可能重复”而不提供可比较的关键字段，员工仍然无法判断；如果提示过多，员工会习惯性忽略。因此应根据实际误报情况调整提示条件，并设置“确认不是重复”的合理说明机制。
发现疑似重复之后，需要一个明确的待办机制：谁负责补充资料，谁有权裁决，处理期限如何设定，超期时如何升级，最后如何关闭。只给业务人员发一封通知，如果没有责任人和状态跟踪，异常往往会沉淀在邮箱或聊天记录里。
关闭异常时，至少记录最终结论、判断依据和处置方式。若同类异常重复出现，还应回到规则、培训、权限或系统入口检查原因，而不是反复要求员工更谨慎。
清理了多少条数据，并不必然代表质量改善。更有用的复盘要同时看结果、过程和风险：新增重复是否减少，疑似候选有多少被复核，误报是否造成业务阻塞，异常关闭是否及时，重要对象是否仍缺少识别信息。
不同指标之间可能存在取舍。例如，提高拦截强度可能减少重复新增，但也可能增加审核等待；降低误报可能减少业务干扰，却可能放过部分重复。企业应结合业务影响决定目标，而不是只追求某个数字最大或最小。
上线前优先确定主数据范围、字段映射、唯一识别规则和业务责任人。尤其要检查旧系统与新系统之间的对象关系：一条旧记录是否拆成多个新对象，多个旧编码是否应映射到同一新对象。
迁移测试至少覆盖正常样本和异常样本。除了格式错误，还要挑选简称、同名、主体变更、规格差异、停用记录和历史关联复杂的样本，验证导入结果与后续业务查询是否符合预期。
如果上线时间紧，不宜承诺在切换前处理所有历史瑕疵。可以按业务影响划定必须清理的范围，把低风险、低频使用的历史记录纳入后续分批治理，并明确其使用限制。
先不要急着批量去重。抽取近期新增数据和一部分高频主数据，找出重复主要集中在哪些对象、部门、录入渠道和字段差异。确认问题来源后，再决定是改规范、改权限、改搜索体验还是补审核。
可以先选一个对象类型做小范围试点。例如，先治理新增量较高、业务责任人清楚、识别信息较完整的一类客户或物料。试点的目的不是证明所有对象都能用同一规则，而是验证流程、责任和数据口径。
重点是减少多头创建，并使跨部门查重成为低成本动作。应明确主数据的归口责任、授权新增范围和例外审批方式，避免一个部门录入的记录对另一个部门不可见。
如果不同部门确实需要维护不同业务信息，可考虑区分主体主档与业务扩展信息，避免把一个对象拆成多条互不关联的主档。具体数据模型要结合 ERP 能力和业务关系设计，不能只为减少记录数而牺牲业务表达。
对缺少稳定识别字段的数据，先补充证据、建立人工核验清单，不宜用激进的自动合并规则。可以按业务风险分级：正在交易或结算的记录优先补齐，长期未使用的记录先限制新增引用，再安排核验。
如果短期内无法确认某条记录属于哪个对象，可以保留待核状态并限制关键业务使用。比起为了报表好看而强行归并，保留不确定性并控制风险更诚实也更安全。
先从管理动作开始：统一新增申请入口、制定简版字段字典、明确审核责任、建立周期性异常表。很多基础问题并不需要先采购复杂工具，但必须有人持续维护规则、处理例外并跟踪结果。
如果重复主要来自批量导入，可以先设置导入前模板检查和重复候选复核；如果主要来自员工手工新增，则优先改善检索入口和新增审核。工具选择应由问题来源决定，不应反过来为了使用某项功能重造流程。
可以区分低风险和高风险对象：字段齐全且识别明确的记录走简化路径，关键字段冲突或高影响对象进入人工复核。审核时限、紧急例外和事后复查要一起设计，避免“所有记录都等人工”拖慢业务。
需要警惕把“快速放行”变成永久绕行。紧急新增应记录原因、责任人和补充资料期限，并在事后检查是否形成长期未关闭的例外。
如果识别字段可靠、业务对象边界清楚、错误新增的影响较大，严格拦截更有价值。若字段经常缺失、存在合理例外或误拦截会直接中断业务，则先提示、再由责任人确认，通常更稳妥。
建议将“可否直接拦截”作为独立决策，不要因为系统支持某项配置就默认开启。先用历史样本验证误报，再在一类对象、一个部门或一个阶段试运行，并观察员工是否开始绕开系统。
全量清理的优点是口径统一、项目边界清晰；风险是工作量大、业务确认资源不足，而且容易把低价值历史记录和高风险当前记录混在一起。
分批治理更便于验证规则和控制风险，但需要管理多个批次、版本和遗留事项。适合业务复杂、数据量大或责任人有限的情况。无论选择哪种方式，都要明确批次范围、未处理数据的使用限制和后续责任。
| 选择方式 | 更适合的条件 | 主要优势 | 需要承担的代价 |
|---|---|---|---|
| 一次性全量清理 | 数据范围可控、业务确认力量充足、切换窗口明确 | 能集中统一规则和处理口径 | 项目压力集中，复杂记录可能拖慢整体进度 |
| 分批治理 | 对象复杂、数据量大、业务不能长时间停顿 | 可先验证高优先级对象和规则 | 需管理批次差异和待处理记录，治理周期较长 |
格式统一有利于检索和统计，但历史数据有时承担追溯、合同识别或审计作用。为了视觉整齐而覆盖原始信息，可能损害历史证据。可考虑把规范化后的字段与原始值分开保存，或保留变更记录；具体能力需要根据系统和企业制度确认。
对展示名称、搜索别名和业务识别字段，也不必强行塞进同一个字段。若系统支持，可区分标准名称与历史名称；若不支持，则需要用受控备注或关联文档补充，避免员工为了搜索便利随意改写正式名称。
规则越复杂，覆盖的边缘情况可能越多，但维护成本、解释成本和误判风险也会上升。刚开始时，优先管住高频、高影响、识别条件较可靠的场景，比一次性设计覆盖所有特殊情况更容易落地。
每条规则最好能回答三个问题：它解决什么具体错误，错误判定的影响是什么，谁负责维护规则。若规则没有明确业务收益，也找不到维护责任人，就不应仅因为“看起来更全面”而加入流程。
精细指标能够发现更多问题，但如果数据来源不稳定、状态定义不一致，复杂看板只会制造精确感。起步阶段，先选少量能被持续记录的指标，并固定时间范围、对象范围和状态定义。
后续再逐步补充误报率、漏检抽查率、平均处理时长和业务阻塞时长。对于“漏掉多少重复”这类指标，往往需要抽样复核才能估计，不应把系统没有提示的记录直接当作没有重复。
检查表不是一次性验收文件。业务范围、组织结构、系统配置和数据来源变化后，应重新确认关键规则是否仍然成立。发现重复数量下降，也要检查是否因为新增业务减少、数据源变化或统计口径变动，而不能只看表面趋势。
ERP 数据录入真正落地，至少要连起对象定义、识别字段、录入校验、人工复核、处置留痕和周期复盘。缺少其中任何一环，重复问题都可能换一种形式重新出现。
尤其要记住，数据去重不等于把相似记录压成一条；标准化也不等于字段格式整齐。真正有价值的标准，是让不同员工在相同业务条件下作出一致、可解释、可追溯的判断。
如果企业还没有成熟的数据治理机制，不必先做庞大的制度工程。选择一种高频主数据，明确它代表什么对象；选出几项可靠识别字段；整理一组已知重复与非重复样本；让业务责任人共同复核，再决定采用自动拦截、疑似提示还是人工审核。
之后，把判定依据、处置方式、责任人和统计口径写下来，先运行一个周期，再根据误报、漏检和办理时长调整规则。能够被业务人员持续执行、能够在出现争议时追溯、能够随着业务变化而修订的规则，才是 ERP 标准化管理真正落地的标志。
读者评论
把重复数据从“删除问题”转成“识别、复核、处置、留痕”的流程，比较符合 ERP 实际情况，尤其是已有订单和收款关联时。
文章强调先定义客户、供应商或物料记录代表什么，再选识别字段，这比单纯按名称匹配更稳妥。
漏斗中的数据明确标注为情景模拟，也提醒了候选记录不能直接算作确认重复，这一点对制定指标很有帮助。
迁移数据和对象更名都可能造成重复；上线前清洗之外，还需要持续维护生命周期规则和新增审核。