應用PDCA 管理循環在半導體製造工程上之重大異常處置管理系統

國立交通大學

資訊學院 資訊學程

碩 士 論 文

應用 PDCA 管理循環在半導體製造工程上之重

大異常處置管理系統

Application of PDCA management cycle in the semiconductor

manufacturing project management system for the disposal of

major anomalies

研 究 生：鄭琨耀

指導教授：袁賢銘 教授

應用 PDCA 管理循環在半導體製造工程上之重大異常處置管理系統

Application of PDCA management cycle in the semiconductor

manufacturing project management system for the disposal of major

anomalies

研 究 生：鄭琨耀 Student：Kun-Yao Cheng

指導教授：袁賢銘 Advisor：Dr. Shyan-Ming Yuan

國 立 交 通 大 學

資訊學院 資訊學程

碩 士 論 文

A Thesis

Submitted to College of Computer Science National Chiao Tung University in partial Fulfillment of the Requirements

for the Degree of Master of Science

in

Computer Science July 2009

Hsinchu, Taiwan, Republic of China

應用 PDCA 管理循環在半導體製造工程上之重大異常處置管理系統

學生：鄭琨耀

指導教授：袁賢銘

國 立 交 通 大 學 資 訊 學 院 資 訊 學 程 碩 士 班

摘

要

2008 年全球陷入金融風暴的漩渦中，各企業公司不斷尋求降低營運成本， 以提高公司營運的競爭力。在各方面的營運成本中，以生產成本的降低所帶來的 效益為最大。尤其是對於半導體公司而言，晶圓製造技術的生產成本降低，足以 決定該半導體公司的長久獲利與永續經營的關鍵之一。對於生產成本的降低範 圍，除了提升製造過程的正確性與最高效率外，也應該涵蓋品質異常所衍生出的 製造損失與成本支出。後者異常狀況的確實修正與異常再發防堵，更可以進一步 提升生產製造的最高效率。 本研究主要是針對重大異常發生後所衍生的相關處置作業流程，建置出一套 基於 PDCA 品質管理作業程序的電子化平台。協助落實重大異常 MRB 會議之 招開、Action 管理追蹤與異常處理知識庫建構，如此可提升重大異常處置之紀 律、效率，進一步達到降低再發率。同時也幫助因客訴問題所產生的廠內對應矯 正作業之追蹤管理，如此便可提升客戶服務品質。另外也記錄了產品 Lot 的異 常品處置方式，提供了未來經驗的學習。再者建構出重大異常損失與成本資訊的 完整記錄，可直接協助決策資源的管理，提升公司的競爭力。

Application of PDCA management cycle in the semiconductor

manufacturing project management system for the disposal of major

anomalies

Student: Kun-Yao Cheng

Advisor: Dr. Shyan-Ming Yuan

Degree Program of Computer Science

National Chiao Tung University

ABSTRACT

In 2008 the global financial crisis into a whirlpool, a constant search for the enterprise to lower operating costs in order to enhance the competitiveness of the company's operation. In all aspects of operating costs in order to reduce the production cost benefits for the largest. Especially for semiconductor companies, wafer fabrication technology to reduce production costs enough to determine the semiconductor company's long-term profit and one of the keys to sustainable development. Lower production costs for the scope, in addition to enhancing the accuracy of the manufacturing process with maximum efficiency; it should also cover the quality derived from abnormal loss of manufacturing costs. The latter situation is indeed unusual to amend and re-issued protective, but also to further improve manufacturing efficiency.

The purpose of this study is a major anomaly derived after the operations related to the disposal process, build a set of quality management based on the PDCA operating procedures of the e-platform. Assist in the implementation of major strokes and abnormal opening of the MRB meeting, Action management tracking and exception handling knowledge base construction, and so enhance the disposal of a significant abnormality of discipline, efficiency, and further to reduce the rate of recurrence. At the same time help customers v. corresponding generated by the factory management to correct operation of the track, so they will be able to enhance the quality of customer service. Products also recorded abnormal Lot Disposal of goods, provision of learning experience for the future. Furthermore, construction of a significant abnormal loss of information and a complete record of the cost of direct resources to assist management decision-making to enhance the competitiveness of companies.

謝誌

首先我要感謝袁賢銘教授給我的指導，在我的研究領域裏給我很多寶貴的意 見，並且給予我最大的空間來發揮我的創意。在老師許多精闢且獨到的研究思維 下，激盪出我不同的思考方向，讓我更能發掘出問題的癥結，確實讓我獲益良多。 還要感謝的是，本公司的部門協理黃國助先生、課長錢啟華小姐，在我 2005 年 9 月入學交通大學研究所後，經常主動表達關懷之意。並且在時間方面給予最 大的彈性空間與自主權，好讓我能配合學校不同的時段的課程需求。另外在 2005 年底，我和同部門的協理董韶惠小姐與技術協理黃衛聖先生一同進行公司重大異 常管理系統的需求訪談與系統建置。專案進行期間提供了相當多的想法激盪、設 計建議與協助，對我的論文內容的撰寫助益良多，特此，表達致謝之意。 最後，我要感謝家人與我老婆的全力支持，鼓勵我繼續升學研究所。他們在 我背後默默的祈禱與為我加油，讓我感到精神上無比專注。有了家人的支持，實 在是我繼續升學並完成碩士學位的原動力。

目錄

中文摘要 ... i

英文摘要 ... ii

謝誌 ... iii

目錄 ... iv

圖目錄 ... vi

表目錄 ... vii

一、 緒論 ... 1

1.1 研究背景與動機... 1 1.2 研究目的... 1 1.2.1 研究步驟... 2 1.2.2 研究流程... 2

二、 背景與相關研究 ... 4

2.1 背景... 4 2.1.1 PDCA 品質管理循環 ... 4 2.1.2 MRB 定義 ... 5 2.1.3 CAR 定義 ... 5

三、 系統架構 ... 7

3.1 系統概要... 7 3.2 相關研究... 7 3.2.1 MVC Design Pattern ... 7

3.3 Plan - MRB 系統模組 ... 8

3.4 Do - Meeting Management 與 Suffer Lot Maintain 系統模組 ... 8

3.5 Check - Action Tracking 系統模組 ... 9

3.6 Act - CAR Request 系統模組... 9

四、 程式開發詳述 ... 10

4.1 概述... 10

4.2 軟體設計架構... 10

4.3 系統分析設計... 10

4.4 MRB Module ... 13

4.5 Meeting Management Module ... 14

4.6 Suffer Lot Maintain Module ... 16

4.7 Action Tracking Module ... 17

4.8 CAR Request Module ... 19

4.9 軟體平台與程式工具庫... 21

五、 研究結果與比較 ... 22

5.1 研究結果... 22 5.1.1 上線後的功能變更歷程... 22 5.1.2 MRB 再發率數據比較 ... 22 5.1.3 MRB 使用率數據比較 ... 24 5.1.4 MRB 處置回應時效比較 ... 24 5.2 滿意度調查... 25

六、 未來工作與結論 ... 26

6.1 未來工作... 26 6.2 結論... 27

參考文獻 ... 28

附錄一 ... 32

附錄二 ... 66

自傳 ... 67

圖目錄

圖 1 戴明循環... 4

圖 2 PDCA 循環 ... 5

圖 3 修改後的 PDCA 循環 ... 7

圖 4 Process flow of MRB system ... 10

圖 5 Use case diagram of MRB system ... 11

圖 6 Component diagram of MRB system ... 11

圖 7 Activity diagram of MRB system ... 12

圖 8 State chart diagram of MRB system ... 13

圖 9 MRB Database schema ... 14

圖 10 MRB 立案功能的序列圖 ... 14

圖 11 Meeting Management Database schema ... 15

圖 12 MRB 會議紀錄維護的序列圖 ... 16

圖 13 Suffer Lot Maintain Database schema ... 16

圖 14 Suffer Lot 資料上傳的序列圖 ... 17

圖 15 Action Tracking Database schema ... 18

圖 16 Action 新增維護的序列圖 ... 18

圖 17 Action 回覆的序列圖 ... 19

圖 18 CAR Request Database schema ... 20

圖 19 CAR 表單填寫的序列圖 ... 20

圖 20 系統上線前後滿意度比較圖... 25

表目錄

表 1 MRB 模組的資料表概要 ... 13 表 2 Meeting Management 模組的資料表概要 ... 15 表 3 Meeting Management 模組的資料表概要 ... 16 表 4 Action Tracking 模組的資料表概要 ... 17 表 5 CAR Request 模組的資料表概要 ... 19 表 6 軟體平台與程式工具庫... 21 表 7 系統上線後功能變更歷程... 22 表 8 系統上線前 MRB 重覆發生比率 ... 23 表 9 系統上線後 MRB 重覆發生比率 ... 23 表 10 系統上線前 MRB 處理回應時效 ... 24 表 11 系統上線前 MRB 處理回應時效 ... 25 表 12 MRB 立案功能詳述 ... 32 表 13 MRB 會議紀錄維護 ... 38 表 14 Suffer Lot 資料上傳 ... 42

