編輯導語：MRP是什麼？一般而言，MRP指的是物資需求計劃，企業在實施了ERP之後，目标之一便是跑通MRP。但是不少企業卻不能實現這一目标，其背後原因在于數據、流程等多方面。本篇文章裡，作者就MRP無法跑通的原因做了總結，一起來看一下。

在實施了ERP的企業，能真正跑物料需求計劃MRP的鳳毛麟角。也就是說，生産和采購計劃還在Excel上做。有些企業即使啟用了MRP模塊，可還是在手工錄入生産計劃。

而ERP能做的呢，隻是自動生成采購計劃而已。企業耗資千百萬元上ERP，一大目标就是跑物料需求計劃MRP。

但現實是大部分企業的ERP與MRP根本不沾邊，充其量是個訂單管理系統，發揮執行記錄的功能而已。

MRP跑不起來，有些公司就習慣性地讓系統背鍋：ERP的功能不行。對那些以進出存為主的小ERP來說，這或許有道理；但對SAP、Oracle那樣功能齊全的大型ERP來說，這顯然不适用。

我們這裡想說的是，MRP跑不起來，表面上是個系統功能問題，背後有深刻的數據、流程和管理問題。

物料清單BOM是MRP運作的基礎：需求錄入了ERP系統，系統打開BOM，一層層判斷有沒有庫存；沒有的話，驅動供應鍊來生産、采購。

所以說，MRP能否運行，直接取決于BOM準确與否。

在企業裡，BOM早已不隻是個物料清單的概念，而是一個跨領域、跨專業的管理體系，是制造業信息化系統中核心的基礎數據。它持續整個産品生命周期，涉及了幾乎所有的職能部門，貫穿銷售、研發、工藝、計劃、制造、采購、倉儲、物流、财務、售後等整個供應鍊，是将這些環節聯系在一起的紐帶。

對于BOM來說，唯一不變的就是變化。在紛繁複雜的變化中，BOM的準确度很難維持。

常見的BOM數據錯誤有：

1. 零件屬性，比如圖紙号、圖紙版本、單位等标識錯誤；
2. 零件數量，比如BOM中的一級零部件、下級零部件數量錯誤；
3. 配置問題，比如市場配置表、工程配置、生産配置三者不符；
4. 采購狀态，比如貨源引起的BOM數據錯誤；
5. 工位錯誤，比如系統工位與實際組裝不符等。

這隻是衆多BOM錯誤中的幾種，詳細的錯誤清單可以參考《如何提升BOM的準确率》一文，那裡有個冗長的清單，讓人不由發出“凡是有可能發生的問題，都會發生”的感慨。

更糟糕的問題是根本沒有BOM，或者BOM在一堆一堆的Excel表格中。這在信息化程度低的企業很常見，因為那就是他們傳統的操作方式。

或者說，有了信息系統，BOM也放進去了，BOM不準确的問題也發現了，但很難在ERP系統裡修改，比如BOM的變更要遵循變更流程，公司越大，這些流程就越複雜、越慢，客觀上導緻員工在系統外操作，結果是BOM的“賬實不符”。

要解決BOM的準确度問題，就離不開研發人員。在任何公司，研發都是最忙的一幫人，雖然是BOM的主要責任人，但以開發新産品為主，能有多少時間來維護BOM呢？

況且，那麼多的産品，那麼多的BOM，投入資源把一些做準了，另一些沒有，那還是不行啊。這就陷入沒有能力全部解決，但部分解決又沒法解決問題的窘境。

于是，日積月累，BOM就越來越不可信，最後就變成誰也沒法對付的大問題。BOM不可靠，就如同地基不堅實，作為建在上面的房子，MRP自然是沒法運作了。

MRP邏輯的運作離不開主數據，比如提前期、最低起訂量、默認供應商等。在管理粗放的企業，主數據一般都很不完整。

一個原因是沒有專職的計劃：本土企業中，相當一部分企業還處在計劃職能的萌芽狀态，主要依靠執行部門之間的靈活配合；計劃和執行不分離，規範主數據的内在需求就不強烈。

比如生産主管做生産計劃，他熟悉産線的每一道工序，每道工序需要多少人力，以及相應的工藝參數，都在他的腦子裡。你說他會給自己找麻煩，花費大量精力，把這些主數據固化在系統裡，并定期維護嗎？

主數據很不完整、不準确，很多企業就是在這樣的基礎上，跨越式進入信息化時代，希望通過ERP實施，倒逼流程和管理，同時解決數據的問題，但往往事倍功半。

常見的場景是，顧問在實施ERP系統，把所有的産品都導入系統後，就要用戶部門提供相應的生産工藝參數、提前期、工藝路線、産能數據，以及單位成本等。企業突然發現，因為曆來都是人工排産，執行者兼職計劃，這些主數據很多還沒有正式計算過。于是就惡補，那麼多的數據，在很短的時間裡整出來，準确度肯定不高，導緻MRP生成的計劃無法執行。

