ERP 选型时，供应商演示里的物料、客户和订单往往整齐得像教科书；换成企业自己的资料，重复编码、单位不统一、必填项缺失和特殊流程才会浮出来。我的核心判断是：数据录入不只是上线前的准备工作，它也是一种选型测试。先用一小批有代表性的基础资料跑通关键业务，再判断系统是否适配，通常比只看功能清单更可靠。

一、先讲结论：先用数据验证系统，再决定是否选它

1. 把数据录入从“实施任务”前移到“选型验证”

很多企业把数据录入安排在采购系统之后：先签约，再整理资料，再让实施团队导入。这种顺序看似自然，却会把一些重要问题留到后期才暴露。例如，产品的必填字段是否符合业务实际、编码能否沿用、导入错误能否定位、不同部门对同一资料是否使用同一口径。

我建议把验证拆成两个阶段。选型阶段只准备足以验证关键流程的样本数据；实施阶段再扩展数据范围，完成清洗、迁移、复核和权限配置。这样既避免选型前就投入大量清洗成本，也不至于只凭供应商准备的演示资料下判断。

判断一套 ERP 是否适合，不只看它能不能“导入数据”，更要看企业能否用真实资料持续维护数据，并且让资料正确地进入业务流程。导入按钮存在，不等于字段匹配、错误处理、权限控制和后续维护都可用。

2. 选型阶段先验证四件事

• 资料能否表达业务：物料、客户、供应商、仓库、单位等对象的字段和分类是否覆盖实际需要。
• 资料能否被可靠导入：模板、字段映射、重复检查、错误反馈和批量修正是否清楚。
• 资料能否带动流程：录入的物料能否进入采购、入库、领料或销售流程，而不是只停留在档案页面。
• 资料能否长期治理：谁能新增、谁负责审核、谁能修改关键字段，系统是否留下必要的变更记录。

这四项要用同一批企业样本来测试。若每家供应商都使用不同的演示数据，比较结果就容易被演示脚本、数据复杂度和讲解方式影响。

3. 小样本的作用是暴露问题，不是代表全量迁移

选型验证样本不需要覆盖企业全部资料，但要覆盖业务差异。比如，不能只挑最常见的标准物料，还要挑有多单位换算、停用状态、替代料、批次管理或特殊采购规则的对象。一个样本是否有价值，取决于它能否触发关键判断，而不是样本数量有多大。

实操中，我会优先准备一组“最小但有区分度”的样本：少量正常资料、少量边界资料、少量已知问题资料，再配一条从业务起点到业务结果的流程。这样既能控制准备成本，也能检验系统遇到异常时是否给出可理解的反馈。

二、背景与业务场景：基础资料为什么会影响选型

1. 基础资料是业务单据能够成立的前提

ERP 中的业务单据通常不是孤立文本。采购订单要关联供应商、物料、计量单位、交货地点和价格条件；入库单要关联仓库、库位、批次或质检状态；生产领料可能还要引用 BOM、工序和替代关系。基础资料如果定义不清，单据测试结果也很难解释。

例如，同一物料在台账中出现“铝板”“铝板材”和内部简称，录入者可能把它们当作三种材料。若系统允许三条资料同时建档，后续库存和采购记录就可能被拆散；若系统强制唯一编码，却没有清晰的重复提示，导入人员又可能不知道哪条该保留。这并非单纯的录入速度问题，而是资料治理方式与企业管理习惯是否匹配的问题。

2. 同一份数据，在不同业务里会暴露不同限制

在采购场景里，物料名称和供应商信息只是起点，采购单位、最小包装量、交期、供应商料号和价格有效期也可能影响下单。在仓储场景里，仓库、库位、批次、保质期、库存状态和计量换算更关键。在生产场景里，BOM 生效日期、版本、替代料和损耗口径可能决定工单是否能正确展开。

因此，不能只拿“基础资料字段很多”判断系统强不强。字段多不一定有用，字段少也不必然不合适。真正要问的是：关键业务对象能否按企业口径表达，必须的信息是否能在正确环节维护，非必需的信息是否会增加录入负担。

