品保人的部落格

ISO 8.5.3 b) 為防止不符合事項之發生,組織應決定措施以消除潛在不符合事項之原因, 預防措施應與潛在問題之影響相稱, 文件化程序應予以建立,以界定下列各項要求:b) 評估採行措施之需要,以預防不符合事項之發生

 上述要求簡單易懂,但真正能落實的很少..很多供應商不是把矯正措施拿來當作預防措施,要不然就是不提,直接略過.探討其原因,主要是P6的原因分析作的不夠精緻仔細,或者是根本無法透析問題背後的問題(根因),以至於不知如何對症下藥.

 大家都知道5Why,因為照邏輯一直問下去,終究可以探討出真因,但是,我很少用,或者是說,我都是當根因被找出後,寫報告時才會用5Why,甚至於不用.因為我所遇到的問題,很少可以用5Why這樣一條鞭的方式找出根因,除非該問題是屬於簡單問題.否則,我還是都會乖乖的利用假設法搭配 FTA/系統圖來畫出問題的結構,並據以瞭解現況(NC,Controlled)..就是在P3步驟所描述的方式.

 不同於P4的風險管理(註:P4的風險管理主要是針對採購件,半成品,成品,庫存品,已出貨,已使用),在P7階段的風險管理,主要是針對即將採取的措施所可能存在的風險來辨識與規劃回應,其目的就是在有限的資源條件下找出最適解,而不是正確解.這點,也是我認為是優秀工程師或主管所該學習的一種專長,因為在投入資源之前若能掌握未來所有可能的不良變異而預先採取因應措施,那即時真的風險發生,那也不至於手忙腳亂不知所措.

我一直強調供應商的共同弱點:溝通管理,風險管理與執行力,其中風險管理就是考驗當責與負責的人員對於所處的環境(企業環境因素+組織流程資產)的掌握度是否足夠,以便能不浪費利害關係人寶貴的時間又能準時(或及時)的完成任務的一項功夫,這功夫讓我如此看重是因為負責人需要全盤掌握所處的環境(文化)與面對的難題(流程)才能找出一條順暢的道路繼續往下走,最後才能順利達標致果!

 通常也是在這個階段,我會對供應商提出的分析與建議案(Proposal)多所挑剔,因為一但雙方達成協議,那就表示資源準備投入,風險隨時會變成問題考驗團隊,而我的工作在此時就像是顧問一般提醒當責(A)與負責(R)是否該注意那些狀況(風險)未被考量

對於對應問題的解決措施(建議;Proposal),我會建議工程師最好養成習慣準備個2~4方案(通常我都是準備3個),一來可以練習你對問題如何解決的任何可能性是否徹底掌握,二來也可以讓不同利害關係人有更多解決方案互相討論蹦出絕妙的解答也說不定;因為不同階層,不同部門,不同經驗,掌握不同資源與看問題的廣度和深度的不同,每個人提出的看法多多少少都會不同.(時間軸,空間軸,角色,目的….).這對於當責人員是項不簡單的挑戰,而往往一個是否稱職的當責人員也可以在此proposal的產出上看出其邏輯思考功力與看問題的深度和廣度是否有機會真正解決問題.

 當然,並不是每個當責人員都是高手,這時候就需要大家集思廣益(專家判斷)來合作提出任何可能性(歸納,關連….)

決策分析的評估項目 

效率,

成本,(需將品質成本與淨現值納入考慮)

困難度,

掌握度,

風險,

其他…

談及效率:探討的是時間管理,我提出,決策並非要找正確解,而是應該找出最佳(適)解,舉例來說:距離婚禮只剩不到1小時,原本新郎指定的法拉利前導車因塞車無法準時到達,這時,如果我們一定要等到法拉利前導車,勢必影響婚禮舉行,所以,退而求其次,直接在親有團中另尋其他替代方案..因為此時的重點不是法拉利而是婚禮.

談及成本:除了可預知的花費(品質成本),我通常會快速計算以下成本: (相信我,老板都會看到底要花多少錢)