這是真正考驗倒逼的時刻了，但隻有極個别的企業會持續和主數據搏鬥，一個一個地糾正，那是條人迹罕至的路，需要長年累月的堅持；大部分企業呢，則揀了條阻力小的路，讓系統和顧問背黑鍋了事——ERP系統不會争辯，實施顧問拿錢走人，主數據的差距就一直沒法關閉。

這說的是生産主數據。因為牽扯衆多的内部職能，很難搞定，很多企業就繼續沿用老做法，在Excel上做生産計劃。

采購主數據主要跟供應商相關，相對比較容易對付，那至少還可讓MRP來跑采購計劃吧。

是的，有些企業自己内部搞不定，但還是搞定了供應商，所以手工做好生産計劃後，導入到ERP裡，好歹把采購計劃通過MRP跑起來了。

但對相當多的企業來說，供應商相關的主數據也搞不定，因為供應商在不停地換；物料的提前期、采購批量和包裝規格等參數也一直在變；主數據的管理職責不明，這些主數據的更新也很不及時。

就算有一天，供應商終于固定下來了，但主數據還是困難重重。就拿采購提前期來說，你不能簡單地通過曆史訂單來确定，因為有些訂單是早早發出，但要求供應商遲遲發貨；或者是一攬子訂單，同一日期發出，但多批次收貨，這都導緻實際的訂單發送日期、交付日期不準确，基于兩者計算的采購提前期自然不可靠。

那就隻好要求供應商提供，結果供應商發來一個很長的提前期，并告知，實際上不會這麼長，但合同上必須這麼說。背後的原因呢，“小采購”們一直關注的是價格、質量、退貨等所謂的“關鍵”采購指标，對提前期、按時交付等服務指标就從來沒有認真約定過；現在生意做了多時後，要供應商确認提前期，供應商就非常警惕，報個大數字來保護自己。

采購呢，也就睜一隻眼閉一隻眼，畢竟，供應商的績效就是采購的績效。不管是生産還是采購，主數據不準的原因多樣，但結果都一樣：主數據不準确，MRP的結果就不可靠；結果沒人信，MRP就自然沒法跑了。

有個用戶挑戰MRP的邏輯，說明明讓它購買100千克，結果它隻生成了95千克的訂單。

系統有這麼蠢嗎？當然沒有。仔細查看，原來ERP裡已經有一個訂單，數量是5千克，懸挂在那裡多時了，還沒有到貨，系統在計算淨需求時，就扣減掉這5千克，隻生成95千克的訂單。

這時候，需求是100千克，供應是100千克，供需平衡，這不正是你希望MRP做的嘛。

在運作粗放企業的系統裡，大量尾單沒及時關閉是個普遍現象。比如客戶訂單取消了，需求預測改變了，安全庫存調整了等多種原因，采購訂單也不需要了，或許給供應商的訂單取消了，但在ERP裡還沒有及時關閉，就成了懸空訂單。

或許這個懸空訂單确實是有用的，原因注明在某個人的Excel表格中，手工做MRP的活兒時，這個人會手工調整；但當系統運行MRP時，ERP沒法知道那麼多，自然不會去調整了。

懸空訂單如此，懸空需求也是——實際需求沒了，但需求預測甚至客戶訂單還挂在那裡。有些銷售故意把需求懸着，期望以此來“占貨”，萬一以後有需求的話也好盡快滿足。

手工運行MRP時，這會注明在某個人的Excel表格中，在執行時做出适當的調整，比如暫時不要發送供應商訂單；但當自動運行MRP時，系統沒有那麼靈活，這不就一股腦兒轉化成采購訂單，等一堆堆的貨到了，積壓在那裡的時候，已經來不及了。

這後面的問題呢，是對基本規則的不尊重。比如需求與供應匹配，這是MRP的最基本要求：有需求，你就得有供應去匹配；如果需求沒了，你就得把相應的供應拿掉。

但在很多企業裡，基本的業務操作規則不明确，或者雖然明确但過于強調靈活性，權威大于規則，所以像供需平衡這樣極其簡單、極其基礎的規則，也沒法落實下去。

時間長了，就有大量的例外。手工操作時，員工可以繞過這些例外；ERP系統沒那麼“靈活”，該幹啥就幹啥，一跑MRP，就跑出一堆的“麻煩”來，成為沒法跑MRP的一個原因。

托爾斯泰說過，幸福的家庭都是相似的，不幸的家庭各有不幸。跑得起MRP的企業都差不多，跑不起MRP的原因各種各樣，這裡提到的隻是冰山一角。

很多原因，比如庫存數據不準，我們這裡就根本提都沒有提，因為那個罐子一揭開，裡面的蛆蟲就更多了。

這些問題其實都反映了企業的運營水平。運營越是粗放的企業，操作越是“靈活”，也越不遵守基本規則，各種例外就越多，遠非結構化的MRP能對付得了。

這不，千百萬元投資的ERP系統自然就敗下陣來，成了擺設。

本文由@山人小道 原創發布于人人都是産品經理，未經許可，禁止轉載。

題圖來自Unsplash，基于CC0協議