老闆拿到 OpenClaw 後的第一件事：公司底層營運數據，解決全通路零售數據儀表板「系統商」v.s「客製化」的兩難
老闆拿到 OpenClaw 後：把會員、流量、廣告、客服、YouTube 串成一條完整零售情報鏈，零售生意有了「全鏈視角」
上述兩篇文章是我用 Claude + Openclaw 以及整合 BigQuery 的資料做出「將數字變成數據」的各個工作與數據的儀表板，這偏向從數字 -> 數據。但數據 -> 洞察 -> 執行，也是零售業面臨最大的難題。坊間很多人在賣 AI Agent，或是開各種課程，但要解決「洞察」到「落地執行」，才是我最在乎的。
於是，我把原本搭建在 Telegram 的一個機器人(也可以視為一個 Agent)的使用模式，改成一個 AI 智能採購網頁。
從很多張試算表說起
公司的採購流程，長期依賴 POS 系統 + PowerBI 營運數據搭配，加上 PM 與採購團隊時時掌握各個品牌的銷售狀況，供貨狀況，加上他們自己手上各式 Excel 與試算表撐起了一年二、三億的採購金額。
隨著代理品牌數量增加，採購人員每週要比對銷售與庫存數字、對照過去幾個月的銷售紀錄，再用專業與經驗判斷決定要不要補、補多少。這個過程沒有錯，但它的問題是：人的判斷基準不一樣，以及超過 50 個供應商，上千個 sku，以及全通路(也超過 40 個通路) 的交錯，不可避免地就會出現熱賣品漏補、緩銷品過補的狀況反覆出現，伴隨著營收放大，以及代理經銷品牌數量增加，這件事只會越來越吃力。
我決定自己建一套採購管理系統，讓 AI 依據歷史銷售資料給出補貨建議，採購人員在這個基礎上調整、確認，再送出正式採購單。
系統現在(其實都是今天中午 12:30 到 15:30 發生的事)已經上線，這篇文章記錄整個建置過程，包括架構設計、AI 補貨模型的邏輯，以及我在過程中遇到的幾個離譜錯誤。
系統架構：BigQuery 當底、Flask 建構使用者介面
公司的所有銷售、庫存、採購資料再過去建構儀表板時，就執行了每日進銷存數據拋入 BigQuery（Google Cloud 的雲端資料倉儲）資料庫，過去建構 PowerBI 時也是如此，可以在最短時間將 AI 智慧採購系統的數據來源，直接接上 BigQuery。前端用 Flask（Python 的輕量網頁框架）做了一個 7 步驟的採購單精靈，採購人員登入後依序填：
- 申請人資訊（部門、姓名）
- 供應商（可輸入名稱、代碼或品牌名稱搜尋）
- 採購模式（AI 智能補貨，或專案採購手動加品項）
- 品項確認（確認 AI 建議清單，可調整數量）
- 時程（交貨日、前置時間、截止下單日）
- 備註（採購原因、優先程度）
- 預覽確認送出
登入走 Google OAuth，限定公司 email 網域，加上白名單限制才能進入。
核心：AI 補貨模型 – ABC 分類加上動態安全係數
加快流程當然是期待能夠創造的結果，但運用 AI 運算與合理的模型才是這套系統我認為關鍵的核心：把商品分級，然後依分級、週期，以及供應商的供給能力、前置期等因素計算建議補貨量。
分級用的是 ABC 分類法（一種依商品營收貢獻度排序的分析方式），標準如下：
- A 品：貢獻前 80% 累計營收的品項
- B 品：貢獻倒數 20% 到 5% 的品項
- C 品：貢獻最後 5% 的品項
- D 品：過往 12 週沒有任何銷售記錄
這個分類每次都是「滾動」計算(我發現很多人其實沒有滾動的觀念，都會急迫地想分清楚週期前後的差別…)，資料來源是過去 12 週的 BigQuery 銷售資料，不是靜態的歷史標籤。
有了分級之後，建議補貨量的公式我採用以下的算式為基礎：
cover_weeks = 補貨週期（週）+ 前置天數 ÷ 7
目標庫存 = 週均銷量 × cover_weeks × ABC 安全係數 × 檔期倍率
建議補貨量 = max(0, ceil(目標庫存 − 現有庫存))
其中 ABC 安全係數是這個模型的關鍵設計，而且它跟補貨週期連動：週期越長，係數越保守。
1 到 2 週補貨：A 品 ×1.05，B 品 ×1.02，C 品 ×1.00
4 週：A 品 ×1.05，B 品 ×1.00，C 品 ×0.98
8 週：A 品 ×1.00，B 品 ×0.95，C 品 ×0.90
12 週：A 品 ×0.90，B 品 ×0.85，C 品 ×0.75
26 週：A 品 ×0.80，B 品 ×0.73，C 品 ×0.63
邏輯是：補貨週期越長，代表這批貨要撐越久，但也代表中間有更多機會追單補貨，所以不需要靠高倍率製造緩衝，反而要更保守，避免長週期囤了太多。
D 品一律建議補貨量為 0，不進入計算(也得想怎麼清理吧)。
C 品降級機制：解決分類邊界的問題
ABC 是相對分類，C 品是「排序倒數 5%」的那批商品，但「落在 95% 到 100%」這個標準，並沒有保證這些商品有實際意義的銷售量。
實際跑下來，C 品裡會出現週均銷 0.1 件、12 週營收 NT$200 這種品項。它確實「有賣」，所以不是 D 品，但替它補貨沒有意義，它的庫存就算歸零也不會有人發現少了什麼。
所以我在 C 品裡加了降級門檻：只要週均銷量低於 0.5 件，或 12 週累計營收低於 NT$500，就自動降為 D 品，建議補貨量歸零，並在介面上標注降級原因。這樣採購人員看到的清單，只有真的需要管理庫存的品項。
建置過程中，我犯的幾個錯
這套系統從無到有大概花了半天的對話往返才把核心邏輯調對，中間出現幾個問題值得記錄下來。
錯誤一：短週期 A 品係數設太高
最一開始的版本，1 週補貨的 A 品係數是 ×1.50，B 品是 ×1.30。這個數字的出發點是「短期補貨要留緩衝」，但實際上不一定正確。
1 週補貨代表下週就會再訂一次，中間幾乎沒有缺貨風險，給 ×1.50 只是讓本週多囤了 50% 的貨，然後下週再多囤一批。反覆幾次，庫存會快速堆高。
修正後：短週期係數壓到非常接近 1.0（A 品 ×1.05，B 品 ×1.02），讓數量貼近實際需求，不製造人工緩衝。
錯誤二：進貨單價用市場售價
採購單上要顯示「採購單價」，最初的實作是從 BigQuery 的商品主檔（dim_product）抓 list_price，也就是建議零售售價。
這是個嚴重的錯誤。採購單的單價應該是進貨成本，不是售價。用售價算出來的採購總金額是虛數，完全無法對應實際的付款金額。
修正後：改從進貨記錄表（fact_purchase）抓每個品項最近一次的實際進貨成本，用這個數字當採購單價的預設值，採購人員可以手動修改。
錯誤三：幣別換算只是貼標籤
公司有些訂單是用美金或日圓結算。系統設計了幣別選項（TWD、USD、JPY 等），使用者可以切換，但第一個版本的問題是：切換完，金額完全沒有換算，只是把標籤從「TWD」換成「USD」，實際數字還是台幣金額。
這個問題沒有在開發過程中被主動發現，是在完成整個流程走一遍之後，看到一張標示 USD 但金額是 NT$35,000 的採購單，才意識到邏輯根本沒寫進去。
修正後：加入匯率輸入欄（1 外幣 = ? TWD），選擇非台幣幣別時，系統自動把所有品項的進貨成本（台幣）除以匯率，換算成外幣單價。每個品項同時保留原始台幣成本，切換幣別或修改匯率時，所有數字重新計算，整張採購單的金額始終一致。
錯誤四：5 步設計了一個沒有用的步驟
第一版流程的第五步是「選擇通路」，讓採購人員勾選這批貨要鋪去哪幾個通路（實體門市、91APP、蝦皮等）。
這個設計的出發點是想記錄通路分配計畫，但實際上這個資訊跟補貨建議完全沒有連動，只是讓採購人員多填一個沒有意義的欄位。而且通路鋪貨是倉儲的事，不是採購單要決定的。
一個讓流程更順的設計：時程自動帶入
第五步（現在的時程步驟）本來要採購人員手動填寫前置天數和預計交貨日。但在第三步的 AI 補貨設定裡，採購人員已經填過「前置時間」了。
所以修改後，進入時程步驟時，系統自動把第三步的前置時間帶過來，預計交貨日自動算成今天加上前置天數，截止下單日自動算成交貨日減掉前置時間。採購人員只需要確認或修改，不需要重新填一次。
這個改動沒有增加任何技術複雜度，卻讓流程減少了一次重複輸入。
最後加入的東西：AI 使用引導
系統的右下角有一個浮動的聊天視窗，是我們內部叫做「熊古錐」的 AI 助理介面，和 ERP 報表系統使用相同的視覺設計。
採購人員在操作過程中，可以直接問：「補貨週期選越長倍率越低是什麼意思？」「C 品為什麼會被降為 D 品？」「前置時間怎麼影響交貨日？」系統會即時回答，不需要查文件或等人解釋。
這個設計的邏輯很直接：一套系統有多少人真的會去讀操作說明？在需要的時候能問、能得到具體答案，比任何靜態文件都更有用。
這套系統現在能做什麼，還不能做什麼
可以做的：根據 12 週滾動銷售資料，依 ABC 分類和補貨週期自動算出建議補貨數量；進貨成本從 ERP 歷史進貨記錄抓取；支援多幣別換算；採購單可存草稿或送出；整個流程有版本紀錄。尤其，滾動的數據只要經過足夠長時間的運作，累積更多實際發生的數據，就能夠更優化整套模型的邏輯與算式，未來可以更精準地運用。
還不能做的：跨廠商比價、自動觸發採購（目前還是人工確認後送出）、和供應商系統直接對接。這些是下一階段的工作。
但我們現在至少解決了最核心的問題：補貨建議不再靠個人記憶和感覺，有資料基礎，有可以追溯的計算邏輯，有辦法解釋「為什麼建議補這個數量」。
建置這種系統最難的地方，不是技術，是把業務邏輯想清楚。那幾個錯誤出現的位置，正是業務邏輯模糊的地方。把它們找出來、修正，才算是真正把規則定義清楚了。
可以休息一下了。
コメント