3. 场景化测试比抽象问答更容易找到差异

选型会议上，问“能不能批量导入”“能不能做审批”，通常会得到肯定答复。要得到有用答案，需要把问题改成可观察的测试：给出一份包含重复编码、空字段、单位不一致和停用物料的表格，请对方现场说明系统如何识别、如何反馈、如何修正，以及修正后如何进入采购或库存流程。

这类测试的目标不是为难供应商，也不是要求所有产品采用同一设计，而是把抽象能力转成企业能够核对的操作结果。供应商若需要配置或开发，也应将范围、成本、维护责任和版本影响记录下来，而不能只留下“可以实现”的口头结论。

4. 把数据问题分成“产品限制”和“企业规则”

资料导入失败时，不应立刻认定系统不合适。原因可能是模板设置错误、源数据不规范、用户权限不足，也可能确实是产品无法支持某个必要字段或流程。选型评审要把失败原因分类，否则企业既可能把可治理的数据问题怪到系统头上，也可能把产品短板误当成上线后再处理的小问题。

我会要求每一个失败样例都留下四项记录：输入数据是什么、预期结果是什么、系统实际结果是什么、判断责任归属是什么。这个最小记录集能让项目团队复测，也能防止会议结论被“当时演示过”这样的模糊说法替代。

三、常见误区：看似在录数据，实际绕开了选型判断

1. 误区一：先把全部历史资料搬进测试环境

选型阶段就整理全部物料、客户、供应商和历史单据，容易把大量时间花在清洗旧账上，但并没有增加等比例的判断价值。很多历史资料已经停用，部分字段来源不明，另一些资料只有在特殊审计或追溯场景才有迁移必要。若此时还没有确定系统和业务范围，清理成本可能重复发生。

更稳妥的做法是先圈定验证范围：当前活跃资料、关键流程依赖资料、边界场景资料和少量历史问题资料。全量盘点可以在方案确定后继续做，但选型测试不要把“整理得足够多”当成“验证得足够好”。

2. 误区二：把“导入成功”当成“数据可用”

导入文件显示成功，最多说明系统接受了某种数据格式。它不一定证明编码没有重复、单位关系正确、必填规则合理，也不证明这条资料能正确关联业务单据。若导入后还要业务人员逐条改字段、用表格补充映射，或者由管理员直接修改数据库，实际实施成本就被藏在“成功”两个字后面。

验收导入能力至少要追问：失败记录能否定位到行和字段？错误原因是否可读？能否只重导失败记录？重复数据如何识别？导入后怎样抽样复核？这些回答应通过现场测试确认，而不是只看产品介绍材料。

3. 误区三：把编码规则当成软件设置问题

编码长度、前缀和分类段只是表面规则。更重要的是编码由谁生成、是否允许重编码、跨部门是否共用、产品变型如何区分、停用编码能否重用。如果编码规则由某个部门临时决定，却没有采购、仓储、生产和财务共同确认，系统即使支持多种编码形式，后续仍可能出现重复建档和口径争议。

编码是否带有业务含义也要谨慎。包含类别、材质、规格等信息的编码便于人工识别，但业务分类调整时可能引发大面积改码；纯流水编码稳定性较好，却需要依赖查询和属性字段识别。没有一种方式适用于所有企业，选型测试要验证系统能否支持企业定下来的治理方式，而不是替企业草率决定规则。

4. 误区四：只让 IT 或实施顾问验收

IT 团队擅长判断接口、权限和数据格式，实施顾问熟悉产品配置，但资料定义是否符合实际业务，需要业务使用者参与。采购员知道供应商料号和包装单位的例外，仓库人员知道库位和批次管理的真实执行方式，生产人员则可能掌握 BOM 变更和替代料的具体边界。

如果业务人员只在项目结束时才参与，系统里可能已经建立了大量“形式正确、业务不愿使用”的资料。测试阶段就安排实际使用者操作，观察他们能否理解字段、完成录入并处理异常，能够更早识别培训问题和流程阻力。

