為什么企業的MRP跑不起來?
編輯導語: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數據錯誤有:
- 零件屬性,比如圖紙號、圖紙版本、單位等標識錯誤;
- 零件數量,比如BOM中的一級零部件、下級零部件數量錯誤;
- 配置問題,比如市場配置表、工程配置、生產配置三者不符;
- 采購狀態,比如貨源引起的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的邏輯,說明明讓它購買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協議
那是你腦子里,或你家MRP跑不起來,,,生產企業難點不在文中說的那些很基礎方面,,,深了去了,,不然那么多制造企業都實現智能化,,而不是卡在信息初級階段。
那你講講唄,只會陰陽怪氣。
你這類小白,杠精,不知道,不值得給你,無知者無罪。免得你消化不良
公司剛上了用友的財務系統,難得一見的全面吐槽,哈哈哈
一個財務系統就跑不起來,說明啥子問題,,當初為何選??? 那要把ERP 模塊都上了,你們不是要關門了?
上系統是為了解決問題,但是結果反饋并不理想,你們做咨詢實施類項目不能幫客戶有效解決問題,反而怪客戶不行,這個理念真的是讓人嘆為觀止。
用友做財務出身國內老大,全球客戶第一,你一個財務系統有好復雜,居然說用不起來你說是系統問題還是使用人的問題,醒醒吧, 該站起來了,,,
你既不是操作用戶,又沒有參與實施,聽到說,問題所在不知所以然,開始情緒化杠精開啟,職業大忌,
這位朋友語氣看起來不夠客氣,但我也認為本文所列舉的,都是很基礎的困難,除了第一點“BOM不準”外,后二點僅是困難下面的困難(企業管理基礎薄弱衍生的問題)。作者應該沒有參與過完整的實施項目,喝過些湯未嘗其肉。有人喜歡反問式,有些東西確實不是一二句可言得了的,舉其上一點,企業有多大,各方利益博弈就有多大,那利益二個字也就不是三言二語的事了。也是云里霧里裝了一波,難道就無解了嗎?如何統一思想,就看企業主的魄力了。