雲端資訊模型

(CIM) 中的供應商 (Supplier) 實體是一種專門的參與者角色 (Party Role) — 它描述了扮演向企業提供商品或服務角色的一方（組織或個人）。由於 CIM 將參與者 (Party)（企業或個人的持久身分）與其所扮演的角色 (Role) 分開，因此同一參與者可以同時成為客戶、供應商和合作夥伴，而無需複製主資料。這是該模型的核心互通性承諾：一個與應用程式無關的共享詞彙表，讓採購、ERP、物流和分析系統就「供應商」的定義達成一致。

供應商實體具有兩大類屬性：身分和分類（供應商是誰）和績效評分（供應商的表現如何）。評分屬性分為三個加權類別 — 合約、滿意度和競爭力 — 最終匯總成一個 supplierScore。對於任何在 CIM 之上實施供應商記分卡、供應商主資料或採購分析的人來說，了解這些部分如何組合在一起至關重要。

要點

• 供應商是參與者角色，而不是獨立實體。 它從參與者 (Party) 繼承身分並添加特定於角色的屬性，因此您永遠不需要將供應商主資料從客戶主資料中分叉 (fork)。
• 評分是一個加權的三類模型。 合約、滿意度和競爭力衡量標準各帶有一個 weightPercent 和一個 weightScore；整體 supplierScore 將它們結合起來。
• 大多數率值 (rate) 欄位表示為代表百分比或計數的整數，這使模型保持簡單，但將捨入和標準化決策交給實作端。
• id 和 activeFromDate 是強制性的。 每個供應商記錄都需要一個穩定的 GUID 主鍵及其活躍期的開始日期。
• isCarrier 是一個輕量級的專業化標誌，讓物流邏輯無需單獨的實體即可識別運輸承運商（例如 FedEx、UPS）。
• CIM 旨在可擴展。 該模型是開源的，旨在被分叉和調整，因此請將這些屬性視為基線契約，而非封閉的結構 (schema)。

為什麼供應商被建模為參與者角色

CIM 中最重要的設計決策是參與者 (Party) / 參與者角色 (Party Role) 的分割，這種模式也存在於已建立的企業模型（例如 TM Forum 的資訊框架 (SID)）以及一般的主資料管理實務中。參與者 (Party) 是持久存在的事物 — 一個法人實體、組織或個人。參與者角色 (Party Role) 是該參與者與企業之間具有時間限制的關係。

這很重要，因為現實中的企業身兼數職。一家合約製造商可能會向您出售成品（供應商），向您購買組件（客戶），並共同開發產品（合作夥伴）。如果您將每一項建模為單獨的記錄，則會出現重複的供應商/客戶主資料、對帳噩夢以及不一致的層級結構。透過將供應商設定為一個角色，CIM 允許您將單一參與者附加到多個角色，並保留一份黃金記錄 (golden record)。

實際影響：

• 重複資料刪除發生在參與者層級。 指向同一參與者的兩個供應商記錄代表同一個法人實體。
• 角色具有時效性。 activeFromDate 和 activeToDate 欄位允許供應商關係開始和結束，而無需刪除歷史記錄。
• 特定於角色的資料保留在角色中。 供應商排名和記分卡指標屬於供應商 (Supplier)，而不是參與者 (Party)，因為它們僅在供應商情境中才有意義。

身分和分類屬性

身分屬性被刻意簡化，這是共享模型的典型特徵，以便能乾淨地映射到許多來源系統。

相關： Boomi AtomSphere — 用於雲端到本地混合整合的企業 iPaaS.

• id (guid, 強制) — 主鍵。使用 GUID 而不是自然鍵 (natural key) 可以避免在合併來自多個系統的記錄時發生衝突。
• activeFromDate (date, 強制) — 供應商關係生效的時間。
• activeToDate (date) — 結束時間（如果有）。
• supplierType (string) — 自由文字分類，例如零售商 (Retailer)、經銷商 (Distributor)、製造商 (Manufacturer) 或商家 (Merchant)。
• isCarrier (boolean) — 當供應商是 FedEx 或 UPS 等運輸承運商時為 true。
• supplierSpend (integer) — 從該供應商採購產品所花費的總成本。

關於 supplierType 的註解：因為它是一個純字串，所以它是一個基於約定而非基於結構 (schema) 的受控詞彙。在實際部署中，您應該使用列舉 (enumeration) 或參考資料清單來約束它，否則 “Manufacturer”、“manufacturer” 和 “Mfg” 將使您的報告碎片化。這是共享模型中靈活性與一致性之間的典型權衡，而 CIM 傾向於靈活性，期望實作者自行加強約束。

