講清楚，說明白

在阿麵過去待過的公司裡，很少老闆會花時間跟阿麵解釋公司的政策。大部分的狀況是，當高階主管決定公司的方向、政策後，和阿麵相同的員工只會接到像是這樣的訊息：「從今天起，我們開始進行 OO 政策，請大家配合。」當然，上有政策下有對策，如果 OO 政策對大家有益，我們就會乖乖執行；如果政策怪怪的，或對大家有不良的影響，那，就看我們的對策啦。

實際上，在推行 TOC 時，高德拉特博士很強調推行政策對員工的說明。尤其，在說明未來要如何推行新政策前，還要一步步告訴大家為什麼要這樣做，就像高德拉特博士上課時的說明方式(未來若有空，可以跟大家分享 TOC 的問題解釋步驟)。

老闆只要把未來要推行的政策告訴大家就好了，為什麼還要大費周章地說明如此做的原因呢？答案很簡單，因為慣性。

舉例來說，如果在一個員工閒下來就會被罵的公司中，老闆突然說：從明天開始，我們採用TOC的作法，除了瓶頸部門外，其他部門等接到工作再努力，沒接到工作就不用做事。

在 TOC 中這個做法是對的。但，員工聽到這樣的新作法後，標準反應會是：老闆的腦袋短路、燒掉了。甭說，「政令宣導」的隔天，每個員工還是會「看起來很忙」，絕對不會有人願意、也不會有人敢閑著。

雖說，透過 TOC 的方法論解決問題時，常常在找到答案的同時會說「這是常識啊」。但，對於已經習慣舊有作法的人員來說，即便新作法是「常識」，但真正在推行時，衝擊還是十分的大。與其得到員工的反對、抗拒，還不如透過 TOC 的三個步驟：要改變什麼、要變成什麼、以及
要怎麼改變，對每個員工說明，並讓他們了解這樣做的來龍去脈。

所以，要推行 TOC，還是別忘了，講清楚、說明白。

生產力 100% 的迷思

在軟體業裡有句名言：上班打卡制，下班責任制。阿麵的公司也不例外。上班的時候，雖然不像大陸的工廠一樣，盯著人一定要在位置上不能亂跑，但，如果離開座位太久，阿麵的老闆就會開始問：人呢？去哪了呢？好像僱來的人，一定要不停的工作、努力的工作，絕對不能偷懶、打混。

說實話，雖然阿麵覺得這樣子很不人性，但開始帶人時，也覺得，既然人都花成本來請了，能夠用多少，就用多少。放在那裡什麼事情都不做，就叫空轉。反正，不用白不用，對吧...

不過，自從阿麵開始研究 TOC，就發現，有空轉的人是正常的。雖然理論上，我們可以計算每個人的產能，然後透過分配，讓每個人都不停的運作，但在實務上，莫非 (Murphy) 是存在的，只要莫非出擊，生產就會受到影響。

假設有一個資源可以 100% 運作，為了保護這個資源不會因為莫非的出現而受到影響，生產鏈之前的資源必須加入保護用的產能 (protective capacity)。有了這些保護產能，一旦莫非出現，讓之前某個資源停止運作，當莫非離開時，這個資源就可以藉由多出來的產能，追上原來應該生產、但被延遲的產出。

因此，在這個狀況下，幾乎所有的資源，都要有保護用的產能，以防莫非出現，造成無法彌補的延遲。

如果保護用的產能也拿來生產，讓大家都可以有 100% 的生產力，會發生什麼事情呢？很簡單，有保護產能的資源，可以生產一堆的東西，但原來那個可以 100% 運作的資源，就沒有辦法消化堆積在前面的庫存，然後... 庫存越來越高，投入的資源越來越多，到最後，公司只有破產一途！

所以，讓人發呆、暫時不動，未必是一件很糟糕的事情；相反的，如果瓶頸沒有受到影響，讓非瓶頸暫停一下，又有什麼關係呢？

用衝突圖處理衝突 (I)

在 TOC 中，有一個解決衝突的好幫手，就是衝突圖 (Evaporating Clouds)。在高德拉特博士的著作中，常常看到書中人物利用衝突圖化解歧見、找出雙贏解。實際上，阿麵剛開始和朋友一起研究 TOC 時，就用過衝突圖解決問題。

還記得那天阿麵和朋友們準備讀書會要簡報的內容，而這次讀書會的主題剛好就是介紹衝突圖。與會人員都同意只講理論是不夠的，要準備一個範例讓大家練習，才能加深印象。但在討論範例的進行方式時，大家碰到一個問題：衝突圖的題目要怎麼準備呢？這時，出現了兩種聲音。

