01 / THE REAL PROBLEM
卡住的地方不是技术，是权责The Real Problem
数据给不出去，多数时候不是接口不通，是「给了出事谁负责」没人敢拍。所以先落纸面，再谈接口。
目录不清CATALOG
有哪些数据、在哪个系统、谁在维护，说不清就只能靠开会问。
权属不明OWNERSHIP
谁能给、给到哪一步、给了之后谁负责，没有书面依据。
口径不一DEFINITIONS
同一个指标几处算出来的数不一样，一共享就打架。
流程不成链PROCESS
申请、审批、交付、留痕各走各的，卡在哪一步查不到。
02 / SIX STEPS
六步，按顺序做Six Steps
跳过任何一步，后面都要返工。
| 步骤 | 做什么 | 产出 | 不做会怎样 |
|---|---|---|---|
| 编目 | 按部门、系统、表、字段逐层编目，摸清家底 | 资源目录 | 不知道有什么，共享无从谈起 |
| 定权 | 数据权属与共享权限逐条写清，不靠口头 | 权责清单 | 出事没人负责，谁都不敢给 |
| 定口径 | 同一指标统一算法与出处 | 口径表 | 几处报数不一致，一共享就打架 |
| 定流程 | 申请、审批、交付、留痕一次一条链 | 流程与时限 | 卡在哪一步查不到 |
| 接系统 | 原系统不动，接口层对接，取数不落地 | 接口清单 | 要么复制数据，要么动原系统 |
| 出服务 | 数据以接口与看板形式给出去 | 可用的数据服务 | 数据躺着没人用 |
03 / WHO DOES WHAT
三方各干什么Who Does What
| 角色 | 负责 | 不负责 |
|---|---|---|
| 大数据局 | 编目规范、权责清单、口径裁定、平台运维 | 替业务部门承担数据责任 |
| 业务部门 | 本部门数据的准确性、更新、共享授权 | 维护共享平台本身 |
| 我们 | 平台与工具、编目辅助、口径冲突的比对与提示 | 决定数据该不该给 |
04 / UTILIZATION
利用率看板：数据到底被用了没Utilization Board
编完目不等于用起来。要看哪些数据真被调用、谁在用、卡在哪。
| 指标 | 说明 | 能看出什么 |
|---|---|---|
| 编目覆盖率 | 已编目资源 / 应编目资源 | 家底摸清到什么程度 |
| 共享开通率 | 已开通共享的资源 / 已编目资源 | 有多少真的能给别人 |
| 调用活跃度 | 近 30 天被调用的接口数 / 已开通接口数 | 有多少真的在被用 |
| 未使用清单 | 开通了但 30 天零调用的资源 | 哪些是编了没人用，可以收回来 |
| 申请积压 | 待审批 / 平均审批时长 | 卡在哪个环节 |
| 冲突处理 | 口径冲突数与处理时长 | 口径治理的真实工作量 |
05 / WHAT CHANGES
跑起来之后What Changes
查数不用发函NO LETTERS
原来要发函等对方排期，现在一句话出数，带来源表和更新时点。
共享有据可查TRACEABLE
谁在什么时候申请、批给谁、用了多久，全程留痕。
口径不再打架ONE SET OF DEFINITIONS
同一指标只有一种算法，出处写清。
无效共享收得回RECLAIM
长期零调用的共享自动列出，可以收回权限。
06 / WHERE IT RUNS
现在在用的情况Where It Runs
只写行业与数量，不写单位全称。
31
家单位在跑
4,120
个库表已编目
1,860
个共享接口
216
个数据环境