控制成本意味著某種管理方式。假設你是負責整條環鏈的總裁，而我是你的下屬，負責一個部門，即一個環。現在你要求我“改善”，而我真的改善了我的環，使它的成本減少。你從全局來看這整個環鏈，知道我改善之後，整條環鏈的成本也相應減少了。這意味著一種管理哲學：任何局部的改善會自動轉化成整個組織的改善。

換言之，為達到整體的改善，必須誘發很多局部的改善。整個過程可稱之爲“成本世界”(cost world)。

(2)保證有效產出
保障有效產出意味的是另一套相反的哲學，也就是“有效產出的世界”(throughput world)。

什麽是“有效產出的世界”？
有效產出的本質：如果其中一個環出了錯，公司的有效產出就會受到影響。因此，處理有效產出的問題時，每個環本身當然重要，環與環之間的銜接亦不能忽視。

在環鏈中，什麽東西等同於有效產出，什麽東西不但因各環而定，且因各環之間的互動而定？答案不是環鏈的成本，而是環鏈的强度。

環鏈的强度代表環鏈的特質。環鏈中的任何一個環斷了，代表整個環鏈斷了，環鏈的强度瞬間變爲0。

Q：什麽東西決定一條環鏈的强度？
A：最弱的一環。

單一環强度的改善對整個環鏈强度的增加沒有幫助。絕大多數企業局部的改善對企業整體都是沒有幫助的。我們渴望改善的是企業整體，而企業整體的改善絕對不是靠推行許多局部改善而達成的。

結論：“成本控制”和“保證有效產出”二者無法並行。

説到這裏，費沙將演講的焦點轉換爲“聚焦”。

“一個不懂得聚焦的經理人，既不可能成功地控制成本，也不可能保障有效產出。”

Q：什麽是聚焦？
A：一般指的是統計學上的“柏拉圖定律”(Pareto Principle)，即專注於解決20%的問題，便會得到80%的獲益。但“20—80法則”只適用於那些由獨立變項組成的系統，只適用於把各環分開來管理的“成本世界”。對“有效產出的世界”並不適用。

Q：如何才能知道需要聚焦的問題是什麽？可以用什麽方法？
A：首先找出環鏈中最弱的一環，也就是“確認”制約因素。

制約因素有兩類：
(1) 第一類是實物的，就像瓶頸，是一種產能不敷需求的資源。以這一類而言，强化最弱的一環就是要協助瓶頸增加產能。
（個人心得：不理解的話，推薦閲讀《目標：簡單有效的常識管理》這本書）
(2) 錯誤的決策，也就是必須更改決策，而不是協助錯誤的決策增加產能。
（個人心得：就如《目標：簡單有效的常識管理》這本書中提到的一些錯誤決策造成的後果，如大量零件積壓在倉庫，只是因爲大批量生產的成本比較低廉；又或者是瓶頸資源得不到充分的利用，因爲爲了避免工人在等待的時候無事可做，而安排他們進行別的工作，導致瓶頸機器生產結束之後一直空閑，沒有人看管等等）

費沙只打算談實物制約，他表示其重要性雖然不是最高，但卻比較容易理解。强化瓶頸有兩個方法：(1) 透過外力增加產能，例如增添人手或添購機器設備；(2) 由内挖掘現有的最大產能。

既然TOC接受“控制成本”是必備的條件之一，那麽它采取的第二個步驟是決定如何“減少”制約因素的產能。如果對環鏈上的某一個環有所行動，就必須檢視此舉對其他環會造成什麽影響。

實驗：
Step 1: 角色A扮演瓶頸，每小時可以處理10件產品；
Step 2: 角色B扮演非瓶頸，每小時可以處理20件產品，但你處理過的產品必須經過瓶頸加工；
Step 3: 最大產能只能由角色A決定；
Step 4: 想得到更多的有效產出，必須為角色A增添人手和機器設備——將制約因素“鬆綁”；
Step 5: 角色A這個環經過强化之後，不再成爲瓶頸，也就不再制約產能，新的瓶頸產生，新的循環重新從Step 1開始。

