故障樹分析(Fault Tree Analysis, FTA)

故障樹分析或失效樹分析(Fault Tree Analysis, FTA):為品質改善工具之一﹐以某一失效模式為起點﹐此即為故障樹或失效樹之樹根。其後﹐各種可能的原因漸次加入故障樹中﹐形成所謂的故障樹。

 

Fault tree analysis

In the technique known as “fault tree analysis”, an undesired effect is taken as the root (‘top event’) of a tree of logic. Then, each situation that could cause that effect is added to the tree as a series of logic expressions. When fault trees are labelled with actual numbers about failure probabilities, which are often in practice unavailable because of the expense of testing, computer programs can calculate failure probabilities from fault trees.

 

 

A fault tree diagram

The Tree is usually written out using conventional logic gate symbols. The route through a Tree between an event and an initiator in the tree is called a Cutset. The shortest credible way through the tree from Fault to initiating Event is called a Minimal Cutset.

Some industries use both Fault Trees and Event Trees (see Probabilistic Risk Assessment). An Event Tree starts from an undesired initiator (loss of critical supply, component failure etc) and follows possible further system events through to a series of final consequences. As each new event is considered, a new node on the tree is added with a split of probabilities of taking either branch. The probabilities of a range of ‘top events’ arising from the initial event can then be seen.

Classic programs include the EPRI (Electric Power Research Institute)’s CAFTA Software which is used by almost all the Nuclear Power Plants in the US and by a majority of US and international aerospace manufacturers and the Idaho National Laboratory‘s SAPHIRE, which is used by the U.S. government to evaluate the safety and reliability of nuclear reactors, the space shuttle, and the International Space Station.

Unified Modeling Language (UML) activity diagrams have been used as graphical components in a fault tree analysis.


 

Categories of Legitimate Reservation, CLR

Categories of Legitimate Reservation, CLR, 台灣有譯作 “分類合理存疑” 或 “合法保留分類原則”者﹐兩種翻譯都讓人摸不著頭腦!

邏輯樹是TOC工具的主幹﹐包括Current Reality Tree (現況樹)﹑Future Reality Tree(未來樹)等﹐這些邏輯樹的成功關鍵﹐在於確實可靠的邏輯推理﹐CLR則就是用來確保邏輯樹的邏輯可靠性!針對各種因果關係之推理, 以CLR 之原則加以檢驗, 能通過檢驗者方能確認因果關係。根據上述說明﹐版主認為 CLR 譯作 “(邏輯)合理性檢驗原則” 較為平易近人!

CLR 八大檢視項目﹕

  1. Clarity: 陳述之明確性﹐對問題的陳述不夠明確﹐使後續的分析與討論往往連要面對的問題都各說各話﹐遑論得到可行的結論。因此必須檢視問題陳述的明確性。
  2. Entity Existence: Entity是TOC邏輯樹的元件﹐Entity Existence則檢視其存在性﹐Dettmer以完整句子﹑非複合句及確實內容三項檢驗Entity Existence。
  3. Causality Exisgtence: 檢視兩個Entity間確實存在因果的邏輯關係。
  4. Cause Insufficiency: 檢邏輯關係的視因果關係之中﹐所列原因之充分性(sufficiency)。若所列出之單一要因無法單獨產生所列的結果(如可燃物無法單獨燃燒)﹐則須將其餘所需之要因列出(如氧氣與燃點)﹐此一群要因共同滿足了要因之充分性要求。
  5. Additional Cause: 是否遺漏了其他造成結果的獨立要因(independent causes)?
  6. Cause-Effect Reversal: 因果倒置是常見的邏輯錯誤﹐其中又以將現象(indication)錯當原因為常見。(例如”我發高燒﹐所以我感冒了”此一說法有邏輯上因果倒置的錯誤)
  7. Predicted Effect Existence: 預期結果檢視﹐此檢視之目的在於確認一隱諱之要因的存在﹐例如天文學家無法直接觀察到未知星球﹐乃透過已知星球運行軌道的偏移﹐協助他們找到未知星球之位置﹐並以天文望眼鏡直接觀測之。
  8. Tautology: 又稱為Circular Reasoning, 較常見於口語對話之中﹐在TOC的邏輯樹中不會出現﹐更不會以圖形的方式出現。

參考資料﹕
Breaking the Constraints to Wrold-Class Performance by H. William Dettmer

Entity Existence,

