重新定義ERP系統

顧名思義，ERP系統就是用來製定企業資源計劃的工具。

但企業資源計劃本身到底是什麼東西？不論你在網上搜尋ERP或者看教科書，你都只能見到它們在描述一個系統。亦即是描述一件工具。這件工具要用來達成的那個事情就沒有解釋。通常都說是MRP或MRP-II延伸出來的一個函蓋了整個企業的一切活動的系統。而企業資源計劃到底是什麼就不清不楚。難怪市面上見到的所謂ERP系統充其量只是MRP，只不過是新瓶舊酒罷了。

依我從字面上解，企業資源計劃就是分配企業的資源的一個計劃吧。就是要知道企業裡，什麽時候在那裡要什麽和幾多資源。以一間製衣企業為例，老闆當然想知道未來十二個月接單的情況、而這十二個月要生產什麼類別的款式，從而估計出要幾多車位，什麽様的機器，工資的支出要多少，諸如此類一連串的問題。

說到這裡，大概你已經發覺所謂的企業資源計劃和會計用的營運預算（Operating Budget）很類似了吧。不過就只是類似，不能就在兩者之間劃個等號。如果是製造業，我認為還得加上總體生產規劃（Aggregate Production Plan）才成。而且應該先有總體生產規劃才有營運預算。即使沒有電腦，這兩個計劃也是企業必須做的。

要用一件工具的原因不外乎是提高做某件事情的效率和質素。例如要將一颗釘子打進木板裡可以有很多方法和工具。空手道高手可以徒手將釘子插進木板，用皮鞋的鞋跟也可以。但用鎚子是最省力和最快的。一個不能幫助你快而準地製定總體生產規劃和營運預算的系統，就不算是ERP系統。

因此一個適合製衣業使用的ERP系統，必須能夠收集所有為了製定和檢討總體生產規劃及營運預算的數據。離開這兩個計劃而設計的系統不是本末倒置就是只見樹木不見森林。

我會在以後的文章分解總體生產規劃和營運預算所需要的數據。因為要有這些數據，就要有捕捉這些數據的組件。這就可以拼合出一個ERP系統。

遺憾微軟

電腦壞了，乘機換台新的。但發覺用開的輸入法不能在 Windows 7跑。現在用 mouse 手寫，速度比平時慢十倍。

製衣業用的系統和其他製造業的有些什麼不同？(二)

上文提到成衣的尺碼令到製衣業和一般的百搭ERP格格不入，但故事還未完呢。顏色這個屬性，雖然世間萬事萬物絕大部分都擁有，但在工作流程上，製作一件黑色的襯衣和製作一台黑色的筆電可是天壤之別。

一台黑色筆電或者一輛黑色平治，顏色會是最後的工序，甚至等到交貨前才噴漆或才加上外殼，對於整個生產過程無足輕重，不會因為不夠黑色油漆所以不能把引擎裝上的。製衣就不同，生產前就要很確定什麼色要生產多少，不能含糊。因為在裁剪時就要知道不同顏色的布料要用多少，布料變成裁片後還得整理好，按色按碼分派到縫紉車間。只有一些針織服裝，可以整件織好之後才拿去染色的，但在整個製衣行業裡算是很少數。

這個流程上的差異對系統設計有什麼影響？假如你要工廠生產100台汽車，你可以開張製單要100台什麼型號的汽車。廠收到製單，生產完，100輛未上漆的汽車先收到倉庫裡。等你確定了市場的需求，再通知廠把30輛噴紅色、30輛噴白色、40輛噴銀色。只要在發貨單上輸入這些資料就成。即是說在整個生產過程中，顏色這個資料不是必需的。製衣就大大不同，顏色的數量一天未確定，這個訂單都還是半天吊，不要說生產，連訂多少布回來也不行。即是說顏色這個屬性，由產品開發、買料、生產、存倉、交貨都是必需的。

成衣是些潮流產品，要捕捉消費者的品味可不容易。愈來愈多買家要到最後一分鐘才肯告訴廠家每個顏色的數量，因為萬一顏色的分配和消費者的品味錯配得很厲害，他們就會損失慘重。這個風險當然是盡量推給廠家了。可廠家又不能等到一切都確定才去行動，必需以已有的有限資料做最多的事，做最好的決定。例如在做產能規劃時要知道會做什麼款、什麼數量、什麼時候交貨，這時顏色是多少並不重要。知道了幾時交貨，就估計到何時開始生產，也就知道什麼時候一定要落訂單買料，買料時就必需要知道每隻色的數量。如果這個時候連尺碼的分配也可以知道就最好，因為可以最準確地訂料，降低成本。等到要生產的前幾天，就一定要確定尺碼的數量，否則裁床就不能開工。有些廠會索性先買未染色的布回來，等到顏色確定了，才拿去染色，這就可以爭取到時間。

