3. 追溯数据源与采集点梳理

数据缺失核查的第一步不是“查缺”，而是“知道本该有什么”。如果连数据源在哪里、由谁写入、在哪个业务节点产生都说不清楚，缺失判断就失去了基准。本节围绕四类典型追溯系统——ERP、WMS、MES、区块链溯源平台——梳理它们各自承载的追溯数据、关键采集节点，以及如何用数据字典和元数据标准把“散落在系统里的字段”统一成可核查的数据源地图。

四类系统的数据分工

四类系统在追溯链上并非平级并列，而是承担不同粒度的记录职责。ERP 掌握“批次与交易”层面的信息：采购订单、供应商批次、原料入库批次号、生产工单、成品批次、销售出库去向。它的追溯粒度通常是批次级，是正向追溯（从原料找成品）和反向追溯（从成品找原料）的主干。WMS 掌握“库内位置与移动”层面的信息：库位、托盘/箱码、收货上架、移库、拣货、发货，以及库内温湿度（若接入）。它回答的是“这批货在什么时间、在哪个库位、被谁动过”。MES 掌握“工序与投料”层面的信息：工单对应的实际投料批次、投料时间、设备、工序参数、操作人、半成品与成品产出批次。它是把原料批次与成品批次真正“焊接”起来的关键环节。区块链溯源平台则承担“对外存证与共享”职责：把关键节点的哈希、时间戳、批次标识上链，形成不可篡改的存证记录，供下游或监管方核验。

理解这一分工后，一个常见的核查误区就清楚了：成品批次在 ERP 有记录、在区块链平台有存证，但 MES 中缺少对应的投料批次关联，追溯链在“原料→成品”这一跳就断了。缺失核查必须按系统职责分别设检查点，而不是笼统地问“有没有追溯数据”。

关键采集节点与“最小可追溯字段集”

把系统职责落到字段层面，才能形成可核查的清单。以一批乳制品为例，一条完整追溯链至少需要以下节点字段：供应商批次号（ERP 采购收货）、原料入库批次与库位（WMS 收货上架）、领料批次与投料时间（WMS 领料 + MES 投料记录）、工单号与成品批次（ERP 工单 + MES 产出）、成品发货去向（WMS 发货 + ERP 销售出库）、链上存证哈希（区块链平台）。这组字段构成“最小可追溯字段集”，缺失核查即以它为基准逐项比对。

实践中容易忽略的是关联主键。各系统往往用各自的内部 ID 记录同一批物料：ERP 用物料编码+批次号，WMS 用托盘码或箱码，MES 用投料记录 ID。若没有一张映射表把“ERP 批次号—WMS 托盘码—MES 投料记录—链上哈希”对应起来，即使每个系统数据都齐全，追溯链在跨系统处仍然断开。因此数据源地图必须显式标注关联字段及其映射关系，这也是后续缺失核查能定位到“哪一跳断了”的前提。

数据字典与元数据标准

数据字典的作用是把字段的“名称、类型、长度、取值规则、是否必填、来源系统、更新频率”固定下来，避免同名不同义。例如“批次号”在 ERP 中可能是 12 位字母数字，在 MES 中可能是“工单号+序号”，核查时必须先确认两者是否同一编码体系。元数据标准则进一步规定时间格式（统一为 ISO 8601，如 2025-03-14T08:30:00+08:00）、计量单位（kg 与 g 不混用）、编码规则（GS1 或企业内部规则）以及数据责任方。建议为每个关键字段建立如下条目：

实战任务：绘制数据源地图

数据源地图不是系统架构图，而是“追溯对象—系统—字段—节点—责任人”的对照表加关系图。可按以下步骤落地：第一步，选定一个代表性产品和一个生产批次作为样本；第二步，沿“来料→入库→领料→投料→产出→发货”顺序，逐个节点记录数据产生系统、字段名、写入时间与操作角色；第三步，标出跨系统关联主键，验证映射是否唯一；第四步，对每个节点标注“必填字段是否齐全、时间戳是否连续、责任方是否明确”，形成缺失风险标记。

完成地图后应做一次交叉验证：随机抽取 3 个成品批次，分别从 ERP 正向查到区块链存证、从链上哈希反查到原料批次，记录每一跳的字段命中情况。若某一跳在两个方向上都无法闭合，该节点即为优先核查对象。数据源地图的价值正在于此——它把“追溯数据缺失”从模糊感受变成了可定位、可分工、可复核的具体节点。