4. 数字化项目类型与需求侧重

食品工厂的数字化建设很少是一次性铺开的“大平台工程”，更多时候是由若干定位清晰的项目组成：车间要管生产执行，仓库要管收发货与批次追溯，质量部门要管检验与放行，动力车间要盯住水电气汽，设备部门则希望把关键机台的运行状态实时采集上来。这些项目在招标文件里往往被写成相似的“数字化系统”，但它们的需求内核差别很大。需求分析阶段如果把它们混为一谈，最常见的后果是：MES被要求承担仓库的库位管理，WMS被要求做生产工单报工，最终两边都做不深，接口还互相打架。

理解这些差异，先要抓住一个判断依据：每个系统真正“拥有”的业务对象是什么。MES拥有的是工单、工序、报工与在制品；WMS拥有的是物料、库位、批次与库存事务；QMS拥有的是检验单、样品、判定结论与不合格处置；能源管理系统拥有的是计量点、能耗读数与单耗指标；设备物联拥有的是设备、采集点位、状态与报警。对象不同，需求的主线、数据粒度、实时性要求和验收方式就不同。

从图中可以看出，五类项目在实时性上形成明显的梯度。设备物联要求秒级甚至更高频率采集，因为停机判断、报警联动依赖连续的状态序列；MES通常以分钟级接收报工和工序流转；能源管理以15分钟为典型采集与统计周期，足以支撑班次和产线分摊；WMS和QMS则以业务事务为触发点，一次收货、一次检验完成即产生一条记录，不追求高频刷新。需求分析时把这个梯度写清楚，才能避免“所有系统都要求实时”这种看似保险、实则推高成本和接口复杂度的表述。

差异背后：需求文档该写什么

以MES为例，需求重点不在“有没有报工界面”，而在投料防错与批次绑定规则。实际做法是：在配方中定义每个物料的允许替代范围与投料顺序，工单下达时锁定批次，操作工扫码投料，系统比对“物料编码+批次+数量”与工单要求，不一致则拦截并记录。验收时可设计一个具体用例：工单要求A物料批次L20240501、投料20kg，实际扫入L20240502，系统应拒绝并生成偏差记录。这类可判定的用例，比“支持投料管理”这样的描述有价值得多。

WMS的需求核心是库位规则与先进先出。食品原料普遍有保质期，需求中必须明确：收货时按效期自动推荐库位、出库时按“先到期先出”而非简单先入先出、临近效期触发预警。一个常见的教学示例参数是：某原料保质期180天，预警阈值设为剩余30天，则系统应在第150天起将该批次标记为待处理，并在拣货时优先推荐。盘点方式也要写清——是盲盘还是明盘、差异如何审批、盘盈盘亏是否影响批次库存。

QMS的需求难点是判定标准的可追溯。检验项、限值、取样规则往往随产品标准和客户要求变化，需求中应要求检验标准带版本和生效日期，检验单记录当时适用的标准版本，判定结论不可事后修改只能走偏差流程。这样在客户审核或监管检查时，才能回答“这批产品当时按什么标准判合格”。

能源管理和设备物联则更偏“采集与口径”。能源管理要先画清计量拓扑：总表、分表、产线表、设备表的层级关系，明确分摊口径（按产量、按工时还是按面积），否则单耗指标算出来无法解释。设备物联要先出点位清单：每台设备采哪些信号、什么协议、采集频率多少、断网时本地缓存多久、恢复后如何补传。这两类项目的需求如果只写“实现能耗监测”“实现设备联网”，实施阶段几乎必然反复。

共性：不能省的五件事

差异之外，五类项目共享同一套底座需求。第一是主数据统一编码：物料、设备、工序、计量点、检验项必须有全厂唯一编码，否则系统间接口只能靠名称匹配，迟早出错。第二是批次全程可追溯：从原料收货批次到成品出厂批次，中间经过哪些工序、哪些设备、哪些检验，要能正向和反向查询。第三是权限与审计留痕：谁在什么时间改了什么数据，必须可查，这在食品行业审核中是硬要求。第四是接口与数据口径：接口方向、频率、失败重试、字段含义要写成清单，而不是一句“预留接口”。第五是报表与看板：明确指标定义和取数来源，避免同一个“得率”在MES和报表里算出两个值。

最后要强调的是项目边界。五类系统之间存在天然的数据流：设备物联为MES提供设备状态和产量信号，MES的工单与报工为WMS提供领料和入库依据，QMS的检验结论决定WMS中批次能否放行，能源管理从MES取产量做单耗分摊。需求分析阶段就应把这些跨系统依赖画成接口清单，标明谁是数据源头、谁是使用方、更新频率和异常处理方式。边界清、口径一、用例可判定，五类项目才能各自做深又彼此咬合，而不是建成五个互不相通的信息孤岛。