同樣地，supplierSpend 作為整數會引發貨幣和規模問題。該模型未指定貨幣或最小單位約定，因此您必須在跨區域匯總支出之前做出決定（例如，儲存最小單位並將該欄位與您自己擴充功能中的貨幣代碼配對）。

供應商記分卡：合約、滿意度和競爭力

供應商實體的核心是其記分卡，它是三個衡量類別的加權綜合體。每個類別都有一個 weightPercent（對總分的貢獻程度）和一個 weightScore（分析該類別衡量標準後分配的分數）。整體 supplierScore 定義為：

我們的選擇： Workato — 業務團隊實際上可以在此基礎上建立自動化主導的 iPaaS.

(合約權重 × 分數) + (滿意度權重 × 分數) + (成本/競爭力權重百分比 × 分數)

合約績效衡量標準

這些是與採購協議相關的客觀營運指標：

• contractOnTimeDeliveryRate — 準時交貨量 ÷ 總交貨量（依承諾日期計算）。
• contractDeliveryCorrectnessRate — 數量正確的交貨量 ÷ 總交貨量。
• contractProductQualityRate — 有缺陷產品的百分比。
• contractProductReturnRate — 退貨產品的百分比。
• contractInvoiceAccuracyRate — 過去 12 個月內發票不正確的頻率。
• contractSLAIssueRate — 過去 12 個月內違反 SLA 的次數。
• contractBudgetCostRate — 高於商定採購訂單價格的單位成本差異百分比。
• contractSourcingCycleDays — 從採購開始到合約簽署的天數。

滿意度衡量標準

這些是更主觀、以關係為導向的評級：

• satisfactionCustomerServiceRank — 客戶帳戶管理問題的路由與解決方式。
• satisfactionTechnicalSupportRank — 訓練與文件的評分情況。
• satisfactionEthicsRank — 勞工實踐、安全工作條件及配送資格。

競爭衡量標準

這些反映了供應商與替代方案相比的競爭力：

• competitiveCostAvoidanceRank — 透過免費培訓、交付及類似讓步所提供的價值。
• competitiveMarketingRank — 與供應商相關的商譽程度。
• competitiveProductPriceRank — 在合作關係生命週期內獲得首選或更優價格的可能性。
• competitiveWarrantyRank — 相對於其他供應商所提供的保固。

接著，每個類別會分別貢獻 competitiveWeightPercent / competitiveWeightScore、contractWeightPercent / contractWeightScore 以及 satisfactionWeightPercent / satisfactionWeightScore 到匯總結果中。

實作範例

假設採購團隊對三個類別的加權如下，並為每個類別分配 0–100 分：

相關： Matillion — 為雲端資料倉儲所建構的下推式 ELT.

類別	權重 %	分數	加權貢獻
合約	50	90	45.0
滿意度	20	80	16.0
競爭力	30	70	21.0
總計 (supplierScore)	100	—	82.0

關鍵原則是 三個 weightPercent 值的總和必須為 100。CIM 並不強制執行此限制，因此您的實作應對其進行驗證。如果總和不等於 100，則綜合分數作為標準化數值將毫無意義。一種常見的治理方法是集中固定權重（例如 50/20/30），使所有供應商的分數具有可比性，僅針對權衡條件確實不同的特定商品類別調整權重。

如何決定：實作者的實用指南

當您採用供應商（Supplier）實體時，有幾個決定將影響您的記分卡是否值得信賴。

• 先標準化再加權。 原始比率欄位是不同量級的百分比和計數。在應用權重之前，請將每個度量轉換為統一的 0–100 量表（或 0–1），否則單一高數值的計數將主導結果。
• 明確決定方向性。 對於大多數欄位，數值越高越好 —— 但 contractProductReturnRate、contractSLAIssueRate、contractInvoiceAccuracyRate（作為「錯誤次數」）和 contractBudgetCostRate（作為高於商定價格的差異）則是 越低越好。在評分時請將其反轉。
• 刻意處理缺失數據。 新供應商沒有 12 個月的歷史記錄。請決定是要排除該類別、填補中性分數，還是將供應商標記為「數據不足」，而非默默地將其評分為零。
• 保留原始度量。 將底層比率與綜合分數一起存儲，以便日後重新加權和審核。沒有來源依據的單一 supplierScore 在採購審查中是無法成立的。
• 權重版本化。 如果您更改權重，歷史分數將變得無法比較。請記錄計算每個分數時所採用的權重集。

