Article
制造业数字化项目里，最贵的部分常常不是开发本身，而是把混乱流程、模糊责任和临时决定一起系统化。表面上看是“需求很多”，本质上往往是一期做太多、旧逻辑不肯断、基础数据没人收口。项目一旦这样开场，预算很容易被吃掉，但效果并不会同步变好。
发布时间
2026年4月8日
阅读时间
7 分钟
制造与工业
我这两年接触过几类工厂 ERP 重做项目，最典型的共性不是功能不够，而是老板一开始就想“一次性把问题全解决”。采购、销售、库存、生产、审批、报表全想一起上，结果项目推进到中段，团队才发现流程还没统一、旧系统数据对不上、每个部门口中的“必须功能”其实都不是同一件事。
这种情况下，预算不是花在真正提高效率的部分，而是花在反复确认、返工、兼容旧习惯和填历史坑上。很多钱不是不能花，而是没必要在第一阶段就花。
很多工厂在重做 ERP 时，第一反应是“原来有什么功能，现在也都要保留”，甚至连那些已经没人愿意用、只能靠特定员工记住操作顺序的流程，也想一比一复刻。听起来像降低迁移风险，实际是在让新系统继承旧系统最贵的包袱。
如果一个流程本来就依赖口头补充、Excel 二次加工或跨部门人工兜底，那它大概率不是应该被完整保留，而是应该被拆开看：哪些是必须保留的业务约束，哪些只是过去软件能力不够时形成的临时补丁。把补丁一起开发进去，预算会很快失真。
先区分“业务规则”与“历史习惯”，不要默认全部照搬
凡是必须靠人解释的流程，都值得先重画再开发
旧系统里的例外分支，通常不该在一期无条件保留
不少 ERP 项目卡住，不是页面没做完，而是物料、客户、供应商、价格、仓位、BOM 这些主数据根本没有统一口径。开发阶段大家会先说“系统先做，数据后面再整理”，但一到联调和上线，所有字段命名、编码规则、权限归属都会一起炸出来。
这类问题用开发时间硬扛最贵，因为每改一次数据口径，前端、接口、报表、导入逻辑都可能跟着变。更稳的做法反而很朴素：在立项早期就明确谁对哪类主数据负责，哪些编码规则必须先定，哪些历史脏数据只迁核心部分。这个动作不酷，但特别省钱。
没有数据 owner，就不要高估上线节奏
历史数据迁移应先保关键字段，不要默认全量搬家
报表口径先统一，再谈自动化，否则后面都会返工
我越来越倾向于把制造业系统项目做成“先跑通一条关键链路”的模式，比如先把销售下单到库存占用打通，或者先把采购申请到入库结算打通。只要这条链路能被真实使用，后面的扩展才有判断依据。相比一上来做全模块，这种方式更容易看清哪些功能真有价值，哪些只是会议里听起来重要。
一期范围收窄，并不等于做得小气，而是把预算用在验证组织是否真的愿意按新方式协作。系统项目最大的风险从来不是代码写不出来，而是上线后大家还是回到原来的表格和群聊。先把一个闭环做成，让团队愿意切换，后续预算反而更好花。
ERP 项目里最浪费预算的，通常是旧流程照搬、例外逻辑过度保留和一期范围失控。
主数据治理如果没人负责，开发越快，后期返工通常越贵。
先打通一个关键业务闭环，比一次性铺满所有模块更稳，也更容易看见真实回报。