可靠性不是验出来的，是供应链各方共同”设计”进去的。

---

一、问题的提出

在工业制造领域，客户与供应商在可靠性工作上的协作存在以下普遍现象：

客户方负责提出可靠性指标，但受限于自身技术判断能力，容易出现要求与实际脱节的情况；可靠性工作有时被处理为”符合性工作”——FMEA做了、报告交了、评审过了，但产品在实际使用中仍出现预期外的失效。

供应商方往往将可靠性工作视为合同要求的组成部分，重点放在满足交付条件上，对产品在实际使用中的长期表现关注不足。有能力的不一定拿到项目，拿到项目的未必把可靠性作为核心设计目标。

双方的目标取向存在差异——客户关注的是满足技术文件要求，供应商关注的是在合同约定范围内完成交付，“实现高可靠性”这一共同目标，在实际操作中容易被各自的具体诉求所稀释。

这不是态度问题，是制度设计问题。

---

二、第一关：准入机制是源头控制

2.1 现状：低价中标 资质门槛 ≠ 可靠性保障

当前的供应商准入，往往陷入两个误区：

误区	表现	后果
低价中标导向	报价最低者得，可靠性投入被压缩	供应商无动力投入可靠性工程
资质门槛替代能力评价	有ISO 9001证书就认为”具备可靠性能力”	证书≠能力，两张皮的根源之一

质量管理体系证书只说明”有流程”，不能说明”流程有效”，更不能说明”具备可靠性工程技术能力”。

2.2 用组织可靠性能力评估供应商

ISO 9001 只说明”有质量管理体系”，不能说明可靠性能力。业界公认、且已被纳入IEEE标准的参考框架是IEEE Std 1624-2008《Organizational Reliability Capability》——这是专门针对”组织可靠性能力评估”的标准，定义了评估供应商可靠性能力的标准化准则，可以据此对供应商进行分级评估。

IEEE 1624 的核心是”八项关键可靠性实践”和”五级能力等级”：

八项关键可靠性实践（评估维度）

序号	关键实践	核心内容
1	可靠性需求与策划	理解客户可靠性需求，制定可靠性程序计划，分配资源与责任
2	培训与发展	确保设计、制造、管理人员具备相应的可靠性知识与技能
3	可靠性分析	FMEA/FTA、应力分析、可靠性预计、单点故障识别
4	可靠性试验	发现设计弱点、验证可靠性指标的试验策划与执行
5	供应链管理	供应商准入评估、器件认证、变更通知跟踪、优选目录维护
6	失效数据跟踪与分析	FRACAS、现场失效采集、根因分析、Pareto分析
7	验证与确认	内部审核、预计值与现场值对比、供应商承诺核验
8	可靠性改进	基于失效分析实施纠正措施、预防复发、经验反馈

对供应商的评估，不是打一个总分，而是对八项实践分别评级，每项实践独立判定一个能力等级（1~5级）。

五级能力等级（IEEE 1624 Clause 6.1）

等级	名称	特征描述
1级	初始级	无一致的可靠性程序，靠个人能力，出问题后被动应对，产品可靠性水平不稳定
2级	可重复级	有基本的可靠性活动，能按组织标准或行业惯例重复成功，但可靠性数据利用不足，改进主要依赖重大现场问题
3级	已定义级	可靠性需求被正式定义，有文档化的可靠性程序，工程师接受可靠性培训，对试验和现场失效有响应，能基于反馈做部分设计改进
4级	量化管理级	可靠性计划针对具体产品定制，可靠性以分布而非点估计表达，设计随可靠性考虑而主动调整，供应链被纳入可靠性保障，失效机制和模式被系统记录并用于预防复发
5级	优化级	可靠性被纳入战略业务规划，产品全生命周期的可靠性反馈被广泛共享，主动评估技术/业务变化对可靠性的影响，可靠性被视为生命周期成本中的一个可优化属性

IEEE 1624 明确指出：等级是累积的——达到某一级，意味着该级及以下各级（未被更高级活动替代的）活动都已被执行。评估不是看”有没有文件”，而是看”文件有没有被执行、执行结果有没有被记录、记录有没有被用来改进设计”。

具体评估方式

针对八项关键实践，每项都依据IEEE 1624 Table 1中定义的活动清单进行核查。评估时应重点了解以下情况，而不是只看供应商交了什么文件：

可靠性活动是否早于设计启动

——关键失效模式在设计方案阶段还是设计完成后才被考虑？

可靠性分析的结果是否真正影响设计决策

——分析报告里的建议措施，有多少被采纳、有多少被忽略、忽略的理由是什么？

有没有真实的现场数据

——不是”我们没有失效”这种结论，而是失效记录本身，以及基于这些记录做过什么改进？

可靠性验证试验的条件是否贴近实际使用

——还是只是为了”通过试验”而设计试验条件？

出现问题后，供应商的第一反应是解释还是改进

——这往往比流程文件更能说明成熟度。

供应链管理是否有主动的器件认证和变更跟踪机制

