本文定位：失败复盘。它不是产品宣传稿，而是把一个常见的企业数字化问题拆成“背景—症状—方案—结果—经验”，方便你对照自己的情况判断。
一、背景：问题不是突然出现的
一个 ERP 项目原计划 8 周上线，最后拖到 14 周。复盘发现，延期的主要原因不是开发，而是数据迁移。历史 Excel 里物料重复、客户简称混乱、供应商编码缺失，库存期初也对不上。
二、关键症状：真正卡住业务的地方
最初团队低估了数据清洗，以为导入前整理两天就够。真正开始导入时，系统发现同一物料有多个名称，同一客户有不同开票主体，仓库库存和财务金额不一致。
三、落地/救火路径：先收口，再扩展
救火方法是分层清洗。高频物料和在途订单必须清干净，低频历史数据先归档；客户和供应商先统一开票主体，简称作为别名；库存期初由仓库和财务共同签字确认。
四、结果：能被管理动作验证的变化
上线后我们补了一条规则：以后新增物料、客户、供应商必须走主数据申请，不能让每个部门自由命名。
五、给同行的建议：别先追求大而全
ERP 数据迁移不是技术动作，而是管理动作。没有主数据负责人，再好的导入工具也救不了。
六、可直接照抄的检查清单
| 检查项 | 要问的问题 | 不合格信号 |
|---|---|---|
| 业务目标 | 这次项目到底要让哪个指标变好？ | 只说“提升效率”，没有具体场景 |
| 数据来源 | 关键数据现在在哪里、谁负责维护？ | 数据散在个人 Excel 和聊天记录里 |
| 责任闭环 | 异常出现后谁处理、多久复查？ | 只有提醒，没有责任人和复查机制 |
| 上线范围 | 第一阶段哪些必须做、哪些先不做？ | 一期就想覆盖所有部门 |
| 管理承接 | 上线后在哪个会议、哪个岗位使用？ | 系统上线后没人固定看 |
七、数据迁移要提前排进项目计划
ERP 项目里，数据迁移不能放到上线前一周才做。比较稳的节奏是从需求阶段就开始盘点主数据：物料、客户、供应商、仓库、BOM、价格、期初库存和未结单据分别由谁负责，哪些字段必须统一，哪些历史数据只归档不进新系统。
我们在救火时把数据分成三类：上线必需数据、上线后查询数据、只做备份数据。上线必需数据必须清到可用，例如高频物料、当前客户、供应商、在途订单和库存期初；历史查询数据可以保留原表，通过附件或归档库查询；多年以前且不会再参与业务计算的数据，不要强行导入新 ERP。
最重要的是签字机制。仓库确认数量，财务确认金额，业务确认客户和供应商，技术只负责导入和校验。没有业务签字的数据迁移，最后一定会变成技术背锅。项目计划里也要单独留出数据清洗、试导入、差异修正和最终冻结窗口，否则上线当天才发现库存对不上，任何系统都救不了。
八、数据迁移要先做“停用清单”
ERP 数据迁移失败，往往不是因为导入工具不好，而是企业不愿意决定哪些历史数据不再使用。旧系统里有重复客户、停用供应商、错误物料、历史价格、废弃仓库和多年未动的库存。全部迁进去，看似完整，实际上是把旧问题带到新系统。
救火时我们先做停用清单：超过两年无交易的客户是否停用，供应商是否合并，物料是否有替代编码，历史仓库是否关闭，库存差异是否做期初调整。每一类数据都要有业务负责人签字确认，而不是让实施顾问替企业决定。
迁移不是技术动作，而是一次主数据治理。导入前不清理，导入后就会在采购、库存、销售和财务里持续放大。
九、迁移演练至少做三轮
第一轮是结构演练，确认字段能不能导入、格式是否正确。第二轮是业务演练，抽取典型客户、物料、订单、库存，看业务人员能不能在新系统里查到并继续操作。第三轮是期初演练，模拟上线当天的库存、应收、应付、未完工单和未结订单。
每轮演练都要输出差异清单和责任人。没有演练就直接切换，问题会集中在上线当天爆发，业务团队会迅速失去信心。
十、落地前可以先问自己的五个问题
第一，当前最痛的业务动作是什么，是销售漏跟、库存不准、项目亏损、数据口径不一，还是系统没人用？如果一句话说不清，说明项目目标还需要继续收敛。第二，这个动作今天的数据在哪里，是系统里、Excel 里、微信群里，还是某个人脑子里？数据越分散，第一阶段越要小。第三，谁是这个数据的负责人，谁有权决定字段口径和流程变化？没有负责人，系统上线后也会变成无人维护的表。
第四，异常出现后谁处理，处理结果回写到哪里？很多数字化项目只做到“发现问题”，没有做到“问题被处理并复查”，价值会卡在最后一公里。第五，老板或管理层准备在哪个会议里固定使用这套系统？如果上线后没有会议承接，大家很快会回到原来的汇报方式。
这五个问题的答案，比功能清单更重要。功能清单决定开发什么，五个问题决定系统上线后有没有人用、有没有人维护、有没有管理动作跟上。
十一、适合先做小诊断的企业画像
如果你的企业已经有一些系统，但数据分散、口径不一、老板看数还要等人导表，适合先做诊断；如果你的企业还主要靠 Excel、钉钉群和人工审批，也适合先做诊断，因为这时最重要的是确认第一阶段到底该系统化哪一段。
不适合一上来做大项目的情况也很明确：目标太泛，只说“全面数字化”；内部没人能拍板；历史数据没人愿意清；业务部门只想让 IT 自己解决；老板希望一次上线解决所有问题。遇到这些情况，先做 1 到 2 周的小范围梳理，反而比直接开发更省钱。
开沿通常会把诊断结果拆成三张图：业务流程图、数据流转图、一期范围图。三张图对齐后，再决定用标准 SaaS、低代码、钉钉二开、系统集成还是定制开发。这样做慢在前面，快在后面，也能减少上线后推倒重来的概率。
补充一点：第一阶段还要提前约定复盘节奏。上线后的前四周，建议每周固定看一次使用数据、异常清单和业务反馈，把必须改的小问题快速收掉，把“以后再说”的需求放进二期池。这样既能保护一期范围，也能让业务团队看到系统是在持续服务他们，而不是上线后就没人管。
还有一个容易忽略的动作，是给二期需求设入口。业务在试运行期提出的新想法，不要马上塞回一期，也不要简单拒绝，而是记录触发场景、预期收益和影响范围。等一期稳定后，再按收益和复杂度排序处理，项目节奏会稳很多。
十二、开沿的建议
如果你看到这里，最该做的不是立刻问“做一套多少钱”，而是先把当前流程画出来：数据从哪里来，谁加工，谁决策，谁执行，结果回写到哪里。只要这条链路不清楚，系统越复杂，后期越难维护。
开沿更愿意先做小范围诊断：选一个高频场景，确认数据和责任是否能闭环，再判断适合低代码、标准 SaaS、二开还是定制。这样预算更可控，也更容易让团队真正用起来。