表 15 Suffer Lot Excel 資料轉入共用模組 ... 43

表 16 Suffer Lot 資料上傳 ... 46

表 17 Suffer Lot Excel 資料轉入共用模組 ... 47

表 18 Action 新增維護 ... 50 表 19 Action 回覆 ... 54 表 20 CAR 表單填寫 ... 57 表 21 CAR 共用顯示資料模組 D0-D3 ... 59 表 22 CAR 共用顯示資料模組 D4-D7 ... 63 表 23 使用者滿意度調查表... 66

一、 緒論

本論文主要的目的係將重點放在有關於半導體 P 企業如何採用以 PDCA 品質管理循環作業方法所建置的重大異常管理系統。本章首要闡明本論文的研究 背景與動機、提出本論文之主要目的，進而建立本論文之研究架構與研究流程之 設計。

1.1 研究背景與動機

2008 年全球陷入金融風暴的漩渦中，各企業公司不斷尋求降低營運成本， 以提高公司營運的競爭力。在各方面的營運成本中，以生產成本的降低所帶來的 效益為最大。尤其是對於半導體公司而言，晶圓製造技術的生產成本降低，足以 決定該半導體公司的長久獲利與永續經營的關鍵之一。對於生產成本的降低範 圍，除了提升製造過程的正確性與最高效率外，也應該涵蓋品質異常所衍生出的 製造損失與成本支出[8][12]。後者異常狀況的確實修正與異常再發防堵，更可以 進一步提升生產製造的最高效率。如此，改善帶來了新的作業標準，新的作業標 準不久又成為下一階段的改善目標，這樣的改善過程，便如此循環而止於至善 [1][2]。異常發生次數減少了，自然而然提升了產品品質，相對的也提升了客戶 的滿意度[6]。 本論文即是針對重大品質異常狀況的所有相關活動提出以 PDCA [2] [3]管理 循環方法所實作的電子化系統平台。以下章節說明為何需要建立此一電子化系統 平台，以及此管理平台所應有的功能。還有它所需要面對的問題與各問題的解決 方法。

1.2 研究目的

本研究主要是針對重大異常發生後所衍生的相關處置作業流程，建置出一套 基於 PDCA 品質管理作業程序的電子化平台[5]。具體而言，本研究的目的如下： 1. 協助落實重大異常 MRB 會議之召開、Action 管理追蹤與異常處理知識庫建 構。如此可提升重大異常處置之紀律與效率，進一步達到降低再發率[3]。 2. 幫助因客訴問題所產生的廠內對應矯正作業之追蹤管理，如此便可提升客戶 服務品質[6]。 3. 記錄產品 Lot 的異常品處置方式，提供了未來經驗的學習。 4. 建構出重大異常損失與成本資訊的完整記錄[10]，可直接協助量化嚴重程 度，以焦距管理重心，並協助決策資源的管理[11]。

1.3 研究步驟與流程

1.3.1 研究步驟

本研究是藉由深入訪談的方式，以了解當初晶圓生產發生異常時，如何進行 改善程序動作的現況以及其特徵要素。接著針對公司各生產單位與品質管制部 門，以直接深度訪談相關人員所陳述而觀察到的現象，以及各種異常報告與資料 的蒐集方式，來分析與了解到公司重大異常的真實運作情形。進而分析推導出本 研究的發現與結論。最後提出建置遵循 PDCA 品質管理流程的重大異常電子化 系統，以及此系統所能帶來的管理決策效益。

1.3.2 研究流程

本研究的主要開發時間為期十個月，期間與另外兩位公司同事一起進行需求 訪談、系統分析與設計工作。起先在 2005 年十二月開始進行目的與效益分析。 之後再進行一個月的企業作業流程改造，在此階段我們明訂了公司未來皆頇遵循 的重大異常管理作業程序規範。有了規範後便針對細節流程的系統化進行各單位 人員需求訪談作業，為期一個月。之後將這些訪談需求設計出以 PDCA 管理循 環中心精神的管理系統。最後在 2006 年三月份開始進行系統開發作業，並於同 年九月上線服務。本研究之細項流程如下所示： 1. 研究動機與目的：如 1.1 與 1.2 節所列之內容。 2. 文獻蒐集與探討：本研究透過公司過往發生之重大異常後所提出的各單 位研究報告預防矯正措施報告並加以分析與了解。 3. 深度訪談：本研究針對公司相關負責人員作深入的訪談，充分了解各單 位對公司內對發生重大異常時的看法與建議。並加以分析整理各單位所 提供之研究報告與文獻作歸納比較，詴圖找出一個足以貫穿相關品質系 統的主軸，進而推導出一個新的融合之系統執行模式。以作為最後之結 論與建議之重要參考依據。以下節錄訪談相關人員所收集到的建議與看 法： (1) MRB 案件成立與否都是需要經過開會決定，並且會議中所做出的 各種必要處置與結論都必頇要被追蹤與紀錄。其中會議的召開次數 會視實際需要異常是否已經解決而召集。 (2) MRB 案件中影響的 Lot 需要確實透過系統紀錄與追蹤，最好能夠 實作為由 MRB 系統快速且自動的扣留住產品，以免出錯壞品給客 戶。 (3) 每個 MRB 案件都必頇要有 CAR 的報告才能算是結案。並且 CAR 報告中所提到的預防矯正措施都必頇要歸檔執行。以及進行矯正措 施執行結果的稽核查驗作業。 (4) MRB 案件能夠估算實際失敗金額，可聚焦異常發生的嚴重性與決 策判斷依據。 4. 分析輔助系統：針對先前的輔助管理系統以及稽核管理系統，檢討實務

運用時兩系統之間的關聯與作業流程。發現先前的輔助管理系統無任何 強制力管制異常發生單位的矯正作業落實。並且再稽核管理系統上，亦 無完整的異常矯正報告記錄以便做後續生產矯正作業已被確實更正。 5. 系統設計與撰寫並提出研究報告、建議與結論。

二、 背景與相關研究

2.1 背景

2.1.1 PDCA 品質管理循環

PDCA 循環，就是由 P 計畫（Plan）、D 執行（Do）、C 查核（Check）及 A 處置（Action）四大步驟過程所構成的一連串追求改善的行動，亦有人稱為「戴 明循環」（Deming Cycle）或「戴明轉輪」（Deming Wheel）[16]。

戴明循環是戴明博士（W. Edwards Deming）在西元 1950 年受邀於日本講習 時所介紹的一項管理理念，最初應用於品質管理，爾後擴及企業各階層的管理思 維及行動上，經由不斷的改進而成為如今的面貌。最早的戴明循環分為設計、生 產、銷售、研究四個階段（如圖 1）。之後日本人將其中的改善觀念與管理功能 的觀念相結合（如圖 2），修改為 PDCA 循環，以便適用於各種狀況。PDCA 循 環是提高產品品質，改善企業經營管理的重要法則，同時也是品質保證體系運轉 的基本方法。 圖 1 戴明循環 戴明循環與ＰＤＣＡ循環兩者的對應：  設計→計畫：產品的設計相當於管理的規劃階段。  生產→執行：產品的生產、製造相當於管理的實行階段。  銷售→查核：從測詴產出良率結果可以看出執行成效。  研究→處置：萬一發生異常仍舊發生的情況，就應該在下一個階段規劃 時加以考慮，並據以採取適當的措施。

圖 2 PDCA 循環

2.1.2 MRB 定義

MRB 的全名是 Material Review Board，意思是指物料審查會議。它是針對 所有檢驗工作站點，發現產品異樣狀態但是讚時不能確定是否為缺陷異常的一種 處理作業。這邊指的工作站點包括了進料檢驗、過程檢驗、出貨檢驗以及可互退 回的產品檢驗。根據不確定的缺陷發現的位置，MRB 會議可以由不同的負責單 位召集。比如在進料檢驗過程中發現原物料有異常而該檢驗工程師不能確定時， 他可召集 MRB 會議。MRB 會議中可邀請專案經理、採購工程師，製造工程師 參與。如有必要也可以邀請品質經理和生產經理加入，已加速問題的釐清與解 決。透過 MRB 會議一般可以得到以下幾點結論：1. 繼續使用該原物料；2. 需 要重新評估後使用；3. 報廢；4. 退回供應商並要求換貨。MRB 召開會議重點是 能使相關的人在第一時間知道問題的存在，並且能加速該問題的解決。 本論文所參考的半導體 P 企業便是採用 MRB 的管理方式，運用於當遭遇重 大產品異常，針對異常產品的處置以及問題發生原因的找尋，一直到問題的預防 再發，所召開的風險管理會議。

