4. 业务痛点与需求工程

在智能制造项目里，最危险的不是技术选型错误，而是把“老板以为的问题”当成“车间真实的问题”。痛点挖掘与需求工程，本质上是把模糊的抱怨转化为可验证、可排序、可交付的需求条目。本节围绕三条挖掘路径、一套分类与排序方法，以及一份需求规格说明书的写法展开。

一、三条互补的痛点挖掘路径

价值流分析（VSM）适合发现“流程级”浪费。做法是选定一个代表性产品族，从原材料入库到成品发运，逐工序记录周期时间（C/T）、换型时间（C/O）、在制品数量（WIP）、设备可用率与信息流触发方式。关键不是画得漂亮，而是算出两个数：增值时间与总前置时间之比（增值比），以及每个工序的等待时间占比。例如某机加工件总前置时间 12 天，实际增值加工仅 96 分钟，增值比约 0.56%，说明绝大部分时间消耗在等待与搬运上——这类结论会直接指向排产、齐套与物流类需求。

现场观察（Gemba Walk）适合发现“执行级”问题。建议按“一个工位、一个班次、一个异常”的粒度蹲点，记录操作员的实际动作序列、走动距离、扫码次数、纸质单据流转、异常上报方式与响应时长。观察时要区分“标准作业”与“实际作业”的偏差，偏差本身就是需求线索。例如发现操作员每班需手工抄录 6 次设备参数到纸质报表，单次约 4 分钟，则每班浪费约 24 分钟，且存在转录错误风险，这直接对应“设备数据自动采集与报表自动生成”需求。

访谈适合发现“管理级”诉求与隐性约束。访谈对象应覆盖高层、中层、班组长与一线操作员，且分层设计问题：高层问目标与考核指标，中层问协同与瓶颈，一线问操作与痛点。访谈要避免“您想要什么功能”这类诱导式提问，改为“最近一次影响交付的异常是什么？当时您怎么处理的？”用事件回溯法获取真实场景。三类方法的关系可用下图表示：

二、需求分类与优先级排序

痛点不能直接当需求。一个痛点往往对应多个需求，一个需求也可能解决多个痛点。建议先把痛点池按“现象—数据—影响”三要素整理，再转化为需求条目，并归入四类：功能需求（系统要做什么，如工单自动派工）、数据需求（采集什么、频率、精度、留存，如设备状态 1 秒级采集、保留 12 个月）、集成需求（与 ERP/MES/WMS/PLC 的接口与触发方式）、非功能需求（响应时间、并发、可用性、权限与审计）。

排序推荐用“价值—成本”矩阵配合 MoSCoW 分级。价值可从交付影响、质量影响、人工节省、合规风险四个维度打分（1~5 分），成本按人天与集成复杂度估算。一个可操作的公式是：优先级得分 =（业务价值 × 0.5 + 紧迫度 × 0.3 + 实现可行性 × 0.2）÷ 相对成本。得分高且成本低的进入 Must have，价值高但成本高的进入 Should have 并拆分试点，价值一般且成本高的进入 Could have，合规或安全类需求即使价值分不高也通常直接列为 Must。

三、需求规格说明书编写

需求规格说明书（SRS）的核心是“可验证”。每条需求应包含：编号、名称、来源痛点、需求描述、验收标准、优先级、依赖与约束、提出人与确认人。其中验收标准必须可测量，避免“提升效率”这类无法验收的表述，改为“工单派工时间从平均 15 分钟降至 2 分钟以内，抽样 30 笔验证”。

下面给出一份可直接参考的需求条目示例，字段按制造运营场景设计：

编写时还要注意三点：一是一条需求只描述一件事，避免“并且/同时”堆叠；二是区分需求与方案，需求写“要看到设备实时状态”，方案写“用 OPC UA 采集”，方案可在设计阶段再定；三是建立追溯关系，每条需求能回溯到痛点，每个痛点能对应到需求，避免出现“没人提却做了”或“提了却没做”的遗漏。完成初稿后，组织一次业务、IT、设备三方评审，重点检查验收标准是否可测、依赖是否明确、优先级是否达成共识，评审通过后冻结基线，后续变更走变更流程。

综上，痛点挖掘解决“问题真不真”，需求分类与排序解决“先做什么”，需求规格说明书解决“做成什么样才算完成”。三者环环相扣，缺一环都会让智能制造项目在实施阶段反复返工。