那天我叫外賣，等了半小時，突然想到這不就是個 DMAIC 嗎？
說實話，在 Fab 待久了，腦子裡想的都是那些 P_L_C、C_I_M 系統，還有那堆永遠跑不完的機台。那天中午餓到翻，心血來潮訂了公司樓下的便當。結果勒？APP 顯示「訂單處理中」，硬是給我卡了半小時。我滑著手機，突然一個念頭閃過：這不就是我們半導體廠最怕的那個「等待時間過長」嗎？而且，這也能用 DMAIC 來處理啊！不信？你聽我說。
問題出在哪？服務業也有瓶頸
說穿了，你跟我都遇過這種鳥事：訂單送出去，然後就石沉大海。在工廠裡，我們叫它「機台稼動率低」或「批次等待時間太長」。在服務業，它就是「客戶不耐煩」。「訂單處理時間過長」聽起來很抽象，但實際拆開來看，你會發現它跟我們工廠的製程超像。從你點餐，到廚房備料、烹飪、包裝、出餐，每個環節都可能卡住。假設我們想把訂單處理時間從平均 25 分鐘降到 15 分鐘，這中間的 10 分鐘，就是我們要去挖寶的地方。
實際上怎麼做？DMAIC 走一遭
坦白講，DMAIC 不是什麼黑科技，它就是一套有系統的解決問題方法。
- Define (定義問題)： 我們要清楚知道，目前「訂單處理時間」的現況是什麼？假設我們量測了 1000 筆訂單，發現平均處理時間是 25 分鐘，標準差 8 分鐘。換句話說，有時候你等 15 分鐘就拿到，有時候等 40 分鐘還沒影。我們設定的目標是平均 15 分鐘，最大不超過 20 分鐘。這就定義了我們的目標。
- Measure (量測現況)： 這個步驟最重要。你不能憑感覺說「好像很慢」。我們需要數據。你可以用 Excel 拉出訂單資料，記錄下每個環節的時間點：從「收到訂單」到「開始備料」、「烹飪完成」、「包裝完成」到「出貨」。假設我們發現，「烹飪」這個環節的平均時間是 10 分鐘，但標準差卻是 5 分鐘，而「包裝」則只有 2 分鐘，但有時會飆到 8 分鐘。這時，我們就發現了潛在的瓶頸。
- Analyze (分析原因)： 有了數據，我們就要分析「為什麼慢」。假設我們發現，週末中午的訂單，烹飪時間會拉長，因為只有一個主廚。或者是，包裝區常常因為找不到餐盒而延誤。這就是找出根本原因。我們可以用魚骨圖、5 Why 法來追溯。說實話，很多時候問題不是出在「人偷懶」，而是「流程設計不良」或「資源分配不均」。
- Improve (改善方案)： 找到了原因，就想辦法改進。如果主廚是瓶頸，是不是可以考慮增加一個副主廚？或者，把菜單簡化，減少複雜菜品的比例？如果包裝是問題，是不是可以把餐盒分類擺放，並設定一個低於安全庫存的補貨點？我們在工廠裡，看到某個機台 OEE 低，就會去改 SOP、換零件、加人。服務業也是一樣。
- Control (控制成效)： 改善不是做一次就沒事。你要建立一套機制來維持成效。比如，你可以每天追蹤訂單處理時間的 Cpk，如果掉到 1.08 以下就發出警報。或者，每週檢討一次是否有新的瓶頸出現。換句話說，就是要把好的做法「標準化」，並持續監控。
最常見的坑：數字迷思與流程慣性
我踩過最大的坑，就是一開始太執著於「數字」。我們常常會把一堆數據丟出來，但沒有好好分析，就急著下結論。結果就是，改善的方案根本沒打到痛點。還有一個就是「流程慣性」。很多服務業，特別是老店，會說「我們一直都這樣做啊」，但時代在變，客戶要求在變，你不變就會被淘汰。就像我們工廠，你用舊的 recipe，品質就永遠上不去。
今天能做的一件事
挑一個你覺得最慢的服務環節，開始記錄它。