庫存計劃的優化：組織和系統的博弈

前面說過，庫存計劃就是賭博，放在「長尾」需求上尤其如此。我們都是賭徒，但要像賭場那樣去賭，提高總體贏面。庫存優化的目標就是全局優化（贏得戰爭），從統計學的角度增加整體的勝算，以最小的庫存投資來達到整體的服務水平目標，而不是局部優化（贏得戰鬥），執迷於一城一池的得失。

比如企業有幾千個產品，大部分是「長尾」產品，需求低、周轉慢。該企業希望達到的整體有貨率是95%，即客戶訂貨時，95%的情況下手頭立即有庫存。如何投資才能使庫存金額最低？優化的邏輯其實很簡單：越是便宜的越多備，這些產品的有貨率高；越是貴的越少備，這些產品的有貨率低；但兩者結合，既能達到整體的有貨率，同時總體庫存最低。我們的挑戰呢，是成千上萬的產品，單價不同，需求歷史不同，究竟哪些多備，哪些少備，備多少，可能的組合有千千萬萬，最後試出個最優組合來。你一眼就看得出，這可不是Excel表格能對付得了的。

市面上有庫存計劃軟體，不過大都是針對單個產品的，即可以計算單個產品的庫存水位和服務水平（有貨率），但沒有能力做多個產品的組合優化。市面上也有個別高級計劃軟體，能夠做庫存的全局優化，但有各種短板，使得全局優化的效果不理想。

比如沃頓商學院的教授、博士們開發一個服務備件計劃系統，叫SPO[1]，專門針對「長尾」需求明顯的服務備件進行庫存優化。該軟體在需求預測、庫存計劃方面有非常優秀的計算邏輯，是基於多年的研究和博士論文，但一般的計劃員不懂。不懂就不能信任，不信任就不願用、不敢用。而且這個軟體「歧視」單價高的產品，往往就建議那些很貴的產品一個也不備，儘管這些產品的歷史需求相當多，而且也很關鍵。這是由軟體的全局優化邏輯決定的：多備便宜的，少備貴的。

舉個極端的例子：比如一個產品是1元，另一個是10000元，那SPO一類的軟體的建議往往就是1元的備很多，達到99.99999%的有貨率；10000元的一個都不要備，有貨率為0，但所有產品一起，能達到95%的整體有貨率目標。稍有業務常識的人都知道，這不行。

這問題的解決方案有二。其一，把產品按照單價劃分為不同的組，每個組內進行互相比較。比如單價1到10元的放一組，10到100元的一組，5000到10000的放一組。這樣，10000元一個的產品不和1元一個的比較，而是跟單價差不多的比較。其二，設定最低有貨率，比如5000到10000元的那一組，至少要達到85%的有貨率。

但不管怎麼樣，優化軟體系統「歧視」高價產品的根本「問題」還在，特別是高值慢動的產品，因為那是庫存全局優化的本質所在。而這些高值慢動產品往往是最為關鍵的，一旦缺料，後果嚴重，純粹的數據分析沒法客觀反映這些，導致計劃員不敢輕易遵循軟體系統的建議。結果呢，就可能出現這樣的問題：便宜的產品加了相當多的庫存（那是遵循軟體系統的數據分析），而昂貴的產品又沒有減下來（那是遵循計劃員的判斷），導致有貨率高、庫存更高的「雙高」現象。

計劃員是天生的自下而上，一個一個料號來計劃，從每個料號的局部優化做起，代價是可能犧牲全局優化；計劃軟體是自上而下，綜合考慮全局而提出優化建議。對一個幾十億幾百億規模的企業來說，計劃員動輒就幾十個，計划水平層次不齊，每個人都有自己的一套邏輯，自下而上地構建庫存的「大廈」。在計劃人員眼裡，「大廈」的每一塊積木是獨立的，互不關聯，因為即使關聯，計劃人員也沒能力關聯；但在庫存優化軟體看來，這些積木是有關係的（這沒錯），就把那一塊塊單獨積木的稜角修修圓，讓更好地套到一起來。結果發現，對於大量的產品，計劃員和軟體系統的想法不一樣，如果要採取軟體的建議，那意味著要調整的太多了，無異於推倒重來，顯然不現實。

計劃員往往是憑經驗，從判斷開始，由判斷結束；庫存優化軟體是憑數據，由數據開始，由數據結束。這兩種方法是兩個極端，用哪一種來代替另一種都行不通。理想的方法是從數據開始，由判斷結束：綜合系統的數據分析和計劃員的職業判斷。有些庫存優化軟體考慮到這點，把計劃人員的判斷輸入到系統里。比如有一堆庫存是出於「政治原因」建的——客戶因為短缺，告到工程師的老總那裡，供應鏈只好花錢消災，放上一堆庫存，雖然沒什麼用，但你還不能拿掉。這OK，我們可以告訴軟體系統，優化庫存計劃時，把這些庫存排除在外。但是，小批量、多品種的行業高度複雜，有大量的情況一直處於變動狀態，難以固化在信息系統里，不得不依賴人工來決策。這是個大挑戰，讓我們舉例來說明。

在大型工業設備領域，有些昂貴的零部件壞掉後，要修復再用，否則成本太高。剛開始，備的料都是新零件，客戶的零件壞了，就給他個新零件，把老零件拿來修理；慢慢地，在維修渠道里的老零件越來越多，「維修池」足夠大了，就不再需要備新零件了，所有的庫存水位都替換成修復件。這個時候，需求歷史也要「清洗」，把原來對新零件的需求歷史轉到修復件上，計劃軟體才能正常運作，給出合理的庫存建議來。但這是個非常漫長的過程，動輒需要幾年才能完成；在此期間，需要人工來判斷，究竟需要備多少新零件、多少修復件，不斷動態調整庫存水平。計劃軟體很難對這類庫存優化。

