过程失效模式及后果分析.docx

上传人:b****1 文档编号:18647670 上传时间:2023-08-24 格式:DOCX 页数:19 大小:27.63KB
下载 相关 举报
过程失效模式及后果分析.docx_第1页
第1页 / 共19页
过程失效模式及后果分析.docx_第2页
第2页 / 共19页
过程失效模式及后果分析.docx_第3页
第3页 / 共19页
过程失效模式及后果分析.docx_第4页
第4页 / 共19页
过程失效模式及后果分析.docx_第5页
第5页 / 共19页
过程失效模式及后果分析.docx_第6页
第6页 / 共19页
过程失效模式及后果分析.docx_第7页
第7页 / 共19页
过程失效模式及后果分析.docx_第8页
第8页 / 共19页
过程失效模式及后果分析.docx_第9页
第9页 / 共19页
过程失效模式及后果分析.docx_第10页
第10页 / 共19页
过程失效模式及后果分析.docx_第11页
第11页 / 共19页
过程失效模式及后果分析.docx_第12页
第12页 / 共19页
过程失效模式及后果分析.docx_第13页
第13页 / 共19页
过程失效模式及后果分析.docx_第14页
第14页 / 共19页
过程失效模式及后果分析.docx_第15页
第15页 / 共19页
过程失效模式及后果分析.docx_第16页
第16页 / 共19页
过程失效模式及后果分析.docx_第17页
第17页 / 共19页
过程失效模式及后果分析.docx_第18页
第18页 / 共19页
过程失效模式及后果分析.docx_第19页
第19页 / 共19页
亲,该文档总共19页,全部预览完了,如果喜欢就下载吧!
下载资源
资源描述

过程失效模式及后果分析.docx

《过程失效模式及后果分析.docx》由会员分享,可在线阅读,更多相关《过程失效模式及后果分析.docx(19页珍藏版)》请在冰点文库上搜索。

过程失效模式及后果分析.docx

过程失效模式及后果分析

過程失效模式及後果分析(PFMEA):

制定項目風險管理計畫的有效工具

2003年2月1日,美國東部時間上午9時(北京時間1日22時),即將返航的哥倫比亞號太空梭在大約63km高空處與地面控制中心失去聯繫,在德克薩斯州中部地區上空爆炸解體,機上7名太空人全部遇難。

專案的失敗,使人類付出了生命的代價!

那麼,怎樣去減少項目失敗的風險呢?

項目風險是一種不確定的事件或條件,這種事件或條件一旦發生,就會對專案目標產生某種程度的影響,或者導致專案進度拖期、成本超支,或者引起品質事故、客戶投訴,甚至引發專案執行不下去、系統癱瘓、機毀人亡的災難。

項目的風險事件或條件往往具有不確定性,但它發生後對項目的範圍、成本、進度、品質性能等方面的影響卻是肯定的。

因此,專案管理人員必須具備“生於憂患,死於安樂”的意識,在執行專案之前就盡可能識別出項目的各種風險,並由此制定出周密的風險管理計畫,以便能夠在項目執行期間有效地監控和回應,從而消除風險事件對項目的影響或者將其影響降至最小,做到化險為夷。

過程失效模式及後果分析(ProcessFailureModesandEffectsAnalysis,簡稱PFMEA)是一種綜合分析技術,主要用來分析和識別工藝生產或產品製造過程可能出現的失效模式,以及這些失效模式發生後對產品質量的影響,從而有針對性地制定出控制措施以有效地減少工藝生產和產品製造過程中的風險。

這項綜合分析技術出現於上世紀60年代中期,最早應用在美國航空航天領域,如阿波羅登月計畫,1974年被美國海軍採用,再後來被通用汽車、福特和克萊斯諾三大汽車公司用來減少產品製造及工藝生產過程中出現的失效方式,從而達到控制和提升產品品質的目的。

