有一种项目，叫做「永远快完成了」。 ERP 实施就是这种项目的高发重灾区。

签合同的时候顾问信誓旦旦：「三个月，最多四个月，我们做过很多类似的客户。」然后你就信了。

然后第四个月还在改需求，第八个月还在调接口，第十五个月系统上了但没人用，第二十四个月项目组解散了但问题还在，第三十六个月你换了一批人重新讨论要不要推翻重来。

这不是个案。这是国内 ERP 实施项目里极其普遍的一种死法。

为什么会这样？不是某一个人的问题，也不是某一家厂商特别烂。是有一套系统性的失败机制在运转。

今天我们把这八种方式一条一条掰开来说，看看你的项目中了几条。

---

第一种：三个月的承诺，

从一开始就是谎言

先说最根本的问题。

那个「三个月上线」的承诺，是怎么来的？是销售在投标阶段为了拿下合同报的数字，是顾问按照最理想路径估算的工期，是项目计划书里写的最乐观情况下的时间表。

它从来没有认真考虑过：你们公司的数据有多乱、你们的流程有多复杂、你们的管理层有多少时间配合、你们的 IT 团队有没有能力对接、你们的业务部门会不会抵制变化。

这些变量，在报价阶段是不存在的。销售顾问见过的是你，不是你们公司真实的运营状况。

但合同一签，三个月的承诺就变成了双方的共同幻觉——你真的以为三个月能搞定，他们真的以为用标准方案能套进去。

然后现实开始一巴掌一巴掌地打脸。

ERP 项目的工期估算，应该是在做完完整需求调研、梳理完数据现状、确认完集成范围之后再给出。

任何在这之前承诺的上线时间，都是在拍脑袋。

---

第二种：需求调研走了个过场

ERP 项目失败的原因，有一半可以追溯到需求调研阶段——那个理论上最重要、实际上最容易走形式的阶段。

标准的需求调研是什么样的？顾问来了，开几场会，各部门负责人轮流汇报一下现有流程，顾问记录，然后输出一份厚厚的需求文档，大家签字确认。

听起来很完整，问题在哪里？

问题在于，部门负责人告诉你的，是他认为应该怎么运作，或者是他想让外人看到的运作方式，而不是这家公司真实的日常操作。财务总监不会在需求会上告诉你他们有一套线下的 Excel 对账逻辑是十年前留下来的遗产，销售主管不会主动说他们的客户折扣体系复杂到连他自己都说不清，仓库主管不会提那个被大家默认使用的「临时货位」其实已经用了五年。

这些才是真正影响系统设计的细节。但它们不会出现在需求文档里，会出现在系统上线之后，以各种「这个系统不支持我们的实际操作」的投诉形式冒出来。

那个时候，改，代价极高。不改，系统就是摆设。

真正有效的需求调研，不是开会，是跟人待在一起。

跟着销售拜访客户，跟着仓库操作员在货架旁边看他们怎么实际操作，坐在财务旁边看月结的时候他们在对哪些数。

你看到的才是真的需求。

---

第三种：主数据是个烂摊子，没人想动它

如果你问 ERP 项目里最不性感但最关键的事情是什么，答案是主数据治理。

主数据是什么？是系统里所有业务数据的基础

——物料编码、客户档案、供应商信息、BOM 结构、科目体系、价格体系。

这些数据如果是乱的，系统建在上面就像在流沙上盖楼，迟早要塌。

但主数据治理是一件极其枯燥、极其费时、极其容易被忽视的工作。

为什么容易被忽视？

因为它不出现在演示 PPT 里，它不产生「哇塞」的效果，它是几百个人花几个月时间对着 Excel 表格一行一行核对、清洗、统一。

很多企业在启动 ERP 项目的时候，主数据的状态是这样的：

• 同一个供应商在系统里有三个名字
• 同一个物料因为不同时期录入有五个编码
• BOM 数据是两年前做的，早就跟实际生产对不上
• 客户信用额度不知道谁在维护，也不知道是否准确

这个摊子，没有人愿意去动。因为动了意味着要协调所有部门，要有人负责，要花时间，要承担「影响现有业务」的风险。

于是很多项目选择了最省事的做法：先迁数据，上线再说。

结果是上线第一天，系统里跑的就是脏数据，然后越跑越乱，越乱越没人信任系统，越不信任越绕过系统手工操作，然后系统里的数据就更脏。