(1)   機會成本與沉沒成本

    機會成本Opportunity cost:選擇某個機會而必須放棄機會所損失的最高可能獲益

    沉沒成本Sunk cost:已投入無法回收的成本.在經濟學標準裡頭,有問題的專案是否繼續或中止的決策是不需要考量沉沒成本的

(2)   品質成本

預防成本:品質管理活動費、品質評審和審核費、培訓費、品質改進費等。

檢驗成本:檢驗費、試驗費、檢測設備費。

內部故障成本:廢品損失、返修或返工損失、事故處理費、 停工損失。

外部故障成本:保修費用、退貨損失、折價損失、責任賠償費、處罰損失。

談及困難度:這端賴當事者所提出的方案具體可行與所需搭配的條件為何,有時候困難是來自於準備時間不足,有時候是人員熟練度不夠, 或是該方案牽涉到Process re-regeneering..總之,就是討論資源易取得性,操作性與使用是否可以達成該有的績效.

談及掌握度:對於所列出的方案,分包商或其他部門的進度是否容易掌握(平衡矩陣或強矩陣組織),工藝條件是否需達到一定水準人員才可上手,遠距離安排人員作業的細節與協助部門是否溝通無誤….

談及風險:我將專案管理所學到的知名運用在此步驟上,條列如下:

  決策分析:風險管理

   風險:是一種不確定性的未來事件.若都不會發生(0%)或一定會發生(100%)就不是風險.

   風險不只是潛在的負向威脅(Threats),也可能是潛在的正向機會(Opportunities).

   風險發生在未來(Risk is always in the future).

   風險發生之原因包含:需求,假設,限制及其他可能對決策造成正面或負面得條件等.

   已發生的風險應視為一問題或議題(Issue)來處理之.

  辨識風險

   決定那些風險會影響決策結果,並記錄其特性.

   辨識風險需要一些利害關係者的參與.

   辨識風險是一個反覆執行的流程.

   在決策執行前即開始辨識風險.

  風險分類Risk Categorization

   專案的風險可以依風險的來源資料(如:使用風險分解結構RBS),被影響的專案範疇(如:WBS)或其他管理用途的分類(如:專案階段),用以辨別專案不確定性較高的風險

   將風險依原因分類可以發展有效的風險回應對策,依原因分類時,剔除一原因後,可以去除原因之下的多個風險

   風險的分類依據組織或專案歸類後的:共同功能或風險來源

   風險分類的方法有:

     外部:規範,環境,政府,市場變遷

     內部:時間,成本,範疇變更,無經驗,規劃不良,人員,材料,設備

     技術:技術變更

     不可預測的:只有一小部份風險(10%)是不可預測的

   執行定量風險分析Perform Quantitative Risk Analysis
     執行定量風險分析的流程,分析風險事件的衝擊並給予風險衝擊的量化數據,也提供決策者面對不確定性的定量分析
    找出專案整體風險
    找出成本預備金及預備時程
    當對專案的時程或成本有意義時才進行定量分析
     成本管理控制,對於預算或成本計畫方面之定量風險分析,有助於分析方法及結構之決定
     進度管理控制,對於進度方面之定量風險分析,有助於分析方法及結構之決定

 執行定性風險分析Perform Qualitative Risk Analysis

   包含將辨識的風險一其對專案的衝擊加以排序,是規劃風險回應的前置作業

   定性風險分析的排序是由前階段的辨識風險所完成的簡短清單來完成

   組織聚焦在高優先順序的風險,可以有效提昇專案績效

   定性風險分析使用風險發生的機率,對專案目標產生的衝擊及其影響專案的限制因素做分析

   在定性分析的過程中,可使用風險專家對類似專案的研究或來自產業,專利資料來源的有效風險資料庫

   欲有效進行定性風險分析,參與流程成員對於風險因素之態度甚為重要.若成員有主觀因素(Bias,偏見)發生時,應注意並對該行為糾正

  風險機率與衝擊評估Risk Probability and Impact Assessment
    定性風險分析是風險辨識後主觀性的分析,包含風險發生的機率及當風險發生時的衝擊
    風險機率評估研究個別風險發生的可能性
    風險衝擊評估研究對專案目標的潛在效應,如:時間,成本,品質或性能.包含機會與威脅
    每一個辨識的機會及威脅皆需被評估,風險可以使用訪談方式或與參與者開會讓他們選擇風險的等級,訪談對象也不僅止於內部,連外部專家亦可訪談
    假設的等級也應被記錄
    風險機率及衝擊依據風險管理計畫書定義來評分

 機率和衝擊矩陣Probability and Impact Matrix
    風險可以以定性分析後的評分來排出優先順序及依風險的評分來反應
    評分是依據評估後的風險機率和衝擊來決定
    評估每個風險的重要性可以參考機率和衝擊矩陣
    組織需辨別機率與衝擊的組合,若是較高的數字是高風險,較低的數字是低風險
   風險評定規則通常依組織流程資產所定義,並描述於風險管理計畫書中
   組織可以依個別的目標,如:成本,時間及範疇來評估風險.可以加上每個風險發展的方法建立整體的評分
   風險指數引導風險回應,一個高機率高負面衝擊的風險需排在較高的優先順位並主動回應
   對機會也是相同,一個高機率高正面效應的風險回應應優先實施

 風險急迫性評估Risk Urgent Assessment
  風險需要快速回應,專案開始執行之前可排出風險處理的優先順序
  優先順序指標可以包含風險的回應時間,徵兆,警告訊息及風險評分

 規劃風險回應Plan Risk Response
   規劃風險回應是發展額外的風險管理活動以提昇專案成功的機會並降低風險對 專案目標的威脅
   規劃風險回應包含指派一個或多個成員來承擔風險的責任並主動回應發生的風險
   規劃風險回應對回應不同風險的優先順序指派資源.規劃風險回應與風險的顯著性相呼應.從多個風險對策選出最佳的風險回應對策
   風險包含機會與威脅,都會影響專案的成敗
  回應負面風險或威脅的策略Strtegies for Negative Risks or Threats
    規避Avoid:改變專案計畫以排除風險與形成條件,或保護專案目標不受影響
    移轉(Transfer,deflect,allocate):將風險的後果連同責任轉移到第三者,典型作法為"保險".非積極手段,並沒有將風險去除或規避掉
    減輕Mitigate:設法把不利的風險機率或衝擊降到可接受的臨界值之下
     減輕機率:加強訓練,做更多測試
     減輕衝擊:做好失火應變措施,主機異地備份
    承擔Accept:很少專案可以完全消除所有的風險,專案團隊已不打算處置某風險或改變專案計畫
  回應正面風險或機會的策略Strtegies for Positive Risks or Opportunities
    開拓Exploit:目標在於確保機會得以實現,而積極消除風險的相關不確定性,如:  專案資源分配最好的專案經理或執行成員
    分享Share:將風險的責任分配給最能為專案利益獲取機會的第三方,如:策略聯盟
    增強Enhance:與減輕相反,讓好的機會發生機率提高或益處提高
    承擔Accept:承擔一個機會希望發生時可以利用,但不積極促使其發生
 

  應變回應策略Contingent Response Strategies
     發生特定事件時才使用
     經常制定一因應成本風險及時間風險之應變準備金(Contingency reserve),並預設動用該準備金之條件
    應確定及追蹤風險徵兆因素(Trigger)
     如:里程碑未如期完成,即啟動之前已擬定好的緊急應變計畫

  風險登錄表
   詳列各項已辨識風險的名稱,原因,類別,發生的機率,評估的衝擊,應對措施,負責人和目前的狀態.亦即包含風險識別,風險分析和風險回應規劃的結果;風險監控亦可能更新風險登錄表
   應變計畫(緊急應變計畫)包含在風險登錄表中
  請注意:風險登錄表並非風險管理計畫的一部份,兩者是不同的文件

  風險再評估Risk Reassessment
  使用風險管理流程對新風險進行辨識並對風險進行重新評估
  安排定期的專案風險再評估
  狀態審查會的議程應包含專案的風險審查

  風險稽核Risk Audits
  風險稽核在於檢查並記錄風險應對策略如何處理已識別的風險及追究其發生的根因,以及風險管理過程的效力
  想像一群稽核員詢問專案經理:請提出如何證明已辨識專案所有的風險?有相對應的重大風險應對計畫及風險觀察清單?當風險發生時,該風險負責人該如何處理?未處理的觀察清單的風險該如何Recview?這就是風險稽核

  風險管理的變異及趨勢分析Variance and Trend Analysis
  專案實施變異及趨勢分析,可以使用實獲值分析,變異分析和趨勢分析及其他方法,對專案整體績效進行監控.
  分析結果可以顯現專案完成時的成本與進度目標方面的潛在差異
  與計畫基準的差異表示威脅或機會的潛在影響
 各專案管理流程所更新的專案文件內容

 自製或外購分析Make-or-buy Analysis
  自製或外購分析是一般的管理技巧,屬專案採購規劃流程的一部份,可用來確認專案所需要特定產品或服務是由專案團隊來製作或外購
  自製或外購分析結果會受到專案的限制因素的影響
  當專案對某產品有持續性的需求且超過邊際效益時,建議直接購買(租或買的決策)
  專案團隊組織的長期策略規劃的需求,也可以當作自製或外購的考量,如:外包的專案在未來會有持續的需求,儘管已超過目前專案的範疇

 自製或外購決策Make-or-Buy Decisions
  紀錄專案的產品,服務或結果需要專案團隊自行製造或外購的文件
  這個決策包含考量是否將風險轉移給廠商
  自製或外購決策可以是簡單的列表包含簡要的決策原則,這些決策,這些決策可以回饋到其他採購活動的不同需求

 考慮自製的時機
  組織擁有自有的生產單位並且有多餘的產能
  專案組織對於產出成果的過程,想要得到較多的控制權
  牽涉到的產品或服務包含重要機密資訊或組織的智慧財產
 購買或租賃決策Buy-or-Rent Analysis
  計算原則以先計算出購買及租賃平衡點,再決定購買或租賃

