食品安全追溯系统浅谈（下）

你翔叔 2023-08-08 05:08:55

上篇主要提及了食品安全领域的追溯系统的产品价值和市场现状部分，本文重点阐述其主要业务场景和功能设计，供大家参考和交流。

产品经理，产品经理网站

一、主要业务场景和功能设计

1. 概述

下面主要讲追溯具备的一些基础功能的设计，还是先做个划分，本章包含：商品在生产、流通、销售不同业态进行追溯的功能设计，追溯的核心批次管理，后续的赋码和展示三个部分进行讲述。

刚才提到追溯系统的核心对象是批次，有必要提前讲下其概念，即通过一定的规则（如生产、进货等操作）生成批次ID，系统记录同一个批次ID的商品（SKU）在不同的企业间生产、流转所产生的相关追溯信息，串连上下游企业形成追溯信息，单个企业节点常见字段如：企业名称、操作名称、操作人员、操作时间等。那么如果想到达成从终端消费环节追溯到源头的效果，则需要所有参与商品流转的企业使用的是同一套（同一家公司开发）系统，或者使用同一套行业标准，否则不同系统间的数据标准不一而无法串联，这是非常困难的。

其中理想的方案就是建立公共标准或体系，而最具备这个条件的也就是监管方。上海的监管单位建设了一套追溯标准体系，其中以“商务部追溯码”作为通用批次号，要求所有企业进行追溯时需携带“商务部追溯码”，并按照标准接口要求上报数据，进而理论上能够追溯到源头。另外如果客户企业自身就是覆盖从生产到销售全环节的企业，那自然也是极好的，但这类企业毕竟不多。

若无法覆盖上下游多个环节的企业，粗一点的做法则是企业自行录入上游信息，如供应商、原产地等，而没有商品在上游企业流通的信息，市面上多数追溯信息展示均是此类。

还一种做法是通过强势的上下游企业间的影响，使追溯系统覆盖到上下游，从而达成上下游的追溯信息串联。这种情况比较依赖当地政策和企业间强弱势关系，同时对被影响的企业，提供的系统服务往往也会有让步，升至可能直接免费。但追溯信息往往终止于向上或下一个层级，更多如源头生产商环节则较难产生影响。当然也有供应商即是生产商的情况，这种情况下也算追溯到源头了。

最后的情况是政府招标项目，涉及的行业/企业一般比较全面，而且基本都有补贴，企业配合度高，有机会做成标杆。

最后，包括本章节在内，下面章节主要是基于多企业节点追溯的场景进行设计。

2. 生产、流通、销售各环节的追溯

一般可将食品从生产到到消费者手上分为“生产、流通、销售”三个环节，每个环节可抽象出若干企业类型，下面主要讲下各类型企业的追溯环节主要功能。另外在各个环节都有一些通用业务如“进货管理、出货管理、检测管理、供应商管理、客户管理、产品管理、证件票据等基础信息管理”等。

2.1 生产环节

企业类型：种植、养殖、加工、屠宰

这里是食品最上游源头的环节，其实一般加工、屠宰处于种养殖企业的下游，因此这里也可以分为两个环节，种养殖作为“源头环节”，加工、屠宰一起作为“加工环节”，但本文还是合并在一起讲。

2.1.1 种植、养殖

种养植企业的业务模型基本一致，追溯功能基本可以复用，因此放在一起讲。如种植企业在进行追溯时需要记录从播种、到施肥以及采收等一系列操作，形成追溯信息。一般需要对“田间地块、供应商、员工、产品（成品）、农资（投入品）、农事作业”几个对象进行管理，中间通过种植计划（批次）进行串联。换到养殖企业，对象性质一致，只是换个叫法，如：“基地、供应商、员工、产品（成品）、养殖物资（投入品）、养殖作业”

以种植为例，进货农资时即生成进货批次ID，农资（如农药、种子等）进货时记录对应的供应商；然后创建种植计划生成种植批次ID，下一步记录的农事作业则需关联种植批次、所使用的农资进货批次；最后对种植计划进行采收，以上每个SKU的每次种植计划、农资进货都生成一个批次ID，一次种植/进货多个SKU则生成多个批次ID。这样一个农产品从农资的采购进货，到种植过程的农事作业，采收和后续的出库等信息都通过批次进行关联。形成了在种植节点内的追溯信息。在下游进货后，可通过批次ID间的关系追溯串联，形成贯通上下游的追溯信息。

2.1.2 加工

加工类企业则需要将原材料的进货、加工、出货进行记录和管理，主要对象包含“供应商、员工、原材料、加工成品、物料清单（BOM表）、原材料进货、加工生产记录等”，主要通过加工批次进行串联。加工本质上是对多个批次的合并，即通过BOM表将原材料批次，加工品批次进行关联，而BOM表一般可包含主要工艺（用于展示）。面对复杂的加工流程，则需要在BOM表的设计上支持更多样的对象关系。

2.1.3 屠宰

与加工相反，屠宰本质上是对单个批次的拆分，一般是对猪、牛、羊的屠宰和分割，主要管理对象包含“供应商、员工、胴体、分割品、分割清单、进货管理、屠宰分割等”，同样可通过分割清单的形式建立“胴体与分割品”之间的关系。
2.2 流通环节