以上就是“有效產出世界”的聚焦程序，這幾個步驟也是持續改善的程序。在有效產出的世界裏，集中焦點和持續改善並非兩個不同的程序，而是同一個程序。
（個人心得：很有道理。專案在執行過程中不斷會有問題產生，專案經理必須根據新產生的問題持續改變思路，這就是learn to fail, fail to learn. 不要期待一勞永逸，而是不斷接受事物的變化，這樣才能真正管理好專案）

Q：如何證明“成本的世界”和“有效產出的世界”無法並存？
A：角色A仍舊扮演瓶頸，每小時可以處理10件產品。角色B依然扮演非瓶頸，每小時可以輕鬆處理20件產品，但處理過的產品必須經過瓶頸加工。在“成本的世界”裏，角色B仍舊會被要求生產20件產品，否則效能就只有一半，造成成本增加；在“有效產出的世界”裏，角色B就會被要求只生產10件產品。
（個人心得：這個觀念在《目標》那本書中有詳細講解，此處的筆記也可以幫助很輕鬆地瞭解）

Q：解決問題的第一步就是明確界定問題。那麽何謂“明確界定問題”？
（我們什麽時候知道了自己明確界定了問題？就是當問題已經解決，而回顧起來，我們同意自己明確界定問題的那個階段是向前邁進了一大步。但是在解決問題之前，要怎麽知道我們已經把問題明確定義了呢？）
A：TOC采用的是自然科學界普遍接受的定義，即問題必須能夠以兩個必要條件之間的衝突來呈現，才算是一個明確定義的問題。

經理人的目標是有效管理，其必要條件一是成本控制，二是保障有效產出。爲了控制成本，經理人必須按照“成本世界”的原則來管理，而爲了保障有效產出，經理人又不得不依照“有效產出世界”的原則來管理，結果兩者互相衝突。
（個人心得：這個部分的解讀比較類似《絕不是靠運氣》這本書了）

TOC的立論基礎之一就是，只要遇到衝突，那就明確指出有人做了錯誤的假設，而這個錯誤的假設是可以修正的，一旦糾正了，衝突便消失了。不過費沙的這個説法，理查德似乎並不贊同。

費沙繼續介紹“衝突圖”(evaporating cloud)的方法。
（個人心得：這個部分可以繼續推薦閲讀《絕不是靠運氣》）

衝突1的假設：爲了控制成本，經理人必須依照“成本世界”的原則來管理 —— 要達到好的成本效益，唯有各局部環節都有好績效
衝突2的假設：爲了保障有效產出，經理人必須依照“有效產出世界”的原則來管理——要達到好的產出績效，不可能每個局部環節都有好的績效

現在有三個選擇：
(1) 選擇衝突1的假設
(2) 選擇衝突2的假設
(3) 在衝突1和2的假設之間尋求妥協

衆人几乎都選擇了(2)，於是費沙開始求證結論是否正確。
我們都要求非瓶頸的產量要遠低於它的實際產能，這不是爲了保障有效產出，而是爲了控制成本，否則多生產出來的庫存會越來越多，造成成本增加。所以“要達到好的成本效益，唯有各局部環節都有好績效”是錯誤的命題，非瓶頸的環節並不需要好的效益。TOC認爲這就是現今企業遇到的問題核心。

所有最新的管理哲學都强調保障有效產出的重要性，不强調局部的表現。
1. 全面品質管理和及時生產系統，雖然它們並未覺悟有效產出需要更清楚的聚焦

2. 再造工程强調重新檢視基本假設
3. 學習型組織的理論基石之一，是以雙贏的解決方法取代不能令人滿意的妥協
結論：利用TOC所提供的清晰度，及有系統地運用它的分析方法，所有這些哲學最終都融合成爲一個貫通的整體。

（個人心得：這一章看起來似乎都是在重複《目標》和《絕不是靠運氣》那兩本書的相關内容，但其實又有些不同。因爲已經讀過這兩本書，我對TOC已經有了一定程度上的理解，但我發現，大部分經理人在管理專案的時候還是會陷入“成本控制”的思維之中，所以理解了之後，如何跳出這樣的思維才是關鍵所在）

12. 到優尼公司取經

費沙講述了他在優尼公司期間的故事，他被公司副總裁彼得森安排去為優尼公司即將收購的一家鋼鐵廠進行分析，然後提出建言。

這家工廠和目前業界的其他工廠差不多，但現在嚴重虧損。熟悉鋼鐵市場的費沙嘗試著找出了一些問題，但他仍然認爲這家工廠無法實現扭虧爲盈。

