63 lines
4.9 KiB
Plaintext
63 lines
4.9 KiB
Plaintext
業務資料比對與轉換率分析系統 - 邏輯規格書 (v1.0)
|
||
文件日期：2026-01-09
|
||
適用範圍：半導體製造業銷售漏斗分析 (Sales Pipeline Analysis)
|
||
部署環境：On-Premise (地端)
|
||
1. 資料源與 ETL 前處理策略 (Data Ingestion)
|
||
系統針對三份異質資料來源進行標準化清洗，具備「動態表頭偵測」能力以適應 ERP 匯出的非結構化報表。
|
||
1.1 資料來源定義
|
||
資料類型 | 檔案特徵 | 關鍵欄位識別 (Key Columns) | 處理邏輯
|
||
DIT Report | 含 Metadata (前 ~15 行) | R欄 (Opportunity ID), AQ欄 (ERP Account), Customer, Part No, EAU, Stage | 自動跳過 Metadata，定位至 "Stage/Part" 所在行作為表頭。
|
||
樣品紀錄 | 含 Metadata (前 ~8 行) | AU欄 (Oppy No), G欄 (Cust ID), Customer, Part No, Qty | 自動跳過 Metadata，定位至 "索樣數量" 所在行。
|
||
訂單明細 | 標準格式 (第 1 行) | Order No, Customer, Part No, Qty, Status (Backlog/Shipped) | 識別 Big5/CP950 編碼，標準化讀取。
|
||
1.2 資料清洗規則 (Sanitization)
|
||
Part Number (PN): 去除所有分隔符 (-, _, )，統一轉大寫。例：PMSM-808-LL ➔ PMSM808LL。
|
||
Customer Name: 移除法律實體後綴 (如 "Inc.", "Co., Ltd")，全形轉半形，統一轉大寫。
|
||
日期格式: 統一轉換為 YYYY-MM-DD，無效日期視為 Null。
|
||
2. 核心比對引擎 (Matching Engine) - 瀑布式邏輯
|
||
為解決客戶名稱不一致（如別名、子公司）問題，系統採用 三層級瀑布式比對 (Waterfall Matching)。優先級由高至低，一旦上層匹配成功，即鎖定關聯，不再向下尋找。
|
||
優先級 1：案號精準比對 (Golden Key) 🥇
|
||
邏輯：直接透過 CRM/ERP 系統生成的唯一案號進行勾稽。
|
||
對應欄位：
|
||
DIT Report: R 欄 (Opportunity ID / 案號)
|
||
Sample Log: AU 欄 (Oppy No)
|
||
信心水準：100% (絕對準確)
|
||
適用情境：業務在申請樣品時已正確填寫案號。
|
||
優先級 2：客戶代碼比對 (Silver Key) 🥈
|
||
邏輯：若無案號，則比對 ERP 客戶代碼 (Account Number)。
|
||
對應欄位：
|
||
DIT Report: AQ 欄 (ERP Account No)
|
||
Sample Log: G 欄 (客戶編號)
|
||
信心水準：99% (解決同名異字問題，如 "Liteon" vs "光寶")。
|
||
限制：需同時滿足 Account Match AND Normalized Part Number Match。
|
||
優先級 3：名稱模糊比對 (Fallback Mechanism) 🥉
|
||
邏輯：前兩者皆空值時，使用 Levenshtein Distance 演算法計算名稱相似度。
|
||
對應欄位：Customer Name vs 客戶名稱
|
||
信心水準：80% ~ 90% (不確定性高)
|
||
處理機制：系統標記為 Pending Review，強制進入 Human-in-the-Loop (人工審核) 流程，需人工確認後才計入績效。
|
||
註：訂單 (Order) 資料通常無 Oppy ID，故訂單比對主要依賴 Priority 2 (Account + PN) 與 Priority 3 (Name + PN)。
|
||
3. 歸因與時間窗邏輯 (Attribution & Time Window)
|
||
定義「何時」發生的送樣與訂單可以算在該 DIT 的績效上。
|
||
3.1 時間窗 (Time Window)
|
||
DIT → Sample:
|
||
Sample Date 必須在 DIT Date 的 前 30 天 (容許先跑流程後補單) 至 今日 之間。
|
||
DIT → Order:
|
||
Order Date 必須在 DIT Date (或 First Sample Date) 的 前 30 天 之後。
|
||
目的：排除 DIT 建立很久之前的舊訂單（那些屬於舊案子維護，非新開發案）。
|
||
3.2 多對多歸因法則 (LIFO Logic)
|
||
針對「同一客戶、同一料號」有多筆 DIT 的情況，採用 LIFO (Last-In-First-Out) 庫存扣抵法 進行業績分配：
|
||
將同料號的 DIT 按建立日期 由新到舊 排序。
|
||
將該料號的總訂單量 (Backlog + Shipped) 放入「業績池 (Revenue Pool)」。
|
||
優先滿足 最新 的 DIT EAU 額度。
|
||
若有剩餘業績，再分配給次新的 DIT，依此類推。
|
||
目的：確保業績優先反映在最新的開發專案上，避免舊案子無限期佔用新訂單的功勞。
|
||
4. 關鍵績效指標定義 (KPI Definitions)
|
||
系統最終產出的量化指標，用於衡量業務轉換效率。
|
||
指標名稱 | 計算公式 | 業務意涵
|
||
送樣轉換率 (Sample Rate) | (有匹配到樣品的 DIT 數) / (總 DIT 數) | 衡量前端 Design-In 開案後，成功推進到送樣階段的能力。
|
||
訂單命中率 (Hit Rate) | (有匹配到訂單的 DIT 數) / (總 DIT 數) | 衡量開發案最終轉化為實際營收的成功率 (Binary)。
|
||
EAU 達成率 (Fulfillment Rate) | (歸因之訂單總量) / (DIT 預估 EAU) | 衡量客戶預估量 (Forecast) 的準確度與實際拉貨力道。
|
||
無效送樣率 (Orphan Sample) | (未匹配到 DIT 的送樣數) / (總送樣數) | 監控是否有「偷跑」或「未立案」即送樣的資源浪費行為。
|
||
5. 系統輸出與審核
|
||
DIT 歸因明細表：每一列 DIT 清楚標示匹配到的 Sample No 與 Order No。
|
||
可追溯性 (Traceability)：滑鼠懸停 (Hover) 可顯示匹配邏輯來源 (如 "Matched via Opportunity ID: OP12345")。
|
||
人工介入：對於模糊比對的案件，提供 UI 介面供使用者點選 Accept / Reject，並將結果回寫至資料庫，作為日後自動比對的訓練樣本。 |