镇江市丹徒区建设局网站,网站中用特殊字体,wordpress修改自定义尺寸logo,无锡网站优化哪家好失效模式和影响分析#xff08;FMEA#xff09;是一个在开发阶段#xff0c;用于确定产品或流程可能的风险和失败点的有条理的过程。FMEA团队会研究失效模式#xff0c;也就是产品或流程中可能出错的地方#xff0c;以及这些失效可能带来的影响#xff08;如风险、损害、…失效模式和影响分析FMEA是一个在开发阶段用于确定产品或流程可能的风险和失败点的有条理的过程。FMEA团队会研究失效模式也就是产品或流程中可能出错的地方以及这些失效可能带来的影响如风险、损害、浪费或缺陷目的是在产品发布之前减少或消除这些可能的失败。
产品开发团队需要平衡许多相互竞争的利益。市场竞争、客户需求和利益相关者的压力可能会促使团队急于将产品推向市场从而忽视一些重要的步骤。但是忽视这些步骤也会增加未来可能遇到的失败、产品召回甚至法律挑战的风险。那么开发团队如何设计和开发出能满足安全和监管指导方针、使客户满意、为公司赢得利润的产品呢
开发团队的流程中一个至关重要的部分就是失效模式和影响分析FMEA。然而为了能够充分利用FMEA团队不仅需要理解FMEA是什么他们还需要理解为什么FMEA很重要并且需要知道如何将其完全融入到产品开发过程中。
对于产品团队的失效模式和影响分析流程概述
FMEA并不仅仅是一次性的事件或者一个需要被勾选完成的预定流程。如果执行得当FMEA可以提升产品质量、降低成本并通过帮助开发团队在生命周期早期而非在产品验证、确认阶段甚至市场上线之后就识别潜在的失败从而确保符合安全准则。执行FMEA还有助于围绕产品捕获组织的知识并将这些信息保存供未来开发周期使用。最后收集新产品的数据不仅记录了可能出错的地方还记录了被拒绝的建议、采取的行动以及被采纳的解决方案。
可以将失效模式和影响分析视为一种高度结构化的头脑风暴。在FMEA的结构框架内鼓励团队成员考虑所有可能导致产品失败的因素并利用团队和组织的知识来找出可能的解决方案或行动以解决问题。正确的FMEA不仅仅是一个需要填写的模板它是一组旨在实现以下目标的系统性活动
识别和评估产品或流程的潜在失败评估失败的影响识别可能消除或减少潜在失败机会的行动记录流程并记录决策。
在这个概述中我们将回顾FMEA的历史和目的定义关键术语并为如何将FMEA作为开发过程的一部分提供指南。
什么是FMEA
FMEA失效模式和影响分析最初在1940年代被军方用于测试关键任务的安全性。从那时起FMEA已经在多个行业得到应用如汽车、医疗设备和航空航天等。作为一种减轻风险并满足ISO 14971、ISO 13485、IATF 16949和AS9100等国际标准的工具FMEA支持许多风险管理任务并有助于证明其合规性。
什么是失效模式
失效模式是指元素、组件、系统、功能或过程可能出现故障的方式。比如说自行车的手刹是通过转子和刹车片之间的摩擦来工作的。任何干扰这种摩擦的事件都可以被视为失效模式 — 例如大雨可能导致在使用刹车时摩擦力减小从而导致刹车失效。
一旦你知道了失效模式就可以确定其影响。影响是指故障可能对客户造成的伤害、浪费或缺陷。在上述自行车的例子中刹车失效可能会导致自行车的使用者严重受伤。FMEA的分析部分是在新产品发布之前识别、优先考虑并尝试减少或消除失效模式和其影响。
失效模式如何被发现的
失效模式是通过开发过程中的测试和头脑风暴时被发现的。
FMEA如何计算
什么是风险优先数RPN以及它如何在FMEA中使用
风险优先数RPN是一个数字它被赋予流程中的特定步骤以量化故障模式发生的可能性、故障未被检测出的可能性以及故障对人或设备造成伤害的严重性。RPN是这三个因素的乘积
1故障发生的可能性
2故障不被检测的可能性
3故障对人或设备造成伤害或损害的严重程度。
在FMEA中每个故障模式都会被分配一个RPN。FMEA的目标是尽可能地降低RPN。如果某个故障可能导致的影响非常严重那么在产品发布或重新发布前FMEA过程就会更加努力地通过纠正措施来降低这个风险。
FMEA还可以通过一个简单的计算方式来得出即故障的严重性乘以发生次数。
FMEA最常见的类型有哪些
FMEA最常见的类型有两种设计FMEA和过程FMEA。
设计FMEA
在设计FMEAdFMEA中产品团队会评估潜在的产品故障、产品寿命可能的减少以及安全和法规问题。团队会从各个方面来审查产品如材料属性、几何形状、公差、与其他组件或系统的接口、环境、用户画像、降解和系统交互等。
过程FMEA
过程FMEApFMEA主要寻找可能导致产品质量或可靠性降低从而引发客户不满的潜在失败。它还会关注可能由于人为因素、加工方法、材料、机器、测量系统和环境因素引发的安全问题。
FMEA的层次和范围
FMEA取决于上下文只有当团队了解过程或设计特性在整个系统中的位置才能进行适当的分析。
在最高级别产品作为一个整体就是一个系统。在该系统下有子系统。每个子系统有装配体和/或过程每个装配体或过程有组件和/或活动。 FMEA应该在每个层次和每个项目中进行。
在每个项目或层次中FMEA团队需要确定分析的边界或范围。明确的范围会回答以下问题
我们的焦点是设计还是调试产品在开发到发布的时间线上的位置是什么 这个FMEA覆盖了哪个项目和级别—系统、子系统、组件、过程等 引发这个FMEA的是什么—改变的法规产品重新设计新的环境 我们正在处理设计或过程的哪个方面可靠性、环境影响、可服务性等谁是客户客户的要求是什么
为什么要进行FMEA
对于许多公司和产品开发团队来说产品发布周围的最大担忧是一个重大失误导致用户受伤、负面新闻、召回、产品纠正、诉讼甚至更糟。但即使是较小的产品问题也可能侵蚀公司的声誉和底线。如果工程师和客服团队把他们的时间花在应对产品问题和解决客户投诉上他们就无法把时间花在设计新的功能和产品上推动公司的增长。 将FMEA程序作为产品开发过程的常规环节将风险评估移到开发周期的早期。它有助于确保在过程的早期就降低了风险从长远来看节省了时间、金钱并保护了声誉。在过程的早期进行FMEA让团队在还有可能控制风险、成本和声誉时对潜在的设计和过程失败进行深思熟虑。
控制成本的时间是在开发过程的早期即在成本产生之前。失效模式和效应分析帮助公司通过提供一种评估和分析潜在风险和失败的结构化方法准确地评估和规划成本。 我们应该什么时候进行FMEA
FMEA是一个主动的工具适用于以下任何情况
开发全新的设计、技术或过程 修改现有的设计或过程改变设计或过程的环境、位置、应用或使用情况或响应影响设计或过程的法规变更。
同时也需要记住FMEA是一个连续的过程而不是一次性的事件。事实上它在不同的时间为不同的目标实施时最有效。为了获得最好的结果尽可能多地汇集跨职能的人才。这并不是要求公司的每个人在每个阶段都参与而是要求聚集具有不同观点和见解的人他们可以一次专注于一个系统或子系统。
FMEA的过程是什么我们应该如何进行FMEA
虽然FMEA一开始可能看起来结构过于严密但实际上这种结构实际上是它的一大价值所在。在FMEA的结构中团队有能力提问、提供见解、头脑风暴解决方案同时为组织捕获知识提高产品性能和安全性。
但是虽然结构是FMEA的一大优点但对于对它不熟悉的团队来说可能会觉得有些困难。
以下是进行FMEA的有序方式
步骤1准备FMEA文件。通常这个步骤可以由熟悉被分析的设计或过程的人完成例如设计团队的一员。这里的诱惑是使这个文档过大或过于包罗万象。请记住它只应该包括一个系统或子系统甚至一个过程或属性。
步骤2邀请团队。这一步可以与第一步同时进行。产品团队的一员应该组建一个由开发团队内外四到六人组成的临时团队。你的跨功能团队可能包括来自采购、计划、财务、销售、营销和生产部门的人员当然还有客户或最终用户。
步骤3输入信息。当团队组建完成文档就位时就可以开始头脑风暴了。查看所有可能的失效模式。评估可能的原因、风险和失效模式的潜在效应然后在FMEA文档中相应地填写。
步骤4分配RPNs。计算和分配RPNs通常可以与信息输入同时进行但如果没有确保在优先考虑和头脑风暴解决方案之前进行分配。
步骤5优先考虑失效模式。RPN最高的失效模式是风险最高的失效模式应优先评估和审核。
步骤6与其他团队协调。当然最好是让许多FMEA团队同时审核系统、子系统和每个级别的其他项目。团队应该确保彼此之间的协调。如果一个团队的解决方案实际上导致了另一个团队的失效模式或者如果一个团队的效应可能意味着对另一个团队的系统的后果那么在开发周期尽可能早的时候发现这一点是非常重要的。
步骤7与需求管理以及合规性和法规指导进行整合。随着FMEA团队完成他们的分析并解决潜在的失效这些结果应该被整合到需求管理过程和相关的安全和合规指南中。使用如PingCode这样的需求管理工具团队能够直接将FMEA项目链接到潜在的失效来源以及缓解要求或验证。 是否有软件工具可以帮助产品团队简化 FMEA 流程
一些专业的需求管理工具可以将FMEA直接整合到设计过程中通过提供可定制的模板让团队能够协作、关联缓解措施、跟踪更改、审查和跟踪工作流程状态。
别让匆忙的开发周期使你面临差评、产品召回、诉讼或更糟糕的风险。通过将彻底的FMEA整合到你的开发过程中你将能够将更好的产品带入市场并确保安全和合规。
需求管理 需求管理指南
需求管理 需求管理主要内容 | 需求管理的重要性 | 采用敏捷方法进行需求管理 | 如何克服需求管理的 5 大挑战 | 更多
需求编写 功能需求的示例和模板 | 采用 EARS 方法来改进需求工程 | 如何编写一份优秀的产品需求文档PRD | 功能性需求与非功能性需求的区别 | 有效需求的特征 | 更多
需求收集和管理流程 需求工程概述 | 产品团队的需求分析指南 | 敏捷产品团队的 11 种需求收集技巧 | 定义和实施需求基线 | 更多 需求的可追溯性 什么是需求可追溯性 | 可追溯性在现代产品和系统开发中的关键作用 | 如何创建和使用需求追溯矩阵 | 更多
需求确认和验证 产品团队的需求验证和确认 | 更多
需求管理领域文章 做好需求分析的4大关键认知 | 盘点国内9款热门需求管理系统 | 构建产品路线图的方法与工具 | 做好需求优先级判断的7种主流模型 | 采用敏捷方法进行需求管理 | 更多
