當兩個正確的庫存數字仍然互相矛盾

兩個庫存數字不一致，不代表其中一個系統必然出錯。一個數字可能計算分切前的原料，另一個計算製作後的成品包裝，第三個則排除了已預留或被扣起的貨。表面是數量問題，實際往往是產品身份、營運事件，以及數字所支援的決策之間缺少連繫。

食品及飲品營運尤其容易出現這種情況。同一批實物在履約前，可能多次改變商品身份。核對的價值，不是令所有數字看起來一樣，而是解釋差異，讓團隊判斷哪些貨可出售、製作、調撥或需要調查。

兩個正確數字可以描述不同庫存

每個庫存總數都在回答一條特定問題。財務庫存、倉庫實存、可承諾庫存及符合食安要求的庫存，本來就可能不同。問題出現在某個用途的數字，被移到另一個決策使用，卻沒有帶上原來的定義。

客服在電商平台看見十件，倉庫因兩件已預留而顯示八件可用，品質紀錄又因兩件被扣起而只容許六件放行。追問哪個系統才正確，並未觸及重點。真正有用的問題是，六、八或十之中，哪個數字足以支援眼前的決定。

GS1 追溯標準^{2GS1，Traceability}描述產品在收貨、轉換、包裝、付運及運輸之間的關鍵追蹤事件與資料。這種事件視角重要，因為庫存是經由行動而改變，不是只靠總數改變。

產品身份在營運過程中改變

食品從收貨到出售，未必一直沿用同一識別碼。原料可能被分切、重新包裝、重新標籤、組合，或經不同渠道出售。不同供應商的貨可以變成同一成品 SKU，名稱相近的包裝也可能有不同規格、致敏原或保質期要求。

因此，身份是一條鏈，而不是產品表內的一行。供應商貨號、收貨批次、製作批次、成品 SKU、客戶訂單行及交付包裝，可能在不同時點指向同一批物料。任何一環缺失，數量差異便無法追溯至產生它的事件。

第一步是審核識別碼、單位、包裝換算、位置、批次、時間戳及庫存狀態。清理資料不是強迫所有來源使用同一格式，而是分清哪些紀錄指向同一事物、哪些並非如此，以及哪裏證據不足。

同步只能解決穩定的部分

若兩個系統共用穩定的產品身份，而差異只源於明確的過帳或連接器故障，直接修復同步是最簡單、成本最低的選項。

核對報表適合必須保留多個系統的情況。它能集中數字並揭示差異，但仍要由人判斷原因是時間差、包裝換算、產品轉換、實物差異還是品質狀態。

更換成單一庫存平台可以減少部分重複，但遷移並不會自動建立產品轉換及用途相關的可用狀態；同時，倉庫、生產、電商及品質流程亦要承受較大改動。

較複雜的營運可採用連接式庫存模型，保留原有來源紀錄。這裏的做法是建立有索引的業務本體模型，持續映射產品、識別碼、批次、位置、事件、限制及其關係。來源 ID、時間戳、權限及出處一併保留，讓分歧保持可見，而不是被合併成虛假的整齊總數。原有來源系統仍是權威紀錄。

一項差異如何由銷售走到解決

某成品包裝在線上顯示有貨，倉庫卻無法揀貨。電商紀錄指向成品 SKU，庫存系統指向原料，製作紀錄顯示只有部分原料完成分裝，品質紀錄則把其中一個製作批次扣起。

複製總數無法解釋問題。連接紀錄可由線上 SKU，沿已核准的包裝換算追溯至相關製作批次，再把已放行成品、原料、已預留及被扣起的物料分開。客服知道訂單暫時不能承諾，倉庫看見欠缺哪個事件，品質團隊仍掌握放行權。

直接成果不是自動改數，而是以較少來回完成調查，並留下負責人及可延續至下一次更新的解釋。若同類差異重複出現，管理層亦能分辨問題來自事件記錄太遲、產品映射不合適，還是實際流程根本未被任何系統記錄。

邊界情況決定這個視圖是否有用

不定重產品、拆批、重新包裝、補錄收貨、離線點算、損壞箱件、替代品及跨地點調撥，都會產生合理的中間狀態。產品實物存在，也可能因隔離、剩餘保質期不適合某路線、已預留，或尚待製作事件而不可使用。

不同情況帶來不同業務後果。把時間差當成庫存損失，會製造多餘調查及調整；把被扣批次當成可用，會帶來服務及食安風險；把包裝換算錯誤當成實物短缺，可能觸發不必要的採購或生產。

批次身份缺失、致敏原狀態未明及品質扣貨尚未解除，都應停止可用聲明。其他不確定情況可保留最後可靠事件、資料年齡及負責人。Codex Alimentarius 實務守則^{1FAO 及 WHO Codex Alimentarius，實務守則}提供食物衞生框架，確保營運方便不會凌駕既有安全控制。

信任在核對會議中建立

採用應從現有差異檢討開始，而不是另開一個儀表板。倉庫、品質、營運、財務及主數據負責人需要把連接後的解釋，與日常調查方式逐項比較。介面亦要使用團隊熟悉的產品、包裝、批次、位置及事件語言。

培訓最適合採用棘手案例，例如拆批、延遲收貨、重新包裝、扣貨後放行，以及實物點算與系統相反。每項修正要分類：來源事件太遲、映射錯誤、狀態定義太闊，或實際流程已改變。

這些修正紀錄就是持續優化的機制。重複覆核只應在相關負責人同意規律可重用後，才改動映射或營運規則。一次性的遷就不應悄悄變成預設做法。

NIST AI 風險管理框架^{3NIST，AI Risk Management Framework}強調情境、評估、監察及問責。在這個流程中，意思是用真實調查測試解釋、保留人員對庫存行動的權限，並留意產品及流程變動造成的漂移。

檢驗標準是減少調查，不是消滅分歧

營運成果是減少追查庫存差異的時間，同時令可用性、製作、補貨及撇帳決策更可靠。一項有效領先指標，是所選差異中有多少毋須反覆跨團隊追問，已能找到有來源連結的原因及負責人。

護欄同樣重要。被扣起、過期、致敏原未明或受其他限制的貨，不可因連接視圖更流暢便變成可用。另一項護欄是修正能否持續；若已解決的差異在更新後重現，改善的只是展示，不是控制。

若調查時間沒有下降、操作人員仍在系統外重建同一解釋，或模型產生的假異常多於現有檢討，這個做法便被推翻。此時，較好的投資可能是改善來源記錄、產品主數據紀律，或修復整合。

身份規則不只適用於庫存

同一原則支配幾種餐飲及食品工作流程：在機構能夠說明一項行動依賴哪個身份、營運狀態和權威來源之前，自動化不應對該項目採取行動。

對客戶庫存問題而言，這決定非正式語言是否已轉換成有效產品及製作狀態。因此，庫存核對不是獨立的資料清理工作；它建立日後客戶和製作行動依賴的身份鏈。

較簡單的控制有時已經足夠

只有一個可靠庫存系統、產品簡單而轉換少的小型營運，可能只需要清晰的庫存狀態定義及定期實物點算。若產品身份穩定，而且差異來自一個已知故障，直接同步仍是更合適的選擇。

當差異反覆跨越產品轉換、位置、品質及渠道邊界，連接模型才顯出價值。目的不是令所有數字一樣，而是在每項差異變成更多工作、錯誤決策或可避免的客戶問題之前，先讓它變得可理解。

資料來源

1. FAO 及 WHO Codex Alimentarius，實務守則
2. GS1，Traceability
3. NIST，AI Risk Management Framework