对“实施”这两个字的理解，大多数人差不多—— 选型、蓝图、配置、测试、培训、上线，一条龙走完，系统能正常跑，就叫实施成功。

项目启动时，每个人都在说同一套话：

• 要打通业财一体；

• 要统一集团管控平台；

• 要夯实数字化基础。

方案评审会上，PPT 一页页过，流程很漂亮，架构很先进，领导点头，供应商保证，项目组也觉得“就按这个干没问题”。

直到这个集团 ERP 真正落地、上线、跑了一阵之后，会慢慢意识到一件非常扎心的事：

原来我们口中的“实施”，很多时候只是“把系统按时上线”。

 而真正要命的那部分

—— 怎么改组织习惯、怎么收拾历史烂账、怎么统一算账方式、怎么落集团管控逻辑，几乎没人真正准备好。

这一篇，就不谈技术细节，也不聊产品功能，

只把这次集团项目给我的几个后知后觉的经验总结说清楚：

ERP 实施，究竟在实施什么、为什么集团项目格外容易翻车？

 1.ERP 实施的本质，不是“上了系统”

集团 ERP 项目有个很大的误区：

• 立项时讲的是“业财一体、集团管控、数字化转型”；

• 真正推进时，落地到一句话：“原来的系统换成 ERP。”

但 ERP 真正改变的，是三件事：

1. 账怎么记？ 业务发生在哪儿记、按什么维度记、谁有权改、能追溯到多细。

2. 权责怎么划？ 谁有权限下单、审批、调价、跨公司对账、调拨资产。

3. 规则怎么执行？ 预算约束怎样兑现，风控怎么前置，数据标准谁说了算。

以前是：

• 各子公司各记各的账，各有一套系统、一堆 Excel；

• 集团层面做的是“汇总、纠偏、拍脑袋”；

现在变成：

• 全集团用同一套科目、同一套组织模型、同一份主数据；

• 每一笔业务从“发生那一刻起”，就被固化在统一规则里。

这才是 ERP 实施的本质： 

不是“软件替换”，是“集团从此只能按这一套方式活”。

你一旦从这个角度看，就会明白：

真正的难点，从来不是技术难题，而是—— 谁愿意放弃原来的“小自由”，接受一套统一、可追责的游戏规则。

---

2.集团项目最难的，不是功能

做集团 ERP，和做单体公司最大的不同是：

你面对的，不是一个“公司”，而是一群习惯各自为政的“小王国”。

1）所有分公司都说“我们很特殊”

统一 BOM？

• 制造子公司说：我们工艺复杂，没法统一。

统一价格逻辑？

• 贸易公司说：我们按项目做生意，必须灵活。

统一科目体系、费用归集？

• 区域公司说：我们当地税务口径不一样，要保留现有习惯。

每一家都有理由，每一家都能举出很多“历史原因”。

 如果项目组没有强有力的主线，ERP 很容易变成一个“所有人都妥协一半，最后谁都不满意”的怪物。

实际体会是：

集团 ERP 项目的关键，不是“怎样满足所有人”， 而是“哪些事情可以差异化，哪些事情必须集团一刀切”。

财务科目、主数据编码、基础组织架构、结算规则、风险控制点

—— 这些如果不统一，集团层面永远只能做“事后算总账”，做不了“过程管控”。

2）各条线的“隐形博弈”，才是真正的风险点

你能明显感觉到几股力量在博弈：

• 财务线：希望系统“管得紧”，一切都要有单据、有审批、有凭证；

• 业务线：希望系统“别太烦”，能下单、能出货、能签单就行；

• IT：希望逻辑清晰、架构统一、能稳定维护；

• 子公司老板：希望集团看得见大方向，看不太清细节。

如果项目经理和业务负责人没有看懂这个局，很容易陷进一种状态：

表面在做需求梳理，实际上在帮不同势力之间“打补丁”。

做完这个项目之后，我反过来总结一句：

集团 ERP 真正实施的，是“集团治理模式”

—— ERP 不是简单做业务流程，而是在固化：集团到底想管到哪一层、放到哪一层。

这件事不给答案，项目就永远在来回拉扯。

 3.集团 ERP 实施，踩坑最多的地方

做项目之前，你会以为最难的是功能、有多少模块； 

做完之后，你会发现真正让项目掉坑的，是下面这四个点。

1）主数据：大家都觉得“以后再规范”

编码规则、物料分类、客户/供应商档案、计量单位、组织结构……

所有人都知道这些是“基础”，但一到项目推进，最常听到的一句话就是：

