QIF 導入指南（中）｜從 Use Case、系統盤點到資料定義，開始 QIF 導入前先做這 6 件事

上一集（延伸閱讀：QIF 導入指南（上）｜手上有 CAD、CMM、量測軟體，就能導入 QIF 嗎？）我們先釐清了一件很重要的事情：

企業導入 QIF（Quality Information Framework，品質資訊框架），通常不是去購買一套獨立的「QIF 軟體」。

真正需要確認的是，企業現有的 CAD（Computer-Aided Design，電腦輔助設計）、量測軟體、QMS（Quality Management System，品質管理系統）、MES（Manufacturing Execution System，製造執行系統）或 PLM（Product Lifecycle Management，產品生命週期管理）等系統，能不能在需要的地方產生、讀取或轉換 QIF 資料。

因此，在正式進入實際應用階段之前，建議先完成一次 QIF 導入準備度盤點。了解一下：

企業有沒有明確的使用情境、系統之間有沒有可以串接的資料、資料定義是否一致，以及現有軟體到底具備多少 QIF 能力。

一、先決定：這次導入 QIF，到底想解決什麼問題？

這應該是整個專案的第一個問題。

很多企業在接觸 QIF 時，很容易直接從技術開始：

• 「哪一套 CAD 支援 QIF？」

• 「哪一套量測軟體可以 Export QIF？」

• 「我們要不要買 Converter？」

但更重要得是，要清楚知道「我們為什麼需要 QIF？」

因為不同的需求，會導向完全不同的導入方式。

---

1. 量測結果進入 QMS

假設目前流程是：

CMM
 ↓
Measurement Software
 ↓
Excel / CSV
 ↓
人工整理
 ↓
QMS

如果目前最大的問題，是量測完成後還需要人工整理資料，再輸入 QMS，那麼第一個 QIF Use Case（使用情境）可以很單純：

Measurement Software
        ↓
    QIF Results
        ↓
       QMS

這時候專案的重點會放在：

• 量測結果怎麼輸出

• QMS 怎麼接收

• Characteristic（特性）怎麼對應

• Result（結果）怎麼判定

• ID（識別碼）怎麼追蹤

企業不需要同時處理完整的產品定義與所有 CAD 資料。

---

2. 檢驗計畫傳給量測軟體

另一種情況是：

CAD / Engineering
       ↓
Inspection Planning
       ↓
Measurement Software
       ↓
      CMM

目前檢驗規劃人員建立完檢驗項目之後，量測人員還需要重新建立量測程式。

那麼 QIF 可以被放在：

Inspection Planning
       ↓
    QIF Plans
       ↓
Measurement Software

這時候需要處理的問題，就從「量測結果」往前延伸到「檢驗計畫」。

---

3. 從產品定義一路追到量測結果

如果企業希望建立完整的資料關聯：

Product Definition
        ↓
Feature / Dimension / Tolerance
        ↓
Inspection Plan
        ↓
   Measurement
        ↓
      Result
        ↓
       QMS

這時候就會開始涉及 CAD、MBD 與 PMI。

MBD（Model-Based Definition，基於模型的定義）讓產品定義中的幾何與工程語意可以更完整地被數位流程使用。

這類 Use Case 的導入範圍自然會比單純交換量測結果更大。

---

所以企業在評估導入QIF前，最先要思考的是

企業目前最需要改善的資料流程是哪一段？

這個問題確定之後，才知道要盤點哪些系統、哪些資料，以及需要多少 QIF 能力。

二、把現在的流程畫出來，先看資料到底卡在哪裡

Use Case 確定之後，下一步要把企業現在的流程，也就是 As-Is Process（現況流程）畫出來。例如：

CAD
 ↓
Engineering Review
 ↓
Inspection Planning
 ↓
Measurement Software
 ↓
CMM
 ↓
Excel / CSV
 ↓
QMS

接下來逐段檢查：

• 哪裡需要人工輸入？

• 哪裡需要重新建立資料？

• 哪裡需要 Excel？

• 哪裡需要 CSV？

• 哪裡需要人工確認？

• 哪裡容易發生版本不一致？

• 哪裡的資料無法回溯來源？

• 哪裡的資料到了下一個系統之後，失去原本的關聯？

這一步很重要，因為很多企業真正的問題是：

同一筆資料被建立很多次，而且每次建立的方式都不一樣。

例如一個產品的孔徑，在 CAD 裡定義過一次，檢驗計畫再建立一次，量測程式再輸入一次，QMS 又建立一次。

如果每一個系統都需要重新建立，那麼即使企業擁有完整的數位系統，資料仍然可能持續斷裂。

因此，QIF 導入的第一個價值判斷，可以簡化成：

哪些資料現在被重複建立？哪些資料其實已經有了，卻還要再輸入一次？

這些地方通常就是值得優先處理的資料斷點。

三、盤點現有系統：不要只問「支不支援 QIF」

流程畫完之後，接下來進入系統盤點。

供應商的軟體支援QIF，接下來才是重點。因為「支援 QIF」可能代表很多不同事情。

有些系統可以輸出 QIF、有些可以輸入 QIF、有些只支援特定資料類型、有些可以透過 API（Application Programming Interface，應用程式介面）取得資料，但沒有原生 QIF、有些則需要另外安裝模組。

因此，建議企業直接用 Capability Assessment（系統能力盤點）的方式確認。

