摘要

Facility daily management Platform planning

日常管理落實–開關門十件事看板規劃

關鍵詞/ 循環式品質管理2、日常管理、關鍵績效指標2敏捷式專案管理2
Keywords / PDCA2,Daily Management,KPI2,Agile Project Management
本文以台積電的品質管理為開頭,說明落實日常管理在企業營運及策略中的重要性,探討日常管理是如何利用PDCA的管理循環,去建立日常考核的關鍵績效指標(KPI)。並且進一步的將日常管理落實在廠務的主要工作任務上,從中我們得知現有的管理平台不足以支援工程師進行有效率的日常管理,為改善此現象,我們建立跨部門的專案團隊,收集竹中南三個廠區的日常管理項目完成初版具有全員共識的KPI項目,並導入「敏捷式專案管理」方法重新設計整合管理平台,最終於9月完成初版系統上線。後續對使用者進行問卷調查,分析結果得到具體的回饋建議,以此作為日後第二階段持續完善系統的參考。
文字設定:

前言

台積在品質管裡的四個階段[1] : ①品質檢驗(QI)、②品質管制(QC)、③品質保證(QA)、④全面品質管理(TQM)已經進展到最後的TQM階段。TQM最重要的精神就是管理每一個細節,透過各個環節的完整管理達到高品質的最終產品。為達成有效率且完整的日常管理,本文將探討如何規劃一套符合廠務運轉並與工廠品質管理精神同步的平台,透過合理且一致的管理項目,凝聚廠務所有人的共識,進而建立相同的價值觀,並透過完整資訊提供及人性化的操作平台,讓工程師願意執行日廠管理,藉此達成落實執行日常管理的目標。

文獻探討

中國生產力中心張寶誠總經理在「日常管理奠定績效基本功」[2]文章中認為日常管理的目的,在於促成個人與團隊每日專注於達成目標過程的持續改善,透過建立日常考核的關鍵績效指標(KPI),讓組織成員以數字管理及自主管理模式,達成組織設定的目標。 藉由建立可視化報表,進行異常反饋及問題解析的參考,達成不斷進步的迴圈。

在上述觀念中第一個提到的就是關鍵績效指標(KPI),也就是日常管理成敗的核心。因為廠務的主要任務是提供工廠生產所需的高品質Utility,因此在品質管理精神以必須跟上甚至超越工廠品質管理的腳步。

Fab日常管理的概要項目→表1,其中可以看出廠內所共同重視的包含列為第一的可靠度,列為第二第三的產出狀況,以及列為第四用來找出系統變異的SPC。後續則是依照任務不同所制定的異常管理,PM管理,施工管理及人員管理。

表1、日常管理項目
製程(課) 製程(工程師) 設備(課) 設備(工程師)
Defense KPI Defense KPI Defense KPI Defense KPI
Productivity Productivity Productivity Productivity
Hold lot Hold lot Line status Line status
In-line & off-line SPC In-line & off-line SPC off-line SPCC off-line SPCC
In-line Defect In-line Defect In-line Defect In-line Defect
Issue/Event/AR   FDC review FDC review
人員出勤狀況&宣導   Tool PM  
    Daily派工  
    人員出勤狀況&宣導  

廠務依照此精神進行台積廠務各廠區的交接項目及管理平台現況調查→表2,我們確認現行的管理平台並不足以支援工程師進行有效的日常管理。

表2、平台調查表

需改善 ▲、無:X