PFMEA以其最嚴密的形式總結了人們在進行工藝生產和產品製造過程中防範于未然、追求卓越的思想,它通過對工藝生產和產品製造過程要求和功能的系統分析,憑藉已往的經驗和過去發生的問題,在最大範圍內充分考慮到那些潛在的失效模式及其相關的起因與後果,從而解決在產品生產過程中的一個關鍵問題:

產品生產和工藝過程可能會出現什麼差錯,導致產品無法發揮原先設計的功能?

1.PFMEA的原理

PFMEA的分析原理如表1-1所示,它包括以下幾個關鍵步驟:

§ 確定與工藝生產或產品製造過程相關的潛在失效模式與起因;

§ 評價失效對產品品質和顧客的潛在影響;

§ 找出減少失效發生或失效條件的程序控制變數,並制定糾正和預防措施;

§ 編制潛在失效模式分級表,確保嚴重的失效模式得到優先控制;

§ 跟蹤控制措施的實施情況,更新失效模式分級表;

表1-1過程失效模式及後果分析

 

過程失效模式及後果分析(PFMEA)

 過程功能/要求

 潛在失效模式

 失效後果

嚴重性

失效的原因/機理

可能性

現行控制方法

不易探測性

風險級

 建議採取的措施

❾措施結果

嚴重性

可能性

不易探測性

風險級

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

這裡,專案管理培訓

(1) “過程功能/要求”:

是指被分析的過程或工藝。

該過程或工藝可以是技術過程,如焊接、產品設計、軟體代碼編寫等,也可以是管理過程,如計畫編制、設計評審等。

盡可能簡單地說明該工藝過程或工序的目的,如果工藝過程包括許多具有不同失效模式的工序,那麼可以把這些工序或要求作為獨立過程列出;

(2) “潛在的失效模式”:

是指過程可能發生的不滿足過程要求或設計意圖的形式或問題點,是對某具體工序不符合要求的描述。

它可能是引起下一道工序的潛在失效模式,也可能是上一道工序失效模式的後果。

典型的失效模式包括斷裂、變形、安裝調試不當等;

(3) “失效後果”:

是指失效模式對產品品質和顧客可能引發的不良影響,根據顧客可能注意到或經歷的情況來描述失效後果,對最終使用者來說,失效的後果應一律用產品或系統的性能來闡述,如雜訊、異味、不起作用等;

(4) “嚴重性”:

是潛在失效模式對顧客影響後果的嚴重程度,為了準確定義失效模式的不良影響,通常需要對每種失效模式的潛在影響進行評價並賦予分值,用1-10分表示,分值愈高則影響愈嚴重。

“可能性”:

是指具體的失效起因發生的概率,可能性的分級數著重在其含義而不是數值,通常也用1—10分來評估可能性的大小,分值愈高則出現機會愈大。

“不易探測度”:

是指在零部件離開製造工序或裝備工位元之前,發現失效起因過程缺陷的難易程度,評價指標也分為1—10級,得分愈高則愈難以被發現和檢查出;

(5) “失效的原因/機理”:

是指失效是怎麼發生的,並依據可以糾正或控制的原則來描述,針對每一個潛在的失效模式在盡可能廣的範圍內,列出每個可以想到的失效起因,如果起因對失效模式來說是唯一的,那麼考慮過程就完成了。

否則,還要在眾多的起因中分析出根本原因,以便針對那些相關的因素採取糾正措施,典型的失效起因包括:

焊接不正確、潤滑不當、零件裝錯等;轉自專案管理者聯盟

(6) “現行控制方法”:

是對當前使用的、盡可能阻止失效模式的發生或是探測出將發生的失效模式的控制方法的描述。

這些控制方法可以是物理程序控制方法,如使用防錯卡具,或者管理程序控制方法,如採用統計程序控制(SPC)技術;

(7) “風險級(RPN)”:

是嚴重性、可能性和不易探測性三者的乘積。

該數值愈大則表明這一潛在問題愈嚴重,愈應及時採取糾正措施,以便努力減少該值。

在一般情況下,不管風險級的數值如何,當嚴重性高時,應予以特別注意;專案管理論壇

專案經理博客

(8) “建議採取的措施”:

