單元三：智慧製造案例解析

授課時間：60 分鐘（講授 + 討論） 適用對象：製造業現場主管、生管人員、品管人員、設備維護人員 學習成果：學員完成排程事件分類表、品質缺陷分類表、維修故障分類表

課程導言

各位學員好，歡迎來到第三單元「智慧製造案例解析」。

在前兩個單元中，我們已經了解了工廠資料的常見痛點，也學會了如何正確地向 AI 提問。但在真正讓 AI 幫我們做決策之前，還有一件更根本的事情必須做好——建立標準化的分類體系。

為什麼分類這麼重要？想像一下，你去醫院看病，如果每位醫師對同一種疾病使用不同的病名，病歷就無法交接、統計報表也毫無意義。工廠也是一樣：如果不良品沒有統一的代碼、設備故障沒有標準的字典、排程事件沒有一致的分類，再強大的 AI 模型拿到的都是一盤散沙。

這堂課，我們將透過台灣製造業的真實案例，帶大家學會三件事：

1. 如何設計一套分層的品質缺陷分類系統（Defect Taxonomy）
2. 如何建立設備維修故障分類字典
3. 如何定義排程資料的標準欄位與事件分類

最後，我們會用 5M1E 框架把這三塊資料串連起來，形成完整的數據整合概念。

核心理念：分類是數據分析的地基。地基打不穩，上面蓋什麼都會倒。

3.1 生產瓶頸診斷邏輯

講稿

在進入分類設計之前，我們先建立一個重要的分析概念：生產瓶頸診斷邏輯。

所謂瓶頸（Bottleneck），是指整條生產線中產出速率最慢的那個環節。根據高德拉特（Eliyahu Goldratt）的限制理論（Theory of Constraints, TOC），整條產線的最大產出不會超過瓶頸站的產出能力。換句話說，改善非瓶頸站的效率，對整體產出幾乎沒有幫助。

但問題是——瓶頸不一定是固定的。在實際生產中，瓶頸可能因為訂單組合改變、設備故障、人員異動而在不同站別之間移動。這就是所謂的「漂移瓶頸」（Shifting Bottleneck）。

要診斷瓶頸，我們需要三類資料的交叉分析：

台灣案例：新竹某 PCB 廠的瓶頸診斷

一家位於新竹的 PCB 電路板製造廠，長期面臨交期延遲問題。管理層最初認為瓶頸在壓合製程，因為那是「最貴的設備」。但經過資料分析後發現：

• 壓合站稼動率為 85%，產能充足
• 真正的瓶頸在鑽孔站——因為舊型鑽孔機故障頻繁（每月平均停機 18 小時），加上鑽頭更換需要人工判斷磨耗程度，等待時間長
• 鑽孔站的 OEE 只有 62%，拖累了整條產線

這個案例告訴我們：瓶頸的發現，不是靠直覺，而是靠資料。而資料的前提是——你的排程事件、品質缺陷、設備故障，都要有標準化的分類和記錄。

瓶頸診斷流程

步驟一：收集各站別 OEE 數據
    |
    v
步驟二：找出 OEE 最低的站別（候選瓶頸）
    |
    v
步驟三：拆解 OEE = 稼動率 x 性能率 x 良率
    |
    |-- 稼動率低 --> 檢查設備故障紀錄與停機分類
    |-- 性能率低 --> 檢查排程事件（換線、等料、缺人）
    |-- 良率低   --> 檢查品質缺陷分類與重工紀錄
    |
    v
步驟四：交叉比對三類資料，定位根因
    |
    v
步驟五：制定改善對策，持續監控瓶頸是否轉移

關鍵訊息：瓶頸診斷需要排程、品質、設備三類資料的聯合分析。缺少任何一塊，診斷結果都會失準。

3.2 品質異常分類設計（Defect Taxonomy）

講稿

品質缺陷分類是品管工作的基石。一套好的分類系統，不僅能讓品檢人員快速、一致地記錄不良品，更能讓後續的統計分析和 AI 模型有乾淨的資料可用。

Defect Taxonomy（缺陷分類學）的設計原則有四個：

1. 互斥性（Mutually Exclusive）：每一個缺陷只會歸屬於一個類別，不會同時屬於兩個分類。
2. 窮盡性（Collectively Exhaustive）：所有可能出現的缺陷，都能在分類中找到對應的位置。
3. 階層性（Hierarchical）：從大類到小類，層層細分，便於不同層級的分析需求。
4. 可操作性（Actionable）：分類名稱要直覺易懂，品檢人員在產線上能快速判斷。

分層分類架構

我們建議採用三層分類架構：

第一層：缺陷大類（Category）
  └─ 第二層：缺陷中類（Sub-category）
       └─ 第三層：缺陷細類（Detail）

