ERP 数据表格按时收齐，不代表系统已经具备上线条件。真正容易被忽略的是：每个字段背后的业务口径是否一致、数据之间能否相互解释、导入后是否符合实际流程。质量检查看起来发生在系统搭建之前，实际上会反向检验需求定义、字段映射和配置规则；检查得太晚，原本属于业务定义的问题就会被误判为系统故障。

一、先讲结论：质量检查不是录入后的补救，而是系统设计的验证环节

1. 数据质量影响的不只是“导入成功”

我判断 ERP 数据准备是否扎实，不会只看导入工具有没有提示成功，而会继续追问三个问题：系统能否识别这些数据，业务人员能否用它们完成流程，最终产生的库存、应收、应付或经营报表能否被业务解释。

导入成功只说明数据通过了某些格式或字段校验，不一定说明数据语义正确。例如，表格中的“单位”字段填写“箱”，系统可以接受；但如果采购部门按箱下单、仓库按件收货、销售部门又按套出库，而换算关系没有被定义，数据即使成功入库，业务流程仍可能在后续环节暴露问题。

所以，质量检查的核心不是证明表格整齐，而是验证“业务含义，数据字段，系统规则”三者是否一致。这也是为什么质量检查会影响系统搭建：数据检查中发现的异常，往往迫使项目团队重新确认字段、编码、关联关系、权限或流程配置。

2. 我会把“检查”拆成四道关口

为了避免把所有问题都推给录入人员，我通常把数据质量检查拆成四道关口。每道关口回答的问题不同，不能用一次 Excel 筛选代替全部工作。

1. 业务定义检查：字段代表什么，谁有权解释，哪些取值有效？
2. 数据内容检查：数据是否完整、准确、重复，是否符合已确认的规则？
3. 导入映射检查：来源字段是否映射到正确的系统字段，代码和单位是否转换正确？
4. 导入后业务验证：用户能否在真实业务场景中查询、审核、收发、结算或追溯？

四道关口解决的是不同层次的问题。比如“供应商名称有空格”属于内容清理；“供应商类别到底按税务属性还是采购品类分类”属于业务定义；“旧系统的供应商类型映射到了新系统的付款条件”属于字段映射；“采购订单可以创建，但无法按合同条款结算”则要在业务验证中发现。

3. 数据检查会把系统搭建中的隐性假设暴露出来

系统配置不是凭空完成的。字段是否必填、编码是否唯一、物料能否多单位管理、客户是否按区域分组、库存是否按仓库和批次管理，都依赖企业的业务规则。规则没有说清楚，实施人员只能根据访谈、旧表格或现有习惯暂时推断。

在这种情况下，数据质量检查的价值，是让推断接受真实数据的检验。假如一个字段被配置为必填，但历史数据中有相当一部分记录没有这个信息，项目团队就必须判断：是补齐数据、调整字段规则，还是重新定义业务流程。这个判断属于系统设计决策，不是单纯的数据清洗。

数据检查越早开展，越容易把问题归到正确的层级；越晚开展，越容易把业务口径问题包装成系统缺陷。不过，这并不意味着所有数据都要一次性清理到完美。项目需要按风险、用途和上线范围确定检查深度。

二、先弄清楚数据是什么：不同数据类型，检查重点不同

1. 主数据：重点是身份、编码和关系

主数据通常包括客户、供应商、物料、产品、仓库、部门、员工、科目等相对稳定的对象。它们会被多个流程重复引用，因此一条主数据的定义不一致，可能影响采购、销售、库存、财务或报表的多个环节。

检查主数据时，我会先确认“一条记录代表一个什么对象”。例如，客户档案是按法人主体建档，还是按门店建档？供应商是按开票主体建档，还是按每个供货地点分别建档？物料编码对应的是一种规格，还是一个大类？如果对象边界没定下来，重复数据检查就没有可靠标准。

随后才检查编码和关系：编码是否唯一，历史编码是否保留，名称变更是否需要记录，客户与所属区域是否对应，物料分类与计量单位是否匹配。把“名称相似”直接当作重复，或者把“名称不同”直接当作不同对象，都可能误删或漏合并。