在鋼鐵廠召開的會議上，彼德森用“現況圖”(current reality tree)來展示目前鋼鐵廠面臨的問題（每小時噸數評量標準所導致的不良影響的邏輯表述）：
500 每小時噸數是鋼鐵業的首要運作評量標準
510 告訴我你是如何評量我，我就會告訴你我是如何行事的
515 各部門努力將每小時噸數增至最大
520 在大多數部門有些產品所需要時間少於其他產品
525 無生產則每小時噸數是零
530 轉換機器必減少每小時噸數績效
540 爲使每小時噸數增至最大，各部門往往優先處理需時較短的產品，犧牲需時較長的產品
545 爲使每小時噸數增至最大，就算市場在短期或中期内沒有需求，各部門也會繼續生產囤積
550 爲使每小時噸數增至最大，各部門往往調換訂單順序，以增加批量
560 在鋼鐵業，產品生產流程中有許多分支點
570 爲使每小時噸數增至最大，各部門往往采取一些可能導致“偷工減料”的措施

分析：
(1) 515推導出了540,545和550兩個結果
(2) 525推導出了545這個結果
後果：處理快的產品庫存過高，而慢的產品卻交不出貨

在鋼鐵業，每個部門都要花許多時間轉換（Setup）機器，通常為三至五個小時。由此530會推導出550這個結果。
對一個部門來説，最壞的情況是閒著不開工，即525。525也將導致545這個結果。
基本工業（鋼鐵工業是其中之一）的特點是，產品在生產流程的每個階段都會遇到分支點，即560。例如：不可能把已經切割成70cm的鋼板再改成80cm。

結論：540，545，550，560最終都會導致570這樣的結果。
例：有兩張近期交貨的訂單，都要求一種特定的鋼板。一張訂單要求10噸60寸的鋼板，一張要求10噸70寸的鋼板。切割部門所需要的setup時間大約為3個小時，而切割10噸鋼板所需的時間會比切割20噸鋼板短，爲了績效，有人將所有的20噸鋼板全部切割成了6寸，再抱怨缺少鋼板可以切割為7寸。最後導致部門之間互相指責，也不能準時交貨給客戶，還多了10噸6寸的庫存。
（個人心得：這個案例很好笑對不對，看文字的確覺得簡單又好笑，可是現實場景有人會這麽做卻一點都不奇怪）

核心問題，即公司的制約因素，在於他們的主要運作評量標準是每小時噸數。

Q：爲什麽會選擇這樣的評量標準？
A：因爲他們的制度基於“成本世界”—— 所有環節都有好的表現，是達成好的成本表現的唯一方法。

（個人心得：這個案例和《絕不是靠運氣》中的那些類似，所以我很快就完成了這部分的閲讀。不過我還是因爲閲讀這個部分有了一些新的對專案管理的構思，我們現在看到的案例都是在產品生產過程中產生的問題，專案管理中一樣也有制約因素，就以軟體開發爲例好了，一個版本release之前，會有一些新功能的開發。我現在的問題是：這些新功能加在一起算是一個專案，還是每個功能單獨算一個專案呢？如果是新功能加在一起算一個專案，那麽什麽樣的功能可以稱之爲瓶頸？還是有什麽其他的方法來比對衡量呢？問題好多啊，很期待接下來的章節可以回到我的疑問...）


13. 三進三出

第三堂課上，理查德驚訝地發現只有一個學生有交作業，情況看起來有點不妙。

細細追問之下，才發現其他學生根本就問不出“專案各步驟加進了多少安全時間”這樣的問題。理查德發現，這些學生問問題的方式明顯不當，直接問他人加了多少安全時間是沒有意義的，因爲他們相信自己的預估是實際的，所以應該改爲問當事人“在預估時間内完成任務的幾率有多大”。

經過理查德的提醒和説明，有人開始有了新的發現，預估時間相當程度地受到程式設計師上一次的延誤影響。事實上絕大部分的電腦程式設計師都無法準時完成工作任務。
（個人心得：如果將“程式設計師”翻譯爲“程式開發者”，那麽現在討論的就和我的工作比較接近了）

