|
接著，先介紹相對於傳統DBR之SDBR的定義，根據計劃性負荷(the planned load) 的概念，與如何顧及CCR有限產能之生產計畫。然後，探討對一般訂單提出可靠交期的技巧，這部分會區別生產前置時間（Production-lead-time）與給顧客的報出前置時間（quoted-lead-time）。接下來，介紹CCR保留產能之需求，及探討作者所推薦的程序，善用保留產能，以決定快速回應訂單與其他訂單的開工日期。
最後一部分探討這種之改善計畫的執行規則。
簡易之鼓-緩衝-繩，鼓-緩衝-繩及計畫性負荷 (SDBR, DBR and the planned load)
SDBR（簡易之鼓-緩衝-繩)只包含一個緩衝：交期緩衝（shipping buffer），對訂單式生產（MTO，make-to-order）及庫存式生產（MTS，make-to-stock，或更確切地說是可得式生產[make-to-availability]）兩者皆為如此。當製造現場中有足夠的保護產能（protected capacity）甚至連『最弱的一環（the weakest link）』都有，而不需去保護車間裡任何資源不多的產能時，SDBR必定適用。現在，我們提出SDBR也能有效應用於，內部產能限制資源（capacity-constrained resource，CCR）處於活躍的狀態。
傳統的DBR（鼓-緩衝-繩）使用一套三個緩衝的系統，以保護交期和詳細的CCR有限產能排程。這遠比僅僅防範因非限制資源的延遲，或缺少優先順序造成CCR匱乏（starvation）的情況，擁有更多的保護。使用CCR緩衝來保持實際的順序，不變動。現在，當只使用一個緩衝來保護交期，我們該升起兩項顧慮：
（一）無法適度利用CCR的產能，尤其是造成CCR匱乏，或在CCR花太多的準備時間（setup time）。
（二）在計劃的時段內，負荷無法均衡順暢。以致於不良結果可能是，我們堅持使用過長的時間緩衝，或是報出一個
不切實際的交期。
第一項顧慮能夠而且應該由領班及生產經理來處理，此為執行程序的一部份。在任何可行願景專案中，我們認定市場需求是唯一的限制，這表示我們不能忍受車間有真正的瓶頸存在。換句話說，我們應該擁有保護產能，即使是其中最弱的一環都該有。這樣還是不能表示，我們能忽視任何產能的考量，但這並不表示因為缺乏產能，我們就願意放棄確鑿的市場需求為系統限制。
所以，我們應該如何監控有相當負荷的CCR產能呢？
我們期待生產經理來監控CCR執行之順暢度，藉由避免匱乏的可能性，記住當需求相當低時，有些匱乏的情況自然會發生在最弱的一環（我們視為CCR的資源）。然而我們不需要事先決定在CCR確切的工作順序。實際的順序該受到緩衝管理的優先順序，及可能之準備時間的考量，即是整倂某些訂單以節省準備時間的影響，以避免造成嚴重紅色之交期緩衝的滲透狀態。
許多時候，在CCR的實際順序必須由操作員來決定！在複雜的生產環境，其中順序對於品質、準備及製程時間有重大作用的情況下，更該如此處理。大多數這樣的複雜環境沒有一般可用的軟體能處理其複雜度，例如，我不知道目前有任何DBR軟體有能力，排出含有數個烤爐的CCR之順序，其中烤爐並非完全相同，根據訂單的數量及品質考量，幾張訂單被放在一起處理。在這樣的情況，你應該提供夠長的交期緩衝，自然地給予領班足夠的選擇以做出即時的決定。信賴車間人員的知識。
處理第二項顧慮，我們首先需要一套工具去確定是否太多負荷已威脅到標準之達交時間。確定這樣的情形是計畫性負荷的第一個任務。
定義：計畫性負荷是在CCR（最弱一環）所衍生之負荷的累計，包含必須在某段時間內送交之所有確定的訂單。
例如，在一星期的標準工作時間內，我們必須送交四張訂單，訂單一需要在CCR工作10小時；訂單二要15小時，訂單三只要4小時，及訂單四要10小時。計畫性負荷就是總時數10+15+4+10=39 小時。
生產計畫以小時或工作天來表示。自然地，應該總是比提給市場的標準報出前置時間還短。而標準報出前置時間與計畫性負荷的時間差距，代表目前CCR，以致於車間裡，擁有之保護產能的數量。當然我們必須使計畫性負荷與標準前置時間之間最低限度的差距，能確保最後一張確定的訂單從CCR到完工還有足夠時間。以上面的例子來說，假如一週正常的工作天是五天，每天八小時，那麼標準前置時間是40小時。而計畫性負荷是39小時，似乎過長不足以確保能在一週內安全地送交所有訂單。
雖然計畫性負荷不是一張『排程表』，還是得具有一些有限產能排程的關鍵特質。最重要一項是：假設CCR能夠持續運作，在CCR能夠操作新訂單時，計畫性負荷即通報合理的時間。這表示在考慮計畫性負荷之下，我們能預估一個可靠的完成時間，並增加一些時間緩衝，以給予CCR之後的非限制資源足夠的時間。我們後續在本文中，將詳述提報交期的程序。
因此，我們克服了兩項不實施CCR排程的主要顧慮。
但是，藉由使用單一緩衝，而不詳排CCR的時程，我們得到什麼呢？
CCR之有限產能排程是根據在計畫當時已知的訂單及優先順序。任何變更需求不是被擺到下次排程，就是迫使重新排程，結果是打亂了先前的排程。這表示任何局部干擾（noise）會影響到整個系統，而非只是局部區塊。所以即使是一個小變更，像是將一張訂單的時間往後推，會造成車間內很大的干擾。更為麻煩之處在於，所謂根據CCR的詳細排程而得的『可靠的交期』，並不真的『可靠』。
CCR排程在訂單式生產時特別有問題，由於銷售突然激增，每天的優先順序可能有重大的變化。
因此，轉換成SDBR的方式，並使用計畫性負荷來決定可靠的交期，和具有保留產能的能力，以滿足快速回應及某些其他類型之訂單需求。對可行願景專案而言，當需充分掌控生產與銷售間的聯繫時，似乎是一種優質的方法。
報出一般訂單的可靠交期 (Quoting Safe Due-dates for Regular Orders)
交期緩衝是一種有彈性的時間預估，從投入物料到完成訂單所需的時間。
當決定交期緩衝時，我們有幾項主要的假設：
（一）所有已知之政策限制已消除。政策像是集批常規（batching norms），使轉移批量（transfer batch）等於
作業批量（process batch），及提早投入訂單。在此的假設是那些來自效率衡量的錯誤政策、常規和行為
已消除。
（二）根據CCR的負荷，我們以抑制投入訂單來控制在製品的數量。這表示交期緩衝能比報出前置時間短多了，
因為當CCR已有許多排在該訂單前面的訂單得先做時，報出前置時間必須考量訂單等待被投入車間的時間
。交期緩衝只考量實際投入製造到完成的時間，僅考慮能確保CCR工作順暢之足夠數量的在製品。
目前的計畫性負荷，來自所有確定之訂單的CCR負荷累計，如下圖：
平均上，計畫性負荷的前端（the front of the planned load）通報何時CCR能進行新訂單。當然這是個非常大概的預估。我們並不知道CCR執行前面訂單的精確順序。我們不真正知道實際的順序得用多少準備時間，且我們也絕對無法確定作業之時間數據的準確度，雖然我們喜歡越精準越好。所以，關於CCR何時能進行下一個收到訂單的時間，我們有的是一個不錯的假設。
當只有一個緩衝，讓我們決定在CCR該開始作業之前的一半緩衝時間（1/2 the time-buffer）釋出物料。這不是一項很緊要的假設，由於CCR的時間並非全然實在。我們假設在整個交期緩衝的一半時間內，足夠的訂單會出現在CCR，以防止不必要的匱乏。注意，當CCR並非真正活躍時，表示有相當的剩餘產能，則該有時會閒置。
圖示如下：
到此或許是加以說明的適當時候。在傳統的DBR中，設計CCR緩衝以保護CCR之詳細排程 – 不僅是防備匱乏之用。在排程中的每個指令特別置入CCR緩衝，而在SDBR，我們使用全部緩衝的一半（交期緩衝涵蓋整個路線，從原料到完工），來決定投入原料的時間。以一張訂單來看，所有原料投入生產的時間一樣。在增加新訂單前，計畫性負荷的前端決定投入的時間點。
何時該是承諾訂單交期的時間？現在似乎明顯了，在目前的計畫性負荷前端加上二分之一的緩衝，我們就有一個可靠的交期。圖示如下。
注意，我們能夠安全地在那個時間點達交，問題是，我們應該承諾在那個日期送交嗎？
重點是我們不想要提出一個非常早的送交時間，即使那是個可靠的交期，而這是比標準達交時間還早的時間。當我們準備提供快速回應的服務方案，我們最好不要以更早的交期來寵壞未來顧客。
所以，假如可靠的交期比標準時間更短，那麼我們就該延長緩衝直到標準時間。圖示如下。
在此的構想是夠早投入訂單以確保CCR無匱乏之虞，希望短期內出現更多需求。如果我們延遲投入原料未能供給一般訂單緩衝的需求，可能的負面效應是浪費CCR產能；在一段低需求期後，有一段很高的需求時，則這種現象會發生。假如CCR的產能在低需求期能適當使用，那麼在高需求期便能在可接受的報出前置時間內，生產更多且不威脅到可靠達交。
操作程序之範例說明：(An example to demonstrate the process:)
假設，當下我們有三十張待辦訂單，應該使用CCR三百二十小時。一張一般訂單的標準前置時間是六星期。工廠一週工作六天，兩個八小時的工班。交期緩衝是十天，或二十個工班。
以一張一般訂單而言，我們能提出何時為可靠交期呢？
計畫性負荷的前端在從現在起算的三百二十小時之處。我們擁有的可用產能是一天十六小時（兩個工班），意思是二十天。我們一週工作六天，所以計畫性負荷是在從現在起算三週又兩天之處。可靠交期是計畫性負荷加上一半緩衝，加上五天。所以，日期是從現在日期起四星期又一天。在這個例子，我們維持從現在起算的六週標準前置時間。
投入該訂單是根據計畫性負荷減去一半的交期緩衝：二十天減去五天是十五天 – 從現在起兩星期又三天。
交期是從現在起六星期（三十六天），該特定訂單的緩衝比通常的大些：36-15=21天，而非十天的一般緩衝。這表示我們擁有大量的多餘產能，在傑出的準時達交表現之下，能促成提供快速回應方案。
提供快速回應方案 (Offering the RR)
確保非常可靠的準時達交是絕對必要，以能啟動快速回應之方案，而實際上只從操作觀點來考量是不足的。
每當需求出現時，為了對某些客戶承諾快速與甚至超快速之可靠交期，生產前置時間必須短到足以提供那樣的回應能力。
生產前置時間需要多迅速呢？交期緩衝，生產前置時間的大概預估，需要差不多超快速的時間長度。有人可能議論，在許多DBR實施中，我們有時會接受比一般交期緩衝還要短的訂單。道理是緩衝長度包含很多的保護時間，而大多數的訂單不會滲入紅色區。所以，當我們面對有利可圖的訂單，得在一半的一般訂單的交期緩衝時間達交時，這是個『可能的任務』。當然，我們假設，如此的訂單自然地從第一天起便滲透了百分之五十的緩衝，而有高優先順序，且其他訂單會為此訂單準時完工『鋪路』。
在偶發機會下這是相當可行的，而這樣的達交承諾成為正常運作的話，情形則大不相同。承諾並滿足非常快速的達交每次一起，而不會干擾一般訂單的準時達交，是有可能的。但是你同時能處理多少報出前置時間大約是一半交期緩衝的訂單呢？當你拿到幾張『超高優先順序』的訂單，就有真的風險，就是某些一般訂單會延遲。當這個情形發生 – 你的非常可靠供應商的聲譽就完了。因此，我們需要有一個可靠的生產前置時間，差不多與超快速報出之前置時間相同。這表示我們需要減短生產前置時間到大約標準前置時間的四分之一。這樣會確保一張新超快速訂單會立即投入生產，但並非自動得到比同一天投入之一般訂單高的優先順序。
即使有很短的生產前置時間，我們仍須確定有足夠的產能去供給所有的訂單：很可靠商譽所倚賴之快速和一般的訂單。當我們承諾在某天送交時，我們考慮到目前在生產日誌中的訂單。如果我們可能拿到訂單的交期確實比能承諾的還早，會有無法保持承諾的真正風險。去克服這種風險，我們必須確定能維持產能承諾。所以，在我們考量一般訂單的可靠交期時，我們必須保留某個數量的產能給快速回應訂單。
構想上，計算一般訂單之計畫性負荷只佔可用產能的70或80%，留下20-30%的產能給快速回應訂單（及一些其他訂單，稍後會談到）。圖示如下。
一個簡單例子說明保留產能的概念：(A simple example to illustrate the notion of capacity reservation:)
我們繼續之前的例子。標準報出的前置時間是六星期。交期緩衝是十天（二十工班），車間每週工作六天，每天兩班次。快速回應方案的達交時間是三星期，超快速是一個半星期，就是九個工作天，僅比交期緩衝少一天。
假設我們已啟動快速回應方案，而我們決定保留總產能之25%給快速回應的訂單。今天的生產日誌來自一般訂單的需求，CCR的負荷是396小時（是的，需求上升，由於已建立受肯定之可靠商譽）。接著CCR還有超快訂單的20小時，及另外快速訂單的40小時。
首先，我們計算給一張新一般訂單，能承諾的可靠交期時間。當保留25%的產能，我們一天只有12小時（16小時減去其中25%）給予一般訂單。所以，CCR為了執行所有存在之一般訂單得用396/12=33天。為了承諾可靠交期，我們需要加上半個交期緩衝，另外五天。所以，我們現在算到從今天起的第38個工作天，或是六星期又兩天。所以，保留25%產能表示得報出比該標準時間慢些的交期。
現在，假設今天收到一張額外的超快速訂單，交期已定，從現在起九個工作天。根據交期減去交期緩衝，來投入訂單物料。在這個情形裡，清楚地我們必須今天投入訂單。該訂單的緩衝狀態（buffer status）是(10-9)/100=10%(10%緩衝滲透，由於要求九天送交而非十天)。
所以，任何新的超快速訂單相對於今天投入的其他訂單有些小幅優先權，但不會造成任何實際問題。
今天收到一張快速訂單，三週內送交，18個工作天。交期緩衝是十天，因而我們在8天後投入訂單！看看，縮小的交期緩衝允許我們以快速回應方案的操作，延後投入訂單，且得到更好的價格。
啟動快速回應方案 (Launching the RR Offers)
當開始告訴潛在客戶快速回應方案，即是我們準備接受任何快速或超快速交期的訂單，需要稍微小心。在那時，生產日誌中的訂單交期是根據滿載的CCR產能而得；因此，有保留給快速回應訂單的產能需求，而我們能確定有保留產能的最快時間，是目前計畫性負荷時間。
所以，快速回應方案的啟動日期是，從決定我們完全準備好時之計畫性負荷前端。假如我們用前面例子，假設以一般訂單而論，我們已有396小時之CCR計畫性負荷。這表示，根據一天16小時（還未保留產能），計算出：從現在起第25個工作天（不需更精準）。
所以，已承諾25天之全部CCR產能。從那天起，我們才能接受快速及超快速的訂單！任何今天進來的新一般訂單，應該根據從現在起第二十五天，加上自那時算起之CCR75%的產能而定。
管理快速回應訂單 (Managing the RR orders)
一旦訂單投入生產，車間的優先順序就由其緩衝狀態來決定。快速回應訂單並無特殊之優先順序。CCR決不該卡在計畫性負荷清單上的順序。當然我們並不是要告訴CCR，或任何其他資源，一天中做75%的一般訂單，及做25%的快速回應訂單。
自然地，當沒有快速回應訂單時，CCR投入其100%可用產能於製造一般訂單。當這樣的情形發生，計畫性負荷的時間更短了，因為計算時考量到保留產能。
當許多快速回應訂單出現時，它們能使用比保留部分更多的CCR產能。然後計畫性負荷會增加及新訂單會有較慢的日期。已有的一般訂單會被擠壓到某個程度（即是一般訂單使用較少的CCR產能），但是交期緩衝與緩衝管理應該能支撐所有的訂單，使能準時達交。
然而，我們需要一套機制來決定是否保留的比率是不是蠻適當的。如上面定義之計畫性負荷只包含一般訂單，快速回應訂單就得由保留產能來完成。因此，我們將超快速及快速回應訂單的部分填入，看看成為什麼情況。
下圖呈現兩組負荷情形：一般訂單之計畫性負荷，與保留部分，已填入一部份。這是由於在保留部分的每張訂單必須在快速時間內達成，而一般計畫性負荷所含的訂單是得在標準時間內達交。
我們如何縮短上圖的時間？看來快速與超快速訂單，似乎對一般訂單並無明顯的威脅。當然假如四張快速回應訂單全都是超快速的話，那我們可能會有問題。在那樣的情況，在超快速時間內，投入所有CCR產能，首先投到在很短時間內需完成的訂單，當然表示是超快速訂單，也可能有些一般訂單。根據圖中訂單一也可能在超快速時段之前到期。這種短暫的高峰情形會增加CCR的壓力，及訂單二遭受及時達交的威脅。其他訂單可能一點也不會有問題，由於目前保留產能並未全部使用。
當然上圖中我們需要緩衝管理來掌控全部訂單，和需要持續改善程序，來釐清是否保留產能是過高或太低。
對於短時期之產能控管，一張含有所有落入交期緩衝紅色區之訂單的圖表，和一張所有在整個交期緩衝時間內需要完成之訂單的圖表，是相當有意義的資料。計畫性負荷之程序確保在一般訂單，CCR沒有高峰負荷，但是快速回應可能造成暫時的負荷高峰，尤其在時間短之交期緩衝的情形。這種圖表呈現短期負荷應該考慮到所有的訂單，包含一般或快速回應，而它們個別的交期落在特定的時段內。
假設上圖中，所有快速回應訂單是超快速，而訂單一也得在從現在起算之超快速時段內達交。考慮所有訂單及所有可用產能，我們得到CCR產能與該時段的關係：
合理的假設是CCR先做那五張訂單，那些在其他訂單之前到期者，所以我們希望他們的緩衝狀態反映出較高之優先順序。但我們確定那五張訂單會準時達交嗎？這一定是麻煩的情況，而我們最好不要讓這種情形發生。清楚可見，問題是因為剩下來的時間不多，沒有足夠的時間去完成快速回應訂單四(RR4)。我們需要精確的緩衝管理之狀態來實際瞭解現況。
另一個問題，是否短期之負荷高峰對其他訂單沒有負面影響，那些應該在超快速時段後不久達交的訂單，不太久就到期。當然讓CCR只投入很快到期的訂單，會危及到後面到期的訂單。為了更清楚知道實際狀況，我們應該找出在快速時段內，全部訂單的計畫性負荷總數。
這裡呈現，快速時段與在快速時段之前或在該期間的CCR訂單負荷間的差距，看來合理的。事實上，我們想看到有一半交期緩衝的差距，方能感到差不多適當的。
所以，現在快速時段看來差不多是適當的。但是，當考量如果更多超快速訂單可能會出現，而得使用其餘的產能時，卻是相當的沈重的。所以，一套良好的產能控管機制應該推論出，有保留較高產能程度之需求，或是擴充CCR產能的措施。
總而言之，當我們收到產能壓力開始增加的信號，如在真正需要時，有一套迅速的方式去增加產能的話，上述的情況便能容易掌握。否則，我們需要採用警覺性更高之產能計畫，為快速回應訂單保留更多產能，以確保所有訂單及承諾的績效不受威脅。
更多產能保留的需求 (More needs for capacity reservation)
保留CCR產能的需求源自於，承諾比目前之CCR計畫性負荷還早達交某些未來訂單。換言之，目前的計畫性負荷只呈現部分之實際負荷，因而據此承諾交期並不是真的可靠。
一般而言，就快速回應訂單來說，一旦收到，我們必須比已報給一般訂單還早的日期送交。還有其他像這樣的訂單種類：
■ 策略性客戶，有固定的達交時間。
■ 顯著地比主要的大部分訂單有更短標準前置時間的產品。
■ 庫存式生產（MTS）的產品。
我們先來處理短前置時間的產品。假設，一般訂單的標準前置時間是六星期，而固定性高的產品種類，其業界標準前置時間只有三星期。這兩種都需要CCR，而固定性的產品需要的作業時間短，所以市場上的想法是這種產品應該蠻快就能送交。
只要在計畫性負荷的前端三週還是可靠交期的話，表示恰當地該前端比三星期還早，那就沒問題了。我們還是在標準前置時間內，對所有的一般訂單承諾可靠交期，並十分可靠地準時達交。
所以，只有在CCR計畫性負荷超過短前置時間產品的標準前置時間時，問題才成立。然後當你答應一張長標準前置時間的訂單時，你不知道可能收到多少短前置時間的訂單。當然，你能根據計畫性負荷，報出所有的交期，即使是短的標準時間。引起建構疑雲圖（cloud）的興趣：對一張固定作業程序的訂單，報出較短前置時間，或是根據計畫性負荷報時間。有兩個明顯的解決方案：
（一）著手對付問題的起因。假如實際的限制是市場需求，為什麼我們受限於產能限制呢？假如我們增加CCR產能，
計畫性負荷會落入容許我們去報標準前置時間的時段之內，而無任何妥協之舉。
（二）對那些產品及快速回應訂單，使用保留產能的構想。
以上探討也適用於策略性顧客。
庫存式生產的產品情況不一樣。MTO及MTS兩種生產方式參雜在一起的環境是常見的，因而，我們可能有可行願景專案含有快速回應和供應商管理庫存（VMI）兩者。
為庫存生產的概念是為了經常的與迅速的補貨。預期之運作是根據昨天的銷售量，投入每日的庫存訂單。但是那些沒有確定交期的訂單，他們個別的優先順序則視昨日的銷售量而定。當然，生產經理實際上考量CCR負荷及相關之庫存產品的優先順序，才將MTS訂單投入生產。一旦額外的MTS訂單被投入生產，有些在車間的時間多些，而其他有些會迅速執行。
所以，我們應該如何處理沒有確定交期的訂單呢？
我認為，我們需要考量一些保留產能的總額，以確保具有回應MTS優先順序的能力。然而，這個總額要比總負荷中由MTS訂單而來的負荷比例低。因而，一旦產生MTS訂單，則其CCR負荷該被算入一般的計畫性負荷。而我們必須保留一些產能，以在需要時能能較快速回應，而不去犧牲快速回應及一般MTO訂單的可靠性。
一項重要的觀察：沒有意義去管理個別的保留產能。當然能將它們全部設成一個保留產能的比例。接著藉由觀察預訂訂單之實際負荷的總和，來監控保留產能總額，如前面所述。
簡單或精密的解決方案 (Simple versus sophisticated solution)
在此提供共通之疑雲圖給TOC實踐者，及許多其他的實踐者參考。
這個疑雲圖關聯及已描述之程序，即是我們選擇許多簡化的步驟與方針，接著或許試圖要進一步『改善』其中某些部分，例如，當我們決定可靠交期，沒考量訂單本身單純的作業時間。為什麼？因為相對於緩衝大小而言，並不十分有意義（我們還是假設是製造業），及許多時候，當考量一張並未正式收到的訂單時，我們不知道CCR的工作總量。同時，決定使用一半交期緩衝，去支配期限和投入時間也是很簡單的規則，但是，我們真的需要進入細節，並詢問CCR在生產線上的位置嗎？我當然不以為然。
疑雲圖的解決方案在於挑戰假設『可能在簡單的解決方案下，得到大幅改善。』該挑戰在於認清系統中『干擾（noise）』的數量，及假如『大幅改善』不比干擾還大的話，那麼我們就無法實現改善。
在一個典型的快速回應實施中，我們得知道干擾的數量。通常評估我們需要多少CCR的時間並不是很好的方式（大多數快速回應訂單是客製產品），評估緩衝是十分大概的數字，我們會收到多少RR訂單很不明確，等等。堅持簡單的、坦率的解決方案就很容易實施，並確保在車間的工作人員未來不會使之變形，這點對於實施改善是非常嚴重的威脅。
|