2. 业务数据：重点是状态、时间和单据关系

订单、收货单、发货记录、付款记录等业务数据，通常带有业务状态、发生时间、来源单据和关联对象。检查这类数据，不能只看每一行是否有值，还要判断单据之间是否能串起来。

比如，订单状态显示“已完成”，但缺少对应的收货或发货记录；或者发票日期早于业务单据日期，且没有特殊原因说明。这些情况未必一定是错，但需要业务人员确认。系统可以检出逻辑异常，却不能替企业判断例外是否合理。

业务数据的迁移范围也要谨慎确定。项目可能只迁移未完成单据，也可能迁移一段时间内的历史单据，或只保留汇总余额。迁移范围不同，检查规则和验收方式也不同，不能把“所有历史记录都完整复制”当成默认目标。

3. 期初数据：重点是基准时点与勾稽关系

库存期初、应收应付余额、总账余额等数据，除了本身正确，还必须明确对应的基准时点。若库存表统计到月末，而财务余额统计到次月初，期间内又有收发业务，两个口径就不能直接对照。

期初数据需要检查总量和明细之间的关系。例如，库存明细按仓库、物料、批次展开后，汇总金额或数量是否与确认的期初总数一致；客户应收明细加总后，是否能与对应总账余额核对。发现不平时，不应简单把差额塞入一个“其他”项目，而要找到差异来源或形成经业务和财务确认的调整记录。

这类检查特别容易被压缩成“余额填进去就行”。但期初数字往往会成为上线后业务和报表的比较基线。基准时点、计量单位、含税口径或币种不一致，可能让后续核对持续出现偏差。

这张表不是一套适用于所有企业的固定分类。ERP 模块、行业和迁移范围不同，数据对象会有差异；它的作用是提醒项目团队，先确定对象和口径，再选对应校验方法。

4. 数据范围要由上线目标决定，不要盲目追求“全量”

我会把迁移范围拆成“上线必须有”“满足追溯需要”“可留在历史系统”三类。客户、供应商、物料等基础档案通常需要按上线业务范围准备；未完成订单是否迁移，要看新系统是否继续处理；多年以前的完结单据是否迁入，则要衡量查询需求、数据质量和迁移成本。

全量迁移看起来更完整，但旧数据里可能包含重复编码、废弃分类、已失效规则和缺少关键字段的记录。如果这些历史问题被原样带入新系统，项目不仅要承担清洗成本，还可能把旧口径固化为新系统的默认做法。

反过来，过度缩减迁移范围也有风险。若业务、审计或服务人员需要在系统中查询历史订单，而项目只保留汇总数据，用户可能被迫在新旧系统之间反复切换。因此，范围决策应当明确数据用途、查询期限、责任部门和可接受的追溯方式。

三、常见误区：为什么“表格没报错”仍不能证明数据可用

1. 误区一：导入成功等于数据正确

导入成功通常只能证明数据满足了工具识别的技术条件，例如字段存在、格式符合要求、必填项没有空缺。它不能自动证明每个字段的业务含义正确，也不能证明单据之间的关联完整，更不能证明结果符合企业的审批和核算逻辑。

我会把“技术导入成功”和“业务验收通过”作为两个独立状态记录。若它们被合并成一个“导入完成”，项目进度看起来更快，实际风险只是被延后到流程测试或上线后。

2. 误区二：完整性高，就代表质量高

一张表所有字段都填满，仍可能存在错误、冲突或过时信息。比如，联系人电话完整但已经失效；物料分类填写齐全但分类口径已调整；仓库名称没有空值，却把临时仓和正式仓使用同一个编码。

因此，完整性只是质量维度之一。实际检查至少需要同时考虑准确性、一致性、唯一性、有效性和可追溯性，并根据数据用途赋予不同优先级。关键交易对象的唯一性可能比描述字段的完整更重要；对期初余额而言，时点和勾稽关系可能比文本字段是否齐全更重要。

3. 误区三：所有异常都由录入人员负责