5. 误区五：用“系统可以定制”替代适配性判断

定制不是天然的坏事，也不是免费的万能解法。关键字段缺失、特殊审批逻辑、外部接口和历史报表都有可能需要配置或开发，但要评估后续升级、维护、测试和人员交接成本。若每个小差异都要写定制，系统可能短期满足需求，长期却形成难以维护的独有版本。

选型记录中应把需求分为“标准支持”“参数配置”“二次开发”“流程调整”四类，并标注验证状态和责任人。这样才能判断是系统与业务不匹配，还是企业需要调整现有规则，以及调整的代价是否可接受。

6. 误区六：看到字段越多，就认为越专业

字段数量不能直接代表管理能力。必填字段过多会增加录入和审核负担；字段过少又可能无法支撑追溯、质量和分析。评审时应逐个问字段的业务用途、维护时点、数据来源、填写责任和后续使用者。没有明确用途的字段，可能只是把资料维护复杂化。

对于暂时不确定是否需要的字段，可以记录为候选项，在小样本测试中验证使用价值。不要为了“以后也许用得上”而把所有字段都变成必填，更不要把供应商标准字段和企业必需字段混为一谈。

四、专业判断逻辑：从数据盘点到系统适配结论

1. 先确定要验证的业务边界

开始整理样本前，先写清楚本轮选型要判断什么。可能是单一仓库的采购入库，也可能是多组织、多仓库的生产协同；可能只需要库存和采购，也可能要覆盖销售、生产、财务。范围不同，基础资料清单和测试路径会明显不同。

我建议为每条测试路径写明业务起点、参与角色、关键资料、预期结果和失败判定。例如“新增一条采购物料，建立供应商关系，生成采购订单，完成收货，查询库存”，比“测试采购功能”更容易执行，也更容易比较不同产品。

2. 将数据分为基础资料、期初数据和历史业务数据

基础资料描述长期使用的业务对象，例如物料、客户、供应商、仓库、部门、计量单位、价格条件或 BOM。企业应根据业务范围选择，不必照搬一份通用清单。

期初数据描述切换时点的业务状态，例如库存数量和金额、应收应付余额、在制品或未结订单。需要哪些期初数据，取决于上线策略和财务、库存核对要求。

历史业务数据包括已经完成的订单、出入库记录、生产记录等。是否迁移应看审计追溯、客户服务、经营分析和查询要求；不能仅因为“旧系统里有”就默认全部迁入新系统。

这三类数据的来源、质量和责任人通常不同。把它们混成一个“ERP 数据表”，会让项目无法区分哪些是主档、哪些是切换时状态、哪些只需归档查询。

3. 建立样本矩阵，而不是只挑容易录入的数据

每个关键对象都应同时考虑正常记录和例外记录。样本矩阵可以包含常规物料、多个单位的物料、受批次管理物料、停用资料、名称重复资料、字段缺失资料以及需要替代料的生产物料。并非每家企业都要涵盖这些类型，选择标准是它们是否影响核心业务。

矩阵里的条目不必追求数量多，而要保证每一项都有明确的测试问题。没有对应问题的样本，只会增加准备和解释成本。

4. 录入前先锁定字段字典和数据规则

字段字典至少说明字段名称、业务含义、数据类型、是否必填、来源、责任人和使用场景。相同字段在不同部门可能含义不同，例如“规格”可能指采购规格、生产规格或包装规格，不先统一定义，导入模板即使列名相同，也不代表数据口径相同。

编码规则、计量单位、分类体系、状态值、日期格式和精度也要形成简单规则说明。选型阶段不必一次性制定完整的数据治理制度，但至少要把影响关键流程的规则写下来。系统无法执行的规则，或只能靠人员记忆执行的规则，都应纳入风险评估。

5. 选择录入方式时，把效率和可控性一起比较

少量资料可以人工录入，适合字段少、样本小、需要快速理解界面的情况。风险是漏填、误选和人员操作差异，因此要限定录入量，并安排另一位业务人员复核。