Entity Existence 是 CLR 檢驗原則之一﹐有譯作實體存在性者﹐但實質內涵則無法由字面上瞭解。說明如下﹕

Entity(實體)是邏輯樹的構成基本元素﹐在邏輯圖中圓角之矩形內涵文字表示﹐在吾人檢視Entity間的邏輯關係之前﹐不妨檢視Entity之存在(?)。

Dettmer提出了三個檢視準則﹕

  1. 文句完整﹕至少包含了主詞與動詞才是完整的句子﹐必要時還可加上受詞。
  2. 非複合句(Complex Sentense)﹕複合句常暗藏因果關係在其中﹐卻因為複合句的關係而在邏輯性的檢視中遺漏檢驗!
  3. 真實性﹕Entity內的敘述符合上述要求後﹐還要符合一般之認知﹐例如紅燈代表停止﹐綠燈代表通行等﹐違反這些一般之認知者﹐其Entity Existence將被否決。

參考資料﹕
Breaking the Constraints to Wrold-Class Performance by H. William Dettmer

Current Reality Tree, CRT, 現況樹

Current Reality Tree, 現況樹是TOC邏輯工具之一﹐可以用來找出系統現狀的核心問題(Core Problems)或核心強項(Core Strength)等﹐我們在此專注在找出核心問題之方法。簡述CRT建立之步驟如下﹕

  1. Define the Scope: 在此指我們所關心的系統﹐確認系統之目的﹐以及系統performance之量測。這系統可以是我們所服務的公司﹐所服務的部門﹐但是定義的Scope不宜過小﹐否則將有局部最佳化的隱憂。
  2. List 5~10 pertinent entities: 在以找系統核心問題為目的的CRT﹐pertinent entities是指系統之核心問題,又稱UDE(UnDesired Effects) 。所有妨礙系統達成其目的之問題﹐都視為UDE.
  3. Diagram the Cause-Effect Relationships: 在上述的pertinent entities間找尋因果邏輯關係﹐以此建立CRT﹐必要時得加入其餘的Entities以滿足CLR之邏輯性要求。
  4. 以CLR確認CRT之邏輯因果關係。
  5. 待續

Evaporating Clouds = Conflict Resolution Diagram, 衝突圖

Evaporating Clouds (或 Conflict Resolution Diagram)是TOC Thinking Process Tools之一。

 

企業運作﹐最困擾的莫過於兩個單位間的衝突﹐常見其上級單位的做法是尋求雙方都勉強接受的妥協之道。

 

TOC的創始人Dr. Goldratt尋求更有創意的雙贏的做法﹐稱之為Evaporating Clouds或Conflict Resolution Diagram﹐簡稱EC或CRD﹐翻譯成撥雲見日的衝突圖極為傳神。

 

EC或CRD與其他幾個邏輯工具有一個較大的差異﹐它有固定的五個Entities﹐而其他的FRT, CRT等﹐它們的Entities數量不固定﹐相互關係也不各有不同。下圖是EC的簡單範例﹕

 

 

最右側上下兩Entities代表相互衝突的兩項需求或計畫的行動﹐這兩個衝突是為了滿足各自的需求﹐更重要的是﹐不同單位間有一個共同的目標(Objective)﹐EC的主要功能在於協助管理者找到衝突背後的共同目標。

 

也有些採用直立式的衝突圖﹐如下例﹕

 

 

EC衝突圖之建構﹕

  1. 以相互衝突之D及D’為起點﹐這也是大家關注的焦點﹐兩者之需求相反且無法共存。
  2. 找出D及D’對衝突雙方所以”必須”的原因﹐填入B及C兩個Entities中。
  3. 最後要找到衝突雙方的共同目標﹐填入A Entity中。
  4. 最後修飾字詞﹐並確認各Entities間之邏輯關係。

 

參考資料﹕

  1. Thinking for a Change; Putting the TOC Thinking Processes to Use (by Lisa J. Scheinkopf)
  2. Goldratt’s “Theroy of Constraints” Thinking Processes: A Systems Methodology linking Soft with Hard. (by Victoria Mabin)

Future Reality Tree, 未來樹

Future Reality Tree﹐未來樹是TOC Thinking Process Tools之一。

