-
产品中心
产品体验
质量管理解决方案
质量管理案例
-
服务与支持
-
关于我们
-
联系我们
FMEA应用于IT项目风险管理解决方案
- 【导读】
- 在IT项目中，软件部分或软件产品占了很大的比重，软件是IT项目的重中之重。在软件中使用FMEA的基本思想是：列举和识别软件在生命周期各阶段存在的潜在失效模式、综合评估各个失效
3．1 应用FMEA进行IT项目风险管理的可行性
在IT项目中，软件部分或软件产品占了很大的比重，软件是IT项目的重中之重。在软件中使用FMEA的基本思想是：列举和识别软件在生命周期各阶段存在的潜在失效模式、综合评估各个失效模式对系统产生的影响、排序确定优先级并提出有效的预防和改善措施。软件的失效模式可以理解为是系统的非预期行为。下面给出几个基本概念：
a．软件失效：指软件在使用中丧失了全部或部分功能，出现了与预期相偏离或背离的非正常状态，多数是由软件的故障或错误引发的。
b．失效原因：指设计缺陷、错误调用、接口信息错误、设备或电路损坏、管理不力、思考不全面等引起失效模式发生的原因。这些原因要给与足够的重视，因为可能导致软件失效或软件失败。
c．失效模式：指失效的方式或者是失效对系统造成的影响。
d．失效影响：指失效模式对软件系统的运行、状态和功能产生的影响。
e．失效模式及后果分析：指对软件系统中存在的失效模式及其后果进行分析。
WBS，即Work Breakdown Structure，中文译为工作分解结构。工作分解结构是最常用的一种整理项目范围的方法。WBS将项目分解成可以管理的小单元，使得可以更加容易的控制和掌握小单元的进度和成本。建立一个良好的WBS结构是项目管理能否成功的重要因素之一。
以下几点可以为在IT项目中应用FMEA提供可行性依据：
(1)FMEA是一种持续性的活动，作用于IT项目的整个生命周期。IT项目风险管理是对IT项目全生命周期中遇到的或者可能遇到的各种风险进行识别、分析、控制和监控的过程。FMEA是一种持续性的动态分析活动，可以对IT项目全生命周期中的各种风险进行管理，通过不断地更新风险管理的评估准则，并采取措施，从而降低项目的各种风险。
(2)对潜在的可能会出现的风险进行事前预防性分析，这种事前预防的机制降低了各种风险发生的概率。IT项目的高复杂性和自身的特点决定了IT项目必然会产生很多不确定的因素，从而带来很多的风险。FMEA分析依靠大家的智慧和经验，集思广益，对各种因素进行分析和筛选，识别出可能会导致风险发生的风险因素，在风险还未发生之前，就采取预防和控制措施，从而降低风险和减少损失。所以，FMEA分析注重的是“事前预防”，而不是“事后补救”。
(3)FMEA对IT项目风险管理的过程进行了改善和优化。风险计划、风险识别、风险分析、风险应对和风险跟踪是IT项目风险管理的五个过程。FMEA强调风险管理过程的连续性和持续性，可以合理地把这五个环节衔接在一起。这五个过程相互作用和相互衔接，循环往复运动，正是FMEA分析一轮又一轮持续不断动态进行的真实写照。上述五个环节之间的关系如图3．1所示。
图3．1 IT项目风险管理的过程
(4)由于IT项目需求多变，任务边界模糊，人的因素很大，导致IT项目中的风险大多是一种隐性的风险，无法通过相关指标体现出对项目的影响。风险度(RPN)是风险的严重度、风险发生的频度和风险的可探测度这三项指标的乘积。FMEA分析通过对风险度(RPN)进行计算，从而对IT项目的风险进行了量化，并提供了评定风险等级的标准。根据风险度(RPN)数值的大小，对所有风险进行降序排序，就能够确定风险应对的优先顺序，为合理应对项目的风险提供依据，从而引导有限的资源优先去应对排名较高的关键问题。
(5)FMEA有一个很大的特点就是全程文档化，实施FMEA的每一步都要做好相应的书面记录，从而形成了一系列的文档。这些文档对IT项目风险管理的进度进行了记载和跟踪。FMEA分析表格中包含风险编号、风险描述、风险原因、风险后果、应该采取的措旆、采取措施前的RPN及排名和采取措施后的RPN及排名，并通过比对采取措施前后的RPN数值来判断风险是否已经得到有效控制。这种表格简便而直观地记录了风险在项目进行过程中的变化趋势，项目管理者可以由此掌握项目的整体风险状况。需要指出的是，当项目结束时，形成的文档不能丢弃，要进行分类装订和留存，因为这是一笔宝贵的技术财富，下一个项目可以参考和借鉴。FMEA的相关文档还记载了责任人和日期，为明确责任和绩效考核提供了一些途径。
3．2 过程FMEA的工作原理
过程FMEA，即PFMEA，是一种用于对产品制造过程进行潜在失效模式识别、分析和排列的方法，它可以描述为一组系统化的活动，其要点是：
a)探究和识别某个过程中的失效模式，并确定每个失效模式的严重度、发生的频度和可探测程度，进而计算出风险度并排序，就可以确定需要优先进行改善的失效模式。
b)对于重点关注的失效模式，探究和确认能够消除或降低其发生频率的措施，并不断进行改善和追踪。
c)对于重点关注的失效模式，采取预防和改善措施后，要重新计算风险度，并比对采取措施前后的风险度数值，关注失效模式的风险降低到何种程度，并进行持续关注。
d)是一个持续的动态的过程，全部过程要求有记录，形成文档。
PFMEA对过程中的潜在失效模式加以识别、分析、评估和排序，可以将有限的资源集中在高风险度的失效模式上，并通过降低失效模式发生的频度和严重度来降低风险，其工作原理框图如图3．2。
图3.2 过程FMEA的工作原理框图
3．3 使用FMEA对IT项目进行风险管理的步骤
在项目风险管理的过程中，对各种可能的风险进行识别后，还要对每个风险进行评价，这一步是很重要的，只有准确地对各个风险进行了评价，才可以分清风险的重要程度并确定需要预防和改善的优先级，才能够提出并采取相应的应对措施。在对IT项目的风险评价方法进行分析时，可以参考过程FMEA的失效模式评价与决策方法。本文采用风险优先数法对IT项目中的风险进行分析和评价。笔者根据IT项目的特点和FMEA分析的基本要素，按照软件经典生命周期模型，并结合自身的项目和管理经验，设计出一套适合IT项目进行风险管理的FMEA工作流程，如图3．3所示。
图3．3 IT项目FMEA工作流程图
3．3．1 项目启动
项目启动预示着一个项目的正式开始。IT项目的启动包括项目立项、拟定项目章程、任命项目经理和组建项目团队。此过程通常需要制定初步的项目范围说明书、项目管理计划、成本计划、进度计划和质量计划等。
3．3．2 组建FMEA管理团队
通常由项目经理担任‘FMEA管理团队的领导者，召集相关部门的人员，邀请本公司和外公司的专家，组成跨公司和跨部门的FMEA管理团队。需要指出的是，FMEA管理团队的人员构成不是一成不变的，是动态的，可以根据需要随时进行人员的调整，这也和FMEA分析是一个动态的过程相吻合。FMEA团队的组织结构如图3．4所示。
图3．4 FMEA团队的组织结构
3．3．3项目分阶段展开
瀑布模型是一个经典的软件生命周期模型，如图3．5所示。
图3.5 IT项目瀑布模型
按照此模型可以将IT项目分为计划、需求分析、设计(概要设计、详细设计)、编码、测试和运行维护等几个阶段。
3．3．4 项目分阶段WBS分解
WBS中文译为工作分解结构，是制定成本计划、资源需求、进度计划、风险管理计划和采购计划等的基础。WBS分解的越清晰透彻，说明项目组对整个项目的范围和细节把握的越好。由于IT项目最终需要提交的是软件产品，所以IT项目的WBS分解应该是结合了软件生命周期模型的产品分解结构，并且包含管理域和支持域的内容。按照软件生命周期模型对IT项目进行分阶段展开后，要对每个阶段进行详细的WBS分解，这是项目管理的基础，也是进行FMEA分析的重要一环。
3．3．5 列举各工作包的失效模式
FMEA分析即“失效模式和影响分析”，是对故障种类及其影响的分析和改善，列举故障模式便成了最重要的一个步骤。可从以下几个角度着手去列举故障模式。
3．3．5．1 理解目标产品
理解目标产品的目的是从消费者、使用者的观点来观察产品，观察以下方面：
(1)产品规格、使用环境和使用条件。
(2)产品功能、性能、构造等。
(3)产品安全性、经济性要求。
(4)产品操作和运行维护要求。
3．3．5．2 收集故障模式
收集故障模式是从各种渠道收集、整理相关产品已有和预计的故障种类。方式如下：
(1)组织专人有针对性地收集目标产品以往的故障种类和模式。
(2)使用头脑风暴法列举已有的和可能的故障种类和模式。
(3)对其它公司的同类产品存在的失效模式及种类进行调查和分析。
(4)参考业界通常可能的故障模式、列举目标产品的故障模式。
(5)调查和探究失效模式的发生原理来预测可能的失效。
3．3．5．3 FMEA故障分析体制的建立
FMEA分析是一项较为复杂的系统过程，靠一个人单打独斗不可能取得理想成果，需要进行团队协作。在列举失效模式时，这一点尤为重要。在对一个系统进行FMEA分析时，可以把一个系统分为几个子系统，每个子系统划为一组，组织专人针对该组实旌FMEA。小组成员要来自设计、开发、测试、系统集成、市场和运维等部门。从不同的角度列举失效模式，往往会得到较为全面的结果。小组中要包含对目标产品和子系统的功能、原理和技术十分熟悉的人员。
列举故障模式和潜在风险时可以采取团队集体会议的形式，大家在会议上进行广泛讨论，集思广益，由专人负责记录和整理发现的潜在风险。最后由项目经理负责将识别的结果书面化，作为后续风险分析、应对和监控的依据。
3．3．6 失效模式严重度分析
根据多年的项目经验，笔者认为IT项目的失效模式严重度可以从以下三个方面进行分析：
(1)功能性方面。指某个失效模式对产品功能和性能方面所造成的影响。
(2)经济性方面。指失效损失的大小或者对整体进度和成本造成的影响。
(3)修复性方面。指失效发生后，对失效造成的后果进行修复的难易程度。
在进行失效模式严重度的分析时，对每一个潜在的失效模式，要对这三个方面进行分析。对于被找出的每个失效模式，要问以下问题：假如这个失效模式发生，危害的严重度有多高。
为了可以直观有效地表示失效模式的危害程度，可以采取量化评分的方式，制定失效模式严重度量化评分表。10分可以设为灾难级，1分设为无影响，1分和lO分之间设置阶梯分数。此表的制定要广泛进行协商，征求专家意见，最终必须要达成一致。
对失效模式的严重度进行分析，可以采取以下步骤：
a根据失效模式严重度量化评分表对每个方面进行评分。用F1、F2和F3分别表示这三个方面的评分。
b根据这三个方面的重要性进行加权系数的分配。笔者所在的项目组确定加权系数分别为7、5和6，分别用C1、C2和C3表示。
c这三方面的加权系数乘以各自的风险严重度评分，再求和，就得到了该失效模式严重度的数值。通常用S表示失效模式的严重度，得到S的计算公式：S=C1XFl+C2×F2+C3×F3。失效模式严重度量化评分表将在后面详述。
3．3．7 失效模式发生度分析
此过程是分析每个失效模式发生的原因并评估其发生频率(Likelihood of Occurrence)。对于被找出的每个失效模式，要问以下问题：这个失效模式发生的可能性有多高?
由于IT项目的故障模式发生的频率难以精确计量，故采取量化评分来进行分析，制定失效模式发生度量化评分表，分为lO个级别，分别对应1分到10分。在评分时，按照每个级别的对应描述进行打分，分值为1到10之间的一个分数，1可以表示几乎不可能发生，10可以表示必定会发生。此量化评分表的制定要广泛进行协商，征求专家意见，最终必须要达成一致。根据此表对每个失效模式进行评分就得到了失效模式发生度数值，通常用O表示。失效模式发生度量化评分表将在后面详述。
3．3．8 失效模式可探测度分析
此过程是确定失效模式在目前的控制方法下被探测出来的难易程度。对于每个失效模式，要问以下问题：假如这个失效模式发生，被探测出来的难易程度如何?
采用量化评分来进行分析，制定失效模式可探测度量化评分表，分为10个级别，分别对应1分到10分。在评分时，按照每个级别的对应描述进行打分，分值为1到10之问的一个分数，1可以表示几乎必然会被探测到，10可以表示几乎不能被探测到。此量化评分表的制定要广泛进行协商，征求专家意见，最终必须要达成一致。对每个失效模式进行评分就得到了失效模式可探测度的数值，一般用D表示。可探测度的分析应该越早进行越好，进行的越早，越容易预先采取预防和应对措施，从而降低损失。失效模式发生度量化评分表将在后面详述。
3．3．9 风险度(RPN)的计算
风险度用RPN来表示，此过程是计算每个失效模式的风险度。风险度是失效模式的严重度、失效模式的发生度和失效模式的可探测度这三项的乘积，即RPN=S×0×D。风险度RPN的数值越高，表明该失效模式的风险越大，应该及时采取预防和改善措施。
需要指出的是，在实际中，有时会计算某个过程的风险度，只要先把该过程包括的所有失效模式的风险度计算出来，再进行求和即可。
3．3．10 预防和改进
在对所有潜在的失效模式进行计算后，就可以根据计算结果对一些失效模式进行预防和改进。对于具有很高风险度数值的失效模式，要引起足够的重视，因为这些失效模式可能是整个过程中最需要进行预防和改善的。对于那些风险度数值很低的失效模式可以暂时不采取预防和改善措施，但要进行记录和监控，情况有变可以及时采取行动。为了筛选出符合这两种情况的失效模式，就需要对所有的失效模式的风险度进行排序。
在对所有失效模式的风险度进行计算后，按照数值大小对风险度进行降序排列，得到风险度排序表，可以对前20名或排名前20％的失效模式进行特别关注。根据柏拉图原则，一般而言，占排序前20％部分所导致的风险度占总风险度数值的80％以上，需针对该20％的关键少数进行预防和改进，这样投入资源较少，但是效果非常明显。项目团队应该优先考虑改善这些失效模式，以便使有限的项目资源发挥到最重要的地方。
对前20名或排名前20％的失效模式进行关注只是一般情况下采取的范围和比例，可以根据实际情况进行调整。需要特别指出的是，对于严重度非常大的失效模式，不管其风险度数值的大小，都应该进行预防和改善。
3．3．11 后续追踪
在对前20％的关键少数失效模式进行改进和预防措施后，要进行后续追踪，重新评估失效模式的严重度、失效模式的发生度和失效模式的可探测度，重新计算改进后的风险度(RPN)，以衡量改进和预防措施的有效性，并形成文档。这反映了FMEA分析是一个连续的，动态的和有记录可查的过程。
3．4 IT项目FMEA评分标准的设计
3．4．1 失效模式严重度量化评分表的设计
对失效模式严重度的量化评分，分为三个部分，分别为功能性严重度量化评分、经济性严重度量化评分和修复性严重度量化评分，下面分别进行设计。
3．4．1．1 功能性严重度量化评分表的设计
由于IT项目大都是软件产品，功能的实现好坏标志着项目的成败，因此在对严重度进行评分时，给予的加权系数为7。对失效模式功能性严重度量化评分的设计如表3．1所示。
3．4．1．2 经济性严重度量化评分表的设计
经济性严重度指故障损失的大小或者对项目整体进度和成本增加所造成的影响。本部分就是人们通常认为的故障严重度，在本文的分析中，把此部分的权重设为5。
对失效模式经济性严重度量化评分的设计如表3．2所示。
3．4．1．3 修复性严重度量化评分表的设计
在IT项目的全生命周期中，对故障模式的功能性和经济性进行严重度的评估还不够。有的故障模式虽然很重要，关乎核心功能，但是极易修复和复原，而其它的故障模式功能性和经济性次之，但是修复难度极高。因此需要引入修复性严重度，即故障发生后，对故障所造成的后果进行修复的难易程度。在本文的分析中，把此部分的权重设为6。
对失效模式修复性严重度量化评分的设计如表3．3所示。
3．4．2 失效模式发生度量化评分表的设计
失效模式发生度量化评分表的设计如表3．4所示。
3．4．3 失效模式可探测度量化评分表的设计
失效模式可探测度量化评分表的设计如表3．5所示。
3．5 IT项目FMEA分析标准表格的设计
3．5．1 IT项目FMEA分析标准表格的设计
根据前面提到的FMEA分析的步骤，对IT项目FMEA分析标准表格进行了设计，如表3．6所示。
表3．6IT项目FMEA分析标准表格
3．5．2 IT项目FMEA分析标准表格的元素
(1)表头。填写表格编号、日期、项目名称、所属阶段、责任人和审核机构。
(2)失效模式。填写此功能点或者任务可能出现的失效模式。
(3)严重度。专家组填写根据失效模式严重度量化评分表得出的对此失效模式严重度的评分。
(4)发生度。专家组填写根据失效模式发生度量化评分表得出的对此失效模式发生度的评分。
(5)探测度。专家组填写根据失效模式探测度量化评分表得出的对此失效模式探测度的评分。
(6)RPN。填写RPN即风险度，是严重度、发生度和探测度这三者的乘积。
(7)排序。填写某种失效模式在此表格中的风险度降序排名的名次。
(8)建议措施。填写专家组对此失效模式所建议的措施。
(9)完成日期。填写项目组对此失效模式采取措施约定的完成日期。
(10)措施。填写对此失效模式所采取的措施。
(11)采取措施后的严重度。相关责任人采取措施后，专家组根据失效模式严重度量化评分表，对此失效模式的严重度重新进行评分。将评分填于此处。
(12)采取措施后的发生度。相关责任人采取措施后，专家组根据失效模式发生度量化评分表，对此失效模式的发生度重新进行评分。将评分填于此处。
(13)采取措施后的探测度。相关责任人采取措施后，专家组根据失效模式探测度量化评分表，对此失效模式的探测度重新进行评分。将评分填于此处。
(14)RPN。填写相关责任人采取措施后的RPN，即采取措施后的严重度、发生度和探测度这三者的乘积。
(15)采取措施后的排序。采取措施后，某种失效模式在此表格中的风险度降序排名的名次填于此处。
3．6 IT项目FMEA分析结果对策的制定
由于项目的各种资源都有限，出于经济性的考虑，不可能对所有的失效模式都采取对策。进行IT项目FMEA分析的目的是针对风险度㈣降序排名很高的关键少数，采取相应的对策来消除故障现象及故障原因。FMEA团队需要按照风险度的顺序来进行分析改善，提交改善对策。
3．6．1 失效模式对策评分筛选表的设计
提出备选的对策，可以采用头脑风暴法，将能够想到的对策列举出来并记录在案，然后根据所提对策的可行性、时间支出、成本支出和效果等四个方面进行综合筛查，选出最佳的对策。对这四个方面进行筛查也是采用评分法，分为三个等级，优、中和差，分值依次是9分、6分和3分，对策的总得分是这四方面分值的乘积，分值越高，优先级就越靠前。可以采用表3．7进行对策的筛选。
现举例如下：某个故障模式，有A、B、c、D和E五个对策，填写失效模式对策评分表如表3．8所示：
从上表可知，对策A的分值远远高于其他几个对策，故应该优先选择对策A对故障模式进行改善。需要指出的是，对策的确认要具体到部门和人，并列明确认时间，否则易落空。
3．6．2 失效模式对策范围的确定
通常情况下，使用FMEA进行分析所确定的失效模式和失效原因有很多，究竟要对多大范围的失效模式采取措施呢?一般应针对风险度排在前10％．30％的失效模式采取对策。笔者所在的项目组针对风险度排在前30％的失效模式采取对策。
3．6．3 对策制订时的注意点
(1)在产品或项目的早期阶段，应尽早将FMEA分析的结果通报相关部门，以便及时对设计问题采取措施以减小损失。对于那些存在严重失效模式的子系统和需要改变设计的子系统，应立即采取行动进行应对。
(2)对于存在重大潜在失效模式的子系统或系统，要从设计方面予以对策，可采用冗余设计、简化设计或改变构成件等方法，确保故障及其原因的消除。
(3)在制订对策时需提供相关的文件或资料信息，以备检查或验证之用。
(4)对于某些重要的失效原因，须考虑提出检测方法。
(5)对于可能引起事故、产品安全或与法律法规不符合的潜在失效模式，即使其致命度不高，也应考虑改善应对。
产品视频
下载产品资料 
服务与支持 