系統	主要用途	QIF 輸出	QIF 輸入	API	Converter	主要資料
CAD	產品定義	✓ / ✗	✓ / ✗	✓ / ✗	✓ / ✗	Part、Feature、PMI
Measurement Software	量測	✓ / ✗	✓ / ✗	✓ / ✗	✓ / ✗	Plan、Measurement、Result
QMS	品質管理	✓ / ✗	✓ / ✗	✓ / ✗	✓ / ✗	Requirement、Result
MES	製造執行	✓ / ✗	✓ / ✗	✓ / ✗	✓ / ✗	生產與品質資料
PLM	產品生命週期	✓ / ✗	✓ / ✗	✓ / ✗	✓ / ✗	Product、Revision

四、接著確認：不同系統對「同一個東西」的定義一樣嗎？

系統能力盤點完成後，另一個容易被忽略的問題就出現了：

就算資料可以傳遞，傳過去之後，它還是不是同一個東西？

例如同一個孔：

• CAD 裡可能叫：Feature_001

• 量測軟體可能叫：F001

• QMS 裡可能叫：CHAR-001

從系統角度看，這是三個不同的名稱。

但從工程角度看，它們可能其實代表同一個 Feature。

這就是 Data Definition（資料定義）問題。

五、QIF 導入真正需要統一的，是資料的「語意」

第一次做系統整合時，多數人會直接建立一張欄位對照表：

系統 A	系統 B
Product ID	Product ID
Feature No.	Feature No.
Actual Value	Measured Value
Pass / Fail	Result

看起來已經完成 Data Mapping（資料對應）。

實際上還需要繼續追問：

這兩個欄位的意義真的一樣嗎？

例如：

「Actual Value」 是不是 QMS 所定義的：「Measured Value」 ？

兩個欄位雖然都存數字，但可能使用不同單位。

又例如：

Pass / Fail 到底是誰判定？是量測軟體判定？

還是 QMS 依照 Nominal 與 Tolerance 重新判定？

這些問題都屬於「資料語意」。

因此，QIF 導入真正需要建立的是：

不同系統對同一筆工程與品質資訊的共同理解。

這也是為什麼 Data Mapping 往往比「產生一個 QIF XML」更重要。

六、再往前一步：企業需要多少 MBD？

這時候才重新回到 MBD。

MBD（Model-Based Definition，模型為基礎的定義）不是每一個 QIF 專案都需要做到相同程度。

我們需要知道：

這個 Use Case 需要多少產品語意？

可以先簡單分成三種情況。

---

• Level 1：只交換量測結果

例如：

Measurement Software
        ↓
   QIF Results
        ↓
       QMS

此時企業重點放在：

• Actual Value

• Nominal

• Tolerance

• Result

• Part

• Characteristic

不一定需要完整的 MBD。

---

• Level 2：交換檢驗計畫與結果

例如：

Inspection Planning
        ↓
    QIF Plans
        ↓
Measurement Software
        ↓
    QIF Results
        ↓
       QMS

此時需要更明確地描述：

• 要檢查哪些特性

• 每個特性對應什麼 Feature

• 使用什麼要求

• 量測結果屬於哪一個檢驗項目

---

• Level 3：建立完整產品定義到品質結果的關聯

例如：

CAD / MBD
   ↓
Feature
   ↓
Dimension / GD&T
   ↓
Inspection Plan
   ↓
Measurement
   ↓
Result

這時候就需要更完整的 PMI（Product Manufacturing Information，產品製造資訊）、Feature、Datum、Tolerance 等工程語意。

因此，企業需要先知道：

這次的 QIF Use Case，需要多少產品與工程資訊？

這個答案會直接決定 MBD 導入的深度。

七、企業可以用這 10 個問題，完成導入前盤點

做到這裡，其實已經可以把整個 QIF Readiness Assessment 濃縮成一張表。

QIF 導入前檢查表

問題	要確認的內容
1. 為什麼要導入？	明確的 Business Problem
2. 第一個 Use Case 是什麼？	Results、Plans、MBD 或其他
3. 哪兩個系統需要串接？	Source / Target
4. 哪個系統負責輸出？	Native QIF / API / Converter
5. 哪個系統負責接收？	Native QIF / API / Converter
6. 現有資料在哪裡？	CAD、Measurement、QMS、MES、PLM
7. 資料定義是否一致？	欄位、語意、單位、判定方式
8. ID 是否一致？	Part、Feature、Characteristic、Result
9. 需要多少 MBD？	依 Use Case 決定
10. 如何驗證成功？	Schema、Data、Relationship

如果這 10 個問題大多數都還沒有答案，不代表企業不能做 QIF。

它代表：

現在比較適合先做需求與資料盤點，而不是直接開始開發。

九、做到這裡，企業才真正知道「缺什麼」

經過這一輪盤點後，企業通常會發現，自己缺的東西可能完全不同。

也已經能夠回答幾個基本問題：

• 我們最想解決哪一段資料流程？

• 哪兩個系統需要交換資料？

• 現有系統到底支援多少 QIF？

• 沒有原生支援時，API 或 Converter 能不能補上？

• 不同系統對同一筆資料的定義是否一致？

• Part、Feature、Characteristic、Result 能不能一路追溯？

• 這個 Use Case 到底需要多少 MBD？

這些答案，就是下一階段導入的基礎。

但真正的 QIF 專案，還沒有開始。

接下來真正需要處理的是：

• 第一個 QIF 專案應該做多大？

• Data Mapping 到底要怎麼建立？

• ID 怎麼設計？

• QIF 產生之後，怎麼確認資料真的正確？

• PoC（Proof of Concept，概念驗證）要怎麼規劃？

下一集，我們會從「確認條件」正式進入「實際導入」，從第一個 Use Case 開始，一步一步走過 架構設計、Data Mapping、ID、Validation（驗證）、PoC、驗收，以及後續擴大到更多系統的方式。