是為了減少風險發生的嚴重性、可能性或不易探測性數值而制定的應對方案,包括行動計畫或措施、責任人、可能需要的資源和完成日期等。

當失效模式排出先後次序後應首先對排在最前面的風險事件或嚴重性高的事件採取糾正措施,任何建議措施的目的都是為了阻止其發生,或減少發生後的影響和損失;

轉自專案管理者聯盟

(9) “措施結果”:

是對上述“建議採取的措施”計畫方案之實施狀況的跟蹤和確認。

在明確了糾正措施後,重新估計並記錄採取糾正措施後的嚴重性、可能性和不易探測性數值,計算並記錄糾正後的新的風險級值,該數值應當比措施結果之前的風險級值低得多,從而表明採取措施後能夠充分降低失效帶來的風險。

2.運用PFMEA制定項目風險管理計畫項目經理博客

由表1-1可以發現,PFMEA事實上就是一套嚴密的識別、控制、改善失效模式的管理過程,通過對過程失效模式及其後果的系統分析,制定出相應地預防措施和行動方案,從而大大降低失敗的機會。

這種系統分析工具不僅可在工藝過程的管理中,也可應用於任何期望能嚴格控制潛在問題出現的管理過程,尤其是產品或服務品質的好壞可能會極大影響到顧客利益的領域。

當然在具體應用的時候,不一定完全按照PFMEA給定的“嚴重性”、“可能性”及“不易探測性”之評價標準進行評分,完全可以視本行業或管理過程的實際情況來設定一系列類似的評價標準,並且在具體操作手法上也可根據實情採用適合於自身的方式,只要能達到更有效地識別、控制潛在問題的發生、提高管理過程品質的目的即可。

專案管理論壇

 項目管理本身就是一種過程管理,目的就是要在規定的時間、在批准的預算、完成事先確定的任務並達到品質性能標準要求,風險事件或條件就是專案過程中潛在的失效模式,它們的發生可能導致專案的上述目標無法實現。

只要對上述PFMEA的原理稍加改造,就可以成為一種有效地制定項目風險管理計畫的工具,如表1-2所示。

表1-2項目風險管理計畫

 

項目風險管理計畫

專案管理過程

�風險識別

❸風險評估

�風險應對措施

潛在的風險事件

風險發生的後果

可能性

嚴重性

不可控性

風險級

 應急措施

預防措施

責任人

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

這裡,

a) “專案管理過程”:

是指項目管理生命期的啟動、計畫、執行、控制和收尾五個過程。

在不同的行業,專案管理過程的叫法可能不一樣,如軟體發展專案通常分為需求分析、系統設計、編碼、測試、上線安裝和系統維護幾個過程,而工程建設專案則分為專案評估、設計準備、設計、施工、驗收與移交等幾個過程;專案管理者聯盟

b) “風險識別”:

風險識別包括確定那些潛在的、可能對專案造成影響的風險事件,只有事先識別出了這些風險事件並且知道了它們對項目可能帶來怎樣的影響,才談得上對其進行應對和處理。

因此,風險識別是制定項目風險管理計畫的第一步。

由於專案管理處於一個動態的環境中,隨著項目的進展原先可能導致專案風險的機會和條件或許已經不復存在,而新的機會和條件可能發生,因此風險識別並不是一僦而就的事情,往往需要貫穿專案執行的始終。

專案小組通常使用頭腦風暴法、故障樹分析、系統分解法、檢查表法、德爾菲法、SWOT分析技術等方法來識別專案的風險事件。

風險發生的後果可能導致專案進度拖期,成本超支,利潤降低,品質或安全事故,人員士氣低落或流失,客戶不滿意或投訴、專案取消等;

c) “風險評估”:

是在風險識別的基礎上對每種風險事件對項目的影響進行定性或定量的分析,並根據風險對專案目標的影響程度對專案風險由大到小分級排序的過程。

定性評估是從類別上評價出已識別出的專案風險的影響和可能性大小,一般分為高、中、低三檔。

