人妻夜夜爽天天爽三区丁香花-人妻夜夜爽天天爽三-人妻夜夜爽天天爽欧美色院-人妻夜夜爽天天爽免费视频-人妻夜夜爽天天爽-人妻夜夜爽天天

ERP的核心功能之一是物料需求計劃（MRP），把計劃、物控、客服、采購從從海量的手工操作中解放出來。但實施ERP以后，真正能跑MRP的企業并不多。也就是說，生產和采購計劃仍舊在Excel上做。有些企業即使啟用了MRP模塊，可還是在手工錄入生產計劃，而ERP能做的呢，只是自動生成采購計劃，充其量是個訂單管理和進出存系統，發揮執行記錄的功能而已。

幾年前，我們調查“供應鏈管理實踐者”微信公眾號的讀者，發現在填寫問卷的35個公司中，能夠自動跑MRP的只有六分之一，半自動半人工的占三分之一，一半的企業是手工跑MRP。填寫問卷的公司規模從1億元左右的中小企業，到幾十億美元的大型外資企業，制造業為主。這是個簡單的問答式的問卷調查，目的不是從統計學的角度得到結論，而是大致了解一下企業的現狀，為以后做詳細的調查做鋪墊。

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，或者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的時候，系統需要扣減在庫和在途庫存來計算凈需求。庫存賬實不符，直接決定MRP沒法運行。

入庫的時候掃描的是產品A，搬進來的卻是產品B；盤點時清點的是產品A，掃描的卻是產品B的條碼；發貨的時候本來該發A，結果發的是B，這些都造成賬實不符。產線返還多余的料，工程師退還沒用掉的產品，東西入庫了，賬沒記，賬實也會不符。包裝本來是12瓶一箱，賬也是這么計的，用的時候卻拆開按瓶發貨，如果瓶與箱的單位都用，記賬的時候把一箱記成一瓶，或者相反，都會導致賬實不符。

有個美國人寫了一本書，快350頁，講的就一件事：庫存的準確度。讀那本書，你會發現造成庫存賬實不符的因素實在太多了——凡是可能發生的都會發生，但歸根到底卻離不開精細化操作，是企業整體運營水平的重要體現。我在評判一個企業的運營水平的時候，一般會問兩個問題，其中一個就是庫存是否賬實相符（另一個是系統能否跑MRP）：賬實相符，并不一定代表運營水平高；但運營水平低的話，賬實一定不相符。

正因為誘因眾多，要解決賬實不符非常不容易。每每有人問我，賬實不符該怎么辦，我都覺得很絕望：他們問我，是希望我能有點石成金的點子；但遺憾的是，在我看來，賬實相符沒有捷徑可走，除非我們把每一件該做的事都做到位。這需要組織、流程和信息系統來支持，但更需要的是決心和紀律。

在我的老東家有位運營經理，他的一部分工作就是確保庫存的準確性，扮演的是“黑面包公”的角色：這老兄是個好人，很好的人，但如果誰領了料而沒有做賬，那就吃不了兜著走。人們往往以太急為借口，沒時間做賬。不過想想看，你在迫切需要產品的時候，都不愿意花兩分鐘記賬，那等你的需求滿足后，還會有多少動力來補記？

托爾斯泰說過，幸福的家庭都是相似的，不幸的家庭各有不幸。跑得起MRP的企業都差不多，跑不起MRP的原因各種各樣，這里提到的只是冰山一角。每一個原因，一旦罐子揭開了，里面注定滿是蛆蟲。運營越是粗放的企業，操作越是“靈活”，也越不遵守基本規則，各種例外就越多，遠非結構化的MRP能對付得了。這不，千百萬投資的ERP系統自然就敗下陣來，成了擺設。