ERP选型演示里，物料可以几秒钟建档，客户也能顺利导入；真正的难题往往在演示结束之后：同一种物料在采购、仓库和财务的表格里叫法不同，计量单位不一致，关键字段没人能说清由谁维护。ERP数据录入规划的关键因此不只是“把表格填进系统”，而是先用基础资料暴露业务规则，再拿这些规则检验系统是否适配，最后通过真实样本导入和流程验收确认选型。
我判断一套ERP是否适合企业，不会只看功能清单里有没有采购、库存、销售或财务模块，而会先追问：企业用什么资料驱动这些流程？这些资料由谁定义、如何维护、会经过哪些部门？同一套功能，可能适配一种编码和审批规则，却无法自然承接另一种规则。
因此，基础资料规划要从选型开始，而不是等合同签完、实施顾问发来导入模板后才启动。企业在评估系统前，至少应盘点首期上线范围内的核心资料、关键字段、业务口径、数据来源和责任部门。盘点结果既是实施输入，也是选型时可供验证的业务样本。
我的核心判断是：系统展示能不能建一条记录，不等于系统能不能承接企业的资料规则。要验证的不是“页面上有没有这个字段”，而是这个字段能否按企业需要维护、校验、关联、授权和追溯。
基础资料与选型的衔接，可以拆成四类验证：第一，字段与分类是否能表达业务；第二，编码、单位、状态等规则是否能执行；第三，资料能否参与实际流程；第四，导入、修改、停用和追溯是否可控。每一类都应该用真实场景验证，而不是只听供应商口头承诺。
例如，系统允许维护物料的名称和规格，只能证明它能存放这两个字段。若企业需要同一物料对应多个采购单位、库存单位和换算关系，就要进一步验证单位换算的准确性、适用范围以及历史单据如何处理。字段“存在”与规则“可用”，是两件不同的事。
建议项目团队在正式比较前挑选少量、但能代表复杂业务的样本：常见记录、边界记录、容易重复的记录、需要特殊属性的记录都要有。把它们用于产品演示、导入测试、业务流程测试和评分表评审，才能把“感觉适合”转成可复核的判断。
下面的阶段投入比例是用于项目排期讨论的示意基准，不是行业统计。它表达的重点是：选型前的资料盘点不应被压缩到几乎没有时间，否则大量业务规则只能在实施后被动补充。
企业常把“ERP数据”统称为待整理的表格，结果物料主数据、库存余额、未结订单和历史单据被放进同一份导入任务。它们的用途、校验口径和上线策略都不同，混在一起容易出现责任不清，也会让项目范围失控。
这几类数据之间有依赖关系：一张期初库存记录可能需要关联物料、仓库、批次和单位；一笔未结采购订单可能还要关联供应商、付款条件和交付地址。若基础资料尚未确定，先导期初数据通常只会产生临时编码、手工映射和重复返工。
我建议从企业实际业务对象出发盘点，而不是把供应商的菜单列表直接当成数据清单。不同企业的资料范围差异很大：贸易企业可能更关注商品、客户、供应商、仓库和价格；制造企业还可能涉及物料清单、工艺路线、工作中心、替代料和批次规则；服务企业则可能需要项目、服务目录、合同和人员技能等资料。
盘点表至少要回答以下问题：资料在业务上代表什么？从哪里来？谁确认其含义？谁维护？哪些字段会被流程使用？预计有多少条？多久变化一次？上线时是否必须完整？这张表将业务概念与软件对象连接起来，是后续字段映射的基础。
| 资料对象 | 常见字段示例 | 选型时要验证的重点 | 常见责任角色 |
|---|---|---|---|
| 物料或商品 | 编码、名称、规格、分类、基本单位、状态、批次属性 | 分类层级、单位换算、批次或序列号管理、停用规则 | 采购、仓储、生产、商品管理 |
| 客户 | 客户编码、名称、税务信息、结算方式、信用属性、地址 | 多地址管理、客户分组、重复校验、信用与结算规则 | 销售、财务、客户管理 |
| 供应商 | 供应商编码、名称、供货范围、付款条件、联系人、状态 | 供应商分类、资质状态、付款信息权限、历史变更追溯 | 采购、财务、质量管理 |
| 仓库与库位 | 仓库编码、组织归属、库位、是否参与可用库存计算 | 多组织、多仓库、库位管理、库存权限和状态控制 | 仓储、物流、生产 |
| 计量单位 | 单位名称、单位组、换算关系、精度 | 换算是否有适用范围，单据和库存使用何种单位口径 | 物料管理、采购、仓储、财务 |
| 组织与人员 | 部门、岗位、员工、审批关系、所属业务单元 | 组织调整后的数据归属、权限继承、离职人员停用方式 | 人事、行政、业务负责人、IT |
这张表只是起点，不是所有ERP都必须具备同一组字段。选型阶段应把企业的关键需求标出来，再确认系统是原生支持、参数配置、扩展开发，还是需要改变业务做法。不同实现方式对应的维护成本、升级风险和实施周期并不相同。
不是盘点出来的每个字段、每条记录都必须在首期完成。首期范围要与业务流程、数据风险和切换计划绑定。对于暂时不参与首期流程的资料，可以记录为后续治理事项；但影响库存、采购、销售、生产、结算或合规追溯的关键资料，通常需要在相应流程上线前确定口径。
判断资料优先级时，我会问三个问题：没有这项资料，首期流程能否运行？错了会造成多大业务影响？上线后修正是否容易追溯？如果缺失会阻断流程、导致账实不符或形成合规风险，它就应进入首期重点清单。
在系统演示之前，先估算资料数量和质量问题的规模。比如物料约多少条，客户是否存在多套编码，供应商名称是否与付款主体一致，旧系统里是否存在停用但仍被单据引用的记录。初期估算不必精确到每一条，但要足以判断项目需要多少清洗、复核和试导时间。
以下图表用三个资料对象展示可能的清洗工作量差异。数值为情景模拟，不是任何企业的实际测量；项目组应从抽样检查、旧系统导出和业务访谈中获得自己的基线。
这种顺序看似能快速推进采购，实际把最重要的适配问题推到了实施阶段。系统选定后，项目团队常会受到合同范围、既定流程和上线时间的约束；此时发现字段不够、分类结构不合用，解决办法可能变成临时加字段、定制开发或让业务人员绕开系统。
纠偏方法不是要求选型前完成全部数据清洗，而是先把影响选择的规则盘清楚。只要能确认核心字段、编码约束、流程依赖和代表性样本，就能在选型中检验系统边界。选型前不必把每个历史记录都整理干净，但不能连企业如何定义这些记录都不知道。
供应商说系统可以增加字段，并不代表字段会自动进入查询、报表、审批、接口、权限控制和后续升级。项目团队应追问：字段能否设为必填？能否限定取值？修改后是否留痕？能否用于流程判断？批量导入时如何校验？相关功能是否需要额外开发或维护？
我的经验判断框架是把需求分成三档：系统原生支持、通过参数配置支持、需要开发或流程调整支持。第三档不一定不能接受，但需要同步评估费用、交付时间、升级影响、测试范围和长期维护责任。不能只因为演示时“做出来了”，就忽略实现方式的后续成本。
一万条记录不一定比一千条更难。若字段标准一致、主键清晰、关系简单，批量处理可能相对直接；若几百条记录混有多套编码、不同单位和不明确的组织归属，逐条确认反而更复杂。真正影响数据准备难度的，常常是规则分歧、关系依赖和确认责任，而不只是行数。
例如，物料的“采购单位”和“库存单位”如果被不同部门按不同口径维护，问题就不是单纯格式转换。需要先确认业务规则，再判断目标系统是否支持对应的单位关系。没有确认口径前，技术人员即使成功导入，也可能只是把不一致的数据搬进新系统。
编码希望“看一眼就知道类别”，是常见诉求，但把过多业务含义塞进编码，未来组织调整、产品分类变化或业务扩展时，编码规则可能变得僵硬。若编码中嵌入部门、产品线、规格、年份等多个信息，任何一项变化都可能引发旧码是否重编、报表如何兼容、历史单据是否映射等问题。
我更倾向于将编码设计成稳定识别符，把易变化的业务属性放在字段、分类或标签中管理。只有当企业确实需要特定的人工识别规则，且能证明它在跨部门和长期维护中有价值时，才把业务含义放进编码。编码规则越长，不一定越专业；更重要的是唯一、可持续、可管理。
IT擅长处理格式、去重候选、映射和批量校验，但通常无法单独决定“两个名称不同的客户是不是同一主体”“一个物料是否已停用”“某个单位换算是否符合业务”。这些判断必须由了解业务的人确认。实施方可以解释目标系统如何处理资料，却不能替企业决定业务口径。
责任应按工作性质分开：业务部门确认业务含义和数据有效性；数据管理员负责模板、格式、批次和映射记录；IT协调访问权限、接口和导入环境；供应商说明系统限制并协助测试。缺少任何一方，都容易出现“谁都处理过、但没人确认过”的资料。
历史数据是否迁移，需要回答实际业务问题：上线后是否必须在新系统查询？审计或监管是否要求可追溯？是否需要在新系统进行跨期分析？原系统能否只读保留？若把“搬得越多越好”当成完整性标准，可能把错误、重复和无用字段一并带入新系统。
更稳妥的做法是区分主数据、期初状态、未结业务和历史交易。主数据保证新流程能运行；期初状态用于切换日对账；未结业务根据流程延续要求处理；历史交易按查询、审计和成本需求决定迁移或归档。
演示数据往往很整齐，无法体现企业真正的边界情况。只拿最常见的物料、标准单位和单一组织做展示，系统看起来几乎都能用；真正的问题可能藏在特殊单位、多个仓库、停用资料、客户多地址、跨组织交易或变更权限里。
选型测试至少要加入一条复杂样本和一条异常样本，并观察系统如何提示、拒绝、修正或追溯。没有异常处理过程的演示，不能证明系统的数据治理能力，只能证明它完成了最简单的一条路径。
每个资料字段都应有业务含义。以物料为例，“名称”“规格”“型号”“类别”看起来简单，但不同部门可能把供应商描述、内部识别名称、技术参数和分类标签混在一起。项目组需要写明字段定义、格式、是否必填、维护责任人和使用场景，避免相同表头代表不同含义。
字段字典是最实用的衔接工具之一。它既能指导源数据整理，也能变成选型测试清单，还能在导入时作为映射依据。若某个字段没有明确使用场景、责任人和维护方式，应先判断是否有必要录入，避免为了“以后可能有用”增加无主数据字段。
| 字段字典内容 | 需要回答的问题 | 选型验证方法 |
|---|---|---|
| 字段名称与业务定义 | 字段记录的到底是什么，是否有歧义？ | 让不同部门分别解释，再对照系统显示和使用方式 |
| 数据类型与格式 | 文本、数字、日期、枚举或多选？长度和精度是多少？ | 测试目标系统的字段类型、精度限制和导入模板 |
| 必填与取值规则 | 哪些流程必须填写？允许哪些值？是否有默认值？ | 测试空值、非法值、边界值和默认值的系统反馈 |
| 维护部门与权限 | 谁能创建、修改、审核和停用？ | 分别用不同角色操作，检查权限和审批留痕 |
| 关联对象与使用场景 | 该字段会影响哪些单据、报表、接口和判断？ | 在真实流程中追踪字段是否传递、可查、可控 |
| 变更规则 | 字段变化时是否影响旧单据、历史统计或外部接口？ | 测试修改、停用、版本变化和历史记录呈现方式 |
选型记录不能只写“满足”或“不满足”。对每个关键需求，我建议明确记录实现方式：系统原生支持、通过参数配置实现、需要扩展开发，或通过调整企业流程来实现。这样才能评估代价，而不是把所有方案都当成同一等级的“支持”。
比如企业希望对物料设置多个分类维度，目标系统可能原生支持多维属性，也可能只支持单一树状分类，或需要开发扩展。前两者的管理方式、报表能力和维护成本不同，后者还涉及升级兼容和测试。选型评估应把这些差异写进决策记录。
最有效的验证不是逐个字段看录入页面，而是把资料放进一条业务链路中。采购业务可以从供应商和物料建档开始，经过询价、采购订单、收货和入库；销售业务可以从客户、价格和库存开始，经过订单、发货和应收处理。流程能否闭环，才能检验资料的实际价值。
测试时要观察四个节点：资料是否能被选中；字段是否自动带出或正确传递；规则冲突时系统如何反馈；资料变更后历史单据如何保持可解释。若系统录入方便，但关键属性无法传到业务单据或报表，资料规划就没有真正落地。
基础资料不是导入一次就不再变化。选型时应验证批量导入模板、错误定位方式、重复记录识别、关联字段匹配、更新策略和失败回滚。尤其要确认批量更新是覆盖、增量还是按主键更新，误操作后能否恢复，以及系统是否保留修改人和修改时间。
停用与删除也需要区分。已经被业务单据引用的资料，通常不适合直接删除；系统应以某种方式限制后续使用，同时保留历史记录的可读性。具体机制因产品不同而异，必须通过产品资料或现场测试确认，不能假设所有ERP都用同一套规则。
建议把选型评分表设计成“需求，样本，测试结果，实现方式，风险，结论”的结构。这样，参加演示的人员即使来自不同部门，也能围绕相同证据讨论，不会因为某个人觉得界面熟悉，就直接得出整体适配的结论。
| 评估维度 | 可观察证据 | 适合追问的问题 |
|---|---|---|
| 字段和分类适配 | 关键字段、分类层级、取值限制和字段权限的测试结果 | 哪些是标准能力？变更后会影响哪些流程和报表？ |
| 编码与关联 | 旧编码映射、唯一性校验、组织及主从资料关系 | 系统如何识别重复？关联失败时如何定位？ |
| 导入与维护 | 导入速度、错误提示、更新方式和回滚安排 | 模板是否版本化？能否按错误行重新导入？ |
| 权限与审计 | 创建、审核、修改、停用和历史追溯记录 | 谁能修改敏感字段？如何查询变更前后的值？ |
| 实施复杂度 | 所需配置、开发、培训、测试与持续维护工作 | 交付责任由谁承担？升级时如何验证扩展功能？ |
| 业务流程适配 | 资料在端到端流程中的选用、传递和校验结果 | 异常和边界场景是否需要线下补充操作？ |
评分可以采用企业自己的权重，但不要在缺乏业务依据时复制一套看似精确的固定分值。对某些企业，批次追溯可能是关键门槛；对另一些企业，多组织权限或单位换算更重要。权重必须反映业务影响，而不是为了让表格显得专业。
我建议至少设置四个阶段闸口：资料对象和负责人已确认；关键规则和字段字典已评审；代表性样本在候选系统中通过测试；上线前的数据验收标准已签字。每个闸口通过后再扩大范围，避免一边导入一边临时改口径。
如果某项高风险需求尚未验证，不宜用“后续再看”简单带过。应在决策记录中写清临时处理方案、影响范围、责任人、验证期限和未解决时的备选方案。这样，风险才真正可见，也能避免它在项目中途变成没人负责的问题。
第一步不是大规模清洗，而是把资料对象、来源、数量、责任人和首期范围列出来。来源可能包括旧ERP、财务软件、业务系统、电子表格、邮件附件，甚至个人维护的工作簿。对同一个对象，要记录哪个来源是权威来源，避免多份表格都被当作最终版本。
盘点表可以包含：对象名称、业务定义、来源系统、预计记录数、更新频率、首期是否必需、业务负责人、数据整理负责人、系统验证要求和当前风险。每项资料都要有“最终确认人”，否则整理人员可能只能猜测记录是否有效。
清洗通常分两类：技术清洗和业务清洗。技术清洗包括去空格、统一日期格式、规范字符、识别疑似重复等；业务清洗则包括确认记录是否有效、分类是否正确、单位如何换算、客户主体是否一致。前者可自动化程度较高，后者需要业务确认。
顺序上先约定口径，再批量处理格式。若规则尚未确认就先改表格，后续一旦发现“简称是否保留”“旧码是否沿用”或“规格字段如何拆分”有争议，已经清洗的数据可能需要重新制作。对每次变更保留原始文件和处理记录，有助于追溯和复核。
若企业需要调整编码、分类或单位，不应只在最终文件里覆盖旧值。应建立映射表，记录源系统的旧值、目标系统的新值、转换规则、确认人、确认日期和适用范围。映射记录既能解释历史数据，也能在后续接口、对账和问题排查中发挥作用。
编码变更尤其要确认引用关系。若旧编码已出现在采购单、库存记录、合同或外部接口中，简单重编码可能影响历史查询和对账。选型测试应验证系统是否有独立主键、是否支持业务编码调整，以及旧编码能否作为查询条件或别名保留。
正式导入前，先挑选一小批样本做试导。样本要覆盖常见记录和复杂记录，而非随机挑选一批“最干净”的数据。物料可包含不同计量单位、特殊规格和停用记录；客户可包含多地址、不同结算方式和疑似重复项；仓库可包含不同组织归属或权限范围。
试导的目标不是证明“文件能上传”，而是检验字段映射、关联关系、规则校验、异常提示和业务使用结果。导入成功后，应进入实际流程做验证。若试导失败，要记录失败原因是源数据问题、映射问题、系统限制还是规则未定义，不能把所有问题都归类为“数据质量差”。
导入错误至少应区分四类：格式错误、值域错误、关联错误和业务规则冲突。格式错误可以通过模板和脚本处理；值域错误要核对字段标准；关联错误要检查主数据映射和依赖顺序；业务规则冲突则需要业务负责人判断，不能只靠技术人员改数。
错误清单应保留源行号、目标字段、错误类型、处理方式和复核状态。这样能区分“已经修正”“待业务确认”和“暂不迁移”的记录。若只有一份改完后的最终文件，团队很难解释哪些记录被改过、为什么改、谁确认了结果。
正式导入之前，要明确数据截止时间、模板版本、编码规则版本、资料负责人和导入批次。否则在清洗完成后，业务部门继续改表，IT又拿着旧文件导入，就可能出现同一资料不同版本混入系统的情况。
我建议给文件和批次使用清晰的版本信息，并保留原始源文件、清洗文件、映射文件、错误清单和导入结果。重要资料可由业务负责人确认最终版本；涉及财务余额和库存期初的数据，还要按约定口径与源系统或盘点结果核对。
“导入了多少行”是必要检查，但不是充分验收。验收还应确认编码是否唯一、必填字段是否完整、资料关联是否正确、权限是否符合职责、状态是否合理，以及关键流程是否能使用这些资料完成业务操作。
验收标准要根据风险和数据规模制定。例如，高风险字段可以要求逐条核验，普通字段可以采用抽样复核；关键库存和期初余额需要对账，非关键历史描述字段则可能接受分批完善。不要为所有资料设置同一个准确率阈值，重要程度和可修复性并不相同。
下面是用于说明方法的匿名化情景模拟，不是具名客户的真实项目，也不代表行业统计。一家拥有采购、仓储、生产和销售流程的制造企业，计划在同一阶段上线物料管理、采购入库和库存管理。旧资料来自多个表格和历史系统，物料编码由不同部门分别维护。
项目初期，团队把注意力放在模块功能和总报价上。演示时，供应商使用整齐的物料样例，建档、下采购单、做入库都顺利。后来项目组抽样检查，发现部分物料的采购单位与库存单位不一致；相同规格存在多个名称；一些旧编码对应不同包装方式；仓库对批次是否必填也没有统一结论。
这些问题不是某个软件“录入页面不够好”造成的，而是选型测试没有拿到真正影响业务的资料。项目组于是暂停大规模清洗，把讨论从“哪家界面顺手”转为“系统能否支撑这些规则，以及规则由谁维护”。
团队从物料样本中挑出四类记录：常规物料、存在多种计量单位的物料、规格相近但用途不同的物料，以及已停用但仍在历史单据中出现的物料。随后逐项记录字段定义、业务来源和使用流程，而不是直接决定哪些字段搬进新系统。
比如“基本单位”由仓储和生产共同确认；采购单位及其换算关系由采购确认；批次属性由质量和仓储评估；停用规则由物料管理负责人确认。项目组还要求供应商演示同一物料从建档、采购订单到入库的字段传递，并测试错误单位和无效状态会怎样被系统处理。
项目组将关键需求记录为四类：系统原生支持、参数配置支持、需要开发、需要调整现行业务规则。比如，单位换算不仅看能否录入换算值，还要检查不同物料是否可以采用不同换算关系、业务单据是否能正确选择单位、库存余额按哪种单位统计，以及换算关系变更后如何保留历史解释。
这种记录方式让管理层看见了成本结构：有些需求可以通过规范主数据解决，有些需要业务部门统一操作方式，还有一些才涉及软件配置或开发。最终决策就不再只是比较报价，而是比较“业务适配、规则变更成本、系统实现成本和长期维护风险”。
在情景模拟中，团队先用12条代表性物料做试导，包含常见记录、单位换算、疑似重复和停用记录。试导中发现，某些记录虽然可以导入，但分类字段缺少明确口径；另一些记录需要先确定单位规则，否则导入后无法可靠地用于库存和采购流程。
这12条样本不用于推断总体问题比例，只用于验证测试设计是否能发现关键风险。若只挑12条普通记录，测试很可能全部通过，却对项目决策没有帮助。样本的价值在于覆盖风险类型，而不在于数量本身。
团队把试导记录放进采购和入库流程，核对物料能否被正确选用、采购单位和库存单位是否按规则处理、仓库是否能看到必要属性、停用资料是否被拦截，以及历史记录是否仍可查询。每发现一个问题，就回到字段定义或系统规则，而不是立即要求录入人员手工绕过。
情景模拟中的试点计划将12条样本分为三组：常规记录用于确认标准路径；复杂记录用于验证单位和属性规则；异常记录用于检查系统提示和阻断能力。试点样本数和分组是示意安排，实际项目应按资料对象、风险等级和系统环境制定。
这个情景案例的重点不是“12条样本能代表多少条数据”，而是选型阶段应拿到足够真实的规则证据。只要能识别哪些资料会阻断流程、哪些规则可能导致定制、哪些历史记录需要映射，管理层就能更早判断系统适配和实施风险。
项目组不需要在选型前完成全部物料、客户和供应商清洗，但必须能回答：核心字段是什么、不同部门如何确认、系统如何验证、错误如何处理、后续由谁维护。资料准备的成熟度，不以清洗完多少行衡量，而以关键业务规则是否可解释、可测试、可治理衡量。
如果还没有确定供应商，不要急着把所有数据洗到“看起来很干净”。先盘点首期业务对象，识别编码、字段、组织、单位、批次、权限和数据量中可能改变选型的事项。每个候选系统都用同一批样本和同一组场景测试，减少演示条件不同造成的错觉。
此阶段的交付物可以是资料对象清单、关键字段字典、代表性样本、选型问题清单和风险记录。重点不是追求文件多，而是让候选系统面对一致的问题，让决策人看到实现方式和限制。
如果合同已经签订，工作重点应转向确认实施范围、模板版本、字段定义和职责分工。先与实施团队对齐哪些内容属于标准配置，哪些需要额外开发，哪些需要企业调整规则；再用少量样本跑通导入和流程，避免直接清洗几万条记录后才发现字段映射不成立。
同时，审查合同或项目计划中的数据工作责任。模板提供、规则确认、数据整理、导入执行、异常处理和最终验收分别由谁承担，要有明确安排。口头上“双方配合”不足以处理复杂的数据问题。
上线时间紧时，最危险的做法是为了赶进度，把所有资料都降低到同一套宽松标准。更合适的方式是按业务关键性分层：先保证首期流程所需的有效资料、期初状态和未结业务；对非关键历史描述、低频对象或暂不使用的资料，评估延后治理或只读归档。
分批上线必须保留边界清单：哪些资料已完成、哪些暂缓、暂缓的业务影响是什么、谁负责、何时补齐。否则“先上线再补”很容易变成长期无人跟进的隐性缺口。
组织复杂的企业，资料治理不应只看字段，还要确认记录归属和共享范围。例如，物料是全集团共享还是各事业部独立维护？客户是否允许跨组织共用？仓库管理员能否查看其他组织的数据？单位、分类或价格规则是否存在组织差异？这些问题会直接影响系统结构和权限设计。
如果企业计划未来整合多组织，应避免各部门先自行建立互不兼容的编码体系。可先确定全局唯一标识、组织级属性和共享规则，再决定哪些字段统一、哪些字段允许组织差异。系统支持能力要通过跨组织样本测试，而不能仅凭单一部门的演示判断。
制造企业、食品、医药或其他需要批次追溯的业务，选型时应优先测试物料属性、批次规则、有效期、序列号、替代关系和追溯查询。不要只确认系统“支持批次管理”，还要模拟从采购收货到生产领料、成品入库和销售出库的追溯路径。
若追溯规则是合规或质量控制的关键要求，应由质量、生产、仓储和IT共同签署测试结果。对于不能覆盖的环节，要明确需要增加的系统控制、流程补偿或外部记录，并评估补偿方案的风险。
如果企业还不知道真实数据量和质量情况，先做分层抽样，而不是立即承诺固定清洗周期。按资料类型、部门、年份或来源系统抽取样本，观察重复、缺失、格式不一致、编码冲突和业务含义不清的情况，再估算整体清洗工时和确认工作量。
抽样结果要标明样本范围和偏差风险。例如，只检查了某个部门的当前资料，就不能推断历史记录也具有相同质量。抽样适合建立初始基线，不替代高风险资料的全量核验。
迁移更多历史数据，能让新系统保留更长时间的查询链路，但也增加清洗、映射、校验和对账工作。减少迁移范围可以缩短准备周期，却可能让跨期分析需要依赖旧系统或归档数据。取舍不应抽象讨论“完整还是不完整”，而应针对具体使用需求。
| 方案 | 适用情形 | 主要收益 | 主要代价 |
|---|---|---|---|
| 迁移全部可用历史记录 | 强依赖跨期查询，且数据结构和质量可控 | 查询集中，历史链路较完整 | 清洗和验证成本高，旧数据问题可能进入新系统 |
| 迁移未结业务与必要历史 | 关注业务连续性，不要求所有历史单据在线处理 | 兼顾上线可行性和关键流程追溯 | 要明确历史边界，并维护旧系统或归档查询方式 |
| 仅迁移基础资料与期初状态 | 首期重点是尽快启动新流程，历史可在旧系统查询 | 迁移范围较清楚，验证工作相对集中 | 跨系统查询和跨期分析需要额外安排 |
判断时要把审计、合同、客户服务、经营分析和法规要求纳入评估。若必须保留历史记录，不一定意味着所有数据都要进入新ERP；经过验证的只读归档或旧系统查询，可能是更合适的方案，但需要确认数据可访问性、保留期限和责任人。
定制开发能贴近现有操作习惯，但会带来设计、测试、文档、升级兼容和长期维护成本。流程调整可能要求员工改变习惯，却能减少系统差异和维护负担。没有哪一种天然正确，关键是区分“企业竞争力所需的差异”与“历史习惯带来的差异”。
如果需求直接关系到法规、质量、关键商业模式或不可替代的业务能力，定制可能值得评估；如果只是表格列顺序、旧命名习惯或少数人员偏好，优先考虑配置、报表调整或流程统一。决策记录应说明不定制会造成什么具体影响，避免把“现在的做法”直接等同于“必须实现的需求”。
全集团统一资料规则，便于汇总、对账和跨组织共享；但不同业务单元可能确实有不同的分类、交易条件或质量属性。过度统一会迫使部门在线下维护例外，过度分散则会让数据无法比较和整合。
较稳妥的设计通常是统一主键、核心字段定义和必要的共享规则，同时明确哪些属性允许按组织差异化维护。选型测试应使用来自不同部门的样本，验证系统是否能表达这种“核心统一、必要差异受控”的结构。
必填字段和严格值域能提升数据质量，但规则设得过死，也可能阻断合理业务。若字段只在少数特殊场景需要，强制所有记录填写可能导致临时填充、错误默认值或线下绕行。相反，完全不校验又会让错误在采购、仓储或财务环节才暴露。
我建议把校验分层：进入关键流程前必须满足的规则设为硬校验；影响质量但不必立即阻断的情况给出提示；暂时不确定的规则先记录为待治理项，并通过抽样复核或审批控制。每条强制规则都应有业务理由和责任人。
大小写、空格、日期格式和明显格式错误可以自动处理；疑似重复、名称映射和业务状态则要谨慎。自动化规则如果误把不同主体合并，修复成本可能高于人工复核；全靠人工逐条判断，又会拖慢大量常规数据处理。
适合的组合方式是先自动识别候选问题，再按置信度和风险分层：确定性高的格式问题自动修正并留痕；可能重复的记录生成候选组供业务确认；高风险资料由责任人逐条核验；低风险资料按规则抽样。自动化应减少重复劳动，不应代替关键业务判断。
不是所有字段都值得投入同样的核验成本。影响库存金额、财务结算、质量追溯和权限控制的资料，错误后果大，通常需要更严格的校验；仅用于展示或低频分析的描述字段，若能在上线后补齐，可能采用抽样或分阶段治理。
一个实用判断方法是同时评估影响、发生可能性和修复难度。错误影响大、修复困难、历史无法追溯的资料，应在上线前加强验证；错误影响有限、可逆且责任明确的事项，可以接受分批完善。具体等级由项目团队定义，不需要追求一套看似精密却无法执行的评分公式。
上线当天数据通过验收，不代表以后会一直准确。新物料、新客户、新供应商不断产生，组织和规则也会变化。若没有明确的创建、审核、修改和停用流程，新的重复记录会慢慢抵消上线前的清洗成果。
企业应为核心资料指定业务负责人和系统维护角色，规定谁能申请、谁能审核、谁能执行修改，以及哪些字段需要复核。不同资料对象的维护部门可以不同，但每个对象都应有明确的最终责任人。
持续治理不一定需要搭建复杂的数据质量平台。起步阶段可以定期检查重复编码率、必填字段完整率、无效或停用资料引用次数、未映射关联记录数和资料变更待审批数量。指标要能够触发动作，不能只作为月报上的装饰。
例如，若某资料对象的重复记录持续增加，就要追查创建权限、命名规则和审批流程；若错误主要集中在某个字段，可能需要重新定义字段口径或改善导入模板。指标的价值是定位机制问题，而非只统计“有多少条错数据”。
资料修改应保留变更前后值、修改人、时间、原因和审批信息。尤其是价格属性、付款条件、物料状态、单位关系和组织归属等关键内容，若缺少变更记录，后续出现账务差异或业务争议时，很难判断规则何时发生改变。
如果系统本身无法满足某项追溯要求，应明确采用何种补充记录方式，并评估其可执行性。不要把关键变更长期寄托在个人邮件、聊天记录或本地文件中，否则人员变动后可能失去解释链路。
新增业务单元、调整组织架构、切换供应商、改变产品分类或增加仓库时，都可能影响主数据。项目团队应规定这类变更何时需要复核字段字典、权限、映射、接口和报表，避免系统结构已经变化，资料规则仍停留在旧版本。
每次重要规则变更应同步更新文档和测试样本。若系统升级或新增模块，也要重新确认资料是否被复用、字段语义是否变化、历史数据是否仍能解释。这样，基础资料规划才不会在首次上线后失去维护。
选型和实施讨论时，可以逐项确认：业务上它代表什么？由谁定义和维护？系统如何表达？错误时如何提示和修正？变更后如何追溯？若暂时不处理，会影响哪个流程？这六个问题能把抽象需求拉回可执行的规则和责任。
若团队对某项资料无法达成一致，不要急着把争议隐藏在导入模板里。先记录争议内容、不同方案、影响范围和决策人。选型期间暴露规则分歧，通常比上线后靠补丁和手工对账来处理更可控。
如果项目刚启动，最实际的第一步不是要求各部门提交所有表格，而是选一类会影响首期业务的资料，例如物料、客户、供应商或仓库，完成一次小型盘点：找出来源、定义字段、确认责任人、抽取复杂样本、验证目标系统，再复盘流程中出现的规则问题。
这类小闭环做通后，再把方法复制到其他资料对象。它能帮助团队及时发现盘点表是否足够清晰、供应商演示是否能回答关键问题、错误清单是否可追溯，也能更准确地估算后续数据准备成本。
ERP项目里，基础资料不是选型结束后的录入附件，而是检验业务规则、系统能力和实施范围的共同载体。选型阶段盘点资料，可以提前发现字段和流程的适配边界；实施阶段按规则清洗和映射，可以减少盲目返工；上线前用试导和业务验收，可以确认资料真的可用。
因此，不必追求在选型前把所有历史数据整理到完美，也不要等系统选定后才第一次讨论资料规则。更可行的目标是：先把影响业务和选型的关键规则说清楚，用代表性样本验证，再按风险和上线范围逐步扩大清洗与导入。
今天就可以从一张盘点表开始：列出首期业务对象、资料来源、责任人、关键字段、规则疑问和系统验证方式。接着选取少量复杂样本，要求候选系统完成导入和端到端流程测试，并把原生支持、配置、开发和流程调整分别记录。
真正有效的数据录入规划，不是把更多行数据搬进ERP，而是让每条关键资料都有清楚的业务含义、可验证的系统规则和明确的维护责任。当这三件事在选型阶段已经可见，后续的数据清洗、试导入和上线验收才有可靠的依据。
读者评论
把基础资料盘点放到选型前很有必要，尤其是单位换算、字段责任和变更追溯，单看功能演示确实容易漏掉这些细节。
文中区分主数据、期初数据和历史交易数据很实用。实际迁移时按用途和截止口径拆开，能减少把所有旧记录一股脑导入的风险。
真实样本测试比只看标准演示更有说服力。建议样本覆盖重复记录、特殊属性和边界情况，并记录哪些需求需要配置或开发。
责任划分讲得比较清楚：业务确认口径，IT处理技术与导入，实施方说明系统限制。若没有明确负责人，清洗结果确实可能没人最终确认。