2. 数字化工厂建设需求分析

数字化工厂建设最容易失败的方式，不是技术选型错误，而是在需求分析阶段就没有把“为什么建、建到什么程度、建成什么样算成功”说清楚。很多项目在立项时只有一句“建设数字化工厂，实现数据驱动”，既没有可验证的痛点，也没有可度量的目标，最终导致范围无限扩张、验收标准模糊、上线后无人使用。本节围绕四个递进环节展开：业务痛点识别、建设目标设定、范围界定、成功标准定义，并给出可直接使用的分析工具与示例。

一、业务痛点识别：从现象到可量化的问题

痛点识别不是收集抱怨，而是把“现象”还原为“可测量的业务损失”。建议采用现象—影响—根因—量化四步法。以某流程制造企业为例：

• 现象：中控操作员每班需手工抄录 6 张报表，交接班平均耗时 25 分钟。
• 影响：每班有效操作时间减少约 4%，且手工录入错误率约 2%，月度盘点差异反复出现。
• 根因：DCS 与 MES 之间无自动数据通道，批次数据靠人工转录。
• 量化：按三班制、年 300 个生产日计算，年损失约 300×3×25 分钟 ≈ 375 小时，折合人工成本与差错返工成本约 18 万元/年。

痛点识别要覆盖生产、设备、质量、能源、安全、供应链六个维度，并区分“业务痛点”与“IT 痛点”。业务痛点决定项目价值，IT 痛点决定技术方案。常见业务痛点包括：OEE 数据滞后超过 24 小时、质量追溯需人工翻查纸质记录、非计划停机缺乏预警、能耗按车间粗放分摊、批次收率波动无法归因等。每个痛点都应记录发生频次、影响范围、当前处理方式、量化损失四项信息，形成痛点清单。

二、建设目标设定：从痛点反推可度量目标

目标必须与痛点一一对应，并满足可度量、有时限、有基线三个条件。推荐使用“基线值 → 目标值 → 测量方式 → 责任部门”的目标卡结构。例如针对上述抄表痛点：

目标应分层：战略目标（如单位产品综合能耗下降 8%）、业务目标（如 OEE 提升 5 个百分点）、系统目标（如数据采集周期从 1 小时缩短至 1 分钟）。三层目标之间要有清晰的支撑关系，避免出现“系统上线了但业务指标没变”的脱节。

三、范围界定：明确做什么、不做什么

范围界定要同时回答三个问题：覆盖哪些工厂/产线/工序、集成哪些系统、交付哪些功能。建议用“范围矩阵”表达，横轴为业务域，纵轴为工厂/产线，单元格标注本期是否纳入。范围之外的内容要显式写入“不包含”清单，例如：本期不含仓储物流自动化改造、不含 ERP 替换、不含新建网络基础设施。

范围界定还需明确数据边界：哪些数据由谁提供、以什么频率、通过什么接口进入平台。例如 DCS 提供 500 个位号，采样周期 1 秒；LIMS 提供检验结果，按批次触发；ERP 提供工单，每日同步一次。数据边界不清是后期返工的主要来源。

四、成功标准定义：让验收有据可依

成功标准要区分交付标准与效果标准。交付标准回答“系统是否按合同建成”，例如：完成 12 个功能模块、接入 4 类源系统、数据采集完整率 ≥98%、页面响应 ≤3 秒。效果标准回答“业务是否真正改善”，例如：OEE 提升 ≥5 个百分点、非计划停机次数下降 ≥20%、月度盘点差异率 ≤0.2%。

效果标准需要设定观察期，通常为上线后 3～6 个月，并明确基线数据的采集窗口。例如 OEE 基线取上线前连续 3 个月的平均值，目标值取上线后第 4～6 个月的平均值。没有基线就无法证明改善，这是很多项目验收时争议最大的地方。

五、需求分析交付物示例

将上述四步整合为一份可评审的需求分析报告，核心字段如下（示例数据为合理假设，用于说明格式）：

【痛点编号】P-03
【痛点描述】批次质量数据分散在 DCS、LIMS 与纸质记录中，追溯一次需 40 分钟
【量化损失】年追溯工时约 200 小时，客诉响应超时 3 次/年
【对应目标】G-03：批次追溯时间 ≤5 分钟，追溯完整率 ≥98%
【范围】一车间 3 条产线，接入 DCS/LIMS，不含二车间
【成功标准】交付：追溯功能上线并通过 UAT；效果：上线后 6 个月追溯平均耗时 ≤5 分钟
【责任部门】质量部 / 信息部
【数据边界】DCS 提供批次起止时间与关键工艺参数；LIMS 提供检验项与结果

需求分析的质量直接决定后续架构设计与实施路径。痛点要能量化，目标要能测量，范围要能划清，成功标准要能验收。四者形成闭环后，数字化工厂建设才具备可管理、可交付、可评价的基础。