高低溫濕熱試驗箱技術規格：

1、指南而不是強制要求
       可靠性是一門有價值的學科，它應用了很多技術，我們可以用來解決問題并開發出可靠的產品。當然這一定存在一些指南和成功經驗，但是我們必須要根據企業的實際情況來進行裁剪。其中我們需要關注的領域有企業的規模、企業文化、過去的經驗、教育背景、市場和客戶要求等。
       即使這本書已經提供了眾多不同的技術，但是千萬不要認為我們需要采用所有的技術。在這本書的剩余部分所寫可以成為指南或者提示。針對具體的項目，我們需要自己來判斷哪些經驗適用，哪些經驗不適用。不能夠直接拷貝別人的可靠性大綱，即使是同一個行業的也不行，當然我們也不能夠拷貝之前公司的可靠性大綱。他們可以是我們開始時非常有價值的參考，但是當我們試圖直接拷貝一個可靠性大綱時只會給我們帶來災難，因為只有切合組織的文化，參與產品項目的人，這個可靠性大綱才會真正起作用。我曾經見過兩家企業生產相同的產品，但是他們的可靠性大綱*不同，但是這兩家公司的可靠性大綱執行的都很好。
      我們應該注意的比較重要的事情是不管我們起草了什么樣的可靠性大綱，關鍵是在產品開發流程給定的時間內必須有一個可以測量的指標，而這個可靠性大綱應該保障產品能夠獲得理想的結果。
案例：
      我曾經對一個The military的供應商開展過一次可靠性評估，作為評估的一部分我要求審核一下他們的可靠性大綱。這家客戶對于他們的可靠性大綱非常自豪，這份資料足足有100頁之多。我咨詢他們的可靠性工程師這份可靠性大綱是如何編寫出來的。他回答說他參考了一份非常的可靠性專著，把這本書的每一章都涵蓋到可靠性大綱中去。為仔細查看了這份可靠性大綱并注意到他幾乎一字不漏的*拷貝了那本書。他認為越遵守這本書越能夠獲得成功。但是這不可能成為現實了。可靠性大綱必須要有一個很好的基礎不錯，一本可靠性專著可以和其它的資源一樣有價值，但是我們必須根據實際情況進行裁剪，而這份可靠性大綱明顯沒有這么做。幸運的是他們的客戶并沒有那么Foolishness，終拒絕了這份可靠性大綱。
       隨后我和這家客戶基于之前的可靠性大綱進行修改來適應他們的實際情況。終他們的客戶接受的新的可靠性大綱。這家客戶按照新的可靠性大綱終開發了非常可靠性的產品。
2、什么是可靠性設計？
       可靠性早已不是由一個團隊來單獨開展的活動。產品可靠性指標、風險和活動已經融入到組織的每個流程和功能當中去。管理團隊的職責就是培訓團隊清晰的可靠性和質量意識。技術團隊必須平衡項目成本、客戶的產品維修保養成本、質量、項目周期、性能和可靠性（有些行業可能還有其它指標）來達到優化產品設計的目的。我們的組織構架必須做到鼓勵每個成員來采用合適的可靠性方法和手段。嘉峪檢測網認為，可靠性設計作為可靠性工程師的一個職責是來發現性價比高的零部件和風險低的結構設計并把它展示給團隊中的其它成員。
       當我1984年開始從事可靠性工作時，可靠性看上去接別人丟過來的東西，當設計工程師完成產品設計后就*轉給可靠性團隊來負責。當可靠性團隊拿到產品時幾乎無法影響產品的設計，所以可靠性工作的重點就是評估產品的可靠性水平。如果產品沒有滿足可靠性指標要求，我們可以做什么呢？事實上還是銷售給客戶，然后花費多年時間來跟蹤產品的性能并糾正那些可以改善的問題。當然，產品會隨著時間的推移越來越好了。我曾經的那家公司通常是利用客戶來建立一個反饋機制。終結果就是客戶不滿意，公司在可靠性方面的信譽很差。很不幸的是這樣的做法很常見。
       在當今經濟下，很多行業在比拼可靠性。我們終于意識到“丟過墻”的模式已經不行了。可靠性是設計出來的。沒有什么比讓設計工程師對他們產品設計的可靠性負責更好的方式了。這種模式現在執行的很好，當我開展可靠性設計演講時，參加的人員大部分是設計工程師而不是可靠性工程師。可靠性工程師的職責轉變為顧問。可靠性工程發現合適的技術并給設計工程師培訓如何使用。可靠性工程師還輔助撰寫可靠性大綱，而設計工程師則負責執行可靠性大綱。
       可靠性設計就是如何讓設計工程師承擔產品可靠性的職責。可靠性部門開始成為指導委員會，幫助制定規章制度，提供方向指導和培訓。我把這比作劃船比賽。可靠性工程師是船長（劃船隊的船長通常坐在船頭面對船尾，指揮整個船隊并協調大家的每個船員的力量和節奏）。設計工程師就是船員。當兩者協同工作，整條船就能夠在水面上更平穩省力的滑行。
 
