QKC20190524：讀書會_GD3 未然防止手法 - 新產品導入三部曲

hlperng

品質學會品質知識社群 (QKC) 讀書會
專題：GD3 未然防止手法 - 新產品導入三部曲
時間：2019 年 05 月 24 日(星期五) 14:00 - 18:00
地點：品質學會九樓教室（台北市羅斯福路 2 段 75 號）
引導：彭鴻霖會友

• 預防行動 (preventive action) 何去何從？從 ISO 9001:2015 說起
• 未然防止與再發防止
• 豐田汽車的 GD3 與通用汽車的 GD3
  

設計、討論、舉證

hlperng

精實：精實管理 (lean management)、精實生產 (lean production)、精實工程 (lean engineering)、精實產品研發 (lean product development)

精實 (lean) 意思是減廢 (reduce wastes)


精實產品研發 13 原則：
13 principles

• Establish customer-defined value to separate value-added from waste.
• Front-load the product design process while there is design space to thoroughly explore alter native solutions.
• Create a leveled product development process flow.
• Use rigorous standardization to reduce variation, thereby creating both flexibility and predictable outcomes.
• Develop a chief engineer system to integrate development from start to finish.
• Organize to balance functional expertise and cross-functional integration (more is involved here than your father’s matrix management).
• Develop towering technical competence in all engineers.
• Fully integrate suppliers into the product development system.
• Build in learning and continuous improvement.
• Build a culture to support excellence and relentless improvement.
• Adapt technology to fit your people and your processes.
• Align your organization through simple, visual communication.
• Use powerful tools for standardization and organizational learning.
  

新產品或改進在市場上算是成功的產品，





參考資料

