几乎每个 ERP 项目的启动会上，都会有一场一模一样的争论。

一边说：资料都没理清，上什么系统？先把主数据整理完再说。

另一边说：再等下去项目就黄了，先上线，缺什么补什么。

两边都对了一半，也都错了一半。这篇文章我把这个问题拆成五步，每步给一个能当场落地的判断，最后附一张 12 条的上线前清单。

01先拆掉两个极端

第一种「全部整理好再上」，听起来最稳妥，实际最常见的结果是：项目卡在准备阶段。因为资料是会生长的——你整理完 A 产品，B 产品又来了新订单；你清完物料，工艺又改了两版。这件事没有「整理完」的那一天。

第二种「先上线缺什么补什么」，听起来最敏捷，实际最常见的结果是：把问题带进了系统。错误数据一旦被业务真实使用过，它就从「数据问题」升级成了「既成事实」——这个区别，后面第 05 节会专门讲。

所以真正的判断标准只有一句话：

这句话里有三个限定词，缺一个都会走偏：上线范围内（不是全公司）、关键资料（不是全部资料）、必须先准（不是可以先错）。

02一个水泵厂的账本

我先讲一个具体的厂，因为它把这句抽象的话讲得非常具体。

一家做了十几年的水泵厂，几万条物料。上 ERP 之前盘了一遍，发现同一个零件的密封件，居然有两个编码。怎么来的？

早期建编码的人按供应商的叫法建了一个，后来的人按图纸的叫法又建了一个。历史 BOM 挂在旧编码上，新订单开始用新编码，两套并行了好几年，谁也没觉得有问题——因为人的脑子里知道这是同一个东西。

但系统不知道。上了 ERP 之后，这两个编码会变成两笔库存、两次采购、两张报表，以及永远对不平的账。

我特别想强调这一句，因为它决定了你整理资料的姿势。如果你的整理动作只是「把编码洗一遍」，那洗完之后新订单还会长出第三个编码；只有当业务规则被定下来（一个零件只能有一个编码、新增编码谁批、旧编码什么时候停用），这件事才算真解决。

顺便说一句：几万条物料里，真正会拖住当前交付的，往往只有几十条。所以别按「几万条」去排工期，按「这几十条」去排。

03第一步：先定范围，不做大扫除

正确顺序是先定上线范围，再倒推资料，而不是先整理资料再想范围。

范围要回答三个问题：先跑哪类产品、哪些订单、涉及哪些部门。这三个问题答完，需要的资料清单基本就自动出来了。

但范围有一个硬约束，我在项目里反复强调：范围可以小，但关联不能断。

什么叫关联不能断？举三个最容易断的地方：

采购在途范围外的料还在路上，但它是给范围内订单买的。这部分不知道，上线第一天就算不出齐套。——在途单据必须一起进来

共用物料库存一个料既给 A 产品也给 B 产品。只上 A，库存怎么分？分不清就会两边抢料。——共用件要全量迁，不能按产品切

半条供应链只管到入库、不管到出货，等于把追溯砍成两段。客户一问批次，还是答不上来。——横向可以窄，纵向要到底

所以「范围」这件事的标准说法是：横向可以窄，纵向必须到底。横向窄，项目才动得起来；纵向到底，数据才连得上。

04第二步：把资料分成两类

范围定了，下一步不是「把所有资料列出来」，而是把资料分成两类——这件事一做，项目立刻能动。

第一类是必准资料，它们决定系统从哪一个真实起点开始运行：物料编码、计量单位、BOM 版本、工艺与业务规则，以及切换时点数据（库存多少、哪些采购没到、哪些工单还在生产、期初余额）。

第二类是后续资料，它们可以分批完善：停用产品（无当前业务、不涉及存货、不影响当前交易）、历史 BOM（影响历史追溯，不影响当前运行）、以及各种补充说明和分析标签。

这个分法最实用的地方，是它把「等资料」这个无限期动作，变成了「先清必准、后补后续」两个有限期动作。项目组终于有了一个可以宣布「准备完成」的时点。

但这里有一条不能松的口子：暂时不迁，不等于历史不要。

我见过一个项目，为了赶上线把历史 BOM 全丢了，两年后客户来做供应商审核，要求提供三年前的批次追溯。结果整条产线的资料要重新人工翻，翻了两个月。这笔成本当年没算进项目预算，但它确实发生了。

05第三步：分批建档，但错误零放行

这一节是全文最容易被忽略、也最容易出事的地方。

「资料可以分批建」这件事本身没错——新产品来了，按规则新增；必要信息确认后放行；用量要准、单位要准。这些都是正常的业务节奏。

但有一条底线：资料可以分批建，但错误不能先放行。

现场最爱说的一句话是：「先随便填一个，月底再改。」听起来是个务实的妥协，实际上是这个项目未来两年返工的主要来源。

为什么月底再改没用？因为已发生的业务不会变：

06第四步：导入成功 ≠ 业务跑通

这一步最典型的翻车方式是：导入工具报「成功导入 38,642 条」，项目组开香槟，一周后车间发现算不出料。

因为导入工具只验格式，不验业务。它只能告诉你「这行有 12 列、都是字符串」，不能告诉你「这个 BOM 能不能真的算出一张领料单」。

所以必须有三道校验：

01 导入前 · 测试校验字段对应对不对、关联对象有没有、余额是不是最新的。这一道验的是「数据本身对不对」。——三道里最便宜的一道，却最常被跳过

02 测试环境 · 跑真业务拿真实订单，从算料、领料一路跑到完工，中间故意造退料和补料。这一道验的是「业务能不能走通」。——跑不通的，正式环境一定也跑不通

03 正式切换 · 核对划界哪些业务留旧系统、哪些在新系统继续、未完业务怎么接。这一道验的是「两套系统交接不会漏记、不会重复」。——切换日的事故，八成出在划界不清

第三道我特别想多说一句。「哪些留旧系统、哪些新系统继续」这条线如果没画清，最常见的结果是同一张订单被记了两次，或者两张订单互相以为对方在处理。而这种错误在财务上表现为「库存对不上」，追查起来要翻几百张单据。

07第五步：责任落到岗位，不落到部门

前面五步都是技术动作，最后这一步是组织动作。它决定前面五步能不能守住。

原则是一句话：业务事实由业务责任人确认，IT 和顾问负责规则落地。

这张表最重要的一行其实是最后一行。因为前面四行只在上线期间有效，而资料是会变的——新产品、新工艺、新客户，每个月都在长。

所以「变化有人负责」这句话，要落成三条具体规则：新增谁批、修改谁审、停用谁定。三条都写下来，治理才算真的进了系统。

08上线前必过的 12 条清单

把上面五步收成一张能直接用的清单。每一条都能当场回答「是 / 否」，答「否」的就不是进度问题，是风险。

写到这里，这个问题可以收成一句话：ERP 能不能上，不取决于资料齐不齐，取决于你划的范围清不清、定的必准项准不准、留的出口堵不堵。

资料永远不会有「齐」的那一天。所以真正需要回答的问题不是「齐了吗」，而是「我这批该准的，准了吗」。

最后留一个问题：你们上次上系统，是卡在「等资料」，还是栽在「先上线」？这两个坑长得完全不一样，但事后复盘时的说法往往都是同一句——「当时资料没弄好」。

阅读原文：点击这里