主数据治理必须是 ERP 项目的前置条件，不是并行任务，更不是上线后再处理的事。这件事没有捷径，只有坐下来一条条处理。

---

​

第四种：业务部门全程缺席

这是国内 ERP 项目里最普遍的一种死法，没有之一。

项目启动的时候，老板开了一个全员大会，宣布 ERP 是今年的重点战略，所有部门必须配合。掌声响起，合影留念，散会。

然后实际推进过程中，业务部门的参与程度是这样的：

• 需求调研的时候派来一个最年轻的小专员，因为「主管太忙」；
• 关键决策需要业务确认的时候，邮件发出去两周没有回复；
• 系统测试阶段业务部门说「等上线了再说」，一个测试用例都没跑过；
• 上线了出了问题，业务部门开始全面投诉「这个系统根本不好用」。

与此同时，IT 部门或者项目组在里面使劲，对接顾问，写测试方案，催各部门配合，成了这个项目里最焦虑的人群。

这背后的逻辑是：业务部门没有真正的 ownership。

ERP 上线对他们来说，短期内意味着更多的学习成本、更多的操作步骤、更多的流程约束，而收益是长期的、系统性的，而且往往不直接体现在他们的 KPI 上。

他们没有动力投入。

于是你得到了一个「IT 的项目」——IT 部门花了很多时间和精力做出来的系统，业务部门用脚投票不认可，然后双方互相指责对方，项目就烂在那里。

ERP 是业务项目，不是技术项目。

它的主体应该是业务部门，IT 是支持角色。如果这个定位反过来了，项目从一开始方向就错了。

---

第五种：系统跟着业务走，把流程问题全搬进了系统

这是个很微妙的问题，很多人没意识到它是个问题。

ERP 上线的核心价值之一，是推动企业做流程梳理和优化。

通过系统的约束，把原来靠人脑、靠微信群、靠 Excel 维系的流程，变成有规则、有记录、可追溯的标准化流程。

但很多企业在实施的时候，走向了反面：

• 业务部门说「我们现在是这么操作的」，顾问就按现在的操作方式去配置系统。
• 业务部门说「我们这里有个特殊情况需要灵活处理」，顾问就加一个例外逻辑。
• 业务部门说「这一步我们不需要审批」，顾问就把审批步骤去掉。

结果是什么？你把所有现有的流程，包括那些混乱的、低效的、不合理的流程，全部固化进了系统。

上线之后，你的 ERP 完美地复现了你上线之前的混乱。

更糟糕的是，系统还让这种混乱变得更难改变。因为流程已经被代码和配置固定了，想改就得改系统，改系统要走变更流程，需要时间和成本。本来可以通过管理手段解决的流程问题，现在成了技术债。

ERP 实施是企业难得的一次「强制梳理流程」的机会。

但太多企业把这个机会浪费了，用「迁就现有操作」的方式，把一个改变的机会变成了固化的包袱。

ERP 上线之前，必须认真问自己：

哪些现有流程是值得保留的，哪些是应该借这次机会改掉的。「我们现在就是这么做的」不是一个充分的理由。

---

第六种：集成接口是个黑洞

ERP 很少是孤立存在的。它通常需要跟 WMS、MES、CRM、电商平台、财税系统、银行系统做集成。每一个接口，都是一个潜在的定时炸弹。

集成的问题，表面上看是技术问题，实质上是业务逻辑问题。

比如，ERP 里的订单状态是「已发货」，电商平台那边的状态应该同步成什么？同步的时机是什么？是实时的还是定时批量的？如果同步失败了怎么处理？

比如，ERP 里的库存单位是「箱」，WMS 里操作的是「件」，换算关系在哪里维护，谁是主数据的主系统？

比如，财税系统需要的发票数据格式，跟 ERP 能输出的格式，字段定义有出入，怎么处理？

这些问题，如果在项目初期没有每一个都明确定义清楚，等接口开发完成之后发现业务对不上，再改的代价是指数级增长的——因为两个系统都要动，两个项目组都要协调，而且改了这边可能影响那边。

更麻烦的是，集成接口出了问题，通常是两边互相甩锅。ERP 那边说「我的数据是正确的，是对方处理逻辑有问题」；另一边说「数据传过来就是乱的，不是我的问题」。然后这个问题就在两个团队的缝隙里待着，没人真正负责，一待就是几个月。