這類看上去是個例，其實很普遍，比如設計變更帶來的零件交替，也有類似的問題。為了降低成本，供應商在不斷推出新的零件，替代那些成本高、效果差的老零件。而新老代替的過程需要人工介入，比如先替代哪些客戶，後替代那些客戶，需要考慮到客戶的接受度和供應鏈的能力，計劃軟體難以有效來優化。

細究一個工業品的庫存體系，你會發現，凡是那些昂貴的產品，總是有這樣那樣的變化，要麼是質量原因，要麼是成本原因，一直處於變化狀態。你說拋開這些產品的話，優化其餘的，但其餘的也沒多少，至少從金額上來說沒多少了。

說了這麼多，都是說工業品環境錯綜複雜，基於計劃軟體系統的庫存優化很難做到位。但這並不意味著庫存優化就不可為。只要做好基本面的工作，你還是可以比你的過去好，比你的競爭對手做得好。要知道，所有的競爭優勢都是相對的。

比如分析庫存，縱向、橫向比較，不同計劃員之間比較，把最佳實踐固化成簡單法則，全面推廣，也會產生顯著的效益。前面講過的成本—頻率編碼體系就是這樣的例子：對於那些單價很高、全球需求很低的產品，比如有個A3產品（成本高過5000美金，全球在過去12個月里只有3個月有需求），當時備貨時沒法有效判斷需求，就在全球的15個地方倉庫都備；現在有了相當的需求歷史了，發現手頭的庫存大概能支持5年的用量。那好，強制把10個庫存點的庫存計划水位清零，讓這10個成為多餘庫存，大概3年後就可以消耗掉50000美金的庫存。而帶來的服務水平風險呢，其實非常小。

再舉個例子。有個工業設備公司做分析，發現沒有及時發貨的產品中，有相當一部分是非常便宜的產品，比如幾毛錢一隻的螺絲釘、螺母、螺帽等。計劃員一般按照平均需求來設定庫存水位，比如備1個月的量；但客戶下訂單時，因為便宜，有時候會一下子訂幾個月的量，結果公司手頭就沒有足夠的料給客戶，導致服務水平指標偏低，客戶和銷售都有意見。那好，這個公司就回顧所有客戶過去24個月的需求，把所有訂單的第一高剔除（這有可能是異常值），確保庫存水位不低於第二高的訂單量。整個分析做完，全球增加了幾十萬美金的庫存，對於一個有過億美金庫存的公司來說，這點投資相當有限，但整體有貨率提高了幾個點。

調整完了，有些計劃員就跳了起來：這螺絲釘我以前備5個，你怎麼給我調到100個呢？在他看來，這95個的增長是個大數字，但轉化成金額呢，也就幾塊錢。而他不知道的是，在地球的另一個角落，有客戶一次訂了100個。當然他可能會爭辯，那不是我的客戶，我的客戶一次要100個的概率有多高呢？答案是當然不高，但並不是不可能：對於這麼低值的產品，即使這麼小的風險，我們也不願意承擔，而且不應該承擔。

在貴的產品上不夠冒險，在便宜的產品上不夠保守，可以說是計劃人員的天性。比如對那些高值慢動的產品，本來可以少備或不備，承擔一些風險來降低庫存，但鮮有例外，計劃員的做法是每樣都備1個，至少客戶怪罪下來我有的說。再比如幾分錢一個的螺絲釘，雖然金額沒多少，很多計劃人員還是不願拔高庫存水位，因為人天生對大數字敏感（比如備了100個，那可是個大數字）。庫存優化是跟人性打交道：平衡人性的弱點，用數據分析的理性來平衡計劃人員的情感。所以，軟體數據作為支持就非常重要，數據也要系統分析，人分析避免不了感性判斷。

從某種程度上講，庫存優化也是系統與組織之間的博弈：不管計劃軟體建議怎麼做，計劃人員總是有各種理由，繼續按自己的老一套來。企業大了，計劃人員的水平良莠不齊，很多人的水平顯然不如軟體系統，雖然軟體系統並不是完美的。但是，系統很少能斗得過組織——系統是死的，人是活的，那些計劃人員總是有足夠多的理由或借口，置軟體系統的建議於不顧，如果你要挑戰他們的話。試想想，那箭是他們射出的，不管射到哪裡，他們總可以圍繞箭頭畫上圓圈，說那就是靶心。系統總是不完美的，會有異常，而國人的傳統呢，就是拋開系統另搞一套，而不是不斷微調、優化系統，最後系統往往是無疾而終。

很多企業採取分散的組織，把計劃分散到基層，是用組織措施來彌補信息系統的短板——企業原來沒有好的計劃系統，就不得不依賴人的經驗；哪些人有經驗呢？自然是基層離客戶近的人，比如客服、物流、運營什麼的。其實，這些人中的大多數不懂計劃，也沒時間鑽研或者不願學習、改變，就只能在經驗主義的路上走到黑，靠拍腦袋做計劃。當企業上了計劃系統後，這些人其實就成了計劃系統的最大絆腳石。

管理者一般站在系統一邊，但永遠沒有足夠的精力來說服這些計劃人員。那一種解決方案呢，就是把庫存計劃的許可權集中，讓最優秀的那幾個計劃員來負責。專業能力高了，人少了，組織和系統就更容易磨合，建立計劃人員與計劃系統的契合，推動庫存優化。

劉寶紅 | Bob Liu

暢銷書作者，供應鏈管理專欄創始人（http://www.scm-blog.com）

[1]Service Part Optimization的縮寫，現在歸PTC公司所有。