當我們透過EC找到衝突背後的共同目標之後﹐吾人即可著手建構FRT未來樹。建構未來樹之目的在於檢視Injection之有效性﹐並確認其對系統無任何負面衝突﹐必要時得加入新的Injection以避免任何負面衝擊(Negative Branch)。因此﹐FTR亦可視為對Negative Branch之修剪工作。

FTR之建構始於Injection﹐終於Desired Effects (相對於CRT的 UDE, UnDesired Effects)﹐以Bottom-up的方式依序建構。

FTR之建構﹐應特別注意Positive Reinforcing loops的系統的正面強化效應。

資料待補充。

參考資料﹕

  1. Thinking for a Change; Putting the TOC Thinking Processes to Use (by Lisa J. Scheinkopf)
  2. Goldratt’s “Theroy of Constraints” Thinking Processes: A Systems Methodology linking Soft with Hard. (by Victoria Mabin)

PreRequisite Trees, PT, 條件樹

PreRequisite Tree, PRT, 條件樹是TOC Thinking Process Tools之一。

Goldratts認為尚未施行之構想(idea)不能稱為對策(Solution)﹐而PRT在於找出導入Injection 之障礙﹐同時與EC相同採用所謂Necessity Logic 或 Necessary Conditon Thinking﹐而FRT, CRT等則採所謂Sufficiency Logic。

根據所面對問題的複雜程度﹐吾人可以選擇是否需要採用 PRT﹐基本上對於非常簡單的工作﹐Just Do it! 不需要過度謹慎﹐反之對於較複雜的問題﹐PRT就有必要﹐至於複雜程度在兩者之見的問題﹐可以直接用 Transition Tree來協助任務之達成。

待續。

參考資料﹕

  1. Thinking for a Change; Putting the TOC Thinking Processes to Use (by Lisa J. Scheinkopf)
  2. Goldratt’s “Theroy of Constraints” Thinking Processes: A Systems Methodology linking Soft with Hard. (by Victoria Mabin)

TOC constraint

TOC將系統限制(system constraints)分成三種﹕

  • paradigm constraint: 又稱 behavioral constraint, 是屬於思惟層次的系統限制﹐例如過去被視為理所當然的大量生產系統﹐認為可藉此降低成本的思惟就是許多企業無法跨越的限制。
  • policy constraint: 又稱 managerial constraint﹐是指企業運作的一些規則與管理指標(Rules and Measures)﹐許多企業狀似採用正確的思惟﹐但因採用了不相干甚至背道而馳的管理指標﹐例如有些企業直些要求採購單位降價25%作為因應金融風暴之道﹐並以此作為採購單位的績效指標﹐其下場可以預料!
  • phisical constraint: 又稱 logical constraint, 主要是指那些資源上的限制﹐例如製程上某製程的產能不足﹐某材料的供應不足﹐某段時間的供電不足等。針對此類的系統限制﹐Dr. Goldratt提出了TOC五大步驟﹐請網友參考。

至於這三種系統限制的相對關係﹐paradigm constraint 會產生 policy constraint, 但是正確的paradigm 不保證不會有policy constraint﹐同時phisical constraint與policy constraint間也有類似的關係。

參考資料﹕

1. Thinking for a Change; Putting the TOC Thinking Processes to Use (by Lisa J. Scheinkopf)

The 40,000′ Perspective, The Value Chain Box

面對複雜問題的時候﹐Scheinkopf 的建議是站在更高的高度﹑更廣的視角去觀察﹑更大範圍去觀察系統﹐他稱此為 40,000′ perspective (四萬英呎的視野)﹐將系統看成一流動的製程(flow)﹑一價值鍊黑盒子(Value Chain Box)﹐建議網友們可以用更大的格局去面對問題。

參考資料﹕

1. Thinking for a Change; Putting the TOC Thinking Processes to Use (by Lisa J. Scheinkopf)

Root Cause﹐根由

大部分有實務經驗的朋友都知道﹐要徹底解決問題﹐必須先找到所謂的根由(Root Causes)。

有所謂5 Why找根由的方法﹐透過追根究底的精神﹐像剝洋蔥似的找到問題的核心﹐然則追朔到何處方能停止呢?

簡單的說,凡有影響力的範圍內都要追根究柢,直追到無影響力的邊界為止。

例如,我們在 Root Causes Analysis,根本原因分析 中所說明的就是最好的範例。

又如我們可能在某些情況下,歸咎於作業人員的能力不足甚至智能不足,這就不是我們要追究的領域,但訓練不足則是我們有能力改變的!