1.收集口径不一致的指标清单或业务场景
例如：
| 营销系统 | ERP | 财务开票 | |
|---|---|---|---|
| 销售收入 | 8.3亿元 | 7.9亿元 | 7.6亿元 |
2.归因分析
- 定义差异：大家说的不是一回事 → 需要业务治理。
- 数据差异：同一定义但来源不同 → 需要统一数据源/主数据。
- 系统差异：计算逻辑/时间截点不同 → 需要工程改造。
| | 营销CRM | ERP | 财务开票 |
| 销售收入 | 8.3亿元 | 7.9亿元 | 7.6亿元 |
| 口径 | CRM按照客户签收确认算 | 供应链按照工厂出库算 | 财务按照开票且控制权转移算 |
|---|
→ 分析：差异最大的是"在途+退货+商业折扣/返利"，主因是定义问题，而不是系统bug。
→ 方案：以财务收入确认口径为法定口径(涉及上市披露)，保留发货口径、签收口径作为运营辅助口径，在指标字典里分别命名：销售收入_收入确认口径 、销售收入_发货口径 、销售收入_签收口径 。在应用平台上建立"口径切换器"，用户看报表是可选择口径，系统自动提示差异说明。
→ 落地：先从一个BU试点跑通3个关账月，再全国推广，同时把返利和退货数据接入DWD层。
→ 效果：报表对账差异从 5% 降到 0.5% 以内；月度经营会不再争论数字对错，直接讨论业务。
为什么说要"跑通 3 个关账月"？
一个关账月只能验证一次理想路径，很多问题要跨周期才会暴露：
- 第 1 个月：发现基础数据问题（字段缺失、时间戳不准、主数据映射错误）
- 第 2 个月：验证修复效果，发现跨期问题（上个月发货本月签收、本月退货上个月订单）
- 第 3 个月：证明流程稳定，可以复制推广
3 个关账月差不多就是一个季度，能覆盖正常的业务波动，也能把季节性、返利季度结算等问题跑出来。
3.成立治理组织
| 层级 | 角色 | 职责 |
|---|---|---|
| 决策层 | 数据治理委员会，VP 级，由财务/营销/供应链/IT 负责人组成 | 拍板跨部门冲突、批准指标定义变更、考核落地 |
| 管理层 | 数据资产管理团队/数据产品经理 | 制定标准、组织评审、维护指标字典、平台产品设计 |
| 执行层 | 业务数据 Owner（每领域 1-2 人） | 营销指标 Owner、供应链指标 Owner、财务指标 Owner |
关键机制：
- RACI 表 ：每个指标的"定义、计算、解释、变更"都要落到人。(详见：IT | RACI典型场景案例 -CSDN博客)
- 双周指标评审会：新指标上线、旧指标变更必须过会。
- 指标冻结机制：月底关账前 N 天，核心指标口径锁定。
| 字母 | 含义 | 说明 |
|---|---|---|
| R | Responsible 执行人 | 具体干活、写方案、跑流程的人 |
| A | Accountable 最终负责人 | 唯一拍板人，对结果负最终责任 |
| C | Consulted 咨询方 | 必须征求意见，达成一致才能推进 |
| I | Informed 知会方 | 事后同步，不参与决策 |
4.建立指标体系
1）原子指标 + 派生指标分层
- 原子指标：不可再拆、来源单一，如"订单数量、发货数量、开票金额"。
- 派生指标：原子指标 + 时间 + 维度 + 修饰词，如"2024 年 Q1 华东区 阿莫西林胶囊（0.25g*24 粒） 含税发货金额"。
- 复合指标：用于管理决策，如"订单满足率 = 按时足量发货订单数 / 总订单数"。
2）指标六要素字典
| 要素 | 示例 |
|---|---|
| 指标名称 | 销售收入（财务口径） |
| 业务定义 | 控制权转移后、扣除商业折扣及退货后的净销售额 |
| 计算公式 | SUM(开票金额) - SUM(销售退回) - SUM(商业折扣) |
| 数据来源 | SAP 销售模块开票数据 + rebate 系统折扣数据 |
| 维度 | 时间、区域、产品、客户、渠道、销售组织 |
| 版本/生效日期 | V2.0，2024-01-01 生效 |
| 业务 Owner | 财务核算部张某 |
| 数据 Owner | 数据中心李某 |
现实中例如"毛利率"，营销想要"销售价 - 标准成本"，财务想要"收入 - 实际生产成本 - 分摊费用"。最后定义了两个版本：营销版毛利率 用于市场分析，财务版毛利率 用于报表披露，但两个都明确标注口径、不可混用。(IT | 指标口径能统一只用财务口径吗？-CSDN博客)
3）维度标准化（主数据治理）
- 产品维度：建立产品主数据编码，打通 SKU（供应链）、商品名（营销）、核算分类（财务）。
- 区域维度：建立区域层级映射，如"销售大区---省---城市---客户" 与 "工厂---仓库---配送区域" 的映射。
- 时间维度：统一"自然月、关账月、滚动 12 月"等定义。
4）血缘与版本管理
- 用数据血缘工具或手动维护，从指标一直追溯到源系统字段。
- 指标变更必须发版，旧版保留可查，避免"今天看的数和昨天不一样"。
5.设计数据应用平台方案
把指标体系落到平台上，建议把平台拆成三层，整体思路是数据仓库做厚、指标中台做薄、数据服务做活。DWS 层沉淀统一事实，指标中台统一语义，前端 BI 只负责展示和探索，不再各自写 SQL 算指标。
1）数据基础层：统一数仓/数据湖
- ODS：接入 ERP、CRM、WMS、TMS、SRM、财务系统等。
- DWD（明细层）：按业务过程建模，如销售发货、开票、回款、生产入库、库存移动。
- DWS（汇总层）：按主题域汇总，如销售主题、供应链主题、财务主题。
- ADS（应用层）：面向具体报表、分析场景。
2）指标/语义层：指标中台或 Headless BI
这是治理落地的关键，把指标定义从报表里抽出来，统一管理：
- 建立指标注册中心：所有指标在这里注册、定义、审核、发布。
- 计算逻辑下沉：指标计算由平台统一执行，避免"同指标不同报表结果不同"。
- API/Metrics-as-Code：让 BI、报表、数据应用统一调用指标服务。
可以用"指标中台"或类似 dbt Semantic Layer、Looker LookML、Metric Store 等思路，具体选型看公司技术栈。
3）数据消费层：统一门户+自助分析
- 统一数据门户：一个入口看营销、供应链、财务指标。
- 数据目录/数据地图：让业务能找到指标、看懂口径、申请使用。
- 数据质量管理：核心指标设置监控规则，异常自动告警。
- 权限管理：按数据敏感度（如客户、价格）做行级/列级权限。