ERP数据录入改造，最容易走偏的一步，是把“去重”当成一次性的表格清理：导出资料、删掉重复行、再导回系统。这样的处理也许能让列表短一些，却不一定能让下一批数据录得更准。我的判断是，去重的价值不在于少了多少条记录，而在于企业能否把识别规则、数据责任和审核动作放进日常流程，让同一类重复问题不再反复出现。本文讨论的重点，正是如何从重复数据入手，逐步推进录入流程和系统规则改造。
重复数据是一个看得见的结果，却不一定是问题的起点。系统里出现两个名称相似的客户，可能是录入时没有查重，也可能是销售和客服各自建档；物料名称不同但规格相同，可能是命名规则不统一，也可能是旧系统迁移时编码映射出了偏差。只删除其中一行，未必能碰到真正的原因。
我通常把ERP录入改造拆成三个连续目标：先判断哪些记录确实重复，再确定重复记录应如何处置，最后把判断规则放回新增、导入、审核和变更流程。第一步解决存量，第二步减少误删，第三步才决定长期效果。
一个实用的验收问题是：清理完成后，下一位员工能否在创建记录之前发现已有对象，并知道应该选用、申请新增还是提交复核？如果答案是否定的，项目大概率只是完成了数据清扫，没有完成录入改造。
这也解释了为什么我不建议把“系统搭建”简单理解成采购一个新平台或开发一个查重按钮。系统要承接的至少包括数据字段、编码与命名规范、权限边界、重复提醒、异常处理、历史关联和责任留痕。缺少这些配套，功能越强，越可能把错误更快地自动化。
存量治理针对已经存在的数据，关注盘点范围、重复判定、保留记录、合并或停用、关联影响和处理记录。增量控制针对未来新增的数据，关注谁能建档、录入前如何搜索、何时触发提醒、由谁审核，以及接口和批量导入如何执行同一套规则。
两条线要分别验收。存量治理看重复记录是否有明确处置结果，增量控制看新建数据是否经过有效校验。只看清理后的重复率，会遗漏一个重要问题：重复数据可能很快从另一个入口重新进入系统。
| 改造部分 | 要回答的问题 | 可观察的结果 |
|---|---|---|
| 存量治理 | 哪些记录重复，保留哪条，关联业务如何处理？ | 疑似记录有结论，处置有审批和留痕 |
| 增量控制 | 谁能新增，新增前如何查，异常如何处置？ | 重复新增受到提醒、拦截或复核 |
| 持续维护 | 规则变化由谁负责，多久复核一次？ | 数据规则与业务变化同步更新 |
如果企业只能先做一件事，我会建议先选一个高频、高影响的数据对象，明确存量问题和新增入口，再决定系统需要承接什么规则。不要一开始就要求所有模块同时清理，也不要先购买功能，再倒过来寻找它能解决的问题。
客户、供应商和物料的“同名”含义并不相同。两个客户可能名称相同但属于不同法人主体；同一企业可能因为门店、分公司或结算主体不同，需要保留多条业务记录；物料名称相近，也可能因尺寸、公差、材质或包装规格不同而必须分开。
反过来，同一个业务对象也可能有多种写法。客户可能经历更名，供应商可能同时使用品牌名和工商登记名，物料可能被录入简称、旧编码或口头叫法。只按名称完全相等查重，容易漏掉这些情况；只要名称相似就自动合并，又容易误伤真实不同的对象。
因此，我会把“相似记录”称作候选，而不是重复。候选需要结合对象类型、业务字段、来源系统和历史关联进行判断。查重规则的首要任务不是替人做结论，而是把值得核实的记录送到合适的责任人面前。
实际排查时，不能只检查ERP页面上的人工新增。数据还可能来自旧系统迁移、Excel批量导入、外部接口、定时同步、临时项目表和不同部门维护的台账。某一个入口做了查重，不意味着其他入口也执行了同一规则。
例如，销售在ERP中手动新增客户时需要输入统一社会信用代码，批量导入模板却只要求填写客户名称；系统界面看似有必填字段，接口调用却没有相同校验。这样的控制只覆盖一部分场景，重复仍可能从覆盖不足的入口进入。
我会先画出“数据从哪里来、由谁提交、经过哪些处理、最终进入哪张主档”的路径。路径图不必做得复杂，但至少要区分人工录入、批量导入、接口同步和迁移写入。只有入口清楚，才能判断应该在前端提示、接口层校验，还是由后台审核兜底。
为了避免把责任简单推给录入人员，我建议将重复成因分为四类。规则问题包括编码不统一、字段定义不清；职责问题包括多个岗位都能建档、没有唯一审核人；技术问题包括接口校验缺失、导入绕过前端限制；历史问题包括旧系统迁移、合并记录未处理或业务主体发生变化。
这个分类会影响改造方案。若根因是规则缺失，先写清字段口径比加一条模糊匹配更重要；若根因是多入口绕过校验，应先统一接口和导入控制；若根因是业务组织调整，则要先确定主记录与历史记录的关系，不能把组织变更当成重复记录直接删除。
这类做法速度快，却把“文本相同”误当成“业务对象相同”。如果被删除的记录已经关联订单、收货、库存、发票或结算信息，清理可能影响查询、追溯、报表口径，甚至让业务人员找不到原来使用的对象。具体影响取决于系统的数据模型和业务配置，不能仅凭导出表格判断。
更稳妥的做法是先识别候选，再由业务负责人确认对象关系。若确认是重复，仍需决定是合并、停用、设置别名、迁移关联还是保留为不同业务主体。每种处置都应有规则和记录，避免“清理完成”之后无人能解释为什么某条数据消失。
存量清理只是某个时间点的状态。如果新增入口没有控制，新的重复记录仍会出现。这个现象并不一定意味着清理失败，而是说明治理机制还没有从专项任务转成日常流程。
我会把“清理完成”和“运行稳定”分开验收。前者检查既有候选是否处理，后者需要观察新增数据、驳回原因、重复提醒命中情况和人工复核负担。观察窗口应由业务量和风险决定，不能机械地规定所有企业都用同一个周期。
模糊匹配适合帮助排序和缩小人工搜索范围，不天然适合替代业务确认。名称、地址、电话或规格字段可能不完整、过期或共享；某个相似度阈值也可能在客户数据上有效，在物料数据上却完全不合适。
我的处理原则是将自动化分成三档：明确唯一字段命中时，可以阻止新增或要求确认；多字段高度一致但仍有例外时，提示人工复核；仅名称相似或字段缺失时，优先给出候选，不自动合并。阈值必须用企业自己的历史样本验证，并记录误报和漏报。
界面上的查重提醒如果能被批量导入绕过，就只是局部控制。若建档权限广泛开放、审核没有明确责任人，员工遇到提醒时也可能选择继续提交。系统规则必须覆盖实际入口，并明确提示之后该由谁行动。
相反，过度拦截也会给业务造成阻塞。若每个相似名称都必须提交审批，审核队列可能积压；若唯一字段定义不合理，合法业务对象也可能无法创建。因此，改造目标不是“拦得越多越好”，而是让风险与控制强度相匹配。
重复率下降不必然代表业务体验改善。企业可能通过限制新增让重复率变低，却造成新客户、临时供应商或新物料无法及时建档；也可能把重复记录改成别名或停用状态，但报表和历史查询仍然混乱。
所以，我会同时观察数据质量和流程代价：重复候选的确认率、误拦截数量、审核等待时间、首次建档通过率、历史单据查询情况，以及员工是否需要在系统外维护影子表。真正有效的改造应当让数据更可信，而不是把问题转移到线下。
主数据、基础资料和业务单据不应使用同一套删除逻辑。客户、供应商、物料等主数据通常需要稳定身份和跨流程引用；仓库、部门、币种、单位等基础资料往往受组织或配置规则影响；订单、收货单、发票等业务单据则有状态、时间和业务关系，重复处理需要考虑流程状态与审计要求。
第一步要做的是列出对象清单，并为每类对象指定业务负责人。对于每个对象，回答四个问题：一条记录代表什么业务实体？哪些字段稳定？哪些字段可变？什么情况下允许存在多个记录？这些问题没有答案时，不宜直接制定自动合并规则。
字段是否适合查重，不只看是否容易填写，还要看它能否稳定地代表业务对象。名称通常便于搜索，但可能改名、缩写或重复；证照编号可能区分法人主体，但不适用于所有客户类型；物料编码具有内部唯一性，却可能因系统迁移或不同组织的编码体系而发生变化。
我会把字段分成三类：身份字段用于判断是否同一对象，业务属性用于确认对象是否可替代，辅助字段用于提高候选排序质量。每个字段还要标记数据来源、是否允许为空、是否会变更、由谁维护。字段字典不是文档装饰，它决定了查重结果能否解释。
| 数据对象 | 可考虑的识别信息 | 必须复核的例外 |
|---|---|---|
| 客户 | 主体登记信息、客户编码、规范名称、联系方式 | 分公司、门店、结算主体、集团内多个业务单元 |
| 供应商 | 主体登记信息、供应商编码、银行或税务相关信息 | 同一集团不同法人、不同供货主体、主体更名 |
| 物料 | 物料编码、规格型号、单位、关键技术属性 | 相似名称但规格不同、替代料、版本或包装差异 |
| 仓库与组织 | 组织编码、归属关系、启用状态、有效时间 | 同名不同地点、历史组织停用、调整后的映射关系 |
表中的字段是讨论起点，不是通用规则。真正的识别字段要由业务、财务、供应链和系统负责人共同确认，并用实际记录检验。涉及个人信息或敏感业务字段时，还要按企业的安全和合规要求控制访问范围。
识别出候选之后，不要只提供“删除”按钮。建议把处理结果至少拆成确认同一对象、确认不同对象、暂无法判断、历史记录停用、需要补充信息等状态。每种状态都对应责任人、下一步动作和可追溯记录。
如果确认是同一对象，需要选择权威记录，并评估历史业务关系如何保留；如果确认不是同一对象，应记录差异字段或业务理由，减少下次重复告警；如果信息不足，应明确补充材料和处理时限，而不是让记录长期停留在无人负责的待办状态。
这里的“权威记录”不一定总是创建时间最早的一条。字段完整度、业务关联、有效状态、审核记录和数据来源都可能影响判断。保留哪条记录，应由企业预先定义优先级，不能临时由操作人员凭感觉决定。
系统控制可从轻到重分为搜索建议、相似记录提醒、提交复核、阻止保存、接口拒绝和后台定期检测。不是每个字段都需要硬性拦截。误拦截会造成业务等待，漏拦截会增加重复治理成本，控制强度要结合两类代价选择。
对于确有稳定唯一标识的对象，可以考虑在系统层设置唯一性约束，但需确认历史数据、组织隔离和业务例外；对于没有可靠唯一字段的对象，应采用候选提示和人工审核；对于高风险业务关联，可能需要在保存前进行复核，而不是只靠事后报表发现问题。
系统提醒之后，必须设计一个可执行的异常路径。操作人员应知道如何查看候选详情、提交不同对象的理由、发起新增申请、补充缺失字段，或联系哪一类数据责任人。审批人员则需要看到足以作出判断的信息，而不是只收到“疑似重复，请处理”这样没有上下文的任务。
异常流程可以记录候选记录、匹配字段、来源入口、申请理由、审批结论、处置动作和时间。这样既能追查某次误合并，也能积累规则优化样本。若系统暂不支持完整流程，可以先用受控审批表或工单承接，但应设定过渡期限，避免临时台账长期成为第二套主数据。
下面用一个匿名的制造企业场景说明方法。由于没有提供可公开核验的企业项目数据，案例中的规模、比例和时间均为情景模拟，用于展示如何拆解问题，不代表真实客户结果，也不应作为行业基准。
假设企业有多个业务部门共用ERP，历史上经历过系统迁移。物料建档由工程、采购和仓储共同参与；部分资料通过页面新增，部分通过模板导入。管理人员发现同一类零件检索结果很多，但不能确定是重复建档、不同规格，还是旧编码迁移后保留了历史记录。
在这个推演中，项目组先从近期新增物料和高频使用物料中抽取样本，再按完全相同编码、名称相似、规格冲突、疑似历史迁移四类整理。抽样不是为了证明全库重复率，而是为了找到问题类型、入口差异和需要业务确认的字段。
如果直接对全量数据跑模糊匹配，可能生成大量低价值候选。先用高区分力字段缩小范围，再对名称相似但规格不同的候选安排人工复核，更容易让业务团队看到查重规则为什么触发、哪些信息真正有用。
项目组需要与工程、采购和仓储确认：什么样的规格差异意味着不同物料？替代料是否作为独立对象管理？单位转换是否改变物料身份？版本升级后旧物料是否停用？这些决定都不能单由IT人员根据字段表推断。
例如，名称相同但关键尺寸不同的记录可能是不同物料；名称不同但规格、材质和图纸版本相同的记录则可能是同一对象的不同叫法。若企业允许多个供应商使用不同内部描述，还要区分采购描述与物料主名称，避免将业务备注误当成身份字段。
对存量候选，业务负责人确认是否合并、停用或保留；对页面新增，系统在保存前用编码和关键规格字段提示候选；对批量导入，模板增加必要字段，并在导入预检阶段返回疑似重复行和冲突原因。三类入口共享规则，但提示方式可以不同。
例如，导入预检不一定要直接拒绝整批文件。可以把错误分成必填缺失、唯一标识冲突、疑似重复待复核和格式异常，允许无问题行继续进入下一步，把需要处理的行单独退回。这样既避免整批阻塞，也不会悄悄跳过风险数据。
情景模拟中，企业可以设定一个试点观察窗口，并记录候选命中后人工确认的比例、错误拦截数、从提交到审批的耗时、导入退回原因和重复候选复发情况。所有目标值都应在试点前由企业根据业务量确定，不能把示意数字包装成通用标准。
例如，若提醒命中很多，但确认重复的比例很低，可能是匹配字段过宽；若人工复核准确，却经常超时，可能是责任人不清或审批负荷过高；若页面新增效果良好、批量导入仍反复出现，则说明入口覆盖不完整。指标的意义在于帮助找到下一步要改哪里。
若团队需要持续看重复候选、审核积压和入口差异，可以使用数据分析工具建立监控视图。例如，企业可评估是否将ERP导出的质量指标接入九数云这类分析平台，按数据对象、来源入口、部门和时间观察趋势。
这里要划清边界：分析工具可以帮助汇总和呈现指标，但是否能直接承担ERP内的建档拦截、业务审批或主数据合并，必须以实际产品能力、接口方式、权限设计和系统架构为准。不要因为仪表板能展示重复候选，就把它当成主数据治理流程本身。
更稳妥的分工是：ERP或经验证的主数据流程负责权威记录、权限和业务处置；分析工具负责质量监测、异常趋势和管理视图；业务负责人负责确认对象关系；IT团队负责接口、日志、安全和规则落地。系统边界清晰，数据责任才不会在工具之间来回漂移。
先限定范围，不要一上来清全库。可以选一个业务影响明显、负责人明确、字段相对可解释的数据对象，盘点它的记录数量、来源入口、字段完整情况、重复候选和历史关联。盘点结果要区分已确认问题与待核实问题。
我建议每条候选至少保留来源、关键字段、当前状态和责任人。若只有一份去重后的结果表，没有原记录、匹配理由和处置结论，后续很难复查，也无法从误判中改进规则。
规则文件至少要覆盖对象定义、字段口径、编码或命名要求、字段责任人、可新增角色、审核条件、重复候选处置、例外场景和变更流程。内容要能被业务人员执行，避免只写“保证数据唯一”“按规范录入”这种没有操作含义的要求。
责任矩阵要回答谁提出新增、谁审核、谁维护规则、谁批准合并、谁负责接口校验。一个岗位可以兼任多项，但不能让关键责任隐含在“相关部门共同负责”这句话里。发生争议时，要能找到有权作出业务判断的人。
在系统改造前，用真实但受控的历史样本检验候选规则。抽取一批确认重复记录、一批确认不同记录和一批暂时无法判断的记录，观察规则分别命中什么。若规则对确认不同的对象也频繁报警，就应调整字段组合或控制强度。
这一步能减少“功能上线后才发现规则不适用”的返工。系统配置应基于已经验证的业务规则，而不是先设一个相似度阈值，再要求业务迁就它。若业务定义本身有争议，优先解决定义，不要把争议隐藏在代码参数里。
不同入口可有不同交互，但应遵守一致的数据规则。人工页面侧重即时搜索和提示；批量导入侧重导入前校验、逐行错误反馈和结果追踪；接口侧重必填字段、身份校验、幂等处理和失败日志；后台检测侧重发现绕过流程或历史遗留问题。
系统能力要以实际版本、接口和数据模型为准。上线前应至少测试正常新增、重复新增、相似但不同、关键字段缺失、跨组织同名、接口重试和审批退回等场景。任何测试都不能只用“成功保存”判断，还要确认业务关联、日志和权限符合预期。
规则上线后，既要检查误报，也要检查漏报。误报是把不同对象提醒为疑似重复；漏报是实际重复对象没有被识别。二者的成本不同，观察指标不能只报“查出多少条”。对于误报，要分析字段过宽或例外缺失；对于漏报，要看入口绕过、字段缺失还是规则没有覆盖别名和历史编码。
规则调整应有版本记录，说明改了哪些字段、为什么调整、由谁批准、影响哪些对象。若没有版本管理，业务人员很难解释前后规则差异，历史数据也可能因新规则被重新判定，导致处理结论不一致。
这类企业通常更适合先做好增量控制，而不是等数据积累后再集中清理。优先明确主数据责任人、字段口径、建档权限和新增审批；对关键对象做小范围样本验证，再配置查重提示或唯一性约束。
取舍重点是不要过早把规则做得过度复杂。业务还在变化时，硬编码大量例外可能增加维护负担。先把稳定身份字段和基本流程落地，定期复核高频异常，再逐步增加精细化校验。
这类企业应先评估数据关联和审计要求，按对象、业务状态和风险分批处理。不要直接对全库进行自动合并，也不要仅凭名称或编码判断。先从高频查询、长期维护成本高或影响跨部门协同的对象入手。
取舍重点是改造速度与追溯完整性。分批处理耗时较长，却能降低误删历史记录的风险；全量清理看起来快，但如果缺少回滚方案、关联校验和审批留痕，后续修复成本可能更高。复杂数据应由业务和系统人员共同确认。
先决定权威来源和同步方向，再谈查重规则。如果多个系统都可以独立建档，却没有主从关系和冲突处理机制，ERP中的重复数据只是更大问题的一个表象。应盘点各系统负责的字段、数据流向、同步频率和失败处理方式。
取舍重点是集中管理与业务自治。集中建档能提高一致性，但可能增加单一团队的审核负担；分散建档更贴近业务，却需要统一编码、接口校验和责任边界。企业应根据业务响应速度、数据风险和系统架构决定，不宜简单追求“所有数据都只能从一个页面录入”。
不要把所有疑似重复都送人工审批。应先区分高置信度冲突、中等置信度候选和低置信度相似记录，再选择不同的提醒与拦截方式。候选提示可按字段解释、来源和匹配原因排序，让员工更快判断，而不是只展示一个分数。
取舍重点是审核负荷。强拦截减少部分重复新增，却可能延长建档周期；弱提示保持速度，却依赖员工遵循流程。可以先对高风险字段强校验，对一般相似候选采用提醒和抽查，再依据误报率和业务等待时间调整。
先用流程和受控模板建立最低限度的控制：统一新增申请表、规定必填字段、设定责任人、导入前执行校验、保留处理记录。可以先用现有ERP的查询、权限和审批能力，但需要验证这些能力是否能覆盖实际入口。
取舍重点是临时方案的可持续性。表格或人工审核适合短期试点，帮助企业验证规则；若持续依赖个人维护、没有版本控制或无法追溯，就应设定迁移到系统流程的时间点。临时台账不能无限期地充当另一套主档。
| 企业情况 | 优先动作 | 不宜优先做的事 | 主要取舍 |
|---|---|---|---|
| 新上线、数据少 | 定义责任、字段和新增入口 | 建设过多复杂例外 | 先易执行，再逐步精细化 |
| 历史数据多 | 抽样、分对象、核验关联 | 全库自动合并 | 处理速度与追溯安全 |
| 多系统共建 | 明确权威来源和同步规则 | 只改ERP单一页面 | 集中管理与业务自治 |
| 高并发录入 | 分层控制、优化候选排序 | 所有相似项一律审批 | 重复风险与审核效率 |
| IT资源有限 | 用受控流程做规则试点 | 长期依赖无版本台账 | 短期成本与长期维护 |
重复率看起来简单，实际上需要说明分母和判定条件。是全量记录中疑似重复的比例，还是抽样复核后确认重复的比例？统计的是当前有效记录，还是包含停用和历史记录？不同口径得出的数字不能直接比较。
同理，“建档耗时”应说明起点和终点；“驳回率”要区分资料不完整、重复候选和业务信息错误；“重复候选命中率”要说明候选是否经过人工确认。没有口径说明的百分比，不适合拿来做项目成效承诺。
质量指标可以包括确认重复率、关键字段完整率、候选误报率、重复问题复发次数；流程指标可以包括首次提交通过率、审核等待时间、补录次数和人工复核耗时；风险指标可以关注未经审核的新增、接口失败、异常合并和历史关联告警。
不需要一次性追踪几十个指标。试点阶段选少量能触发行动的指标更有效：如果误报高，就调整规则；如果审核等待长，就优化责任分配；如果某个入口复发，就补齐入口校验。指标不是为了生成漂亮报表，而是为了告诉团队下一项具体改进是什么。
改造前应保留一段可比较的基线，记录数据量、业务量和统计范围；改造后则在相近口径下观察。若同期业务量明显变化，单看异常数量可能误导判断，可以同时看每千条新增记录中的异常数、每次导入中的冲突数等相对指标。
对于规模较小的企业，几条异常就可能让比例大幅波动，不宜过度解读短期变化。可以把定量指标与案例复核结合，查看典型误报、漏报和重复复发路径。只有在口径稳定、样本充分时，才适合讨论趋势。
若建档通过率下降，可能是查重拦截过严，也可能是字段要求刚刚补齐，或培训尚未完成；若人工复核耗时上升，可能是候选池变大，也可能是审核责任集中到少数人员；若重复率下降但历史查询投诉增加，就要检查合并和停用处理是否影响了原有业务路径。
因此，每次调整都应记录背景、影响对象和验证结果。将“规则改了”与“问题改善了”区分开，避免因某个报表数字暂时变好，就忽略了其他部门承担的工作量或业务风险。
第一，企业是否已经说清楚“重复”在这个数据对象上意味着什么？如果没有，先做业务定义和样本复核。第二，问题主要来自哪个入口？如果只来自导入，先改导入预检和模板，未必需要重做整个录入界面。第三，误拦截和漏拦截哪个代价更高？答案会决定采取提示、人工复核还是强制拦截。
这三个问题能帮助企业把系统建设从功能清单拉回到业务决策。真正需要开发的，可能不是一个复杂的模糊匹配引擎，而是明确责任人、统一接口字段、增加异常原因和建立可复查日志。功能规模不等于改造价值。
ERP数据录入改造的难点，不是找到一条看起来相似的记录，而是让企业对“为什么认为它重复、由谁确认、如何处置、以后怎样避免重现”形成一致答案。只有能解释的规则，才适合交给系统；只有能复核的结果，才适合用于长期治理。
下一步可以从一类高频数据开始：抽取一批候选，标明来源和关键字段；邀请业务负责人确认对象边界；记录误报、漏报和历史关联；再把稳定规则落到新增、导入和接口流程。先完成一个可验证的小闭环，比一次性追求全系统、全数据、全自动更可靠。
去重是入口，持续治理才是目标。当企业把数据责任、判断规则和系统控制连接起来，ERP里的每一次新增才不只是多了一行记录，而是为后续查询、协同和经营分析提供一条可追溯、可维护的数据基础。
我准备改造ERP录入流程，但现在客户、物料资料都比较乱。我担心先清数据会返工，也担心先搭系统只是把旧问题搬进去；到底应该从哪一步开始？
建议先做小范围数据盘点，再定规则、清理试点数据，最后配置系统。直接全量去重容易把“名称相似但实际不同”的记录合并；先搭系统却不定建档标准，则可能把重复问题固化进新流程。可以选一个业务影响明显、范围可控的数据对象试点，例如客户档案。
先抽取一批记录，标出重复疑点、来源系统、维护岗位和关联业务，再由业务人员确认识别规则。试点通过后，把规则转为字段要求、审核责任和录入校验，逐步推广到其他对象。
我发现系统里有些客户名称只差一个字，也有同一家公司用简称和全称分别建档。我不确定能不能直接按名称去重，怕合并后影响历史单据和后续对账。
不要只凭名称判重。名称可以作为初筛线索，但应结合对象类型选择识别字段：客户可核对统一社会信用代码、开户地址或联系方式；物料可核对规格、型号、单位和关键属性；供应商也要结合证照与结算信息。字段组合需要业务负责人确认，不能把某个字段天然当成所有场景下的唯一依据。
处理时可分为“确认重复”“疑似重复”“确认不同”三类。疑似记录交给业务复核；确认重复后，先检查订单、库存、应收应付等关联，再决定保留、合并或停用。保留原编码、处理理由和审批记录，通常比直接删除更利于追溯。
我所在团队以前做过一次表格清理，刚开始看起来整齐了，过段时间又出现相似记录。我想知道问题是操作培训没做好，还是ERP配置不够，应该把哪些控制点放进日常流程？
一次性清理只能处理存量，不能替代新增流程治理。应先列出资料新增入口：页面手工录入、批量导入、外部系统接口和业务单据带入；每个入口都要明确校验、审核和异常反馈责任。只在人工页面提示，往往挡不住接口和导入文件产生的新重复。系统控制可以分层设计：提交前做必填和编码校验；
发现相似记录时提示用户查看，而不是一律自动合并；高风险对象由指定岗位审核；批量导入则保留错误行、原因和处理日志。具体能否配置，要核对ERP版本、接口方式及数据模型，不能仅凭产品功能介绍推断。
我不想把项目验收写成“数据更规范了”这种主观结论，但目前也没有可靠的行业基准。我希望有一套能在改造前后对比的指标，同时避免为了降低重复率而把正常业务记录误判掉。
先定义统计口径，再比较改造前后的同类数据。可观察确认重复率、疑似重复复核量、建档驳回率、导入失败率和新建档平均耗时。重复率应明确分母、数据范围与判重规则；规则变更后要重新标注，否则前后数字并不具备可比性。例如，以下仅是内部验收模板，不是行业基准：试点前抽查1000条客户记录，按已确认规则标出疑似项；
上线后连续观察一个月，比较每周新增记录中的确认重复数、人工复核量和建档耗时。若重复数下降但审核等待明显增加，应继续调整提醒阈值和审批分工，而不是只追求一个更低的重复率。
读者评论
把存量清理和新增控制分开验收很实用，清完旧数据后还要检查导入、接口等入口，才能判断重复是否会再次出现。
文中强调相似记录只是候选，这点很重要。客户主体、物料规格等差异可能影响业务，不能只凭名称相似就合并。
查重规则需要覆盖人工录入、批量导入和接口同步，否则页面上的提醒容易被其他入口绕过。
除了重复率，也应看误拦截、审核等待时间和历史单据查询情况，这些指标更能反映改造是否影响日常业务。