3. 制造运营需求调研与业务蓝图设计

制造运营项目最容易失败的阶段,往往不是编码或配置,而是需求调研。FactoryTalk 这类 MES/MOM 平台本身能力很强,但若访谈时只听到“我们要上系统”“要能追溯”“要实时看板”这类笼统诉求,后续蓝图必然反复返工。本节聚焦一件事:如何用结构化访谈把生产、质量、设备、物料四类角色的真实业务,转化为可评审、可交付的业务蓝图与需求规格说明书(SRS)。

先分清四类角色的关注点差异

访谈不是拿着同一份问卷问所有人。生产关心工单执行与节拍,质量关心检验判定与不合格处置,设备关心状态与维保,物料关心收发存与齐套。若用同一套问题,得到的答案会互相矛盾。正确做法是先按角色建立“关注维度—典型问题—期望输出”的映射,再进入现场。

四类角色访谈关注点与蓝图映射 生产 • 工单下发与派工方式 • 报工粒度(工序/批次) • 节拍与在制品(WIP) • 异常停线与补料 • 换型与首件确认 输出:工单执行流程 质量 • 检验点与抽样规则 • 判定与不合格处置 • 追溯链(人机料法) • SPC 与偏差放行 • 返工返修闭环 输出:检验与追溯规则 设备 • 状态采集与停机原因 • OEE 计算口径 • 点检与预防性维保 • 备件与维修工单 • 报警与联锁 输出:设备数据接口 物料 • 收发存与批次管理 • 齐套与缺料预警 • 条码/RFID 标识 • 线边库与拉动 • 与 ERP 对账 输出:物料流转模型 业务蓝图(To-Be 流程 + 数据模型) 统一术语 · 消除冲突 · 明确接口边界 需求规格说明书 SRS 功能需求 · 数据需求 · 接口需求 · 验收标准

访谈怎么问:从“痛点”到“可验证需求”

访谈的核心技巧是把模糊描述逼成可验证条件。例如生产主管说“报工太慢”,这不是需求。继续追问:现在报工发生在哪个工位?用什么介质(纸质/终端/扫码)?一次报工平均耗时多少秒?瓶颈在录入还是等待?期望降到多少?当答案变成“注塑车间 12 台机,操作工在机台终端扫工单码+产品码,单次报工从 45 秒降到 15 秒以内”,这才具备写进 SRS 的条件。

建议每个角色访谈控制在 60~90 分钟,按“现状流程—痛点与频次—期望状态—数据与接口—约束与例外”五段推进。其中“例外”最容易被忽略却最关键:质量访谈中要专门问“不合格品在什么情况下允许让步接收?谁审批?审批记录留多久?”这类例外往往决定后续工作流分支的复杂度。

访谈时安排一名记录员专门标注“待确认项”,会后 24 小时内回传纪要,让被访者确认。未确认的纪要不能作为蓝图输入。

业务蓝图:把四份访谈合成一张 To-Be 图

四类角色访谈完成后,不能简单拼接。要召开蓝图工作坊,重点解决三类冲突:术语冲突(生产叫“批次”,质量叫“炉号”,物料叫“批号”,需统一为同一数据对象)、边界冲突(设备状态由 PLC 直采还是人工录入,决定接口方案)、优先级冲突(质量要求全检追溯,生产要求不增加节拍,需折中为关键件全检+一般件抽检)。

蓝图应包含:To-Be 端到端流程(从订单下达到成品入库)、角色与职责矩阵、关键数据对象及关系、系统间接口清单、以及每个流程节点的输入输出。蓝图评审通过后,才进入 SRS 编写。

需求规格说明书:可交付的字段结构

SRS 不是散文,而是可逐条验收的条目集合。每条需求建议包含以下字段,便于后续开发、测试与验收对齐:

字段说明示例
需求编号唯一标识,便于追溯REQ-PROD-012
需求名称简短描述工单扫码报工
来源角色提出方生产主管
优先级必须/应该/可选必须
需求描述可验证的行为描述操作工扫描工单码与产品码后,系统在 2 秒内返回报工成功并更新 WIP
验收标准如何判定通过连续 20 次扫码,成功率≥99%,平均响应≤2 秒
关联接口涉及的系统/设备FactoryTalk ProductionCentre ↔ ERP

一个可参考的访谈问题清单(节选)

【生产角色】
1. 当前工单如何下发到工位?纸质还是系统?
2. 报工在哪个环节发生?工序级还是批次级?
3. 换型时如何确认首件?记录在哪里?
4. 停线时如何通知?停线原因如何分类?

【质量角色】
1. 检验点设在哪些工序?抽样规则是什么?
2. 不合格品如何隔离、评审、处置?
3. 追溯需要覆盖哪些要素(人/机/料/法/环)?
4. 是否有 SPC 控制图?超限如何响应?

【设备角色】
1. 设备状态如何采集?PLC 还是人工?
2. OEE 的时间口径如何定义(计划/运行/停机)?
3. 点检与维保计划如何触发?
4. 报警是否需要与工单联动?

【物料角色】
1. 批次如何生成与标识?条码还是 RFID?
2. 齐套检查在什么时点执行?
3. 线边库如何补料?拉动还是推送?
4. 与 ERP 的对账频率与差异处理?
常见误区:把“用户想要的界面”当成需求。界面是解决方案,需求是业务目标。访谈中若对方直接描述界面,应追问“这个界面帮你解决什么问题、判断什么、触发什么动作”,再回到业务需求本身。

从需求到蓝图的收敛判断

判断调研是否到位,可以用三个问题自检:第一,每个痛点是否都有对应的 To-Be 流程节点?第二,每个流程节点是否都有明确的输入、输出和责任角色?第三,每条需求是否都能写出可执行的验收标准?三者齐备,蓝图和 SRS 才具备进入设计与开发的条件。否则,宁可再补一轮访谈,也不要把模糊需求带入下一阶段——后期返工的成本远高于前期多问一小时。