台灣案例：桃園某電子連接器廠的缺陷分類表

這家位於桃園的電子連接器製造商，原本有超過 50 種不良代碼，但許多代碼定義模糊、使用率低，品檢員經常隨意選擇，導致 Pareto 分析失準。經過重新設計後，他們採用了以下三層架構：

不良代碼命名規則

代碼結構：[大類英文字母][中類序號]-[細類序號]

範例：A2-03
  A  = 外觀缺陷（大類）
  2  = 成型異常（中類）
  03 = 變形（細類）

這套命名規則的好處是：只看代碼就能知道缺陷的層級歸屬，不需要查表就能大致理解缺陷類型。

品質缺陷分類資料結構（Data Schema）

以下是建議的品質缺陷紀錄欄位設計：

關鍵訊息：欄位設計不只是為了「記錄」，更是為了後續的「分析」。每筆紀錄都要能串聯到工單、機台和人員，才能進行 5M1E 的交叉分析。

3.3 不良代碼分層分類系統

講稿

上一節我們看了連接器廠的案例，這一節我們把分層分類的概念推廣到更多產業。

台灣製造業跨越多種領域，每個領域的缺陷型態不同，但分層分類的邏輯是相通的。以下是三個產業的分類對比：

跨產業不良代碼分類對比

嚴重等級定義

不論哪個產業，每筆不良紀錄都需要標示嚴重等級：

台灣案例：台中某汽車零件沖壓廠

這家位於台中的汽車零件供應商，為國內某知名車廠供應車門鉸鏈。過去他們只使用兩個不良代碼：「外觀不良」和「尺寸不良」，導致每次客訴時都無法快速追溯問題來源。

導入三層分類系統後：

關鍵訊息：分類不是越多越好，也不是越少越好。要在「分析精度」和「操作便利性」之間找到平衡。一般建議大類 4-6 種、中類每大類 3-5 種、細類每中類 2-5 種。

3.4 設備維修履歷標準化設計

講稿

設備維修資料的標準化，是實現預測性維護（Predictive Maintenance）的先決條件。如果維修紀錄只有「修好了」三個字，AI 什麼都學不到。

維修履歷的標準化有三個重點：

1. 維修事件分類：區分計畫性保養、故障維修、改善維修等不同類型。
2. 故障分類字典：建立統一的故障代碼和故障描述。
3. 時間與成本紀錄：精確記錄停機時間、維修工時、更換零件與費用。

設備維修紀錄資料結構（Data Schema）

維修事件類型定義

3.5 維修故障分類字典建立

講稿

故障分類字典是設備管理的「共通語言」。就像醫師使用 ICD 國際疾病分類碼一樣，工廠也需要一套統一的故障分類體系，讓不同班別、不同廠區的維修人員都能用相同的標準記錄故障。

故障分類字典模板

以下以 CNC 加工設備為例，展示故障分類字典的建立方式：

台灣案例：高雄某精密機械廠的故障字典

高雄一家精密機械零件加工廠擁有 35 台 CNC 加工中心，過去維修紀錄全靠自由文字描述。同一個故障，不同維修師傅的記錄千差萬別：

• 師傅 A 記錄：「主軸有聲音」
• 師傅 B 記錄：「spindle noise at high RPM」
• 師傅 C 記錄：「軸承快壞了」

導入故障分類字典後，以上三種記錄統一為代碼 M1-01-A（主軸系統 > 軸承 > 磨損），搭配自由文字補充細節。半年後的成效：

關鍵訊息：故障分類字典不是要取代維修師傅的經驗，而是把經驗轉化成結構化的資料，讓 AI 能從中學習規律。

3.6 排程資料欄位設計與事件分類

講稿

排程資料是連結訂單與產線的橋樑。標準化的排程資料設計，不僅讓生管人員能即時掌握產線狀態，也是 AI 排程優化的資料基礎。

排程資料欄位設計

排程事件分類表

排程事件分類用於記錄所有影響排程執行的異常狀況，是分析生產效率損失的關鍵：

關鍵訊息：事件分類必須綁定「責任歸屬」，這不是為了追究責任，而是為了讓改善對策能找到正確的推動單位。

3.7 5M1E 數據整合概念

講稿

到這裡，我們已經分別學了品質缺陷分類、設備故障分類、排程事件分類。但在實際的智慧製造中，這三塊資料不是各自獨立的——它們必須整合在一起，才能發揮真正的分析價值。

5M1E 是製造業經典的分析框架，涵蓋了影響品質與生產的六大要素：

5M1E 數據整合架構圖

