精通DMAIC，成為解決問題的高手！ 2005/4/1
有一本暢銷書叫做「QBQ」，中文書名是「問題背後的問題」。當我們聽到問題時，要瞭解問題背後的動機與意涵，才能真正解決問題。可是，你有沒有想過，如果一開始，你的問題就問錯了呢？
當我剛進來接U410這個案子時，拿到一疊量測報表，好像怎麼樣就是找不到critical factors.把standby mode耗電流從7mA降到5mA？那時雖然各相關部門都在進行power量測，但由於測試方法；protocol setting；平均量測時間長短不同；code版本不同；量測儀器設備不同，沒有系統化的方式去規劃，導致量測結果很發散，很難去做分析，無法經由控制變因使量測成為強而有力的工具。
針對這樣情況跟相關部門溝通後，重新界定問題和量測步驟。最重要的是要從整個硬體系統量測的流程著手。所以我們設立三大步驟：
1. 確定系統測試架構，使用的儀器和量測的方法流程
2. 確定Protocol setting 和RF power level，SW driver setting和HW board的版本
3. 確定Debug步驟 -Setup system test tool
-Measure HW power system block
-Check SW driver GPIO setting
-Record test result and waveform
-Find the critical factor and report
當driver team改一版code都要花接近一天的時間去量測整個系統，因此driver team採取的策略是先讓最簡單的original code當作驗證HW system的平台，把各種可能數據蒐集齊全，才開始進行分析。蒐集足夠數據後，再一項一項展開，找出可能的問題點。所以當我們發現第一個可能的問題點在RF部份便請RF工程師協助檢查該模組電路，最後找出2顆電阻原本是保留做時脈控制用，被設計為預留接地，卻造成多耗1mA多的電流。經過我們反覆驗證，最後確定問題點是出在這兩顆電阻上。從確定量測方法後，把debug的方向和重心做調整，整個過程大概花了兩個月時間，才讓我們找到真正造成耗電的critical factor。
我們檢討整個過程，覺得建立量測的真正目標是為了協助下一步驟的進行，而不是先入為主，認為問題一定是出在這裡。等你仔細的都量過一遍後，會發現其實有很多部分是很穩定的，不需要再多花時間。DMAIC的精神就是要讓每位RD面對問題時，在一開始就想清楚去擬定一個可執行的計畫，然後有效率的去解決難題。如果能用最短的時間得到solution，應該是每位RD都期望得到的。
～PMCC RD3 HW Kenny Lo口述， KPM（知識與流程管理）整理
全站熱搜
留言列表
