我沒有經手過大豆油生產、也不是食品製造現場的人，只是最近看到大豆沙拉油相關事件，我就順手去看了一下這類產品大概怎麼做(實際製程一定比較複雜)

腦中就冒出一個問題：

如果今天是我在做這套履歷追溯系統，當架上的某一瓶油出事時，我到底能不能一步一步往回追，追到原料來自哪個國家、經過哪些製程、最後問題可能出在哪一段?

我想像中的追法

如果今天在全聯或超商架上拿到一瓶大豆沙拉油，掃到成品批號 F-301，系統應該不是只吐一句：

這是某年某月某日生產的

而是要能一路往回拆：

  • 這瓶油是哪一次充填出來的？
  • 當時用了哪一槽精煉油？
  • 那槽精煉油又是由哪些半成品批次組成？
  • 半成品往前追，用了哪些毛油？
  • 毛油再往前追，來自哪些大豆原料批次？
  • 這些原料是哪家供應商、哪個來源國進來的？

如果系統只能看到「成品對工單」，其實還不夠 因為真正出事時，大家想知道的是：

這瓶油從哪裡來？經過什麼？問題可能卡在哪？

大豆沙拉油這條鏈，實際上大概長這樣

Mermaid · 圖表原始碼
sequenceDiagram
    participant F as 成品批號 F-301
    participant P as 充填 PACK-01
    participant R as 精煉油批號 R-201
    participant RP as 精煉製程
    participant C as 毛豆油批號 C-101
    participant E as 壓榨 / 萃取
    participant S as 大豆原料批號
    participant BR as 巴西來源批次
    participant US as 美國來源批次
 
    F->>P: 查詢充填紀錄
    P->>R: 追溯使用的精煉油批號
    R->>RP: 查詢精煉製程紀錄
    RP->>C: 追溯投入的毛豆油批號
    C->>E: 查詢壓榨 / 萃取紀錄
    E->>S: 追溯投入的大豆原料批號
 
    S->>BR: 查詢巴西來源批次
    S->>US: 查詢美國來源批次

如果從全聯 / 超商架上一瓶油開始掃，系統應該怎麼一路查回去？

這張 Sequence Diagram 是我腦中比較理想的查詢流程：

Mermaid · 圖表原始碼
sequenceDiagram
    participant Store as 全聯 / 超商門市
    participant QA as 品保 / 客服
    participant Trace as 追溯系統
    participant MES as 製造系統
    participant WMS as 倉儲系統
    participant ERP as 採購 / 進料系統
 
    Store->>QA: 回報問題商品，提供瓶身批號 F-301
    QA->>Trace: 查詢成品批號 F-301
 
    Trace->>MES: 取得充填事件 PACK-01
    MES-->>Trace: F-301 來自精煉油批號 R-201
 
    Trace->>MES: 查詢精煉事件 REFINE-01
    MES-->>Trace: R-201 由毛油批號 C-101、C-102 組成
 
    Trace->>MES: 查詢壓榨 / 萃取事件 CRUSH-01
    MES-->>Trace: C-101 對應原料批號 R-101、R-102
 
    Trace->>ERP: 查詢原料進貨資訊
    ERP-->>Trace: R-101 來源巴西，R-102 來源美國
 
    Trace->>WMS: 查詢同批次流向
    WMS-->>Trace: 受影響成品 F-301、F-302；部分已出貨，部分仍在庫
 
    Trace-->>QA: 回傳完整追溯結果與受影響範圍

這才是我認為「有用」的追溯 不是只有把批號查出來，而是能把：

  • 成品
  • 製程
  • 半成品
  • 原料
  • 供應商
  • 來源國
  • 流向

全部串成同一條路徑

為什麼只存一個 ParentLotId，通常不夠用？

因為現場很少永遠都是一對一

真實世界比較常見的是：

  • 多個原料批次一起投入
  • 一個半成品再拆成多個成品批次
  • 不同批次在儲槽或某道製程併批
  • 某批成品被拿去重工
  • 中間還會有損耗、取樣、報廢

像這種情況：

Mermaid · 圖表原始碼
flowchart LR
    A["巴西原料 R-101"] --> C["MIX / REFINE Event"]
    B["美國原料 R-102"] --> C
    C --> D["半成品 S-201"]
    D --> E["充填 PACK-01"]
    E --> F["F-301"]
    E --> G["F-302"]

如果你的資料模型只有：

ParentLotId -> ChildLotId

很快就會卡住
因為這根本不是單純的父子關係，而是：

多個 Input
↓
一次 Process Event
↓
多個 Output

所以如果是我設計，我會把重點放在事件，而不是只放在「父批號是誰」

換句話說，要記的是：

這次作業用了哪些批次進來，又產出了哪些批次出去

只要這個關係有記清楚，拆批、併批、重工，後面才追得回來

真正出事時，不只是往回追，還要往前追

假設最後查出是 R-101 這批原料有問題，事情還沒結束

下一步不是只知道「喔，原來是巴西那批」

而是還要立刻回答：

還有哪些產品被這批原料影響？

例如：

Mermaid · 圖表原始碼
flowchart LR
    A["問題原料 R-101"] --> B["半成品 S-201"]
    B --> C["F-301"]
    B --> D["F-302"]
    B --> E["REWORK-01"]
    E --> F["F-401"]
 
    C --> G["已出貨"]
    D --> H["庫存中"]
    F --> I["重工後產品"]

這時候追溯系統就不只是「查歷史」而已，
而是要變成能支援現場決策的工具：

  • 哪些批次要先隔離？
  • 哪些已經出貨？
  • 哪些還在庫存？
  • 哪些已經重工過？
  • 召回範圍到底多大？

這些都不是靠一個批號欄位就能解決的

所以，如果是我做這套系統，我最在意的是這件事

我不會先問：

系統裡有沒有批號欄位？

我會先問：

當一瓶油真的出事時，我能不能從終端成品，一路追到原料來源國、供應商、製程、設備、時間，最後把受影響範圍全部拉出來？

如果可以，這套履歷才算真的有用

如果不行，那它多半還只是「有批號資料」，不是「真的能追溯」

我自己會把核心原則濃縮成一句話：

不要只記錄這張工單用了哪個批號，而是要記錄每一次製程事件中，哪些東西進來、哪些東西出去

因為只有把這條投入 / 產出鏈建起來，
拆批、併批、重工、召回、影響範圍分析，才有可靠基礎

這就是MES的價值了

Subscribe to new articles訂閱新文章