第二章 文獻探討
2.2 系統分析工具
2.2.5 對策提出與實施計劃表
透過腦力激盪的方式，根據所發現的缺失原因提出對策進行改善，唯 對策不一定要全部實施，而對策提出與實施計劃表可將對策依改善的不同 效果程度透過事先定義的分數評定表加以區分，以總和分數的高低決定對 策實施的順序或決定是否值得實施[3]。
2.3 系統開發相關技術介紹 [6] [7]
本小節介紹系統開發的相關技術，由於考量系統開發後，使用上的相 容性與維護的方便性，我們選擇目前普遍使用的微軟作業系統開發環境。
2.3.1 .NET 架構(.NET Framework)
NET架構為一建構、部署、執行 XML Web Services 及應用程式之平 台，它可提供一高產能、標準、多語之開發環境，並能整合現有投資與下
世代應用程式及服務，並解決了佈建及操作網路應用程式之難題，.NET Framework 是由兩個主要部分所組成：通用語言執行階段程式庫及一組階 層式類別程式庫（包括元件化版本的 Active Server Pages 稱為ASP.NET、
資料存取子系統 ADO.NET 及建置視窗應用程式開發環境 Windows Forms 等）。
2.3.2 ADO.NET
ADO.NET 是 ADO(Active Data Objects)資料存取模型所發展而出的 產品，直接滿足使用者開發可調適性應用式的需求。它是特別針對 Web 的 延展性 (Scalability)、無國界特性和 XML 而設計。
ADO.NET 使用許多 ADO 物件，例如 Connection 和 Command 物 件，而且還採用新的物件。重要的新 ADO.NET 物件包含DataSet、
DataReader 和 DataAdapter。這個進化的 ADO.NET 和前一版資料架構最 大差異在於有 DataSet 物件的存在，它不同於任何資料存放區。基於上述 因素，DataSet 可以當作獨立的實體 (Entity)。DataSet 可以被視為一個中 斷連接資料錄集(Disconnected Recordset)，它並不知道其所包含的資料之來 源或目的端。在 DataSet 內部，很像是在資料庫中，有資料表、資料行、
關聯性 (Relationship)、條件約束 (Constraint)、檢視表 (View) 等等。
DataAdapter 是用來連接到資料庫的物件，以將資料填DataSet。然後，
根據在 DataSet 持有資料時所執行的作業，連接回資料庫以更新該處的資 料。在過去，資料處理是以連接為主。現在，為了使多層次應用程式更有 效率，資料處理轉向以訊息為基礎的方法，並以資訊區塊 (Chunk) 為中 心。在這個方法的中心是 DataAdapter，提供DataSet 和其來源資料存放區 之間擷取並儲存資料的橋樑。它依靠對資料存放區所產生的適當 SQL 命 令的要求而完成這項目的。
以 XML 為主的 DataSet 物件提供了一致的程式撰寫模型
(Programming Model)，它和所有的資料存放模型 (扁平式、關聯式和階層 式) 相容。DataSet 並不知道它的資料來源為何，它會用集合物件和資料 型別來存放它的資料。不論 DataSet 內的資料來源為何，都可以使用 DataSet 及其附屬物件所公開的一組標準 API 來操作處理裡面的資料。
Managed 資料提供者提供資料控制項，易於與 OLEDB 和 ODBC 資料庫來源建立連接，這些資料來源包括 Microsoft SQL Server™、
Microsoft Access、Jet、DB2、Oracle 及其他資料格式，雖然 DataSet 不瞭 解串聯資料的來源，但是透過 Managed 提供者(Provider)詳細和特定的資 訊定義，則可快速有效的連結資料。因此，Managed 提供者的角色是連接、
填入和保存 DataSet 至/自資料存放區。
OLE DB 和SQL Server .NET 資料提供者(System.Data.OleDb 與 System.Data.SqlClient) 是 .Net Framework 的一部份，提供四種基本的物 件：Command、Connection、DataReader 和 DataAdapter。這些物件包含 功能有以下五種:
1. Connection -針對資料庫的連接和管理交易。
Connection 是用來與資料庫進行溝通，是由提供者特定類別所代表 的，例如 SQLConnection。瀏覽連接和結果集 (Resultset) 的命令是以資 料流形式傳回，可以由 DataReader 物件讀取或送回至 DataSet 物件。
2. Command -針對資料庫發出 SQL 命令。
Command 包含送出至資料庫的資訊，是由提供者特定類別所代表 的，例如 SQLCommand。任一命令可以是預存程序 (Stored Procedure) 呼叫、UPDATE 陳述式或可傳回結果的陳述式。您也可以使用輸入和輸 出參數，以及將傳回值當作命令語法的一部份。
3. DataReader -針對從SQL 資料來源讀取順向資料流的資料紀錄。
DataReader 物件有點同義於資料上唯讀/順向的資料指標 (Cursor)。
DataReader API 支援扁平式和階層式資料。在對資料庫執行命令之後，
會傳回 DataReader。傳回的 DataReader 物件的格式不同於資料錄集 (Recordset)。
4. DataSet -針對一般資料、XML 資料和關聯式資料進行儲存、遠端 處理和程式設計。
DataSet 物件表示資料的快取，具有類似資料庫的結構，例如資料 表、資料行、關聯性和條件約束。DataSet 物件不會直接與資料庫或其 他來源資料互動。這樣開發人員才能使用永遠一致的程式撰寫模型，而 不管來源資料所在的位置。
5. DataAdapter -針對資料庫將資料送回 DataSet，以及調解資料。
DataAdapter 物件可以當成 DataSet 和資料來源之間的橋樑。當開 發人員對 DataSet 做了變更之後，DataAdapter 物件會使用命令更新資 料來源。
圖 2- 3 SQL DataAdapter 示意圖[7]
資料來源：Microsoft .Net Framework SDK 快速入門教學課程
第三章 出貨流程改善與作業系統構建步驟
步驟 3 :利用 OQC Cycle time 層別圖(圖 3-1)與 OQC 作業特性要因圖(圖 3-2) 及時間差異柏拉圖(圖 3-3)，找出關鍵問題及可能發生原因。透過查 檢表所得到的資料，整理成相關的層別圖找出關鍵的子作業，再透 過要因分析，了解問題發生原因，找出對策。
圖 3- 1 層別圖 資料來源：本研究
圖 3- 2 特性要因圖 資料來源：本研究
機台 人員
方法 材料
Cycle Time 太長 真因 真因
真因
真因
真因
真因
真因 真因 真因
圖 3- 3 柏拉圖 資料來源：本研究
步驟 4 :尋找可行對策
利用對策提出與實施計劃表，評估並找出有效可行的對策。
表 3- 2 對策提出與實施計劃表
不良項目 要因細分 對策提出
檢討 效
果 可 行 性
費 用
期 間
得 分
順
位 提案人 試行日期 負責人
資料來源：本研究
步驟 5 :實施對策進行作業面改善與調整。
第四章 實例驗證
在圖 4-1 中收料與履歷檢查是分為兩個步驟，以區別不同作業屬性所
步驟 3、找出關鍵問題及可能發生原因
經由以上兩個步驟，我們已經定義標準作業時間並取得實際作業時間 資料，根據取得的數據，可以利用 OQC 作業時間層別圖與 OQC 作業時間 差異柏拉圖的分析方法，找出整個作業環節中，影響較大或首要急需解決 的問題，如圖 4-2 ;圖 4-3 之說明。
圖 4- 2 OQC 作業時間層別圖
由作業時間層別圖可看出，各作業模組的實際工時與標準作業工時皆 有一定的差距，玆整理於時間差異分析表(表 4-2)並進行 OQC 作業時間差 異之柏拉圖分析。
表 4- 2 時間差異分析表
模組 Key in 外觀檢驗 包裝 履歷檢查 晶舟轉換
標準工時(hrs) 0.15 0.44 0.15 0.05 0.05
實際工時(hrs) 0.5 0.69 0.25 0.14 0.13
時間差異(hrs) 0.35 0.25 0.1 0.09 0.08
差異百分比(%) 40.23% 68.97% 80.46% 90.80% 100.0%
圖 4- 3 OQC 作業時間差異柏拉圖
由作業時間差異柏拉圖可看出，各作業模組與相對標準作業的工時差 距中，以檢驗紀錄 Key-in 作業差距 0.35 小時佔總差距的 40.23%貢獻度最 高，而後依序為:外觀檢驗 0.25 小時、包裝 0.1 小時、履歷檢查 0.09 小時 及晶舟盒轉換的 0.08 小時。可知，若優先改善檢驗紀錄 Key-in 作業，對 於作業時間改善有最大的效果。
同時亦利用特性要因圖分析法，要求現場人員進行力激盪，有系統的 加以確認造成作業時間過長的實際因素，如圖 4-4 所示。
圖 4- 4 OQC 作業特性要因圖
步驟 4、尋找可行對策
4.2 作業流程改善
根據標準化後之作業流程，進行實際作業環境的改善與調整。
步驟 5、實施對策進行作業面改善與調整
步驟 5 主要針對步驟 4 分析結果中，作業面的部分加以改善，亦即工 作動線不佳之要因進行調整。在改善前原本的工作動線為往返式的動線，
每一模組作業完成要道下一模組作業需經過較長的移動距離，完整動線全 長高達 42.6 公尺，且物流動線反覆交錯，容易導致人員作業疏失，作業時 間也較長，如圖 4-5 說明。
圖 4- 5 對策前 OQC 作業動線示意圖
調整後，將動線修正為單線單向作業方式，調整帳務系統電腦位置，
依作業模組順序，重新安排作業區 Layout，動線全長由 42.6 公尺減為 30 公尺，亦即每批貨移動距離減少 12.6 公尺，大幅降低物流複雜性，提昇作 業效率，如圖 4-6 說明。
6 2
3 4
5
1
收料 履歷檢查
Key-in
包裝 晶舟轉換
外觀檢驗
In Out
圖 4- 6 對策後 OQC 作業動線示意圖
6 2
3 4
5
1 收料 履歷
檢查
Key-in
包裝 晶舟轉換
外觀檢驗
In Out 將電腦移至此
4.3 電腦系統建構
步驟 6-2 建立使用者介面
根據目前線上作業方式與使用者習慣，決定介面顯示資訊，再串聯 相關資訊系統與資料庫，建構相關輸入、輸出控制項與畫面，建構流程 如圖 4-8 所示。
圖 4- 8 使用者介面建構流程
步驟 6-3 撰寫主程式及其他資料處理相關程式碼
檢驗作業輸入表為主程式部分，是利用條碼讀取技術連結製造生產系 統與晶圓測試資料庫，自動帶入生產資訊並比對產品履歷，減少作業人員 產品履歷確認時間，簡化資料輸入複雜度，並建立異常產品 MAP 繪製系 統，縮短產品 MAP 繪製時間。
透過主程式獲得產品檢驗結果資料，並整合連結之製造生產與測試資 料庫，統一資料格式，即可開發其他如查詢、刪除、新增、修改功能之資 料處理子系統，滿足工程人員工作需求，提昇人員工程分析效率，與產品
決定表單應顯示的資訊
繪製使用者介面
選擇資料來源
撰寫資料讀取程式碼
撰寫介面控制項程式碼
撰寫資料回存程式碼
測試資料 庫系統 製造生
產系統
現況的即時掌握，使得客戶能獲得多面向、高品質的產品資訊回饋，加速
4.4 系統功能簡介
系統操作使用介紹如下:
由於該系統除產線人員使用外，亦有工程人員使用，即有多人在不 同地方及相同時間使用該系統資料庫，因此規劃安裝於公司伺服器上，透 過公司區域網路提供給有需求的人員使用，操作方式如下:
1. 直接由電腦桌面開啟程式捷徑，如圖 4-10 所示。
圖 4- 10 開啟 OQC Client 程式
2. 系統起始畫面為功能選單，包含所有系統功能選項，如圖 4-11 所示。
圖 4- 11 系統功能選單
3. 選取交貨紀錄選項，進入收貨作業功能，如圖 4-12 所示。
3. 選取交貨紀錄選項，進入收貨作業功能，如圖 4-12 所示。