集成接口必须有详细的接口规范文档，必须明确每一个字段的业务含义、数据格式、异常处理逻辑，必须有明确的负责人。这件事不能等到开发阶段再说。

---

第七种：一口气全切，没有退路

大爆炸式上线，就是选一个日子，全公司在这一天同时切换到新系统，旧系统关闭，退路断绝。

这个策略有一定的逻辑——避免新旧系统长期并行带来的双重工作量，强制所有人用新系统，加速磨合。

但在实际操作中，大爆炸式上线是高风险操作，尤其对于业务体量稍大、流程稍复杂的企业。

原因很简单：

你不可能在上线之前把所有问题都测出来。系统在测试环境里跑得顺，上了生产环境面对真实业务量和真实操作用户，问题会以你预料不到的方式涌现出来。

如果这个时候你已经关闭了旧系统，你就只有两个选择：

咬牙在新系统里混乱地处理问题，或者紧急把旧系统重新启动（技术上往往没那么容易，而且数据已经在新系统里操作过了，两边对不上）。

某家制造企业的案例是这样的：

ERP 大爆炸上线，第一天出库单打印模板有问题，打出来的格式不对，快递公司不收。仓库被迫停止出货。这一天积压的订单，花了一周时间才处理完。客户投诉，销售离职，老板震怒，项目负责人背锅。

这还只是一个模板问题。

如果是核心业务逻辑的问题，后果可想而知。

ERP 上线应该分批次、分模块、分区域推进。先上风险相对低的模块，积累经验，验证系统稳定性，再推进核心模块。给团队时间学习，给系统时间暴露问题。

---

第八种：没有人管后续运营

这可能是八种死法里最隐蔽、也最致命的一种。

很多 ERP 项目的逻辑是：上线=项目完成。

顾问离场，项目组解散，合同履行完毕，大家各回各家。

然后系统就这么在那里跑着，没有人持续优化，没有人处理新的业务需求，没有人跟进用户反馈，没有人盯着数据质量是否在下降。

用户遇到问题，找不到人解决，就开始绕过系统。绕过了一次，就绕过第二次，渐渐地大家找到了系统之外的各种替代路径。三年之后你去看，发现系统还在跑，但系统里的数据跟实际业务早就脱节了，真正的业务是靠微信群、靠 Excel、靠人脑在支撑。

这背后有一个很现实的问题：

ERP 不是上了就一劳永逸的东西。

业务会变，产品线会变，组织架构会变，法规会变，上下游的系统会变。每一个变化，都可能需要系统做相应的调整。

如果没有人专门负责这件事，系统跟业务现实的距离就会越来越远。

更根本的问题是，很多企业没有内部的 ERP 运营能力。

实施阶段高度依赖外部顾问，顾问走了之后，内部根本没有人能维护和优化系统。这种能力的缺失，在上线之初可能感觉不到，但会随着时间推移不断放大。

ERP 上线不是终点，是起点。

你需要一个内部的系统运营团队，持续跟进用户问题、数据质量、业务变化，让系统跟业务保持同步。没有这个能力，再好的系统也会慢慢被废掉。

---

说在最后：为什么三年还没跑通？

如果你对照着这八条想了一想，发现你的项目中了三条、四条甚至更多，先别慌。

这很正常，因为这些问题不是因为你们特别倒霉，也不是因为选的厂商特别差，而是因为 ERP 实施本身就是一件极其复杂的系统工程，而国内大部分企业——不管是甲方还是乙方——对这种复杂性都还没有足够的敬畏。

甲方以为买了软件就买了管理能力，乙方以为套个标准方案就能完成实施，双方都低估了这件事，于是一起吃了苦头。

三个月上线是个美丽的谎言，但它之所以能一直被接受，是因为大家都希望它是真的。

老板希望，因为他不想花太长时间；顾问希望，因为这样能拿到合同；业务部门希望，因为他们不想被这件事拖着太久。

但现实不会因为你希望而改变。

ERP 实施是企业的一次深度体检和改造手术，做得好，体质会脱胎换骨；做得差，可能在手术台上就没了。

想清楚这件事的重量，再动手，才是对的。

阅读原文：原文链接

点晴模切ERP更多信息：https://moqie.clicksun.cn，联系电话：4001861886