決策

決策分析的主要活動

1. 決策聲明

2. 發展目標

3. 將目標分為[必要]及[想要]

4. 對[想要]目標予以加權

5. 產生可選擇的方案:多多益善

6. 運用[必要]目標來篩選可選擇的方案:OK,NG

7. 運用[想要]目標來比較可選擇的方案:0~10

8. 找出不利的後果(風險管理)

9. 做最好,最平衡的選擇:篩選方案

把每個選項獲得的權值加總,得分最高者即為最優先的選擇.

杜拉克:做出正確決定是經由不同主張的衝突和碰撞,以及對於替代方案的嚴密思考而產生的

不要為了付諸行動,而將目光鎖定在自己較有把握的解決方案來看問題,如此,很有可能會把自己推向離成功更遠的境界

決策評估之前需先決定決策限制之必要條件(Must)以免評比項目立足點不平等

決策採用的方法:

(1)   多數表決法-可以快速達成決定.

(2)   德爾菲-可將多樣選項縮小至較少項目以取得共識

(3)   決策矩陣法-極為邏輯的選擇方式,可對各種方案進行比較,並對concern的因素加上權重以利理性判斷.

決策分析(預防措施),大部份的品質議題我都會分成2個區塊來討論 : 管理面與技術面

所謂管理面:主要是著眼於QMS是否有不足的地方需補強,需改進,需增加,或是需要修正的(整理如下);通常也包含抽樣計畫(暫時措施與長期變更)

