267_东北某大型企业集团MES生产执行系统信息系统项目范围管理

ONEPSOFT | 软考学习知识库

---

2024 年 6 月，为打通集团旗下多家工厂的生产数据孤岛、提升制造执行透明度，我所在公司中标东北某大型企业集团 MES 生产执行系统项目。建设单位为该制造集团信息化管理部，合同额 1520.46 万元，工期 15 个月，我任乙方项目经理，团队 19 人，下设需求组 3 人、开发组 9 人、集成组 3 人、测试组 2 人、等保与实施 2 人。系统需覆盖集团三家核心工厂的排产、工单、质检、设备采集闭环，技术栈采用低代码平台搭建业务表单、微服务网关统一鉴权、OceanBase 承载生产主数据、RocketMQ 解耦产线消息。项目难点在于第三方厂商交付质量参差导致集成测试反复返工、多家外部单位联调使进度同步与责任界面复杂、涉密与敏感数据较多须按等保三级要求同步建设。

鉴于本项目厂商杂、工厂多、涉密重，我深刻认识到：范围管理是项目成功的基础，必须清晰界定 " 做什么 " 与 " 不做什么 "，才能有效防止范围蔓延。本文按题目三个子问题分节论述我的做法。

一、如何进行需求收集及采用的启发技术

所谓收集需求，指的是确定、记录并管理干系人需要和需求的过程，其作用是为定义产品范围和项目范围奠定基础。我采用访谈、问卷调查与原型法。鉴于三家工厂工艺差异大，我用原型快速验证排产逻辑，并针对涉密数据需求单独访谈保密办，明确哪些字段须脱敏、哪些须物理隔离。

访谈保密办时我们才知，部分工艺参数属国家秘密级，连字段名都不能明文存储。这条需求直接重塑了范围——凡涉密的必须脱敏且物理隔离，我们把它写进范围说明书最高优先级，任何功能不得与之冲突。保密办的访谈还让我们提前识别了 " 涉外厂区的工艺参数 " 这条高敏感线，直接把它从需求里单列最高保护级，避免后期被动。需求收集阶段定下的 " 涉密最高优先级 "，在后来每次变更评审时都成了第一道筛子，任何触碰它的需求直接否，省去了大量无谓讨论。原型迭代中，排产逻辑三家工厂各说各话，我用原型把 " 按订单、按设备、按班组 " 三种排法都跑一遍，让厂长们对着真实界面选，最终统一到 " 按订单驱动、设备维度展示 "，避免了需求发散。为摸清质量痛点，我用帕累托图统计历史集成缺陷的分布，发现 " 接口字段缺失 " 与 " 协议不一致 " 两类合计占七成，其中 " 协议不一致 " 里又以两家老厂的自研协议占比最高，据此把这两家的适配列为最高优先级，资源精准投放。帕累托图还帮我们说服了厂长：起初有人坚持 " 所有接口都做 "，我把缺陷分布图往会议桌一放，七成问题集中在两类，资源自然该优先砸向这两类，对方当即认同，用数据争范围比凭经验省力得多。问卷调查里一线班组长最在意 " 质检上报别太麻烦 " 和 " 别让系统比手写还慢 "，我们据此把质检页做成极简三步、把性能写进需求硬指标，后来这两条都成了范围确认时最被盯的项。最终形成需求文件并通过评审，从源头框定 " 该做哪些 "。需求跟踪矩阵把每条需求映射到设计与测试，后续任何变动都能顺着行定位，改动范围清清楚楚。

二、如何创建 WBS 及其在范围管理中的作用

所谓创建 WBS，指的是将可交付成果和项目工作分解为较小、更易于管理的组件的过程，其作用在于提供结构化视图、界定工作包边界。我采用分解技术遵循 100% 原则，带领团队把项目拆为 " 排产引擎 "" 工单管理 "" 质检追溯 "" 等保三级建设 "" 系统集成 " 五个一级分支，逐层细化至工作包，并配套 WBS 词典明确每个包的验收标准与负责人。

