『精實革命』閱讀筆記

        消除浪費、創造獲利的有效方法

        這本書一樣是在松菸的慈善書展購入手。有陣子我對精實理論的實踐非常有興趣，想知道如何用最小的成本做最大的事情，這套方法論在創業圈一直是個熱門的議題。

        這本書雖然跟軟體圈無關，談的是製造業，工廠生產線如何精實化，但閱讀起來就算產業不同也會心有所得。書中精實生產的實踐，在豐田汽車有著顯目的發揮。

        他從很簡單的道理出發：不要生產客戶不需要的東西。

        因為過去製造業的特性，都是先預估銷量，然後事先生產、囤貨，再交給經銷商或是業務拼命想辦法銷售，這種方式稱為「推式生產」，往往產生大量的浪費，包含囤貨的空間浪費，多餘的生產浪費。因此生產出客戶不需要的東西是最大的浪費！

        這不但造成諸多庫存問題，而且庫存的管理還佔用的廠房都是企業獲利的殺手和浪費。為了消除這樣的浪費，豐田主推「後拉式生產」，也就是透過客戶下單才開始生產流程。

        說的簡單，但這樣的概念實施起來絕不容易！因為客戶下單才開始生產，這代表交期變久了，客戶極可能不願意承受這樣的時間延誤，而會將訂單轉給能快速出貨的其他競爭對手。

        所以要讓後拉式生產兼顧商業的時效性，需要的是整個生產流程徹頭徹尾革命性的改變。看著大野師傅拿著碼表計時，追蹤每一個生產環節耗費的時間，消除過程中任何等待的步驟，這樣反覆操演找出最合適的生產流程，讓我想到最近一部講述麥當勞發跡故事的電影：速食帝國。

        其中有一段麥當勞兄弟如何讓點餐供餐的過程極速化，他們在網球場上用粉筆描繪各種可能的廚房動線，讓工作人員在網球場上面操演，不斷擦去粉筆路徑反覆找出最流暢的工作路線，這一段相當能體現豐田汽車的大野耐一幫各大企業實施精實策略的過程。

        大野先生定義企業的七大浪費：

1. 超出需求的多餘生產
2. 等待下一步的加工步驟
3. 不必要的物料搬運
4. 工具或設計不良的加工過程
5. 存量超過底線標準
6. 員工在工作中做不必要的移動
7. 產出不良品

        要消除這七大浪費，需要依靠以下觀念和做法。因為這是製造業的概念，所以我會補充軟體業可能的對應做法。

拉式生產

        它是一種制度，將多層瀑布式的生產和交貨指令逐一由下游往上游送，上游只有在下游有確切的需要時再生產。

        軟體觀點：盡量讓需求從真實的客戶身上回饋得來，而不是 PM 自己發想。過去發現太多新開發的功能，花了大量人力物力卻沒什麼使用者在用的情況，實為一種浪費。

單件流

        設計、訂單處理、生產的各個階段作業，一次都只處理一單位的產品，而沒有中斷、回流、報廢。

        軟體觀點：要軟體開發上一次只處理一個需求，做好再換下一個需求，而且要降低回流：也就是 QA 測試失敗丟回給 RD 再開發的情況，因為回流會打斷 RD 剛開始做的新需求，在版本控制上，就是增加切換分支的頻繁度，容易產生更多錯誤。

週期時間

        在某作業完成某一單一循換所需的時間。如果整個製程之內的諸作業週期時間能夠調成一致的拍子時間，那麼產品就可以採用單件流的生產法。

        軟體觀點：開發週期如果可以跟 QA 的測試週期一致，就可以順暢的讓 RD 做完一個功能就立刻有空出來的 QA 幫忙測試，而 QA 測完也立刻可以接下一個 RD 的成品做新的測試。軟體業要做到這個難度比較高要做到這件事，就非常仰賴一開始需求的顆粒度大小的切割。這在製造業是比較容易做到，因為通常都重複生產類似的東西。敏捷開發就是用 sprint 來當作這樣的週期概念。

暢流

        當工作沿著價值溪流逐漸完成，如此，某產品從設計到生產完成，從訂單到交貨，從材料到顧客手中，這些過程都沒有停頓或停工，報廢或過程回流等浪費。

製程村落

        將不同作業的不同類別的加工機器排成緊密順序的佈置方式，通常採用Ｕ字型，如此可以採用單件流方式和一人多機的彈性生產系統。

        軟體觀點：這應該類似產品 BU team 的概念，把一組產品相關的規劃、開發與測試人員集中在一起，並且因為同組的人對手上系統的熟悉度，每個人手都可以相互支援。RD 等待時可以加入 QA 幫忙測試，QA 空出來可以幫忙 PM 去 review 需求的合理性。

多能工／多機工

        訓練員工來操作並維護各種不同的生產設備、機器。這是實施精實製造所必須的，因為要求操作多部不同機器。

        軟體觀點：這就是最近流行的 FullStack Developer 嘛。所有 RD 都是同時可以做前端、後端，只是擅長的比例各自不同。這我以前有類似的經驗，當時我的 Team 是以專業職能找 RD 進來，最後網站開發人員都在等 DBA 把 SQL 寫好給他們呼叫，我就要求全部的人都要下去寫 SQL，從前到後到數據讀寫，都由每個人自行負責，而 DBA 則改為讓人發問請教如何撰寫 SQL 的對象，個別指導。這方式讓整個專案的瓶頸被解開。

價值溪流

        設計、訂製、生產某產品時所必須的特定活動：從概念到新產品的推出，從接到訂單到交貨。

        軟體觀點：價值溪流就是檢視並找出和生產本身無關的活動，想辦法將之屏除。這種通常是行政流程、會議、稽核、權限控管、把關放行....這些步驟，找出這些與生產無關的活動來反省其必要性或加以刪減。

拍子時間

        將可用的生產時間除以顧客的需求速度。譬如某顧客對產品的每日需求為 240 單位，工廠每日工作 480 分鐘，此時拍子時間為 2 分鐘；如果客戶每月需要兩種新的產品設計，則拍子時間為兩週。拍子時間設定生產如何配合顧客的需求率，因此他是每一精實生產系統的「心跳」或脈動。

        軟體觀點：我在以前的公司，就認為多人多團隊的系統開發就像是交響樂團，共同演奏同一首曲子，是需要以共同的節拍來做協調。因為以前的公司缺乏這樣的概念，所以各團隊常有脫稿的演出。後來我們制定了每週三和週五的系統上線規範，這個節拍才逐漸形成，大家都知道什麼時候可以交付，如果趕不上那下一次又是什麼時候，有了這樣的班車班次時刻表的概念，大家亂插隊的亂象才得以解除。

目視管理

        將所有工具、零組件、生產活動，和生產系統的績效指標等，都放在可以一目了然的地方，讓所有的利害關係人都容易掌握狀況，也是「透明度」管理。

        軟體觀點：敏捷的看板、燃盡圖、每日站立會議，這些就是為了讓團隊達到透明度管理的工具和制度，也讓大家隨時知道彼此正在做什麼。

到博客來購買此書