豐田生產方式：少量多樣生產

（2008/6/6 正式版）

在豐田之前，福特開創了大量生產的道路。大量生產，會降低每個單位的生產成本。量越大，單位成本越低，銷售獲利也會越大。但前提是，產品必須是做出多少，就能賣掉多少。一旦銷售量下降，會造成大量庫存。如果為了促銷而降價，那原先因大量生產帶來的成本優勢也就不見了。

豐田生產方式TPS的設計不是朝向大量生產，而是少量多樣化的生產。他們認為，產品會有生命週期，汽車產業的景氣也是有高有低，所以生產方式的設計，不該只是為了增產而考量，也要能在減產的階段持續維持競爭力。

少量多樣化的堅持，也是因為Just in Time(剛好即時)的原則。由業務賣出車子來觸發生產。各車型的銷售量以及銷售比例，沒辦法事先掌握。所以生產線要隨時能生產各型的車子，同型車一次可能只生產一兩台。

要做到少量多樣，有非常多措施來配合。例如一次生產小批量，意味著要經常更換模具。而更換模具是費時費力，又沒有附加價值的工作。所以傳統的觀念認為，應該把同樣的零件匯集一起，增加批量，以降低單位生產成本。TPS反過來，為了達成小批量的生產，認為應該『快速換模』。

大野耐一書中說，當初這個概念一開始推行，就遭受生產人員強烈的抵抗。因為換模時間需要兩三個小時，所以當時的習慣是儘量不更換模具。但是經過不斷的訓練與改善，到1955年，豐田車廠換模時間已經可以降到一小時內。而到1965年，可以降低到三分鐘。

另一個配合的措施是多技能工。不同於大量生產的輸送帶旁，每個工人只負責一個工作﹔豐田的作業員可能同時熟悉多個技能，至少對鄰近的工作熟悉，以便在生產過程中互相支援。所以一個作業員可能同時具備車床、銑床、鑽床甚至焊接等多種技能。

因為少量生產，TPS對於流程改善的觀念也跟傳統觀念不同。假設原先十個人每天可以做出一百個產品。經過改善後這十個人每天可以做120個，從TPS的觀點，這不是好的改善方向。因為需求量不一定那麼大。在增產的階段還好，一旦遇到減產時期，這個改善就失去意義。TPS認可的改善，是八個人每天可以做一百個，或是讓七個人每天可以做出九十個。遇到減產時才能夠做彈性調整，同時仍維持著成本優勢。要達到這個標準，需要有多技能工的制度才能達到。後面會有專文介紹TPS的改善。

少量多樣生產，在軟體開發比較難找到直接的類比。如同筆者三月post的文章所提，寫程式是設計活動，而不是生產製造活動。軟體似乎沒有產量的概念（我知道，軟體工程講LOC、Function Point等等各種量的單位，不過那些不見得適用在今天的開發技術上），而且軟體人員不會做出兩個一模一樣的產品，所以沒有大批量或是小批量生產的問題。不過，Agile方法有不少做法是基於相同的精神。

如同TPS要求快速換模一樣，Extreme Programming告訴我們，如果我們比較怕做某件事，因為很費時而且容易造成破壞（例如改資料庫架構，或是系統佈署），那我們反而應該更時常做它。如果可以自動化（例如將舊系統資料轉到開發中的新系統），那就考慮將它自動化。重複的演練，會讓人熟練，也會更進一步發展出改善的方法。讓軟體的計畫能真的跟著價值走，而不會因為避免做某個動作而受到牽制，延遲新功能整合進系統的時間。

在我個人的工作經驗裡，難做的事要求工程師常常做，的確是會遭受阻力，就跟大野耐一書中所提一樣。因為初期會需要一段適應期，工程師心理壓力大。擔心因為進度落後被要求加班，或是怕因為花太多在做這類重要但沒附加價值的工作，到檢討績效時，被評為產能不好。推行上需要有主管有堅定的立場以及耐心的溝通，加上高層的支持與授權才能成功。

另外，Agile方法強調團隊合作，在XP中這個精神稱為Whole Team。時程與品質，都是整個團隊的責任。例如測試人員可以協助客戶把他要的需求規格描述得更清楚，或是傳授程式人員測試的技巧，幫助程式人員做TDD。程式人員可以協助測試人員解決較難的自動測試程式問題。在Agile團隊裡，專案團隊裡擔任不同職務的成員可以互相協助或替代，每個人都是多技能工。