企業知識怎麼分類？產品、應用、問題與文件的關聯

AO2 FIELD GUIDE · N039 · 企業知識庫與治理

企業知識分類要連接產品、應用、問題、文件與核准答案。附最小資料模型與關聯表，說明穩定 ID、欄位字典及查找任務驗收。

企業知識分類：資料夾只能回答一部分的找法

PM 習慣按產品線找資料，業務習慣按客戶問題，客服可能按故障情境，海外編輯則從語言版本開始。同一份文件若只能放在一個資料夾，使用者就要先猜作者怎麼分類；若每個地方都複製一份，更新時又容易留下不同答案。

知識模型的目的，是把這些找法連到同一份來源。以 IoT 產品為例，產品、支援介面、應用情境與操作文件可以是不同物件。問題「既有設備能否整合」則連到相關產品、條件與核准回答。模型不需要第一天就涵蓋所有資料，先從一條產品線的真實查找任務開始。

先區分物件、屬性與關係

物件是有獨立身份、需要持續維護的東西，例如產品或文件。屬性是描述物件的值，例如語言、版本和狀態。關係則說明兩個物件如何連接，例如文件描述產品、回答引用文件。若把每個值都做成分類，分類會快速膨脹；若把所有關係塞成文字備註，系統又很難追查影響。

穩定 ID 與顯示名稱要分開。產品改名時，若 ID 不變，相關文件與問題仍能連回同一對象。名稱中的中英文、縮寫與歷史別名，則由術語表管理。這也能避免把同名不同產品，或不同名的同一產品誤合併。

用「一對多」情境測試分類是否合理

一份文件可能描述多個產品，一個問題也可能涉及多份文件。先用簡單的關聯表記錄來源 ID、關係類型、目標 ID、適用條件與核准狀態，就能在試作階段驗證模型。是否採用關聯式資料庫、知識圖譜或其他工具，應等任務清楚後再決定；單純增加系統複雜度不會自動改善答案。

半導體與電子示例：不要把應用當成無條件相容

以下為假想情境。一個模組曾在某類設備應用，業務希望把所有同系列產品都標成「適用該設備」。模型應分開記錄「曾有應用資料」與「經核准適用」兩種關係，並保留配置及限制。案例分類可以幫助找到資料，不能直接當成規格相容的證據。

試作時可以挑三個任務：從產品找現行規格、從客戶問題找核准答案、從變更文件找受影響素材。若每個任務都必須靠某位同事口頭補充，可能還缺關係或條件；若系統回傳太多近似項目，則要檢查命名與狀態，而不是立即增加更多分類層。

欄位字典要包含填寫規則與空值意義

每個欄位都應寫出定義、允許值、負責人和範例。空白可能表示未確認、不適用或尚未建立，三者不能混用。例如語言版本尚未核准，不等於沒有翻譯需求；產品狀態未知，也不等於停產。若來源未確認，應讓查找結果明顯顯示待確認，避免使用者把缺值當成肯定答案。

Microsoft 的資料治理術語可協助團隊建立共同語言，但本文的產品與問題模型是工作設計示例，不是特定平台規定。重要的是讓團隊對欄位意思有共識，並能用真實任務檢驗，而不是套完一套名詞後就宣布完成治理。

小規模驗收通過後，再擴充類型

第一次先用少量資料建立可追溯閉環，請 PM、業務與編輯各完成一次查找。記錄找不到、找錯、需要補問及來源矛盾的情況，分別回到資料、關係或介面修正。不同問題應有不同負責人，不能全部歸類為「使用者不熟悉系統」。

常見問題

產品型號要當標籤還是資料物件？

需要管理規格、版本與文件關係時，宜建立有穩定 ID 的產品物件；只是輔助文章搜尋時，可先用標籤。可用三個任務判斷：能否列出某型號的有效文件、辨認舊新版本，以及更新時找出衍生內容。標籤若無法維護這些關係，就需要更明確的資料結構。不要用會改名的顯示名稱作唯一識別，也不必在需求尚不清楚時先做過度複雜的系統。

分類越細，答案會越準嗎？

不一定。分類需要支援查找與維護，過細卻無法一致使用，反而會把同一概念拆散。先用產品、應用、問題與文件等關係測試真實任務，記錄找不到、分不清或重複的情況，再決定新增類別。每一類應有定義、納入與排除條件及責任人。若不同人對同一文件經常分類不同，先修規則和例子，不要只繼續加更多層級。

參考資料與方法範圍

• Microsoft｜資料治理術語

查核日期：2026 年 10 月 21 日。官方文件支援文中對應的平台或可及性說明；工作表與決策流程為本文整理，產業情境另行標示為假想示例。作者公開分享作為工作觀點來源，不作客戶成效或資格背書。