——还是出了问题才追溯？

失效数据是否被系统记录并用于下一代产品设计

——还是只停留在”故障记录表”里？

可靠性改进是否有闭环机制

——纠正措施实施后，有没有跟踪其有效性？

评估的核心不是”有没有”，而是”是不是真的在用”。IEEE 1624 的价值在于提供了一套标准化的评估准则，使供应商可靠性能力评估从”凭印象”变为”凭证据”。

---

三、第二关：客户与供应商的界面必须厘清

3.1 当前界面的混乱状态

现实中的客户-供应商界面，往往呈现以下特征：

客户越位：深入干预供应商的具体设计方案，甚至指定器件选型，却不承担相应的技术责任

供应商缺位：对客户的可靠性要求回应不足，认为”做了FMEA就是做了可靠性”，对最终产品的现场表现缺乏责任感

责任模糊：产品出了问题，客户说”是你供应商的问题”，供应商说”是按你的要求设计的”，互相推诿

3.2 正确的界面划分原则

核心原则只有一句话：客户管”要什么”，供应商管”怎么做”。

责任维度	客户责任	供应商责任
可靠性指标定义	✅ 定义系统级MTB等可靠性指标	参与指标可行性评估
可靠性分配	✅ 将指标分配至各子系统/部件	确认分配指标的合理性
设计方案	审核关键设计决策	✅ 主导具体实现方案设计
器件选型	规定禁限用器件清单	✅ 在约束范围内自主选择
FMEA/FTA	审核报告完整性	✅ 主导分析过程，承担责任
可靠性预计	规定预计方法和数据源	✅ 执行预计，对结果负责
试验验证	✅ 规定试验条件、验收判据	✅ 执行试验，提供真实数据
数据包交付	✅ 规定交付物清单和格式	✅ 准备并交付完整数据包
现场失效	提供现场数据	✅ 分析根因，实施改进

3.3 “把技术权利交给供应商”的边界

业界有观点认为应当”把更多的技术权利交给供应商”，这个说法方向正确但容易误导，必须明确边界：

应该交给供应商的：实现路径的决策权、具体设计方案的主导权、器件选型的自主权（在禁限用清单范围内）、可靠性分析的执行权。

不应该交给供应商的：可靠性指标的制定权、验收试验条件的决定权、关键安全特性的设计变更权。

交给供应商的前提：供应商必须通过可靠性能力评估，进入合格供应商名录。对未经评估或评估不合格的供应商，技术权利的让渡是危险的。

---

四、第三关：用商务约束替代行政干预

4.1 为什么行政干预无效？

当前的客户-供应商关系中，客户推动供应商可靠性工作的主要方式是行政手段（开会、发函、现场审核、评审）。这种方式存在以下局限：

成本高：客户需要投入大量人力进行过程监督

效果差：供应商应付检查的能力远超客户的检查能力

责权不对等：客户干预了技术决策，但又无法对最终产品可靠性负责

4.2 可靠性指标高低与商务定价的关系

这是当前供应链管理中最被忽视、却最关键的一环：可靠性指标不是”技术要求”，而是”商务条件”——指标的高低直接决定成本，必须在定价中体现。

高可靠性指标意味着什么成本？

可靠性不是免费的。每提升一个数量级，背后是实实在在的投入：

可靠性提升手段	对应的成本增加
高等级器件替代商用器件	器件成本增加2~10倍
降额设计（功率/温度）	需要更大封装、更多散热，体积成本双增
冗余设计	器件数量倍增，成本近线性增长
加速寿命试验验证	试验设备、样本、时间的直接投入
更严格的工艺控制	良率损耗、工艺认证、人员培训
更全面的FMEA/FTA分析	人力投入，延长开发周期

现实中的常见情况：客户提出模糊的”高可靠性”要求，但采购定标时仍以最低价为主要依据——这两者在方向上并不一致。供应商面临的选择是：在报价中如实反映可靠性投入成本，或者以最低成本方案报价并在后续履约中寻求平衡。需要注意的是，如果只用MTBF一个指标来定义”高可靠”，会出大问题——不同产品的关键失效模式完全不同，单一指标无法覆盖。

建立”指标—报价”的双向迭代流程

当前最常见的做法是：客户在技术文件中写死可靠性指标，供应商据此报价，评标时只看总价。这导致两个问题：一是指标定得过高，供应商报天价，客户无法接受；二是指标定得模糊，供应商按最低成本报价，可靠性无从保障。

正确的流程应该是一个双向制衡的迭代过程：

技术协议谈判完成后，应形成书面技术协议，至少涵盖以下事项：

指标确认清单：每条可靠性指标，供应商明确确认”可接受”或”有条件接受（附具体条件）”

验证方法约定：每个指标如何验证，验收试验的条件、样本量、判据

变更控制：设计变更（特别是器件替代、工艺变更）的审批流程

