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

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

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

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

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

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

問題之一：物料清單BOM不準

物料清單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協議