ERP 数据录入实施中，旺季前最危险的不是“系统里还有重复记录”，而是团队把名称相似误判为同一主体，批量合并后才发现历史订单、库存或对账关系被带错。数据去重因此不能以删掉多少行作为完成标准；真正的完成标准是：规则经过业务确认，处理结果能够追溯，导入后关键业务流程通过验证，并且出现异常时有明确的暂停和恢复办法。
我会把 ERP 数据去重放在一条完整实施链路里，而不是孤立安排一个“清洗数据”的任务。这条链路至少包括：明确数据范围、定义重复口径、识别候选记录、业务复核、决定合并或保留、导入验证、旺季期间监控。
其中任何一步缺失，都可能让表面上的清理变成新的数据风险。比如，候选记录识别得很准，但没有确认主记录应保留哪个编码；或者导入数量核对无误，却没有检查历史单据能否继续关联。前者会造成主数据规则不一致，后者则会出现“数据导进去了，业务用不起来”的情况。
因此，去重完成率不能只看“疑似重复处理了多少条”，还要看业务确认、关联关系、导入结果和异常处理是否闭环。旺季前做得快不等于做得好；一条错误的合并，可能比一批尚未清理的重复候选项更难收拾。
一个可执行的完成标准，应由业务、数据负责人和系统实施人员共同确认。至少要说明清理对象是什么、重复如何判定、哪些情形必须人工批准、记录如何处理、导入后核对什么，以及遇到错误由谁决定暂停或恢复。
如果项目组只说“把客户和商品重复数据清一下”，任务仍然不可验收。客户的重复判断可能依赖统一社会信用代码、联系方式和业务关系；商品则可能要看规格、型号、计量单位、包装层级及有效状态。不同对象不能共用一条模糊规则。
| 验收层面 | 需要回答的问题 | 可留存的结果 |
|---|---|---|
| 范围 | 哪些数据对象、组织、账套和时间区间纳入本轮处理？ | 数据清单及版本记录 |
| 规则 | 什么是确认重复，什么只是疑似重复？ | 字段口径、例外条件和审批规则 |
| 处理 | 采用合并、停用、保留还是重新编码？ | 处理决策及操作记录 |
| 验证 | 导入数量、关键字段、关联单据和业务流程是否通过？ | 核验结果及问题清单 |
旺季准备时间有限时，不一定要先把所有历史记录整理到最干净。更有效的做法，是先找出近期会进入订单、采购、库存、发货、结算等关键流程的数据对象，再按业务影响排序。高频使用且出错后影响面大的对象优先；长期未使用、没有业务关联的旧数据，可以单独安排治理。
这不是降低数据质量要求，而是把有限的复核能力用在风险最高的地方。尤其是旺季临近时，与其让团队忙着处理大量低影响历史记录，不如先确保新单会使用的商品、客户、供应商及仓库数据能够正确录入和调用。
客户资料可能来自销售表格、旧系统导出、线上订单和人工补录。同一家企业可能同时出现全称、简称、门店名或历史名称；联系方式可能已经更换，开票主体和收货主体也可能不同。若仅靠名称相似度自动合并，就有可能把两个合法的业务对象当成一个。
商品或物料数据也有类似问题。名称相同，不代表规格、包装单位、条码或适用渠道相同；名称不同，也不代表一定是不同商品。比如一个品类在不同仓库采用不同包装单位，若把箱、件、个的换算关系遗漏，后续库存数量就可能出现口径冲突。
供应商资料则可能同时存在集团主体、开票主体和实际供货主体。业务人员日常简称可能一致，但采购合同、发票和付款对象未必相同。这里要先问“业务对象是什么”，再问“哪些字段能帮助识别它”，不能先看匹配结果再补解释。
日常业务量较低时，员工可能通过记忆绕开重复记录：知道该选哪个客户、哪个商品编码，发现字段不对再找同事确认。旺季业务节奏加快，新增人员增加，订单录入和仓库操作更依赖搜索结果与系统提示。此时，同名记录、停用记录未标识、单位口径不一致等问题更容易进入实际流程。
因此，旺季风险不只来自重复本身，还来自“重复记录如何被业务人员选中”。去重工作需要观察搜索排序、状态标识、默认值和权限设置。若系统允许无提示地选择已停用记录，即使后台重复项已清理，现场仍可能出现错误选择。
下面的示例不是某家企业的实测结果，而是用于讨论实施取舍的情景模拟。假设一个经营多渠道商品的团队，在旺季前需要处理客户和商品主数据；他们发现同名或近似名称记录较多，但其中一部分实际对应不同包装、不同交易主体或不同历史编码。此时若用一个相似度阈值直接删除，工作量会下降，误合并风险却可能升高。
我建议每类数据至少追问三个问题：它会被哪个流程调用？出错后谁先发现？发现时是否已经形成下游单据？例如商品资料错误可能在下单时暴露，也可能直到拣货或盘点才被发现；客户主数据错误可能影响报价、开票或应收核对。发现越晚，纠正所需协调的人和记录通常越多。
这也解释了为什么不能仅按记录数量排优先级。几千条长期未使用的旧联系人，未必比几十条旺季高频商品记录更紧急。优先级应综合业务频次、影响范围、发现时点和修复难度，而不是只按数据表的行数排序。
名称只能作为识别线索，不能单独充当合并依据。名称相同的客户可能是不同分支机构、不同开票主体或不同地区的独立经营实体；名称相同的商品也可能存在规格、版本或计量单位差别。
更稳妥的处理方式，是把字段分成强识别字段、辅助字段和描述字段。强识别字段在业务规则允许时可提高匹配置信度；辅助字段用于交叉核验；描述字段只提供线索。哪些字段属于哪一类，应由数据对象的业务定义决定，而不是由清洗工具默认决定。
相似度高只能说明值得复核，不等同于业务上确认重复。尤其是涉及合同、结算、税务或库存关联的数据，不能为了缩短工期，把模糊匹配结果直接当作合并指令。
电子表格适合做初步盘点、字段标准化和小批量人工复核，但“删除重复值”通常只按选定列判断相同。它未必理解一个主数据编码是否被历史订单引用，也未必能判断两个近似名称是否代表同一业务主体。
如果导出数据后在表格里处理，至少要留存原始文件、处理副本、字段说明、去重规则和每次操作记录。不要覆盖唯一原始版本，也不要在没有记录的情况下反复手动排序、筛选、复制和粘贴。否则一旦发现合并错误，很难定位是哪一步改变了数据。
电子表格也不是不能用于实施，而是要明确边界：它可以帮助筛选候选项，不能替代业务批准和系统关联验证。数据规模大、依赖关系复杂或存在严格审计要求时，应评估更适合的批处理与校验机制。
实际处理通常不止“保留一条、删除其他”。可能的处置包括合并记录、停用旧记录、保留历史编码并建立映射、修正字段后继续使用，或暂缓处理争议数据。采取哪一种，取决于系统对历史单据、引用关系和审计记录的处理方式。
如果一条旧编码已被历史单据引用，直接删除可能使查询、报表或关联追踪受到影响。即便系统允许删除，也要先确认删除后的业务语义。看起来重复的记录，有时承担着历史追溯作用；此时停用并保留，比彻底删除更安全。
系统提示“导入成功”，只能说明文件或记录通过了某些导入检查，不能自动证明字段映射正确、主从关系合理、业务权限适配或历史关联完整。比如数量相符，但商品单位映射错了；记录都在，但有效状态被错误覆盖；客户已导入，开票信息却缺失。
验收不能只检查文件上传结果，还要从业务使用角度抽查。对于关键对象，应至少核对数量、编码、必填字段、状态、关联关系及典型业务流程。具体抽样比例不宜套用一个通用数字，应结合数据风险、变化规模和企业验证能力确定。
自动匹配能降低重复查找的工作量，但判断“是否同一业务对象”需要业务语义。系统可以把记录按字段规则分层，把高置信候选和争议候选分开；业务人员再集中处理不确定项。这样比让系统自动合并所有近似记录更可控。
复核不是低效环节，而是风险控制的一部分。真正应该优化的是复核顺序：先处理高影响、低歧义记录，再处理高影响、高歧义记录；对低影响、低使用频率的数据，可在旺季后治理。
去重前应先写出数据对象的业务定义。例如，“客户”是指签约主体、付款主体、收货门店，还是所有这些对象的组合？“商品”是指标准品、具体规格，还是带有渠道或包装属性的可销售单位？定义不同，唯一性规则就不同。
如果企业内部对对象定义不一致，先不要批量清理。应组织业务负责人把常见情形列出来，明确哪些差异代表不同对象，哪些只是资料填写方式不同。否则技术人员只会把分歧快速转成自动化规则，之后再由业务团队承担误判后果。
可以把候选项分为三档，但阈值不应凭空设定。项目组应根据字段可靠性、对象风险和历史数据质量，使用一批已知样本测试规则，再由业务负责人确认可接受边界。
| 候选层级 | 典型特征 | 建议动作 |
|---|---|---|
| 高确定性 | 关键识别字段一致，业务属性也相符 | 仍按项目审批规则处理，并保留处理前后映射 |
| 需要复核 | 名称或部分字段接近，但仍存在主体、规格或状态差异 | 交由对应业务负责人确认，不直接自动合并 |
| 暂缓处理 | 关键字段缺失、关联复杂、责任人无法确认或历史关系不明 | 保留现状并标记风险，必要时暂停进入旺季流程 |
分类的意义不是制造更多标签，而是避免所有候选都挤在同一个处理队列里。高确定性记录可以按既定流程推进；争议项进入人工判断；无法确认的对象不要靠猜测处理。
一条可执行的规则，应该让业务人员回答“为什么这两条被放在一起”。例如，系统使用了哪些字段、字段是否经过标准化、哪些字段冲突时会降低置信度、哪些例外会强制人工审批。若规则无法解释，业务很难为结果背书，事后也难以复盘。
在规则测试阶段，建议准备三种样本：确认重复的正例、确认不重复的反例，以及业务尚不能确定的边界例。只测试“明显重复”的正例，会让规则看起来准确，却可能完全没有暴露误合并问题。
业务决定“应该怎么处理”，系统决定“能否安全地这样处理”。比如业务同意保留某条客户记录，但系统是否支持历史单据引用迁移、编码映射、停用状态追踪，需要根据具体 ERP 的产品文档、测试环境和实际配置核实。
在没有确认系统行为前，不要把“系统有合并按钮”理解为“合并后所有关联都正确”。按钮能执行操作，不代表它满足企业当前的数据治理要求。实施人员应把系统测试结果、业务批准记录和例外处理清单放在一起验收。
抽检资源可以按风险安排，而不是所有对象一律抽同样比例。高频使用、涉及结算或库存、关联历史单据复杂的数据，应增加重点核验；低频且没有下游依赖的数据，可以采用较轻的抽检方式。无论抽样多少，都应留下样本选择方法和核验结论。
如果抽检出现关键错误，不应只修正单条记录后继续导入。要先判断错误来自规则、源数据、映射关系还是人工操作，再决定是否暂停同批数据、扩大复核范围或重新运行流程。出现一个错误不一定意味着整批失败，但不能把它当成孤立偶发问题而不调查原因。
以下是一个用于说明决策过程的匿名情景推演，不代表某个真实企业的项目实测。假设一家多渠道经营团队准备在旺季前迁移客户和商品资料，数据来源包括旧系统导出、业务部门维护表和近期补录记录。团队发现同名客户、近似商品名称和缺失字段同时存在，需要在有限时间内确定先做什么。
项目组没有先承诺“几天清完”，而是先盘点数据对象、使用频率和下游流程。客户资料主要影响报价、订单和开票；商品资料主要影响订单录入、仓库拣货与库存核对。双方据此确定：近期高频商品及直接关联库存的对象优先核验，历史低频客户资料暂不批量合并，先标记后续治理。
团队为客户和商品分别建清单，而不是把所有记录放进一个相似度规则。清单包含来源系统、原始编码、名称、关键属性、状态、最近使用情况、是否关联历史单据、业务责任人和处理状态。
对商品，先确认规格、计量单位、包装层级和有效状态；对客户，先确认主体类型、交易关系、开票或收货用途。字段缺失的记录不会被自动合并，而是进入“补资料”或“待判断”队列。
清洗人员通过统一大小写、去除无意义空格、规范常见简称等方式提高候选发现能力，同时保留原字段。标准化后的字段用于匹配，原值用于复核和追踪。若只保留清洗结果，团队将难以解释原始记录与新记录之间的差异。
候选清单会显示匹配依据与冲突字段。例如，两条商品名称高度相近，但包装单位不同，就不应该只因名称相似进入自动合并；两条客户记录名称接近，但主体标识冲突，也应转入人工确认。
业务负责人逐条处理候选项，并给出“确认同一对象”“确认不同对象”“需要补充信息”“暂缓处理”等结论。对于确认同一对象的记录，再由责任人确定主记录、保留编码策略和历史映射方式；对于确认不同的记录，补充差异说明，避免下次又被当作新候选。
这一步看起来比一键清理慢，但它能把业务判断从口头沟通变成可审计的决定。日后若发现某条记录处理不当，可以追溯当时的字段、依据、审批人和系统操作，而不是重新猜测合并原因。
在正式批量导入前，项目组选取一批覆盖不同情况的样本，包括标准记录、字段缺失记录、曾被引用的旧编码和有争议的近似记录。测试目的不是证明导入按钮能运行，而是检查字段映射、状态处理、编码关系和业务查询是否符合预期。
如果系统对旧编码与历史单据的关联处理方式尚未明确，团队就不把这类记录放入批量合并范围。先请实施人员在测试环境核实，再由业务确认是否接受该处理方式。这样做可能增加前期沟通，却能降低正式环境里反复修复的风险。
导入后，团队对记录数量、关键字段完整性、编码重复、状态和关联关系进行检查，并选择典型业务场景实际操作。例如，创建测试订单时能否选到正确商品，商品单位是否与订单需求一致；客户记录是否能被正确用于业务单据，查询结果是否清晰区分相似主体。
情景模拟中，项目组可以预先设定“发现关键字段错配立即暂停同批次处理”的规则，并指定谁负责判断影响范围。这里不需要承诺所有异常都能自动回滚；应根据系统实际能力确定恢复方式，并在测试环境验证后再用于正式操作。
项目汇报可记录候选数、业务确认数、暂缓数、处理完成数、导入异常数、抽检通过情况和复核工时，但每个指标都要有口径。比如“处理完成”是指已作出业务决定，还是已经在 ERP 中完成修改？如果口径不清，同一张进度表可能让项目组误以为工作已完成。
不要为了做出好看的汇报，把模拟案例中的数字写成企业实绩，也不要将单个项目的观察包装成行业效率基准。项目数据只有在说明样本范围、统计周期、对象类型和计算方式后，才适合用于对外比较。
| 案例检查点 | 情景模拟中的示意结果 | 实际项目应验证什么 |
|---|---|---|
| 候选项复核 | 260条候选中，190条确认重复，40条确认不同，30条暂缓 | 候选规则是否过宽，暂缓原因能否归类，业务责任人是否完成确认 |
| 导入校验 | 190条处理记录中，6条出现字段或关联异常 | 异常是否集中于某一数据来源、字段或操作步骤，是否需要扩大检查 |
| 抽样业务测试 | 20个样本中，18个通过，2个需修正 | 样本是否覆盖高风险场景，修正后是否重新验证同类记录 |
上述数据完全是流程演示用的情景模拟，不能据此推断真实清理比例或系统效果。它的价值在于提醒项目组：候选、确认、导入和业务验收是不同阶段，不能用一个“已清理记录数”代替所有验收信息。
如果项目仍有较充足的准备窗口，先不要急着批量修数据。优先完成数据对象定义、字段口径、来源盘点、责任人指定和匹配规则测试。越早发现“业务上对客户定义不一致”或“商品单位规则不一致”，越有空间处理组织协作问题。
这类情况下可以扩大历史数据治理范围，但仍应把高风险对象先做出可验收结果。不要因为时间充裕，就把所有历史字段的整理工作都塞进 ERP 上线关键路径，导致低优先级清洗拖累核心业务测试。
如果上线或迁移窗口已接近旺季，应缩小本轮范围，优先处理即将使用的数据对象和会影响关键业务链的数据。对不确定、关联复杂或责任人无法及时确认的记录，可以采用暂缓、限制使用或人工审批等受控措施，但具体做法要与系统权限和业务流程匹配。
此时不宜为了追求“零重复”而扩大自动合并。需要把必需数据、可延后数据和禁止未经确认处理的数据分开，明确每日问题处理机制。任何临时新增的主数据，都应记录创建人、理由、审批人和后续复核责任。
小团队可能只需导出数据、按关键字段初筛、业务人员复核并做小批验证，不一定需要复杂治理工具。但轻量不等于随手操作：应保留原始版本，说明筛选字段，标注每条记录的决定，并在正式修改前确认系统是否会影响历史引用。
如果数据量小且候选数量少，人工逐条检查可能比搭建复杂规则更经济。若同一问题反复出现，再将经过验证的业务规则固化，而不是过早自动化未经确认的口径。
当数据来自多个系统、不同团队和不同历史时期时，先给每条记录保留来源信息和批次标识。这样可以识别问题是否集中在某个来源、某次导出或某种录入习惯，而不只是得到一份混在一起的候选清单。
建议按数据来源分批处理：先对每个来源做字段映射和质量检查，再进行跨来源匹配。若直接把所有来源拼成一个大文件，字段冲突、编码重复和口径差异会一起出现，问题定位成本更高。
如果主数据已经被订单、采购、库存或结算记录引用，处理之前要确认 ERP 对引用关系的支持方式。某些场景下，保留历史记录并设置停用或映射关系，比直接合并更符合追溯要求。不要假定所有系统都能自动迁移关联，也不要仅凭测试界面的提示判断实际影响。
当系统能力或历史关系暂时无法确认时，稳妥方案通常是将高风险记录从批量操作范围中隔离，安排实施人员和业务负责人单独验证。暂缓处理并不代表放弃治理，而是承认当前证据不足以支持安全变更。
如果目标是尽快完成旺季上线，通常需要优先限定范围、提高自动筛查效率，并把复杂记录交由后续治理。代价是部分低频历史数据暂时保留；收益是关键业务数据有机会更早通过验证。若追求全量覆盖，就需要更多时间、复核资源和跨部门协调，也可能把上线关键路径拉长。
我更倾向于将“关键业务可安全使用”设为旺季前目标，把“全部历史资料达到同一质量水平”作为长期治理目标。前提是延后处理的记录被明确标识，不会悄悄进入关键流程。否则所谓分阶段，只是把风险藏起来。
自动化适合处理明确、稳定、可解释的规则，例如字段格式标准化、完全一致记录筛查和候选排序；人工判断适合处理主体关系、历史用途和业务例外。两者不是替代关系，而是分工关系。
自动化比例越高，越需要先验证规则质量和异常处置机制。人工比例越高，越需要控制复核疲劳、统一判断口径并留下审批记录。最佳方案不是“全部自动”或“全部人工”，而是让系统减少重复劳动，让业务人员把判断力用于最不确定、影响最大的记录。
合并有利于减少重复入口，但可能涉及历史引用和主记录选择；停用能降低继续误用的机会，却可能保留多个历史记录；映射关系有助于追踪旧编码，但需要有人维护并确认系统支持。没有一种处理方式适用于所有对象。
决策时可以按以下顺序检查：当前记录是否仍被业务使用？是否关联历史单据？是否有明确的主记录？系统是否能保留旧编码映射？合并后能否复核下游数据？只要关键问题尚未回答，就不应把“合并”设为默认选项。
“重复记录为零”通常不是唯一可操作的放行标准，因为仍可能存在待确认数据、特殊主体或有意保留的历史编码。更实际的判断是：高风险候选已处理或被隔离；关键字段和关联关系通过验证；业务负责人认可当前规则；临时新增数据有审批和监控办法；异常处置责任明确。
项目组还应明确不可接受的条件。例如，关键商品单位无法确认、客户结算主体不明、正式导入出现无法解释的关联异常时，应触发暂停或扩大核验。条件应在实施前写清，避免旺季压力下临时降低标准。
如果团队现在就要启动，建议先完成三个动作：第一，选出旺季最常用的两到三类数据对象；第二，找业务负责人确认各对象的唯一性口径；第三，拿一批真实但可控的样本验证“候选识别，人工判断，导入校验”整条链路。先把规则和责任跑通，再扩大数据范围，比一开始就追求全量清理更容易控制风险。
最值得记住的判断是：数据去重的终点不是表格里少了几行，而是业务人员在旺季能够稳定地选对记录，系统能够正确地关联单据，项目团队也能解释每一次合并、保留或暂缓的原因。把这三件事做实，才算真正完成旺季准备。
我正在准备旺季前的ERP数据导入，客户、商品、供应商几类数据都发现了重复记录，但团队人手有限。我想先处理最影响业务的部分，应该按数据数量、出错风险，还是业务流程来排优先级？
优先级不应只看重复记录有多少，而应看它是否卡在旺季的关键业务链上。建议从订单、采购、收货、库存、发货和对账流程倒推：哪些数据会被多个岗位反复调用，哪些数据一旦选错就可能影响单据或统计口径，就先检查哪些。
例如，商品主数据如果同时用于销售下单、仓库拣货和库存统计，通常比低频使用的内部备注类数据更值得优先核查；但若旺季采购依赖供应商档案，供应商数据也可能更紧急。可先列出数据对象、关联流程、负责人和风险等级，再由业务负责人确认顺序，不要仅凭技术人员估算决定。
一个实用的起点是选一个高频业务对象做试点：先抽取候选重复项，确认规则和审批方式，再扩展到其他数据类型。这样比一次性清理所有表更容易发现口径冲突，也能控制误合并的影响范围。
我发现客户名称有全称、简称和历史名称，商品也有相似规格，单靠名称筛选会出现很多候选项。我担心自动合并把两个不同对象合成一条，想知道应该如何设置判断规则和人工复核边界。
把“疑似重复”与“确认重复”分开处理。名称相同或相近只能用于筛选候选项；确认时还要结合数据对象检查稳定字段、业务关系和使用记录。不同对象不能套用同一套匹配规则，客户、供应商和商品应分别制定字段优先级。例如，客户名称相似时，可以进一步核对统一社会信用代码、地址、联系人或历史单据；
商品名称相似时，则要核对内部编码、规格、单位、条码等字段。某个字段是否可靠，取决于企业的数据规范和系统实际记录，不能默认一个字段就足以判定重复。可将结果分为三类：字段和业务关系均吻合的“可确认项”，信息相似但证据不足的“人工复核项”，以及关键字段冲突的“保留为不同记录项”。
这样做比直接批量合并更稳妥，也方便记录谁确认了例外及原因。
我不希望旺季前只做完一轮表格清理，结果导入ERP后才发现字段映射或关联关系有问题。项目团队应该按什么顺序推进，哪些步骤不适合为了赶时间而省略？
建议按“盘点数据，确认规则，试处理，业务复核，批量清理，小批导入，流程验收，扩大导入”推进。每一步都设置负责人和通过条件；具体需要几天或几周，应依据数据量、审批链、系统能力和测试安排确定，不适合套用统一周期。
例如，若发现1.2万条商品记录，可以先用一小批候选项验证匹配规则和字段映射，再由商品负责人复核疑似重复项。这个数量只是说明流程的示例，不代表任何企业的实际项目数据，也不能据此推算固定处理效率。赶工时最不应省略的是原始数据留存、小批测试和业务验收。导入前保留原文件与处理记录；
导入后检查记录数量、关键字段、编码冲突，并抽样走一遍真实业务流程。合并、停用或恢复的具体方式要先核实ERP机制，不能仅凭导入成功提示判断清理完成。
我过去会把“导入成功”当作数据准备完成，但现在担心系统接受文件，并不代表业务人员能够正确使用数据。我想要一套更贴近实际流程的验收办法，也想知道发现异常后该由谁暂停或处理。
验收至少分为数据核对和业务验证两层。数据核对检查导入前后记录数、必填字段、编码冲突和导入错误；业务验证则抽样测试相关数据能否被实际单据和查询正确调用。检查项要按数据对象及流程设计，不能只用一个总数代替验收。例如，商品数据可抽样检查规格、单位和编码是否正确，并验证能否用于创建订单或相关库存业务；
客户数据则可检查名称、关键识别字段和历史关联是否符合业务要求。发现异常时，先暂停受影响范围的后续导入或业务使用，再由数据负责人判断是修正、重新导入还是按系统支持的方式恢复。验收记录建议写明抽样范围、发现的问题、处理人、批准人和复核结果。
是否可以回滚、合并后历史记录如何保留，必须依据具体ERP的文档或测试环境确认；如果恢复路径不清楚，应先缩小导入批次，而不是在旺季前直接扩大操作范围。
读者评论
文章把“候选记录”和“确认重复”区分开来很重要，名称相似不应直接触发合并，尤其是客户主体和商品规格有差异时。
保留原始数据、处理记录和编码映射，能让后续问题有迹可查；这比只统计删掉多少条更适合作为验收依据。
导入成功后还要检查历史单据关联和典型业务流程，文中强调的这一点能避免数据看似进系统、实际无法正常使用。
旺季前按使用频次和错误影响排序比较务实。文中的漏斗和工时数据注明是情景模拟，避免被误当成行业统计。