“先跑起来，后面再慢慢规范。”

为什么会这样？

因为短期看，规范主数据既费时间，又不直接产出 KPI：

• 业务觉得：我现在单子都忙不过来，你让我停下来对编码？

• 财务觉得：历史烂账那么多，真要梳理一遍，精力根本不够；

• 项目组觉得：上线时间已经被压得很死，谁都不想再加一个“拖进度”的动作。

于是就有了最典型的结果：

• 同一件物料，五种叫法、十种编码，按部门、按工厂、按历史系统各自为政；

• 客户在不同子公司被以不同方式登记：有的按法人，有的按项目，有的按联系人；

• 组织结构调整之后，系统里的组织树没人及时维护，实际业务和系统映射严重脱节。

往深里说一句：

主数据乱的本质，是集团不愿为“统一标准”付一次性代价，只愿意让每个公司继续沿用自己的小习惯。

短期看，好像没什么大事，系统照样能跑； 长期看，后果有三层：

1. 集团层面永远做不出一套真正可对比的分析： 存货结构分析，做不到； 客户集中度、跨公司交叉的真实贡献，做不准； 品类盈利能力、区域维度的横向对比，都充满噪音。

2. 任何“数字化决策”都变成了“基于一堆脏数据的决策”。 决策层嘴上说“我们基于数据”，心里其实清楚： “这数据能看看趋势，不能太较真。”

3. 没人真为脏数据负责： 项目组说：上线前给你们时间清洗过，是你们没做好； 业务说：那会儿就那么匆忙搞了一下，现在早就变了； 集团说：反正大家报上来的数字，总归有个大概。

最后就变成那句最无奈的话： 

“系统在跑，但没人敢 100% 信系统里的数据。”

2）流程设计：只考虑“理想路径”

ERP 方案阶段，流程图往往画得很漂亮：

先下销售订单 → 再生成采购/生产 → 再入库 → 再出库 → 再结算。

看上去规范、干净、有条理。

问题在于：真实的集团业务，恰恰是被各种“例外”堆出来的。

最常见的例如：

• 先发货后补单：老客户催得急，单子先走，再补手续；

• 先收钱后发货、跨公司抬头：一个集团大客户，财务政策复杂，只能折中处理；

• 项目类打包报价：材料、人工、服务打在一个总价里，成本却散落在 N 个公司、N 张单据中间。

---

如果这些现实中的“脏场景”在实施阶段没有被一条条摊开讨论，系统上线之后通常只有两条路：

1. 硬塞进“理想流程”里： 每次处理一个例外，都要走一串极其别扭的操作； 业务觉得“这不是在用系统，是在被系统折磨”。

2. 干脆绕过系统： 真正复杂的场景继续用 Excel、邮件、OA、甚至微信解决； 事后为了对得上账，再在 ERP 里“补几笔看起来像那么回事的业务”。

第一种路，带来的是使用体验极差、上线后抱怨连连； 

第二种路，直接把 ERP 变成了“事后录入系统”，所有实时的过程信息，全部死在系统外。

深入一点说：

流程设计如果只覆盖“标准场景”，那做出来的系统就只是一套“考试答案”，而不是一套“在野外活得下去的规则”。

真正的难度在于：

• 哪些例外必须被堵死（例如严重违背风控的做法）；

• 哪些例外需要被“合法化”为标准流程分支；

• 哪些例外可以保留，但要被标记、记录、可追溯。

这都是实施阶段应该认真谈、认真记的东西，而不是上线之后再让用户“自己想办法”。

3）权限与职责：谁能看见、谁能改

集团 ERP 实施过程中，有一个所有人都不愿正面谈，但又绕不过去的话题：

透明度和控制力。

几股典型的诉求：

• 财务希望：集团能看清子公司细账，科目、余额、明细随时 drill-down；

• 子公司希望：集团只看汇总，别天天在细节上“遥控指挥”；

• 业务希望：流程别太复杂，不要每个单据都被卡在审批上；

• 集团管理层希望： 订单、项目、库存、资金随时能往下钻； 一旦有异常，可以快速定位到人和动作。

---

如果项目组在权限设计上只是“照抄现有组织架构 + 默认习惯”，不敢触碰这些博弈，最后通常会得到一个四不像的局面：

• 要看的人看不到： 集团想看具体项目毛利，发现缺权限或者数据口径乱； 审计想查一条业务链，发现关键环节不透明。

• 不该改的人随便能改： 某些部门在系统里有很大操作空间，想“事后补救”非常容易； 出了问题，日志一查，发现一堆人都有权限，追责追不下去。