2.1.3 CAR 定義

CAR 的全名是 Corrective Action Report，意旨針對企業內部某一發生的異 常，所對應之矯正措施報告。CAR 為加強企業的有效管理，找到企業異常問題 癥結所在並防止問題再次發生，實現即時快速的自動化管理。當找到其根本原 因，作出有效解決措施並永久地矯正異常現象。所以若是召開重大異常的 MRB 會議後，最後必頇有其對應之 CAR 報告。以確定該重大異常的原因不再發生， 如此才是召開 MRB 會議最重要的工作之一。 CAR 報告內容格式主要採用福特汽車的品管報告 8D(Disciplines) [4]，其中 最後一個格式不編入 CAR 報告當中。8D 內容大致描述如下： 1. Discipline 1 (Team)：問題解決小組成員。問題的描述。 2. Discipline 2 (Problem Description)：問題的描述。

4. Discipline 4 (Root Cause)：發生問題的最主要原因。

5. Discipline 5 (Permanent Corrective Action)：永久改善措施。

6. Discipline 6 (Verification of Corrective Action Effectiveness)：驗證改善措 施之有效性。

7. Discipline 7 (Action Taken to Prevent to Reoccurrence)：預防再發處置方 式。

三、系統架構

3.1 系統概要

圖 3 修改後的 PDCA 循環 本章節主要描述本研究論文所設計的系統架構。如圖 3 中描述了 MRB 系統 主要的構成程式模組，這些模組主要是以 PDCA 的管理循環為開發的參考依據 所設計而成。主要分為五個模組，各模組之間的運作方式以下舉例說明。 當晶圓製造生產機台發生錯誤異常時，製造單位會先提出 MRB 案件會議， 會議中會討論出該案件是否構成了重大異常的條件。在 MRB 立案成立時，MRB 品管人員就可利用 Meeting Management Module 的會議通知作業召開各項案件 會議來討論相關的處置動作。並可使用 Meeting Management Module 的會議記錄 作業來登錄會議結論及連結 Action Tracking Module 的 Action 維護作業來建立會 議中各項處置並且追蹤各項處置動作之進度。而所下的處置(Action)可連結 Suffer Lot Management Module 的 Suffer Lot List 資料上傳、Lot Disposition 資料上傳及 Lot Hold/Release 等動作。在 CAR 所需的前 3D 的資訊準備完成以及所有處置動 作都完成後，MRB 品管人員便可以透過 CAR Request Module 指派 CAR 資料填 寫人員來產生 CAR 表單並驅動 CAR 流程。接著當所有 Lot Disposition 動作完成 後，即可以利用指派 MRB 成本計算人員之來驅動成本計算。最後等待 CAR 流 程客戶回覆無誤、成本計算完成以及所有 Action 都在可結案的狀態下，即可進 行 MRB 之結案動作。

3.2 相關研究

3.2.1 MVC Design Pattern

當一個應用程式混合了資料存取程式碼、企業邏輯程式碼以及顯示程式碼

時刻的原件變更都會產生連帶式許多影響。如此高度性的相關聯程式碼，也會致 使物件類別的可重複使用性變低，因為各物件總是需要依賴其他物件。當新增一 個資料表時總是需要重新撰寫或是剪貼複製企業邏輯程式。資料存取同樣也必頇 經歷同樣的問題。MVC(Model-View-Controller) [5]程式設計架構藉由降低企業邏 輯、資料存取與使用者操作介面之間的相依性，以解決上述應用程式的開發與維 護問題。

3.2.2 BorG SPM Workflow Engine

BorG SPM 博格商業流程管理系統（Services-Oriented Process Management）， 為 100% 採用 Microsoft .NET、Visual Studio 2003/2005/2008、Windows Server 2003/2008 等 新 技 術 ， 所 開 發 出 來 的 商 業 流 程 管 理 （ Business Process Management）軟體產品。

本論文中所建置的重大異常管理系統，就是藉由 BorG SPM 流程軟體來將 各處置作簽核與追蹤管理。並且系統係由 Microsoft .NET 企業解決方案所開發而 成，而 BorG SPM 同樣採用 Microsoft .NET 技術，對於系統整體開發與整合介面 而言將會更具有穩定性與彈性，如此也可加速系統開發的時程。

3.3 Plan - MRB 系統模組

計畫(Plan)階段主要是目標的訂定與評估基準，本研究就是規劃以 MRB 系 統模組來訂定重大異常所要改善的方向。使用者可以透過 MRB Module 進行 MRB 案件提報登錄。並且可以修改您所立案之 MRB 案件內容。或是取消您所 立案之 MRB 案件。還有可以藉由目前進度的功能查看 MRB 單據所有相關之流 程處理進度。此功能中，系統會協助使用者所欲查看目前進度的 MRB 單據，再 自動分析此單據之各項作業是否已進行，以及顯示相關流程之清單，可點選明細 項目來查看每一筆流程之目前處理進度。使用者也可以透過矯正預防措施功能可 查看 MRB 單據之矯正預防措施單據內容。

3.4 Do - Meeting Management 與 Suffer Lot

Maintain 系統模組

執行(Do)階段主要是確實執行計畫內容，本研究是以 Meeting Management 系統模組來條列各項經過開會討論出的執行細則。並將各執行細則分派給負責人 員。使用者可以透過 MRB 模組裡面的監控作業來驅動會議的召開以及會議紀錄 的維護作業。

本研究還以 Suffer Lot Maintain 系統模組，將那些因為本次 MRB 異常影響 的產品資訊上傳到系統記錄。以及異常產品所做的後續處置方式也一併上傳系統 記錄。若是影響的產品還在工廠生產中的話，也可以透過本模組進行產品的停止 作業。

3.5 Check - Action Tracking 系統模組

查核(Check)階段主要是在檢查執行後的結果，本研究以 Action Tracking 系 統模組來加以檢查。利用此模組可以讓生產工程單位回覆各執行細則的結果。並 且將各項執行措施與結果列入稽核管理系統的後續稽核驗證工作。

3.6 Act - CAR Request 系統模組

處置(Act)階段主要是來確認，在經過前三個階段完成後使否已經達到計畫 中的目標還是要繼續擬定並觸發另外一次的 PDCA 循環。若是已經達到原來的 計畫目標，則可透過 CAR 模組來將各執行細則與檢查結果，以及預防再發的永 久矯正報告建置到系統中。

四、 程式開發詳述

4.1 概述

本章節內容主要描述了重大異常系統的程式軟體設計架構與系統功能設計 內容。其中也包含了各系統模組的資料表設計輪廓，以及各模組所包含的資料表 以及其關聯性的說明。

4.2 軟體設計架構

本研究中所建置的重大異常管理系統的軟體開發架構系主要是遵循 MVC [45]設計模式。並且使用 Microsoft .NET 的 Web 企業解決方案所建置的網站應用 系統。如圖 4 中所示為系統程式執行流程，主要區分為邏輯層與資料存取層、顯 示層、控制層。並連結後端 Microsoft SQL Server 2000 資料庫以及 Oracle 資料庫。

在邏輯層中，我們會將各種企業邏輯判斷，數據運算或是資料交易撰寫在這 個層面的程式中。在資料存取層中則撰寫了資料存取方式的程式。在顯示層中則 為使用者操作畫面呈現以及操作邏輯設計。在控制層中，則為串連畫面之操作與 企業邏輯運算的支配管理，以便使用者能藉由畫面的操作取得正確無誤的邏輯運 算結果。也就是說，使用者透過網頁上的操作介面後，經過控制層的管理呼叫了 邏輯層上正確的企業邏輯判斷，最後再藉由資料存取層以便保存使用者的需求結 果。

圖 4 Process flow of MRB system

以下會說明本管理系統的主要功能需求。由於本系統採用 .NET 的平台開發 所以使用 OOAD 的文件說明將更可表達出系統的設計方式開發。而我們將使用 UML 的符號來表達主要的系統設計內容。圖 5 為本系統的 Use Case 圖示，其中 包含了四個主要的使用者，包含：高層主管、MRB 會議管理者、事發單位以及 負責人員。也包含了五個主要 Use Case，MRB module，Meeting management module，Suffer Lot Maintain Module，Action Tracking Module 與 CAR Request Module，以下小節將分別描述說明其程式撰寫方式。

圖 5 Use case diagram of MRB system

經過 Use Case 的說明我們可將五個 Use Case 分為五個元件，其中 CAR Request 模組會連結稽核系統，如圖 6 所示。各元件之間會有相關資訊作傳遞。 MRB 元件會傳遞 MRB 資訊給 Meeting 管理元件與 CAR Request 元件。Meeting 管理元件，則會傳遞新 Action 資訊給 Action Tracking 元件。Action Tracking 元件 則會將 Action 資訊傳給 CAR Request 元件以便完成 CAR 矯正措施報告以及提供 稽核系統相關稽核資訊做後續的稽核作業。Suffer Lot 管理元件則實現與 Action Tracking 元件相同的程式介面。

