可靠性是一门有价值的学科，它应用了很多技术，我们可以用来解决问题并开发出可靠的产品。当然这一定存在一些指南和成功经验，但是我们必须要根据企业的实际情况来进行裁剪。其中我们需要关注的领域有企业的规模、企业文化、过去的经验、教育背景、市场和客户要求等。
即使这本书已经提供了众多不同的技术，但是千万不要认为我们需要采用所有的技术。在这本书的剩余部分所写可以成为指南或者提示。针对具体的项目，我们需要自己来判断哪些经验适用，哪些经验不适用。绝对不能够直接拷贝别人的可靠性大纲，即使是同一个行业的也不行，当然我们也不能够拷贝之前公司的可靠性大纲。他们可以是我们开始时非常有价值的参考，但是当我们试图直接拷贝一个可靠性大纲时只会给我们带来灾难，因为只有切合组织的文化，参与产品项目的人，这个可靠性大纲才会真正起作用。我曾经见过两家企业生产相同的产品，但是他们的可靠性大纲完全不同，但是这两家公司的可靠性大纲执行的都很好。
我们应该注意的比较重要的事情是不管我们起草了什么样的可靠性大纲，关键是在产品开发流程给定的时间内必须有一个可以测量的指标，而这个可靠性大纲应该保障产品能够获得理想的结果。
案例：
我曾经对一个军方的供应商开展过一次可靠性评估，作为评估的一部分我要求审核一下他们的可靠性大纲。这家客户对于他们的可靠性大纲非常自豪，这份资料足足有100页之多。我咨询他们的可靠性工程师这份可靠性大纲是如何编写出来的。他回答说他参考了一份非常着名的可靠性专着，把这本书的每一章都涵盖到可靠性大纲中去。为仔细查看了这份可靠性大纲并注意到他几乎一字不漏的完全拷贝了那本书。他认为越遵守这本书越能够获得成功。但是这不可能成为现实了。可靠性大纲必须要有一个很好的基础不错，一本可靠性专着可以和其它的资源一样有价值，但是我们必须根据实际情况进行裁剪，而这份可靠性大纲明显没有这么做。幸运的是他们的客户并没有那么愚蠢，最终拒绝了这份可靠性大纲。
随后我和这家客户基于之前的可靠性大纲进行修改来适应他们的实际情况。最终他们的客户接受的新的可靠性大纲。这家客户按照新的可靠性大纲最终开发了非常可靠性的产品。
2、什么是可靠性设计？
可靠性早已不是由一个团队来单独开展的活动。产品可靠性指标、风险和活动已经融入到组织的每个流程和功能当中去。高级管理团队的职责就是培训团队清晰的可靠性和质量意识。技术团队必须平衡项目成本、客户的产品维修保养成本、质量、项目周期、性能和可靠性（有些行业可能还有其它指标）来达到优化产品设计的目的。我们的组织构架必须做到鼓励每个成员来采用合适的可靠性方法和手段。嘉峪检测网认为，可靠性设计作为可靠性工程师的一个职责是来发现性价比高的零部件和风险低的结构设计并把它展示给团队中的其它成员。
当我1984年开始从事可靠性工作时，可靠性看上去接别人丢过来的东西，当设计工程师完成产品设计后就完全转给可靠性团队来负责。当可靠性团队拿到产品时几乎无法影响产品的设计，所以可靠性工作的重点就是评估产品的可靠性水平。如果产品没有满足可靠性指标要求，我们可以做什么呢？事实上还是销售给客户，然后花费多年时间来跟踪产品的性能并纠正那些可以改善的问题。当然，产品会随着时间的推移越来越好了。我曾经的那家公司通常是利用客户来建立一个反馈机制。最终结果就是客户不满意，公司在可靠性方面的信誉很差。很不幸的是这样的做法很常见。
在当今全球经济下，很多行业在比拼可靠性。我们终于意识到“丢过墙”的模式已经不行了。可靠性是设计出来的。没有什么比让设计工程师对他们产品设计的可靠性负责更好的方式了。这种模式现在执行的很好，当我开展可靠性设计演讲时，参加的人员大部分是设计工程师而不是可靠性工程师。可靠性工程师的职责转变为顾问。可靠性工程发现最合适的技术并给设计工程师培训如何使用。可靠性工程师还辅助撰写可靠性大纲，而设计工程师则负责执行可靠性大纲。
可靠性设计就是如何让设计工程师承担产品可靠性的职责。可靠性部门开始成为指导委员会，帮助制定规章制度，提供方向指导和培训。我把这比作划船比赛。可靠性工程师是船长（划船队的船长通常坐在船头面对船尾，指挥整个船队并协调大家的每个船员的力量和节奏）。设计工程师就是船员。当两者协同工作，整条船就能够在水面上更平稳省力的滑行。
谁应该参加可靠性设计的课程？
每次当我提供可靠性设计培训时，我的客户总是问谁应该参加。当然设计工程师必须参加。那么市场人员需要参加吗？当然，他们需要参加。我们必须让销售、客户服务、和工厂都应该有相应的代表参加。同事可靠性团队也需要参加。任何人与产品可靠性相关的都必须参加。然而，设计工程师是流程中的关键。他们日常中队产品设计所做的决定会极大的影响产品的可靠性。那么可靠性团队的职责又是什么呢？这个团队需要可靠性工作的领导者和培训者，同时还需要协助制定可靠性指标和撰写可靠性大纲。而日常的可靠性工作则由设计工程师来完成（在可靠性团队的指导下）。
案例：
一个通信企业被产品糟糕的可靠性水平所困扰。每次他们在产品测试或者工程发现问题时，测试工程师和工程的工程师都无法获得设计工程师的帮助来解决问题，因为设计工程师都在忙着开发新产品没有时间。你看，他们只关心多快可以把产品推向市场，但是产品是否可靠性不重要。这家企业做了一个很聪明的决定，首席执行官做了个决定，他告诉所有的设计工程师，从现在开发解决问题是他们的职责。你知道发生了什么吗？突然设计工程师开始愿意倾听可靠性团队的声音，于是一个可靠性设计的项目开始在企业内诞生。绝大多数设计工程师喜欢从事新产品设计工作，不喜欢对问题进行改善。不久他们开始从事新项目，他们也有了更好的认识。他们试图成功解决之前项目的问题，这时候他们才真正认同可靠性并为产品可靠性设计而做出努力。
3、只有把可靠性整合进产品开发才完整
整合可靠性就是把可靠性技术集成到产品开发流程中来提高产品可靠性水平并降低成本。这意味着我们必须把一些列的技术作为一个项目来考虑，而不只是一堆独立的活动。
如果我们要建造一个系统，而一些是有不同的零部件或者零组件组成，产品的组成包含了不同的领域（其中主要的有电子、机械、软件、固件、光学和化学等）。所有的这些独立的个体组成了一个系统，当然我们也不能够忽视它们之间的交互关系，并且需要保证我们从系统的角度来考虑可靠性项目。下图中我介绍了三种类型组成的系统，电子、机械和软件。
对于软件和硬件这尤其合理。绝大多数的公司把软件可靠性和硬件可靠性分离开来而不是当作一个整理看待。当失效发生时，这就会导致大家互相指责而不是合作。
对于电子和机械这两个领域也同样正确。相比于软件和硬件我们能够看到这两个领域较多的合作。但是在初始时，他们很少会在一起讨论常规的可靠性目标和如何计划对系统的关键部分进行分解。
产品开发团队只是在机械、电子和软件不同领域的独立的看待可靠性问题。但是客户只会从系统的交代看到可靠性问题，而他们只会把很小的关注放在机械、电子和软件问题上。客户希望产品的所有部件可以完美的工作在一起。由于可靠性的度量主要是客户来执行，工程团队必须在系统和子系统上取得平衡来开发可靠的产品。
可靠性与成本
可靠性的重点就是在最小增加开发和制造成本的条件下达成保修和服务成本的降低。在生命周期的特定阶段使用合适的技术会帮助我们来最小化全寿命周期成本。
为了最小化全寿命周期成本，单位必须做如下两件事情：
1、从可用的技术中选择最合适的技术并应用到产品寿命周期的合适的阶段
2、基于具体的信息把这些技术合理的集成到产品寿命周期的不同阶段
1、项目成本会随着可靠性的提高而增加。当到达某个点后，我们不会从可靠性的投资中获取回报，因为当可靠性达到某个点后就会变的很难再提高。这也是为什么我们需要知道目标在哪，这也就决定了我们公司生产的产品是太可靠了还是不太可靠。嘉峪检测网认为，当产品太可靠了，通常会带来成本的增加，而客户也许并不需要这么高可靠性的产品，他们会考虑更低价格的产品。我们上次购买200美元的搅拌机和烤面包机是什么时候？
2、当可靠性降低时，维保成本会增加。
3、软件和制造成本没有关系（也许光盘、说明书和产品生产功能测试成本除外），所以维保费用绝大多数时候分配给硬件。如果软件可靠性并不能够降低成本，为什么还要管它呢，硬度更多的关注硬件可靠性改善来降低成本。我们当然不能够这么做了，主要是以下两个原因：
A、根据我们的经验，典型系统的软件失效和硬件失效的比值为10:1。客户只会购买整个系统而不只是硬件。
B、软可靠性项目并不会直接产生成本降低。相反的，他们会对下面的领域有帮助：
提高软件和固件可用性会降低维修导致的停机
提高客户满意度
每次当我提供可靠性设计培训时，我的客户总是问谁应该参加。当然设计工程师必须参加。那么市场人员需要参加吗？当然，他们需要参加。我们必须让销售、客户服
务、和工厂都应该有相应的代表参加。同事可靠性团队也需要参加。任何人与产品可靠性相关的都必须参加。然而，设计工程师是流程中的关键。他们日常中队产品
设计所做的决定会极大的影响产品的可靠性。那么可靠性团队的职责又是什么呢？这个团队需要可靠性工作的领导者和培训者，同时还需要协助制定可靠性指标和撰
写可靠性大纲。而日常的可靠性工作则由设计工程师来完成（在可靠性团队的指导下）。
案例：把电子、机械和软件可靠性联系在一起
我曾经在一个半导体设备公司工作来帮助改善下一代产的可靠性。首先我为三个领域（电子、机械和软件）的团队提供了可靠性设计的培训。然后我们和电子、机械和软件团队的负责人讨论并制定可靠性目标。我们从系统的顶层指标开始并逐步分解到子系统（电子、机械和软件）。每个团队负责他们子系统的可靠性目标并继续分解到更小的单元。我和每个团队负责人一起制定可靠性大纲来保证他们的子系统可以满足既定指标。我们针对每个不同的子系统发布不同的大纲并最终整合到产品的可靠性大纲中去。我和每个团队负责人合作来确保他们在整个产品开发流程中持续跟踪子系统目标。最终每个子系统成功达成目标，从而保证整个产品达成目标。
4、平衡内部和外部资源
当我们计划一个可靠性项目时，我们必须决定是招聘全职人员来完成、寻求外部资源的协助，或者两者都是。大多数企业同时选择两者。他们让自己的员工负责日常工作，例如开会以及和设计团队共同协作，而当他们不具备相应的能力或者人力不足时则借助外部资源来执行相应的工作。下面是寻求外部资源协助的前十大理由（排名不分先后）供大家参考：
1、可靠性专家
2、可靠性评估
3、技术风险评估
4、特殊技能
5、为工程师提供培训
6、在起步阶段
7、企业裁员
8、引导
9、在特定地区提供帮助
10、专家建议
4.1可靠性专家
企业需要一个强力的可靠性专家来制定可靠性项目的方向，建立企业的指标并决定选择安排不同类型的人到不同的岗位来保证项目的成功。在第2章我们讨论了可靠性设计的专题，但是只有设计工程师觉得在可靠性专家的领导下才会真正起作用。如果企业缺少这样的可靠性领导者，那么就是时候来引入外部咨询专家来领导企业的团队并提供培训。如果企业已经有了自己的可靠性工程师，企业可以考虑让顾问来培训可靠性团队，后期指定可靠性团队的其中一个成员成为企业可靠性负责人来负责整个企业的可靠性工作。
4.2可靠性评估
当我们回顾过去发布的产品时会经常发现产品的可靠性水平需要提高。这并不是一个明确的问题，而是很多小的问题所累积而导致客户的不满。企业需要对可靠性进行更好的预计。如此一来外部机构可以帮助评估企业的薄弱环节。我们把这称为可靠性评估。
4.3技术风险评估
如果企业正在进入一个全新的市场或者采用全新的技术，则企业需要保证能够达到规定的可靠性水平。一个很好的例子是决定采用固态硬盘还是传统的机械硬盘。在技术背后所隐藏的可靠性代表着什么？固态硬盘会比传统硬盘更好还是更坏？企业需要一个专家来进行技术风险评估来评估企业所开发的产品可能的可靠性水平。
4.4特殊技能
如果客户要求指定的技术（或者内部决定采用指定的技术），但是企业并不知道如何做，这也是一个合适的理由来引入外部专家。当引入外部专家时采用试验设计技术是很好的一个选择。大多数公司很少开展试验设计，所以基本对试验设计不熟悉，相应的对于如何开展试验设计比较生疏。嘉峪检测网认为，外部专家可以提供手把手的培训课程通过专题研讨会来给大家做培训并进行实践。可靠性领域很宽，很少有人会涉猎所有的领域。即使很优秀的可靠性工程师出现有些问题超出他的能力范围也是很正常的，这时候可以考虑引入外部的专家来进行协助。
4.5为工程师提供培训
外部专家不仅可以为企业提供培训课程还可以为企业建立课程培训计划。培训计划应该能够弥补工程师的培训需求的缺口并帮助刚入职的员工快速进入状态。培训计划还必须包含培训培训讲师的环境，从而使得企业从现在就可以为未来的内部培训培养人才。
4.6在起步阶段
当一个企业发现自身需要在产品设计领域快速提高时又无法快速招聘或者不太确定需求是短期的还是长期的，这是最好的选择就是聘请外部专家来填补人力缺口。相比于员工招聘，聘请外部专家更加容易（通常我们可以在确定专家候选人后要求对方几天内到位，而他们在到位后可以立即开展工作）。同样如果与外部专家解约也非常简单（在加利福利亚解雇一个全职员工非常困难，法律风险很大，而和顾问解约的风险可以得到极大的降低）。
4.7企业裁员
在企业裁员后利用外部顾问可以更高效，而企业也需要持续开发新产品，工作必须有人去执行。由于不需要雇佣全职人员，外部顾问只是在需要的时候才会聘用，进而可以帮助企业降低总体人力成本
4.8引导
经常会出现一个人技术都具备但是对于团队的现场引导能力不足。一个很好的例子是失效模式影响分析。大部分工程师都熟悉基本的技术并能够指出产品可能存在的失效来决定如何解决潜在的失效。问题是每个工程师所掌握的技术有所差异，当我们把一个不同职能的工程师团队集中在一个房间就会变的很混乱。这时候我所需要的就是一个强力的领导者来指引大家通过流程来确保每个人的想法被倾听而不是由某个人来主导讨论。我们会在第17章讨论更多的内容。
4.9在特定地区提供帮助
当企业某个办事处或者供应商处偶尔需要某个专业技能，这时候聘请当地的顾问也许比派遣一个工程师飞过半个地区去更合理。
A. 聘请当地的顾问费用更低，不仅可以节省出差费用，而且经常会出现当地的办事处或者供应商区域的薪资水平更低，从而我们从费用更低的当地顾问获益。
B. 本地的顾问在语言和与当地客户的交流上更加流畅。某些可靠性顾问机构在全球都有办事处也许在特定区域拥有本地的专家团队。
4.10专家建议
如果客户需要一个专家提供其它观点，聘请一个顾问公司是一个高效的解决方法。在大多数时候，企业的工程师对于他们的方法、计划或者报告都不存在问题，他们只是需要一点点点拨。我就看到一个顾问提了和企业内部工程师同样的建议，但是只是因为他是顾问，而企业或者客户会更认可顾问说法。
可靠性整合：引入外部资源来帮助企业内部工程团队
有些企业对于如何外部不需要很多内部工程师资源来管理外部资源的特定活动依然有一定的顾虑。对于这个问题，非常重要的是在项目开始时就定义好合作内容（内部工程师和外部专家各自的工作内容和职责），如何进行审查，多长时间审查一次。如果这些做好了，那么外部资源会成为企业巨大的财富；如果没有做好，那么管理外部资源将成为企业巨大的累赘。
案例：可靠性专家审查服务
亚洲的咨询市场和美国的有很大区别。我从2006年开始在新加坡提供咨询服务，和美国一样没有聘请任何的顾问。亚洲的企业倾向于自己开展工作，通常只是在需要培训或者某种特殊技能时才聘请顾问。很少会因为人手不够而聘请顾问的情况。现在亚洲人力重组，缺少工程师很少发生。于是我针对亚洲市场创新了可靠性专家审查服务。企业的工程师执行，我来审查他们的工作，在需要的时候进行一些修正并最终为工程师的工作签字。这给予了企业以前所没有的某种程度上的信心，同时审查服务的费用也是他们可以承受的。
5、可靠性能力评估
在为产品推荐可靠性方案前必须首先评估组织的可靠性能力水平，我们把这称为可靠性能力评估。
5.1、什么是可靠性能力评估？
可靠性能力评估师一个对整个组织进行详细评估的方法并且涵盖所有产品开发部门。对组织当前的情况进行评估后制定可执行的可靠性大纲。
可靠性能力评估并不需要再每个项目开始前完成，但是符合下列条件时需要开展：
A、 成熟企业由于内部或者现场大量失效而必须极大改善产品可靠性
B、 成熟企业产品保修成本太高而需要寻找方法来降低
C、 成熟企业不知道自己产品的可靠性水平或者不知道产品由于何种原因而被退回
D、 成熟企业试图进去新的市场
E、 新成立企业开发第一款产品
F、 成熟企业或者新成立企业从未有过可靠性计划
5.2开展可靠性评估的动机
可靠性能力评估可以识别对可靠性有影响的系统变更。它和企业的文化和产品紧密相关。它同时会提供达成目标的一个路线图任务清单。而组织能力和期望可以取得一致。
打个形象的比喻，当人生命时需要去看医生。在医生没有进行初步诊断前他们无法知道应该如何开药方？对于可靠性项目也一样。除非我们知道哪出了问题和为什么出问题，否则我们无法知道如何解决问题。看病时，医生开的药方取决于病人的症状，当然也包括病人的身体条件。有些病人对于某些药有耐药性，而无法获得比较好的疗效。这对于可靠性项目同样适用。嘉峪检测网认为，有些企业的文化接受某种技术或者某个变更，而有些企业则不。例如，有些企业在统计领域很擅长，可以通过统计理论来很好的解决问题。对于这些企业，加入其它技术例如Weibull分析来解决产品失效时间的问题就和企业的文化非常吻合。然而，如果工程师没有统计的背景，介绍这类的统计技术可能会不被流程所接受。
5.3、可靠性能力评估步骤
可靠性能力评估包含如下步骤：
A、 确定被调查人
B、 确定调查主题
C、 制定评分系统
D、 分析数据
E、 一起审核结果（检查步骤）
F、 结果总结
G、 方案建议
H、 对特定领域进行深入分析
5.3.1、确定被调查人
首先确定谁是合适的被调查人。这很大程度上取决于评估目标。调查就是一个发现问题的过程。评估者的工作就是从被调查者获得最多的信息。推荐把下列人选列入被调查人员名单：
设计工程师（电子、机械、光学、化学、软件、固件等）
技术经理
系统工程师
生产工程师
测试工程师（硬件和软件）
质量和可靠性工程师
公司质量负责人
采购
项目经理
技术支持/现场服务
核心供应商
合同制造商或者原始设计生产商
注：这个名单可能会由于公司的岗位和职责定义不同而不同
5.3.2、确定调查主题
我们必须准备至少20-30个问题来覆盖组织的可靠性不同领域，其中包括管理、设计和制造。下面是几个问题的示例：
管理：可靠性的目标是如何制定的（可以是年失效率或者保修期内失效率）？
设计：“失效模式影响分析是如何应用的？
制造：“面向可制造性的设计是如何开展的？
注：同一个问题获得团队中不同岗位的反馈非常重要。因为很有可能参与调查的某个人对于实际情况了解不够。例如，如果我们咨询管理层如何设定目标，他们也许回答在每个项目开始时都会执行，具体要求由市场提出并给予工程团队。当我们再咨询工程师时，我们可能会发现其实这样的情况并没有发生。如果某人的反馈和公司情况相左，他们只是想通过调查来表达他们的不满，这时候我们就需要对调查的反馈进行过滤。
5.3.3、制定评分系统
我们必须为评估建立评分系统。为了达成此目的就必须为每个反馈进行评分。下面是评分标准的建议。
5 = 非常有效
4 = 很有效
3 = 有效
2 = 效果较差
1 = 无效
0 = 未执行或者执行中断
- = 无信息、无法评价
具体的评分和技术的效果直接相关。效果通过技术的执行结果和使用频率进行评估。如果团队某种技术开展的非常好，但是他们很少采用这种技术，那么这种技术仍然不是一个有效的技术。必须注意的是，如果被调查者在流程中并未介入，应该允许他们跳过某问题或者不进行评分，而不是填写评分结果为零，这样就不会对最终的结果产生影响。为了获得综合结果，每个问题必须综合多人的评分结果。
在某次评估中，我曾经问过一个团队关于“失效模式影响分析有多重要？”的问题，生产工程师反馈失效模式影响分析只是一个分析问题的技术，所以他对于这个问题的评分是2。设计工程师的反馈则认为失效模式影响分析只在对关键设计进行评估是才比较重要，所以他们的评分是3。嘉峪检测网认为，可靠性工程师的反馈则认为失效模式影响分析是一个重要的设计技术并且可以应用到所有的设计领域中，所以他们的评分是4。通过对这三个岗位的评分进行平均，最终的评分为3。然而，除了评分以外，我们看到其中存在的问题。如果可靠性工程师认为失效模式影响分析师一个重要的设计技术，为什么设计工程师不经常使用这个技术。如果失效模式影响分析师如此关键的设计技术，他们必然会参与到其中。也许这个技术并不如可靠性工程师所想的那样有效，如果这确实是开发流程中的重要技术，那么我们必须要解决流程中所存在的问题。
5.3.4、分析数据
在调查完成后，我们必须对调查结果进行审核并计算每个问题的平均值。当然除了计算平均值外也可以设定相应的权重再进行计算。一旦完成对所有调查结果的计算后需要对每个大类的结果进行总结。
5.3.5、一起审核结果（检查步骤）
和团队一起审查分析结果是非常重要的，因为这为他们提供一个额外的机会来进行反馈。这个过程也被大家称为“我们是否是对的？”。这样做的目的是希望保证结果尽可能正确。如果在调查过程中出现疏漏，我们需要正视并给予反馈者额外的机会来进行修正。请注意，如果我们不能够有效的开展评估流程就无法发现组织的真实情况，我们就无法为组织设定正确的方向。
5.3.6、结果总计
对每个问题的回复进行总结并给予参加调查的每个人提供反馈。我们必须整理所反馈的每一个评分结果。下面的表格是可靠性成熟度矩阵的总结工具。
5.3.6.1、可靠性成熟度矩阵
可靠性成熟度矩阵是一个对问题进行归类和总结的方法，同时我们可以用它来和同行业的其它企业进行对比。表格5.1a和5.1b展示了可靠性成熟度矩阵的流程。我们基于Crosby20实际70年代提出的质量矩阵方法来建立了可靠性成熟度矩阵。欢迎使用此矩阵，当然需要根据具体的行业来对矩阵进行修改。
我们把可靠性成熟度矩阵分成了5个不同的阶段和7个不同的分类来对成熟度进行评估。请仔细阅读每一行的来选择最适合企业的描述。每个阶段的平均值就是企业的总体的成熟度水平。通常，不同的分量成熟度水平评估结果会有所差异，但是同一个企业一个分类的评估结果相差超过2个水平是不正常的。几乎没有企业属于第一阶段的水平。当我们建议企业开展可靠性能力评估，他们都会说“为什么需要这么麻烦，我们早就知道我们可靠性方面什么都没有做了。”。绝大多数企业有可靠性项目的模板，但是通常不会记录那些经验教训。企业都喜欢那些能够引人注目的成功经验。嘉峪检测网认为，通常我们也很少发现企业处于第5阶段的，而第5阶段是预留给那些世界上最优秀的企业，相信这样的企业不会很多（我知道有一家公司处于第5阶段，但是处于竞争优势的考虑不能够和大家分享他们的技术）。第5阶段的企业有他们自己的流程并能够很好的执行，他们不需要通过评估来告诉他们处于哪个阶段，通常也不会邀请外部顾问来对他们进行评估，他们明确了解自己处于什么位置。
5.3.7、方案建议
在获得反馈并且确信已经发现了组织的本质后就可以就评估结果进行提供建议了。这也许是评估中最难的部分。这也是经验真正起作用的地方，我们必须对于行业中的优秀案例有很好的理解，并且能够从不同的案例中进行提炼。如果之前没有任何的评估经验，建议在进行第一次评估时邀请一位专家来确保执行流程和最终结论的的正确性。对于评估，需要重点注意的有趋势、流程缺陷、能力不匹配、过度分析和欠分析。从多个方面对组织进行评估，例如优势项目、好的结果和需要努力的地方。没有一个方法或者一套方法能够成就一个可靠性项目。具体的方法需要和产品和组织的文化相匹配。很多公司在我们评估下只是出于第2或者第3阶段，但是他们想了解如何达到低5阶段。首先要说明的是达到第5阶段的组织非常少。第二，在一个产品上提高超过一个阶段也是很难做到的。我们需要设定一个合理的期望，并且在变革中有足够的耐心。
5.3.8、对特定领域进行深入分析
在评估过程中吗，某些领域需要进行深入分析。只是一个调查问卷并不能够很好的对企业进行评估并给出建议。我们建议对下列领域进行详细分析。其中部分领域如下：
审查现场结果
审查工程良率
评估关键供应商
审查设计控制流程
这些领域的深入分析结果可以加入到评估建议中。
5.4、100个评估中的发现
我们已经为超过100个不同的客户开展可靠性能力评估。基于我们评估，我们发现没有两个客户是一样的。即使同一客户的两个不同部门也有很大的差异。当然，如果要对自己的企业进行评估，我们建议对每个部门进行单独评估，而不是假设一个部门可以代表整个企业。基于所有部门的评估结果来决定企业最好和最差的领域。下面两个章节列出了部分结果。在本书的后续章节会进行反复强调，某些甚至会成为一个独立的章节或者某个章节重要的主题的。请参考目录来了解更多信息来选择大家所感兴趣的章节。
5.4.1、企业做的好的地方
可靠性预计
高加速寿命试验
快速解决问题
设计准则
软件问题数据库的跟踪
软件系统测试
5.4.2、企业做的不好的地方/需要改善的地方
目标制定
可靠性计划
维修和保修信息缺失
经验总结流程
产品可靠性专人负责制
多个问题追踪系统
好的可靠性设计方法
应用统计技术
软件和硬件的互动
可靠性整合：明确可靠性项目的目标
可靠性能力评估推动可靠性项目来引入更多的活动。评估建议可以知道企业未来的可靠性项目方向。在项目的某个合适节点，再次进行可靠性能力评估来了解企业的和目标的距离也是合理的。
案例：评估建议客户远离某个市场
我们一个客户生产试验室的环境测试设备，他们希望使用类似的设备来生产控制设备以进入一个新的市场。实验室设备的可靠性要求低于控制系统。通过评估后，我们给客户展示了他们还未准备好来生产新的产品类别。而新的设备要求客户在产品发布前可靠性成熟度上至少提高2-3个阶段，这意味着需要对组织进行完全重组（他们并没有准备好为此进行重组）。基于评估建议，他们决定不进入这个新的市场。总体而言，他们节省了巨大的资金并且保护他们的声誉。