• 真出事的时候，很难查清楚链路： 谁改了单价？谁变更了结算对象？中间有没有跳过批准？ 系统里虽然有记录，但权限体系一团乱，很难说“这是制度问题还是人钻空子”。

本质上，权限设计是在回答一个更深的问题：

集团到底要把“看得到”与“改得动”的边界画在哪里？

不敢在项目阶段把这条线画清楚，系统上线后，就只会在暗处延续原来的灰区：

• 表面上大家都说“以后按系统来”；

• 实际上该绕系统的照绕，该口头拍板的照样口头拍。

4）变更管理：所有人都在变，只有系统没变

集团 ERP 项目周期往往不短： 一年是“正常水平”，两三年一点都不夸张。

问题在于：

业务和组织的变化节奏，往往比系统快得多。

项目周期内，通常会发生这些事：

• 组织调整、业务重组、事业部拆分或合并；

• 新业务模式冒出来（比如从卖产品变成卖服务、卖方案、做平台）；

• 收购了一两家新公司，或者剥离了某块老业务。

如果一开始没有设计好“变更机制”，ERP 系统会很快滑向这样一种状态：

• 小改动：靠 IT 不停打 patch，加字段、加配置、加报表；

• 大调整：没人敢动核心模型，只好在系统外围搭 Excel、外挂、小工具；

• 新业务：因为“暂时不好建模”，只能先在系统外跑一套，年底再想办法“合进去”。

​

---

做到这个阶段，ERP 的状态就非常微妙：

业务不敢完全依赖，IT 不敢大改，集团又舍不得换，只能维持着一个“半废不活”的状态。

更深层的问题是：

• 谁有权发起“体系级调整”？是 IT？是财务？是业务线？还是必须集团层拍板？

• 每一次组织/业务的大变更，系统里有没有“标准动作”（比如必须重新评估组织模型、主数据、流程、报表）？

• 项目结束之后，谁来扛“持续演进”的责任，而不是所有事情都仍旧归到“实施商”和“最早那拨项目组的人”头上？

如果 ERP 项目只有“上线时的项目团队”，而没有“长期的产品负责人和演进机制”，那它的命运几乎是注定的：

• 第一年还挺积极，大家觉得“终于上系统了”；

• 第二年开始抱怨“系统跟不上业务”；

• 第三年开始讨论“我们要不要再上一个新系统”。

不是 ERP 不行，而是一开始没人认真设计“怎么跟着业务一起变”。

5.做完这个项目之后，我对好实施商的定义变了

以前看实施商，看的是：

• 模块熟不熟；

• 行业做得多不多；

• 报表能不能做漂亮。

做完集团项目之后，我发现： 真正重要的，是他们能不能站在“集团治理”的视角和你对话。

一个靠谱的实施团队，至少要能帮你回答这些问题：

• 哪些地方可以因地制宜，哪些地方必须集团一刀切？

• 当前这套流程设计，会导致哪些权力发生变化？

• 这套主数据体系，3 年后是否还能撑得住集团扩张？

• 未来要做预算管控、业财一体，今天哪些字段必须打好底子？

同样，一个真正成熟的 ERP 项目经理，也不只是会管进度、管里程碑，而是：

敢在项目初期，就把那些“早晚要撕破脸的问题”，摆在桌面上讲清楚。

——集团到底想统一到什么程度；

 ——哪些灰色空间、特批逻辑，未来要不要继续存在； 

——哪些部门要为这套新规则承担持续责任。

这些没谈清，后面越“实施”，越是在给旧秩序打补丁。

 

6.写在最后

做完这个集团 ERP 项目之后，我对“实施”这两个字的理解，变成一句话：

实施不是“把系统做出来”，而是“把一套规则真正跑起来”。

系统选得再好，如果只是跑在 IT 机房里，那叫“部署”； 流程画得再漂亮，如果业务照旧在 Excel 里，那叫“演示”； 只有当：

• 业务、财务、供应链都绕不开这套系统；

• 管理层开始用同一套数据说话；

• 任何人想“走老路”，都会感觉比走新路更费劲——

那一刻，才可以说：

这个集团 ERP，算是真正“实施”了。

如果你现在正准备上 ERP、或者正在 ERP 项目里被折磨， 至少可以问自己三个问题：

1. 我们到底在统一什么？

2. 谁会因为这套系统失去一部分“自由”？

3. 项目结束那一天，我们的决策方式，会不会真的不一样？

阅读原文​

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