MRP的起源
MRP源自美國60年代初，最初是針對當時製造企業生產管理中存在的普遍問題，以及傳統庫存控制方法的不足，而提出的一種庫存管理技術。它是物料需求計算器，根據對產品的需求、產品結構和物料庫存資料，來計算各種物料的需求，將產品出產計畫變成零部件投入、出產計畫和外購件、原材料的需求計畫，從而解決了生產過程中需要什麼，何時需要，需要多少的問題。
MRP的需求量計算邏輯
1 首先由成品需求來源，如銷售訂單(S/O)及銷售預測(F/O)對沖，產出需求資料，經人為考量及調整後，就是主生產計畫(MPS)。
2 將該成品的供給與需求，依據日期排序，Check每個日期點的庫存可利用量是否大於等於零。庫存可利用量(INV) = 供給 - 需求；供給包含：庫存，採購單，製令單(含委外)；需求包含：訂單，預測，製令用料單，安庫量。
3 針對供給不足者，依據料件自製採購碼，產生建議製令(EWO)或建議採購(EPO)。
4 假如產生的是建議製令，則展出其所屬子階料件(BOM)，再Check所屬子階料件的供給需求，如此重複 2. & 3. & 4.，直到全部子階展算完畢為止。
5 關於供給/需求的單據計算條件：
(1) 有效單據才可含括進來，及Status = “OPEN”的
(2) 有效數量 = 訂單數量 – 已實現數量(如已出貨/已驗收/已領料/已繳庫)
MRP的日期計算邏輯
MRP計算供給不足而產生建議製令(eW/O)或建議採購(eP/O)單時，其單據的相關日期計算公式如下：
1. 訂單預計出貨日：我方裝箱上貨櫃(貨運)的日期
2. 工單預計完工日：訂單預計出貨日 – 生產後整備(品檢/理貨)時間
3. 工單預計投料日：工單預計完工日 – 料件生產前置期
4. 採購單預計交貨日：工單預計投料日 – 收料後整備(品檢/理貨)時間
5. 採購單預計下單日：採購單預計交貨日 – 料件採購前置期
6. 急單：採購單預計下單日在今天之前，即是為急單，因前置期不足
上列公式必須再扣除例假日(於工廠行事曆設定)，也就是碰到假日，日期必須再往前調整。
MRP物料需求日程表範例及說明
1. 料件庫存(BOH)195PCS
2. 因為父階需求3500xBOM表標準用量0.06，所以製令(MO)用料需要210PCS
3. 195減210，庫存不足15PCS，所以MRP產生了建議採購單(EPO)15PCS
4. 因為設定廠內整備(品檢/理貨)時間2天，所以EPO 15PCS的供給日期為07/14
5. 以下同理
RUN MRP的條件
1. BOM表要正確，子階用量，損耗率等要正確
2. 基本資料：各種前置期(L.T)要正確
3. 庫存要正確，準確率必須98%以上
4. 各類供給/需求單據要正確，包含日期、數量、結案與否
哪些生產型態的公司不需要RUN MRP?
1. 原材料共用性高的行業，或原物料採季或年採購者，比如金屬加工業、螺絲業、
某些化工配方業(如電感)
2. 原材料ITEM數少，而半成品ITEM較多，成品ITEM更多者，如下圖
為什麼使用MRP的普及率這麼低?
因為下列原因，以致於一些公司沒有RUN MRP：
1. 基本管理不札實，比如上述資料正確率不高時，RUN MRP就只是垃圾進垃圾出
2. MRP系統效能不佳，RUN一次MRP需要5-6小時，並且只能在下班時間RUN，
所以只好3天或一週才RUN一次，但是訂單多是急單，不可能3天後甚至下班後
才RUN MRP去購料!! 所以囉，MRP變成沒用的東西。
3. 管理者不能夠真正瞭解MRP，善用MRP，所以被一些所謂的 “LRP” 給替代了。
傳統MRP計算的方式 － 系統慢的原因
1. 沒有使用DB的Procedure功能，大量資料在DB Server與Client之間流竄，再大的網路頻寬也不夠。
2. 展算觀念落後，以所謂的 “低階碼” (Low Level Code，LLC) 迴圈方式逐階展開。
迴圈(Loop)的效能遠遠落後給一行的SQL指令。
3. 沒有使用正確的Index key，通常是where後面的條件順序不對，以致於DB未能使用到正確的Index key。
上述三點是現有絕大多數ERP系統都有的共同問題，也是MRP效能不彰的最最主要原因。
ArgoERP的MRP計算方式 － 為什麼這麼快 !!
1. ArgoERP展算MRP全部使用Procedure：
p_mrp_itemdetail：供給/需求展開，資料來自各類單據或標準BOM表
p_mrp_cal_shortage(‘MO’)：針對製造件供給不足者，產生建議製令單(eW/O)
p_mrp_cal_shortage(‘PO’)：針對採購件供給不足者，產生建議採購單(eP/O)
2. 不使用 “低階碼” 為迴圈(Loop)逐階展開需求的方式，直接使用DB PL/SQL功能，一次展開子階用料。如下SQL指令：insert into (...) select ... from structure where ... start with ... connect by prior ...;
3. ArgoTeam擁有台灣最早開始使用Oracle DB的人才，對於DB Tuning經驗豐富。
總結
好的理論基礎，歷久不衰，雖然已經過了50年(60年代)，MRP仍然是王道。您不需要因為工具不良，而改走變形的MRP，這樣並沒有真正解決問題的根源。ArgoERP提供快狠準(速度/方法/精確)的MRP系統，提供您模擬試算、提前或延後訂單的建議表，殘材檢討…等資訊，達成不缺貨、零庫存目標。
很棒..
回覆刪除