誰應該參加可靠性設計的課程？
 
每次當我提供可靠性設計培訓時，我的客戶總是問誰應該參加。當然設計工程師必須參加。那么市場人員需要參加嗎？當然，他們需要參加。我們必須讓銷售、客戶服務、和工廠都應該有相應的代表參加。同事可靠性團隊也需要參加。任何人與產品可靠性相關的都必須參加。然而，設計工程師是流程中的關鍵。他們日常中隊產品設計所做的決定會極大的影響產品的可靠性。那么可靠性團隊的職責又是什么呢？這個團隊需要可靠性工作的Leaders和培訓者，同時還需要協助制定可靠性指標和撰寫可靠性大綱。而日常的可靠性工作則由設計工程師來完成（在可靠性團隊的指導下）。
 
案例：
 
一個通信企業被產品糟糕的可靠性水平所困擾。每次他們在產品測試或者工程發現問題時，測試工程師和工程的工程師都無法獲得設計工程師的幫助來解決問題，因為設計工程師都在忙著開發新產品沒有時間。你看，他們只關心多快可以把產品推向市場，但是產品是否可靠性不重要。這家企業做了一個很聰明的決定，執行官做了個決定，他告訴所有的設計工程師，從現在開發解決問題是他們的職責。你知道發生了什么嗎？突然設計工程師開始愿意傾聽可靠性團隊的聲音，于是一個可靠性設計的項目開始在企業內誕生。絕大多數設計工程師喜歡從事新產品設計工作，不喜歡對問題進行改善。不久他們開始從事新項目，他們也有了更好的認識。他們試圖成功解決之前項目的問題，這時候他們才真正認同可靠性并為產品可靠性設計而做出努力。
 
3、只有把可靠性整合進產品開發才完整
整合可靠性就是把可靠性技術集成到產品開發流程中來提高產品可靠性水平并降低成本。這意味著我們必須把一些列的技術作為一個項目來考慮，而不只是一堆獨立的活動。
如果我們要建造一個系統，而一些是有不同的零部件或者零組件組成，產品的組成包含了不同的領域（其中主要的有電子、機械、軟件、固件、光學和化學等）。所有的這些獨立的個體組成了一個系統，當然我們也不能夠忽視它們之間的交互關系，并且需要保證我們從系統的角度來考慮可靠性項目。下圖中我介紹了三種類型組成的系統，電子、機械和軟件。
對于軟件和硬件這尤其合理。絕大多數的公司把軟件可靠性和硬件可靠性分離開來而不是當作一個整理看待。當失效發生時，這就會導致大家互相指責而不是合作。
對于電子和機械這兩個領域也同樣正確。相比于軟件和硬件我們能夠看到這兩個領域較多的合作。但是在初始時，他們很少會在一起討論常規的可靠性目標和如何計劃對系統的關鍵部分進行分解。
產品開發團隊只是在機械、電子和軟件不同領域的獨立的看待可靠性問題。但是客戶只會從系統的交代看到可靠性問題，而他們只會把很小的關注放在機械、電子和軟件問題上。客戶希望產品的所有部件可以的工作在一起。由于可靠性的度量主要是客戶來執行，工程團隊必須在系統和子系統上取得平衡來開發可靠的產品。
可靠性與成本
 
可靠性的重點就是在小增加開發和制造成本的條件下達成保修和服務成本的降低。在生命周期的特定階段使用合適的技術會幫助我們來小化全壽命周期成本。
 
為了小化全壽命周期成本，單位必須做如下兩件事情：
 
1、從可用的技術中選擇合適的技術并應用到產品壽命周期的合適的階段
 
2、基于具體的信息把這些技術合理的集成到產品壽命周期的不同階段。
1、項目成本會隨著可靠性的提高而增加。當到達某個點后，我們不會從可靠性的投資中獲取回報，因為當可靠性達到某個點后就會變的很難再提高。這也是為什么我們需要知道目標在哪，這也就決定了我們公司生產的產品是太可靠了還是不太可靠。嘉峪檢測網認為，當產品太可靠了，通常會帶來成本的增加，而客戶也許并不需要這么高可靠性的產品，他們會考慮更低價格的產品。我們上次購買200美元的攪拌機和烤面包機是什么時候？
2、當可靠性降低時，維保成本會增加。
3、軟件和制造成本沒有關系（也許光盤、說明書和產品生產功能測試成本除外），所以維保費用絕大多數時候分配給硬件。如果軟件可靠性并不能夠降低成本，為什么還要管它呢，硬度更多的關注硬件可靠性改善來降低成本。我們當然不能夠這么做了，主要是以下兩個原因：
A、根據我們的經驗，典型系統的軟件失效和硬件失效的比值為10:1。客戶只會購買整個系統而不只是硬件。
B、軟可靠性項目并不會直接產生成本降低。相反的，他們會對下面的領域有幫助：
提高軟件和固件可用性會降低維修導致的停機
提高客戶滿意度
 