批量导入适合资料较多、字段结构相对稳定的场景。测试时要关注模板版本、字段映射、编码唯一性、错误行反馈、重复导入处理和部分失败后的重试方式。不要只测试一份完全干净的表格，也要加入可预期的错误样例。

接口同步适合需要持续连接其他系统或多来源数据的场景，但要额外确认数据方向、更新频率、主数据归属、失败重试、权限和接口维护责任。一次性迁移和长期同步是不同问题，不能用“有接口”笼统回答。

6. 用统一评分维度记录结果

测试不能只留下“很好用”或“基本满足”。我建议按固定维度记录每个样本的结果，并将分数与证据链接起来。一个可操作的示意评分方式是：0 分表示无法完成；1 分表示需要较多人工绕行或未承诺开发；2 分表示通过标准配置完成，但存在可接受限制；3 分表示按企业规则稳定完成，且异常可定位、可复测。

分数只是帮助团队比较，不是行业标准，也不应脱离业务重要性机械加总。对法规、审计、库存准确或生产连续性有直接影响的能力，可以设为一票否决项；对低频报表或非关键体验，则可按成本与收益权衡。

7. 对失败结果做根因归类

每次失败至少区分四种原因：源数据错误、测试操作错误、规则尚未确定、产品能力不足。若是源数据错误，记录清洗规则；若是操作问题，补充培训或流程说明；若是规则未定，安排业务负责人决策；若是产品能力不足，记录替代方案、成本和风险。

根因分类的价值在于防止“所有问题都归到实施阶段”。有些问题确实可以通过实施解决，有些需要组织先定规则，还有一些会影响系统适配性。把这几类混在一起，最终的选型比较就失去依据。

五、案例与数据观察：用一组样本识别“导得进”和“用得起来”的差别

1. 案例说明：以下是情景推演，不是客户实测数据

为了避免把假设写成真实客户案例，以下设定为一家具有采购、仓储和简单装配业务的中型企业，称为“甲企业”。企业准备比较两套 ERP，现有物料台账约 2400 条，但选型阶段只抽取 36 条物料、8 家供应商、3 个仓库和 12 条关联业务记录进行测试。

这 36 条物料不是从台账中随机抽取。样本里包括常用件、外购件、自制件、多单位物料、批次管理物料、停用物料、重复名称物料和带替代关系的物料。这样设计是为了让测试覆盖差异，而不是为了推断全量台账的错误率。

2. 测试发现一：名称相同，不等于同一资料

样本中有两条名称相近的物料，分别属于不同规格；另有两条名称不同、实际可能指向同一规格的资料。第一类如果只按名称去重，会误删有效记录；第二类如果只按编码判断，又可能漏掉重复档案。

这类情况说明，重复识别不能只依赖单一字段。企业要明确用于匹配的组合条件，例如规格、材质、图号、供应商料号或内部编码，并明确最终由谁判定合并。系统如果支持模糊匹配，也仍需业务人员确认，避免把相似资料自动合并成错误主档。

3. 测试发现二：导入成功后，单位换算仍可能错

甲企业的一个示意物料以“箱”采购、以“个”管理库存。模板中如果只导入基础单位，却没有导入换算关系，记录可能成功创建，但采购单和库存数量无法按预期对齐。此时“资料能建档”不等于“数量可核对”。

测试时应记录换算关系的维护位置、精度、是否允许修改，以及历史单据是否保留当时使用的换算口径。若采购包装可能变化，还要确认变更会影响哪些新旧单据。具体设计因企业流程而异，不能仅凭“支持多单位”就结束验证。

4. 测试发现三：缺字段是产品问题，还是源数据问题，要分开判断

某些物料缺少重量、品牌或供应商料号，如果这些字段不是业务必需项，就不应为了导入而补造数据；如果某字段是质检、追溯或采购必需项，则要明确数据来源和维护责任。系统要求字段必填，可能是在提示治理要求，也可能是限制过度，必须对照真实流程判断。

因此，甲企业给每个字段增加“是否进入本轮测试”的标记。字段分为关键必填、流程条件必填、可选维护和暂不采用四类。这样既避免把所有字段都当成同等重要，也能识别系统强制规则与企业管理规则之间的差异。