第一種聲音是，因為衝突圖中，要分析背後的假設，所以最好是讓練習的人自己想題目，才會有感覺；第二種聲音是，因為怕有人想不出問題，拖延到練習的時間，所以最好是由報告的人準備制式的題目。

結果，衝突就發生了。一邊說，使用制式題目，若題目不好，也沒有效果；另一邊說，到時候若想不出題目，也沒有足夠的時間練習。說著說著，大家的火氣就上來了，講話的聲音也越來越高。

就在這個時候，有個成員說：既然這樣，我們乾脆用衝突圖處理看看囉！這句話打醒了大家。是啊，既然在研究衝突圖的時候發生衝突，就用衝突圖來解決衝突吧！

沒多久，製作衝突圖的第一步 -- 畫出衝突，就做好了。

緊接著，雙方開始「各自表述」，逐一檢視衝突圖中每個箭頭後面的假設找出來。

正當我們開始進行第三步 -- 檢視每個假設是否合理時，突然有個成員指著「閃電」說：奇怪，難道「自己設定題目」和「設定制式問題」是衝突的嗎？我們難道不能讓這件事情同時進行嗎？仔細想想，沒人說這兩件事情是互斥的啊，是我們讓它變成互斥的。

最後，大家達成協議，在 20 分鐘的練習中，我們給大家 5 分鐘的時間思考自己的題目；若想不到，我們會公佈準備好的制式題目，請沒想到題目的成員做制式題目。這個解決方法，不但可以讓找到問題的人練習解決切身的問題，也不會讓找不到問題的人在思考問題時花費太多時間。

在這次的事件中，阿麵看到，看起來是衝突的事情，有時候，也未必是衝突的呢！

寫不完的手冊

阿麵在公司裡扮演了多重角色，常常在救火模式和工作模式切換。有一天，老板娘安慰阿麵說，別這樣覺得辛苦，要覺得驕傲，因為一個人要有能力，才能一次做多件事情。此外，一次處理多件事情，如果 A 做煩了，就可以改做 B ，然後再做 C 換個心情。這樣，才不會無聊。阿麵聽了老闆娘的解釋，也覺得這樣的講法是對的。

直到有一天，公司產品推出了新版本，撰寫手冊的工作落在阿麵身上；手冊還沒處理好，老闆娘又把阿麵調到某個專案裡救火。從此之後，阿麵身上就綁著平常要做的工作、救火，以及寫手冊，事情很多、但好像都做不完。

那段時間的阿麵，疲於奔命地到處救火，早把寫手冊放到最低優先度的工作。即便在週會裡，老闆娘不時提醒阿麵還有手冊沒寫，還要阿麵排出寫手冊的 schedule，但，哪有時間啊？

好不容易，所有的事情都忙完了。阿麵回到寫手冊的工作，並在兩星期內，完成了三本手冊。

只可惜，沒多久新版的產品又推出了。阿麵再度回到寫手冊的地獄裡，好不容易等到產品手冊的客戶，又得繼續等待新版的手冊。

在 TOC 的關鍵鏈理論中，這稱為「多工處理 (multi-tasking)」。在小公司裡，這種事情幾乎天天都會發生，看起來也沒錯。

只是，原本各需 9 天完成的 A、B、C 三件事，若依序完成，可以在開工後 9 天、18 天、和 27 天完成；但若 A、B、C 以多工處理方式，分兩次、每次 4.5 天輪流做，就要 18 天、22.5 天、和 28 天完成。對 C 來說沒差，但對於 A 和 B，就會造成延遲了。

如果考慮工作轉換的成本，如果把工作切得更細、輪流得更頻繁，那麼，連 C 都會延遲了。

以阿麵寫手冊的故事來看，如果阿麵可以多花兩個星期完成手冊，雖然其他事情可能會被延兩個星期，但客戶不需要多等兩個月，就可以拿到產品手冊。

當然，阿麵不是說不可以進行多工作業、不可以插單，工作也有優先順序要考量。只是，插單前請先三思，因為在專案裡，許多預留的緩衝，就這樣莫名奇妙地消失了。阿麵的手冊就是因為插單，似乎永遠也寫不完。

瓶頸瓶頸，Where Are You？

在限制理論中，「找出瓶頸」是一件很重要的事情，因為瓶頸會成為整個生產線上「發號施令」的部門，而且公司的策略、方向，都會從瓶頸考慮。根據 Goldratt 博士的經驗，一家公司中，只會有一、兩個瓶頸，而找出瓶頸最簡單的方式，就是問生產線的人：東西都堆在哪個部門裡？