企业类型：配送（物流）中心、批发市场、其他供应商

这类企业的特点是处在中间的商品流通环节，有的是独立的供货商、批发市场，也有从属于下游商超的物流中心（大仓），主要将进货、检测、出货进行追溯的串联，其中批发市场的模式往往是市场作为管理方，其中具体进行商品批发销售的是一个个商户。主要管理对象包含“供应商、员工、产品、进货管理、出货管理”，批发市场还有额外的“商户”，一般在进货时生成批次ID。

2.3 销售环节

企业类型：超市卖场、便利店、农贸市场、团体采购单位

这类企业作为终端销售环节，在追溯信息的记录上主要是进货和可能的检测。主要管理对象包含“供应商、员工、产品、进货管理”，同样一般在进货时生成批次ID。其中农贸市场和上面的批发市场一样，存在商户对象。而便利店，超时卖场会存在总部端统一管理SKU、供应商等场景。

最后再简单提下SKU的管理，在追溯场景下，对SKU的管理较为简单。主要是两点，一是SKU和供应商的绑定关系，一般可采取多对多的关系，可以满足各类场景；二是在处理上下游多家企业时，还需注意不同企业SKU不一致的情况，一般需要进行映射。另外一般不需要管理SPU。

3. 批次管理

追溯的核心是批次，主要有两个问题：批次的生成以及批次在流转中合并拆分的管理，批次与批次间的关联，本质上是要实现追溯数据和商品实物的关联

3.1 批次的生成

入库生成：同一个SKU每次生产/进货入库即生产一个批次，一个SKU多次入库生成多个批次，一个进货多个SKU对应生成多个批次。
日期生成：对于连续性生产过程、工艺稳定、价格较低的产品，可采用记录日历日期来追溯，即一天一批。

3.2 混批管理

首先讲的是多节点追溯时，需要将上下游批次进行关联，即将上游批次作为下游批次的父节点，这样在下游进行追溯时，向上对父节点进行逐级追溯，最终达到源头。

基于以上逻辑，在多节点追溯场景下，商品批次在流通时可能存在混批的情况，一般是在物流中心等大仓环节（加工环节的合批属正常业务情况，没有影响）。混批一般是多个入库批次混在一起出库，在批次管理上存在是否要合成一个批次的问题。

如果合批，下游入库时只有一个批次，那么向父节点追溯时会存在多个父节点，实际上对于实物商品（消费者扫码查追溯的场景），只会有一个真实的父节点，但数据层面无法识别到底是哪个。

如果不合批，那么在商品流通过程中，只会存在批次不断拆分的情况，一个批次会逐渐变成多个批次，最终导致到下游时同一个商品的批次过多，增加管理成本。类似我只进了一车苹果，但系统里显示进了5个批次，另外我也不知道哪箱苹果是哪个批次。

首先，如果可以选择那么尽量不合批。在此前提下，要解决不合批的问题需要做到精细化管理（我还没实践过哦），做到一物一码、一箱一码、一批一码，商品码与箱码关联，箱码与批次码关联，对一个批次进行的操作，都会同步到箱码和商品码上，向下类推。每个商品，每个货箱都需要赋码。因此结论是大部分食品的附加值不足以支撑这样精细化管理的成本，但在一些高附加值如白酒、或者工业领域仍然有应用价值。（以上精细化管理的前提是标品，非标品一般只能管到批次的层面）

4. 赋码和展示

4.1 赋码场景

给商品赋码的主要作用有两点，一是下游进货时通过扫码快速完成进货登记，二是供消费者扫码查看追溯信息。这两个场景可用同一个二维码解决，也可根据实际场景分开。毕竟消费着扫的往往是“一物一码”，商家进货登记一个一个扫码可太麻烦了，一般会扫上游的出库单码，或是箱码，因此赋码时便有了商品码、箱码、批次码的绑定的生成和绑定需求。

4.2 码的类型

从码本身的类型上讲常见的有二维码、一位码、RFID等；赋码的方式有印刷贴码标签（人工贴码）、生产线喷码、包装印刷等，这方面有很多成熟的供应商。其中RFID成本略高，但操作效率也能得到极大提，食品领域还是以二维码、一位码居多。

4.3 追溯的展示

常见的是一品一码、一物一码。一品一码适用于商超货架的价签上，是一个商品（SKU）的唯一追溯码，展示改商品最近一个或多个批次的追溯信息，不用频繁更换。一物一码则常赋于包装上面，一般是印刷或者手工贴标，展示商品对应的一个批次信息。

展示的信息大部分都是事先维护好的，如产品信息、当前企业信息、供应商信息；其他的就是追溯过程产生的信息，如产品在上游流通的信息（上文提及的流通的企业名称、操作名称、操作人员、操作时间等），检疫检验信息。其中产品信息、企业信息等都可以展示事先维护好的证照，获奖证书等，提升企业正面形象。

在展示时常对接的硬件，有常用于超市、农贸市场货架上展示一品一码的电子价签，以及追溯电子秤（一般打印一物一码），还有各种类型的打印机。