AI 庫存預測是什麼？中小企業導入前的資料、流程與風險

庫存太少會缺貨、太多會占用現金與倉儲空間；這個問題從來不只靠「猜下個月會賣多少」就能解決。AI 庫存預測的價值，在於把歷史銷售、供應、現有庫存與營運條件整理成可檢查的需求估計，協助團隊判斷何時該補貨、哪些品項需優先處理，以及哪些預測其實不夠可靠。

但它不是自動下單的魔法按鈕。若資料把缺貨期間誤當成需求下降、沒有區分不同倉庫與商品變體，或忽略供應商交期，模型很可能給出看似精準、實際不適用的建議。中小企業導入時，應先建立可驗證的流程，再決定是否使用更複雜的 AI 模型。

AI 庫存預測是什麼？

AI 庫存預測是用過去按時間排列的交易與營運資料，估計未來某段期間的需求、庫存變化或缺貨風險，再讓採購、營運與倉儲人員據此安排補貨。模型可以是簡單的移動平均、季節性時間序列方法，也可以是結合更多特徵的機器學習模型；關鍵不在名稱是否叫 AI，而在輸入資料、預測範圍與決策規則是否清楚。

以 Microsoft Business Central 的銷售與庫存預測文件為例，系統會用歷史銷售資料預測未來銷售，並呈現可能的缺貨情況。文件也提醒：資料愈多通常愈有幫助；但若歷史資料不足或期間波動很大，服務可能無法產生預測。這正說明預測工具要被視為決策輸入，而不是不容質疑的答案。

先分清楚：預測、補貨規則與自動下單是三件事

很多導入失敗，是因為把三個不同層次混在一起。第一層是需求預測：估計某 SKU 在未來一週、一個月或一季可能賣出多少。第二層是庫存政策：把預測結合現有庫存、在途貨、最低安全庫存、訂購批量與供應商交期，算出需要處理的品項。第三層才是執行動作：建立採購建議、產生採購單或跨倉調撥。

前兩層可以較早導入，讓人員先比較預測與實際結果；第三層涉及資金、供應商與客戶承諾，應保留明確的權限與人工覆核。即使系統已能產生建議，也不代表每一筆建議都應自動執行。

一個安全的介面會把「預測」與「建議動作」分開顯示：前者標明預測期間、信心或不確定性與使用的資料；後者清楚列出庫存、在途貨、交期與規則如何形成建議。使用者應能修改、拒絕或延後建議，並留下理由。這些回饋日後既可改善流程，也能防止系統把臨時例外誤認為永久規律。

導入前先整理的六類資料

1. 可追溯的銷售與退貨紀錄

最基本的是每個 SKU、每個日期或週期的銷售量，並能辨識取消、退貨、贈品、內部調撥與一次性大單。若把不同性質的交易混成同一條時間序列，模型看見的不是正常需求，而是混雜的營運事件。

2. 現有庫存與在途供應

需求預測只回答「可能需要多少」，不能單獨決定「現在要買多少」。決策還要知道可用庫存、已保留數量、已下單但尚未到貨的數量，以及預計到貨日。缺少在途資料時，系統容易把已經補上的貨再算一次。

3. 交期、最小訂購量與補貨限制

不同供應商的交期與可靠度不同，同一個品項也可能受最小訂購量、箱規、保存期限或採購週期限制。這些限制不一定應交給模型學習，但必須明確寫進補貨規則，否則「預測正確」仍可能導致無法執行的採購建議。

4. 地點、變體與銷售通路

把不同倉庫、門市、顏色尺寸或通路全部合併，常會掩蓋真正的缺貨風險。Microsoft 的庫存預測報表文件也將地點、品項與交易類型列為分析維度。實務上要先決定預測要做到「全公司某品項」還是「某倉庫的某個變體」，粒度愈細，資料量與維護成本也愈高。

5. 促銷、節慶與異常事件

促銷、節慶、價格調整、缺貨、供應中斷與新品上市，都可能讓歷史曲線失真。這些事件可先以欄位或註記保存，不必一開始就全部交給模型；至少要讓分析者知道哪一段數字不宜當成正常需求。

6. 資料時間點與定義

