)故障分類的標準還不夠明確，參加故障分類的研發(fā)人員對于故障理解不同。
(2)參加故障分類的研發(fā)人員沒有能力按分類標準對故障進行分類。解決的辦法是在故障分類前進行測量系統(tǒng)分析，確認故障分類標準是否已經(jīng)明確，參加分類故障的研發(fā)人員是否具備了故障分類能力。
對于故障分類進行的測量系統(tǒng)分析可采用離散測量系統(tǒng)分析。進行離散測量系統(tǒng)分析的基本步驟為：
1、 在需要分析的故障中隨機抽取30個故障。
2、 多個開發(fā)經(jīng)理按故障分類標準共同確定每個故障的分類結(jié)果。（作為“真值”——本文作者）
3、 讓參加故障分類的研發(fā)人員按故障分類標準進行分類。（作為“測量值”——本文作者）
4、 一周后，讓參加故障分類的研發(fā)人員重新按故障分類。
5、 進行離散測量系統(tǒng)分析，確定故障分類的準確性、重復(fù)性和再現(xiàn)性。
如果通過測量系統(tǒng)分析，發(fā)現(xiàn)故障分類的重復(fù)性有問題，同一個研發(fā)人員對于同一個故障的判定結(jié)果不相同，則一般是研發(fā)人員自身素質(zhì)的問題，采取的措施是需要加強對分類標準的學習。如果不同研發(fā)人員之間的再現(xiàn)性有問題，則一般是由于分類標準不明確造成，需要進一步明確分類標準。若重復(fù)性、再現(xiàn)性都符合要求通過，基本可以保證故障分類的標準定義是明確的，參加故障分類的研發(fā)人員的技能已經(jīng)符合要求。
實際上這種測量系統(tǒng)分析的方法并非第一次使用，去年我們研究所的一個綠帶項目做法極其類似，其原理。
這是一種典型的離散數(shù)據(jù)MSA的案例，在展示時，不少研發(fā)人員很吃驚：“原來MSA是可以這樣做的”，或者“原來是可以這樣得到量化數(shù)據(jù)的”。有很多人總是說研發(fā)過程中的數(shù)據(jù)量化不足，所以不適合做6sigma項目。其實不是6sigma不能用于研發(fā)領(lǐng)域，而是很多時候是我們沒有找到正確的方法而已。所以多思考、多動手，這個從小老師就教我們的話，在工作中一樣適用。
三、如何提高執(zhí)行力？
記得前不久一位領(lǐng)導(dǎo)說：“我們公司從來不缺好的策劃，我們?nèi)钡氖呛玫膱?zhí)行?！避浖械膯栴}有些就是執(zhí)行的問題，如規(guī)范的執(zhí)行不嚴格，流程不合理等等。有人會問：“如果解決方案就是執(zhí)行的問題，可以依據(jù)其影響力選擇合理化建議，或者團隊項目來解決，并不適合做6sigma項目。”實際上，一來6sigma項目在開始時并不知道關(guān)鍵因子是什么，二來執(zhí)行也不簡單，知道和做到是兩碼事，正如一個黑帶所言：“聽到你會忘記，看到你會記住，做到你才會明白。”
言歸正傳，這個案例是另一個黑帶項目《提高功能測試儀的軟件研發(fā)效率》，研發(fā)效率的定義為單位軟件的軟件開發(fā)和維護人力成本。這個項目的特點首先是非常細致，每一個步驟都按照6sigma的思路、方法完整、清晰地描述，可以作為初學者的樣板指導(dǎo)。然而對我而言，它更加重要的特點是它強大的執(zhí)行力。在分析階段，已經(jīng)確認了三個關(guān)鍵因子：
1． 模塊化程度不高；
2． 接口文檔不規(guī)范；
3． 系統(tǒng)部、軟件部、硬件部溝通機制不健全；
為了解決第一個問題，此項目提出建立10個模塊的目標，而目前它只有3個模塊；為了解決第二個問題，需要建立接口文檔的模板，但是更重要的是得到使用者的認可和操作；而第三個問題更是需要三個部門的最高長官——部長來親自溝通協(xié)調(diào)解決。以上這些，這個項目都做到了！怎么做到的？看看他的團隊成員，有研究所的所長，一個產(chǎn)品總經(jīng)理，三個相關(guān)部門的部長，還有相關(guān)的所有科長、開發(fā)經(jīng)理，以及部分開發(fā)人員，這樣的團隊架構(gòu)，還擔心解決方案得不到執(zhí)行嗎？
就是這么簡單，每個項目負責人