低風險是指發生的可能性相當低,發生後對項目的影響也無關緊要,又很容易被專案小組控制的風險,這類風險不需要採取其它的專門措施來處理;中等風險是指發生的可能性比較高,對項目的技術性能、成本或進度將產生較大影響,並且控制起來又有一定難度的風險,這類風險,需要對其進行有效的監控和評審,並應採取適當的手段或行動來降低風險;高風險是指發生的可能性很高,其後果將對項目產生極大影響,並且運用現有的技術條件和手段又很難控制的風險。

表1-3是借助風險識別檢查單,運用定性的方法評估出的專案的風險情況。

該專案有哪些風險,其中哪些風險低,哪些中等,哪些高,從表中一目了然。

 

表1-3   風險識別清單及定性評估結果

 

風險領域

 

風險因素

風險定性評估

客戶資訊

▪        新客戶

▪        客戶的原則性

▪        影響客戶的數量

▪        客戶提供的資訊

及時

 

晚到

產品要求

▪     產品的性質

▪     產品的品質性能要求

一般產品

清楚

 

模糊

特殊產品

不清楚

時間

▪     專案工期

▪     專案的交付結果

▪     對進度的要求

正常

按時

專案小組決定

 

趕工期

拖期

客戶決定

技術

▪     工藝

▪     零件

▪     設計能力

成熟

 

資源

▪     人力

▪     資金

▪     生產能力

▪     測試設備

充足

落實到位

足夠

具備

 

不足

沒有著落

不足

財務

▪     投資回報率

▪     資金計畫

▪     利潤幅度

▪     外匯匯率

可接受

已審批

 

太高

未審批

分包商

▪     數量

▪     經驗

▪     資質

 

定量分析是量化分析每一風險的概率及其對專案目標造成後果的嚴重程度,並得出每種風險大小及其嚴重程度的一種方法。

一般來講,風險定量評估是在定性評估的基礎上進行的,通常採用從若干方面逐項評分的方法來量化風險的大小,即事先確定評分的標準,然後由專案小組一起,對預先識別出的專案風險一一打分,然後得出不同風險之大小,按照PFMEA的思想,可以從風險時間發生的可能性、風險發生對專案影響的嚴重性和專案小組能否有效控制風險發生三方面來定量分析。

如圖1-4所示。

例如,可以從1到10分的等級來評估風險,如果項目小組在評估發生資金短缺的風險時,認為它非常不可能發生,得3分,但是一旦發生後果則非常嚴重,得9分;而且,資金短缺項目小組很難控制,得8分,然後把這三個數字相乘,即得到該風險的風險級別(RPN)。

風險級別越高,表示風險越大,需要專案小組制定相應的措施認真對待。

表1-4風險定量評估標準

 

分數

嚴重性

可能性

不可控性

10

嚴重影響專案,導致專案取消,而且沒有警示。

非常高,

頻繁發生

大於或等於每小時一次

絕對不能控制,只能聽天由命。

9

嚴重影響專案,導致專案取消,但有警示。

很高,經常發生.

一天兩次

利用現有的技術和條件幾乎不能控制。

如需控制,需要創造一定的條件。

8

嚴重影響專案目標的實現,可能導致嚴重的拖期、超支或品質問題。

高,經常發生.

一天一次

利用現有的技術和條件控制難度很大,可能需要其他條件。

7

專案的進度、成本或品質性能受到顯著影響,可能導致有些工作不能完成,客戶不會很滿意。

較高,經常發生.

每週一次

利用現有的技術和條件有一定的難度。

但不需要其他條件。

6

專案的進度、成本或品質性能受到一些影響,工作然可以完成,但客戶不滿意。

中等,時有發生.

每月一次

利用現有的技術和條件能夠控制。

5

專案的進度、成本或品質性能受到輕微影響,客戶會有輕微不滿。

中等,時有發生.

每年兩次

無徵兆,利用現有技術和條件容易控制。

4

專案受到一些影響,客戶也將認識到這種影響。

中等,偶爾發生.

每年一次

無徵兆,能夠控制

3

對專案有比較小的影響,客戶意識到這種影響。

低,很少發生.

