为什么 MES 项目容易变成 IT 部门的独角戏
MES 是业务系统,但经常被当成 IT 项目。本文分析这个错位的原因、后果,以及如何让业务部门真正参与进来。
现象
MES 项目启动后,实际情况往往是:
- 需求调研只有 IT 和信息中心的人参加
- 业务部门说"你们定就好"
- 系统做出来了,业务部门说"这不符合我们的实际"
- 上线后使用率低,IT 天天催
IT 部门承担了不该承担的责任。
为什么会这样
数字化被贴上"技术"标签
在很多企业,凡是和"系统""软件"相关的,默认归 IT。
但 MES 的本质是业务系统——它承载的是生产管理逻辑,不是技术。
IT 部门主导立项
项目由 IT 提出、IT 推动、IT 汇报。业务部门从头到尾是被动的。
业务部门没有激励
业务部门的本职工作是完成生产任务。参与项目对他们是"额外负担",且做好了没奖励、做差了要背责任。
理性选择就是不参与。
缺少高层推动
如果项目只是 IT 部门的项目,业务部门没有动力配合。
后果
| 后果 | 说明 |
|---|---|
| 需求失真 | IT 不懂工艺细节,传递中丢失信息 |
| 数据质量差 | 业务不参与设计,不会认真维护数据 |
| 上线后推不动 | 没有业务支持,一线抵触无法化解 |
| 项目失败 IT 背锅 | 根因是组织机制问题,责任却归 IT |
怎么破
一、立项要由业务发起
理想情况:生产部门提出需求,IT 提供技术支持。
如果做不到,至少要联合立项——业务和 IT 共同作为项目发起方。
二、项目负责人由业务担任
项目经理最好是生产或运营负责人,不是 IT 负责人。
IT 提供技术资源和技术方案,但推动力来自业务。
三、把项目目标写进业务部门的考核
这是最有效的一招。
把"系统使用率""数据准确率"这类指标,写进生产部门的 KPI。
一旦和个人/部门利益挂钩,配合度立刻不一样。
四、给项目组成员减负
被抽调做项目的人,如果本职工作一点不减,他只能应付。
建议明确减免比例(比如减免 30%-50% 的日常事务)。
五、高层要真正参与
不是"出席启动会",而是定期听进展、协调跨部门问题、拍板重大决策。
最直接的体现:项目周会有高层出现,且能当场做决定。
六、让业务部门先受益
选一个业务部门最痛的场景先做,让他们很快看到好处。
先有了正面体验,后面的配合就顺了。
一个判断标准
判断一个 MES 项目会不会失败,最简单的方法是看第一次需求评审会:
| 情况 | 判断 |
|---|---|
| 会议室里大半是 IT 的人 | 危险 |
| 业务部门只来一个人,而且是"来听听" | 危险 |
| 业务部门来了多个岗位的人,且积极提问 | 健康 |
| 生产负责人在场,且参与讨论 | 健康 |
这个信号在项目第一周就能看出来。
组织结构建议
一个健康的 MES 项目组应该包含:
| 角色 | 来源 | 职责 |
|---|---|---|
| 项目发起人 | 高层 | 拍板、协调资源 |
| 项目经理 | 业务部门 | 整体推动 |
| 业务骨干 | 生产/质量/设备/仓储 | 需求、测试、推广 |
| IT 负责人 | IT | 技术方案、集成 |
| 实施方顾问 | 供应商 | 方案、配置、培训 |
| 关键用户 | 一线 | 试用、反馈 |
注意"业务骨干"要实际参与,不是挂名。
给 IT 部门的建议
如果你正在被推着主导 MES 项目:
- 主动把业务部门拉进来,宁可慢一点也要拉
- 用业务语言沟通,不要讲技术
- 把项目目标翻译成业务指标(交期达成率、库存准确率)
- 争取高层背书,让高层明确要求业务部门参与
- 不要独自承担推广责任,推广必须靠业务部门
如果业务部门始终不参与,建议暂停项目,先去解决组织问题。
硬推的结果是:花了钱,系统没人用,最后责任还是 IT 的。
组织保障是 MES 项目成败的关键前提,需要在项目启动前就解决。百华实施团队在项目启动阶段会协助明确组织架构与责任分工,[待补充:启动阶段交付物]。
这篇内容对你有帮助吗?
当前为游客态,投票按设备去重