分類 Review item F15B 14A 14B Remark
人員管理 1 . 總人數/出勤/值班/請假/出差/需關懷 onefac onefac onefac  
2. 各課值班人員/電話 Alarm 即時通(廠務值班與 製造部值班/副理/部經理) efac ▲ efac ▲ F12 : 護貝紙本 F14 : 缺值班人員電話
3. TXM 人數 TXM工時管理系統 TXM工時管理系統 TXM工時管理系統  
施工管理 1 . 施工總件數/ LV1/LV2/一般工程/高風 險區工程 onefac ▲ onefac ▲ onefac ▲ F14 : 缺高風險區工程
2. 高風險人員/廠商人數 VMS 風險控管平台 風險控管平台 F12 : 缺高風險人員
警報/變更 1 . Alarm 100 /200 /300 數量,警報隔離, 即時警報未復歸--- (F15) onefac DIP onefac ▲ onefac ▲ F14 : 缺300數量,警報隔離, 即時警報未復歸
2. 參數變更(IPRS) IFPMS(P5/P6) ; 參數變更 Tool (Group/Golden) ECM ECM  
3. Wait FAC onefac onefac onefac  
4. Blue book matching rate X X X  
今日PM PM數量/PM未回報/PM執行逾期/異常追 蹤/簽核逾期/CM執行逾期 onefac ▲ onefac ▲ onefac ▲ F14 : 缺CM執行逾期
線上狀態 值班交接宣導 通報事項(Call in ) X 值班組長Daily Mail&值班 守則 ▲ 值班組長Daily Mail & 值班 守則 ▲  
巡檢異常 X X X  
強供 X X X  
環保/環境 1 . 空汙/水汙未達標點數 THC污染物雲端監控 onefac onefac  
2. 空污排放連續監測CEMS VOC上傳科管局日報 CEMS CEMS  
3. 台電備轉容量 onefac onefac onefac  
4. 外氣數值 onefac onefac onefac  
5. 天然災害預警 onefac ▲ onefac ▲ onefac ▲ F14 : 需搜尋後連結到天然 災害預警系統
系統可靠度 2. N+1 Fail onefac onefac onefac  
用量管理 Tank Level(Level 1/Level 2/Level 3) onefac onefac onefac  
供應品質 SMP 點數 1. OOC, OOS, Median Shift>30%, RSR > 3% onefac onefac onefac  
2. F-Charter warning 點數 F-Charter F-Charter F-Charter  
3. Off-line(COA, SCAD, MQR ) X Chemical Lab on ECP ▲ Chemical Lab on ECP ▲  

在6個廠區23個項目共138個平台功能中只有66個是由Onefac廠務共同平台所提供,其中甚至有16個平台功能並未建立,而是以紙本或Excel進行管理,其資料歷史紀錄及透明度在未來的分析改善工作中將無法提供足夠的資訊。

故本文將以建立一套有效的管理平台為方向,並以落實日常管理為研究目標。

平台設計原則方面

此次目標設定為9月完成系統初版上線,第一階段以滿足部經理管理需求為目標,因此將平台設計區分為提供客觀資訊的管理層,進一步提供處理結果的檢查層,最後才是提供工程師詳細資訊及回報功能的操作層。

綜合以上研究結果,平台設計方面將包含管理層,檢查層及操作層三類主要模組為基本設計→圖1,再透過持續的回饋修正達到不斷進化,漸趨完整的設計,打造客製化的高效率平台。

圖1、三個模組平台設計

專案團隊建立方面

2001年由Kent Beck、Mike Beedle、Arievan Bennekum等17位著名敏捷式開創者共同制訂了敏捷開發宣言[3],再由四項敏捷宣言延伸出的敏捷開發十二項原則,我們擷取其中第4~9項來做為專案團隊建立的指導原則,建立一個由專案贊助者,開發人員以及使用者組成的開發及持續改善團隊來負責執行專案開發及推展[4]

  1. 最為優先的事情是透過早期與持續交付有價值的軟體來使客戶滿意。
  2. 歡迎需求的變動,即使是在開發的末期。敏捷式流程駕馭變動來作為客戶的競爭優勢。
  3. 頻繁的交付工作產生的軟體,自數週至數月,週期越短越好。
  4. 領域專家與開發成員必須一同作業,並貫穿整個專案開發時期。
  5. 引入積極的工作成員來建構專案,給予他們環境以及支援所需的一切,然後信任他們能夠完成工作。
  6. 在開發團隊中最快也最有效的傳遞資訊方法是面對面的溝通。
  7. 可用的軟體是衡量進度最主要的依據。
  8. 敏捷程序提倡可持續的開發。
  9. 專案贊助者,開發人員以及使用者都必須持續維持一致的步伐。
  10. 持續重視技術的優勢以及設計品質。
  11. 最好的架構、需求以及設計會出現在能夠自我管理的團隊裡。
  12. 在規律的反覆之間,團隊會反省與思考如何更有效率,然後相對的來調整與修正團隊的開發方式。綜合以上探討歸納出未來發展方向→表3
    表3、未來發展方向
    成功關鍵 研究方向
    全員共識的KPI 如何整合全員共識
    高度整合的平台設計 整合方向及高效率的平台設計
    專業多元的開發團隊 建立專業的團隊及合作機制

研究方法

3.1.全員共識的KPI _整合全員共識

