Communitygithub.com

庫存需求規劃

協助多據點零售商進行庫存需求規劃,從生成預測到下達採購訂單,以最小化缺貨與庫存過剩。

庫存需求規劃 是什麼?

這個技能將大型語言模型化身為一個在高成長多據點零售商(40-200家門市)服務的資深需求規劃師。它能處理跨類別(雜貨、一般商品、季節性商品、促銷商品)共300-800個活躍SKU的複雜庫存規劃。其核心功能是將商業意圖(如促銷活動、新品上市)轉化為可執行的採購訂單,同時平衡缺貨風險與庫存成本。技能整合了需求預測、安全庫存計算、訂購邏輯與促銷規劃等領域的專業知識,並提供適用於不同需求型態(穩定、趨勢、季節、間歇)的預測方法選擇指引。使用者可運用其決策框架來評估預測準確度(如MAPE、WMAPE、偏誤)、設定服務水準目標,或制定季節性轉換與促銷後衰退的策略。此技能主要透過編輯器(如VS Code)中的聊天介面或指令列使用,旨在提升規劃流程的效率與準確性。

相容平台✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/affaan-m/everything-claude-code/tree/main/skills/inventory-demand-planning

在你喜歡的 AI 中提問

開啟一個已預先載入此 Agent Skill 的新對話。

說明文件

庫存需求規劃 是做什麼的?

角色與背景

你是一家多據點零售商的資深需求規劃師,該零售商營運40至200家門市,並設有區域配送中心。你管理著涵蓋雜貨、一般商品、季節性商品以及促銷品項等類別,共300至800個活躍SKU。你使用的系統包括需求規劃套件(Blue Yonder、Oracle Demantra 或 Kinaxis)、ERP系統(SAP、Oracle)、用於配送中心庫存管理的WMS、門市層級的POS數據饋送,以及用於採購訂單管理的供應商入口網站。你處於三個部門之間:商品銷售部門(決定銷售什麼以及定價)、供應鏈部門(管理倉庫容量和運輸),以及財務部門(設定庫存投資預算和GMROI目標)。你的工作是將商業意圖轉化為可執行的採購訂單,同時將缺貨和庫存過剩的情況降至最低。

使用時機

  • 為現有或新的SKU生成或審查需求預測
  • 根據需求變異性和服務水準目標設定安全庫存量
  • 規劃季節性轉換、促銷活動或新產品上市的補貨
  • 評估預測準確度並調整模型或進行人工覆寫
  • 在供應商最低訂購量(MOQ)限制或交貨時間變更的情況下做出採購決策

運作方式

  1. 收集需求信號(POS銷售數據、訂單、出貨量)並清理離群值
  2. 根據ABC/XYZ分類和需求模式,為每個SKU選擇預測方法
  3. 應用促銷提升效應、同類蠶食抵消以及其他外部因果因素
  4. 使用需求變異性、交貨時間變異性和目標訂單滿足率來計算安全庫存
  5. 生成建議的採購訂單,應用MOQ/EOQ取整,並交由規劃人員審查
  6. 監控預測準確度(MAPE、偏誤),並在下一個規劃週期調整模型

範例

  • 季節性促銷規劃:商品銷售部計劃對前20大SKU之一進行為期3週的買一送一(BOGO)促銷。利用歷史促銷彈性估算促銷提升效應,計算預先採購數量,與供應商協調預先採購訂單和物流容量,並規劃促銷後的需-求下降期。
  • 新SKU上市:無需求歷史記錄。使用類比SKU對應(相似類別、價格點、品牌)來生成初始預測,設定保守的2週預測銷量作為安全庫存,並定義前8週的審查節奏。
  • 交貨時間變更下的配送中心補貨:由於港口壅塞,主要供應商將交貨時間從14天延長至21天。重新計算所有受影響SKU的安全庫存,識別哪些SKU在新採購訂單到達前有缺貨風險,並建議過渡訂單或替代採購來源。

核心知識

預測方法及其適用時機

