治理资产协同的最佳实践是什么？如何打造收藏级的资产管理体系？

我做过七个数据治理相关的项目，真正把资产目录用起来的只有两个。三个项目的功能清单拉出来都够用，差别不在工具，在于治理动作有没有在资产侧留下能被看见的痕迹。

我的判断很直接：治理和资产的协同，本质是一场责任与交付物对齐的设计，不是两套系统的接口对接。治理侧每产出一个标准、一条质量规则、一次主数据清洗，资产侧都要有对应的可见变化；资产侧每新增一个条目，治理侧都要能追溯到它的责任人和口径来源。这条链断在哪一环，协同就死在哪一环。

所谓收藏级，我的定义很朴素：业务同事遇到问题时，第一反应是去资产目录里找，而不是先找人问口径。做不到这一点，目录再全也只是台账。要做到，需要三个前提——每个资产有人担保、每个口径有唯一出处、每次变更有人通知。听着像常识，落地时九成项目卡在第二条。

下面我把自己踩过的坑、用过的判断标准和实际跑下来的做法摊开讲。涉及工具的地方，我会说清楚普元的产品在哪个环节接得住，哪些环节还得靠人补。

我见过最典型的一个集团客户，治理做了两年，标准文档三百多页，数据资产目录录了八千多条，后台打开率不到 2%。我去问业务部门为什么不用，回答很实在：目录里的表名我看不懂，我要的指标搜不到，找到了也不敢信。

问题出在哪？治理团队的考核是标准覆盖率、质量问题整改率；资产团队的考核是目录条目数、月度访问量。两个 KPI 互相不咬合，谁都不用为”业务有没有真的用起来”负责。指标不交叉，动作就一定分叉。

我通常会拿一张对应表去跟双方对齐，把治理动作和资产成果硬绑在一起。下面这张表是我在三个项目里反复改出来的版本：

这张表最大的价值不是内容多准确，而是它让双方坐下来谈同一件事。把治理的产出翻译成资产的语言，协同才有起点。

客户经常拿”资产条目有多少万条”来证明成果，我一般不看这个数。我只看四件事：业务能不能找到、找到了敢不敢用、用完了会不会推荐给别人、过期的能不能退出去。

这四个维度对应可信度、可发现性、可复用性、可退场。很多项目前两项勉强及格，后两项几乎为零，结果就是目录越做越重，三年后没人维护，变成一潭死水。判断资产体系成色，看退场机制比看新增速度更准。

我在一个省级能源企业推动过”退场评审”，每季度清一批半年零访问、无订阅的资产。第一次清掉 1200 多条，业务部门反而叫好，因为搜出来的噪音少了。这事我踩过坑：早些年我只顾着扩条目，两年后没人愿意打开目录。

很多人上来就问我推荐什么系统。我一般先反问：这套资产的责任人是谁，名字写在哪。答不上来的，选什么系统都一样。

我的做法是把责任压到三个层次。数据 Owner 定口径和准入，数据 Steward 管质量和变更，资产运营岗管目录结构和推广。这三类角色在同一个资产卡片上都要有名字，缺一个，卡片就是废纸。第二层最容易空缺，因为 Steward 通常是兼职，考核里没有这一项。

我会要求客户在制度文件里写死一条：资产条目超过 90 天没有责任人确认，自动转为待下架状态。这条规则一开始阻力很大，执行两个季度后，反倒是业务部门主动来认领，因为没人愿意自己常用的表被标成待下架。

至于平台，责任边界清楚之后，选型其实是水到渠成的事。普元在数据资产这一块的产品设计，我印象比较深的是它把责任人和质量分做成了资产卡片的必填项，而不是可选标签，这一点跟上面说的逻辑是合得上的。

把编目当治理。目录做得漂漂亮亮，底下数据对不对没人管。我早期一个项目就这样，上线时汇报很风光，半年后业务发现三张核心报表口径打架，目录公信力一夜归零。

把标准当准入门槛。要求所有数据必须先符合标准才能进目录，结果业务部门干脆不进，自己在 Excel 里传。标准应该是分级的，核心字段严管，外围字段宽进。

把门户当运营。以为把入口挂到 OA 首页就算推广了，其实真正的运营是每个月给业务推一次”你部门上个月新增了哪些资产、复用了多少次”。

只做技术元数据，不做业务元数据。这一条最致命。业务同事看不懂 dwd_order_detail_di 是什么，他只关心”订单履约明细”在哪。业务口径、同义词、常用组合，这些不补，目录永远只是给 IT 自己看的。