知道了系統的主要元件，我們接著來說明管理系統如何實現 MRB 的管理作 業流程。圖 7 為 MRB 系統的作業流程示意圖。首先發布 MRB 案件經過會議討 論後決定是否成立案件。確定成立後進入召開會議的階段，這個階段是可以不斷 的進行召開會議以便進行各種必需的處置。當所有處置都完成後便可進入 CAR 的作業流程。之後再確定 CAR 內容的完成後，就會進入稽核 CAR 內容的流程， 稽核完成後即是完成整個重大異常的處置作業。

圖 7 Activity diagram of MRB system

接著我們可以依據上述的作業流程定義出主要的流程狀態。如圖 8 中所示， 主要流程為 MRB 案件處置作業將會有 Initialing、Action Tracking、Action Completed、MRB Closed。在處置追蹤階段中，又可區分為三種不同的處置分別 為 Action State、CAR State 與 Meeting State。

圖 8 State chart diagram of MRB system

4.4 MRB Module

MRB 系統模組為本管理系統之初始主要功能。表 1 為此模組的資料表概要 說明，主要條列七個資料表。圖 9 則為 MRB 系統模組的資料表欄位屬性。

表 1 MRB 模組的資料表概要 Entity Name Usage

mrb_data 主要儲存 MRB 案件基本屬性。 problem_failure_mode MRB 案件發生問題的失敗模式分類。 problem_module MRB 案件發生問題的負責單位。 problem_product MRB 案件發生問題的產品類別。 problem_reason MRB 案件發生問題的原因。 affected_lot MRB 案件發生影響的 Lot。 shutdown_data MRB 案件發生後影響的機台停止生產的時間。 Cost_data MRB 案件發生後所估算的失敗成本。

圖 9 MRB Database schema MRB 系統模組中，主要是以申請 MRB 的立案申請為最開端。之後再搭配 相關功能如：MRB 進度監控作業、待處理工作追蹤、重大異常原因分析查詢等 功能以便管理 MRB 案件。以下將以圖 10 MRB 立案功能的序列圖為例，來描述 本模組的系統功能如何撰寫。本模組的其餘畫面功能都是類似此序列圖的方式撰 寫而成。 首 先 使 用 者 介 面 form_initialMrb.aspx.cs 會 呼 叫 邏 輯 層 物 件 INITIAL_MRB_BLL.cs 的 InsertMrbData 方 法 並 且 傳 入 mrb 資 料 物 件 。 在 InsertMrbData 方法中會先透過 MrbDataDAOr.cs 物件取得目前的表單單號。最後 再透過資料儲存物件 MrbDataDAOwBase.cs 的 Insert 方法，將使用者網頁介面 上所輸入的 MRB 案件儲存進入 mrb_data 資料表中。 圖 10 MRB 立案功能的序列圖

Meeting Management 系統模組為各改善措施執行的觸發點，任何異常處置 都頇先經過開會討論以決定出可行的執行辦法。表 2 為此模組的資料表概要說 明，主要條列七個資料表。圖 11 則為 Meeting Management 系統模組的資料表欄 位屬性。

表 2 Meeting Management 模組的資料表概要 Entity Name Usage

meeting_minutes 主要儲存會議召開的基本屬性。 meeting_team 會議召開的主要部門。 action_tracking 會議後處置動作的基本屬性。 action_type 處置動作的分類型態。 status_type 處置動作的執行狀態。 problem_source MRB 案件發生問題的來源。 attendant_data 會議召開的與會人員。

圖 11 Meeting Management Database schema

維護 MRB 會議記錄的功能為本模組主要的功能，以下將以圖 12 MRB 會議 記錄維護的序列圖為例，來描述本模組的系統功能如何撰寫。本模組的其餘畫面 功能都是類似此序列圖的方式撰寫而成。 首先在維護會議紀錄 m_maintainMeetingMinutes.aspx.cs 的表單中呼叫邏輯 層 物 件 M_MAINTAIN_MEETING_MINUTES_BLL.cs 的 UpdateMaintainMeetingNotice 方 法 ， 接 著 呼 叫 資 料 儲 存 物 件 MmMeetingMinutesDAOw.cs 物件的 Update 方法更新會議內容到 meeting_minutes 資料表。之後再呼叫流程處理物件 BorG_function.cs 的 SendFlow 方法觸發簽核 流程。最後再將簽核流程的處置資料透過 ActionTrackingBLL.cs 邏輯層的更新， 將簽核流程資料完成 action_tracking 資料表的同步。

圖 12 MRB 會議紀錄維護的序列圖

4.6 Suffer Lot Maintain Module

Suffer Lot Maintain 系統模組為改善措施的其中一種執行辦法。藉由此功能 來紀錄重大異常發生時候，所有影響 Lot 的處置細節。表 3 為此模組的資料表概 要說明，主要條列四個資料表。圖 13 則為 Suffer Lot Maintain 系統模組的資料 表欄位屬性。

表 3 Meeting Management 模組的資料表概要 Entity Name Usage

suffer_lot_wp 主要儲存影響 Lot 的主要屬性。

suffer_lot_ft 主要儲存影響 Lot 的晶圓後段封測資料。 suffer_lot_disposition 主要儲存影響 Lot 的處置動作。

process_code 處置動作的分類型態。

Suffer Lot 的資料上傳功能為本模組主要的功能，使用者利用此畫面來完成 Suffer Lot 範例檔案下載及填寫完的 Suffer Lot Excel 檔案資料上傳動作。以下將 以圖 14 Suffer Lot 資料上傳的序列圖為例，來描述本模組的系統功能如何撰寫。 本模組的其餘畫面功能都是類似此序列圖的方式撰寫而成。

首 先 在 uctl_sufferLotImport.aspx.cs 的 使 用 者 介 面 中 呼 叫 共 用 物 件 m_sufferLotImportProcess.cs 與 ImportSufferLot.cs 的 dataProcess 方法進行開始作 業。接著透過邏輯層查詢物件 ADD_NEW_SUFFERLOT_QueryBLL.cs 抓取產品 的生產相關資訊。最後再透過邏輯層存取物件 ADD_NEW_SUFFERLOT_BLL.cs 更新資料表 suffer_lot_wp 內容。

圖 14 Suffer Lot 資料上傳的序列圖

4.7 Action Tracking Module

Action Tracking 系統模組主要為各項改善措施的檢驗追蹤功能。藉由此模組 來追蹤各項處置的執行狀況並予以回覆。表 4 為此模組的資料表概要說明，主要 條列三個資料表。圖 15 則為 Action Tracking 系統模組的資料表欄位屬性。

表 4 Action Tracking 模組的資料表概要 Entity Name Usage

action_tracking 主要儲存各項改善措施的基本資料。 action_type 主要儲存各項改善措施的分類。 status_type 各項改善措施的實施狀況分類。

圖 15 Action Tracking Database schema

我們可藉由 Action 新增維護功能來將各種處置作新增與修改，其中包含 Containment Action、Lot Disposition Action、Suffer Lot List、Hold Lot、Release Lot、 CAR Action 等處置型態。以下將以圖 16 Action 新增維護的序列圖以及圖 17 Action 回覆的序列圖為例，來描述本模組的系統功能如何撰寫。本模組的其餘畫 面功能都是類似此序列圖的方式撰寫而成。 在新增維護的序列圖中，首先透過新增畫面 m_AddAction.aspx.cs 呼叫 localDataUpdate 方 法 來 儲 存 處 置 資 訊 ， 接 下 來 呼 叫 邏 輯 層 儲 存 物 件 ActionTrackingBLL.cs 的 InsertWithAutiGenSnoAndAcitonNo 方法。此方法中會先 藉由查詢物件 ActionTrackingDAOr.cs 取得處置的系統唯一編號與流水號。最後 再 將 處 置 資 料 透 過 儲 存 物 件 ActionTrackingDAOw.cs 更 新 到 資 料 表 action_tracking 中。 圖 16 Action 新增維護的序列圖 在 Action 回覆的序列圖中，首先透過新增畫面 form_actopmFeedback.aspx.cs 呼叫簽核流程控制頁面 TaskPane_form_actionFeedback.cs 中的 SPM_BeforeSend 方 法 來 進 行 處 置 回 覆 作 業 。 接 下 來 呼 叫 邏 輯 層 儲 存 物 件 ACTION_FEEDBACK_BLL.cs 的 UpdateActionTracking 方法。此方法中再藉由儲

存物件 ActionTrackingDAOw.cs 更新到資料表 action_tracking 中。

圖 17 Action 回覆的序列圖

4.8 CAR Request Module