所謂技術面:主要是依據要因分析後,如果判斷是設計風險,Process管制範圍不佳,或是模具尺寸管控不當,模具設計規範不佳.雖然討論的是技術面,但常常最後還是會回到管理層次來討論,因為到最後,這些都是QMS的一環,也都是管理的問題!

QMS可能會遇到需要討論的章節,我將ISO 7.產品實現所需注意的重點整理如下,若牽涉到其他條文,則參考教材附件內容!

ISO 7.1 產品實現之規劃
     1) 產品實現的要求焦點在於[品質保證]
     2) 產品實現過程的三種型態的系統要求原則都是一致的:規劃,執行,查證
          2-1)三種型態: 設計與開發,生產與服務,採購與分包
          2-2)在規劃之前,必須先確定[目標與要求]-->套用PSM
   3)關於產品實現過程的[工作說明書]:[執行]階段的管理焦點不是[建立]而是[備妥]與[使用].
 4)工作說明書在執行階段的[備妥與使用]並不是強制性的要求,而需視實際[需要]或[使用]之狀況而定.而是否[需要]或[適用]的依據是:當[缺少]時是否會[對品質有所不利]
 5) 產品實現之規劃的重點
    5-1) 要求,過程以及查證等規劃明確
    5-2) 產品實現過程所需的資源有明確的規劃
    5-3) 產品的允收準則明確(7.3.3/7.1 c)/8.2.4)

    ISO 7.2 顧客有關之過程

   1) 顧客要求的符合不能確保顧客滿意度高,透過顧客要求的重新界定,可以提升顧客使用滿意度
   2) 產品有關要求必須包含:
        2-1) 顧客明示的要求
        2-2) 非顧客明示要求但為已知使用所需之要求(物超所值)
        2-3) 與產品之法令與規章要求
        2-4) 組織認為需要之任何附加要求(物超所值)
   3) 產品有關要求不只限定於[產品本身]的要求,還包含[品質管理系統]與[產品實現過程]的相關要求
   4) ISO條文帶有"需","應"有135處;If..., then..屬於強制要求
   5) [產品有關要求]不只是[顧客提出的要求],要補足[法令要求]與[顧客使用利益考量的要求]


          ISO 7.2.2 產品有關要求之審查

   1)產品有關要求審查不等於合約審查
   2)對於不可直接互懂之交易方式(如網際網路銷售),此項審查則以充分之產品資訊,型錄,廣告資料以及交易規定等方式處理
   3) 產品有關要求之審查,
        3-1) 是[事前]的審查,不是事後的處理;
       3-2) 不只涵蓋[書面合約],還有其他要求事項
       3-3) 除了管制其確認,還要管制其變更

          ISO 7.2.3顧客溝通[談效率與效果問題]

    1) 透過有效的溝通,確保[產品有關要求]與[組織的供應能力]相符

 如果只是藉由e-mail方式表達建議的決策,我都是採取以下寫法:

