|
這個現場看來與其他製造現場相似，在製品（Work in process）到處都是。各個工作站（Work centers）執行其特定作業，以製造出最後的產品。再看看，許多原物料…常見的問題是數量不夠與品質方面，這裡的確是一個製造的工作現場（manufacturing shop floor）。
真的是製造環境嗎？最後產物是很大型的系統物件。每張顧客的訂單是一件特定的系統產物，完全依照顧客的需求客製的產品。最後的測試工作是一套複雜的作業，得花一到四週的時間。投入工程工作所需的時間較長一點也不令人驚奇。照這樣的觀察來看，履行顧客的訂單是一種專案（project）工作。
總之，這是製造工作還是專案（manufacturing or projects）工作呢？
對上面這個問題，我們能找出好答案是很重要也很有意義。規劃製造現場與管理專案顯然有所區別。舉例來說，在管理專案，關鍵要徑（critical path）是個重要的概念，而在製造，MRP/APS中並無相同的概念。製造的規劃（manufacturing planning）皆全然不去辨認履行一張訂單的最長作業路徑，而我們最好能選用正確的規畫與控制方法。
為何在專案與製造有如此不同的作法呢？如圖一所示，履行一張顧客訂單所需的基本性質大約相同。如果是這樣的情況，為何開發不同的方法呢？
更進一步理解環境上的不同之處，能帶出不同的規劃方式，能得到更好的整體規劃方法，得以有一套相當健全的計畫，在必要時系統終能有最佳的表現。如能建立一套一致的規劃方式，當然樂於如此。然而，假如我們的結論是有其他延伸的因素，需要不同的規劃方式，那麼能準確確立什麼方法最適合我們的環境，就有極大的價值。
此時，如我們需要有兩種不同方式，則進到另一個問題，是一種混合的環境（hybrid environment）嗎？是否有某些產品需要多專案規劃，與製造規劃兩種方法呢？
不同方法的原理（The Rationale for the Different Methodologies）
專案與製造導向環境之間有幾個不同之處。專案被定義為『每一件專案都是獨特的（each one is unique）』。然而，有些製造環境全部都是客製產品，而MRP的邏輯操作能在這些訂單式生產（make-to-order）的環境良好地運行。專案一般說來，傾向較長的前置時間（longer lead-time），和典型的專案資源是人員的專長。另一方面，製造規劃通常以機械及設備為主，而不是作業人員。儘管如此，這些特質還是未能完全解釋規劃方法間的不同之處。
為了理解不同之處，我們來看一些PERT/CPM -- 這是主要的專案管理方法，與以製造為主的CPIM資料，這兩者的關鍵名詞。
關鍵要徑（critical path）是專案管理方法的中心部分，這個名詞確認對專案而言，平行作業（parallel operations同時作業）是相當普遍的情況（就像在一般的製造作業），因此在最長路徑上的活動/工作，對專案的前置時間而言，比其他活動/工作更加緊要。另一個與專案規劃有關聯的名詞是慢啟動對照早啟動（late-start versus early-start）的概念，這些排程名詞論及非關鍵路徑的啟動彈性。再提一次，這些名詞製造範疇中並不存在。
現在想一想製造中一個重要的名詞：等待時間（queue time）。正如大多數讀者所知，等待時間是生產前置時間中最大的部分。等待時間代表一張訂單必須等到某個資源有空去加以作業。甚至大幅降低庫存，降低生產前置時間的意圖，無法全然消除一張訂單得花很長時間等待資源的可能性。所以，當你在完成訂單後，分析實際的前置時間，你看到經常停停走走的作業時間。
例如，假設實際的前置時間是一個星期。你可能發現該訂單在第一天做了一個小時，第二天做了三十分鐘，第三天沒做，第四天做十五分鐘，最後一天做一個小時。作業時間加總是分散在一週的2.45小時。該訂單的關鍵要徑可能只有1.15小時，不過要能達此時數，我們必須確定在需要作業時，資源到位。換句話說，為了消除系統中所有的等待時間，得要就位準備提供需要的資源，如此資源利用率會很差。精實製造（Lean manufacturing）奮力於以很短的前置時間，達成這樣不間斷的流動（continuous flow）。總之，即使在精實製造的情況，一張訂單的總前置時間還是比關鍵要徑長多了。
當我們察看典型的專案環境，我們看到不同的觀點。讓一件專案排隊等待某個資源是否是可容忍的（tolerable）呢？這表示下一個關鍵要徑上的活動/工作必須等待某個正在別處忙碌的資源。當然，我們都知道這是偶而會發生的。仍然，這還是非常不樂意見到的情況。在廣泛的專案世界裡，以其中每個專案需要盡快完成來看，這是不可忍受的等待時間。同時，反映出實際上大多數活動/工作（在製造用語稱為作業）時間，在專案中是相當長。
現在假設一位專門人員得同時執行三件專案的三個活動/工作。每個工作平均得用兩週時間。這表示其中一件專案必須等待四週的時間，才能輪到被執行。假如該工作正好位在關鍵要徑上，那麼整個專案就被暫停四周等待專門人員，而我們可以想像四週可能拉成八週或更長的時間。由於沒有專門人員，而使一件專案暫停，而不是因為沒有昂貴的設備，這真的難以忍受，經常在一個真正的多專案環境，專門人員『被迫』落入多工的情境(multi-tasking)。換句話說，同時實行三個工作任務，當然，完成這三件任務則各用六週的時間。多工的情境具有極大的破壞性，但是我們無法忍受看到，因為專門人員在忙其他專案，而得暫停另一件專案。
不同作法呈現於圖三與圖四。當然，多工操作無法解決問題，恰恰相反，使情形更糟。然而，在多專案環境，為了使專案盡快完成與達交，其中策略是避免等候，而在製造環境等候是典型的情況。這表示高資源利用率，然而滿足市場需求是非常重要，所以製造規劃工作的矛盾是，在標準回應時間內要完成多少。記得，在製造環境裡，純加工時間比生產前置時間短。下列表格簡述製造與專案間的不同之處，不可避免地帶出不同的規劃方法。
TOC觀點（The TOC Angle）
限制理論（Theory of Constraints，TOC）對於製造與多專案環境，提供不同的規劃與控制方法，以專注於正確的目標。
TOC製造規劃方法稱為鼓-緩衝-繩（Drum-Buffer-Rope ，DBR），整個車間的產能與製造鏈的最弱環節相同。因此，每當市場需求接近CCR（產能限制資源，capacity constraint resource）的產能，則關鍵在於善加利用（exploit）有限的CCR產能。一項挑戰是防止CCR由於匱乏（starvation）而停頓，沒產出。因為莫非及不可靠數據的因素，有必要確保大多數物料，在排定之CCR作業時間前及早抵達。這項要求稱為『CCR時間緩衝（CCR buffer-time）』，見下列圖示，在CCR之處會有計畫中的等候，付出的代價是產品的前置時間（從釋出物料到完成訂單），循著最長的作業鏈，其長度大幅長於純加工時間。
多專案環境的TOC解決方案提供一套全盤的計畫，其中保持每件專案為一個標的（one entity），循著關鍵要徑/關鍵鏈，進行一種不斷的流程作業。緩衝提供對抗莫非/不確定性的防護，與在DBR中使用的方式略為不同。在專案，不能假設純作業時間只是整個前置時間很小的一部份。然而，最大不同在於排程與管理多專案的方式。利用負荷最重的資源來平穩系統上的總體負荷，而專案是以一個標的(one entity)的方式流動。在此圖七為圖二中三件專案的排程結果。
保持專案為一個標的，所以一旦啟動，則不間斷地執行該專案，除非資源競爭/衝突（resource contention）的情況，或其他問題干擾計畫。根據TOC專案規劃，縮短任務時間以排除個別的保護時間。取而代之，聚集部份的安全時間，且在專案路徑尾端安置一個時間緩衝，緩衝末端被視為專案的完成時間。
注意，完全用盡MX（負荷最重的資源）並無實際效果。事實上，對於第二及第三件專案而言，MX的可得性是受到，在前一件專案的計畫完成時間，與下一件專案開始時間之間的時間緩衝所保護。這是因某些延誤，而MX還在忙前一件專案，我們必須防衛對後續專案的影響。
就TOC來看，相較於TOC在製造環境的方法，多專案規劃呈現出一套顯然非常不一樣的方法。這兩種方法對於目標各有不同的焦點。在製造上，目標是在內部產能容許之下，盡力滿足市場需求。在多專案上，主要目標是盡力縮短每件專案的實際前置時間。TOC似乎是唯一的全盤方法，善用關鍵的不同之處，從而提供一套清晰的多專案規劃機制，強調多專案環境的特殊需求。
含有製造任務的專案（Projects that include Manufacturing Tasks）
考量製造大系統，如船、飛機或是整台通訊機組。如能盡早達交，每個這樣的系統都能帶來更大的利益。當然我們能同意，系統越早運作，你的客戶越能據此獲利。在這樣系統的基本架構中，我們會發現的任務像是：各種零件的工程設計，大量零件的整合工作，及最後的測試皆是典型的專案任務。這些被歸類為專案任務，因為其中大量時間在使用特定的資源。假如這些資源在執行中，被卡在一個非最高優先順序的任務，如此一來就會延誤到較高優先順序的任務，結果延遲整件專案。
不過，在該專案中的其他任務可能接近製造作業。例如，生產一艘船中，在幾個地方都需要的一些零件，或甚至檢驗購自承包商的次系統的品質。這些任務通常在車間或特定工廠執行。零件生產一般由數個工作中心完成，而這些工作中心製造不同類別的零件。實際『加工時間（touch time）』是短的，但是生產一組零件可能要幾個星期。這樣的任務，在整體專案的架構中，是一個製造的任務（a manufacturing task）。
對於這樣的環境，合併TOC多專案及DBR方法得到優等的整體規劃。多專案規劃先做，接受生產零件所報出的前置時間（quoted lead-time for manufactured parts）為安排多專案時間的大概時間。根據DBR方法，其預設緩衝（the default buffers）自動地得到良好的大概時間。一旦，完成多專案規劃，每個製造的任務以一個訂單的方式進入該DBR系統。製造訂單的完成日期與專案需要它的時間同步（synchronized）。
合併DBR與多專案環境也使合併兩種TOC規劃方法的執行系統（execution system）(緩衝管理)成為必需的，合併的細節超出本文的範圍。
結論（Conclusions）
釐清規劃方法背後的基本假設與規則是重要的，以開發多專案與製造環境間的正確關係。我們發現重要區別與某些傳統的定義，如『每件專案是獨特的，而製造大多是重複的作業』。另一個常被引用的區別是，專案通常只一件產物，即使這樣與其規劃方法也沒什麼關係。
關鍵區別在於規劃方法的焦點。對不同焦點，主要因素是時間範圍，當一個資源必須全力投入某個特別的任務/運作。在專案，大多數任務按天、週、月計算，而在製造，我們通常按分鐘或小時。因此，專案不能忍受幾個任務在排隊等候某個資源（通常是人力資源），以致於有盡快完成每件專案，及維持每件專案工作之連續性的慾望。一種快速衡量，以評估是否某個環境是接近多專案，還是製造環境，即是計算整條關鍵鏈/關鍵要徑的純作業時間，是否相當接近實際的前置時間。
我們發現許多環境應該被納入多專案環境的考量，卻在使用一般的ERP套件。由於缺乏常見的整體多專案規劃，是一定會移到製造規劃類型軟體的一個因素。現在TOC方法能滿足這樣的情況，支援軟體在市面上可見。忽略適當的物料條件的需求，在專案管理軟體中還是一個普遍的大問題，因此操作專案的組織，生產大型系統真的需要MRP/ERP的支援。但是，如果他們選擇這麼做，那麼資源規劃會是不足的，所以有些這樣的組織同時採用專案管理系統來支援這個需求。
我們提出，最終ERP套件得將多專案規劃，納入製造規劃與執行系統。這兩種不同的系統應該整合，以對多專案提供製造任務的支援，當然完全支援庫存管理與物料條件的需求。特別的產業區塊生產大型系統，像一些高科技公司，與飛機產業顯然需要專案管理與製造規劃兩種，如他們IT系統中不可缺的部份。
The authors: 作者
Eli Schragenheim 是一位國際顧問與教師，他是Management Dilemmas及Manufacturing at Warp Speed (with William H. Dettmer) 書籍的作者，還有Dr. Goldratt’s business novel Necessary But Not Sufficient (also with Carol A. Ptak)。 Eli Schragenheim 是數套教學模擬器的開發者，用於體驗管理製造與專案的問題及TOC解決方案的功能。
Daniel Walsh 是Vector Strategies的總裁，一家 TOC企業顧問公司，位於美國加州聖地牙哥地區。
|