录入错误确实存在，但很多“错误”来自上游规则没有确定。例如，两个部门给同一物料使用不同简称，可能是编码规则不清；一个客户出现多个档案，可能是法人主体和门店主体的建档原则不同；同一单位字段出现“个”和“件”，也可能反映企业没有确认是否视为同一计量单位。

只要求录入人员“仔细一点”，不会解决规则缺失。有效的复盘方式是区分异常来源：规则未定义、来源数据不可靠、录入操作错误、字段映射错误、系统约束不足，或业务例外未被记录。不同原因需要不同措施。

4. 误区四：发现多少问题，就代表数据有多差

问题数量不能脱离检查口径解读。检查一万条记录和检查一百条记录，发现的问题绝对数不能直接比较；检查规则更严格后，问题数上升，也不一定意味着数据质量变差，有可能只是识别能力提高。

更有用的做法是按数据对象、问题类型、严重程度和处理状态统计。比如，必填字段缺失、编码重复、金额勾稽不平、描述字段拼写不一致，对系统上线的影响并不相同。若把它们统统合并成“错误总数”，团队很难判断先处理什么。

5. 误区五：把异常都修成系统能接受的样子

有些项目为了让导入通过，会给缺失字段填默认值，把未知分类统一塞进“其他”，或临时生成占位编码。技术上，这样可能减少报错；业务上，却可能掩盖真实问题。

默认值只有在业务含义明确、责任人确认、后续维护机制清楚时才安全。若“未知”被当作“其他”，系统报表就可能失去区分能力；如果占位编码长期保留，后续人员也许无法判断它代表真实对象还是迁移临时值。

异常处理要有原因、规则、责任人和复核状态。能补齐的补齐，能合并的按批准规则合并，确属业务例外的应保留例外说明；无法确认的记录，要进入待决清单，而不是为了通过导入而静默改写。

6. 误区六：用一套通用检查表覆盖所有模块

“必填字段是否为空、格式是否正确、有没有重复”是有用的基础检查，但不能覆盖全部模块风险。财务数据需要关注币种、期间、借贷方向和余额勾稽；库存数据可能需要关注仓库、批次、单位和可用状态；采购数据则可能要核对供应商、价格、税率与交货条件。

基础检查规则可以共用，业务规则应由模块负责人确认。采用同一份模板不等于采用同一套标准。模板可以规范记录方式，不能替代各业务领域对“什么是合理数据”的判断。

四、专业判断逻辑：从字段校验走向业务规则验证

1. 先定义“正确”，否则校验只能发现格式

我会要求每个关键字段至少有一份简明定义：字段名称、业务含义、数据类型、是否必填、允许取值、来源系统、责任部门、更新频率和特殊情况处理方式。字段字典不必一开始写得庞大，但关键字段不能只留下一个表头。

例如，“客户类别”如果只是表头，销售部门可能按行业分类，财务部门可能按账期分类，客服部门可能按服务等级分类。几种分类都可能对各自工作有用，却不能未经确认就混在同一个字段中。必要时应拆成多个字段，或确定唯一主口径并明确其他信息放在哪里。

对编码规则也要说明编码是否有业务含义。若编码由业务人员手工拼出区域、品类和年份，规则一旦变更，编码就可能过期；若编码只是稳定的唯一标识，分类变化则可以通过独立字段维护。两种设计各有适用情形，关键是团队知道编码承担什么职责。

2. 把质量维度改写成可以执行的问题

“准确、完整、一致、唯一、有效”是常见质量维度，但如果停留在词语层面，项目人员很难形成一致检查。我的做法是把每个维度转成具体判断问题，并注明检查范围和处理动作。

这些检查动作并不要求全部自动化。可以先用表格筛查格式、空值和重复，再由业务人员确认真实含义；关键在于每项规则要能被复核，异常处理不能只存在于某个人的口头说明里。

3. 校验应从单字段扩展到跨字段、跨表和流程

单字段校验可以发现日期格式错误、编码长度不符、取值不在清单内等问题。跨字段校验关注字段之间是否互相矛盾，例如记录状态为“已关闭”，但关闭日期为空；单位为“千克”，却填写了不符合企业规则的换算系数。