• Eric Rebentisch (2006), Lean Product Development
• Book Review, James M. Morgan and Jeffrey K. Liker (2006), The Toyota Product Development System
• Ana Julia Dal Forno et al., Lean Product Development: an overview of the best global practices
• Jeffrey K. Liker and James M. Morgan (2006), Exchange: The Toyota Way in Services: The Case of Lean Product Development
• Amer Catic and Michael Vielhaber (2011), Lean Product Development: Hype or Sustainable New Paradigm?
• Magnus Gillebo and Morten Skogli Pettersen (2013), Master Thesis, Lean Product Development Systems - How internal lean product principles and work organization integrate with product development systems
• Ana Julia Dal Forno and Fernando Antonio Forcellini (2013), Lean Product Development - Principles and practices
• Micaela Institories and Lars-Ola Bligard (2014), Human Factors Engineering as a supportive tool for Lean Product Development
• Larry Navarre (2016), How Lean Product and Process Development Can Improve Your R&D Results
• Erwin Rauch, Patrick Dallasega, and Dominik T. Matt (2016), The way from Lean Product Development (LPD) to Smart Product Development (SPD
• John J. Paschkewitz, Ensuring Reliability in Lean New Product Development
• 
  

hlperng

2003 年吉村達彥博士離開日本加入美國通用汽車公司，推動美國版的 GD3。

GD3 = Good Design + Good Discussion + Good Dissection

Good Design = Design for Reliability (DfR)，Design for Six Sigma (DFSS)
Good Discussion = Design Revivew Based on Failure Mode (DRBFM)
Good Dissection = Design Review Based on Test Results

DRBTR 結合通用汽車公司對於車用電子產品環境與耐久性試驗所採用的 A/D/T (Analaysis/Development/Testing) 過程，這項工作係由通用汽車公司 Larry Edson 先生負責配合發展，展現在通用汽車公司全世界工程標準 - 通用規範 (Worldwide Engineering Standards - General Specification) GMW 3172: General Specification for Electrical / Electronic Components - Environmental / Durability。

吉村達彥 (1942-)

hlperng

日本豐田汽車公司稱 GD3 為未然防止的基本原則 (GD3: Fundamental Principles of Mizen Boushi)，GD3 是一種主動式的問題預防 (proactive problem prevention) 概念與手法。在產品發展過程中確保可靠性的首要不變原則，千萬記住：「不做變更！」(make no changes)

提到豐田汽車公司，國內品質與管理界最風靡的就是豐田式生產方法 (Toyota Production System, TPS)，以及衍生的精實生產 (Lean Production, LP)，這些觀點都是以按圖施工、代工製造、現場管理為主。但是若要從創新研發、新產品導入，這些技法顯然就會有南轅北轍之虞。豐田汽車公司對於精實的實踐，除了精實生產，也有精實研發 (lean development) 的部分，其實豐田汽車公司的競爭優勢不是在生產線場管理，而是新產品設計與開發之前，由部分研發與可靠度人員涉入所完成的各種預防品質問題發生的方法與工具，又稱為豐田產品研發系統 (the Toyota Product Development System, TPDS)，相關內容可參考的論述著作包括：

• Jeffrey Liker, The Toyota Way
• Machael Kennedy, Product Development for the Lean Enterprise - Why Toyota's System is Four Times More Productive and How You Can Implement It
• James Morgan and Jeffrey Like (2006), The Toyota Product Development System
  

GD3 的相關作業是從失效模式為基礎設計審查 (Design Review Based on Failure Mode, DFBFM) 衍生出來的。根據豐田汽車公司資料，未然防止著重在品質問題預防，基本原則是 3 個 GD：良好設計 (good design)、良好討論 (good discussion)、與良好設計審查 (good design review)。亦即：

GD3 = Good Design + Good Discussion + Good Design Review

DRBFM 與 GD3 倡議者：吉村達彥博士
1997 年吉村達彥 (Tatsuhiko Yoshimura) 博士替豐田汽車公司發展出新的設計管制手法，稱為「以失效模式為基礎設計審查」 (design review based on failure mode, DRBFM)。後來吉村達彥博士又倡議 GD3，是預防發生可靠度問題的產品研發技法，
2003 年吉村達彥博士，離開豐田汽車公司和九州大學，到美國加入通用汽車公司。

DRBFM 時代背景：新開發車型可靠性重點變更控管豐田汽車公司以算是成功的研發生產汽車，新型車大多是沿用驗證成功舊款進行部分更新或創新，屬於設計變更研發方式。因此利用 FMEA 方法的特色與長處，推出新產品研發 DRBFM 手法。將配套使用的 FMEA 稱為「創意 FMEA」 (creative FMEA)，針對設計變更部分執行失效模式與效應分析所得到的失效模式，作為設計審查時討論的焦點議題。日本產業推動 FMEA 是為了設計審查做準備，在設計者在設計定型之前把問題攤出來，試圖從源頭解決可能發生的問題，透過 FMEA 過程找出根因及解決對策；而其他普遍做 FMEA 只是為了應付認證稽核，稽核畢竟是事後挑毛病、找碴卡關，作為是否頒發稽核合格證書的利器，格局與視野差太多了。


DRBFM 過程的實施步驟如下

• 確定已證明可靠運作零組件的條件
• 設定新開發零組件的設計條件
• 比較兩者的設計條件決定設計條件變更
• 設計人員根據已確定的設計變更（失效來源）、失效模式表單、預估可能的失效模式
• 利用 FTA 考量失效模式的主要因素
• 考慮主要根因的對策
  

透過 DRBFM 可以有效地預測潛在失效模式，但是在推動時經常會碰到下列三種誤差，嚴重影響 DRBFM 的成效：

• 未注意造成的誤差：設計人員沒有考慮到的問題，使用結構性零件結構圖降低可能性。
• 低估造成的誤差：設計人員注意到問題，但認為只會造成部分失效，疏忽了可能失效鏈效而造成整個系統失效，因此並沒有採取預防對策。選擇適切的審查委員及討論過程可以發掘及解決此類問題。
• 誤解造成的誤差：設計人員注意到問題存在，但是因為知識或經驗不足，所採取的設計對策不夠。此類問題涉及複雜的零件結構介面議題，處理失效鏈效應相對困難，必須找到可以有效防止事故發生的解決方法。
  

Dephi Thermal Systems 公司推動 DRBFM 的作法：

BOD: Bill of Design
BOM: Bill of Materials
BOP: Bill of Processes


參考資料

• Shigeto Kano and Hirokazu Shimmizue, A Guide to GD3 Activities and DRBFM Technique to Prevent Trouble Ver. 5.0
• Amer Catic and Michael Vielhaber (2011), Lean Product Development: Hype or Sustainable New Paradigm?
• Hirokazu Shimizu, Yuichi Otsuka, and Hiroshi Noguchi (2010), Design Review Based on Failure Mode to Visualize Reliability Problems in the Development Stage of Mechanical Products
• R. Laurenti and H. Rozenfeld (2009), An Improved Method of Failure Mode Analysis for Design Change
• John Teresko (2007), Toyota's Real Secret: Hint, It's Not TPS.
• Lisa Allan, Change Point Analysis and DRBFM: A Winning Combination, ReliaSoft Website.
• James McLeish and William Haughey, White Paper: Introduction to Japanese Style Mizenboushi Methods for Preventing Problems Before They Occur
• John J. Paschkewitz, Ensuring Reliability in Lean New Product Development, Part 1: Lean Product Development, ASQ
• John J. Paschkewitz,  Part 2: Using FMEA, DFR, Test and Failure Analysis in Lean NPD, ASQ
• John J. Paschkewitz (2014), Applying Accelerated Testing in Lean Product Development, ASQ
• PlanTech Inc.,DRBFM Case Study, www.plantechinc.com
  

hlperng

日本產業重視產品品質，與 ISO 9000 的發展和盛行無關。為了解決問題特別強調二防手法：預防未發與防止再發（日文漢字為未然防止と再発防止） ，前者強調沒有發生的問題或事故不能讓它萌芽發生，後者對於已經發生的問題或事故不允許再次發生。預防未發的日文為 みぜん ぼうし (Mizen Boushi)，漢字為未然防止，中文常用術語為防患未然，是一種良好的問題預防手法。(good problem prevention)

問題解決與問題預防 (problem solution vs. problem prevention) 包括兩個層面，前者問題已經發生，後者問題尚未發生、但有可能會發生。問題解決容易有績效，只要不事我犯錯，要提出對策大家趨之若鶩。問題預防，潛在問題往往見光死、自動解決。所以 AIAG-VGA FMEA Handbook 2018 把 AIAG 長期加在 FMEA 前面的 潛在的 (potential) 拿掉了。相信工程師更是為了保護自己，絕對會對自己所提出的設計見解或解答說絕對零失效！沒有甚麼值得拿出來審查的，至於其他失效模式，看誰提出來誰就該負責處理解決。

日本科技連 (JUSE) 對於「問題解決與未然防止」的說明如下：
未然防止とは、製品の品質トラブルや製造現場での事故などを、起きる前に（＝未然に）防ぐための活動を指します。言葉だけでは単純そうに見えますが、実はこれは意外と難しい作業です。問題解決においては、既に「見えている、存在している」問題を対象にしています。しかし、未然防止では「見えていない、存在しない」問題を"想定する"という、問題解決とは違った能力が必要になるためです。
未然防止是指，在生產現場為了防止產品品質問題和事故發生所採取的事先活動。 此一名詞單獨使用雖然看起來很簡單，但實務上卻是一項艱鉅的任務。 在解決問題方面，我們的目標是「可見的、現有的」問題。 而防範未然，則必須先發制人能夠「假設」一個「看不見的、不存在」問題，而不是解決已經知道的問題。

日本結構化知識研究所 (SKY) 詞彙集（用語集），對於 「未然防止と再発防止」 的說明如下:
実際に発生した故障・不具合に関する根本的な原因を追究し、その原因に対して今後同じ問題が発生しないように対策を講じる再発防止も重要であるが、設計業務、試作評価などの設計プロセス、製造工程やそのアウトプットである製品などに潜在する信頼性、安全性に関する故障・不具合・事故に対する未然防止の重要性も高まっている。多くの企業では、設計品質の向上、不良コストの低減、手戻りの低減などを目的に、開発・設計などの生産プロセスの上流段階からの未然防止活動に取り組んでいる。
重要的是要調查實際失效或不合格的根本原因，並採取措施防止將來發生同樣的問題，但重要的是防止再次發生，但設計過程如設計工作和試驗評估， 防止與製造過程中和產品相關的可靠性與安全性相關的潛在失效、不合格和事故的重要性也在增加。 許多公司正在從開發和設計等生產過程的上游階段開展預防活動，旨在提高設計品質，降低缺陷成本並減少重工。

hlperng

2015 年版之前的 ISO 9001，對於品質改進議題一直強調「預防」與「改正」並重，因此長久以來預防行動與改正行動 (preventive action and corrective action, PACA) 成為品質人論及改善時常常使用的口訣。但是 ISO 9001:2015 發行之後，本文內容不再出現預防行動，似乎違背了預防勝於治療的通識原則，有人甚至宣稱 ISO 9001:2015 取消預防行動此一重要的手法！此一爭論主要是因為新版 ISO 9001 第 10 章改進沒有提到預防行動，造成一些迷惑性的資訊流傳坊間，列舉如下：

• 生產X中心：... 新版條文也刪除了管理代表、品質手冊與預防措施等原本管理代表的稱謂。...
• Leaderxxxx：...ISO 9001:2015標準主要變化是什麼？ 一變：條文架構改變，使用ANNEX SL語言。三減：刪減「品質手冊」、「管理代表」、「預防措施」，九加：...
• xxxx管顧：...新版條文已無預防措施，矯正與預防措施目前常被混用或誤用。...
• BSMX：... ISO 9001:2015 有那些改變 ... 外包改為外部提供之物品及服務；沒有書面程序；沒有預防措施；包含利益相關者，非僅客戶；沒要求手冊、管理代表；增加文件使用靈活性。...
  

品質管理的真正精神與終極目標在於對於所提供產品與服務的品質保證，應該採取的理念是：與產品有關的問題，不管當下有沒有發生，就是不能發生；若有發生過，當然要立馬針對不符合事項採取適切的改正行動（或矯正措施）。而且改進的動因不是呼口號式的零災害、零故障、零缺點、零污染、．．．（書生誤國！），應該是採用「以風險為基礎」的決策模式，願意忍受「低至合理務實風險」 (as low as reasonably practical, ALARP)，同時心存滾動式持續改進的精神與原則，隨時保持「好還要更好」 (better than best) 的態度，不是只永遠宣稱「先求有、再求好」卻只做前半套。人非聖賢、凡事沒有十全十美。ISO 9001:2015 強調風險思維改進或風險思維持續改進 (risk-thinking improvement or continual improvement)；採取過程方式 (process approach)，因為品質管理本身就是系統，不需要另外要求系統原則。風險思維與過程手法兩項原則是新版 ISO 9001 的核心價值，其目的就是要擺脫過去教條式、官僚化的口號品質管理，劍及履及務實地實踐在日常事務上。有關 ISO 9001:2015 調整預防行動的背景可以參考 John Nolan (2015) 的文章。  

另外一個與風險思維改進相關的議題是，在管理理念與做法上從過去的預防 (preventive) 朝向主動 (proactive) 調整。近年來人工智慧 (AI) 的興起，大數據、萬物聯網裝置、虛網系統 (CPS) 架構與通訊協議等技術漸趨成熟實用。以常見的控制和維護作業為例，由於各種感測器的導入與佈建安裝，許多作業活動從預測調整為互動 (interactive)，若再加上電腦及/與微處理器及模型決策支援系統的運用，則可更進一步從互動變成主動，其間的變化趨勢如下：

操到壞 (Run to Failure or Run to Death, RTF) ⇒ 改正或矯正 (Corrective) ⇒ 被動 (Reactive) ⇒ 預測 (predictive)、互動 (interactive) ⇒ 主動 (proactive) ⇒ 自動 (automatic) ⇒ 自主 (autonomous)

John Nolan (2015), Risk-based thinking: The real difference from preventive action，ISO 9001 知識庫：
ISO 9001:2015 將現行的預防行動改由「風險為基礎思維」取代。以前的預防行動只是當作是否滿足 ISO 9001 要求的打勾用選項，而不是導入變更和持續改進的實際驅動力。過去預防行動大多數是由組織中低層負責規劃與推動實施，例如品質團隊成員，往往無法從高層管理的角度掌握實際會影響組織的議題、因而錯失持續改進的機會。

ISO 9001:2015 強調風險為基礎的方法，最高管理者團隊從一開始就參與品質管理系統的風險識別、記錄、消除和減輕活動，這種基於風險思維的過程，其有效性遠遠超過預防措施。管理者團隊要確保在日常管理會議上有討論風險識別的時段，這是非常重要的步驟。同時保證所有低層員工的意見都有相同的管道可以上達到管理者團隊供其考慮。兩者結合到位，就形成一個「基於風險思維」過程，由最高管理者團隊主持，由來自組織上下的信息提供支持，前者掌握著可以威脅組織業務的全部關鍵戰略資訊，後者可能會暴露出一些前者不知道的問題。實際結果是，組織獲得一個基於風險的思考過程，其管理團隊擁有來自組織最高層的所有資訊，自上而下過濾一以貫之，而被取代的只是一個單維的預防措施過程，通常屬於組織較低層的動作，永不上達。依據此過程所作出的決策，以及隨後的保障措施不難看出，這樣所做的建檔措施和目標在公司範圍內，比起預防行動更可以有效地得到貫徹和實現。那麼，企業需要如何著手才能跟上這一變化？


中文漢字的迷思：
preventive action = 預防行動、預防措施；預防未發、未然防止
corrective action = 改正行動、矯正措施；防止再發、再發防止
ensuring: 保障、保證，保障比保證好
stakeholder: 利害關係人，利益關係人 (有點樂觀)

另類應得之戰，須 (must)、應 (shall)、得 (should)、宜 (may)

英文	中文	使用時機與文件類別	說明
must	必須、須	法遵性，法令、技術法規 (technical regulation)	法律方面的強制性，一般可能涉及刑事侵權行為。
shall	必須、須	強制性，標準 (standards, specifications)	公共利益為，一般可能涉及民事侵權行為，
should	應該、得	建議性、指南、指引 (guides, guidelines)	屬於可以增加競爭力或者競爭優勢的項目。
may	可以、宜	自願性、選擇性，手冊 (handbook)	屬於方便作業，提高觀感與印象的項目。

只有實際參與標準、邀標書 (RFP)、計畫書 (proposal, program plan)、系統需求文件 (SRD)、ABC 規格書、測試程序書 (SIP)、作業程序書 (SOP)、紀錄、報告等文檔的人，才能體會這些字眼背後的酸甜苦辣。格局與視野，本體論 (ontology) 與分類學 (toxanomy) 的內涵與實踐，大家加油吧！


S. Bradner (1997), Network Working Group, Harvard University
Request for Comments 2119

• MUST is equivalent to REQUIRED and SHALL indicating that the definition is an absolute requirement.
• MUST NOT is equivalent to SHALL NOT and indicates that it is an absolute prohibition of the specs.
• SHOULD is equivalent to RECOMMENDED means that there are valid reasons to ignore a particular requirement, but the implications need to be weighed.
• SHOULD NOT and NOT RECOMMENDED means that a particular behavior may be acceptable or useful, but again, the implications need to be weighed.
• MAY means OPTIONAL and that the requirement is truly optional. Interoperability with different systems that may or may not implement an optional requirement must be done.
  

對於低至合理務實風險 (ALARP) 的詮釋，英國健康與安全執行署 (UK Health and Safety Executive, HSE) 網站的圖示說明，算是較為清楚易懂之一（如下圖）。滿意、接受、容忍、拒收之間如何拿捏，是一種技術、也是一種種藝術！



機率值如何決定？習慣上採取回歸週期倒數，一個週期一次的概念。
無法接受個人致命風險準則：每年千分之一。
可容忍個人致命風險準則：每年百萬分之一。