过程失效模式及后果分析(PFMEA)

合集下载
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

过程失效模式及后果分析(PFMEA)
过程失效模式及后果分析(Process Failure Modes and Effects Analysis,简称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 的原理,制定出的软件开发项目的风险管理计划。

项目风险管理计划
风险识别
风险评估 风险应对措施
项目管理过程
潜在的风险事件
风险发生的后果
可能性
严重性不可控性风险级
应急措施
预防措施
责任人
需求分析 客户的需求不明确; 项目范围定义不清楚;
项目目标不明确; 与客户沟通不够; 分析员对客户业务了解不够; 分析员没有真正理解客户需求; 没有进行可行性研究;
需求分析报告没有得到客户的确认; 需求不断变化; 缺乏有效的需求变化管理过程;
任务定义不够充分; 客户不接受产品或拒绝付款 项目没完没了 项目进度拖期或成本超支 软件不能满足客户需求 软件不能实现业务功能
软件不能满足客户需求
项目失败或执行不下去 客户拒绝签字、验收
项目变得没完没了 项目不能按时、按预算完成
项目不能按时、按预算完成
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
300360 240270270 560
250200
360160
240按照客户的要求修改 按照客户要求变更
修改项目目标 立即与客户进行沟通
修改软件 根据客户要求修改
取消项目或修改目标 按照客户要求修改 提交CCB 讨论、决定 对需求变化进行评审 重新定义
事先进行需求评审
事先定义清楚并获得客户的确认事先明确项目目标 制定沟通管理计

加强了解并让客户参与 让客户确认需求报告 进行认真分析和研究 事先获取客户确
认 建立范围变更程序 建立需求变更程

事先与客户达成共识
李伟李伟
李伟
李伟 设计 缺乏有经验的分析员;
设计偏离客户需求; 没有变更控制计划; 软件功能漏项;
分析错误或不可行 软件不能满足需求,客户拒绝接受 客户不满意
4 5
4
10 10 8
5 5 5
200250
160培训或换人 修改设计
增加相应的功能 配备有经验的分析员 进行设计评审
进行设计评审、获得客户确认
编码
程序员对系统设计的理解上出现偏差;
程序员开发能力差; 程序员不熟悉开发工具;
开发环境没准备好; 软件实现不了设计的功能,客户拒绝接受
项目进度拖期、质量问题 项目进度拖期
项目进度拖期、质量问6 3 4 3
4 9 9 8 8
10 5 4 5 4
5
270
10816096
200修改代码
培训或换人 培训或换人 立即改进 修改设计
进行设计评审
配备精兵强将 事先提供培训 提前准备 编码之前进行设
设计错误导致编码实现困难;
客户要求增加功能;项目交付时间提前;程序员离开;
开发团队内部沟通不够; 题
项目进度拖期、质量问

项目进度拖期、成本超

质量问题
项目执行不下去
接口混乱、质量问题
8
4
5
5
7
8
10
8
5
5
4
4
280
160
200
160
修改程序
加班加点或增加
资源
临时替补人员
修改程序
计评审
事先确定项目范

合同固定交付时

与相关人员签订
合同
制定内部沟通计

测试 没有切实可行的测试
计划;
测试人员不能按时到
位;
测试人员经验不足;
测试设备故障;
测试期间出现重大问
题;
没有有效的备份方
案;
测试发现的问题迟迟
解决不了; 项目拖期、质量问题发
现不了
项目进度拖期
程序问题发现不了
项目拖期
客户拒绝接受产品
数据丢失无法挽救
项目进度拖期
2
2
4
3
4
4
3
9
7
6
8
10
9
9
5
3
3
4
5
4
5
90
42
72
96
200
106
135
修改测试计划
临时安排测试人

培训或换人
修理或换设备
修改程序
重新开始
加快解决
事先评审测试计

制定出人力资源
计划
选择有经验的人

加强设备预防性
维修
分步测试
异地双重备份
专家会诊解决
上线安装 设备不能按时到位;
运行时质量问题多;
客户突然要求增加功
能;
重要的记录、文件、
数据丢失;
系统崩溃; 项目进度拖期
客户投诉
项目进度拖期、成本超

客户投诉、要求赔偿
客户要求承担损失
3
6
7
3
2
8
8
8
9
10
4
4
5
5
3
92
172
280
135
60
催设备供应商
即时解决问题
作出相应修改
重新生成数据
加紧修复
提前采购或合同
约束
事先进行局部运

事先确定项目范
围和功能要求
作好备份
事先备份
维护 出现故障,用户维护
人员解决不了;
用户手册错误多;
培训手册没有按时准
备好;
培训效果差; 客户投诉
客户投诉
客户投诉,培训不能按
时进行
客户不满意
8
3
3
3
8
6
5
6
8
4
3
3
512
72
45
54
派技术人员帮助
解决
修改错误
加班加点准备
重新培训
事先培训客户系
统维护人员
专人检查
提前准备出来
确定标准、充分准
备、把好培训师质
量关
在这样的风险管理计划基础上,然后按照风险级的大小将项目评分最高的前10个风险按大小排序,形成“top10”,也就是“前10个风险列表”,并将它们作为控制对象,以便在项目的执行过程中密切监控这10个可能会给项目带来严重问题的风险。

这样,无论是这些严重的风险还是其他一般风险一旦发生了,就能做到“兵来将挡,水来土淹”。

由于项目的执行处于一个动态的环境中,随着条件的变化“top 10”可能发生变化,因此,还要在项目关键里程碑事件实现后再次评估存在的风险,形成新的“前10个风险列表”。

相关文档
最新文档