CAR Request 系統模組為執行完改善措施後的紀錄報告功能。藉由此功能來 彙整重大異常最後的所有改善辦法與處置結論。表 5 為此模組的資料表概要說 明，主要條列四個資料表。圖 18 則為 CAR Request 系統模組的資料表欄位屬性。

表 5 CAR Request 模組的資料表概要 Entity Name Usage

car_data 主要儲存 CAR 報告基本資料。系統將 action tracking 的處置內容直接予以連結共存使用。 car_originator CAR 報告的撰寫與處置單位。

car_root_cause 重大異常的根本問題。

圖 18 CAR Request Database schema CAR 表單填寫為本模組的主要功能，使用者利用此畫面來完成 CAR 資料填 寫與簽核作業。以下將以圖 19 CAR 表單填寫的序列圖為例，來描述本模組的系 統功能如何撰寫。本模組的其餘畫面功能都是類似此序列圖的方式撰寫而成。 首 先 透 過 CAR 表 單 畫 面 form_initialCar.aspx.cs 呼 叫 簽 核 物 件 BorG_function.cs 的 SendFlow 方法觸發簽核流程。之後再呼叫邏輯層的儲存物件 ASSIGN_CAR_RESPONSIBILITY_BLL.cs 的 InsertCarData 方 法 接 續 呼 叫 CarDataDAOw.cs 的 Insert 方法來儲存 CAR 表單上的所有資訊內容到 car_data 資 料表中。最後在呼叫儲存物件 INITIAL_MRB_BLL.cs 的 UpdateMrbData 方法來 更新 MRB 的對應資料。

4.9 軟體平台與程式工具庫

MRB 系統在開發時，設計與使用了一些工具與平台，列表如表 6 中所示： 表 6 軟體平台與程式工具庫

Name Usage License

C# .NET Web application framework Microsoft BorG SPM 表單 Work flow engine 博格科技公司 Log4NET Logging service Apache License SQL Server 2000 Database system Microsoft MyGeneration Code Generation, O/R Mapping,

and Architectures

Freeware License Agreement

五、研究結果與比較

5.1 研究結果

本章節主要說明重大異常管理系統上線後所得到的實際效益分析。以下先條 列系統上線後功能變更歷程，說明系統的變更都是以 PDCA 管理循環架構下進 行修改。接著以重大異常相同原因再發率、使用者上線使用率以及異常處置回應 時效等三種數據，來驗證此系統上線前與上線後得到的效益是否有達成本研究的 主要目的。

5.1.1 上線後的功能變更歷程

本研究論文的管理系統於 2006 年上線後到 2009 年上半年，總共經過了二 十幾次的系統功能變更。其中大部分的變更都以使用者操作介面上的友善為主， 另外有三個的變更為新功能的增加，條列如表 7 所示。由此表中我們可以觀察 到，在後續相關功能變更歷程中完全還是依據 PDCA 的管理循環系統模組的架 構下做出變更。並且所有新增的功能都是原開發功能上的補強。因此，我們可以 推論 PDCA 管理循環架構的系統對於異常管理上確實收到實質的效益。 表 7 系統上線後功能變更歷程 更新日期 更新內容說明 所屬系統模組 2008/7/17 Pre-MRB 機制上線 MRB 系統模組

2008/8/11 Auto Hold/Release Lots 功能上線 Suffer Lot Maintain 系統模組 2009/3/9 失敗成本資料系統結構化 Action Tracking 系統模組

5.1.2 MRB 再發率數據比較

當生產過程發生重大異常時，決策主管不但需要訂出改善措施，而且更需要 了解如何防堵預防再發。本研究目的之一是想藉由 PDCA 管理循環，來加強防 堵異常再發。 我們前後整理出 P 公司四年的資料內容，分類為以下兩個表格資料。表 8 所呈現的資料為重大異常系統上線以前所整理的重覆發生比率。數據中，A 廠區 在該廠區重覆發生了 3 件異常。B 廠區在該廠區重覆發生了 1 件異常。C 廠區雖 然在該廠區沒有重複發生相同的異常，但是其發生的案件卻是在 B 廠區已經發 生過。也就是系統上線以前就多發生了這五件重複發生的案件。在表 9 所呈現的 資料為系統上線以後到現在所整理的案件重複發生比率。很明顯地我們可以了解 到，在重大異常系統的 PDCA 管理循環下，的確可以將異常案件再發率逐漸的 降低。

總之，透過本研究的 PDCA 循環所開發的管理系統，確實達到本研究的主 要目的之一。 表 8 系統上線前 MRB 重覆發生比率 廠別 重覆 (件) 重覆發生 比率 重覆影響 Lots 他廠已發生 A 廠區 B 廠區 C 廠區 A 廠區 3/36 8.3% 318 0 0 0 B 廠區 1/19 5.2% 17 0 0 0 C 廠區 0/7 0% 0 0 1 件 (影響 406 批) 0 資料來源：P企業 表 9 系統上線後 MRB 重覆發生比率 廠別 重覆 (件) 重覆發生 比率 重覆影響 Lots 他廠已發生 A 廠區 B 廠區 C 廠區 A 廠區 2/52 3.8% 50 0 0 0 B 廠區 1/19 5.2% 25 0 0 0 C 廠區 0/9 0% 0 0 0 0 資料來源：P企業

5.1.3 MRB 使用率數據比較

另外一個我們整理的數據資料是針對使用者上線的使用率，來說明透過本研 究的管理系統將大幅提升員工的使用率。系統上線後到 2008 年底，曾經使用過 系統總人數為 1417 人。其中與異常案件直接相關的負責人數為 112 人。在這 112 人中有 49 人的使用率比起本系統未上線前高出 2 倍，更有高達 63 人使用率超過 5 倍以上的使用比例。其餘非異常案件直接相關的人數，其中扣除使用次數不滿 10 1次的人數，也有 271 人上線查看了解別人所發生的異常案件。由上述人數統 計數據上可以知道在系統上線後，驗證了以 PDCA 循環所建置的異常管理系統， 確實增加了人員對各異常事件的聚焦效果。提供了工程師經驗的傳承與核心智識 的學習，縮短了人員學習曲線。

5.1.4 MRB 處置回應時效比較

由於上述的使用者上線使用率增加，以及簽核系統的催簽機制。我們可以加 以比較 MRB 案件的相關處置回應時效。由表 10 我們發現，系統尚未建立以前 平均完成天數高達兩個半月，並且要回覆給客戶的 CAR 報告書也需要 13 天的處 理時間。而正常的處理時間 7 個工作天內就必頇回覆客戶。如此長的處理時效， 可能隱藏了錯誤再發的風險。因此，對於異常處置時效的掌握確實也是非常重要 減少錯誤再發的指標之一。 表 10 系統上線前 MRB 處理回應時效 廠別 MRB Action 平均完成(天) CAR 平均要求回應(天) 平均逾期(天) A 廠區 74 21 8 B 廠區 82 19 5 資料來源：P企業 1_{一件異常案件直接相關人員至少需使用 10 次網頁上功能，少於 10 次的人皆只是上系統查看異} 常案件統計報表，因此予以扣除。

由表 11 中我們很明顯的看到，基於 PDCA 管理模式的系統上線後所有的 MRB 案件完成結案的天數已經下降到 1 個多月，並且回應給客戶的 CAR 時間也 都達到不會逾期的效果。確實證明本研究論文所建置而成的重大異常管理系統， 的確提升了 P 企業生產品質與處置的時效性，有效防止了異常再發的機率。 表 11 系統上線前 MRB 處理回應時效 廠別 MRB Action 平均完成(天) CAR 平均要求回應(天) 平均逾期(天) A 廠區 51 15 0 B 廠區 56 16 0 資料來源：P企業 接著我們舉一個 P 企業實際發生的異常事件來說明因為處置效率的提升，所 帶來的效益。2008 年七月發生機台 A-1 螺絲鬆脫掉落到製造熱盤上的重大異常， 經過 MRB 系統的管理後建立了失敗偵測判斷的系統參數，以期及早發現異常減 少做錯的產品。經過系統的追蹤管理該異常順利於兩個月內完成預防的系統機 制。接著於同年九月另外一個機台 A-2 同樣發生零件掉落熱盤的異常，因為有了 系統的失敗偵測判斷機制使得機台自動及時停止此異常。使得原本可能損失的金 額，降低高達 86%的幅度。再者統整 P 企業在 2008 年內，經過異常管理系統的 運作總共替該企業省下的金額占該企業當年度銷貨損失中的 3.6%。由上述兩項 實際數據我們可以清楚知道藉由系統追蹤與處置管理，確實可以因為縮短了異常 矯正時間而降低再發率或是失敗成本。

5.2 滿意度調查