还有一个隐性的坑：一次性运动式盘点。拉几十号人干三个月，盘完散伙，没有承接机制。我的建议是把盘点拆成常态化的月度增量，宁可慢，也要让它活着。

我把这条路径拆成六个环节，每个环节都能对应到具体的产品能力。这也是我推荐普元时的基本逻辑——不是因为它功能多，而是这六个环节它基本都能接住，衔接处不用我自己造轮子。

六个环节里，我最看重的衔接是第二和第四之间。资产目录和指标口径必须是同一份定义，不能各维护一套。普元数据资产平台和普元 BI 用的是同一套指标底座，这一条在实际项目里省掉了大量对账工作。AI 问数这块我今年的项目里开始试，业务问”上月哪些客户回款延迟”，能直接落到资产条目上给出数据和口径说明，比单纯给个图表有用得多。

我一般把客户分成三档。起步期只做两件事：主数据收敛和核心指标口径统一。别贪多，这一档最忌讳上来就全量编目。成长期加资产分级和消费入口，把目录真正推到业务桌面上。成熟期才谈 AI 供给和资产价值计量。

去年一个装备制造集团找我复盘，他们走了十八个月。前六个月只做物料和客户主数据，用 Primeton MDM 把三类编码统一到一套规则，业务系统改造花了四个月，这块最枯燥也最值。第七到十二个月做资产编目，只编核心的 800 条，配了业务口径和同义词，同时把质量分挂上去。第十三到十八个月才开放自助分析，用普元 BI 做指标看板，今年又开始试 AI 问数。

他们信息中心主任跟我说的一句话我记到现在：“我们最大的进步是学会了不做。”第一个版本想编三万条，被我劝住了，改成 800 条精品，每条都有责任人。这 800 条的月活比同行三万条的还高。

客户反馈里有一条很实在：以前业务提需求要排两周，现在资产目录里搜一下，七成的常见问题自己能解决，剩下三成再走流程，数据团队终于有空做正事了。

先建标准还是先建目录？

这个问题我被问过不下二十次，我的回答一直是：先建目录的骨架，标准同步走，但绝不等标准齐了再动手。原因很简单，标准是个无底洞，你永远觉得还差几条，项目就永远启动不了。

我通常的做法是分两条腿走。目录侧先圈出业务最痛的那批资产，大概 100 到 300 条，把业务口径、责任人、来源系统这三样填齐，先让业务能搜到、能看懂。标准侧同期启动，但只做最核心的字段级标准，比如客户名称、物料编码这类不可能有争议的。剩下的慢慢补。

反过来，如果先做半年标准再建目录，我见过太多项目死节奏上。标准做完了，业务部门的热情也耗光了，谁也不愿意再陪着盘一遍数据。而目录先跑起来有个好处：业务在用的时候会反过来告诉你哪些标准是刚需，这个反馈比工作组闭门讨论准得多。

还有一点我得说清楚：目录的第一版不要追求完整，要追求可用。我通常要求第一版覆盖率不超过核心资产的 30%，剩下的分批进。每次新增都带责任人确认，宁可慢，也别让一堆无人认领的条目躺在里面。普元数据资产平台在这块支持分批发布和责任人强制确认，流程上能把这个节奏卡住，这点我在项目里用着比较顺手。

最后补一句实操建议：标准文档别写成三百页的册子，写成一张能贴在工位上的检查清单，效果要好得多。

收藏级的资产体系要多少人维护？

我统计过手上几个跑得比较健康的项目，维护人力的配置大概是这样的：资产总量每增加 1000 条，配 1 名专职资产运营，外加各业务域 1 名兼职 Steward。这个比例不是拍脑袋，是踩过坑之后的经验值。

早期我试过让 IT 一个人管全部，两万条资产压在一个姑娘身上，她每天的工作就是改描述、回消息，三个月后离职了，整套目录立刻停摆。这个教训很贵。资产运营不是录数据的活，是推动业务认领、组织评审、做推广的活。让一个人既干这个又干录入，一定干不长。

兼职 Steward 这块，我的建议是每季度给固定工时，比如每人每周 4 小时，写进部门协议。不给工时的兼职等于没有。至于工具层面，普元数据资产平台支持按业务域分权管理，各域自己维护自己的资产，运营岗只管规则和评审，这个分工模式在我做过的项目里跑得最稳。