跨系統整合供應商數據

由於 CIM 與應用程式無關，供應商實體作為整合的 規範目標 (canonical target) 最具價值。典型的管線會從 ERP（SAP, Oracle, Microsoft Dynamics）提取供應商主數據，從採購或 SRM 工具提取記分卡數據，從運輸管理系統提取承運人標記，然後將所有數據映射到 CIM 供應商模型上。

我們從哪裡開始： Fivetran — 完全託管的 ELT 管道持續運行.

• 將自然鍵映射到 id。 每個來源系統都有自己的供應商編號；請維護一張對應到 CIM GUID 的交叉引用表。
• 在參與方 (Party) 層級進行協調。 使用 Party 實體作為去重錨點，以避免同一法人實體被重複計算。
• 將 isCarrier 視為路由提示。 下游物流邏輯可以根據此欄位分支，以應用特定於承運人的處理方式。
• 將模型作為合約發布。 使用 dbt、Apache Atlas 和數據目錄等工具記錄 CIM 映射，使分析師了解每個欄位的含義。

對於將其形式化的團隊，CIM 的開源性質意味著您可以分叉 (fork) 該模型並添加業務所需的實體或屬性 —— 例如為 supplierSpend 添加貨幣代碼，或為 supplierType 添加受控枚舉 —— 同時保持核心 Party/Role 結構完整。值得對齊的相關標準包括用於參與方/角色模式的 TM Forum Information Framework (SID) 以及用於產品和位置識別碼的 GS1，因為供應商和產品數據經常同步傳輸。

治理與數據品質考量

供應商記分卡的好壞取決於輸入數據的品質，而供應商數據因源自多個系統且隨時間變化，向來非常混亂。

• 所有權。 為供應商主數據指派數據管理員；記分卡欄位（採購部門）的擁有者通常與身份欄位（財務或 MDM 部門）的擁有者不同。
• 新鮮度。 發票準確性和 SLA 欄位中的 12 個月窗口意味著需要滾動重新計算。請定義刷新頻率並使其透明化。
• 可審核性。 由於分數會驅動採購決策，請保留輸入值、權重和計算結果的審核追蹤。
• 道德與合規性。 satisfactionEthicsRank 欄位涉及勞工實踐和安全工作條件 —— 這些領域日益受到供應鏈盡職調查法規的監管。請將其視為合規訊號，而非僅僅是軟性評級。

常見問題

雲端資訊模型 (Cloud Information Model) 中的供應商實體是什麼？

供應商（Supplier）是 CIM 中的一個參與方角色（Party Role），描述向企業提供商品或服務的一方。它繼承了參與方（Party）實體的身份，並添加了特定於供應商的屬性，例如 supplierType、isCarrier、supplierSpend 以及完整的績效記分卡。將其建模為一個角色而非獨立實體，可以讓同一方同時充當供應商和客戶，而無需重複主資料。

supplierScore 是如何計算的？

supplierScore 結合了三個加權類別：合約（contract）、滿意度（satisfaction）和競爭力（competitive）。每個類別由其 weightPercent 乘以其 weightScore 貢獻，並將結果相加。為了使綜合結果有意義，三個權重百分比的總和應為 100，且每個基礎度量在加權前應被標準化為通用比例。

哪些供應商欄位是必填的？

只有兩個欄位是必填的：id（GUID 主鍵）和 activeFromDate（供應商關係生效的日期）。其他所有內容（包括 activeToDate、supplierType 和所有記分卡屬性）均為可選，這允許增量載入部分記錄。

isCarrier 標誌是什麼意思？

isCarrier 是一個布林值，當供應商是運輸承運商（例如 FedEx 或 UPS）時為 true。它為物流和運輸邏輯提供了一種輕量級的方法來識別承運商，而不需要單獨的實體或子類型，從而保持模型緊湊。

為什麼大多數記分卡欄位都是整數？

比率（rate）和排名（rank）欄位被定義為整數，通常表示百分比或計數。這使模型保持簡單且可在系統間移植，但這意味著實作者必須自行決定捨入、縮放和標準化約定，而非依賴架構（schema）來強制執行。

我可以擴充供應商實體嗎？

是的。CIM 是一個旨在被調整的開源模型，因此您可以新增屬性（例如為 supplierSpend 新增貨幣代碼，或為 supplierType 新增受控枚舉）或新增實體。擴充應保留核心的參與方/參與方角色（Party/Party Role）結構，以便維持與其他基於 CIM 系統的互通性。