系統上線後，我們針對 P 企業內部直接使用者進行了系統滿意度調查滿意度 調查表的內容如附錄二中表 23 所條列。回覆人數全部為 259 份，有效資料為 259 份。以下我們繪製了 PDCA 管理模式開發的系統上線前後使用者比較的滿意度 統計圖。如圖 20 所示，很明顯我們可以了解到 P 企業人員不管哪個廠區，對於 系統上線後所帶來的效益與方便性，給予高達 94%的高滿意度回應。

六、未來工作與結論

6.1 未來工作

本章節內容我們將提出幾點針對此管理系統的相關未來可再進行研究與發 展的工作方向： 1. 本論文中的重大異常管理系統是以 PDCA 管理循環方法所建置而成。 其中 PDCA 循環主要是由四大步驟所構成的改善流程。開發出的系統 中，我們還可以針對「Do」與「Check」步驟加以改善，符合新版本的 PDCA 管理循環（如圖 21）。也就是在「Do」與「Check」步驟中，再 視為另外一個管理循環，從訂定工作目標、工作執行、工作檢驗到目標 確認，演變為另一個完整的 PDCA 循環。 圖 21 新版本 PDCA 循環 2. 本研究所開發出的重大異常管理系統，將各種異常狀況予以矯正並且加 以紀錄與分類。因此我們未來可以建立不同廠區的水平展開學習作業。 藉由製造過程負責單位的不同，將各個重大異常於結案後發送通知訊息 給不同廠區的對應單位，並且經過這些單位主管的審查確認後派送通知 單位內作業人員。如此可給予各單位人員充分了解異常發生原因、後續 改善辦法與防堵作業等所有資訊。如此可避免與降低他廠區相同重大異 常的再發率，擴大到了全公司的生產品質管理，放大了整體的生產效 益。所以水平展開學習作業是未來可以進行開發的工作之一。 3. 再者經過本系統的整合後，已經可以詳細記錄每個生產產品異常資訊以 及異常處置方法。我們藉由這些資料，可以精算出每個異常發生的生產 耗損成本，量化了生產異常結果。再加上對於每個異常事件的責任釐 清，可以明白記錄異常發生的部門與人員。將兩者資訊與人事考核系統 整合，可讓考核評斷更加公平與公正。如此，可提升企業員工的工作效 率、紀律、工作品質與專業技術。

6.2 結論

本研究所開發出的異常管理系統，在透過 PDCA 的方法管理後，不但可以 將各種異常狀況加以矯正與預防，更改善了生產的品質，同時降低了公司的生產 異常的再發率，大大提高了公司的競爭力。 戴明博士的 PDCA 理論是一種科學嚴謹的工作方法與工作程序，也是一種 經過各行業驗證的科學管理工具。這個理論不但幫助我們建立整體生產的管理處 置系統，而且對於每個局部小細節或是突發事件的處理都有不可取代的管理作 用。本論文研究内容，便是實作開發出應用 PDCA 管理循環的重大異常管理系 統。其驗證了 PDCA 管理循環，對於解決工程困難與單一細節的作用。而 PDCA 是ㄧ個貫穿始終的工作步驟，對於管理人員只要認真執行 PDCA 的每一個細節， 就會使得最終的目標得以成功實現。本管理系統中，許多重大異常的後續處理， 是由於運用 PDCA 管理循環中的嚴謹分析，制訂出確實可行的工程製造程序， 並透過工程人員的執行落實以及管理人員的嚴謹查核而得以實現的。所以我們透 過系統化的管理，向每個過程要效益，才是企業得以長期發展的根本。本重大異 常管理系統是充分運用戴明博士的 PDCA 管理循環的一個半導體工程上異常管 理成功案例。

參考文獻

[1] 戴久永，「全面品質管理」，中華民國管制學會，台北，民國八十一年。 [2] 陳耀茂，「品質保證-理論與實務」，五南出版公司，台北，民國八十三年。 [3] 鄭清和，「品管新七手法實戰」，臺灣復文興業股份有限公司，台南，民國八 十三年。 [4] 廖方者見，「品管小組活動導入法」，中華民國品質管制學會發行，台北，民 國八十三年。 [5] 辜輝，「企業 e 化知識管理策略」，知行文化事業股份有限公司，台北，民國 九十年。 [6] Richard C. Whitely 著，經營顧客心，第一版，董更生譯，天下文化出版社， 台北，民國八十二年。 [7] E. EDWARDS DEMING，戴明的新經濟觀，戴久永，天下文化，台北，民 國八十五年。

[8] William J. Stevenson, Production /Operation Management 6th ed., 傅和彥譯， 前程企管出版，台北，民國八十八年。

[9] Eitan Haven, Avner Halevy, A Hierarchical framework for a quality information system, Total Quality Management, vol.11, No.1, pp.87-111, 2000.

[10] Hilton, R. W., M. W. Maher and F.H. Selto, Cost Management Strategies for Business Decisions., New York：McGraw Hill, 2000.

[11] Kim, D. H., Toward Learning Organizations-Integrating Total Quality Control and Systems Thinking, Innovations in Management Series, Pegasus, Cambridge, 1997.

Concepts in Manufacturing and Service, Ch7, pp253 290, Ch19, pp683 722, 1995. [13] 「8D 問題解決訓練課程教材」，福特六和汽車，訓練課程教材，民國九十年。 [14] 張聖德，「ISO 9001:2000 品質管理系統要求」，統一企業股份有限公司內部 訓練教材，台南，民國九十年。 [15] 張淑慧，「企業導入網路化訓練（WBT）促進組織知識整合之研究」，人力 資源管理研討會，民國八十九年。 [16] 戴久永，「由活用 PDCA 循環談起」，品質管制月刊，29 頁，民國八十九年 四月。 [17] 林建基，「PDCA 循環全員品管」，管理雜誌，第 316 期，pp.98-100，民國八 十九年。 [18] 王銘宗，吳永智，「全面品質管理資訊系統之探討」，國立台灣大學工業工程 學研究所，八十八學年度技術報告，民國八十八年。 [19] 王銘宗，洪勝利，「高科技產業實施全面品質管理與提昇競爭力之探討」，國 立台灣大學工業工程學研究所，87 年上半學年技術報告，民國八十七年。 [20] 李華揚，「統一企業品管圈活動二十年」，現場與管理，第 26 卷第 12 期，頁 38-45，民國八十七年。

[21] Eitan Haven& Avner Halevy., "A hierarchical framework for a quality

information system", Total Quality Management, Vol11, No.1, pp87-11, 2000. [22] Oko, Daniel, "Applying the Ford Eight Disciplined (8D) Approach to Prevention

of Defects and Preventing Defect Reoccurrence In Software", Die Manufacturing Organization, ASQC, 1997.

[23] Powell, T.C, "Total Quality Management as Competitive Advantage：A Review and Empirical Study", Strategic Management Journal, Vol. 16, pp.15-37, 1995. [24] Dixon, "Organizational Learning Cycle：How We Can Learn Collective."

[25] Keith, Richard B Jr., "MIS+TQM=QIS", Quality Progress, Vol. 27, pp.29-31, April, 1994.

[26] Allender, H.D., "Using Quality Circles to Develop an Action Plan Required for Leading Organization." Industrial Management, pp.8-10, October, 1992. [27] Bennett, H.S., "Next generation Quality Software", Quality, pp.42-44, 1990. [28] Persico, Jr. J., "Term up for Quality Improvement", Quality Process, pp.33,

January, 1989.

[29] Chang, C.H., "The structure of quality information system in a computer

integrated manufacturing environment", Computers and Industrial Engineering, Vol.15, No.1-4, pp. 338-343, 1988.

[30] Pickler, L, "Quality Circle in the Systems Enviroment.", Journal of Systems Management, pp.14-16, November, 1983.

[31] E. EDWARDS DEMING, "Quality Productivity and Competitive Position", Massachusetts Inst Technology, 1982.

[32] 朱晁瑩，「運用 MVC 設計樣式建置元件化資訊系統」，國防大學中正理工學 院資訊科學研究所，碩士論文，民國 95 年。 [33] 黃石欽，「Model-View-Controller (MVC) 架構之整合設計與實務應用」，中 原大學應用數學研究所，碩士論文，民國 91 年。 [34] 李昆林，「全面品質管理、知識管理與學習型組織整合模組之構建」，國立中 正大學企業管理研究所，碩士論文，民國 90 年。 [35] 鄭清和，「品管圈活動之管理績效實證研究-以統一企業公司為例」，長榮管 理學院經營管理研究所，碩士論文，民國 90 年。 [36] 邱炫儒，「以文件式 Model-View-Controller 設計樣式為基礎的應用系統開發 方法」，中原大學資訊管理研究所，碩士論文，民國 90 年。 [37] 周芸薇，「學習型組織評鑑量表之建立」，國立中央大學人力資源管理研究 所，碩士論文，民國 89 年。