但是，在阿麵的公司中，似乎每個地方都是瓶頸，業務、專案服務、研發、教育訓練... 似乎所有的工作都卡在每個部門，每個部門看起來都是瓶頸。有哪個部門的人很輕鬆嗎？沒有耶，到處在忙，到處在救火，每個人的事情都做不完，叫苦連天。不是說，瓶頸只有一、兩個嗎？怎麼在阿麵的公司裡，到處都是瓶頸呢？

實際上，在良好的管理下，瓶頸是不會亂跑的。Goldratt 說，如果瓶頸會跑來跑去，大概只有兩個原因：

• 公司以批次的方式進行生產。這時候，就會像「蟒蛇吞下一隻大象，看著大象在蛇肚子移動」般，只要批次工作跑到哪個部門，那個部門立刻就變成瓶頸。
• 習慣讓員工永遠保持忙碌。老闆看到瓶頸出現後，就從其他部門調人到瓶頸部門，紓解瓶頸部門的壓力。這時，瓶頸部門會變成非瓶頸部門，而被調人的部門馬上變成瓶頸部門候選人。

看看阿麵的公司，大家都被調來調去，忙著協助其他部門的工作。如果 coder 做不完，就找 RD 人員幫忙；如果 presale 抽不出身，就找 PM 協助業務；如果沒有 PM，就找個 coder 帶案子；如果找不到產品安裝人員，QA 就要協助。在這個狀況下，即便阿麵公司裡真的有個瓶頸(阿麵相信，一定有個瓶頸)，在這樣支援來、支援去的狀況下，瓶頸一定跑來跑去，所有的部門都覺得自己的人不夠。

講到這哩，阿麵的老闆娘有話要說：這就是彼此互相支援啊，而且我們沒有多餘的資金養冗員！可是，當瓶頸被模糊時，我們又怎麼知道哪個部門的人力足夠，哪個部門是真正的瓶頸？可別忘了，瓶頸是發號施令的部門，也是公司調整生產方向的依據啊。瓶頸，可是重要的部門呢 (未來有空，再聊這塊吧)。

看這跳來跳去的瓶頸，身為瓶頸部門之一的阿麵只能希望，目前喘不過氣的瓶頸同事們，大家辛苦了！

會虧本嗎？

這星期起，一個剛來的部門同事被丟到專案裡 (雖然他不應該負責專案)。我們可愛的老闆娘只要逮到時間，就會跟阿麵說「阿麵啊，這個人在案子裡只有 40 個人日，所以他一定要在 40 個人天內做完，不然我們就會虧本囉！」緊接著，老闆娘努力的跟阿麵解釋，如果超過 40 人天，對於成本的影響有多大，會如何的讓公司虧本...

阿麵並不打算在此討論成本會計、或專案成本的計算控管。但，如果真的沒有在40人日完成，真的會造成虧本嗎？

在TOC的理論中，評估生產時，只集中檢視下面三個重點：

• Throughput：產品售價減去原料成本。Throughput愈高，愈好。
• Inventory：從原料到產品間產生的「半成品」。Inventory是可以變成成品的。Inventory愈低，愈好，但不能是 0，不然會導致其他問題。
• Operating Expense：營運成本。只要公司開門營業，就要付出的成本。Operating Expense愈低，愈好。

在軟體業，阿麵覺得，專案談的錢，就是Throughput(因為軟體沒有"原料成本"。除非聘工讀生，只做這個案子就好，這樣工讀生的薪水就會變成原料成本)，公司的薪水管銷，包括程式設計師的薪資，都算是Operating Expense。

根據這樣的定義，怎麼會有虧本的狀況呢？因為，沒有"原料成本"、只有"營運成本"，而不管這個案子什麼時候做完、甚至那個同事有沒有案子做，都有營運成本的支出啊。如果不是做完這個案子，就開除這個同事，Throughtput和Operating Expense都是固定的啊。

也許有人說，這個案子在20人日做完，會比用40人日做完來的好。但這個前提是，如果當他做完這個案子馬上就要進入其他的案子；或是，他是整個"專案生產線"的"瓶頸"，那，20人日做完真的會比40人日做完好，因為早點作完，就可以早點進行其他專案，藉此可以提高Throughput。

不過依目前狀況來看，這個案子做完後沒有其他的案子，那20人日做完，和40人日做完，又有什麼差別呢？老闆娘又不能說，如果可以在20人日做完、而非40人日，這樣可以少給20人日的薪水，降低Operating Expense！

所以，要阿麵同事趕緊把案子做完，應該不是"這樣會讓公司虧本"，而應該是為了要"提高Throughput"吧。

TOC 限制理論的部落格

研究 TOC 一段時間了，越來越覺得這個理論很有趣。未來很希望可以往這個方向發展，但，還是要先充實自己的能力。

在這，阿麵就分享一些自己從限制理論中學到的東西吧。如果有機會，也希望可以跟有興趣的朋友討論。