Page 103 - Vol.43
P. 103
圖12、All Chart SPC系統，管理Chart一站完成
口完成所有SPC設定。 實際插旗系統時，Trend如 圖14所示，該區段不計算
• 改善OI與系統不同步 : 現行廠務OI為手動傳簽、手動 SPC與不發警報。
填寫，簽核後再依OI簽准案手動設定iEDA，故在執行
上容易發生人為疏失。圖13所示，FAB TB透過TCP系
統控管設定值，廠區由ACE平台選取項目，全自動傳
簽ECP。All Chart SPC系統將把紙本OI，全數轉為數
位化OI，簽核管理皆為電子化，簽核完成直接設定系
統。另外TCP也是管理框架，AEC則是實際的點位，
未來管理上所有Lesson Learnt水平展開時，都必須要
圖13、FAB vs FAC SPC Chart設定管理
看到新系統必須要在TCP及AEC上完整建制，才算完
成管理系統。
• SPC涵蓋範圍不夠 : 我們期許能將大部分監控設備以
Inline方式掌握現場情形，以避免有異常情形發生而
晚被通知，但仍有大部分在執行Inline上有困難只能
以Offline方式來抽樣檢測，故在All Chart SPC系統未
來也將整合這些Offline納入系統一併通知工程師，並
且再分析問題時可以納入Offline的Chart如CHAD、
MQR、及COA的資料來分析。而整個SPC含蓋範圍將
由目前3%(Keynode Chart/General Chart)，再持續
推進28%，最終100%的有Chart就要管的程度，並且
我們選擇以ICCI來做我們整合的最終平台。 圖14、插旗系統，插旗期間，該段不計算SPC及不發警報
• 廠務Data Integrity疑慮 : 因為PM、Trouble
Shooting、工程時，過往皆使用ROFS(Remote of ③ 導入適當統計管理辦法 : 廠務系統除了供應穩定的
Force Scan)，此功能是試車或是Commission專用功 Utility，也要因此面對外部的環境，而如何處理這些
能，而當廠務有Activity時，皆使用此功能來避免警 資料，並針對每種Utility設計最適當的統計管理辦
報過多導致值班室捆擾，但使用功能時會導致上傳資 法，讓廠務運轉更有效率。以下為經過QM(Quality
料為一條線，恐有Data Integrity疑慮。故設計一插旗 Management)、STAT(統計應用技術部)，所設計的廠務系
系統，一但插旗期區段不計算SPC及不發警報，而達 統各Utility SPC管制辦法如 表4。
到原汁原味資料上傳及值班室不會無法值班的目的。
FACILITY JOURNAL 09 2021 101