[38] 吳永智，「建構高階主管品質資訊系統（EQIS）之規劃參考模式的初期先導 研究」，國立台灣大學共業工程學系，碩士論文，民國 89 年。 [39] 洪勝利，「高科技產業實施全面品質管理與提昇競爭力關係之研究」，國防管 理學院資源管理研究所，碩士論文，民國 88 年。 [40] 姜約翰，「台灣鋼鐵業通過 ISO 9000 品質管理系統認證後之績效評估－以某 鋼鐵公司為例」，國防管理學院資源管理研究所，碩士論文，民國 87 年。 [41] 賴武元，「全面品質管理與競爭優勢之個案研究：以中鋼公司為例」，國立中 山大學企業管理研究所，碩士論文，民國 86 年。 [42] 羅秋香，「全面品質管理與經營績效關係之探討」，淡江大學國際企業學研究 所，碩士論文，民國 85 年。 [43] 劉志鵬，「品質資訊系統架構與資料流程之研究」，國立臺灣大學商學研究 所，碩士論文，民國 82 年。 [44] 陳志遠，「製造策略、產品策略之配合與績效關係之研究-以台灣電子零組件 業為例」，國立政治大學企研所，博士論文，pp.53-57，民國 81 年。 [45] http://java.sun.com/blueprints/patterns/MVC-detailed.html, Sun Microsystems,

附錄一

表 12 MRB 立案功能詳述

Component Type Description

MRB_NO URL傳入參

數

 來源單號(MRB單號)。

 [Logic] 若有傳入參數，則依mrb_data.request_no = MRB_NO

條件讀取資料，否則新增一筆資料。  [DB Mapping field] mrb_data.request_no。

Request Date User Control Read only

 申請日期。

 [Logic] 網頁讀取時，帶出系統日期(date time) 。

 [UserControl] DateSelector.cs。

Isser UserControl Read only

 立案申請人。

 [Logic] 網頁讀取時，依Login ID帶出員工Email ID & 中文姓 名，儲存時儲存員工ID。

 [UserControl] EmployeeSelector.cs。  [DB Mapping field] mrb_data.isser。

Fab DropDown List 必填  異常發生廠別。  [Logic] 依挑選Fab之不同Module會隨之帶出該廠別對應之 Module。  [Data Source]

 取自 qams_fab_data ，Condition : status=‟Y‟ 。  DataTextField : fab_desc。

 DataValueField : fab_no。

 [DB Mapping field] mrb_data.fab_no。

Status Date UserControl Read only 必填

 立案日期

 [Logic] 網頁讀取時，帶出系統日期(date time)，可點擊 ，

顯示出日曆表提供日期的選擇。  [UserControl] DateSelector.cs。

 [DB Mapping field] mrb_data.status_date。

Problem Source DropDown List 必填

 MRB異常發生來源。

 [Data Source]

 取自 mrb_problem_source ，Condition : status=‟Y‟ 。  DataTextField : problem_src_desc。

 DataValueField : problem_src_no。

 [DB Mapping field] mrb_data.problem_src_no。

Module CheckBoxLi st

必填

 異常發生單位(Mutli-Select)

 [Data Source]

 取自 qams_fab_module ，Condition : fab_no=上述選擇之異常 廠別 AND status=‟Y‟。

 DataTextField : module_desc。  DataValueField : module_no。

 [DB Mapping field] mrb_problem_module.module_no。

MRB Subject Text 必填

 重大異常主題。

Reason DropDown List 必填

 符合重大異常原因(Mutli-Select) 。

 [Data Source]

 取自 mrb_reason ，Condition : status=‟Y‟ 。  DataTextField : reason_desc。  DataValueField : reason_no。  [Logic] 點選左邊視窗內所要選擇之異常原因並按 鍵即可 挑選所要選擇之異常原因，並將該異常原因顯示於右邊視窗 內，點選右邊視窗內的異常原因並按 鍵即可取消選取，若 要一次挑選多個異常原因時，可於左邊視窗挑選異常原因時配 合使用Ctrl 按鈕與Shift按鈕。

 [DB Mapping field] mrb_problem_reason.reason_no。

Description Textarea 必填

 重大異常描述。

 [DB Mapping field] mrb_data.problem_desc。

Product Name DropDown List 必填

 異常產品別(Mutli-Select) 。  [Data Source]

 取自 qams_product_name ，Condition : status=‟Y‟ 。  DataTextField : product_desc。

 DataValueField : product_name。

 [Logic] 可先依Micron或是Product Type來過濾顯示之Product

Name內容，或在條件輸入欄位輸入關鍵字後按篩選來過濾符合 關鍵字的Product Name 列出全部按鈕則可回復篩選之前依所 設定之Micron與Product Type條件來過濾的所有Product Name，

點選左邊視窗內所要選擇之Product Name並按 鍵即可挑選

所要選擇之Product Name，並將該Product Name顯示於右邊視窗

內，點選右邊視窗內的Product Name並按 鍵即可取消選取，

若要一次挑選多個Product Name 時，可於左邊視窗挑選Product Name時配合使用Ctrl 按鈕與Shift按鈕。

Failure Mode DropDown List 必填  Failure Mode異常發生區域。  [Data Source]  Option item : WP / WT / AP / FT。  [Logic] 選取異常發生區域時會對應顯示符合該異常區域之 failure Mode資料。

 [DB Mapping field] mrb_data.failure_area。  異常失效模式(Mutli-Select) 。

 [Data Source]

 取自 mrb_failure_mode ，

 Condition : failure_area = mrb_data.failure_area and status=‟Y‟ 。  DataTextField : failure_desc。

 DataValueField : failure_no。

 [Logic] 可在條件輸入欄位輸入關鍵字後按篩選來過濾符合關

鍵字的Failure Mode 列出全部按鈕則可回復篩選之前的所有

Failure Mode，點選左邊視窗內所要選擇之Failure Mode並按 鍵即可挑選所要選擇之Failure Mode，並將該Failure Mode顯示

於右邊視窗內，點選右邊視窗內的Failure Mode並按 鍵即可

取消選取，若要一次挑選多個Failure Mode 時，可於左邊視窗 挑選Failure Mode時配合使用Ctrl按鈕與Shift按鈕。

 [DB Mapping field] rb_problem_failure_mode.failure_no。

Affected Lot Text 必填

 初估異常所影響之Lot資訊。

 [DB Mapping field] mrb_data.affected_lot_note。

Attachment File 瀏覽

File  上傳 Reference File。

 [Logic] 點擊瀏覽，系統 pop-up 選擇檔案畫面供選擇要上傳

的檔案，選完上傳檔案後，點擊 儲存 或提交MRB委員會處理 時系統會將檔案上傳。上傳後畫面會帶出該檔案名稱(限 15Mbytes) 。

 [DB Mapping field] mrb_data.attach_filepath , mrb_data.attach_filepath_save。

 [Attach file] 置放於 \Web\uploadFiles\MRB\。  Action Button

提交MRB委員會處理 Button  確定立案，並開始MRB處理流程。  [Logic]  系統頇自動產生一申請編號。  Check 必填欄位。  系統必頇確認欄位的 data format 是否正確，若 check 不過, 則要求申請者修正。  系統需將申請內容儲存於mrb_data中，並將此申 請單 之 STATUS 標註為 Action Tracking (status_no=1) 。

 展開MRB流程。

 送 mail 通知MRB會議記錄者。

 主管亦可由MRB 裏的My Job List 點選所要處 理之單據加以處理。 儲存 Button  暫存表單申請內容  [Logic]  系統必頇確認欄位的 data format 是否正確。若 check 不過, 則要求申請者修正。  Check 必填欄位。  系統需將申請內容儲存於資料庫中，並將此申 請單 之 STATUS 標註為 Initialing (status_no=0) 。  系統頇自動產生一申請編號以利日後 tracking 之用 . 日後可由[MRB立案]模組中之 [修改立 案內容] 功能進來繼續填寫。  暫存成功後，出現 “申請單號：xxxxxx，表單存 儲成功” 提示。

刪除此單據及其相關 資料 Button  刪除此表單及其相關資料。  可刪除之條件為此申請單尚未提交MRB委員會處理或是雖 已提交MRB委員會處理但已利用[MRB立案]群組中的 [取 消立案] 功能進行單據及其相關流程之取消動作，單據狀態 (status=4)已為取消之狀況。  [Logic]  除了刪除mrb_data中該筆資料外，需先刪除相關 檔案中資料。  mrb_problem_module中 request_no=mrb_data.request_no。  mrb_problem_reason中 request_no=mrb_data.request_no。  mrb_problem_product中 request_no=mrb_data.request_no。  mrb_problem_failure_mode中 request_no=mrb_data.request_no。  mrb_affected_lot中 request_no=mrb_data.request_no。  刪除成功後，畫面會出現 “申請單號：xxxxxx， 表單刪除成功” 提示。

表 13 MRB 會議紀錄維護