跨表校验则关注对象和单据能否关联。例如订单中的供应商是否存在于供应商档案，明细中的物料编码是否对应有效物料，发货记录是否能追溯至订单。此类问题常常不是某一行数据自身格式有误，而是多张表之间缺少一致的键值或映射。

最终还需要流程验证：由业务用户使用代表性数据完成一段端到端操作。只测一条“最干净”的记录，无法覆盖常见异常；只测极端异常，也不能证明日常流程顺畅。测试样本应包含高频场景、关键边界和已知例外，并记录预期结果。

4. 用风险优先级安排检查深度

不是每条记录都值得投入同样的人工复核时间。我建议从四个角度评估优先级：错误影响多大、出现概率多高、问题是否容易被发现、修复成本是否会随时间上升。

影响多流程的核心主数据、财务期初和关键库存数据，通常需要较高检查强度。描述性字段、已经封存且只用于历史查询的旧记录，可能采用抽样或分层检查。优先级不是用来放弃质量，而是让有限的复核资源先覆盖高风险对象。

下面的分值只用于演示风险排序方法，不是行业通用阈值。项目团队可以用低、中、高分级替代数字，重点是每个等级背后有一致的定义。

5. 把数据规则反向用于验证系统配置

数据检查不是单向地“把数据修到系统能收”。系统也要接受数据和业务规则的反向检验。若业务定义要求某些对象必须唯一，系统是否有适当约束？若物料存在多种单位，系统是否支持换算和记录来源？若客户有不同结算条件，流程和字段是否能表达？

这一步尤其重要，因为清洗团队可能通过人工方式把数据整理得很规整，但系统没有相应约束，后续新数据仍会重新出现同类问题。反过来，系统规则设得过严，也可能挡住合法业务例外。质量检查发现的每类问题，都应讨论它属于一次性历史清理，还是需要通过系统配置和日常维护机制长期预防。

五、一个示意案例：物料单位不一致，为什么会牵动配置和上线测试

1. 场景设定：表格只有一个“单位”字段

下面是一个用于解释问题传导的示意场景，不对应特定企业，也不代表真实项目统计。某企业准备整理物料档案，表格中有物料编码、名称、规格、采购单位和库存单位，但早期模板把单位合并成一个字段。不同部门根据自己的工作习惯，填写了“箱”“件”“套”等值。

最初的检查结果可能看起来并不严重：必填项大多填写，编码格式统一，重复行也不多。若检查只关注空值和格式，这份表格很容易被判定为“基本合格”。但采购订单、收货入库和生产领用所使用的单位并不完全相同，真正的问题藏在字段定义和换算规则中。

2. 拆解问题传导链条

如果业务人员把采购包装单位当作库存单位填写，系统可能无法准确记录实际库存数量；如果系统按基本单位管理，而导入数据没有明确换算关系，采购数量与库存数量可能无法可靠转换；如果测试只用一种单位一致的简单物料，问题可能直到真实采购或盘点时才暴露。

1. 源头问题：表格字段没有说明单位代表采购单位、库存单位还是使用单位。
2. 录入表现：不同部门按各自工作场景填值，单行格式可能完全正确。
3. 系统影响：实施团队无法确定字段映射、基本单位和换算规则。
4. 测试影响：单据测试结果可能混合了配置问题和数据解释问题。
5. 上线风险：库存数量、采购数量或领用数量需要人工换算，增加对账和操作负担。

这里的重点不是断言“单位不一致一定会导致库存错误”，而是说明：当字段语义、换算关系和流程规则未确定时，系统无法替业务团队做出正确选择。真正的整改动作应先确认业务单位模型，再决定数据整理和系统配置。

3. 处理方式：先定单位模型，再清理，再验证

我会建议团队按顺序完成四件事。第一，找采购、仓储和使用部门共同确认物料在各环节如何计量；第二，确定基本单位、可选业务单位以及换算关系由谁维护；第三，将历史表格映射到已确认的单位模型，并对无法判断的记录单独标记；第四，在测试环境中选择不同单位组合的代表物料完成采购、收货、出库和盘点验证。

