可靠性流程建设辅导方案

在产品的设计开发过程中，产品的可靠性活动也是贯穿于产品的全生命周期，在每个阶段都包含一系列的可靠性活动。

一、在概念阶段的活动包括：可靠性需求收集、筛选、分析、评审、确定，可靠性需求会随着开发阶段的行进而可能持续迭代的；

二、在计划阶段的活动包括：可靠性目标及计划设定，可靠性任务的细分到各系统、各专业方向、各职能，计划和细分任务要得到各方向的评审和确认，以保证可靠性任务都被领取；

三、在开发阶段的活动包括：可靠性设计和验证，主要是按计划和细分活动的执行和设计实现，以及可靠性预计，可靠性的子系统级和系统级的测试验证，可靠性故障解决及回归，也包含生产工艺采购售后等职能的可靠性评估和验收；

四、在确认阶段的活动包括：可靠性确认和保证，以及各职能对可靠性需求的正式验收；

五、上市和生命周期活动包括：上市后的可靠性数据的跟踪和管理，上市后可靠性质量回溯。

进入2024年，在与企业的交流过程中，发觉有关可靠性流程体系建设方面的需求忽然间一下子多起来，让人应接不暇，甚至有点拦都拦不住的感觉。有的企业甚至明明在一些可靠性基础工作不具备的情况下，也要强推可靠性流程体系落地。

  首先这当然是件好事，说明大家对可靠性流程体系的重要性认识越来越深刻了，但另外一方面，我们也要看到可靠性流程体系建设的复杂性。

在一家企业里，可靠性工作的开展基本遵循“点线面”的一个程序（如下图所示）。所谓“点”，就是零散的开展一些可靠性工作，比如在某个产品/项目上做了个FMEA，或者搞了个可靠性强化试验，总体上缺乏流程化和体系化。而“线”指的是我们的研发流程，从需求、设计、测试、生产到投入使用这一个端到端的流程，其中可靠性部分则是把前面说的各个“点”按阶段纳入到这条线里，形成了我们所谓的可靠性流程；“面”则是指为支撑企业可靠性有效开展而需要在技术和管理层面构筑的整体能力。

  从点到线是一个质的飞跃，也是可靠性是否做好的标志性里程碑，因为它表示可靠性的各个“点”的工作真正落入研发流程了，真正与产品相结合了。也只有这样，可靠性工作才算真正落地，也才能真正取得应有的效果。

  而从线到面则是一个自然而然的过程。因为有了流程，自然需要一个相应的体系去支撑它的运转。

  虽然实现从点到线的飞跃如此重要，但它的过程却并不简单，需要我们首先把“点”做好，即打好基础。否则落到“线”里也是空的，落不了地。

  我们就拿流程最前端的“需求”来说，落入流程的可靠性需求要求必须是“可实现、可验证”的，否则就无法落地。我们提出一个可靠性需求，无论是定性的还是定量的（最好是可以量化的），首先要确保我们的开发人员能够实现它，即“知道怎么去做”，这就是所谓的“可实现”。而做到这一点其实并不容易，首先需要把我们的需求搞好，每一条可靠性需求都必须能够细化到特性、规格，否则就必须对这条需求进一步的分解。而从设计层面，需要有大量的CBB支撑，否则开发人员不知道怎么实现，也是白搭。而如果要做到“可验证”，又要求我们的测试能力能够支撑，包括我们的测试方法、测试工具等等。所有的可靠性需求如果不能在研发阶段完成测试，就只能留待市场上去验证了，那么出问题也是必然的。

所以，仅从一个需求的角度，就带动了我们整个研发和测试体系能力的提升。我们其他的可靠性活动道理也是一样的，一张FMEA表格的背后其实需要大量细致的工作支撑。我们分析的失效模式是否包含了产品实际现场出现的各种问题？对这些问题是否进行了充分的失效分析，是否明确了导致的原因？每一个可能的原因是否都对应有预防改进措施？每一条预防改进措施是否都有明确的设计、测试方案，这些方案是否都已经明确到具体的责任人？等等。

总之，其实还是我经常说的，更多时候我们可以把可靠性看作一个杠杆，通过它可以带动整个研发体系能力的提升。我们提了一个可靠性需求，通过FMEA分析出一个可能的隐患点，或者通过试验发现一个薄弱环节。。。就要求我们有相应的设计改进方案，同时要有测试验证手段，如果不具备，就需要我们去通过技术合作等方式把这块的能力补齐，我们的研发能力自然也就提升了，当然产品的可靠性自然也就提高了。