QC PM cause effect diagram

要因分析法(魚骨圖)介紹與實際案例

陳仲和 2018/12/31 00:05:01
22814

要因分析法(魚骨圖)介紹與實際案例


簡介

要因分析法是用圖解展示一定事件的各種原因的方法,是由日本石川馨創立的因果模型圖。它常用於產品設計,來顯示某個總體效果的可能因子。是品管七大手法中的一項。本文除介紹其方法之外,並以本身專案執行時實際案例來輔助說明。

作者

陳仲和


一、方法介紹

       要因圖(Case and Effect Diagram)又稱為魚骨圖,為日本人石川馨提出的品質管理方法,主要是用在工廠品質管理出問題時,藉由分析手法找到問題的主要原因,進而提出改善方式,是品管七大手法中的一項。石川圖常用在產品設計、或是生產質量管理或失效預防,以識別造成問題的所有潛在因素。此方法已問世六十多年了,算不上是新東西,卻是非常實用的工具,初期是只有在工廠品管上使用,之後發展成各行各業,各式各樣的議題皆能運用,即使是到現代的高科技產業,此一手法也是普遍運用中,個人第一次在實際案例運用上,便是在甲方公司,由全球第一半導體製造公司轉到我們公司的同仁帶來的觀念所介紹。我們部門是MES部門,常常要面對廠方的壓力,在系統品質穩定性與可處理時間非常要求,故常藉由此方法釐清各種問題,進而推估可解決的方案。

二、使用步驟

1.    提列問題(魚頭)

       首先要將要討論的問題或議題列於畫面的右邊,我們稱之為魚頭,魚頭記得列的不是方法,而是問題,所以在描述上愈直白愈好,或許在問題列出時會讓與會人員有些          不堪,但也是藉由問題提出能讓人員直視問題,並藉此宣示務必處理問題的決心,故問題是愈簡單明瞭愈好。

2.    問題面向分類(中魚骨)

       面向的提列非常重要,因為會引導人員思考的方向,故提列出好的分類是此手法成功與否的關鍵,常用的方法有

       5M1E或是8M(製造質量管理)

     每一個不完美的原因都是變異的來源。若在問題分析中,多半會將原因分為幾個類,以識別其變異的來源。常見的分類為「人機物法環測」,英文簡稱為5M1E

  • 人(Man):和此一製程有關的所有人員。
  • 機(機器,Machine):進行此製程需要的設備、電腦等相關工具。
  • 物(物料,Material):生產成品需要的原材料、零件、紙、筆等物品。
  • 法(方法,Method):製程進行的方式,以及進行時需要的特定需求,像是政策、程序、規定、標準及法規等。
  • 環(環境/媒介,Environment/Medium):製程運作時的條件,例如地點、時點、溫度、溼度或是文化等。
  • 測(測量,Measurement):在此製作過程所產生,用來檢查品質的資料,也包括測量用的儀器。

      也有些是用上述的五個M再加上以下的三個M,成為8M

  • 任務(Mission/環境(Mother nature):有包括內部(任務)環境或外部(任務)環境。
  • 管理(Management/財力(Money power
  • 維護(Maintenance

另外在行銷上常用的分類為8P

  • 產品(Product)
  • 價格(Place)
  • 促銷(Promotion)
  • 人員(People)
  • 流程(Process)
  • 實體環境(Physical Evidence)
  • 包裝(Packaging)

3.    問題提列(小魚骨)

       可依照分類方式請與會人員列出針對此分類可能遇到的問題,或是將以收集的問題提列到各個分類上,等到提列完畢後就是標記權重,通常重要的問題解決或是改善之後,問題也將迎刃而解。

 

、實際案例

       本部門小組今天八月剛接手公司ERP新功能開發,因本系統已上線系統,交付新功能上線時須配合權責單位安排可停機上線時間,交付需新增與修改資料庫SQL,故內容的正確性與時間把握便變成相當重要。初期時便因為上線步驟的不夠完善而時有問題發生,導致因問題釐清與修正問題造成上線的時間成本增加,並讓負責協助更新SQL的主管浪費很多時間配合更新,造成主管的不便。故小組人員重新檢討問題原因,先統計問題發生的項目有哪些?接著採用心智圖工具XMind來繪製魚骨圖,將問題的題目問項列於右側當作魚頭,以四M(Man, Machine, Material, Method)繪製中魚骨當作問題面向的分類,再將已收集的問題當作小魚骨分類列於中魚骨上,之後同仁開始討論每個問題並標示權重,找出重要的問題之後最後便是針對重要問題開始討論與提供解決方案,並呈報給權責主管獲得同意後著手進行改善,之後順利降低問題出錯的頻率,有效提高上線品質,結束此一議題的再發生。以下列出處理過程供參考:

2.      要因圖(魚骨圖)分析

以人、機、料(SQL程式) 、法(規則)四個面向列出各個面向所發生的問題,並以星號顏色代表問題影響嚴重程度,紅(最嚴重)////(最輕微)色表示,分析圖如下

 

3.      影響原因對應策略,依嚴重程度排列

3.1.     紅色星號

l   交付的SQL沒有經過測試(不能以開發DB測試,因開發環境與正式DB不同)

l   交付的程式沒有測試環境可測試(不能以開發環境測試,因開發環境與正式環境不同)

l   無測試DB供交付SQL測試執行

l   無測試網站供QA測試功能網頁

此四項影響原因皆可利用建置測試DB與測試網站之後獲得有效解決。

3.2.     黃色星號

l   沒有好的備份SQL習慣

提供雲端硬碟空間要求人員備份到雲端,另透過測試網站測試上版程式,也可提早發現SQL短缺問題。

3.3.     藍色星號

l 交付Insert SQL沒有考慮到Foreign Key順序問題

加強人員ER觀念,另透過測試DB測試上版SQL,也可提早發現SQL錯誤問題。

3.4.     綠色星號

l   沒有先以Use DB schema指定instance

l   沒有檢查SQL裏是否有工具產生的多餘贅字

交付前透過另一位同仁交互檢查,另透過測試DB測試上版SQL,也可提早發現SQL錯誤問題。

3.5.     灰色星號

l   人員語法不熟

透過整理SQL注意事項,教育訓練已發生案例的方式讓同仁在準備SQL時有自我防衛,自我檢查SQL Statement的意識

 

4.    結論

分析後得到的優先處理順序如下

4.1.     建置測試DB供交付SQL Statement前做SQL測試(待處理)

4.2.     建置測試環境供上版前做網頁執行測試(待處理)

4.3.     提供雲端硬碟空間備份準備上版SQL(已處理)

4.4.     錯誤案例教育訓練(本週執行)

其中建置測試環境的部分將與同仁協調,未來交付SQL前都須到測試DB執行,確保測試DB與正式環境Table Schema的版本一致性,以利問題的追蹤。

 
 
陳仲和