為建立全員共識的KPI,必須滿足全面性及一致性,為達此條件竹中南針對現行各課晨夕會交接項目已進行完整調查。先取其聯集作為基礎,討論其價值及合理性後完成初版KPI項目。而後透過部經理的管理Workshop取得建議及支持。其流程如→圖2

圖2、建立全員共識的KPI流程

3.2.高度整合的平台設計

為滿足9月完成系統初版上線,第一階段以滿足部經理管理需求的目標。我們將資訊看板設計為三個層次模組,其主要目的在於可以分階段有效執行。由於關鍵指標最終確定下來包含136項,其整合極為複雜,因此我們採取的主要策略為第一階段先開發「廠務資訊看板」的管理層及檢查層,將管理資訊提供出來,操作層則先沿用原系統。到第二階段再將操作層進行跨廠整合或重新開發,最終所有系統都將以廠務資訊看板為源頭得到一致化的管理,進而達到管理機制一致化,資訊完全流動的目的。

3.3.建立專業的團隊及合作機制

首先將136個關鍵指標依照屬性分為十個看板群組如→圖3。分別由十位FMCS工程師進行細部設計,設計理念為直覺、快速,不必訓練也能操作的資訊看板。其設計人員必須負責與IT連線,並與系統工程師確認操作方式→圖4

圖3、十個看板群組原始設計

圖4、看板負責工程師職責

每個看板群組均安排一位主要設計人員,各廠區配合工程師則負責提供廠區意見及資料取得路徑。並於檢查層建立趨勢圖及日報表提供可視化分析工具→圖5

圖5、資訊看板分析報表

結果與分析

根據以上設計,經過兩次Workshop(開發前、 90% design),最終於9月成功將初版上線,過程中的Milestone與Schedule透過每周會議進行檢討追蹤→圖6。可透過辦公電腦及T-phone查詢資訊看板。實際網頁如→圖7圖8

圖6、資訊看板Schedule

圖7、電腦版資訊看板

圖8、手機板資訊看板

在本次開發系統時,結合以往平台開發經驗,由於眾多資訊含在平台內,故在檢查層內放入小書,方便使用者看各別KPI時,若有資料流、資料來源等問題,可自行查看 ,如同→圖9所示。

圖9、各KPI資料流

初版系統上線經過了一段使用時間後,我們便開始對使用者進行問卷調查,雖然普遍獲得好評,但還是有不少使用者具體的回饋意見,能夠作為未來第二階段精進系統的方針。

系統上線後針對使用者進行問卷調查結果及分析→圖10圖11

圖10、使用者調查結果分析

圖11、具體建議

系統上線後針對目前資訊看板的使用狀況分析如下 :

除了針對使用者做問卷調查去的獲得最直接的回饋意見,另外我們也針對資訊看板上線後新竹台中台南各廠至今的使用狀況進行分析,從逐月的統計資料→圖12可以得知。

圖12、資訊看板使用人數

在資訊看板上線初期的2019年10月份,不管是登入使用人次還是各資訊看板被日常管理人員確認的次數都是相對較少 ,可想見系統剛上線初期尚未被大家廣泛的使用,只有少許廠務人員會使用此系統來執行日常管理,但經過一個月的宣導後可以看到登入使用人次與看板確認次數皆有顯著的提升,登入使用人次維持在13500人次左右,各看板確認次數維持在16000左右,從這些數據我們理解到,資訊看板系統上線後,讓各單位有更方便落實日常管理的方式,因此大家對於資訊看板的依賴程度日漸提升,儘管如此我們也從個別看板的分析中發現還能再改進的地方,如果從各看板的確認次數來看→圖13

圖13、各看板確認次數

我們可以發現最常被確認的看板集中在人員管理、PM管理以及施工管理這三個看板,這些也是廠務日常管理中最基本的項目,相較於這三個看板,其餘七個看板的次數相對減少許多,歸納其差別,主要原因為這三個看板,已經行之有年 。因此在未來應該要設想如何更落實每個資訊看板都能在各單位的日常管理中被確認,以及紅黃燈項目的回覆率提升。 例如設計燈號顯示該看板尚未被確認,藉由燈號提醒日常管理者,或是藉由看板日報表產出各看板未確認的單位並以信件提醒,這都是能夠再把資訊看板使用率更往上提升的方式。 

從上述建議我們整理出以下四點作為第二階段的改善方向:

  • 提高現有系統資料正確性及效能
  • Workshop未完成的結論
  • 作法尚未成熟而無法上線的指標
  • 課級指標,值班及個人工作由看板進行控管

