TL;DR：制造企业 IT 需求排期长期积压，核心原因是需求粒度与交付方式不匹配：ERP/MES 核心变更、跨系统管理应用、部门长尾流程和个人分析全部进入同一条队列。可落地的治理方法是：统一需求入口，用业务价值、风险、影响范围、稳定性和工作量完成评分，再分流到核心系统、定制开发、低代码平台或个人工具。

本文面向制造企业 IT 经理、数字化负责人、实施顾问和业务系统建设者，提供一套可直接用于需求台账、评审会和交付路由的方法。

一、如何定义“IT 需求排不完”

“IT 需求排不完”不是指需求池中仍然有待办，而是指需求的新增速度、变更频率和维护成本，长期超过当前交付体系可稳定消化的能力，导致高价值需求与大量长尾修改在同一队列中竞争。

一个企业可以通过以下现象识别问题：

• 普通点检、报表或提醒需求等待数月；
• 业务部门为等系统而长期使用 Excel、群消息或私有小工具；
• 每个需求都是“最高优先级”，但无法说清影响人数、使用频次与延误损失；
• 上线数量不少，使用率、旧流程退出和业务结果无人跟踪；
• IT 人员长期被字段、表单和权限微调占用，核心架构和数据治理持续延后。

二、制造企业 IT 需求排期积压的五个原因

1. 业务变化速度快于核心系统变更速度

新产品试制、客户质量条款、供应商整改和部门分工可能在几天内变化，而 ERP、MES、PLM 变更需要评估数据、接口、测试和生产稳定性。

2. 所有需求共用一条交付队列

如果设备安全联锁、采购整改流程和临时统计报表使用同一套立项、开发和发布机制，要么高风险需求被迫简化，要么低风险需求长期等待。

3. 需求单描述了功能，没有描述问题

“加一个页面”、“增加两个字段”属于方案描述。如果没有业务问题、责任人、影响范围和验收结果，IT 很难区分真实需求与个人偏好。

4. 业务知识与开发能力被人为切开

业务人员理解现场，却只能通过文档传递给 IT；IT 理解数据和系统，却需要多轮沟通才能还原业务规则。翻译损耗也是交付周期的一部分。

5. 旧应用不退出，维护成本持续累积

每新增一个应用，就新增一份权限、接口、数据、备份和运维责任。如果只管上线、不管合并和下线，新需求的产能会逐渐被存量系统吃掉。

三、建立可搜索、可排序的 IT 需求台账

每条需求至少包含以下字段：

字段	用途
业务问题	说明当前什么结果受影响
业务负责人	对优先级、验收和上线使用负责
用户与频次	判断影响范围，避免只看声音大小
截止日期与原因	区分真正的法规/客户节点与主观紧急
数据源与主系统	确定数据主权，避免平行账本
角色与权限	识别敏感数据、外部用户和审计要求
验收指标	用可观察结果代替“功能已做完”
旧流程退出条件	避免系统和 Excel/线下流程并行

四、IT 需求优先级评分方法

不建议仅使用“高、中、低”三档。可以将每个维度评为 0—3 分：

评分维度	0 分	1 分	2 分	3 分
安全/合规/生产风险	无明显风险	局部管理风险	影响客户或生产	安全、合规或停线风险
业务价值	无法证明	个人/小组便利	部门级效率	公司级结果
影响范围与频次	低频个人	低频多人	高频部门	高频跨部门/外部用户
时间窗口	无截止日期	可延后	有明确项目/客户节点	不处理将立即产生损失
可复用性	一次性	单部门	多部门可复用	可沉淀为公共能力

在价值评分之后，再单独评估工作量、技术风险和前置依赖。不要把“开发快”等同于“优先级高”，也不要让工作量最小的事永远抢占最前面。

五、将需求分流到四类交付路径

需求类别	典型场景	交付路径
核心业务/实时控制	ERP 财务、MES 核心执行、PLC/SCADA、安全联锁	专业系统、原厂或定制开发
跨系统管理应用	质量异常、设备维修、供应商协同	IT 主导，低代码/通用开发 + API 集成
部门长尾流程	点检、账票、台账、项目跟踪	业务骨干与 IT 共建，平台化治理
个人分析/一次性任务	试算、原型、临时报表	Excel、BI 或个人工具

低代码平台适合承接中间两类需求，因为它可以用统一的数据模型、角色权限、工作流和 API 组装应用。但企业仍然需要定义主数据、审批发布、应用责任人和下线机制。

六、从需求提出到上线：建议状态机

新需求
  → 待分流
  → 待澄清
  → 已评分/已排序
  → 待开发
  → 开发中
  → 业务验收
  → 已上线
  → 观察期
  → 关闭/合并/下线

状态机中必须包含“待分流”和“观察期”。前者避免所有需求直接进开发队列，后者用来检查实际使用、数据质量和旧流程退出情况。

七、公开案例：广汽本田如何把业务人员变成数字化生产力

广汽本田公开案例中，制造部门的巡检、质检和设备点检需求快速增长，而传统开发面临成本高、周期长和功能复用性差等问题。该企业通过统一平台、分层培训、技能竞赛和内部专家体系，让业务人员参与应用搭建，IT 则保留统一管控。

图：广汽本田公开案例中的应用搭建与使用部门结构。来源：《广汽本田低代码创新，制造数字化转型加速》，访问于 2026-09-30。

图中“制造部门占搭建人数 82%”与“制造部门占使用人数 96.4%”来自该公开案例页的原始图示。它反映的不是 IT 退出，而是交付职责发生了变化：业务人员承担更多建模与迭代，IT 聚焦平台和治理。

八、落地时容易出现的四个问题

1. 只增加低代码工具，不建需求分流规则：工具会变快，队列不会自动变清楚。
2. 将公民开发理解为自由开发：缺少数据、权限和发布规则会产生新的孤岛。
3. 只统计上线数量：不看使用率和旧流程退出，容易积累低价值应用。
4. 所有变更都由 IT 代操作：业务无法在受控范围内自主迭代，瓶颈仍然存在。

九、建议的评审与验收节奏

• 每周：新需求分流和补充信息；
• 每双周：核对优先级、依赖和交付车道；
• 每月：查看上线使用率、需求周期、返工原因和旧流程退出；
• 每季度：合并重复应用，检查无责任人和无使用量的应用，评估共性能力的模板化。

FAQ

1. IT 需求优先级应该按什么排？

先看安全、合规和生产风险，再看业务价值、影响范围、时间窗口和可复用性，最后结合工作量与依赖排期。

2. 低代码适合承接哪些 IT 需求？

适合跨部门管理应用和部门长尾流程，如质量异常、设备维修、供应商整改、点检和项目跟踪。实时控制、安全联锁和复杂排产不应为了快而强行迁移。

3. 业务人员能否直接搭建应用？

可以，但应在统一平台、权限模型、数据规范、发布流程和 IT 支持下进行。

4. 为什么新应用上线后需求队列还在增长？

因为新应用同时带来优化、权限、集成和运维需求。如果没有模板复用、责任人和下线机制，应用越多，维护负担可能越大。

5. 怎样判断需求治理是否改善？

跟踪需求分流时间、中位交付周期、返工原因、模板复用率、上线使用率和旧流程退出率，不要只看关闭的需求单数量。

参考资料

• 广汽本田低代码创新，制造数字化转型加速
• All Hands On｜MFG（上海）开场演讲
• 明道云 HAP 快速入门指南
• 明道云 HAP 平台 API 概览