安全庫存 @ 伊風的網站

文章出處: Taiwan Logistics

安全庫存是爲了應對不確定性。
有人說，那把預測適當拔高點，不也同樣解決問題？
其實不然。

首先，傳遞的需求信號不同。
假定需求預測是每週100個，安全庫存是130個。
這傳遞給供應鏈的信號是，每週給我按照100個來準備産能；
同時，我有個一次性的需求130個，這是安全庫存，你幫我一次性備齊以防不測。
這樣，供應商會按照100個/週來備産能和原材料庫存，對於那130個的安全庫存，他們會以加班加點的方式一次性解決，影響的是供應鏈的短期運營成本。

但如果適當“拔高”預測，比如把這130個的安全庫存分攤到未來三個月（13週），每週分攤10個，那麽需求預測就變成110個每週，供應商就得按照這個來準備産能，中長期産能就多備了10%，導致産能利用率低下，長期成本上升。

其次，在SAP這樣的ERP軟件裏，對待安全庫存和需求預測的方式不同：
安全庫存是“永久需求”，一直在那裏，一旦庫存低于安全庫存水位，ERP就會産生“需求”，驅動供應鏈補貨；
預測則相對“虛”多了，根據用戶的設置，過段時間沒用的話就可以自動刪除，驅動供應鏈來取消或延遲補貨訂單，並且把手頭的多餘庫存用於別處。

對於不熟悉ERP的人來說，這比較難以理解。讓我們繼續上面的例子。
假定你不設安全庫存，而是把預測由100調到110個/週，而真實需求是100個/週，這樣每週就平均有10個是“多餘”的，SAP的邏輯是先幫你留著，萬一需求滯後的話。
但也不會無限期留著啊，比如留了3週以後（用戶可設置），發現需求仍然沒來，SAP就認爲，看來這個産品預測過高了，便把這“多餘”的10個預測給自動取消了，同時傳遞信號給供應鏈，說我們預測虛高了，這裏要取消10個的訂單。那供應商就給你少造10個。
這也意味著實際的安全庫存是30個，因爲在這裏，按照用戶設置，SAP只保留3週的“多餘”預測，即3乘以10等于30。
等到不測發生時，你發現你手頭該有的安全庫存沒有，因爲你的實際安全庫存遠低于應該設置的值。

當然，在那些管理粗放，ERP沒有這功能，或者有但純粹不用的企業，這就不是問題，“傻人有傻福”，對吧？
不要高興得過早：該流的汗總是要流的，麻煩在那裏，總是會造成問題。
舉個例子。
有一次，我們幫助一個企業改進需求預測和庫存計劃，幾位銷售拉住我們不放手，糾纏來糾纏去，老半天才弄明白是兩個問題：
過剩預測的調整和安全庫存不夠“安全”，跟我們上面談的兩個問題都相關。

這個公司是典型的銷售兼職計劃，把安全庫存分攤到需求預測中。
需求預測虛高的話，成了過期需求，就得刪掉一些，不然一直掛在那裏，驅動供應。
但究竟哪些該刪（真正的過剩），刪多少；
哪些要保留（安全庫存），保留多久，沒用ERP的功能，全靠人工判斷，一筆糊塗帳，很難算清。

這幫銷售還弄不明白的是，明明設了“安全庫存”，但總覺得不夠“安全”——經常短缺，被客戶投訴。
他們的感覺沒錯：
本來這130個的安全庫存，要求供應商馬上就送過來的；
現在攤到未來13週送來，實際安全庫存遠比要求的要低，不短缺才怪了。

那解決方案呢，就是需求預測和安全庫存要“上帝的歸上帝，凱撒的歸凱撒”，不要混在一起，人爲地增加不確定性。
要知道，需求預測和安全庫存相輔相成，前者對付的是平均需求，後者對付的是不確定性。
這是兩個不同的概念，應該分開處理。