1.      議題(原由)說明

2.      現況分析

3.      建議措施(3~4項)優缺點分析與我所建議採取的措施(通常都擺在第一位以取得心錨效應)

4.      附件(建議措施的細部分析內容;其他分析報告或數據)

 ISO 8.5.3 b) 為防止不符合事項之發生,組織應決定措施以消除潛在不符合事項之原因, 預防措施應與潛在問題之影響相稱, 文件化程序應予以建立,以界定下列各項要求:

c) 決定與實施所需之措施

Action plan:如同握在P5的 監控管制列出的項目(如下),在經過決策分析與確認後,當責人員需要彙整所有action items並以一正式格式(通常為excel表)納入追蹤:

一般工程師對於提出action item與更新狀態,應該是不會有太大問題,但,就我習慣而言,我會以甘特圖為基礎並在action item列出:

(1)    No:供快速辨識

(2)    Issue description

(3)    負責人

(4)    Due date

(5)    Status

(6)    Cost

(7)    Actual Closed date/ Accumulated cost

(8)    殘留問題

這階段是我歸納觀察過的公司共通弱點之一:執行力(其他為:溝通管理,風險管理).因為議題都是需要跨部門來處理,若其中一部門的執行力不佳,那是很容易拖累整體進度,就好比是弱矩陣的組織,部門經理的權責往往都比專案經理(當責人員)來的大,除非有上層高階主管支持並搭配強有而力的負責人(R,此即為我在P2所提到人員的重要性,因為往往某(些)人的認知偏差或方向設定錯誤,很容易造成資源浪費,最後變成事倍功半(甚至於是無功)的後果.)