如果企业实际没有多单位管理需求，也不应为了“系统功能完整”额外增加复杂配置。可行的方案可能是统一基本单位，并通过业务规则约束录入；若实际存在包装单位与库存单位转换，则需要明确换算关系和维护责任。解决方案应来自实际流程，而不是从软件字段反推业务。

4. 如何用数据观察判断清理是否有效

这个示意案例可以用几个可观察指标跟踪处理进度：单位字段未定义的记录数、需要人工确认的物料数、换算关系缺失的记录数、测试流程中单位相关异常次数，以及复核通过率。指标的目的不是做漂亮的项目汇报，而是识别风险是否真的减少。

以下数字全部为情景模拟，用来展示一类追踪方式，不是实际企业效果、行业基准或承诺值。真实项目应记录自己的基线、抽样范围和统计周期。

5. 案例中的真正教训：异常记录不是唯一观察对象

如果只统计“待处理记录减少了多少”，仍可能忽略系统是否变得更可靠。还应观察字段规则是否经过责任人确认、转换关系是否能复现、测试流程是否覆盖不同单位组合，以及新录入数据有没有受到相同规则约束。

一批历史数据清理完成，不代表数据治理完成。若新建物料仍可随意填写单位，下一次数据准备还会重复出现同样问题。成熟的处理应同时包括历史数据修正、系统规则配置、责任人培训和日常抽查机制。

六、建立可执行的检查流程：从模板准备到导入后验收

1. 第一步：确定范围、时点和责任人

开始整理前，先写清楚本次数据准备覆盖哪些模块、哪些组织、哪个时间范围，以及哪些数据不迁移。期初数据需要明确截止时点；历史单据需要定义保留范围；主数据要明确哪些对象在上线首日必须可用。

每类数据至少要明确三种责任：谁提供原始数据，谁确认业务口径，谁批准最终版本。一个人可以承担多个角色，但不能让“项目组负责”变成没有具体负责人。涉及财务、库存、客户或供应商的重要数据，最好由相应业务责任人参与确认。

2. 第二步：建立字段字典和标准模板

模板应有版本号、字段说明、格式示例、必填标记和允许值说明。不要只发一张空表让各部门自行理解。字段定义不清时，应先处理定义，再要求填报；否则收回来的数据越多，口径差异越难整理。

对于容易产生歧义的字段，可以提供正例和反例。比如日期要求使用哪种格式，编码是否允许人工改写，金额是否含税，联系人信息对应总部还是分支机构。示例不必覆盖所有情况，但要能解释最容易误读的边界。

3. 第三步：把检查拆成自动规则和人工判断

自动检查适合处理明确、可重复的规则，例如必填字段为空、日期格式不符合要求、编码重复、数值超出范围、引用对象不存在。规则越清晰，自动化越有价值；规则本身未定时，自动化只会更快地产生误判。

人工判断适合处理对象是否相同、异常是否合理、字段口径是否符合业务、历史记录是否应迁移等需要上下文的问题。有效的方式不是“全人工”或“全自动”，而是先让机器筛出可判断的问题，再把需要解释的事项交给对应责任人。

4. 第四步：分批导入，先做小样本验证

不要第一次就把全部数据导入正式环境。先选择覆盖不同业务类型、不同状态和边界情况的小批次，在测试环境验证字段映射、编码规则、关联关系和流程结果。小批次的价值不是证明全部数据都正确，而是尽早发现模板、规则和映射设计中的系统性问题。

测试样本应避免只挑最整齐的记录。可以纳入标准记录、缺少非关键字段的记录、历史编码记录、多单位记录、已关闭或部分完成的业务记录等。每种样本要对应一个测试问题，并事先写清预期结果。

小批次验证通过后，再分批处理主体数据。每一批应有明确版本、导入时间、数据范围、校验结果和回退方案。若出现大面积异常，先停止扩大导入范围，判断是个别数据问题还是规则和映射的共同缺陷。

