能力 · 数据治理

治理是否有效,看报送季有没有人在补数据

治理失败的表现很容易被认出来:报送靠人工兜底、年报前一周到处补数据、同一指标在三级平台三个数。我们的交付物是一份带责任人的数据字典、一个分层的指标库、一套变更流程与可执行的数据质量规则,6–12 周内建立,之后按季度复核。

治理体系 6–12 周标准区间14,000+ 覆盖基金(在管口径)18 项风险指标可直接复用字段自定义与责任人矩阵上线后季度口径复核

主张

口径不是 IT 问题,是被记录下来的管理决定

字典里每一个字段都有四个必填项:取值来源、计算方式、更新频率、责任人。缺任何一项,字段就只是一列数据;四项齐全,它才成为可以质询的对象。因此治理工作必须由业务、风控与财务共同签字,而不是由系统管理员代签。

第二项承诺是可自定义:数据字典定义与字段自定义同属一套机制。新增字段走同一条变更流程,制度变化时不需要等版本发布,也不需要私下开一张表绕过字典。

一份没有人负责的数据字典,比没有字典更危险:它给每个部门提供了「我们已经治理过」的说法,而报送季的补数据工作照旧发生。梓川科技 · 交付方法论

六个动作,先算清分歧再定规则

顺序不可调整:变更流程若早于字典定稿出现,就会有一堆未签字的字段被写进规则。

  1. 盘点在用口径

    把各部门现行报表、报送模板与系统字段逐一对照,记录同一指标的不同算法。产出:口径分歧台账,按报送影响排序。

  2. 定稿数据字典与字段责任人

    逐字段确定取值来源、计算方式、更新频率与责任人,三方签字后冻结基线版本。产出:数据字典与责任人矩阵。

  3. 建立口径变更流程

    变更申请、影响分析(涉及哪些报表、模型与披露)、版本编号、生效时点与通知范围五步固定。新字段与修改字段走同一条流程。

  4. 搭指标库的分层结构

    原子指标(可直接取数)、派生指标(由公式合成)、披露指标(对外报送与 LP 报告)三层分列,每层引用字典而非重复定义。

  5. 上线数据质量规则

    按完整性、一致性、时效性与越权四类设检查项,异常自动生成待办并指向责任人,不进人工提醒清单。

  6. 出具一致性核查报告

    抽样比对同一指标在三级平台、报送表与披露文件中的取值差异,逐条给出结论与整改责任人。产出:口径一致性核查报告,作为验收对象。

交付物、典型周期与验收方式

6–12 周为标准区间,自合同工作分解结构确认之日起算;层级多、报送表种类多的集团项目按分期路线图推进,与平台建设共用里程碑。

交付物典型周期验收方式
口径分歧台账治理 6–12 周内三条线确认台账无遗漏,作为字典输入
数据字典与字段责任人矩阵治理 6–12 周内三方签字;每个字段有且仅有一个责任人
口径变更流程(含版本编号规则)治理 6–12 周内现场走一次变更:申请、影响分析、生效
指标库:原子 / 派生 / 披露三层治理 6–12 周内抽验公式与字典一致,披露指标可回溯
数据质量规则与异常待办治理 6–12 周内构造异常样本,规则触发并指向责任人
口径一致性核查报告治理收尾差异为 0 的比例与整改闭环逐条列明
季度口径复核(上线后)验收后每季度按同一公式复算,结论与上期对比

指标复用

18 项风险指标与估值口径不必重复实现

被投企业与基金的风险监控、KPI 预警、资产估值与退出测算共用同一批派生指标。已有自研团队时,我们把这批指标按字典交付为可复用组件,而不是让两边各写一套公式。

  • 风险指标逐日重算
  • 估值与披露同源
  • 公式版本可追溯
看智能风控场景

治理底座

六件东西构成字典之外的治理机制

字典只是起点;没有下面六件,口径会在两次制度调整之间漂移。

数据字典与字段自定义

字段名、取值来源、计算方式、更新频率、责任人五列定稿,支持按机构逻辑增补自定义字段。

  • 基线版本冻结
  • 自定义字段同流程

口径变更流程

