2. 制造数据生态与血缘需求分析

制造企业的数据不是集中在一个系统里，而是分散在从产品设计、计划排产、生产执行到质量检验的多个业务系统中。要建立可用的血缘追踪能力，第一步不是选工具，而是把“数据从哪里来、经过谁、最终被谁消费”这张生态图画清楚。本节围绕制造企业五类核心数据源、它们之间的数据流特征，以及血缘追踪的业务驱动与合规要求展开。

五类核心数据源及其血缘角色

制造场景中最常被血缘追踪覆盖的系统可以归纳为五类，它们在数据生态中承担的角色差异明显：

• ERP（企业资源计划）：主数据与计划数据的源头。物料主数据、BOM、工艺路线、生产订单、采购订单通常在这里创建。ERP 是血缘链的“上游起点”，其物料编码一旦变更，会向下游 MES、QMS 扩散。
• PLM（产品生命周期管理）：工程数据的权威源。EBOM、图纸版本、工程变更（ECN）、物料规格在这里管理。PLM 与 ERP 之间存在 EBOM→MBOM 的转换关系，是血缘中最容易断裂的一环。
• MES（制造执行系统）：执行数据的汇聚点。工单、工序报工、设备绑定、批次/序列号、在制品状态在这里产生。MES 同时消费 ERP 的订单与 PLM 的工艺，又向 QMS 输出生产实绩。
• SCADA（数据采集与监控）：过程数据的采集层。通过 PLC/OPC UA 采集温度、压力、转速、扭矩等工艺参数，按时间序列写入历史库。SCADA 数据是“参数级血缘”的关键，用于回答“这批产品的焊接电流是多少”。
• QMS（质量管理系统）：质量判定与追溯的终点。检验任务、检验结果、不合格品处理、SPC 数据在这里形成。QMS 的追溯结论依赖 MES 的批次和 SCADA 的参数，是血缘链的“下游消费者”。

这五类系统并非简单串联，而是存在多对多的交叉引用。例如一个质量异常单（QMS）可能同时关联 MES 的工单、SCADA 的设备参数曲线和 ERP 的供应商批次。血缘建模时必须允许一个数据实体有多个上游来源。

数据流特征：为什么制造血缘比互联网数据血缘更难

制造数据流有三个显著特征，直接决定了血缘追踪的实现难度。

第一，批流混合。ERP 的订单、PLM 的 BOM 是典型的批式数据，按天或按单更新；而 SCADA 的工艺参数是高频流式数据，采样周期可能达到 100ms 甚至更短。血缘系统必须同时处理“订单号→工单号”的批式映射和“工单号→时间窗→参数曲线”的流式关联。前者可以用 SQL 关联，后者往往需要按时间窗口做区间匹配。

第二，多级批次粒度。制造追溯的粒度不是单一层级。一个生产订单（ERP）对应多个工单（MES），一个工单对应多个产品序列号，一个序列号又对应若干工序和参数记录。血缘链需要在“订单—工单—批次—序列号—工序—参数”之间逐级下钻。如果某一级缺少关联键，整条链就会断裂。

第三，跨系统标识不统一。同一个物料在 PLM 中叫“物料号”，在 ERP 中叫“物料编码”，在 MES 中可能叫“料号”，且编码规则可能不同。血缘追踪必须建立标识映射表，否则无法把 PLM 的 EBOM 节点和 ERP 的 MBOM 节点对应起来。这是制造血缘工程中最常见、也最耗时的治理工作。

业务驱动：血缘追踪要回答哪些问题

制造企业推动血缘追踪，通常由四类业务问题驱动：

• 质量追溯与召回：当客户投诉某批次产品时，需要快速定位该批次用了哪些原材料批次、经过哪些设备、当时的工艺参数是否在规格范围内。血缘链的完整性直接决定召回范围能否精确到“批次”而不是“全部”。
• 变更影响分析：当 PLM 发起 ECN 变更某个零件时，需要知道哪些在制品、哪些已发货产品、哪些检验标准会受影响。血缘图可以反向遍历，从变更点向上游和下游扩散，输出影响清单。
• 根因分析：质量异常发生时，需要把 QMS 的缺陷记录与 MES 的工序、SCADA 的参数曲线关联起来，判断是设备参数漂移、来料批次问题还是工艺路线错误。
• 数据可信度评估：当报表数据出现异常时，需要判断是源系统录入错误、ETL 转换错误还是口径不一致。血缘图可以定位数据在哪个环节被修改或丢失。

合规要求：血缘追踪的硬约束

制造行业的合规要求为血缘追踪设定了最低标准。以汽车行业 IATF 16949 和医疗器械 ISO 13485 为例，法规通常要求企业能够证明“产品从原材料到成品的完整追溯链”，且追溯记录需保存一定年限（常见为产品寿命周期加 1 年，或至少 10 年）。这意味着血缘系统不能只记录“当前状态”，还要保留历史版本和变更轨迹。

此外，FDA 21 CFR Part 11 对电子记录和电子签名提出要求：血缘链中的关键节点（如检验放行、参数修改）必须可审计，记录谁在什么时间做了什么修改。这要求血缘系统在设计时就把“审计日志”作为一等公民，而不是事后补录。

从生态图到血缘需求清单

完成生态梳理后，下一步是把业务问题转化为可执行的血缘需求。一个实用的做法是建立“追溯问题—数据实体—关联键—源系统”的映射表。例如：

这张表的价值在于：它把模糊的“我们要做血缘”变成了具体的“需要采集哪些字段、在哪些系统之间建立关联”。后续的采集、建模和查询都围绕这张表展开。实际项目中，这张表通常需要由工艺、质量、IT 三方共同确认，因为关联键的可用性往往取决于现场数据录入的规范程度。

需要特别注意的是，血缘需求不是一次性完成的。随着产线调整、系统升级或合规要求变化，新的追溯问题会不断出现。因此，血缘系统应支持增量扩展：新增一个数据源或一条关联关系时，不需要重建整个链路。这也是为什么在架构设计阶段就要把“标识映射”和“时间窗口关联”作为核心能力，而不是把它们当作临时脚本处理。