5. 第五步：导入后做数量核对与业务抽查

导入后至少做两类验证。第一类是数量与关键字段核对，例如源记录数与目标记录数是否一致，关键编码是否存在，汇总数量和金额是否符合预期。第二类是业务场景验证，由用户在系统中完成实际操作，确认记录可以被正确查询、引用、审核和追踪。

抽样比例不宜随意套用一个固定数字。关键数据、低质量来源或高风险模块需要更深检查；稳定、规则清晰且已通过小批次验证的数据，可采用分层抽样和异常全检。抽样方案应记录总体范围、抽样方式、样本数量和判定标准，否则“抽查通过”难以复核。

6. 第六步：把问题台账做成闭环，而不是待办清单

问题台账至少包括：问题编号、数据对象、问题类型、影响范围、发现阶段、来源记录、责任人、处理方案、处理前后值、复核人和关闭状态。对于无法按期解决的事项，还要写清业务影响、临时控制方式、批准人和后续期限。

我不建议把“已修改”直接等同于“已关闭”。关闭的标准应包括修改完成、复核通过、影响范围评估完成，必要时还要更新模板或系统规则。否则，个别记录虽然修好了，同类问题仍会继续产生。

7. 设置停止条件，避免带着未知风险进入上线

项目需要提前约定哪些问题必须在上线前解决，哪些可以经过批准后延后处理。关键主数据无法识别、期初金额无法勾稽、核心流程无法完成、关键编码映射不明确，通常不适合仅以“后续再补”带过。

反之，少量不参与交易判断的历史描述字段格式问题，可能可以列为上线后优化项。前提是它们不会影响检索、报表、审计或客户服务，并且有人负责后续修复。停止条件的目的不是追求零异常，而是让团队知道哪些异常会改变上线决策。

七、不同情况下的行动建议与取舍

1. 首次上线，历史数据口径较清楚

如果企业已有稳定的编码体系、责任人明确、数据来源可靠，可以把重点放在模板标准化、自动规则校验、小批次导入和业务抽样上。不要为了展示复杂治理而重复清理已经稳定的数据；应把精力放在关键字段和关键流程验证。

这种情况下的取舍是：接受一定比例的低风险格式或描述类问题延后处理，但不能放松关键对象的唯一性、关联关系和期初核对。上线准备应保留可审计的检查记录，而非只保存最终导入文件。

2. 多部门各自维护表格，字段口径明显不一致

这类场景应先解决业务定义，而不是马上启动批量导入。先挑选影响最大的字段，组织责任部门确认对象边界、标准值和映射规则；再梳理各部门现有表格之间的差异，明确哪些值可以自动转换，哪些必须人工判定。

取舍上，项目可能需要把一部分非关键历史记录留在旧系统或归档环境中，而不是为了“全量迁移”投入不成比例的人工整理成本。但客户、供应商、物料等上线必需对象必须有清晰的识别方式和维护责任。

3. 上线期限很近，数据尚未完全清理

时间紧张时，先划分“阻断上线”“需要批准后带风险上线”“可以上线后处理”三类。判断依据应是业务影响、错误传播范围、发现难度和补救成本，而不是谁催得更急。对于无法确认的数据，不要悄悄填默认值，应明确标记、限制使用或暂缓迁移。

此时的取舍是用范围换质量：减少低价值历史数据迁移，保留必要的关键数据核对，把有限人力集中到核心交易、关键余额和高影响主数据上。不要用“先上线再说”掩盖已知的高风险问题；上线后的修复往往还要同时处理真实交易和数据清理。

4. 旧系统数据质量差，无法获得完整来源

先评估数据的用途和可信度。若记录只用于查阅，可考虑以只读归档、历史查询或分阶段迁移方式保留；若记录将继续驱动未完成业务，则需要逐条确认关键字段和关联关系。来源不明的数据不应因为“已经在旧系统里”就被视为准确。

取舍时要区分“能迁移”与“值得迁移”。迁移范围应考虑未来查询、合规要求、业务连续性和清理成本。对无法验证的历史值，可以保留来源标记和可信度说明，避免新系统用户把旧数据误认为经过确认的标准数据。

