經營會最尷尬的場面：銷售說回款到了，財務說沒到，營運掏出第三張表——同一個指標三種算法。大家吵的不是業務，是口徑。報表工具越先進，口徑分裂越隱蔽：每人一個 SQL，三種結果都能「自圓其說」。
先立口徑詞典，再談看板好看
資料治理在經營側的最小閉環是：
- 指標定義：業務含義、分子分母、時間粒度、幣種/含稅、剔除規則
- 版本凍結：口徑變更走版本號，歷史報表可復算或標註「舊口徑」
- 取數入口：唯一認證查詢或語義層，禁止業務庫直連散落
- 審計：誰在何時用哪一版口徑產出數字
沒有詞典，中台只會變成更大的資料沼澤。有了詞典但不強制取數入口，詞典就是擺設。
設計
業務 owner 定義指標；資料管家審核可實現性；分析師只消費發佈態指標；財務對法定口徑有一票否決。主題域（銷售、庫存、資金）分開治理，跨域指標必須引用已發佈原子指標。
- 指標對象：編碼、名稱、口徑文件、owner、狀態
- 計算邏輯：SQL/語義表達式、依賴血緣
- 發佈版本：生效日、變更說明、兼容策略
- 消費方：報表、訂閱、API，記錄口徑版本
會議材料導出時自動帶口徑版本號與刷新時間，杜絕截圖口口相傳。
對比：個人 SQL vs 口徑平台
| 維度 | 個人取數 | 口徑詞典+發佈 |
|---|---|---|
| 爭議 | 開會吵定義 | 先查版本再談業務 |
| 變更 | 悄悄改 SQL | 變更單+生效日 |
| 復算 | 難 | 按版本復算或標註 |
| 權限 | 庫帳號蔓延 | 指標級授權 |
落地與驗收
先治理 Top20 經營指標，不要一上來全公司指標庫。每個指標必須有業務 owner 簽字。語義層上線後，收回業務庫只讀帳號（例外走審批且短期）。
驗收：同指標兩看板數字是否一致；口徑變更後舊訂閱是否提示；無版本號報表能否外發（應不能）；血緣能否從報表追到來源表。
資料智能的前提是數字可辯護。不可辯護的精準，只是更貴的爭吵。
失敗模式
指標同名異義：強制編碼唯一，名稱允許別名。分析師繞過語義層：審計查出直連即回收權限。口徑變更無溝通：變更訂閱通知消費方，給予並行期。
四周後看什麼
口徑爭議工單數、重複指標數、直連庫帳號數、經營會「對不上數」中斷次數。這四項下降，再擴 AI 取數助手——助手也必須只讀發佈態指標，不能自由生成未治理 SQL。
指標分層：原子、派生、主題
原子指標（如訂單行金額）先治理；派生指標（毛利、轉化率）聲明依賴；主題指標面向場景（回款健康度）由原子/派生組合。禁止主題指標直接寫裸 SQL 繞過原子層。
同名指標申請合併流程：保留編碼，增加別名。廢棄指標設退役期，消費方遷移後下線。血緣圖用於影響分析：改一個原子指標，能列出全部派生與報表。
對外監管口徑與內部管理口徑並存時，用標籤區分，會議材料必須標明用的是哪一類，避免混用。
AI 取數的邊界
自然語言問數只能查詢已發佈指標與受控維度。模型生成的 SQL 若未映射到指標編碼，預設拒絕執行。問答日誌納入審計，方便回放「當時用的哪版口徑」。
訓練業務人員寫「問數話術」：先說指標編碼或標準名，再說時間與組織範圍。比讓模型猜「利潤」是哪種利潤更安全。
資料質量規則掛在指標上：空值率、波動閾值、對賬差。質量紅燈時看板降級顯示「不可用」，比顯示錯誤數字更負責。
組織落地
指標委員會不必龐大：業務 owner、資料平台、財務各一人即可拍板。爭議升級路徑寫進制度，避免群聊裡永久扯皮。每季清理一次殭屍指標與重複看板。
新看板立案必須引用已有指標編碼；新建指標要說明為何現有不夠用。這條比事後治理便宜得多。
對管理層報告附「口徑腳注」一頁：本期用了哪些指標編碼與版本。會議爭論數字時，先對腳注再對業務，少做無謂翻表。
與報表平台分工
報表工具負責展示與權限；指標平台負責定義與版本。看板作者選指標編碼，不複製計算公式。發現報表私自改公式，平台應標紅並阻斷發布到經營例會目錄。
指標變更通知訂閱：消費方（報表、API、郵件訂閱）登記依賴，口徑升級時自動發變更說明與遷移截止日。
口徑爭議怎麼結案
爭議單記錄：提出人、現用算法、訴求算法、業務場景、影響報表清單。委員會裁決後寫入版本說明與生效日；未裁決前，對外材料凍結舊版，禁止各寫各的。
財務關帳期可臨時鎖定口徑變更，變更排隊到下個開放窗。開放窗外緊急修正走加急通道並全員公告。
對經銷商或加盟商開放的指標，單獨命名空間，避免內部管理口徑外泄或被誤讀為合同口徑。
取數審計導出給內審：誰在何時用哪版指標算了哪張表。配合行級權限，防止口徑正確但資料越權。
試點部門先跑通詞典與版本凍結，再推廣全公司問數；全員同時開問數只會放大口徑混亂。
口徑版本號寫進會議紀要附件名，減少事後扯皮。