申请、影响分析、版本、生效时点、通知范围五步固定,报表与披露对象自动列出。

  • 影响分析可查
  • 变更留痕

指标库三层结构

原子、派生、披露三层分开维护,披露层引用派生层公式,不在报送表里另起算法。

  • 三层引用关系
  • 无重复定义

估值与披露指标

资产估值、份额与收益口径、LP 报告与对外披露指标共用同一批字典字段,避免两套账。

  • 估值口径统一
  • 披露可回溯

数据质量规则

完整性、一致性、时效性、越权四类检查自动执行,异常直接生成责任人待办。

  • 四类检查项
  • 异常进待办

报送出口收敛

对外报送与 LP·GP 披露只从一个出口生成,同一指标不再由多个部门各自计算。

  • 单一出口
  • 模板可版本化

治理覆盖的对象域

对象与字段范围按贵机构业态裁剪;未纳入的对象在核查报告里标注为待覆盖,不做默认假设。

基金与份额项目与交易被投企业主体股权层级与稀释估值与减值风险指标(18 项)LP 报告与披露监管报送表工时与成本子基金报送

谁来维护

三种部署形态下的治理责任划分

公有云、私有云、内网三态部署不改变治理责任的分配方式:字段责任人与变更审批始终在贵机构,我们提供流程工具、复核与季度核查。内网场景下所有比对与核查在贵方环境内完成,字典与变更记录按属地要求留痕。

  • 责任人属客户
  • 我们做复核与核查
  • 内网不出环境
看运维与保障

谁在用

治理结果直接面对三类读者

主管单位的报送模板、LP 的问询、审计对公式的追溯,要的是同一份定义的不同切面。资金属性不同,口径分歧的来源也不同:国资三级平台在层级,市场化机构在估值与退出测算。

  • 报送口径
  • 披露口径
  • 审计追溯
按行业看口径差异

方法出处

为什么先定口径,我们公开写过

先定口径再谈功能、报送季为什么必须人工兜底、系统实施周期为何总被压缩——这些判断以文章形式发布,可直接引用进内部立项与评审材料。

阅读全文

这项能力不适合谁

只想要一份「标准数据字典模板」的机构:模板离开签字方与变更流程就是废纸,我们不做这种交付。没有指定字段责任人的组织同样不适合——治理动作最终要落到某个岗位上回答质询,无人认领的字典会在半年内被绕过。

已经确定不上任何系统、仅靠 Excel 协作的单一基金团队:先把表格集中到一处,比先建字典更划算。

数据治理常见问题

以下回答与验收方式一致,可直接用于内部沟通。

数据字典和系统字段说明有什么区别?
字段说明描述数据库里有什么;字典定义业务上这个数怎么算、多久更新、由谁负责。字典的签字方是业务、风控与财务,不是开发。这也是它能用于报送与披露的原因。
治理要多久?6–12 周怎么定?
取决于层级数量、报送表种类与在用系统的可导程度。6–12 周是标准区间,起算点是工作分解结构确认之日;我们会把不能签字的字段单列为待确认项,而不是延长周期。
先治理还是先上系统?
看压力来源。有明确监管报送时点的,通常先把该口径的字段与出口治住,再分期上流程;完全靠手工台账的,先做平台最小可用集,同步补字典。两种顺序都在路线图里写明,不是二选一的立场问题。
口径变更会不会影响历史披露?
变更走五步流程并带版本编号,历史结论保留当时生效的公式版本。核查报告会列出因变更产生的差异,并说明是否需要在下一期披露中解释。
已有自研系统,还需要做指标库吗?
常见做法正好相反:自研系统已有实现,我们把散落在代码与报表里的算法收敛成三层指标库并补上责任人,使估值、风险预警与披露不再各算各的。
数据质量规则误报很多怎么办?
规则按四类分档,先开高影响项(关键字段缺失、跨表不一致),其余作为观察项不生成待办;误报样本进入调整清单,随变更流程一起修订阈值。

下一步

带三份报表来,我们做一次口径对撞

把同一指标在业务、风控、财务三处的算法现场比对一遍,指出必须签字的字段与可以先放下的字段,并给出 6–12 周的区间建议。