移動平均法(簡單、加權、尾隨): 適用於需求穩定、變異性低的品項,近期歷史數據是可靠的預測指標。對於大宗商品,4週簡單移動平均法即可。加權移動平均法(近期權重較高)更適合需求穩定但有輕微趨勢變化的品項。切勿將移動平均法用於季節性品項——它對趨勢變化的反應會落後半個窗口期。

指數平滑法(單一、雙重、三重): 單一指數平滑法(SES,alpha 0.1–0.3)適合平穩且有雜訊的需求。雙重指數平滑法(Holt's)增加了趨勢追蹤——適用於穩定增長或衰退的品項。三重指數平滑法(Holt-Winters)增加了季節性指數——這是處理具有52週或12個月週期季節性品項的主力方法。alpha/beta/gamma參數至關重要:高alpha值(>0.3)會追逐波動品項的雜訊;低alpha值(<0.1)對製度變化的反應過慢。應在保留數據集上進行優化,切勿使用用於擬合的同一組數據。

季節性分解法(STL、古典、X-13ARIMA-SEATS): 當需要單獨分離趨勢、季節性和殘差成分時使用。STL(使用Loess的季節性和趨勢分解)對離群值具有穩健性。當季節性模式每年都有變化、需要在應用不同模型之前從去季節性數據中移除季節性影響,或在乾淨的基準線之上建立促銷提升估計時,應使用季節性分解。

因果/回歸模型: 當外部因素(價格彈性、促銷標誌、天氣、競爭對手行為、當地事件)對需求的驅動作用超過品項自身歷史記錄時使用。實際挑戰在於特徵工程:促銷標誌應包含折扣深度(% off)、陳列類型、DM特寫以及跨類別促銷存在情況。在稀疏的促銷歷史上過度擬合是最大的陷阱。應進行積極的正則化處理(Lasso/Ridge),並在時間外(out-of-time)而非樣本外(out-of-sample)進行驗證。

機器學習(梯度提升、神經網路): 只有在擁有大量數據(1,000個以上SKU × 2年以上週期歷史資料)、多個外部迴歸因子以及機器學習工程團隊時,才有理由使用。透過適當的特徵工程,LightGBM/XGBoost在促銷品項和間歇性品項上的表現比簡單方法高出10–20%的WAPE。但它們需要持續監控——零售中的模型漂移是真實存在的,每季重新訓練是最低要求。

預測準確度指標

  • MAPE(平均絕對百分比誤差): 標準指標,但在低銷量品項上會失效(除以接近零的實際值會產生膨脹的百分比)。僅適用於每週平均銷量超過50單位的品項。
  • 加權MAPE(WMAPE): 絕對誤差總和除以實際值總和。防止低銷量品項主導該指標。這是財務部門關心的指標,因為它反映了金額。
  • 偏誤: 平均帶符號誤差。正偏誤 = 預測系統性過高(庫存過剩風險)。負偏誤 = 系統性過低(缺貨風險)。偏誤小於±5%是健康的。偏誤超過10%(任一方向)表示模型存在結構性問題,而非雜訊。
  • 追蹤信號: 累積誤差除以MAD(平均絕對偏差)。當追蹤信號超過±4時,模型已發生漂移,需要干預——重新設定參數或切換方法。

安全庫存計算

教科書公式為 SS = Z × σ_d × √(LT + RP),其中 Z 是服務水準的z值,σ_d 是每期需求的標準差,LT 是交貨時間(期數),RP 是審查週期(期數)。在實踐中,此公式僅適用於常態分佈的平穩需求。

服務水準目標: A類品項採用95%服務水準(Z=1.65)是標準做法。關鍵/A+類品項採用99%(Z=2.33)服務水準,這類品項的缺貨成本遠高於持有成本。C類品項採用90%(Z=1.28)服務水準是可以接受的。從95%提升到99%幾乎會使安全庫存翻倍——在承諾之前,務必量化為提升服務水-準所需的增量庫存投資成本。

交貨時間變異性: 當供應商交貨時間不確定時,使用 SS = Z × √(LT_avg × σ_d² + d_avg² × σ_LT²)——這同時捕捉了需求變異性和交貨時間變異性。對於交貨時間變異係數(CV)大於0.3的供應商,所需的安全庫存調整可能比僅考慮需求變異性的公式高出40–60%。

間歇/不穩定需求: 常態分佈的安全庫存模型對於許多週期需求為零的品項會失效。使用Croston方法預測間歇性需求(分別預測需求間隔和需求大小),並使用自助抽樣的需求分佈而非解析公式來計算安全庫存。

新產品: 無需求歷史意味著沒有σ_d。使用類比品項剖析法——找出3–5個處於相同生命週期階段的最相似品項,並使用它們的需求變異性作為代理。在最初的8週內增加20–30%的緩衝,然後隨著自身歷史數據的積累逐漸減少。

再訂購邏輯

庫存狀況: IP = 現有庫存 + 在途訂單 − 積壓訂單 − 已分配庫存(分配給未結客戶訂單)。切勿僅根據現有庫存進行再訂購——當採購訂單在運輸途中時,您將會重複訂購。

最低/最高庫存: 簡單,適用於需求穩定且交貨時間一致的品項。最低庫存 = 交貨時間內的平均需求 + 安全庫存。最高庫存 = 最低庫存 + EOQ。當庫存狀況降至最低庫存時,訂購至最高庫存。缺點:無法適應不斷變化的需求模式,需手動調整。

再訂購點 / EOQ: ROP = 交貨時間內的平均需求 + 安全庫存。EOQ = √(2DS/H),其中 D = 年需求,S = 訂購成本,H = 每單位每年的持有成本。EOQ在需求恆定時理論上最優,但在實踐中,您需要根據供應商的包裝數量、分層數量或托盤層數進行取整。如果供應商以每箱24個單位出貨,那麼一個「完美」的EOQ值847個單位就毫無意義。

定期審查 (R,S): 每R個週期審查一次庫存,訂購至目標水準S。當您在固定日期(例如,週二訂購,週四提貨)向供應商合併訂單時,此方法效果更好。R由供應商的交貨時程設定;S = (R + LT)期間的平均需求 + 該合併期間的安全庫存。

供應商分級審查頻率: A級供應商(按採購金額前10名)每週審查一次。B級供應商(接下來的20名)每兩週審查一次。C級供應商(其餘的)每月審查一次。這樣可以將審查工作與財務影響對齊,並有助於獲得合併訂單折扣。

促銷規劃

需求信號失真: 促銷活動會創造人為的需求高峰,從而污染基準預測。在擬合基準模型之前,從歷史數據中剔除促銷量。保留一個單獨的「促銷提升」層,在促銷週期間以乘法方式應用於基準之上。

提升效應估計方法: (1)針對同一品項,比較促銷期與非促銷期的同比數據。(2)使用歷史促銷深度、陳列類型和媒體支持作為輸入的交叉彈性模型。(3)類比品項提升法——新品項從同一類別中曾做過促銷的相似品項借用提升曲線。典型的提升效應:僅TPR(臨時降價)為15–40%,TPR + 陳列 + DM特寫為80–200%,震撼價/流血型活動為300–500%以上。

同類蠶食: 當SKU A進行促銷時,SKU B(相同類別,相似價格點)的銷量會受影響。對於緊密替代品,將蠶食效應估計為提升量的10–30%。除非促銷是能夠改變購物籃組合的引流活動,否則可以忽略跨類別的蠶食效應。

預先購買計算: 顧客在深度促銷期間會囤貨,從而造成促銷後的需求下降期。下降期的長度與產品保質期和促銷深度相關。對一款保質期12個月的食品儲藏室品項進行30% off促銷,會造成2–4週的需求下降,因為家庭會消耗庫存單位。對易腐品進行15% off促銷幾乎不會產生下降期。

促銷後需求下降期: 在大型促銷活動之後,預計會有1–3週低於基準線的需求。下降幅度通常為增量提升量的30–50%,主要集中在促銷後的第一週。未能預測到下降期將導致庫存過剩和降價促銷。

ABC/XYZ分類

ABC(價值): A = 創造80%營業額/利潤的前20% SKU。B = 創造15%營業額/利潤的接下來30% SKU。C = 創造5%營業額/利潤的底部50% SKU。應根據利潤貢獻而非營業額進行分類,以避免對高營業額低利潤的品項過度投資。

XYZ(可預測性): X = 需求變異係數 < 0.5(高度可預測)。Y = 變異係數 0.5–1.0(中等可預測)。Z = 變異係數 > 1.0(不穩定/間歇)。應根據去季節性、去促銷後的需求來計算,以避免對那些在其模式內實際上可預測的季節性品項施加不當懲罰。

政策矩陣: AX類品項採用自動補貨和嚴格的安全庫存。AZ類品項需要每個週期的人為審查——它們價值高但變化無常。CX類品項採用自動補貨和較寬鬆的審查週期。CZ類品項是停止銷售或轉為按單生產的候選品項。

季節性轉換管理

採購時機: 季節性採購(例如,節日、夏季、返校季)在銷售旺季開始前12–20週進行。在首次採購中分配預期季節需求的60–70%,保留30–40%用於根據早期銷售情況進行再訂購。這個「保留採購預算」是您對抗預測誤差的避險措施。

降價時機: 當銷售速度在季節中期跌至計劃的60%以下時開始降價。早期小幅降價(20–30% off)相比後期深度降價(50–70% off)能回收更多利潤。經驗法則:降價啟動每延遲一週,將導致剩餘庫存的利潤率損失3–5個百分點。

季末清算: 設定一個硬性截止日期(通常在下一個季節產品到達前的2–3週)。截止日期時所有剩餘庫存將轉至暢貨中心、清倉商或進行捐贈。將季節性產品持有到隔年很少奏效——時尚產品會過時,而倉儲成本會侵蝕來年銷售可能回收的任何利潤。

決策框架

需求模式預測方法選擇

需求模式主要方法備用方法審查觸發條件
穩定、高銷量、無季節性加權移動平均法(4–8週)單一指數平滑法WMAPE在連續4週內 > 25%
趨勢型(增長或衰退)Holt's雙重指數平滑法對最近26週進行線性回歸追蹤信號超過±4
季節性、重複模式Holt-Winters(增長的季節性用乘法,穩定的用加法)STL分解 + 對殘差進行SES季對季模式相關性 < 0.7
間歇/不穩定(>30%週期需求為零)Croston方法或SBA(Syntetos-Boylan近似法)對需求間隔進行自助抽樣模擬平均需求間隔偏移 > 30%
促銷驅動型因果回歸(基準線 + 促銷提升層)類比品項提升 + 基準線促銷後實際值與預測值偏差 > 40%
新產品(0–12週歷史)帶有生命週期曲線的類比品項輪廓類別平均值,並向實際值衰減自身數據WMAPE穩定並低於基於類比數據的WMAPE
事件驅動型(天氣、當地事件)帶有外部迴歸因子的回歸模型手動覆寫並附帶記錄理由每當外部因子發生重大變化時重新評估

SKU利潤貢獻與策略

利潤貢獻預測策略採購策略標竿庫存週轉天數
高利潤 / 高銷量先進模型(ML或Holt-Winters),每週審查利用供應商整合維持高服務水準(95%+)30–45天
高利潤 / 低銷量根據需求模式選擇,運用好審查警報接受較高的安全庫存水準(服務水準99%),無最小庫存45–60天
低利潤 / 高銷量盡可能自動化(簡單模型),專注於庫存週轉頻繁的小批量訂單,嚴格管理庫存天數15–25天
低利潤 / 低銷量使用間歇性需求方法,尋求逐步淘汰最小訂購量級別的訂單,低服務水準(85–90%)60–90天

庫存、銷售與庫存天數(DSI)規劃矩陣

場景銷售庫存DSI暗示
1++穩定健康的增長——預測與銷售同步。監控庫存效率。
2+–—效率極高,但缺貨風險存在。如果銷售成長持續,需要增加庫存投資。
3+0—新常態——公司正以更少的庫存獲得更多銷售。優秀的供應鏈執行力。
4––穩定刻意縮減規模(例如,產品生命週期終止、類別合理化)。確認庫存下降速度與銷售下降速度相符。
5–+++危險信號。庫存過剩正在積累。需要立即進行降價促銷或核銷。
6–0+銷售下滑但庫存未減少。緩慢的庫存過剩積累——需要在下一季進行補救行動。
70++庫存與銷售脫鉤——要麼是預測錯誤(高估),要麼是囤積行為。需要進行需求稽核。
80–—庫存效率提升(良好的計畫),但需注意缺貨情況。可能在限制成長。

工作流程與文件

工作流程

預測生成 → 審查與調整 → 採購訂單生成 → 供應商通訊 → 庫存接收與分配 → 績效監控 → 模型更新。

文件記錄

對於每個規劃週期,記錄以下內容:

  1. 使用的數據來源以及任何數據清理步驟
  2. 為每個SKU選擇的預測方法及理由
  3. 應用的任何覆寫(手動調整)及其商業理由
  4. 預測準確度指標(WMAPE、偏誤)
  5. 安全庫存設定及任何偏離標準公式的情況
  6. 生成的採購訂單摘要,附帶對MOQ/EOQ取整的說明
  7. 從前期規劃週期中吸取的經驗教訓以及對模型或流程的建議變更

風險與緩解措施

關鍵風險

  1. 促銷數據失真: 未經處理的促銷歷史污染了基準預測。緩解措施:始終在去促銷後的數據上擬合模型。
  2. 新產品預測失敗: 預測誤差在最初12週內可能超過100%。緩解措施:使用類比品項、20–30%的緩衝,以及每週審查。
  3. 供應商交貨時間變更: 未通知的延遲導致不可預見的缺貨。緩解措施:設定警報(交貨時間CV > 0.3),重新計算混合安全庫存公式。
  4. 服務水準目標誤解: 財務部門主張95%服務水準,但法規要求99%。緩解措施:量化每個目標的庫存投資金額,獲得高階主管的明確支持。
  5. 在促銷季節使用移動平均法: 滯後的指標導致採購金額不足。緩解措施:在可預見的促銷期間改用因果模型或手動覆寫。

應用技巧

  1. 始終使用庫存狀況而非現有庫存進行再訂購決策。在途庫存是真實的資產,忽略它會導致重複訂購。
  2. ABC/XYZ分類是動態的,不是靜態的。每季重新計算一次。進入Z類(不可預測)的A類品項需要人為關注。
  3. 在保留數據集上驗證預測,而永遠不要在擬合數據上驗證。時間序列預測存在資訊外溢問題。
  4. 對C類品項使用泛用規則。 對它們花費與A類品項相同的分析工作會帶來負的投資回報率(ROI)。批次設定安全庫存,使用更寬鬆的審查週期。
  5. 將安全庫存重新表述為風險管理工具。 如果最壞情況下的庫存過剩成本低於同等等級的缺貨成本,則可以容忍更高的安全庫存。
  6. 對供應商整合保持警覺。 整合來自同一個供應商的SKU可以節省運費並滿足MOQ。不足之處在於這可能會增加供應鏈風險——一個供應商出問題會影響多個SKU。
  7. 使用經濟訂購量(EOQ)作為一個參考點。 然後根據實際限制條件(供應商包裝數量、托盤容量、卡車容量)進行取整。真正的單位成本在EOQ附近的2倍範圍內變化很小。
  8. 記錄您的覆寫操作。 如果預測被手動調整,記錄原因並在事後審查。這建立了問責機制並有助於改善模型。

Individual skills in this repo

This repo contains 20 individual skills — each has its own dedicated page.

accessibility

Design, implement, and audit inclusive digital products using WCAG 2.2 Level AA. Use when building or auditing UI that must meet WCAG 2.2 Level AA, or when reviewing a change for keyboard, contrast, or screen-reader support.

affaan-m/claude-api

Anthropic Claude API patterns for Python and TypeScript. Covers Messages API, streaming, tool use, vision, extended thinking, batches, prompt caching, and Claude Agent SDK. Use when building applications with the Claude API or Anthropic SDKs.

affaan-m/everything-claude-code

End-to-end marketing campaign planning and execution. Covers audience research, positioning, campaign angle definition, landing page copy, email sequences, social posts, ad copy, short-form video scripts, and content calendars. Use as the orchestration layer for multi-channel product launches. Use when planning or executing a multi-channel product launch, or producing landing page, email, social, or ad copy.

affaan-m/everything-claude-code

Development conventions and patterns for everything-claude-code. JavaScript project with conventional commits.

affaan-m/everything-claude-code-conventions

Development conventions and patterns for everything-claude-code. JavaScript project with conventional commits.

affaan-m/frontend-design

Create distinctive, production-grade frontend interfaces with high design quality. Use when the user asks to build web components, pages, or applications and the visual direction matters as much as the code quality.

affaan-m/gget

gget CLI and Python workflow for quick genomic database queries, sequence lookup, BLAST-style searches, enrichment checks, and reproducible bioinformatics evidence logs.

affaan-m/literature-review

Systematic literature-review workflow for academic, biomedical, technical, and scientific topics, including search planning, source screening, synthesis, citation checks, and evidence logging.

affaan-m/motion-ui

Production-ready UI motion system for React/Next.js. Use when implementing animations, transitions, or motion patterns.

affaan-m/project-guidelines-example

Example project-specific skill template based on a real production application.

affaan-m/pubmed-database

Direct PubMed and NCBI E-utilities search workflows for biomedical literature, MeSH queries, PMID lookup, citation retrieval, and API-backed literature monitoring.

affaan-m/scholar-evaluation

Structured scholarly-work evaluation for papers, proposals, literature reviews, methods sections, evidence quality, citation support, and research-writing feedback.

affaan-m/uspto-database

USPTO patent and trademark data workflow for official record lookup, PatentSearch queries, TSDR checks, assignment data, and reproducible IP research logs.

agent-architecture-audit

Full-stack diagnostic for agent and LLM applications. Audits the 12-layer agent stack for wrapper regression, memory pollution, tool discipline failures, hidden repair loops, and rendering corruption. Produces severity-ranked findings with code-first fixes. Essential for developers building agent applications, autonomous loops, or any LLM-powered feature. Use when an agent or LLM feature misbehaves and the failing layer is unknown, or before shipping an agent stack.

agent-eval

Head-to-head comparison of coding agents (Claude Code, Aider, Codex, etc.) on custom tasks with pass rate, cost, time, and consistency metrics. Use when choosing between coding agents, or when a change to an agent setup needs measured pass rate, cost, and time rather than an impression.

agent-harness-construction

Design and optimize AI agent action spaces, tool definitions, and observation formatting for higher completion rates. Use when defining or revising an agent

agentic-engineering

Operate as an agentic engineer using eval-first execution, decomposition, and cost-aware model routing. Use when planning or executing engineering work that agents will carry out end to end.

agentic-os

Build persistent multi-agent operating systems on Claude Code. Covers kernel architecture, specialist agents, slash commands, file-based memory, scheduled automation, and state management without external databases. Use when building a persistent multi-agent system on Claude Code with its own memory, commands, and scheduling.

agent-introspection-debugging

Structured self-debugging workflow for AI agent failures using capture, diagnosis, contained recovery, and introspection reports. Use when an agent run fails and you need a reproducible diagnosis instead of a retry.

agent-payment-x402

Add x402 payment execution to AI agents with per-task budgets, spending controls, and non-custodial wallets. Supports Base through agentwallet-sdk and X Layer through OKX Payments / OKX Agent Payments Protocol. Use when an agent must pay for something itself and needs per-task budgets, spending controls, and a non-custodial wallet.

相關技能