Article
很多制造企业一说要重做 ERP，会议很快就会变成“把所有想补的功能先列出来”。看起来很积极，实际却容易把项目带偏。因为 ERP 真正难的地方，往往不是少几个按钮，也不是报表样式不够全，而是排产、仓库、采购、财务、质检这些环节到底谁负责什么、哪一步以哪个系统为准、哪些动作必须在线闭环、哪些只需要留痕。系统边界没先定清，功能列得越多，后面越容易互相打架。
发布时间
2026年4月16日
阅读时间
7 分钟
制造与工业
我接触过一些制造业数字化项目，前期讨论最热闹的时候，通常不是在讲流程责任，而是在疯狂补需求：生产要更多状态、仓库要更多打印、采购要更多提醒、老板要更多看板。每一项单看都合理，但只要没人先把系统边界讲清楚，这些需求最后很容易堆成一个谁都不满意的混合体。
ERP 不是把所有部门诉求都塞进同一个界面就算升级成功。更现实的做法，是先判断这次重做到底要解决哪几个核心矛盾：是订单到排产断链，还是库存口径不一致，还是采购、仓库和财务之间长期靠 Excel 对账。先把边界定住，功能才知道该往哪里长。
工厂里最常见的混乱，不是没有流程，而是同一份业务事实被多个地方重复维护。订单在 ERP 一套状态，车间白板一套状态，仓库 Excel 又是一套状态，财务月底再手工调一次。等大家开始重做系统时，如果不先明确哪些数据以 ERP 为主、哪些由外围系统承接、哪些只做同步展示，后面每加一个功能都可能加出新的口径冲突。
所以我更建议在列功能前，先画一张很朴素的责任图：订单主数据归谁、库存变动谁确认、排产结果谁维护、财务凭证谁最终认定。只要“谁是主、谁是辅、谁只读”没定，项目很容易在评审时看起来完整，上线后却一直靠人工解释。
先定义主数据归属，不要默认所有模块都能改同一份数据
区分主业务系统、协同系统和只读看板，别全部混成一个层级
功能放在哪个端口，应该服从责任归属，而不是谁声音大
项目里经常会出现一种需求：这个也想自动，那个也想补提醒，再加几个审批、几张报表、几种导出。表面上是在补能力，实质上常常是在试图用功能弥补边界混乱。比如库存口径不一致，于是每个部门都想多一张对账表；排产规则总在变，于是要求系统支持大量手工覆盖；采购和仓库责任没拆开，于是流程里到处都是重复确认。
这类需求不是完全不能做，但如果根因没处理，功能只会越补越厚，系统却越来越难解释。与其在一期里疯狂补例外，不如先追问一句：这个功能是在解决真实高频场景，还是在给原本就没理顺的责任关系打补丁？很多钱，就是这样在“看起来很必要”的补丁里花掉的。
先区分高频核心场景和低频例外场景，再决定要不要系统化
如果一个需求主要服务于“事后解释”，通常要先回头看边界问题
ERP 一期更适合固化主流程，不适合吞掉所有管理焦虑
制造业 ERP 重做最怕“大而全一期”。订单、排产、采购、库存、质检、设备、财务、老板看板一起推，听起来完整，实际每个模块都牵涉不同口径和旧习惯。如果底层边界还没理顺，一次全上通常只会把历史问题数字化，而不是解决问题。
我更倾向于先选一条责任清晰、能直接影响协同效率的主链路，比如订单到排产，或者采购到入库。先把状态定义、角色动作、异常处理和数据口径跑顺，再决定下一条链路怎么接。这样虽然一期看起来没那么“宏大”，但项目会更像在建立可持续的系统，而不是做一套新的复杂表单。
工厂重做 ERP 时，先定系统边界，往往比先列功能清单更关键。
很多看似必须补的功能，其实是在替责任不清和口径冲突背锅。
一期先跑通一条责任清晰的主链路，通常比追求“大而全”更稳。