5. 一个可复核的样本观察表

下面的数字是情景模拟，旨在说明如何记录结果，不能作为行业效率或产品能力排名。正式选型应由企业用自己的数据重复测试，并保留导入文件、错误日志和流程结果。

这个表格里最值得注意的不是哪一列数字更大，而是哪些结论已经有证据、哪些仍然未验证。若替代料对企业生产连续性很重要，就不能因为基础采购流程通过而忽略未完成项；若某功能只是低频需求，也可以记录其成本后再决定是否列为关键门槛。

6. 用“总耗时”补充导入成功率

我不会只用首次导入通过率判断数据能力。更有解释力的观察包括：完成样本清洗用了多少时间、导入失败后修正用了多少时间、复核花了多少时间、业务流程是否需要额外手工补录。两个方案可能首次成功率接近，但异常定位和修复流程差异很大。

情景推演中，方案甲首次导入通过 31 条，方案乙通过 34 条；假设方案甲修正失败记录需 3 小时，方案乙需 1.5 小时，这些时间仅为演示口径，不代表任何产品实测。企业真正应测量的是“从原始文件到业务人员确认可用”的端到端耗时，并注明参与人数和任务范围。

7. 把演示承诺转成可验收事项

若供应商表示某个字段、校验或接口可以实现，我会将其写进问题清单，标注是标准能力、配置项还是开发项，并约定下一次验证材料。口头承诺不能直接计为通过；只有完成复测、明确责任和成本之后，才可以纳入方案比较。

对未完成项，至少记录影响业务、临时替代办法、预计投入、维护责任和最终确认日期。一个功能“以后能做”并不等于上线时可用，也不等于企业未来能够独立维护。

六、不同情况下的行动建议：按企业数据现状选择起步方式

1. 资料少、业务简单：先用人工样本验证关键流程

如果企业只有少量活跃物料、客户和供应商，且流程相对标准，选型阶段可以从人工录入开始。重点不是追求导入速度，而是让采购、仓库或业务人员亲自完成建档和单据引用，确认页面字段是否容易理解、错误提示是否足以指导操作。

人工测试仍然需要控制范围。建议选取正常样本和少量异常样本，并记录每次录入的字段解释、操作步骤和复核结果。样本增多后再切换批量导入测试，避免人工方式掩盖模板能力不足。

2. 台账较多、字段杂乱：先做数据画像，不急着全量清理

若现有台账有大量重复、别名、缺失和历史停用记录，先抽样了解问题分布。可以按资料类别统计记录数、空字段比例、重复编码比例、状态异常比例和来源系统，再据此估算清洗工作量。选型阶段要先确认系统能否处理关键数据结构，不必先把所有历史记录洗到完全干净。

抽样结果要说明抽样方法和样本边界。比如按最近一年活跃物料抽样，与从全部历史记录随机抽样，得到的资料质量结论可能不同。若要据此规划迁移预算，应进一步扩大样本或做全量规则扫描，不能把小样本比例直接外推为全量事实。

3. 多组织、多仓库或多业务单元：优先验证主数据归属

多组织场景最容易出现“同一资料由谁维护、哪些组织可见、哪些字段允许本地变更”的争议。测试应覆盖总部创建、分支使用、组织间复制或同步、局部停用和跨组织查询等场景。字段相同并不意味着主数据治理方式相同。

如果各组织长期使用不同编码和分类，选型前应决定是统一规则、建立映射，还是允许组织差异并通过集团层规则对齐。不同策略都可能成立，但要把权限、数据质量和报表口径的后果纳入评估。

4. 有生产和追溯要求：优先验证 BOM、批次和变更历史

制造企业不要只验证物料主档能否导入。还要测试 BOM 版本、生效日期、替代料、损耗、批次属性、质检状态和领料单位等与生产有关的资料。关键是从生产计划、工单、领料到完工或追溯查询形成一条可复核路径。

