1. 课程导入与需求分析全景

食品工厂的数字化项目，失败的原因往往不在软件本身，而在项目启动时对“要解决什么问题”没有形成共识。一个车间提出“上MES”，背后可能是批次追溯总被客户投诉、可能是投料记录靠纸单导致月底对不上账、也可能是设备停机数据拿不到、OEE长期靠估算。如果需求分析阶段没有把这些真实诉求翻译成可验证的系统能力，项目就会变成“买了一套系统，然后让业务去适应它”。本课程要建立的，正是从业务痛点走向可交付需求规格的完整方法。

数字化项目在食品工厂中的定位

食品工厂的数字化系统不是孤立的一套软件，而是嵌在“原料—生产—检验—仓储—交付”这条主链上的信息基础设施。典型构成包括：车间层的设备数据采集与SCADA、执行层的MES（制造执行系统）、质量层的LIMS（实验室信息管理系统）、仓储层的WMS，以及企业层的ERP。它们各自承担不同粒度的职责：ERP管订单、物料与财务，MES管工单、批次、工序与现场执行，LIMS管取样、检验与放行，WMS管库位与效期。需求分析的核心任务之一，就是判断某个业务诉求应该落在哪一层，避免把ERP能做的事硬塞进MES，或把现场执行细节全部压到ERP里。

食品行业还有两个区别于离散制造的硬约束。其一是批次与追溯：从原料入库批号到成品出货批号，必须能正向、反向追溯，且追溯链条要在分钟级完成，而不是翻几天纸质记录。其二是合规与效期：HACCP关键控制点（CCP）的记录、清洁消毒记录、过敏原管理、保质期与先进先出，都是系统必须承载的对象。需求分析若忽略这两点，后续再补往往要动数据模型，代价极高。

需求分析的价值：把“想要”变成“可验收”

需求分析的价值可以概括为三句话：界定边界、量化目标、锁定验收。界定边界，是明确本期做什么、不做什么，例如“本期只覆盖灌装与包装两个车间，前处理车间下一期”；量化目标，是把“提高追溯效率”变成“任一成品批号可在3分钟内查出所用原料批号、对应CCP记录与检验报告”；锁定验收，是让每条需求都有可观察的判定依据，例如“追溯查询响应时间≤5秒，覆盖最近12个月数据”。

实践中，需求通常分为三类：功能需求（系统要做什么，如工单下达、批次绑定、CCP记录采集）、非功能需求（性能、并发、可用性、接口频率、数据保留年限）、约束需求（必须对接现有ERP、必须满足某审核标准、必须支持车间离线续传）。很多项目只写功能需求，结果上线后发现扫码枪并发一高就卡、断网后数据全丢，这类问题都应在需求阶段以非功能需求的形式写清楚。

课程任务地图与交付物

本课程围绕一个贯穿始终的模拟项目展开：某中型乳制品工厂计划建设覆盖灌装、包装车间的MES，并对接现有ERP与实验室系统。30个章节将沿着“理解业务—梳理现状—识别痛点—设计目标—编写需求—评审确认”的主线推进，最终形成一套可评审的需求规格说明书。下图展示了从业务现状到需求交付物的整体关系，以及各阶段产出如何逐层收敛。

围绕这套交付物，课程会逐步给出可直接使用的中间成果。例如在痛点识别环节，我们会用“影响度×紧迫度”矩阵对候选痛点排序，并给出评分口径：影响度按对追溯合规、客户投诉、人工工时、数据准确性的影响打分（1～5分），紧迫度按是否被审核或客户明确要求、是否已有明确时限打分（1～5分），两项相乘后排序，得分≥15的进入本期范围。在需求编写环节，每条需求按“编号—名称—描述—触发条件—输入—处理规则—输出—验收标准—关联痛点”的字段组织，确保可评审、可追溯。

一个具体的需求片段示例

以“灌装工序批次绑定”为例，需求描述不能停留在“系统应支持批次绑定”。可验收的写法是：操作工扫描工单条码后，系统校验该工单状态为“已下达”且灌装机已通过清场确认；随后依次扫描原料批号、包材批号，系统按BOM校验物料是否属于该工单允许用料，不匹配时阻断并提示；灌装开始与结束时间由设备信号自动采集，人工仅确认异常停机原因；完工后生成批次关联记录，记录内容至少包含成品批号、原料批号、包材批号、灌装起止时间、操作工、CCP温度记录。验收标准可写为：用测试工单执行一次完整绑定，系统在10秒内生成关联记录，且通过批号反查可完整还原上述字段。这样的需求，开发和验收双方都能对上号。