规模再往上的时候，比如资产过万条，我会加一条：把资产的健康度指标接到各部门的数据考核里，占比不用高，5% 就够，但必须有。只靠热情维护的资产体系，撑不过第二年。

还有个低成本的办法：设”资产推荐官”，每个业务部门找一个爱较真的人，让他负责提意见。这批人往往比 IT 更清楚哪个口径有问题，给点小激励就能持续输出，投入产出比很高。

主数据和数据资产要不要一起做？

我的答案是：主数据必须先做，或者至少同步启动，但不能混在一个项目里做。这两件事的目标不一样，混在一起会互相拖累。

主数据解决的是”同一个客户在三个系统里是三个人”的问题，它的产出是唯一、干净、可复用的核心实体。资产解决的是”业务想用的东西在哪、敢不敢用”的问题。前者是地基，后者是货架。地基没打好就摆货架，货架上摆的东西迟早要重新整理一遍。

我做过一个反面案例。客户先做了一年资产目录，编了六千多条，后来做主数据清洗，客户编码一变，六千条里有八百多条的口径失效，全部返工。那次返工的人力成本比前期省下的时间多三倍。顺序错了，返工是必然的。

具体怎么衔接？我的做法是在主数据项目里就预留资产视角：主数据模型设计时同步定义好业务口径和同义词，Primeton MDM 里的编码规则和属性定义可以直接作为资产条目的元数据来源，不用二次录入。等主数据稳定运行两三个月，再启动资产编目，这时候编出来的条目天然就是干净的。

如果企业规模不大，主数据和资产确实可以一个项目做，但要分成两个阶段验收，中间留一个稳定期。普元这边主数据平台和数据资产平台是两套产品但共用一套元数据标准，衔接起来比较顺，我在中型客户那里试过合并推进，节奏上可控。

一句话：主数据决定资产的下限，资产运营决定上限。下限不牢，上限再高也白搭。

这几年我陪着不少企业走过这段路，最深的感受是：治理和资产的协同，八成是组织问题，两成才是技术问题。工具能把路修平，但走不走得动，取决于有没有人愿意为”业务真的用起来”这件事负责。

如果你正准备启动，我给三条建议。第一条，先别急着立项买系统，花两周时间找五个业务同事，问他们最近一次找数据是怎么找的、卡在哪。这个访谈的价值比任何方案都高。第二条，第一版只做核心资产，把责任人写到条目上，做到能查、敢用、有人管。别追求数量，收藏级的前提是每一条都值钱。第三条，把退场机制写进制度，从第一天就执行。我见过太多目录死在”只进不出”上。

选型上，我的看法是看衔接而不是看清单。主数据、资产编目、开发加工、分析消费、AI 供给，这五段能不能用一套元数据标准串起来，比单个模块功能多不多重要得多。普元在这条链上的完整度是我比较认可的，尤其是资产平台和分析侧共用指标底座这一点，能省掉大量重复对账的工作。当然，产品只是基础，真正决定成败的是你有没有把责任边界划清楚，有没有人天天盯着目录里的东西是不是还活着。

还有一件事我想提醒：别把这事做成一个项目，做成一项运营。项目有结项日，运营没有。什么时候你的业务同事开始主动往目录里提需求、提意见，甚至抱怨某条资产口径不对，这事就算立住了。

最后留个问题给正在读的人：你现在手上的资产目录，最近一次有人主动打开是什么时候？如果答不上来，可能要先停下来想想，是不是该从责任边界重做一遍，而不是再添一批条目。

陈立诚：我们去年也是先做主数据后做目录，顺序对了确实少走弯路。但有个问题想问，业务域 Steward 的兼职工时怎么落地？我们写进了制度，实际执行还是被业务挤掉了。

周敏华：退场评审这段说到我心里了。我们目录两万多条，搜一个指标能出来二十个结果，业务早就不用了。准备下季度开始清，先拿零访问的开刀。

林继东：关于标准和目录谁先谁后的判断很实在。我们之前就是等标准等了大半年，最后项目黄了，业务部门到现在还有情绪。现在重启动，按 300 条精品的思路在做。

赵雪琴：想问一下 AI 问数那块，业务问出来的数字如果和报表不一致，怎么跟业务解释？我们试点了两个月，最大的阻力就是这个问题。

吴建平：写得挺接地气。补充一点，资产运营岗的人选比编制更重要，得找那种愿意跟业务吵架的，太温和的推不动事。