每次當我提供可靠性設計培訓時，我的客戶總是問誰應該參加。當然設計工程師必須參加。那么市場人員需要參加嗎？當然，他們需要參加。我們必須讓銷售、客戶服
務、和工廠都應該有相應的代表參加。同事可靠性團隊也需要參加。任何人與產品可靠性相關的都必須參加。然而，設計工程師是流程中的關鍵。他們日常中隊產品
設計所做的決定會極大的影響產品的可靠性。那么可靠性團隊的職責又是什么呢？這個團隊需要可靠性工作的Leaders和培訓者，同時還需要協助制定可靠性指標和撰
寫可靠性大綱。而日常的可靠性工作則由設計工程師來完成（在可靠性團隊的指導下）。
 
案例：把電子、機械和軟件可靠性聯系在一起
 
我曾經在一個半導體設備公司工作來幫助改善下一代產的可靠性。首先我為三個領域（電子、機械和軟件）的團隊提供了可靠性設計的培訓。然后我們和電子、機械和軟件團隊的負責人討論并制定可靠性目標。我們從系統的頂層指標開始并逐步分解到子系統（電子、機械和軟件）。每個團隊負責他們子系統的可靠性目標并繼續分解到更小的單元。我和每個團隊負責人一起制定可靠性大綱來保證他們的子系統可以滿足既定指標。我們針對每個不同的子系統發布不同的大綱并終整合到產品的可靠性大綱中去。我和每個團隊負責人合作來確保他們在整個產品開發流程中持續跟蹤子系統目標。終每個子系統成功達成目標，從而保證整個產品達成目標。
4、平衡內部和外部資源
當我們計劃一個可靠性項目時，我們必須決定是招聘全職人員來完成、尋求外部資源的協助，或者兩者都是。大多數企業同時選擇兩者。他們讓自己的員工負責日常工作，例如開會以及和設計團隊共同協作，而當他們不具備相應的能力或者人力不足時則借助外部資源來執行相應的工作。下面是尋求外部資源協助的前理由（排名不分先后）供大家參考：
1、可靠性專家
2、可靠性評估
3、技術風險評估
4、特殊技能
5、為工程師提供培訓
6、在起步階段
7、企業裁員
8、引導
9、在特定地區提供幫助
10、專家建議
4.1可靠性專家
企業需要一個強力的可靠性專家來制定可靠性項目的方向，建立企業的指標并決定選擇安排不同類型的人到不同的崗位來保證項目的成功。在第2章我們討論了可靠性設計的專題，但是只有設計工程師覺得在可靠性專家的領導下才會真正起作用。如果企業缺少這樣的可靠性Leaders，那么就是時候來引入外部咨詢專家來的團隊并提供培訓。如果企業已經有了自己的可靠性工程師，企業可以考慮讓顧問來培訓可靠性團隊，后期可靠性團隊的其中一個成員成為企業可靠性負責人來負責整個企業的可靠性工作。
4.2可靠性評估
當我們回顧過去發布的產品時會經常發現產品的可靠性水平需要提高。這并不是一個明確的問題，而是很多小的問題所累積而導致客戶的不滿。企業需要對可靠性進行更好的預計。如此一來外部機構可以幫助評估企業的薄弱環節。我們把這稱為可靠性評估。
4.3技術風險評估
如果企業正在進入一個全新的市場或者采用全新的技術，則企業需要保證能夠達到規定的可靠性水平。一個很好的例子是決定采用固態硬盤還是傳統的機械硬盤。在技術背后所隱藏的可靠性代表著什么？固態硬盤會比傳統硬盤更好還是更壞？企業需要一個專家來進行技術風險評估來評估企業所開發的產品可能的可靠性水平。
4.4特殊技能
如果客戶要求的技術（或者內部決定采用的技術），但是企業并不知道如何做，這也是一個合適的理由來引入外部專家。當引入外部專家時采用試驗設計技術是很好的一個選擇。大多數公司很少開展試驗設計，所以基本對試驗設計不熟悉，相應的對于如何開展試驗設計比較生疏。嘉峪檢測網認為，外部專家可以提供手把手的培訓課程通過專題研討會來給大家做培訓并進行實踐。可靠性領域很寬，很少有人會涉獵所有的領域。即使很的可靠性工程師出現有些問題超出他的能力范圍也是很正常的，這時候可以考慮引入外部的專家來進行協助。
4.5為工程師提供培訓
外部專家不僅可以為企業提供培訓課程還可以為企業建立課程培訓計劃。培訓計劃應該能夠彌補工程師的培訓需求的缺口并幫助剛入職的員工快速進入狀態。培訓計劃還必須包含培訓培訓講師的環境，從而使得企業從現在就可以為未來的內部培訓培養人才。
4.6在起步階段
當一個企業發現自身需要在產品設計領域快速提高時又無法快速招聘或者不太確定需求是短期的還是長期的，這是It's better的選擇就是聘請外部專家來填補人力缺口。相比于員工招聘，聘請外部專家更加容易（通常我們可以在確定專家候選人后要求對方幾天內到位，而他們在到位后可以立即開展工作）。同樣如果與外部專家解約也非常簡單（在加利福利亞解雇一個全職員工非常困難，法律風險很大，而和顧問解約的風險可以得到極大的降低）。
4.7企業裁員
在企業裁員后利用外部顧問可以更，而企業也需要持續開發新產品，工作必須有人去執行。由于不需要雇傭全職人員，外部顧問只是在需要的時候才會聘用，進而可以幫助企業降低總體人力成本
4.8引導
經常會出現一個人技術都具備但是對于團隊的現場引導能力不足。一個很好的例子是失效模式影響分析。大部分工程師都熟悉基本的技術并能夠指出產品可能存在的失效來決定如何解決潛在的失效。問題是每個工程師所掌握的技術有所差異，當我們把一個不同職能的工程師團隊集中在一個房間就會變的很混亂。這時候我所需要的就是一個強力的Leaders來指引大家通過流程來確保每個人的想法被傾聽而不是由某個人來主導討論。我們會在第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階段是預留給那些世界上The best的企業，相信這樣的企業不會很多（我知道有一家公司處于第5階段，但是處于競爭優勢的考慮不能夠和大家分享他們的技術）。第5階段的企業有他們自己的流程并能夠很好的執行，他們不需要通過評估來告訴他們處于哪個階段，通常也不會邀請外部顧問來對他們進行評估，他們明確了解自己處于什么位置。
5.3.7、方案建議
在獲得反饋并且確信已經發現了組織的本質后就可以就評估結果進行提供建議了。這也許是評估中難的部分。這也是經驗真正起作用的地方，我們必須對于行業中的案例有很好的理解，并且能夠從不同的案例中進行提煉。如果之前沒有任何的評估經驗，建議在進行評估時邀請一位專家來確保執行流程和終結論的的正確性。對于評估，需要重點注意的有趨勢、流程缺陷、能力不匹配、過度分析和欠分析。從多個方面對組織進行評估，例如優勢項目、好的結果和需要努力的地方。沒有一個方法或者一套方法能夠成就一個可靠性項目。具體的方法需要和產品和組織的文化相匹配。很多公司在我們評估下只是出于第2或者第3階段，但是他們想了解如何達到低5階段。首先要說明的是達到第5階段的組織非常少。第二，在一個產品上提高超過一個階段也是很難做到的。我們需要設定一個合理的期望，并且在變革中有足夠的耐心。
5.3.8、對特定領域進行深入分析
在評估過程中嗎，某些領域需要進行深入分析。只是一個調查問卷并不能夠很好的對企業進行評估并給出建議。我們建議對下列領域進行詳細分析。其中部分領域如下：
審查現場結果
審查工程良率
評估關鍵供應商
審查設計控制流程
這些領域的深入分析結果可以加入到評估建議中。
5.4、100個評估中的發現
我們已經為超過100個不同的客戶開展可靠性能力評估。基于我們評估，我們發現沒有兩個客戶是一樣的。即使同一客戶的兩個不同部門也有很大的差異。當然，如果要對自己的企業進行評估，我們建議對每個部門進行單獨評估，而不是假設一個部門可以代表整個企業。基于所有部門的評估結果來決定企業It's better和差的領域。下面兩個章節列出了部分結果。在本書的后續章節會進行反復強調，某些甚至會成為一個獨立的章節或者某個章節重要的主題的。請參考目錄來了解更多信息來選擇大家所感興趣的章節。
5.4.1、企業做的好的地方
可靠性預計
高加速壽命試驗
快速解決問題
設計準則
軟件問題數據庫的跟蹤
軟件系統測試
5.4.2、企業做的不好的地方/需要改善的地方
目標制定
可靠性計劃
維修和保修信息缺失
經驗總結流程
產品可靠性專人負責制
多個問題追蹤系統
好的可靠性設計方法
應用統計技術
軟件和硬件的互動
可靠性整合：明確可靠性項目的目標
可靠性能力評估推動可靠性項目來引入更多的活動。評估建議可以知道企業未來的可靠性項目方向。在項目的某個合適節點，再次進行可靠性能力評估來了解企業的和目標的距離也是合理的。