前言为帮助大家系统构建可靠性工程的知识体系我们启动系列了专题文章。首期以杨广斌博士《产品生命周期可靠性工程》为主线详解全流程可靠性框架。后续将深入FMEA、寿命数据分析、加速试验、FTA、DOE等核心专题。敬请关注。为什么你的项目总是延期我见过太多这样的项目• 设计师画完了制造说做不出来• 制造搞定了安装说接口对不上• 测试通过了客户端说这根本不是我想要的东西一代代工程师在这个循环里耗尽青春。这些现象的背后是一个共同的根因串行开发。杨博士在书中说每个阶段完成后才开始下一个阶段而每个后续阶段对变更的灵活性都更小。翻译生命周期越往后能改的地方越少要花的钱越多。01串行开发代价最贵的玩法传统的瀑布式开发是一个阶段做完再做下一个。设计完了再做工艺工艺完了再做测试。这种模式的成本规律值得单独说一遍每往后一个阶段典型情况下修改一个设计问题的成本可达前一个阶段的10倍。为什么因为每个阶段沉淀下去的东西不一样。设计阶段的改动成本是改的是图纸制造阶段的改动成本是工艺文件加设备到了客户端再改成本是召回成本加赔偿。更麻烦的是前一阶段的问题会往后积累放大。设计阶段一个没说清楚的细节到了制造阶段可能变成一堆返工单。所以串行开发有个外号叫救火模式——永远在填上一个阶段挖的坑。02并行开发把人相关方从一开始就拉进来解决串行开发问题的方法杨博士在书里叫并行工程Concurrent Engineering。原文定义 并行工程是一种系统性方法将产品的设计和制造、以及售后服务支持整合在一起。它要求产品开发过程中所有参与方从一开始就考虑所有生命周期要素。换言之不是等设计画完了再叫制造来挑刺而是设计阶段就把相关部门都拉进来。这样做有两个直接好处1. 第一次就把事情做对的概率大大提高2. 缩短上市时间这是写在书里的。现实中能不能做到是另一个问题后面会说到。03可靠性嵌入的三个关键节点并行开发不是让可靠性工程师打酱油而是让他们在三个关键节点真正发挥作用。节点1产品规划阶段规划阶段做的可靠性规划决策影响整个产品生命周期。你有没有见过好多企业在这个阶段犯懒——可靠性要求那一栏写的是满足客户需求。这六个字等于没写。真正的规划阶段可靠性工程师应该做这几件事•设定具体可靠性目标不是满足客户而是B10寿命达到X小时或15万公里无大修•把客户期望翻译成工程指标•从可靠性角度评估备选方案可靠性必须在设计阶段就嵌入产品Design-In而不是靠测试测出来Test-Out。这句话直接挑战了很多企业的惯常做法——可靠性工作就是买设备、做试验、发报告。节点2设计与开发阶段这是可靠性工程师的主战场也是代价最贵的阶段。杨博士在书中给了一组数字设计阶段消耗的总产品开发时间只有5%但70%到80%的全寿命周期成本LCC在这个阶段已经被决定了。注意这两个数字的对比5%的开发时间决定了70%到80%的后续成本。这就是为什么设计阶段的一个错误决策后面要用数倍到数十倍的成本来弥补。在这个阶段可靠性工程师的核心任务是把可靠性设计进去——杨博士的原文用了Design-In与之对应的是Test-Out•Design-In在设计层面用分析手段提前找到潜在的失效模式在图纸完成之前就消灭它•Test-Out先把产品做出来再用测试去撞看看哪里会坏前者的成本是分析的时间后者的成本是材料、设备和返工。可靠性分配、FMEA、容差分析、稳健设计、故障树分析FTA——这些工具都属于design-in的手段后续篇目会逐一展开。借助FMEA软件这类工具可以把这个过程系统化管理。节点3验证与确认阶段测试是验证手段是最后的守门员不是救场手段。验证阶段的核心任务是证明设计达到了最初定的可靠性目标而不是让产品通过测试。测出来了没达标怎么办如果产品未能通过验证测试改的是产品设计不是测试条件。这件事说起来简单实际上是很多企业跨不过去的一道坎——改设计意味着追加成本和影响进度而调整测试条件只需要内部开一次会。04串行 vs 并行一张表说清楚05为什么大多数企业做不到说了这么多并行开发的好处现实里为什么大多数企业还是在用串行模式原因就一个组织结构不支持。串行开发的底层是职能型组织——设计部门、制造部门、质量部门每个部门只对自己那一段负责上下游靠文件移交。要实现并行开发需要的不是再买一套工具而是把组织形态改掉——把相关职能的人拉到同一个团队给他们共同的目标。这件事的难点不是技术是组织里的利益结构。并行开发意味着职能部门的边界要被打破而职能部门往往不愿意主动放弃自己的控制权。说到底这需要最高管理层的推动不是可靠性工程师能单独解决的问题。06可靠性工程师的角色杨博士有一句话我建议所有可靠性工程师给自己的领导看一遍 可靠性工程团队是工程团队的有机组成部分不是在外部审核和批准他人工作的旁观者。怎么理解这句话大家是不是也见过一些企业的可靠性部门是这样的设计方案评审的时候可靠性工程师被叫来PPT翻完问有没有问题可靠性工程师抬头看一眼说没问题然后在签字栏上盖章走人。这不是可靠性工程师这是盖章机器。真正的可靠性团队应该•从第一天就参与项目了解产品在做什么•在设计评审中说话有分量不只是提建议•能够在过程中推动设计优化不只是最后的挑刺核心问题是可靠性工程师在组织里有没有话语权可靠性工程师必须从项目一开始就参与进来而不是被叫来审查或批准。我见过太多企业回答不了这个问题。07一句话总结可靠性工作做得越早成本越低做得越晚代价越大。并行开发的核心就是这一句。 至于能不能做到取决于组织愿不愿意让正确的人在正确的时间介入——而这件事最终还是需要最高管理层拍板。08下期预告讲了这么多流程有些读者可能想问我到底应该怎么做别急下一篇我们回到最基本的概念可靠性到底怎么定义可靠性三要素——功能、时间、条件大家应该都有所耳闻吧可靠性就是在规定条件下、规定时间内、完成规定功能的能力。把这三个词说清楚后续的任务剖面分析、环境试验、寿命数据分析、FMEA可靠性指标及目标确定等都好理解。