我們以這四點方向為基礎,結合問題報報平台所回報的問題,歸納出第二階段的工作項目,如→表4表5所示。

表4、第二階段開發進行中項目
開發階段 類別 看板 管理指標 廠區 Sponsor 待辦/備註
2 功能設計調整 供應品質 Offline資訊 F14 立得

請協助align需求與功能設計

吉修 : OOC/OOS顯示紅燈,Per_alert待12/E ICCI

dashboard完成後link(20191031更新)

澄清管理與資料需求後向chem.lab summary KPI的biz owner洽談資料在chem.lab summary KPI中的位置吉取得方式;同步找IT oener與意中/智瑋談資料如何落地(20191128更新)

專案會議決議列為第二階段開發項目(20191219更新)

2 功能調整 供應品質 Offline資訊 NF 智瑋 專案會議決議列為第二階段開發項目(20191219更新)
2 日報表開發 All All NF 智瑋

規劃中(20191024需求確認完成)

變更管理需求待確認(20191128更新)

專案會議決議延至第二階段開發(20191128更新)

初版開發完成,請各廠確認中(20191213更新)

表5、第二階段待開發項目
看板 層次 待開發/待修正
環保/環境 檢查層 考量資料即時與一致姓,大氣壓力SPEC資料來源改由廠務DB抓
供應品質 檢查層 OCAP逾期未簽核狀態
環保/環境 檢查層 新竹水情請加入石門及永和山水庫(看板中獨立列,部與寶山&寶二加總)
環保/環境 管理層 Phase選項需要調整成部重複(例如只保留F12P1/2、F12P45、F12P3&F3E併成F12P3E)
施工管理 檢查層 施工品質管理新增Hookup單位(選擇任一單位下都會顯示)
All All 資料正確性確認(大/小夜值班人員;空/水污、外氣tag與Spec.;廠商發卡/訓練紀錄;N+1/桶槽監測設定資料)
All All 資料完整性確認(需監測的系統/桶槽;6/8吋廠資料、新廠資料)
All All 執行落實度確認(廠商出工處;工時異常原因;高風險工程/人員;警報/參數變更原因;Wait FAC歸屬單位)
All All 課級化指標
All All 三班制交接確認功能
All All 分Phase組織交接功能
環保/環境 管理層 加入地震預警系統
系統可靠度 管理層 Capacity要加進N+1一起看
警報/隔離 作業層 原因填寫時要帶出前幾次填寫原因
用量管理 管理層 台積大車隊資訊加入
PM管理 管理層 只要有CM就要列出來(目前只HLCM逾期)
供應品質 管理層 加入AMC濃度分布
供應品質 管理層 加入OOB指標
供應品質 管理層 加入F-Charter
供應品質 管理層 加入ICCI
變更管理 管理層 Local參數變更要加入當日的參數變更資訊
變更管理 管理層 Local參數變更要設定有沒有要改回來,若逾期沒改回來系統要HL
All 檢查層 確認率、回覆率報表

到截稿前已有第二階段功能列表共26項,其中3項需求已經在開發進行中,14項需求尚未確認需待看板負責人澄清與設計功能,9項需求進入設計階段。為了讓系統更趨完善,消化並檢討使用者建議是必要的,目前尚有部份工程師與主管的建議未被納入,我們將會持續推動精進這套系統,並將這些建議轉化成實際功能項目,相信藉由我們的努力,一個資訊完整又及時且具人性化的日常管理平台指日可待。

結論

成功的資訊看板必須具備全員共識的KPI、高度整合的平台設計及專業多元的開發團隊。為達成以上目的,我們透過舉辦Workshop統一大家的意見,並組成橫跨NFD, FMCS及各專業的開發團隊。最終成功達成9月上線的目標 。惟如何降低工程師的工作負擔,將於第二階段發展持續精進並趨於完整。

參考文獻

  1. 中國生產力中心全面管理組,TQA 全面品質保證手冊,台北市,中國生產力中,1998。
  2. 張寶誠,日常管理奠定績效基本功,台北市,中國生產力中, 2009。
  3. 敏捷軟體開發宣言,2001。http://agilemanifesto.org/iso/zhcht/manifesto.html
  4. Robert Cecil Martin著 ; 林昆穎、吳京子譯,敏捷軟體開發:原則 、樣式及實務,碁峰資訊,台北市 : 台灣培生教育,2005。

留言(0)

Further Reading延伸閱讀