拆分时质检追溯曾想做到每件成品，我认为那超出制造执行范畴且涉密数据爆炸，经与保密办确认定为 " 批次级追溯 "，既满足等保又守住边界。针对厂商交付质量参差，我在 WBS 词典中写入每个包的验收门槛，并配套质量审计计划——对每个厂商工作包做准入审计，代码与接口不达标不许合入主干。质量审计也真发挥了作用：一家厂商的工单接口首次审计就不达标，字段缺失三成，我据词典驳回其合入，逼其返工，避免了脏数据进主干。WBS 在范围管理中的作用有三：一是作为确认范围的对照基线，验收时逐包勾对；二是把等保三级作为独立分支前置建设，而非事后补丁，从结构上锁死涉密边界；三是让三家工厂的对接任务可分配、可追踪，谁家的产线谁认领。WBS 词典里连 " 排产引擎包的验收以三工厂排法一致为准 " 都写进去，后来三家工厂谁都没法说自己特殊。等保三级分支下我们又拆出 " 数据脱敏 "" 访问控制 "" 审计日志 " 三个包，把涉密红线拆成可验收的硬条。等保三级与排产引擎平级设置后，安全团队每次评审先过等保包再谈功能，范围里的涉密边界再没被含糊过，这也呼应了我对多工厂项目的 " 求同存异 " 判断。可以说，WBS 把 " 做且只做必需的工作 " 从一个口号变成了可执行的清单。

三、如何进行范围确认与控制及防止范围蔓延

所谓确认范围，指的是正式验收已完成项目可交付成果的过程；所谓控制范围，指的是监督项目和产品的范围状态、管理范围基准变更的过程，二者共同防止范围蔓延。确认时我组织各方对照 WBS 词典检查，并用统计抽样从海量工单中抽验数据准确性，避免全量核不过来又防漏检。我们定为每里程碑抽验五百条工单，既看得见整体吻合度又不至于核到天亮。统计抽样有次真查出某工厂工单与设备数据吻合度仅八成，我们回溯到对应采集工作包，发现是网关丢包，当场补采，没让脏数据流到质检；抽样我们还按工厂分桶，哪家吻合度低就重点回溯哪家，三家工厂在 " 谁的数据更干净 " 上较上了劲，反倒把质量整体抬了上去。抽样不是走过场，是范围质量的探头。控制范围我严立变更闸门，任何新增功能或数据源须走评审。控制范围的闸门我们也设了分级：动基准的走 CCB，不动基准的小调整由我终审，既严又活，没让厂商觉得处处被卡。

第 10 个月，某工厂提出把 " 供应链协同排程 " 也纳入系统，我评估其超出制造执行基准且会触发等保范围扩张，经评审否决、纳入二期，守住了红线。质量审计中还发现一家厂商偷偷扩大了接口调用范围，我据 WBS 词典当场驳回超出部分，并记入其交付评价。等保边界上，我把 " 生产数据不出工厂内网 " 写进范围基准，任何想上云跨厂的请求一律否；保密办曾提议 " 先上云跑通再迁回 "，我据基准否掉，坚持本地私有化部署，涉密红线一旦松口就再也收不回。正是这套 " 词典对照加抽样核验加审计把关 " 的组合，让范围在十五个月的长周期里始终没跑偏。

经过 15 个月建设，设备在线率由 83% 提升至 98.5%，数据自动核验比例由 42% 提升至 91%，平均业务办理时长由 3.5 个工作日压缩至 0.8 个工作日，系统顺利通过终验。回顾全程，范围管理是防失控的护栏：需求收集用帕累托图抓住要害、WBS 用质量审计卡住厂商、确认控制用统计抽样与闸门防蔓延，三管齐下让 MES 真正成了集团智能制造的底座。另一个反思是，多工厂项目的范围管理要 " 求同存异 "：把三家的共性做成统一包，把差异留在配置而非代码，既守住边界又不扼杀个性，WBS 第一层就把 " 共性引擎 " 和 " 工厂适配 " 分开，是这个项目最对的一笔。等保边界的教训是，它必须写进 WBS 第一层而非藏在细节里，否则容易被 " 先上线再补 " 的呼声冲淡。下次我会把涉密红线在开工第一天就立起来，并让保密办签字共认。我也将 " 帕累托抓重点加质量审计卡厂商 " 的组合沉淀进组织过程资产，后续同类制造项目直接复用，少踩了很多集成返工的坑。把范围管住，制造执行的透明度才能真正转化为效益，而不是又一座数据孤岛。