5. 业务规则仍在变化，字段定义暂时无法冻结

若规则还在讨论，应识别哪些内容会影响系统结构，哪些只是可配置参数。涉及对象关系、关键字段含义、单据状态和财务核算方式的变化，可能影响数据模型或流程设计，应尽早做决策；低影响的分类细节可以在明确变更机制后分阶段确认。

取舍的重点是避免把未决规则永久固化。可以记录当前临时口径、适用范围、批准人和复审时间，并在配置和数据模板中保留变更空间。但“暂定”不能无限期存在，需设置明确的决策节点，否则每次导入都会重复解释同一个问题。

6. 不同检查方案的成本与适用边界

质量检查没有一种方案同时做到最快、最便宜、最彻底。选择时要把一次性清理成本与上线后维护成本放在一起看。低风险字段可以采用自动校验和抽样，高风险数据要增加业务复核；全量人工检查可能过于昂贵，完全依赖系统规则又无法理解业务例外。

对多数项目而言，分层的混合检查更现实：先用自动规则筛除格式和明显关联问题，再由业务人员复核高风险异常，最后通过导入后的真实流程验证关键数据。若数据量很小、风险很高，人工全检可能更合适；若数据规模巨大且规则成熟，自动检查的投入回报可能更好。

7. 一份上线前可直接使用的核对清单

以下清单适合作为项目讨论起点。每项都应填写负责人、证据和状态；若答案为“暂不适用”，也应说明适用范围，而不是留空。

• 本次迁移的数据类别、组织范围、时间范围和排除范围是否明确？
• 关键字段的业务定义、允许值、责任部门和来源系统是否确认？
• 编码规则是否明确区分业务含义编码与稳定唯一标识？
• 主数据疑似重复项是否由对象责任人判断，而不是仅凭名称自动合并？
• 跨表引用、单据状态、日期关系和单位换算是否完成规则校验？
• 期初数据的基准时点、币种、含税口径和汇总勾稽是否经过确认？
• 导入字段映射是否经过小批次验证，并保留映射版本？
• 是否安排业务用户在系统中执行代表性端到端流程？
• 异常是否有类型、影响级别、责任人、处理记录和复核状态？
• 上线前的停止条件、风险接受人和延后事项是否书面确认？

八、结尾：先检查数据，再检查数据背后的业务假设

1. 真正影响系统搭建的，通常不是单个错字

一个错别字通常容易修正；更难处理的是字段含义不一致、对象边界不清、历史规则没有责任人、跨表关系缺少共同标识。这些问题会让系统配置建立在不同假设之上，也会让测试结果难以判断。质量检查的价值，正在于尽早把这些假设摆到台面上。

因此，我不会把数据质量工作简单理解为“上线前清洗一次”。更准确地说，它是一个验证机制：验证业务定义能否落到字段，验证数据能否支撑流程，验证系统约束能否预防重复问题。完成历史数据整理只是其中一部分，长期维护规则和责任同样重要。

2. 下一步从一类关键数据开始，而不是先造一张大而全的表

如果你正在准备 ERP 数据，不必一开始就要求所有部门同时交付所有历史表。先选一类上线必需、业务影响较高的数据，例如物料、客户或期初库存，完成字段定义、检查规则、小批次导入和业务验证，再把验证过的方法扩展到其他类别。

具体可以从三件事开始：列出本次上线必须使用的数据对象；为每个对象指定一位业务口径确认人；挑选一小批包含正常记录和边界情况的数据做端到端测试。若这三件事还没有答案，先不要把“导入模板已发出”当作数据准备已经启动。

最重要的判断是：质量检查不是为了证明数据没有问题，而是为了让问题在进入系统之前变得可见、可分类、可决策。当业务规则、数据来源和系统配置能够相互解释，ERP 搭建才有可靠的基础；当异常有明确责任与处理边界，项目才能在真实条件下做出稳妥的上线取舍。

免费注册

咨询方案

扫码咨询方案