目前在业界实践中，还有一项重要内容往往被忽略：供应商的风险交底义务——即供应商有义务主动披露客户技术文件中未提及、但根据供应商经验会影响产品可靠性的关键风险点（如某类器件的已知薄弱环节、某种工况下的早熟失效模式等）。这不应是供应商的自愿行为，而应作为技术协议谈判的固定议程。客户方如果缺乏足够的技术判断能力，这一条尤为重要——让供应商把”我知道但你不问”的问题主动说出来。

谈判完成后，技术协议与合同价格条款应同时签署、同时生效。没有签字的技术协议，合同价格条款不具备执行依据——这是把技术承诺与商务约束真正绑在一起的关键一步。

高可靠性指标应允许合理的成本溢价

对于关键设备，当客户提出的可靠性指标显著高于行业基准时，应在商务上承认其合理性：

允许供应商在报价中单独列示”可靠性工程投入”分项，使成本透明化

对关键设备实行”生命周期成本（LCC）评标”而非”最低价中标”

LCC评标考虑：采购成本 预计维护成本 停机损失，可靠性高的产品反而可能总成本最低

可靠性承诺应写入合同价格条款

合同中应明确：供应商对可靠性指标的承诺，是其报价的重要组成部分。如果供应商在投标时承诺的可靠性无法通过验证，客户有权：

要求供应商无偿整改至满足承诺

或接受降价（因为实际交付的产品可靠性等级低于投标承诺）

价格必须反映指标，指标必须匹配预算——这两者之间的缺口，应在合同签订前通过技术协议谈判解决，而不是留到合同履行阶段再处理。

这形成了对”虚假承诺”的约束——承诺过高而兑现不了，最终损害的是供应商自身的商业信誉。

---

五、指标不能用一个：建立多维度的可靠性评价体系

用MTBF一个指标来定义”可靠性等级”，是常见的、也是危险的做法。

问题在哪？

不同产品的关键失效模式完全不同：

产品类型	核心可靠性关注点	单看MTBF会出什么问题
连续运行设备（如服务器电源、生产线设备）	MTBF 可维修性	MTBF高但MTTR很长，实际可用性依然很差
含老化机理产品（如电池、密封结构）	老化退化 泄漏/失效概率	MTBF是恒定失效率模型，根本不适用
高精度设备（如测量仪器、医疗设备）	精度漂移 校准周期	不失效≠可用，精度超差同样是”故障”
户外/现场设备	环境适应性（温度/湿度/盐雾/振动）	实验室MTBF很高，现场几个月就腐蚀或振动失效

正确的做法：建立多指标组合的可靠性画像

针对具体产品，应从以下维度中选取适用指标，形成组合要求：

不同工作方式的产品，适用的可靠性指标完全不同，不能一概用MTBF：

连续运行产品：（如生产线设备、服务器、通信设备）：失效随时间累积，失效率相对稳定，适用MTBF / λ（失效率）

间歇运动/循环工作产品：（如工程机械、注塑机、电梯）：失效与循环次数强相关，与累计运行时间有关，与日历时间关系较弱，适用B10寿命（10%样品失效时的循环次数或运行小时数）

应急/备用产品：（如消防泵、应急照明、备用电源）：大部分时间处于待机状态，真正工作的时间很短但要求每次都能启动成功，适用可靠度R(t)（在规定时刻能否成功动作）或启动成功率

一次性使用产品：（如安全气囊、爆破件）：不存在”平均无故障时间”的概念，只关心”该动作时能不能动作”，适用任务成功概率

用MTBF来要求应急产品，是典型的指标错配——供应商可以轻松地用MTBF达标来应付，但应急产品真正的可靠性问题是”三年后第一次使用时能不能启动”，这和MTBF几乎无关。

除以上按工作方式区分的指标外，还有一个通用指标：

设计寿命：产品在规定条件下能完成规定功能的总期限，适用于所有产品类型，是最基础、也最容易被忽视的指标

有了上述多指标体系，才能对”可靠性等级”进行有意义的定义。

关键原则：

不同产品类型的指标组合完全不同，不能套用统一模板

等级定义应由客户与可靠性工程师共同制定，不能由采购部门单独决定

等级对应的验证要求应同时明确——高等级必须有对应的试验证据，不能只靠承诺

客户在提出采购要求时，应明确：本产品适用哪个等级、需要哪些指标、每个指标的目标值是多少、如何验证。要求A级却只批C级预算，是所有矛盾的根源。

---

六、上篇小结：合同签了，事情才刚开始

到这里，我们已经把供应商可靠性治理的前三道关梳理完了：准入有标准、界面有划分、指标与价格有对应、合同有依据。

但必须清醒地认识到：技术协议签了、合同价格定了，不等于可靠性工作就结束了。恰恰相反，合同生效，才是可靠性治理真正开始的时刻。

下篇我们将继续讨论后两道关：

如何通过商务约束机制，让供应商有持续的动力做好可靠性？

如何在过程管控中不越位、不错位？

如何让运行数据真正形成闭环，而不是停留在”故障记录表”里？

---

下篇预告：《供应商可靠性治理（下）：从合同履行到数据闭环》

转自公众号，可靠性不可靠