一批貨還在路上，客戶的訂單卻先進來了；倉庫另一頭，又堆著幾個月都賣不完的商品。安全庫存設得太低，補貨可能趕不上；留得太多，現金又卡在庫存裡。與其先猜「多留幾件比較安心」，不如先把需求、供應時間和可用庫存的算法說清楚。
以下分成六個步驟，整理可以怎麼判斷。公式和數字都是教學示例，實際補貨規則仍要依商品、供應商條件和公司資料調整；這套算法不保證完全不缺貨。
先分清安全庫存與訂購批量
先分清安全庫存與訂購批量：要先核對哪些資料與適用條件？
安全庫存是為了應付預估之外的需求或供貨延遲，先留下一段緩衝；訂購批量則是每次下單要買多少。兩者都會影響庫存，但回答的是不同問題。若把「要多留多少」和「一次買多少」混成一個數字，MOQ、箱裝單位或運費等採購條件，就可能被誤當成需求緩衝。
先挑一個 SKU，確認計量單位、需求紀錄期間、供應商交期、現有庫存的計算口徑，以及已下單但還沒到貨的數量。這種簡化檢查較適合有可追溯銷售或領用紀錄、補貨方式也相對固定的商品。季節品、客製品、一次性需求或保存期限短的品項，要另外註明假設，不宜直接套用同一個水位。
每次採購量也要另外核對最低訂購量、包裝換算、保存期限、供應商限制和公司能接受的資金占用。若商品必須整箱下單，就保留換算後的實際採購單位；不要只為了讓公式整齊，就改寫需求數字。
先分清安全庫存與訂購批量：具體步驟、例外及可交接的結果是什麼？
資料表可以先分成兩欄：「安全緩衝量」和「每次訂購量」。接著寫清楚緩衝量是為了應付什麼情況、訂購量受哪些條件限制，再記下採用的資料日期和負責人。若供應商調整 MOQ、產品快到期，或一次下單量超出原先規劃，就把它列為例外，交由採購或核准人決定，不要直接加進安全庫存裡。
交接紀錄至少要有 SKU、計量單位、緩衝量、訂購量、資料期間、採用假設、例外原因和核准人。Microsoft 的補貨文件也把再訂購點、安全庫存和最大庫存等設定分開說明。這是特定軟體的設定範例；每家企業仍要先定義自己的計算口徑。Microsoft Dynamics 365 優先規劃文件
核對需求交期與庫存位置
核對需求交期與庫存位置：要先核對哪些資料與適用條件？
需求資料要先對得上商品單位和時間區間。假如銷售紀錄用「箱」，庫存卻用「件」，就先確認換算方式。資料若涵蓋促銷、旺季或一次性大單，也要標記出來，免得把特殊時段當成平常需求。銷售、領用、退貨和預測可以分欄保存，先別把不同來源混成一個平均數。
交期也不宜只抄供應商報價上的天數。記錄從下單到貨物完成驗收、實際能用於出貨或生產的時間；同時保留每次實際到貨日期，才能看出承諾交期和實際交期有沒有落差。工作日和日曆日要分清楚，計算需求期間時也要用一致的單位。
庫存位置則要有明確狀態，例如現場可用、已預留、在途、待驗收、品質異常或退貨。先說清楚哪些算可用、哪些只是預期供應，才不會把已分配給客戶的貨再算一次。POS、Excel 或庫存管理工具都可能是資料來源，但它們只是市場上常見的工具；資料是否完整，還是得回到實際紀錄確認。
核對需求交期與庫存位置：具體步驟、例外及可交接的結果是什麼？
挑一個 SKU 和一個倉庫，先定下資料截點，再逐項比對系統帳面數、現場盤點、已預留數量、在途採購和跨倉調撥。若實際數量與紀錄不符，不要直接覆蓋舊數字；先記下差異、可能原因、確認人和修正時間。
待驗收、破損、品質異常、退貨中，或還沒有確認到貨日的貨物，都要依公司的定義標示狀態，不能預設它們能及時滿足需求。交接表要列出 SKU、單位、倉庫、數量、狀態、資料截點、交期來源和待釐清的差異。接手的人應看得出哪些數字已核對，哪些仍是預估。
用簡化教學假設計算再訂購點
用簡化教學假設計算再訂購點：要先核對哪些資料與適用條件？
先確認每日需求、交期和庫存都使用同一個單位，再決定需求期間採工作日還是日曆日。簡化教學模型可以寫成：再訂購點約等於交期內需求，加上明確列出的安全緩衝量。Microsoft Dynamics 365 的優先規劃文件也用交期內需求加最低數量（安全庫存）示範再訂購點。這是該軟體設定中的說明，不是所有公司的通用標準。Microsoft Dynamics 365 優先規劃文件
這種直觀算法適合拿來教學和檢查輸入值，但它不代表需求穩定、交期一定準時，也不會自動處理季節波動、缺貨造成的紀錄偏差或不同商品的風險。若需求或交期起伏明顯，就接著分開檢視下一節提到的因素；不要只把平均值代進去，就認為問題已經算完。
用簡化教學假設計算再訂購點：具體步驟、例外及可交接的結果是什麼？
假設某商品平均每天需求 8 件／工作日，補貨需要 5 個工作日，企業暫時留 20 件作為教學用緩衝。交期內需求是 8 × 5 = 40 件；示例中的再訂購點就是 40 + 20 = 60 件。這些數字純為演算假設，不是市場統計、建議水位或不缺貨承諾。若資料採日曆日，需求也必須按相同的日曆口徑重算。
實際操作前，還要定義觸發依據：是帳面現有量、可用量，還是扣除已承諾需求並納入確認在途供應後的庫存位置。不同系統對預計庫存和安全庫存的處理方式可能不同，不能光看欄位名稱就推定含義。把輸入值、公式、資料期間、庫存口徑、限制、資料日期和覆核人放在同一份紀錄；下單量仍要另外考量包裝和採購限制。
需求與交期波動要另外估
需求與交期波動要另外估：要先核對哪些資料與適用條件？
平均需求和平均交期有時會把重要差異蓋掉。先列出各期間的需求量和每次實際到貨時間，再標記促銷、季節、停工、缺料或供應商改期等事件。看看需求高低和交期長短是否常同時出現，也確認同一個 SKU 有沒有混到不同規格或客群。若資料口徑變了，數字就不宜直接比較。
接著確認這項商品是否能用相同方式補貨。若供應商交期常變、需求受季節影響，或一次缺貨就會卡住後續流程，光看平均值可能不夠。可以把一般期間、需求偏高期間和交貨較慢期間分開檢視。這不是要任意挑最壞狀況，而是讓負責人看清楚不同假設會怎麼影響觸發水位和資金占用。
不要套用沒有查核依據的固定安全係數、服務水準，或「一定不會缺貨」的說法。若要使用機率或服務水準模型，得先確認資料品質、模型假設，以及公司能接受的缺貨與庫存成本；必要時請具備相應專業的人員覆核。
需求與交期波動要另外估：具體步驟、例外及可交接的結果是什麼？
先把需求偏差和交期偏差分開對照。需求方面，標出一般區間、明顯高峰和已知活動；交期方面，列出每次下單日、可用日和延遲原因。再看看需求與交期同時偏高時，原本的假設是否還能支撐補貨決定。若採購條件改變，先列為供應例外，不要只改公式中的一個數字。
負責人要決定採用哪些情境、可以接受多少資金占用，以及遇到什麼狀況必須升級核准。交接紀錄要寫明波動來源、使用期間、情境設定、未採用的資料、調整理由、覆核條件和責任人。之後資料增加或供應商改變，再更新這些判斷；不要把一次設定永久沿用。
缺貨資料與新品怎麼處理
缺貨資料與新品怎麼處理：要先核對哪些資料與適用條件？
缺貨期間沒有成交，不代表客戶沒有需求。若只看已出貨或已領用數量，可能會漏掉因缺貨而沒有成立的訂單。這是根據交易資料形成方式所做的流程判斷，不是特定軟體對缺貨需求的保證。把未交訂單、候補、詢價、取消原因和第一線紀錄分開核對，並註明來源和可信程度；只有能確認的資料才列入實際紀錄。
新品沒有自己的歷史紀錄時，可以暫時參考相近商品，但要說明相似之處是用途、客群、售價區間、季節或供應條件中的哪一項，也要列出差異。參考商品的銷量並不是新品已觀察到的需求。若找不到合適的對照，或缺貨紀錄散落在不同人手上，就把未知資訊寫清楚，交由負責人決定要先小量採購、等待更多資料，或採取其他做法。
Microsoft 的安全庫存計算文件指出，其歷史使用量提案是依特定期間的出庫交易計算。因此，企業若曾缺貨，就有理由另外查找未成交的需求線索。前一句是文件所述；後一句是資料完整性的提醒，不是 Microsoft 對所有缺貨資料的結論。Microsoft 安全庫存日誌說明
缺貨資料與新品怎麼處理：具體步驟、例外及可交接的結果是什麼？
對缺貨品，先記錄缺貨起訖、當時的可用量、未交訂單，以及取消或延期紀錄；能確認的需求和估算值要分欄保存。不要把缺貨期間的零出庫直接填成零需求，也不要把未核實的口頭回憶當成確定銷售量。若不同來源互相矛盾，就留下差異並指定待確認人。
對新品，記下暫時參考的商品、採用理由、明確差異和第一次檢視的條件。若依據不足，就把決定列為例外，讓負責人確認風險與採購方式。交接表要列出資料缺口、估算依據、文字描述的信心水準、下一次檢視條件和決策人；不要拿推測的銷售結果填補空白。
試跑後更新水位與補貨責任
試跑後更新水位與補貨責任：要先核對哪些資料與適用條件？
先挑資料能核對、補貨方式也相對清楚的 SKU 試跑，不必一次把所有商品都套上新水位。試跑期間記下缺貨事件、緊急採購、庫存差異、延遲到貨和人工覆寫原因。若採購或倉庫人員手動調整觸發點，也要留下日期、原值、新值和原因，否則事後很難看出設定何時偏離原先假設。
檢視時間要配合公司的補貨週期和資料更新頻率，沒有一個適用所有人的固定頻率。每次檢視時，可以問三件事：需求與交期資料還能代表目前情況嗎？庫存口徑一致嗎？現有設定造成的例外能接受嗎？若商品改版、供應商更換、訂購單位改變或需求型態明顯不同，就提早重估，不必等到例行檢視。
責任要落到人：誰維護需求資料、誰核對庫存、誰計算水位、誰核准例外、誰下單，以及問題要升級給誰。安全庫存不會自行更新；流程要持續運作，得有人知道何時檢查、要看哪份資料，以及如何留下決策紀錄。
試跑後更新水位與補貨責任：具體步驟、例外及可交接的結果是什麼？
跑過一段實際補貨週期後，回頭檢查需求和交期假設是否成立，再把缺貨、延遲、緊急採購和多餘庫存等狀況連回原始紀錄。只有資料與情境都支持時，才調整緩衝量或訂購量。每次變更都要記下日期、舊值、新值、理由、核准人和生效範圍。若遇到一次性大單或特殊活動，先判斷它是否代表常態，再決定要不要改長期水位。
交接表最後要能回答：哪些 SKU 正在試跑、觸發點依據哪些資料、訂購量受什麼條件限制、例外由誰處理，以及下次何時或遇到什麼情況要重新檢視。若資料不完整、供應中斷或帳面庫存與實際數量不符，就先走例外流程；表格裡有數字，不代表可以自動下單。
需要把方法套用到自己的企業時，可完成官方商戰思維測驗或了解工作坊。