每兩年一次

有徵兆,能夠控制。

2

影響如此之小,以至於只有少數客戶發覺這種影響。

很低,幾乎從來不發生.

第五年一次

有明顯徵兆,很容易控制。

1

無影響

不發生

每十年還不到一次

一眼就能看出問題,控制它不費吹灰之力。

d) “風險應對措施”:

包括緊急措施和預防措施,緊急措施是風險發生後採取的應對措施,而預防措施則是為了防止同樣的問題再次出現所採取的防患措施。

常用的風險應對措施包括:

a) 回避

風險回避有兩種含義,一是指風險發生的可能性極大,後果極其嚴重,又不能控制,感到無計可施,於是主動放棄專案或改變專案目標的策略;二是通過變更專案計劃,消除風險事件本身或風險產生的條件,從而保護專案目標免受影響的方法。

雖然項目團隊永遠不可能消除所有的風險,但某些特定的風險還是可能回避的。

例如,保險公司認為某專案的風險太大,拒絕承保;採用一種熟悉的、而不是創新的方法;避免使用一個不熟悉的分承包商;建築工程上儘量避開梅雨季節施工等,這些都都是風險回避的例子。

美國挑戰者太空梭升空後爆炸,就是因為其中一個密封圈在低溫下發裂,如果等到預熱後再進行發射,就有可能避免這場悲劇,這個推遲發射的決定就是風險回避。

轉自專案管理者聯盟

b) 轉移

風險轉移是設法將風險的結果連同對風險進行應對的權利轉移給另一方。

風險轉移本身不能降低風險發生的概率,也不能減輕風險帶來損失的大小,只是將風險損失的一部分轉移給他人。

從財務的角度看,轉移風險的財務責任是風險轉移最為有效的方法。

轉移風險幾乎總是會伴有向接受風險的一方支付風險成本,這類成本包括保險費用、履約保證金、擔保和保證費用。

或者,可以使用合同方式將某些特定風險的責任轉移給另一方。

例如,如果專案的設計不是十分成熟,那麼使用固定價格合同就可能將責任轉移給賣方。

風險轉移的方法主要有:

出售、分包、保險與擔保等。

專案經理圈子

c) 緩解

緩解是設法將某一負面風險事件的概率和/或其後果降低到一種可以承受的限度。

早期採取措施,降低風險發生的概率或風險對專案的影響,比在風險發生後再亡羊補牢要更為有效。

但是,對照風險可能的概率和其後果,緩解的成本應是合理的。

專案管理者聯盟

風險緩解採用的形式可能是執行一種減少問題的新的行動方案。

例如,採用更簡單一些的作業過程、進行更多的地震實驗或工程技術試驗、或挑選更穩定的賣方。

它可能涉及變更環境條件,以使風險發生的概率降低,例如,增加專案資源或給進度計畫增加時間。

風險緩解可能需要進行模型開發,以減少由模型放大帶來的風險。

如果在風險發生時,我們能採取應急措施,就能減輕其後果。

例如,汽車裡安裝安全氣囊,就是試圖在萬一發生幢車事故時,減輕駕駛員和乘客受傷的程度。

在涉及采購的專案中,獨家供貨是必須考慮的風險,緩解風險就是開發第二貨源,這樣,如果其中一個供應商不能時或按規定要求供貨,另外一個供應商可能能夠做到,這種方法可以認為是風險減緩。

d) 接受

風險接受就是項目小組將風險的後果自願接受下來的辦法,風險接受可以是主動和積極的,也可以是被動和消極的。

前者是已經有了行動計畫和應急方案,當風險事件發生時馬上執行這些計畫和方案;後者是並沒有事先制定風險應對計畫,而是在風險發生時,由專案小組臨時採取權變措施來對付風險。

風險接受決不是被動挨打,如果能提前制訂應急計畫,將會大大減少風險發生時應對行動的成本。

如果風險發生後影響巨大,或所選擇的方案可能並不完全奏效,那麼就應著手編制一個後備措施,後備措施可能包括管理後備措施、研發後備措施、進度後備措施等。