如果生产资料变化频繁，测试资料变更后的影响：旧单据是否保留原有版本，新单据是否读取新版本，谁可以审批变更，变更记录能否回查。企业可根据质量和法规要求确定审计深度，不能将所有制造企业的追溯需求设成同一等级。

5. 需要与其他系统交换数据：先明确主数据源和失败责任

多个系统都能创建客户、物料或供应商时，先判断谁是主数据源。若源头不清，接口可能只是更快地复制不一致数据。选型验证需要明确哪些字段由哪个系统维护，更新由谁触发，失败后如何补偿，重复消息如何处理，接口异常由谁监控。

一次性迁移和持续同步要分别评估。一次性迁移关注数据清洗、映射、导入和切换核对；持续同步还要考虑频率、增量规则、冲突处理、权限和运维。接口演示通过，不代表长期同步能够稳定运行。

6. 财务或审计要求高：把期初和历史数据单独立项

期初库存、应收应付、总账余额和未结单据可能需要不同的核对方式。迁移策略应由财务、业务和项目负责人共同确认，明确切换时点、余额口径、未结业务处理和差异调账责任。历史单据是否进入新系统，则要结合追溯、审计和查询要求判断。

这类场景不宜在选型阶段仅用几条样本就宣称迁移可行。样本可以验证模板和流程，但全量对账、余额核验和切换演练应在项目计划中安排，并由有相应职责的人员签字确认。

7. 项目时间紧：不要跳过验证，要减少验证范围

时间紧不代表只能看演示。更有效的压缩方式是聚焦最影响经营的两三条流程，减少低优先级模块和历史数据范围，保留关键异常样本，并提前准备统一测试文件。删掉的测试项要记录为未验证风险，不能默认为通过。

如果供应商无法在有限时间内完成某个重要场景验证，可以先通过书面方案、操作录屏、配置说明或后续试点补证，但要明确证据强度不同。重要决策不应把“安排时间不足”误写成“功能满足”。

8. 缺少专职数据团队：设立轻量责任矩阵

中小企业未必需要先成立完整的数据治理部门，但至少要为每类关键资料明确提供人、审核人和维护人。采购负责供应商和采购属性，仓储负责仓库与库存规则，生产负责 BOM 和工艺资料，财务负责核算口径，项目负责人负责跨部门冲突协调。

责任人不一定全职投入，但必须有明确的决策权限和变更流程。若资料问题长期无人认领，系统上线后就会变成“谁发现谁改”，导致权限混乱和口径漂移。

七、如何取舍：数据迁移范围、治理深度与系统适配成本

1. 全量迁移与按需迁移之间，优先选可解释的范围

全量迁移的优点是历史资料集中、查询方便，也可能支持长期分析；缺点是清洗、映射、校验和存储成本更高，错误历史资料也可能被带入新系统。按需迁移能够缩小切换范围，但旧系统或归档系统需要继续维护，查询体验可能分散。

我建议先按数据用途分层：当前业务必须使用的资料优先迁移；期初和未结业务按切换方案处理；已结历史业务根据查询、审计和追溯要求决定迁移或归档。每类数据都要有业务责任人确认，不能只由技术团队按文件大小决定。

2. 严格编码与灵活编码之间，平衡稳定性和识别效率

严格编码规则有利于唯一识别和自动校验，但规则过于复杂会提高新建资料门槛，并让分类变化牵连编码调整。较灵活的编码便于扩展，却可能降低人工辨认效率，增加对属性字段和搜索能力的依赖。

取舍时先列出编码的实际使用场景：是否被人工记忆、是否印在标签上、是否被外部伙伴引用、是否参与报表分组、是否允许长期稳定。若编码本身承担太多业务含义，分类一变就可能造成连锁改码；若编码只负责唯一标识，企业就要确保属性和检索能力足够。

3. 标准流程与定制流程之间，比较生命周期成本

标准流程通常便于升级和维护，但可能要求企业调整部分习惯；定制流程能贴近现有操作，却增加开发、测试、培训和后续维护负担。对每个差异都要追问：它是否由法规、客户合同、质量要求或竞争优势驱动？还是只因为“以前一直这么做”？

