[原創] 我的專案管理之路--7、親密接觸六希格碼(四)
3 分析 (Analyze)
分析階段關注的是Y=F(X)的F關係,它是DMAIC各 個階段中最難以“預見”的階段。專案團隊所使用的方法將在很大程度上取決於所涉及的問題與資料的特點。六西格瑪團隊認真研究相關的資料資料,增強對過程和 問題的理解,並且在此基礎上,通過分析來尋找“問題根源”。有時,造成問題的基本原因是一目瞭然,團隊很快就完成了分析工作。但在多數情況下問題根源可能 沉埋於檔案堆和舊的程式中。
整個分析階段一般要走過以下三個步驟:
首先是形成推測步驟,大腦風暴法是這個階段的最好的質量工具。因為它能用來找出所有可能的原因。 大腦風暴法在使用過程中須注意遵從工具本身規則、須確定題目、可對會議的論題進行大腦風暴等等。分析產生問題的原因可以從以下幾個方面考慮,所有這些因素 聯合起來共同影響結果,這些原因型別有時稱為“5M和1E”,而整理經大腦風暴法得出的潛在原因的最佳工具是魚骨圖法(因果圖),它可對“5M和1E”進 行分析。
方法:工作中使用的程式或技術。
機器:工作隊中的硬體設施,例如計算機劃或製造業用的儀器。
材料:資料、指令、數字或事實、表格和檔案。如有缺陷,將對輸出產生負面影響。
測量:有缺陷的資料往往起因於測量過程,測量方法以及測量物件。
人:最重要的也是最難控制的因素。
環境:從天氣到經濟的情況,考慮對過程或績效的影響。
以下幾點可供以參考:
A:資料分析
利用測量值的有關資料來分辯問題模式,問題趨勢或其他一些有關因素,不管這些因素是推測出來的,還是證明/未證明的可能原因。使用帕累託分析方法、柱狀圖法、趨勢圖法、散佈圖法等等統計工具進行分析。
B:過程分析
深入研究並分析過程是如何開展工作的,從而識別不一致的,“不相關的”或可能引起問題發生或導致問題發生的某些領域。通過“價值分析”,可以判別過程型別:增值過程,不增值過程或不能確定是否增值的過程,最終找到問題的原因。
C:資料和流程法統一
應將資料分析法的結果和過程分析的結果最終統一
最後是識別找出其根本原因步驟。通過漫長的征途,我們應該可以找出其根本的(X)因子了。但也可能找出的因子是不在魚骨圖法上。
分析步驟中最大的挑戰之一是正確使用工具,能夠用簡單工具找到根本原因,決不用複雜工具,當原因學深藏或問題與其他因素相關聯,綜合與混雜時,必須採用更高階的統計技術來確定和驗證原因。
具體地說,我們須設計收集檢驗資料的計劃, 然後進行收集、審查和分析。 我們須充分運用各種工具,用數字來檢驗推測。工具可分為收集資料工具如資料表和診斷工具如直方圖,散佈圖等。另外,如推測的根本原因是我們不能控制的因子,則須重新開始。
在前面提到的子專案中,我們主要進行了如下的工作:
1、因果矩陣分析
這個分析是半頭腦風暴的形式,也是初步非常有效達成尋找關鍵因素共識的過程。其最終會形成一個矩陣,將主要問題的主要原因呈現出來,用於後續工作的開展。專案組會根據,加權數對TOP N的內容進行改進。
矩陣的基本形式,類似:
Rating of Importance to Customer 9 9 9 9 7 7 7 5 5 1
Feature # 1 2 3 4 5 6 7 8 9 10
現象描述1 現象描述2 ...
Process Inputs
序號 部門 原因(來自SIPOC圖等)
最終,我們決定:1、改進TOP20項;2、分析所有板卡故障原因
2、缺陷現象根本原因分析
這個過程就是基於每一塊有問題的裝置進行詳細的、徹底的分析,找出根本原因止血,同時總結共性問題新增到預防措施中。應該說這個過程最痛苦,面臨大 量問題:有人員精力的問題(都在本職工作基礎上搞改進),有供應商的問題(供應商不配合,不能得到相關的一手資料,同時有的供應商要切,配合度可想而 知),也有內部流程的問題(缺陷裝置在系統裡沒有良好的登記、跟蹤,使得定位困難重重)。問題擺出來了,就是要解決的--持續溝通!整個過程就是溝通,自 下而上開會推進,自上而下行政權力推進,同時還要在私下建立良好的關係保障推進。
最終分析解決了所有找到手的問題,同時完成了9大系列止血行動。初步達成目標!
3、測量系統分析
測量系統分析,在測量階段和分析階段都進行。在分析階段的測量系統分析,主要是對之前確定採集的資料進行剖析,確定是否符合改進需要。比如,降低產 品的返修率,那麼之前確定的返修率資料採集方法是否合適、可信,在這個階段就可以深入剖析。還比如,對於那些標準仁者見仁、智者見智的問題,通過採集、分 析確定出最終的認同方法。
總之,在分析階段,要詳細闡述因果假設,並要持懷疑的態度對待因果關係;要運用常識和創造力建立因果假設;運用資料來檢驗其推測的根本原因;分析假設不要太細,也不要分析不足。
分析階段關注的是Y=F(X)的F關係,它是DMAIC各 個階段中最難以“預見”的階段。專案團隊所使用的方法將在很大程度上取決於所涉及的問題與資料的特點。六西格瑪團隊認真研究相關的資料資料,增強對過程和 問題的理解,並且在此基礎上,通過分析來尋找“問題根源”。有時,造成問題的基本原因是一目瞭然,團隊很快就完成了分析工作。但在多數情況下問題根源可能 沉埋於檔案堆和舊的程式中。
整個分析階段一般要走過以下三個步驟:
首先是形成推測步驟,大腦風暴法是這個階段的最好的質量工具。因為它能用來找出所有可能的原因。 大腦風暴法在使用過程中須注意遵從工具本身規則、須確定題目、可對會議的論題進行大腦風暴等等。分析產生問題的原因可以從以下幾個方面考慮,所有這些因素 聯合起來共同影響結果,這些原因型別有時稱為“5M和1E”,而整理經大腦風暴法得出的潛在原因的最佳工具是魚骨圖法(因果圖),它可對“5M和1E”進 行分析。
方法:工作中使用的程式或技術。
機器:工作隊中的硬體設施,例如計算機劃或製造業用的儀器。
材料:資料、指令、數字或事實、表格和檔案。如有缺陷,將對輸出產生負面影響。
測量:有缺陷的資料往往起因於測量過程,測量方法以及測量物件。
人:最重要的也是最難控制的因素。
環境:從天氣到經濟的情況,考慮對過程或績效的影響。
以下幾點可供以參考:
A:資料分析
利用測量值的有關資料來分辯問題模式,問題趨勢或其他一些有關因素,不管這些因素是推測出來的,還是證明/未證明的可能原因。使用帕累託分析方法、柱狀圖法、趨勢圖法、散佈圖法等等統計工具進行分析。
B:過程分析
深入研究並分析過程是如何開展工作的,從而識別不一致的,“不相關的”或可能引起問題發生或導致問題發生的某些領域。通過“價值分析”,可以判別過程型別:增值過程,不增值過程或不能確定是否增值的過程,最終找到問題的原因。
C:資料和流程法統一
應將資料分析法的結果和過程分析的結果最終統一
最後是識別找出其根本原因步驟。通過漫長的征途,我們應該可以找出其根本的(X)因子了。但也可能找出的因子是不在魚骨圖法上。
分析步驟中最大的挑戰之一是正確使用工具,能夠用簡單工具找到根本原因,決不用複雜工具,當原因學深藏或問題與其他因素相關聯,綜合與混雜時,必須採用更高階的統計技術來確定和驗證原因。
具體地說,我們須設計收集檢驗資料的計劃, 然後進行收集、審查和分析。 我們須充分運用各種工具,用數字來檢驗推測。工具可分為收集資料工具如資料表和診斷工具如直方圖,散佈圖等。另外,如推測的根本原因是我們不能控制的因子,則須重新開始。
在前面提到的子專案中,我們主要進行了如下的工作:
1、因果矩陣分析
這個分析是半頭腦風暴的形式,也是初步非常有效達成尋找關鍵因素共識的過程。其最終會形成一個矩陣,將主要問題的主要原因呈現出來,用於後續工作的開展。專案組會根據,加權數對TOP N的內容進行改進。
矩陣的基本形式,類似:
Rating of Importance to Customer 9 9 9 9 7 7 7 5 5 1
Feature # 1 2 3 4 5 6 7 8 9 10
現象描述1 現象描述2 ...
Process Inputs
序號 部門 原因(來自SIPOC圖等)
最終,我們決定:1、改進TOP20項;2、分析所有板卡故障原因
2、缺陷現象根本原因分析
這個過程就是基於每一塊有問題的裝置進行詳細的、徹底的分析,找出根本原因止血,同時總結共性問題新增到預防措施中。應該說這個過程最痛苦,面臨大 量問題:有人員精力的問題(都在本職工作基礎上搞改進),有供應商的問題(供應商不配合,不能得到相關的一手資料,同時有的供應商要切,配合度可想而 知),也有內部流程的問題(缺陷裝置在系統裡沒有良好的登記、跟蹤,使得定位困難重重)。問題擺出來了,就是要解決的--持續溝通!整個過程就是溝通,自 下而上開會推進,自上而下行政權力推進,同時還要在私下建立良好的關係保障推進。
最終分析解決了所有找到手的問題,同時完成了9大系列止血行動。初步達成目標!
3、測量系統分析
測量系統分析,在測量階段和分析階段都進行。在分析階段的測量系統分析,主要是對之前確定採集的資料進行剖析,確定是否符合改進需要。比如,降低產 品的返修率,那麼之前確定的返修率資料採集方法是否合適、可信,在這個階段就可以深入剖析。還比如,對於那些標準仁者見仁、智者見智的問題,通過採集、分 析確定出最終的認同方法。
總之,在分析階段,要詳細闡述因果假設,並要持懷疑的態度對待因果關係;要運用常識和創造力建立因果假設;運用資料來檢驗其推測的根本原因;分析假設不要太細,也不要分析不足。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/3433/viewspace-253129/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- [原創] 我的專案管理之路--7、親密接觸六希格碼(二)專案管理
- [原創] 我的專案管理之路--7、親密接觸六希格碼(三)專案管理
- [原創] 我的專案管理之路--7、親密接觸六希格碼(五)專案管理
- [原創] 我的專案管理之路--2、認知專案管理專案管理
- [原創] 我的專案管理之路--提綱初稿專案管理
- [原創] 我的專案管理之路--10、淺談團隊管理專案管理
- [原創] 我的專案管理之路--9、如何從技術向管理轉身專案管理
- 課時1:我和python的第一次親密接觸Python
- 與親生的Redis Cluster,來一次親密接觸Redis
- 與Android熱更新方案Amigo的親密接觸AndroidGo
- 【原創】專案六 Load Of The Root
- 與Flutter第一次親密接觸-Android 視角FlutterAndroid
- [原創]專案過程管理在專案管理中的重要性專案管理
- 專案管理方法論之六西格瑪管理專案管理
- 【原創】組織專案管理討論專案管理
- 優思學院|六西格瑪的創新之路
- 六西格瑪專案選題的原則是什麼?
- 六西格瑪與專案管理有何關係?專案管理
- 與次世代的第一次親密接觸——PlayStation 5 搶先上手體驗
- 【原創】專案過程和專案管理有什麼不同呢?專案管理
- 【原創】專案估算-專案管理MSN群線上討論(2009.6.30)專案管理
- 六西格瑪管理在北京IT專案中的應用探討
- 專案管理中的六力模型專案管理模型
- IT企業開展六西格瑪管理專案的常用工具
- 如何利用六西格瑪有效管理專案團隊成員?
- 【原創】老谷"專案管理MSN群"6.23記錄專案管理
- 【原創】多專案控制的困惑
- 六西格瑪工具:親和圖
- 六西格瑪與現有的專案管理方法有哪些不同?專案管理
- 【原創】答一位網友專案管理問題專案管理
- 【原創】老谷專案管理MSN群專題討論--甲乙方專案監控(2009.7.14)專案管理
- 怎麼選六西格瑪專案?
- 如何建立六西格瑪專案章程?
- 專案經理成長之路-我的大學(一)
- 專案管理十二原則專案管理
- 資訊系統專案管理系列之六:專案範圍管理專案管理
- 程式猿生存指南-7 相親之路(下)
- 分享一個我的 Django 部落格專案Django