Component Type Description

_request_no URL傳入參數  開會來源單號(MRB單號) 。

 [DB Mapping field] mm_meeting_minutes.request_no。

_request_date URL傳入參數  登錄日期。  [Logic] 網頁開始時判斷是否有傳入 _request_no及_request_date，若 有傳入則mm_meeting_minutes.request_no=_request_no AND mm_meeting_minutes.request_date=_request_date 詴著讀取 mm_meeting_minutes檔案資料，若沒有傳入則顯示未傳入來源單號訊 息，並關閉視窗。

 [DB Mapping field] mm_meeting_minutes.request_date

共用資料模組 UserControl  取用共用資料顯示模組。  Call Method :

Meeting Date UserControl 必填

 開會日期。

 [Logic] 點擊 ，顯示日曆表提供選擇日期。

 [DB Mapping field] mm_meeting_minutes.meeting_date。

Actual Time Begin UserControl 必填  安排開會起始時間。  [Logic] 24小時制，輸入範圍0000-2400。

 [DB Mapping field] mm_meeting_minutes.actual_time_begin。

Actual Time End UserControl 必填  安排開會結束時間。  [Logic] 24小時制，輸入範圍0000-2400。

 [DB Mapping field] mm_meeting_minutes.actual_time_end。

MRB Chairman UserControl 必填  會議主席。  [Logic] 點擊 圖形後，會顯示人員挑選視窗來讓使用者挑選。

 [DB Mapping field] meeting_minutes.chairman。

Recorder UserControl 必填

 會議記錄。

 [Logic] 點擊 圖形後，會顯示人員挑選視窗來讓使用者挑選。

 [DB Mapping field] mm_meeting_minutes.recorder。

Meeting Minutes

Text 必填

 會議記錄內容。

Attender List DataGrid Read only  會議通知人員。  [Logic]不分頁顯示。  PageLoad時判斷是否有傳入 _request_no，若有傳入且 mm_meeting_minutes檔案中未建資料時，則依_request_no讀取 mrb_data中的fab_no , problem_src_no (SELECT

mrb_data.fab_no,mrb_data.problem_src_no FROM mrb_data WHERE mrb_data.request_no=_request_no) 來讀取mm_attendant_data中的資料 (SELECT attendant FROM mm_attendant_data WHERE

fab_no=_fab_no AND _problem_src_no IN join_group)，並寫入 mm_meeting_team中。  點擊 圖形開窗新增填寫人員(連結人員挑選作業)，點擊 圖形 可刪除單項之填寫人員，刪除前會先跳出確認視窗。  [Data Source]  SELECT mm_meeting_team.org_no,  qams_employee.cname,mm_meeting_team.optional_yn  FROM mm_meeting_team,qams_employee WHERE

qams_employee.empid= mm_meeting_team.employee_no AND mm_meeting_team.request_no=mm_meeting_minutes.request_no AND mm_meeting_team.request_date= mm_meeting_minutes.request_date。

Dept Text Read only

 部門編號。

 [DB Mapping field] mm_meeting_team.org_no。

Attendant Text Read only

 與會人員。

 [DB Mapping field] qams_employee.cname。

Need DrogdownList  需出席選項。

 [Data Source] Optional：Y / Must：N。

 [Logic] 若非必要出席人員寄送會議通知及會議記錄時CC即可。

 [DB Mapping field] mm_meeting_team.optional_yn。

Action Item 共 用資料顯示模 組

UserControl  取用Action Item共用資料顯示模組。  Call Method :

 bindMasterData (MRB_NO,””,bool boolAddIconCtrl[true],bool boolCancelIconCtrl[true],bool boolRequestNoShow[false],bool boolRequestDateShow[false]) 。

儲存 Button  暫存會議記錄內容，先不展開相關Action Flow。  [Logic]

 系統必頇確認欄位的 data format 是否正確， 若 check 不過則要求申請者修正。  Check 必填欄位。  系統需將內容儲存於mm_meeting_minutes以及Update mm_meeting_team的option_yn。  暫存成功後 , 出現 “資料儲存成功” 提示。 刪除會議資料 Button  刪除此會議所有資料。  [Logic]若已有Action流程送出則此按鈕Disabled。

 刪除mm_meeting_minutes Where request_no=_request_no and request_date = _request _date。

 刪除mm_meeting_team Where request_no=_request_no and request_date = _request _date。

 刪除action_tracking Where request_no=_request_no and request_date = _request _date and status=‟0‟ 。

儲存並送出會 議記錄 Button  儲存資料並送出會議記錄。  [Logic]  檢查必填欄位。  mm_meeting_minutes.status = „2‟ （會議記錄狀態）。  mm_meeting_minutes存檔以及Update mm_meeting_team 的option_yn。  將會議內容發送給Attender中所建立的人。 儲存並送出 Action流程

Button  儲存會議記錄內容，並展開相關Action Flow。  [Logic]

 系統必頇確認欄位的 data format 是否正確。若 check 不過, 則要求申請者修正。  Check 必填欄位。  系統需將內容儲存於mm_meeting_minutes以及Update mm_meeting_team的option_yn，並將此申請單 之 status 標註為會議記錄 (status=”2”)。  展開相關Action 流程。

指派回覆Root Cause/Suffe Lot

Button  儲存會議記錄內容，並另開新頁連結QAMS-MRB Module中的指派 MRB資料回覆人員作業。

 [Logic]

 系統必頇確認欄位的 data format 是否正確， 若 check 不過, 則要求申請者修正。  Check 必填欄位。  系統需將內容儲存於mm_meeting_minutes以及Update mm_meeting_team的option_yn ，並將此申請單之 status 標註為會議記錄 (status=”2”)。 表 14 Suffer Lot 資料上傳

 Component  Type  Description

 MRB_NO  URL傳入參數  MRB單號。

 共用資料模組  UserControl  取用MRB共用資料顯示模組。

 Program Name = uctl_displayMrbHead.ascx。

 Call Method :

 bindMasterData (string MRB_NO,bool rootCauseVisible[true]) 。

MRB 共用資料顯示模組

 Suffer Lot Excel 資 料轉入共用模組

 UserControl  Suffer Lot Excel 資料轉入共用模組。

 Call Method : bindMasterData(string MRB_NO,string FAB_NO) 。

表 15 Suffer Lot Excel 資料轉入共用模組

Component Type Description

Suffer Lot Import UserControl Parameter  UserControl：uctl_sufferLotImport.ascx。  Method：bindMasterData。  string requestNo：MRB單號。  string fabNo：廠別代號。  string displayOnly：Y:單純顯示資料無Import功能。 區塊 1，Lot 基本資料 區塊 2，Lot 處置資料 區塊 3，當下 Lot 的即時生產狀況 區塊 4

Suffer Lot Import UserControl Method

 bindMasterData (string requestNo,string fabNo) 。  bindMasterData (string requestNo,string fabNo,string

displayOnly) 。

Download Sample File

Hyperlink  Suffer Lot List 標準填寫格式檔。

 [Logic] 點擊 圖形，將標準填寫格式檔(Excel)下載，並自

行在檔案中維護好所需提供之資料。

 標準填寫格式檔填寫說明。

 MRB No : MRB單號。

 WP Key No : Suffer之前段Key No。  Process Code : 異常 Process。

 EQ Code : 異常機台。

 Suffer Qty : 99:表待判定 / 0:表OK / 1-25:表NG數。

 Comp.Date : 異常日期。

Import from File File  上傳填寫完成之Suffer Lot Excel File。

 [Logic] 點擊 瀏覽 ，系統 pop-up 選擇檔案畫面供選擇要上

傳的檔案，選完上傳檔案後，點擊 上傳 或 清除後上傳 (將原 有資料刪除後再上傳，被Hold之資料不異動)將檔案上傳至系統。  [Attach file] 置放於 \Web\uploadFiles\。

3 information checkbox

Checkbox  提供user選擇show在畫面上的資訊。

 [Logic]固定顯示WP Key No, FT Key No. 其餘依照背景顏色,勾

選checkbox,顯示同種顏色之欄位,反之則隱藏(區塊 1 為WP的資 本資訊、區塊 2 為Lot Disposition資訊、區塊 3 為WIP資訊)。

Suffer Lot List DataGrid Read only

 上傳之Suffer Lot List。  [Logic]

 點擊 圖形開窗新增Suffer Lot (連結Suffer Lot 資料維護)，點

擊 圖形可刪除單項之Suffer Lot，刪除前會先跳出確認視窗，

點擊 圖形修改單項Suffer Lot。

 Action Button

過濾 Button  提供進階查詢過濾功能，讓使用者可以依設定之條件來找尋所 需資料。

 [Logic]如圖4所示，可依WP Key No、FT Key No、Layer、Mfg

Type、Chip Name 、Customer等條件來複合過濾查詢。