对必须保留的差异，要求供应商说明实现方式、升级影响、测试责任和替代方案。对价值有限的差异，可以考虑优化企业流程。系统选型不是把旧流程原样搬过去，而是在业务价值、管理约束和维护能力之间作出有依据的选择。

4. 数据治理投入与上线速度之间，避免两种极端

治理投入太少，重复、缺失和口径冲突会进入系统，后续修正可能影响单据和报表；治理投入过多，则可能在上线前追求“完美数据”，导致范围膨胀、项目拖延。优先级应由数据错误造成的业务后果决定，而不是由资料看起来是否整洁决定。

对影响采购、库存、生产、财务和合规的关键字段，应设定更严格的校验和责任机制；对低风险、低使用频率的历史属性，可考虑分阶段补齐。治理不是一次性清洗项目，而是上线前后持续的管理过程。

5. “可以定制”与“当前能用”之间，设定证据门槛

评审时可把能力状态分成四级：已在样本中验证、标准功能但尚未复测、需要配置或开发、当前不支持或方案未明确。只有第一类可以直接作为已验证能力；其他状态都应在决策材料中保留限制和成本。

若关键能力需要开发，至少确认范围、交付时间、费用、验收条件、后续升级责任和失败后的替代方案。无法给出这些信息时，应把不确定性视作风险，而不是按“最终能做”计入系统优势。

6. 不同优先级采用不同证据强度

对关键主数据、库存准确、财务核对和生产连续性，建议使用企业真实样本、现场操作和结果复核；对低频、低风险功能，可以接受配置说明和供应商材料作为初步证据，但需标注尚未实测。证据强度应与失败后果相称。

如果某项需求无法在选型阶段验证，可以把它设置为合同前置条件、试点验收项或阶段性上线门槛。这样比在评审会上把未知事项默认记为满足，更能保护决策质量。

八、结尾：先准备一组能暴露问题的数据，再扩大投入

1. 一周内可以启动的验证动作

1. 列出本轮选型要覆盖的业务范围，明确哪些流程是必须验证的。
2. 从现有资料中抽取一组代表性样本，覆盖常规、重复、缺失和边界情况。
3. 为关键字段标注含义、来源、必填条件和责任人，先解决口径冲突。
4. 让候选系统使用同一份数据文件和同一套测试脚本，分别验证人工录入、批量导入或接口方案。
5. 记录失败原因、修正时间、流程结果、配置或开发承诺，并安排复测。
6. 把未验证项、迁移范围、数据治理投入和维护责任写进决策记录。

2. 选型会议上可以直接问的八个问题

• 这类基础资料有哪些必填字段？必填条件能否按业务情境设置？
• 导入失败时，能否定位到具体行和字段？能否只重试失败记录？
• 系统如何识别重复编码、近似名称和跨组织重复资料？
• 计量单位、批次、效期或版本关系如何维护？变更后对旧单据有什么影响？
• 新增、审核、修改和停用资料分别由什么角色负责？变更是否可追溯？
• 测试中的功能属于标准能力、配置能力还是开发能力？费用和维护责任是什么？
• 如何验证资料导入后能够进入采购、库存、生产或财务流程？
• 若某项需求暂时不能验证，能否作为试点验收条件或上线门槛？

3. 最终判断：基础资料是选型的压力测试，不是演示道具

ERP 选型中，最有价值的数据不是数量最多的数据，而是能揭示业务差异、流程边界和治理责任的数据。用企业自己的样本测试，能够看清系统对真实字段、异常记录和日常维护的支持程度，也能帮助企业发现自身规则尚未统一的地方。

我的建议是先完成“盘点，抽样，清理，导入，跑流程，复测，评估”这一小闭环，再决定是否扩大迁移和实施范围。不要用一份干净的演示表证明系统适合，也不要把全量历史资料都整理完才开始选型。让数据成为可复核的决策证据，才是从“录得进去”走向“选得明白”的关键。

免费注册

咨询方案

扫码咨询方案