经营会最尴尬的场面：销售说回款到了，财务说没到，运营掏出第三张表——同一个指标三种算法。大家吵的不是业务，是口径。报表工具越先进，口径分裂越隐蔽：每人一个 SQL，三种结果都能“自圆其说”。
先立口径词典，再谈看板好看
数据治理在经营侧的最小闭环是：
- 指标定义：业务含义、分子分母、时间粒度、币种/含税、剔除规则
- 版本冻结：口径变更走版本号，历史报表可复算或标注“旧口径”
- 取数入口：唯一认证查询或语义层，禁止业务库直连散落
- 审计：谁在何时用哪一版口径产出数字
没有词典，中台只会变成更大的数据沼泽。有了词典但不强制取数入口，词典就是摆设。
设计
业务 owner 定义指标；数据管家审核可实现性；分析师只消费发布态指标；财务对法定口径有一票否决。主题域（销售、库存、资金）分开治理，跨域指标必须引用已发布原子指标。
- 指标对象：编码、名称、口径文档、owner、状态
- 计算逻辑：SQL/语义表达式、依赖血缘
- 发布版本：生效日、变更说明、兼容策略
- 消费方：报表、订阅、API，记录口径版本
会议材料导出时自动带口径版本号与刷新时间，杜绝截图口口相传。
对比：个人 SQL vs 口径平台
| 维度 | 个人取数 | 口径词典+发布 |
|---|---|---|
| 争议 | 开会吵定义 | 先查版本再谈业务 |
| 变更 | 悄悄改 SQL | 变更单+生效日 |
| 复算 | 难 | 按版本复算或标注 |
| 权限 | 库账号蔓延 | 指标级授权 |
落地与验收
先治理 Top20 经营指标，不要一上来全公司指标库。每个指标必须有业务 owner 签字。语义层上线后，收回业务库只读账号（例外走审批且短期）。
验收：同指标两看板数字是否一致；口径变更后旧订阅是否提示；无版本号报表能否外发（应不能）；血缘能否从报表追到来源表。
数据智能的前提是数字可辩护。不可辩护的精准，只是更贵的争吵。
失败模式
指标同名异义：强制编码唯一，名称允许别名。分析师绕过语义层：审计查出直连即回收权限。口径变更无沟通：变更订阅通知消费方，给予并行期。
四周后看什么
口径争议工单数、重复指标数、直连库账号数、经营会“对不上数”中断次数。这四项下降，再扩 AI 取数助手——助手也必须只读发布态指标，不能自由生成未治理 SQL。
指标分层：原子、派生、主题
原子指标（如订单行金额）先治理；派生指标（毛利、转化率）声明依赖；主题指标面向场景（回款健康度）由原子/派生组合。禁止主题指标直接写裸 SQL 绕过原子层。
同名指标申请合并流程：保留编码，增加别名。废弃指标设退役期，消费方迁移后下线。血缘图用于影响分析：改一个原子指标，能列出全部派生与报表。
对外监管口径与内部管理口径并存时，用标签区分，会议材料必须标明用的是哪一类，避免混用。
AI 取数的边界
自然语言问数只能查询已发布指标与受控维度。模型生成的 SQL 若未映射到指标编码，默认拒绝执行。问答日志纳入审计，方便回放“当时用的哪版口径”。
训练业务人员写“问数话术”：先说指标编码或标准名，再说时间与组织范围。比让模型猜“利润”是哪种利润更安全。
数据质量规则挂在指标上：空值率、波动阈、对账差。质量红灯时看板降级显示“不可用”，比显示错误数字更负责。
组织落地
指标委员会不必庞大：业务 owner、数据平台、财务各一人即可拍板。争议升级路径写进制度，避免群聊里永久扯皮。季度清理一次僵尸指标与重复看板。
新看板立项必须引用已有指标编码；新建指标要说明为何现有不够用。这条比事后治理便宜得多。
对管理层报告附“口径脚注”一页：本期用了哪些指标编码与版本。会议争论数字时，先对脚注再对业务，少做无谓翻表。
与报表平台分工
报表工具负责展示与权限；指标平台负责定义与版本。看板作者选指标编码，不复制计算公式。发现报表私自改公式，平台应标红并阻断发布到经营例会目录。
指标变更通知订阅：消费方（报表、API、邮件订阅）登记依赖，口径升级时自动发变更说明与迁移截止日。
口径争议怎么结案
争议单记录：提出人、现用算法、诉求算法、业务场景、影响报表清单。委员会裁决后写入版本说明与生效日；未裁决前，对外材料冻结旧版，禁止各写各的。
财务关账期可临时锁定口径变更，变更排队到下个开放窗。开放窗外紧急修正走加急通道并全员公告。
对经销商或加盟商开放的指标，单独命名空间，避免内部管理口径外泄或被误读为合同口径。
取数审计导出给内审：谁在何时用哪版指标算了哪张表。配合行级权限，防止口径正确但数据越权。
试点部门先跑通词典与版本冻结，再推广全公司问数；全员同时开问数只会放大口径混乱。
口径版本号写进会议纪要附件名，减少事后扯皮。