接下來各行各業的學生都有了新的想法可以分享，但答案都不能讓理查德滿意。此時唯一交作業的基因公司智囊團開始分享他們的發現：
1. 絕大多數人都自認有八成以上的幾率可以如期完工；
2. 但能如期完工是基於兩個前提：(1) 其他人不要延誤他們的作業；(2) 不要同時給他們太多其他工作分心；
結論：員工提出的預估時間是可以讓他們有很大的幾率準時完工，遠超過五成；員工並不明白“五成以上機率”到底代表多少安全時間；只要專案中某一步驟有多個任務組成，而任務由不同的人執行，專案負責人就會要求每個人各自做出時間預估，加總之後，他再加上自己的安全係數。有時專案會涉及若干管理階層，每個階層都會再加上安全係數。

很多公司的高層管理經常不滿意專案完工日期的最後預估，所以這家公司的半數個案中，在所有的預估完成之後，公司高層會要求縮減專案的前置時間，例如縮減兩成。整體的縮減當然影響每一個環節，每個人因此都得縮減兩成時間。當大家都習慣了這一點之後，直接在一開始便把預估的時間灌水兩成半。
（個人心得：我覺得這一點不難想像，重點是要如何解決這類問題呢？）

由此推斷，安全係數是經由三種機制來加入專案每一個步驟的時間預估：
1. 預估時間是根據以往慘痛經驗來制定，即機率分布曲綫的最末端；
2. 涉及的管理層愈多，預估時間總數愈大，因爲每一階層都會加進各自的安全係數；
3. 為防範高層刪減整體完工時間，執行預估者會灌水自保。
結論：把這些加起來，專案的安全時間必然占預估前置時間的絕大部分。

問題：即使預估已經包括了這麽多安全時間，但還是有那麽多專案不能如期完成？
原因1：在連續步驟的情況中，誤差不會平均分攤，一個步驟的延遲會完全轉嫁給下一個步驟；但一個步驟的提前完成所節約的時間卻不會累積。—— 這可以説明那麽多的安全事件是怎樣消失的。
（因爲提前完工沒有獎勵只有懲罰，老闆會覺得你虛報時間，以後就會據此施壓刪減預估，其他的類似的小組也不會喜歡見到這樣的情景）
原因2：在並行步驟的情況中，最嚴重的逾時會轉嫁至下一個步驟，但當中任何一個步驟提前完工卻完全起不了作用。
結論：專案經理試圖保護每個步驟的績效，但事實上預留的安全事件絕大部分沒有用。

（個人心得：看到這裏，已經可以和前兩章費沙去優尼公司取經時學到的“成本的世界”和“有效產出的世界”聯係在一起了，我的疑問也逐漸開始被解開了。在軟體開發專案中，每個feature應該算作並行的步驟，現在看來，預估時程時所留的buffer其實都是沒什麽用的，這一點刷新了我的時程管理概念，算是一個大收穫吧）

此時，阿爾弗萊德也提出了自己的意見，他根據基因公司的專案記錄，發現在提前完成和延後完成的那些步驟之間似乎有些問題。爲什麽安全時間未能保障專案的完工時間呢？是因爲安全事件在步驟與步驟的接駁之間被浪費了。此外，他覺得他尚未發現可以保證每個步驟績效的安全時間。
（個人心得：這是個有趣的觀點，不過部門與部門，個人與個人之間協作的時候，出現delay似乎一點也不意外。我記得前公司有個習慣，就是每天早上會推出一個新版本讓QA測試，可是大家約好的是早上，往往版本給QA的時候已經是下午了，這個例子也許能説明一點什麽）

結論：如果以上推論的邏輯沒有出錯，那麽安全時間一定被浪費了，不但在專案層面被浪費，在步驟層面也是如此。而被浪費的原因是人爲的和故意的。