flowchart TD
    PLATFORM["5M1E 數據整合平台"]
    PLATFORM --> M1["Man 人員"]
    PLATFORM --> M2["Machine 機器"]
    PLATFORM --> M3["Material 材料"]
    PLATFORM --> M4["Method 方法"]
    PLATFORM --> M5["Measurement 量測"]
    PLATFORM --> ENV["Environment 環境"]

    M1 --> WHO["WHO → 操作人員工號"]
    M2 --> WHERE["WHERE → 機台編號"]
    M3 --> WHAT["WHAT → 材料批號"]
    M4 --> HOW["HOW → SOP/配方版本"]
    M5 --> CHECK["CHECK → 量測設備編號"]
    ENV --> WHEN["WHEN → 環境參數快照"]

    WHO & WHERE & WHAT & HOW & CHECK & WHEN --> TRACE["有了這六個欄位<br>就能把任何一筆不良品<br>追溯到完整的生產情境"]

    style PLATFORM fill:#2ecc71,stroke:#333,color:#fff
    style TRACE fill:#1e40af,stroke:#333,color:#fff

5M1E 整合資料 Schema 範例

以下是將 5M1E 概念落實到單筆生產紀錄的欄位設計：

5M1E 交叉分析矩陣

當品質異常發生時，可運用 5M1E 框架進行交叉追查：

台灣案例：台南某精密軸承加工廠的 5M1E 整合

台南一家專精精密軸承的加工廠，良率長期徘徊在 96% 左右。品管人員做了大量 Pareto 分析，但始終找不到關鍵因子。

導入 5M1E 數據整合後，他們發現了一個過去完全忽略的交互效應：

• 單看 Man：各操作員的良率差異不大（95.5%-96.8%）
• 單看 Machine：各機台的良率差異不大（95.2%-96.5%）
• 交叉分析 Man x Machine x Environment：特定操作員在特定機台上、環境溫度超過 27 度 C 時，良率驟降至 91%

根因是：該操作員的研磨手法在高溫環境下會導致冷卻液蒸發過快，造成工件尺寸偏差。這個問題只有在「人 + 機 + 環境」三個因素同時出現時才會發生，單看任一維度都看不出來。

關鍵訊息：5M1E 的價值不在於個別維度的分析，而在於交叉分析。這正是 AI 最擅長的事——從多維度資料中找出人類不容易察覺的交互模式。

重點回顧

三大分類體系總結

flowchart TD
    TITLE["智慧製造資料分類三支柱"]
    TITLE --> P1["支柱一：品質缺陷分類<br>Defect Taxonomy"]
    TITLE --> P2["支柱二：設備故障分類<br>Fault Dictionary"]
    TITLE --> P3["支柱三：排程事件分類<br>Schedule Event"]

    P1 --> P1A["三層架構：大類 → 中類 → 細類"]
    P1 --> P1B["命名規則：英文字母 + 數字編碼"]
    P1 --> P1C["設計原則：互斥、窮盡、階層、可操作"]

    P2 --> P2A["三層架構：系統 → 組件 → 故障模式"]
    P2 --> P2B["搭配典型症狀描述"]
    P2 --> P2C["串接維修事件類型<br>BM / PM / CM / PdM / EM"]

    P3 --> P3A["六大事件類別<br>設備/物料/人員/品質/排程/外部"]
    P3 --> P3B["綁定責任歸屬"]
    P3 --> P3C["記錄延遲時間，量化效率損失"]

    P1 & P2 & P3 --> INT["整合框架：5M1E<br>透過共同欄位串接三類資料<br>實現交叉分析"]

    style TITLE fill:#2ecc71,stroke:#333,color:#fff
    style P1 fill:#3498db,stroke:#333,color:#fff
    style P2 fill:#e67e22,stroke:#333,color:#fff
    style P3 fill:#9b59b6,stroke:#333,color:#fff
    style INT fill:#e74c3c,stroke:#333,color:#fff

核心觀念

1. 分類是分析的前提：沒有標準化的分類代碼，就沒有可靠的統計分析，更不可能訓練有效的 AI 模型。

2. 三層分類架構通用於各產業：無論是品質缺陷、設備故障還是排程事件，都可以用「大類 > 中類 > 細類」的三層架構來組織。

3. 5M1E 是數據整合的框架：將人、機、料、法、測、環六個維度的資料串接起來，才能發現隱藏的交互效應。

4. 資料結構設計要考慮 AI 需求：欄位設計不只是為了「記錄」，更是為了後續的「分析」。每筆紀錄都要能追溯到 5M1E 的完整情境。

討論問題

請各組選擇 1-2 題進行討論（每組 10-15 分鐘），並準備向全班分享你們的想法：

問題一：分類粒度的取捨