「庫存」究竟是可售量、帳面量還是扣除保留後的可用量？「銷售日」用下單日、出貨日還是入帳日？這些定義一旦不一致，後續的準確率與補貨建議都會失去可比性。資料字典與更新時間應和預測結果一起被保存。

不要跳過基準線：先知道簡單方法做得多好

在購買新工具或訓練模型前，先建立一個容易理解的基準線，例如去年同週、近幾週平均，或按季節調整後的簡單預測。之後讓 AI 模型與基準線在相同資料切分、相同預測期間下比較。若複雜模型沒有穩定優於基準線，或改善幅度不足以抵消維護成本，就沒有必要急著擴大。

評估也不要只看單一平均誤差。高單價、長交期或容易缺貨的品項，錯一次的影響可能遠大於一般商品；極低銷量或零銷量品項，百分比誤差也可能失真。較好的做法是把指標和商業決策綁在一起：是否減少不必要的急單、是否降低可避免的缺貨、是否讓過量庫存更容易被看見，並同時保留誤差的原因分類。

特別要留意「缺貨造成的銷售資料」。某商品在貨架上沒有貨時，系統看到的可能是零銷售，但這不一定代表零需求。若沒有標註缺貨、停售或暫停上架期間，模型會把被供應限制壓低的銷售量學成正常水準，下一次又提出偏低的補貨建議。這類問題通常不是換模型能解決，而是要先補上事件資料與人工判讀。

同樣地，不要把預測誤差一概視為模型失敗。需求突然改變、採購設定錯誤、商品改版、價格調整、資料延遲與促銷漏標，都可能讓結果偏離。把原因分類後，團隊才能分辨該改善資料管線、調整庫存政策，還是調整模型本身。

從「預測」走到補貨建議，要經過可檢查的規則

可把補貨思考成一條透明的計算鏈：預測需求，加上安全緩衝，再扣除可用庫存與確認在途供應，最後依交期與訂購限制產出建議。實際公式會因產業不同而調整，但每個輸入都應能從系統回查。若人員無法解釋某個建議是因為需求上升、交期變長，還是資料缺漏，便不應直接執行。

安全庫存也不是固定的「保險數字」。它反映需求與交期的不確定性，以及缺貨的代價。對於停售風險低、可快速補貨的商品，緩衝可能較小；對於長交期、替代性低或影響核心客戶的品項，則需要更嚴格的人工檢視。系統應把這些政策顯示給使用者，而不是藏在黑箱規則裡。

小規模試行的實際做法

先選一組具代表性的 SKU：包含穩定銷售、季節性、波動較大與低周轉品項，並限定一個可控的倉庫或通路。設定一個明確預測期間，例如每週滾動看未來數週；接著將模型結果與既有方法並排，而不是立刻接管採購。

每次檢討時，記錄預測值、實際需求、庫存與在途量、採購人員的最終決定，以及拒絕或修改建議的原因。這些資料能用來發現規則缺漏、資料品質問題與模型偏差。只有在一段時間內證實結果可用、流程可追溯且例外能被處理後，才逐步擴大品項或提高自動化程度。

試行期間也應保留人工原本的作業方式，避免在沒有對照資料時就宣稱改善。每週或每月回顧時，可將「模型建議」、「人工最終決定」與「事後實際結果」放在同一份紀錄中。這樣即使決定暫停或更換工具，仍能保留可用的營運知識，而不是把經驗鎖在特定供應商或單一模型裡。

AI 治理：讓建議可追溯、可停止、可覆核

預測系統應記錄資料版本、模型或規則版本、預測產生時間、輸入範圍、評估結果與最終決策。這不只是工程習慣，也是營運風險控制。NIST AI Risk Management Framework強調把 AI 的風險管理納入設計、部署與持續監測；對庫存預測而言，最實際的落點就是知道建議從哪裡來、誰能覆核、何時必須停用。

可預先訂出停止條件：資料延遲、關鍵欄位缺失、模型誤差突然惡化、促銷或供應事件尚未被納入、建議金額超過權限，或系統要求建立不可回復的採購動作。出現這些情況時，系統應輸出待查清單並交給人員，而不是以舊資料繼續推論。