表1-5就是運用PFMEA的原理,制定出的軟體發展項目的風險管理計畫。

表1-5某軟體發展項目的風險管理計畫

 

項目風險管理計畫

 

 

專案管理過程

風險識別

風險評估

風險應對措施

 

潛在的風險事件

 

風險發生的後果

可能性

嚴重性

不可控性

風險級

 

應急措施

 

預防措施

責任人

需求分析

客戶的需求不明確;

項目範圍定義不清楚;

 

專案目標不明確;

與客戶溝通不夠;

分析員對客戶業務瞭解不夠;

分析員沒有真正理解客戶需求;

沒有進行可行性研究;

需求分析報告沒有得到客戶的確認;

需求不斷變化;

缺乏有效的需求變化管理過程;

任務定義不夠充分;

客戶不接受產品或拒絕付款

項目沒完沒了

 

專案進度拖期或成本超支

軟體不能滿足客戶需求

軟體不能實現業務功能

 

軟體不能滿足客戶需求

 

專案失敗或執行不下去

客戶拒絕簽字、驗收

 

項目變得沒完沒了

專案不能按時、按預算完成

 

專案不能按時、按預算完成

 

5

8

 

6

5

6

 

8

 

5

5

 

8

5

 

6

 

10

9

 

8

9

9

 

10

 

10

10

 

9

8

 

8

6

5

 

5

6

5

 

7

 

5

4

 

5

4

 

5

300

360

 

240

270

270

 

560

 

250

200

 

360

160

 

240

按照客戶的要求修改

按照客戶要求變更

 

修改專案目標

立即與客戶進行溝通

修改軟體

 

根據客戶要求修改

 

取消專案或修改目標

按照客戶要求修改

 

提交CCB討論、決定

對需求變化進行評審

 

重新定義

 

事先進行需求評審

事先定義清楚並獲得客戶的確認

事先明確專案目標

制定溝通管理計畫

加強瞭解並讓客戶參與

讓客戶確認需求報告

 

進行認真分析和研究

事先獲取客戶確認

 

建立範圍變更程式

建立需求變更程式

 

事先與客戶達成共識

李偉

李偉

李偉

李偉

 

設計

缺乏有經驗的分析員;

設計偏離客戶需求;

沒有變更控制計畫;

軟體功能漏項;

分析錯誤或不可行

軟體不能滿足需求,客戶拒絕接受

客戶不滿意

 

4

5

 

4

10

10

 

8

5

5

 

5

200

250

 

160

培訓或換人

修改設計

 

增加相應的功能

配備有經驗的分析員

進行設計評審

 

進行設計評審、獲得客戶確認

 

編碼

程式師對系統設計的理解上出現偏差;

程式師開發能力差;

程式師不熟悉開發工具;

開發環境沒準備好;

設計錯誤導致編碼實現困難;

客戶要求增加功能;

項目交付時間提前;

程式師離開;

開發團隊內部溝通不夠;

軟體實現不了設計的功能,客戶拒絕接受

專案進度拖期、品質問題

專案進度拖期

專案進度拖期、品質問題

專案進度拖期、品質問題

 

專案進度拖期、成本超支

品質問題

專案執行不下去

介面混亂、品質問題

6

 

3

4

3

4

 

8

4

5

5

 

9

 

9

8

8

10

 

7

8

10

8

 

5

 

4

5

4

5

 

5

5

4

4

270

 

108

160

96

200

 

280

160

200

160

 

修改代碼

 

培訓或換人

培訓或換人

立即改進

修改設計

 

修改程式

加班加點或增加資源

臨時替補人員

修改程式

進行設計評審

 

配備精兵強將

事先提供培訓

提前準備

編碼之前進行設計評審

事先確定專案範圍

合同固定交付時間

與相關人員簽訂合同

展开阅读全文
相关资源
猜你喜欢
相关搜索
资源标签

当前位置:首页 > 自然科学 > 物理

copyright@ 2008-2023 冰点文库 网站版权所有

经营许可证编号:鄂ICP备19020893号-2