食品安全追溯系統淺談(下)

1 評論 2312 瀏覽 15 收藏 17 分鐘

當前的食品安全追溯市場還有一定的探索空間,如何建設食品安全領域追溯系統是一個值得思考的問題。上篇講述了關于食品安全領域追溯系統的產品價值和市場現狀部分,本文重點分享其主要業務場景和功能設計,希望對你有所幫助。

上篇主要提及了食品安全領域的追溯系統的產品價值和市場現狀部分,本文重點闡述其主要業務場景和功能設計,供大家參考和交流。

一、主要業務場景和功能設計

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)的唯一追溯碼,展示改商品最近一個或多個批次的追溯信息,不用頻繁更換。一物一碼則常賦于包裝上面,一般是印刷或者手工貼標,展示商品對應的一個批次信息。

展示的信息大部分都是事先維護好的,如產品信息、當前企業信息、供應商信息;其他的就是追溯過程產生的信息,如產品在上游流通的信息(上文提及的流通的企業名稱、操作名稱、操作人員、操作時間等),檢疫檢驗信息。其中產品信息、企業信息等都可以展示事先維護好的證照,獲獎證書等,提升企業正面形象。

在展示時常對接的硬件,有常用于超市、農貿市場貨架上展示一品一碼的電子價簽,以及追溯電子秤(一般打印一物一碼),還有各種類型的打印機。

四、尾聲

整體而言當前的追溯市場(指食品領域)仍然有一定探索空間,但很大程度上受到國內相關行業的發展成熟度影響,食品生產加工行業附加值低,缺乏產業集群,信息化要求低。短時間內而言食品追溯的市場化之路仍然難走,依賴政策驅動,因此在其他領域如區塊鏈、防偽防竄、營銷增值等領域的探索也算是情理之中。

本文對于食品安全領域追溯系統的建設講的比較粗略,有點貪大求全,很多細節沒有展開。如企業同時上報多個監管單位時如何統一和轉換品類;各個追溯環節的詳細設計,更多展示二維碼的場景,防偽防竄體系如何設計等,如果有機會將來可以展開講講。

本文由@天涯 原創發布于人人都是產品經理,未經許可,禁止轉載。

題圖來自 Unsplash,基于 CC0 協議。

該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 感謝分享,最近剛接觸這個行業,有了基本了解,期待后面防偽防竄體系設計的分享~

    來自浙江 回復