MRP計算的經典範例說明

文 – 楊振源

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系統，提供您模擬試算、提前或延後訂單的建議表，殘材檢討…等資訊，達成不缺貨、零庫存目標。

ERP導入方法論－探討時程控管的變數

文 – 楊振源

關於ArgoERP導入的方法論，僅以下圖簡述導入的步驟及其工作項目，以探討導入時程管控的變數。

導入工作概分為上述5階段10步驟，以及底下各階段的各細項工作：

1  導入規劃階段，工作項目包含：
　(a)成立專案小組 (b)定義系統範圍 (c)規劃企業資訊基礎 (d)規劃應用技術

2  作業分析&對策階段，工作項目包含：
　(a)雛型介紹/教育訓練(關鍵使用者) (c)流程對應 (d)調研會議記錄 (e)差異分析報告 (f)客製報價單

3  系統建置階段，工作項目包含：
　(a)客製程式 (b)單元測試 (c)整合測試 (d)標準作業程序書修訂 (e)文件撰寫

4  上線準備階段，工作項目包含：
　(a)基本資料準備及建檔 (b)期初資料準備及建檔 (c)教育訓練(一般使用者) (d)測驗

5  正式上線與維護，工作項目包含：
　(a)平行上線 (b)月結關帳 (c)正式上線 (d)保固維修

顧問導入的工作人天，是每個業主所關心的，在這當中有哪些是可以自己做，哪些一定要委由顧問來執行的呢? 我以底下各導入目標類型的客戶來舉例：

1  完全標準版導入：這類型公司可以僅安排ERP教育訓練就可以，如下類型公司：
　(1) 新公司，尚無資訊系統，沒有歷史包袱
　(2) 公司歷史包袱不深，願意以ERP的最佳典範(Best Practices)者

2  標準版+部分客製導入：
　這類型公司有資訊化經驗，唯使用的系統老舊，新ERP系統功能遠勝於舊系統者，如下類型公司：
　(1) 10-20年公司，使用原始的資訊系統(如DOS+DBASEIII)或單一系統模組者
　(2) 公司歷史包袱不深，願意以ERP的最佳典範(Best Practices)，但需要修改部分ERP關鍵的作業流程者

3  標準版+大量客製導入：
　這類型公司有豐富的資訊化經驗，舊資訊系統屬於量身訂做或大量客製者，如下類型公司：
　(1) 10-40年公司，過去使用專屬或量身訂做的資訊系統
　(2) 公司歷史包袱很深，從上到下不願意(或不能)更改公司SOP以配合ERP最佳典範(Best Practices)者
　(3) 行業特殊性者，如醫療服務體系的廠商，如中衛體系供應商…等，以現有ERP架構符合其需要，但是在多項細部功能上(如取價方式、對帳方式…)尚有不足者

4  專案開發：
　這類型公司通常為特殊的行業或有特殊的管理模式者，如下類型公司：保險業，賓葬業，汽修廠，資訊服務業，工程顧問業，網路購物業，物流業…

在最前面我們提到的整個導入的步驟，我以下表來分析各步驟對於時程管控的變數：

步驟	合適 當擔	合適當擔理由	時程 變數	變數原因
1.開工會議	皆可
2.安裝設定	乙方	專業、常做、責任釐清	低
3.調研、雛型介紹	乙方	專業、常做	低
4.差異化分析報告	皆可		低
5.1流程改造	甲方	甲方的流程甲方最瞭解	低	要時間,對導入影響不大
5.2客製對策	乙方	專業、常做	高	需求不確定,常變
5.3程式客製	乙方	專業、常做	高	改的多,Bug機會就多
6.標準作業流程	甲方	甲方的流程甲方最瞭解	低	要時間,對導入影響不大
3.教育訓練	乙方	專業、常做	低
7.1基本資料準備	甲方	甲方的資料甲方準備	中	沒有料號,BOM,資料零散
7.2基本資料建檔	皆可	量大時乙方可協助轉檔	低
8.1期初資料準備	甲方	甲方的資料甲方準備	中	帳目不清
8.2期初資料建檔	皆可	量大時乙方可協助轉檔	低
9.平行上線	甲方	乙方Stand by	低
10.1月結關帳	甲方	乙方Stand by	低
10.2正式上線	甲方

由上表列，我們可以清楚的知道，ERP導入上線最大的時程變數在 “客製” 範圍的大小，唯有 “客製” 這個項目無法照表操課，其他的項目僅僅是人力與執行力的問題。

當我們決定要導入ERP系統的時候，我們就要清楚的知道，我們是採取哪一個導入目標的類型：
1. 完全標準版導入
2. 標準版+部分客製導入
3. 標準版+大量客製導入
4. 專案開發

不同的導入目標類型，所需要的時程、人力、預算都各不相同，專案本身所承擔的風險更是大不相同，所要達成的資訊目標也不一樣。

在資源有限的前提下，儘量避免客製，或採取分階段並延後客製，都是確保快速取得導入成果的方式。尤其避免想像的客製，也就是要客製的邏輯未經合理化的驗證，或是沒有經過人工與紙本的實作驗證，這一類的客製後患無窮。

不論採取哪一個導入目標的類型，都應該目標明確(明確訂出目標)，不應該在其他操作介面、字體大小、少一個動作或多一個動作上著墨，以免模糊焦點，這些是系統上線後下一階段的優化工作。