一般的系統，要你把BOM一早定下來，然後做MRP (material resources plan)運算，生成物料的訂單(PO)。但是製衣因為這些關鍵資料未確定，就不能太早做運算，等到一切確定時又太遲了，要不買不到料，要不就要付更高價來採購，一切都失預算了。製衣的MRP最少要分兩個階段運算，即是未有顏色數量時計一次，為的是要知道某隻布料的總用量，這樣可以早些和布廠訂料和議價。顏色確定後再運算一次，這時就可以通知染廠或布廠要染多少色。有需要的話還可以等到尺碼數量確定時又計一次，但因為布料已經訂了，這次是為輔料計算的，不過除了胸圍的模杯、夾克的拉鍊等比較關鍵之外，這些材料佔成本的比例很低，要不要再計多次可以酌情處理。

到今天為止，我不知道那些可以給電子產品、電器等廠家應用的ERP有沒有我這裡提到的功能。如果有，請告訴我。

製衣業用的系統和其他製造業的有些什麼不同？(一)

擱置了這個網誌三年有多。這段期間去了那裡？

皆因寫了幾篇就遇上高人，邀我一起開發個製衣業軟件，所以就不便再發表了。但是相見好同住難，利益衝突少不面，一夥人結果不歡而散。

言歸正傳，先說說為什麼會有標題上這個問題。因為常常有人會問，有些ERP系統連汽車工業也可以應用得上，製衣有幾複雜，為什麼用不到這些系統？世事無絕對，沒有法律規定製衣不可以用那個系統的，講到底是錢和時間的問題。你如果不計成本又有耐性，總有一天會把那個系統打造成適合製衣用的。事實上也有廠家這樣做了，當然他不會告訴你花了多少錢和氣力。

那到底製衣有什麼要特別留意的地方？

通常人都會答 －－ 顏色和尺碼 color and size。但放眼看這個世界，有那些人製造出來的東西是沒有顏色和尺碼的？同一款汽車，會有不同顏色、汽缸容量給消費者選購。電視機，大部分都是一個色的外殼，但有不同尺碼的屏幕。筆記簿電腦，也有不同顏色的外殼和不同速度的CPU之分。不少ERP系統都可以招呼製造這些產品的廠家，為什麼製衣不可以？

先從存貨單位(Stock Keeping Unit (SKU))來分析。例如:

一件紅色加大碼的成衣，它的SKU可以是這樣: G001-RED-XL。

一架紅色2000c.c.的汽車，它的SKU可以是BMW325-RED-2000。

一部紅色3.2GHz的筆電，它的SKU可以是DELL494-RED-32G。

從以上例子可以見到成衣的編碼其實可以和其他產品很相似的。假如有個系統可以輸入筆電的訂單，理論上也可以用來輸入成衣的訂單的。那為什麼那樣多的系統在製衣業遭遇滑鐵盧呢？

大家的製成品雖然都有顏色和尺碼，但成衣的顏色和尺碼就瑣碎得多。假設有個客訂一款成衣，要有五個色五個碼，那就是廿五個SKU。這已經是很少的了，大抵T恤和底褲才會這麼少尺碼，如果是長褲，有分腰圍和腳長的，例如五個腰圍、三個長度配三個色，就是 5x3x3 = 45個SKU。大部分的系統沒預計這麼瑣碎的資料，都是一列一個SKU來輸入，重複入十條八條還可以，入幾十條就令人很沉悶，繼而抱怨，投訴就來了。

但這個也沒什麼大不了，只要在輸入介面做點手腳就可以解決。最常見是做一個二維的陣列(matrix)，教用家不用逐個尺碼輸入。我認為這是可行的，不過只是解決了浮在水面上的冰山的一小塊，下面還有個大山要解決。

製造產品必定要有原料，什麼產品要用什麼原料就得定一個清單，這就是人人都知道的 Bill of Material，簡稱 BOM。一般系統是一個產品一個BOM，以上面的編碼來看，不同規格的產品自然要有不同的BOM。這是順理成章的，因為一台32吋的電視機，當然要用32吋的屏幕；2GHz的電腦就要配2GHz的CPU。得幾個SKU的產品當然沒什麼大不了，成衣，動輒幾十個SKU，那一個款就要開幾十個BOM。入一次還不算數，中間轉用別個料就要改幾十次。有些軟件商的解決方法就是用拷貝(Copy)，即是先開一個，然後copy幾十個出來，再把有分別的去逐個改。但是不同尺碼的衣服用料的數量當然會不同，XS用的料和XL用的料，數量可以差幾個巴仙，那就是說，每個碼都要分開設定。看到這裡，大家應該知道這個方法的可用性有幾高的了。

所以很多不知就裡的軟件商，很輕易的在訂單輸入上過了關，但一到BOM就觸礁。把BOM的結構改了就等於把他們系統的MRP全盤改了，可以說是他們的系統核心部份改了，不用上天文數字的開發費用才怪。

還有其他的暗湧，等待下回分解。