你的工廠目前有多少種不良代碼？你覺得是太多、太少、還是剛好？如果要重新設計，你會怎麼決定分類的層級和數量？請考慮品檢人員的操作負擔和數據分析的精度需求。

問題二：故障字典的建立策略

假設你負責為工廠建立設備故障分類字典，但維修團隊中有資深師傅認為「每台機器的狀況都不一樣，標準化分類太僵硬」。你會如何說服他們？又如何在標準化與彈性之間取得平衡？

問題三：跨部門資料整合的挑戰

在 5M1E 的架構中，資料分散在不同部門（生管、品管、設備、資材、人資）。你認為推動跨部門資料整合，最大的阻力是什麼？你會建議從哪一個面向先開始整合？為什麼？

問題四：從資料到行動

假設你已經建立了完整的三類分類系統和 5M1E 整合資料，你認為 AI 可以從中發現哪些「人類不容易看出來」的模式？請舉一個你工廠中可能存在的例子。

自我評量

請選擇最適當的答案（單選）：

題目一

在 Defect Taxonomy（缺陷分類學）中，「互斥性」（Mutually Exclusive）原則指的是什麼？

• (A) 每一種缺陷都必須有對應的改善對策
• (B) 每一個缺陷只會歸屬於一個類別，不會同時屬於兩個分類
• (C) 所有可能出現的缺陷，都能在分類中找到位置
• (D) 分類名稱要讓品檢人員在產線上能快速判斷

正確答案：(B) 解析：互斥性確保每個缺陷只有唯一的分類歸屬，避免同一筆不良品被歸到不同類別，造成統計重複。(C) 描述的是「窮盡性」，(D) 描述的是「可操作性」。

題目二

以下哪一個維修事件類型的代碼代表「依據感測數據預判，提前進行維修」？

• (A) BM（Breakdown Maintenance）
• (B) PM（Preventive Maintenance）
• (C) CM（Corrective Maintenance）
• (D) PdM（Predictive Maintenance）

正確答案：(D) 解析：PdM（Predictive Maintenance，預測維修）是基於設備的即時感測數據（如振動、溫度、電流），透過分析趨勢來預判設備何時可能故障，並提前安排維修。BM 是故障後才修，PM 是按固定時間保養，CM 是針對重複故障進行根本改善。

題目三

在 5M1E 數據整合框架中，「M」不包含以下哪一項？

• (A) Man（人員）
• (B) Machine（機器）
• (C) Management（管理）
• (D) Material（材料）

正確答案：(C) 解析：5M1E 的五個 M 分別是 Man（人員）、Machine（機器）、Material（材料）、Method（方法）、Measurement（量測），加上 E 代表 Environment（環境）。Management（管理）不在 5M1E 的標準定義中。

題目四

台南精密軸承加工廠的案例中，良率驟降的根因最終是透過什麼方式發現的？

• (A) 單獨分析每台機器的故障紀錄
• (B) 比較不同操作員的良率表現
• (C) 對 Man、Machine、Environment 三個維度進行交叉分析
• (D) 請資深師傅憑經驗判斷

正確答案：(C) 解析：該案例的關鍵在於——單看任何一個維度（人員、機台、環境）都看不出問題，只有在進行 Man x Machine x Environment 的交叉分析時，才發現特定操作員在特定機台上且高溫環境下良率驟降的模式。這正是 5M1E 整合分析和 AI 多維度資料探勘的核心價值。

題目五

以下關於排程事件分類的描述，何者正確？

• (A) 排程事件只需要記錄設備相關的異常
• (B) 每個事件分類都需要綁定「責任歸屬」，以便找到正確的改善推動單位
• (C) 排程事件分類越細越好，建議至少 100 種以上
• (D) 外部因素（如天災）不需要納入排程事件分類

正確答案：(B) 解析：排程事件分類需要涵蓋設備、物料、人員、品質、排程、外部因素等六大類（非僅設備）。每個分類綁定責任歸屬不是為了「追究責任」，而是為了讓改善對策有明確的推動單位。分類數量要在分析精度與操作便利之間取得平衡，並非越多越好。外部因素雖不可控，但仍需記錄以完整分析產能損失。

延伸閱讀與參考資料

• 工業技術研究院（2025）。台灣中小製造業智慧轉型路徑白皮書。
• 台灣區電機電子工業同業公會（2025）。電子製造業品質管理數位化指引。
• Goldratt, E.M. (1984). The Goal: A Process of Ongoing Improvement.
• ASQ (2024). Defect Classification and Coding Systems: Best Practices Guide.
• ISO 14224 (2016). Petroleum, petrochemical and natural gas industries — Collection and exchange of reliability and maintenance data for equipment.

本單元結束｜下一單元：單元四 — 工具操作：AI 產線助理