就如同今天上課需要交作業的原因一樣，老師交代作業時，大家都説兩個星期時間不夠用，也爭取到延期，但卻沒有人真的回去立即開始做作業。這個現象被成爲“學生症候群”(students' syndrome)，也就是先極力爭取安全事件，爭取到了，就會對此放鬆，覺得不用着急，直到最後時刻。
（個人心得：作者認爲這就是“人性”，我突然想起了“拖延症”，哈哈，似乎真的是如此）

但馬克對此卻有不同的看法，他認爲大家在壓力下工作，會拖延的可能性就會降低。他以基因公司的數據處理部門爲例，因爲這個部門是個瓶頸，所以它不得不同時肩負多重任務。而所謂在壓力下工作，就是指很多人要求這個部門同時處理不同的工作。

問題的根源就在這裏。數據處理部門同時肩負多重任務，如果不能準確分辨任務的priority，顯然就會出問題，目前基因公司的數據處理部門就是如此工作的。

但多重任務對前置時間是有影響的。以下案例可以幫助理解：

假設有人負責A、B、C三個步驟，這三個步驟來自不同的專案或同一個專案。每個步驟需要10個工作天，如果依序處理，那麽每個步驟的前置時間都是10天。但如果他受到了壓力，想滿足每個人。於是他每個步驟都只工作了5天就轉到下一個步驟。假設他的工作順序變成A、B、C、A、B、C，每個步驟的前置時間就會變成20天。
A ——> B ——> C 
(A 表示10天完成)
A —> B —> C —> A —> B —> C
(A 表示5天，經過B的5天，C的5天，再到A的5天，一共20天完成）

結論：多重任務大概是前置時間的最大殺手。

每當專案經理提出一個預估時間，其實心裏知道真正需要的時間只占預估時間的一小部分，但大家直覺地把多重任務的影響因素算進去了。

Q：多重任務產生的原因是什麽？
A：沒有多重任務，那麽同一時段員工的工作量會不足，效率就會降低。

如何才能解決多重任務的問題呢？
（個人心得：作者在這裏賣了一個關子，哈哈，我直接跑去後面找答案了，但我決定尊重作者的意願，不在這一章節的筆記中對外公佈）

下課時間到，理查德開始公佈此課堂的新發現和下堂課的作業。
發現——
(1) 發現了3個添加安全事件的機制
* 預估時間是根據以往慘痛經驗來制定，即機率分布曲綫的最末端；
* 涉及的管理層愈多，預估時間總數愈大，因爲每一階層都會加進各自的安全係數；
* 為防範高層刪減整體完工時間，執行預估者會灌水自保。

(2) 發現了3個浪費安全事件的機制
*“學生症候群”，不着急，直到最後關頭才開始動手；
* 多重任務；
* 各步驟之間依存性，導致延遲的時間累積，導致提前完工所節約的時間付諸流水。

作業——
以添加安全時間和浪費安全時間的3個機制爲主題，各找出一個例子，而且這些例子必須要有數據支持。

（個人心得：這一章節的内容很精彩，所以我看的時間也比較久。哈哈，其實沒有，我在看的時候受“學生症候群”影響，覺得不急，就慢慢來。直到圖書館發來簡訊通知我接下來要看的三本書到了，我才發現這本書我看了還不到一半^^。

但這一章的内容很值得我們深思，特別是多重任務的部分，我最近因工作需要而開始學習很多新的技能和知識，因爲專心學習，所以變得有些沉默寡言，但我將這理解為是“一心不能二用”，因爲我覺得只有在這樣的狀態下，我才能更好更快地學會這些知識。

那在學習的過程中就不需要和外界交流了嗎？當然不是啊，這是另外一個topic了啦，哈哈，此階段的任務著重在理解“多重任務”不能並行的原因和解決辦法，但和外界交流是不受影響的喔）
 

14. 晴天霹靂

理查德進入院長辦公室討論升任永久教職的問題。在此之前，已經胸有成竹的理查德一直覺得自己獲得這樣的機會是沒有問題的，可是情況卻早就開始變化了。—— 理查德不僅沒能得到在這間大學擔任永久教授的機會，而且即將因爲5年任期結束而失去工作。

心情沮喪的理查德開始聯係同學菲爾，打算到菲爾所在的私立大學謀求一個職位。可惜現在的局勢和5年前相比變化太多，現在有太多具備教授MBA資格的教授可供大學們挑選，可是衆多大學卻傾向聘用在企業界有多年實務經驗的人。

理查德繼續找到同學丹尼，打算轉職去企業擔任顧問，可是他沒有任何相關的工作經驗，也沒有任何科研項目成功申請到研究經費的記錄，很明顯，理查德仍舊不具備。他找到一些小型的合夥顧問公司，這些公司要求他自己找客戶，大小事情一手包辦，還要每月繳交1500美元的辦公室使用費和會計服務費。
（個人心得：在一些小型的合夥律師事務所，目前也是采用這樣的方式與沒有太多實務經驗的律師合作）

理查德處處碰壁，而且他也發覺自己並不適合推銷類型的工作，只適合從事教學。無奈之下，他只好回過頭找到好朋友威爾森，希望可以從這裏找到契機來改變局面。威爾森告訴他這是校長BJ凍結商學院新編的預算項目造成的後果，理查德決定要與校長面談此事。

終於，理查德和校長BJ面對面地討論他永久教職的相關事宜。爲了能夠説服校長改變想法，理查德提出他要吸引更多的學生來就讀在職MBA的課程，而他的秘密武器就是“專案管理”教學。他把最近上課得到的那些新發現一一分享給BJ，而BJ也對此聽得津津有味。可是，這並不能讓BJ立即改變想法，於是BJ提出，如果理查德能夠再找到10個學生來參加目前的MBA課程，他們就可以繼續往下談。

（個人心得：最近幾年回到故鄉，發現故鄉的那些大學們現在也開始推行“永久教職”方案。也就是一所大學對吸引進去的教學人才需要時間來評定。老師的專業經驗，授課經驗，學生的接受度，甚至招生能力都將成爲學校是否會授予“永久教職”的依據。這一點和10年前已經大大不一樣了，爲什麽我會知道？因爲10年前我差點就成爲了一所大學的老師啊^^）


15. TOC生產管理引發靈感

威爾森、費沙和克萊爾與理查德一起開會，可惜理查德實在沒有辦法振作起來，他還沒有將不能轉爲“永久教職”的壞消息分享給太太茱莉。

威爾森和克萊爾將上課時遇到的困難分享給費沙，因爲這些學生在聽過費沙的演講之後，紛紛對現有課程的不合理之處提出了自己的意見和看法。

於是費沙介紹起了“TOC的生產應用”，這是從聚焦5步驟推演出來的。他談到第一步“確認”制約因素，即瓶頸時，被忿忿不平的理查德打斷了。

理查德認爲在實務中，制約因素不止一個，他要求費沙解釋如何處理這樣的問題。費沙用了一個實驗模型來解答這個問題：

假設一條生產綫有數個工作站，我們想要充分利用其中的一個工作站（稱之爲X），要求它的使用率達到100%，要達到這個目的，前面的工作站就必須不斷提供原物料給它。

Q：在實務中，墨菲定律必然存在，當某個工作站的工作效能出現異常時，如何保證工作站X的正常運轉呢？
A：在工作站X之前存放足夠的原物料

Q：工作站X前的物料逐漸被消耗，墨菲定律此時再次出擊，如何能保證工作站X持續100%的正常運轉？
A：供應物料的機器修好後，必須儘快補充工作站X前的物料堆。爲了達到這個目的，供應物料的機器不僅要按照正常速度供應工作站X，還要搶在墨菲定律再次出擊之前，迅速補充物料堆。換言之，每個工作站的產能都必須大於工作站X。

結論：即使我們只要求一個資源的使用率達到100%，所有供應無聊給其的工作站的產能都必須大於它。既然墨菲定律不容輕忽，而供應物料的機器只有有限的時間去補充物料堆，因爲額外產能不能僅僅只是比瓶頸大一點就夠了。

Q：供應物料的機器需要有多少額外的產能？
A：It depends on 故障的嚴重程度和頻率，以及可放在瓶頸前的原物料的數量
（個人心得：這裏的原文翻譯我覺得怪怪的，但又找不到更好的詞來形容，所以就借用英文啦，哈哈）

接下來費沙繼續講解聚焦5步驟的“耗盡”，“遷就”，“鬆綁”和“回復”。怎樣把這些步驟轉化爲有效的後勤方案？

將所有的工作站看成是排隊在行進中的人，第一個人走的是一條原始道路，處理原料。隨後的每個人依序處理同一路段，直到最後一個人交付成品，而成品的量就是全隊所走過的距離。在工廠裏，機器是固定的，物料是流動的，可以將機器看成一個人來理解。而第一個人消耗原物料，最後一個人交付成品，那麽第一個和最後一個人中間的距離就是半成品的庫存量。
（個人心得：如果不能理解這一段，建議可以看看《目標》這本書）

而前置時間就是第一個人踏上定點，到最後一個人踏上同一定點所需的時間。第一個人和最後一個人之間所需的距離越長，前置時間就越久。半成品庫存和前置時間是孿生兄弟。

當大家開始出發的時候，彼此之間的距離離得很近，但逐漸就會被拉開，直至分散到各處。此時叫停隊伍，必然產生損失。此時如果以效益來評量每個人的績效，也就是要求每個人都走快一些，但這並不代表整支隊伍會加速。

原因如下：
因爲全隊前進的速度受制於瓶頸的速度，如果此時鼓勵每個人都以自己最快的速度前進，那麽隊伍就會亂了次序，前置時間就會相應增加。
（個人心得：這讓我想起了費沙演講的時候所提到的“成本世界”和“保證有效產出世界”的差別，管理者不要以爲員工一直都在忙就是專案效益最好的時候，瓶頸員工在忙也許才是真正推動整個專案進展的關鍵）

Q：怎樣才能防範大家走亂呢？
A：設置裝配綫可以有效地調整每個工作站的生產速度，如果瓶頸的產量是10，非瓶頸是20，那麽當瓶頸前面裝滿了非瓶頸生產出來的零件之後，非瓶頸就不得不放慢工作速度來配個瓶頸（及時生產系統JIT也是用的這套邏輯）。
（個人心得：我總算懂Azure裏面JIT的remediation是什麽意思了，哈哈，這算是意外的收貨嗎？）

采用裝配綫和及時生產系統生產，前置時間遠比傳統方法短。這些方法的精髓其實就是給工作站之間可累積的存貨設定一個上限。一旦達到了局部上限，該工作站便不能以100%的產能運作。

Q：“裝配綫”和“及時生產系統”只應用到了聚焦五步驟裏的“遷就”(即：不准工作站以他們各自最高效率運作)，如果改進方法做到五個步驟完全應用，應該如何處理？

在生產綫上，我們以庫存保障工作站，在專案中，我們以安全事件保障步驟。當工作站前的庫存快要清空時，代表著留給下一個步驟的時間快要用盡。此外，生產發生意外，庫存不一定會消失；但專案發生意外，時間一定會流逝。

“裝配綫”與“及時生產系統”的缺陷：
即使四處設置防護，只要一個工作站出問題，整條生產綫很快就會因此停頓下來。

Q：解決的方法就是保障瓶頸100%的運作，可是如何才能做到呢？
A：要“耗盡”瓶頸的產能，就必須保障瓶頸不受其他環節的狀況影響。所以在瓶頸前面必須置放足夠的“庫存”/“安全時間”，但又不能太多，否者會導致庫存過量或前置時間過長。

裝配綫之前是將每個工作站都綁在一起，現在改良的方法是只將第一個工作站和瓶頸綁定在一起即可。而繩子的長度（又稱“緩衝" buffer）則決定了可容許的庫存總量。
（個人心得：我喜歡把安全時間稱爲“buffer”，原因就在於此^^）

在實際應用中，具體的做法如下：
首先確認瓶頸，然後決定緩衝的長度。通常較好的計算方法是將目前的生產前置時間除以2，然後......

理查德無心繼續認真聼費沙講解生產系統中的應用，他把焦點都集中在“專案”上，由此產生了一些新的疑問：專案的瓶頸是什麽？我們必須把繩子結在什麽地方？如何決定緩衝的長短？

但理查德也從中得到了一些收穫，例如綁繩子的這個方法可以解決早起步與晚起步之間的矛盾，也會控制工作量的發放，因而大幅降低多重任務的難題。

此時克萊爾要上課的時間到了，臨走之前她提出了新的疑問：如果説局部效益和差異不適合作爲生產系統的績效評量標準，那麽什麽指標比較適合呢？

（個人心得：這一章的内容與《目標》這本書中“健行”那個章節提到的很類似，但是從專案的角度看，似乎又有了一些新的變化。因爲我認真地看過《目標》那本書，所以理解這個部分就覺得很輕鬆。在軟體開發專案中，如果説寫spec的人是“確認”，那麽瓶頸就是主要功能的開發者，目前絕大部分的軟體開發專案已經意識到了這一點，可是還是會有延期的問題，我覺得和開發者的技術能力有些關係。也不知道我理解得對不對，希望後面的章節能夠解答我的疑問）