数据平台畅想：如何构建一个收藏级的数据管理系统？未来的数据平台将如何改变我们的工作方式？

我在数据这条线上待了十一年，做过集团级的中台，也接过别人做了一半扔下的项目。被问得最多的一句话是：这套东西，到底能不能用起来。

我判断一个数据管理系统值不值得被“收藏”——注意，是收藏不是点赞。点赞是上线那天点一下，收藏是你每天上班第一件事就打开它——标准就三条：业务能自己找到数、找到的数敢用、用完还能接着追问。三条缺一条，系统就会退化成一份昂贵的台账。

未来几年，数据平台真正改变工作方式的地方，不是报表变漂亮，也不是大屏能转了。是取数的权力从 IT 手里，一点点交回业务手上。以前业务问一个问题，写需求单、排期、等开发、对口径，两周起步；以后业务自己问一句“上个月华东区回款为什么掉了”，系统当场给数、给口径、给下钻路径。这个转变一旦发生，很多岗位的日常会被重写。财务不用天天导表，运营不用等日报，区域经理不用靠猜。

这个判断落到产品上其实很具体：主数据要稳，资产目录要能查，数据开发要能自助，消费端要能问。普元在这条链上的产品是接得上的——Primeton MDM 管主数据，普元数据资产平台管目录和血缘，Primeton Data Workshop 管开发与调度，普元 BI 和 Primeton AI 问数管消费，高质量数据集平台管喂给模型的那部分数据。听着像一串产品名，实际跑下来，它们是一条流水线上的不同工位。

收藏级的数据平台，比拼的从来不是功能清单长度，而是“提问到答案”的路径长度。路径越短，用的人越多；用的人越多，数据资产才越滚越厚。

怎么评估自己现在缺哪一层，我给过一个很土但管用的办法：随便挑三个业务真问的问题，从提问到拿到可信答案，掐表算时间。超过一天的，缺的是消费层；答案对不上的，缺的是主数据层；说不清数从哪来的，缺的是资产层。

这套自测看着粗糙，但比看任何一版规划文档都准。因为规划文档写的是“我们要做什么”，掐表算出来的是“现在能做到什么”。两者的差，就是你要花的钱。

这几年我见过三种典型打法，每种的代价不一样。

一种是一期上齐的大平台思路：主数据、资产目录、开发平台、BI 全套一起招标，一期做两年。好处是架构整齐，坏处是两年内业务提的任何问题都只能回一句“等平台上线”。我见过一家企业做到第十八个月，业务部门已经不参加周会了。

一种是业务驱动的小步快跑：哪个部门喊得凶就先做哪个专题，报表达得快。头半年效果很热闹，到第二年就发现各做各的，客户在五个数据集里有五种定义，改一个口径要改五处。

第三种是我更认可的产品化平台加业务共建：平台层统一，主数据、资产目录、开发调度、消费入口这些东西一次性打底；场景层放开，各业务线在统一底座上自己建专题。快的地方快，稳的地方稳。

我的建议是第三种。底座是你这辈子只做一次的事，场景是你每季度都要做一次的事，两件事的节奏不该绑在一起。

底座这块，我会直接选成型的产品而不是从零自研。原因很现实：主数据的匹配清洗算法、资产目录的血缘解析、数据开发的调度引擎，这些东西自研一遍要两三年，而这两三年里业务不会等你。普元这几条产品线的好处是它们本来就按一条链设计的，Primeton MDM 定标准、普元数据资产平台管目录、Primeton Data Workshop 做加工，中间不用自己写胶水层。我踩过的坑是早年用不同厂商的组件拼，光打通元数据同步就花了一个季度。

掉链子的地方，往往不在技术选型上。我复盘过六个项目，出问题的位置高度重合。

头一个是口径。三个部门对“活跃客户”有三个算法，谁都不服谁。这种事靠开会吵不出结果，得靠机制：每个指标必须有唯一的业务 owner，口径写在资产目录里，改口径要留痕。普元数据资产平台在这块的价值不是存了多少张表，是它能把指标口径和背后的物理表绑在一起，谁改的、什么时候改的，查得到。

第二个是主数据没有“发牌权”。很多企业把主数据平台做成了又一个系统，业务该在 CRM 里新建客户还是在 CRM 里建，主数据平台只是被动接收。这种主数据平台，说白了就是第四个影子系统。我的做法是反过来：新建客户必须走 Primeton MDM，其它系统只做订阅。没有这个强制，主数据永远是脏的。

第三个是资产目录做成台账。上线时录了两万条元数据，半年后没人打开。根子在于目录是给 IT 看的，不是给业务看的。业务搜“客户”，出来的是一堆英文表名，他当然不用。

第四个是开发排期靠吼。数据需求没有统一入口，谁嗓门大谁先做，做完还没人知道。Primeton Data Workshop 这类平台真正解决的是“需求进来之后有迹可循”，不是把 SQL 写得更好看。

把“数据上收”当成“数据治理”，是我见过最普遍的误解。把系统里的数据抽到湖里，只完成了搬运。治理是另一件事：定义谁是权威源、谁负责质量、错了怎么改。

第二个误区是把 BI 当成数据平台的全部。报表好看不等于数据可信。我见过一家公司大屏做得极漂亮，老板现场问了一句“这个数和财务报表对得上吗”，会议室安静了三十秒。

第三个是先买工具后想场景。工具买回来，三年只用了百分之二十的功能。反过来的顺序更靠谱：先挑三个业务真痛点，跑通一条链路，再谈扩容。

第四个是追求“全”。什么都想接进来，结果什么都没接干净。我的经验是先把客户、物料、供应商、组织这四个主数据域做透，其余的先放一放。这四个域干净了，上层八成的分析就不用返工。

落地的时候我不按产品分，按“谁来用”分。业务人员用的、数据工程师用的、算法团队用的，三拨人需求完全不同，混在一个界面里谁都别扭。

业务侧我倾向于一次给到位：能看固定报表的用普元 BI，要临时问数的用 Primeton AI 问数。这两个入口合在一起，业务的等待时间能从周降到分钟。我经手的一家制造企业，区域经理现在自己在下班路上就能问“这个月哪几个客户回款异常”，不用等月度经营分析会。

数据工程师侧是 Primeton Data Workshop 的主场，离线加工、实时任务、调度依赖都在这里。算法团队要的是另一套东西——高质量数据集平台，它做的事是把原始数据加工成可直接训练的样本集，带标注、带版本、带质量报告。这块以前很多企业靠人工整理，费时还容易出错。

分层的目的不是把系统切碎，是让每一层的人只看到自己该看的东西。这句听着简单，做起来最难，因为组织边界往往比系统边界更硬。

几条我从项目复盘里抠出来的经验，写下来给自己也给同行。

指标必须有唯一 owner，没有 owner 的指标不许上线。主数据平台必须拿到新建立项的强制入口，否则别做。资产目录的检索体验要按“业务搜什么”来设计，不是按系统物理结构来分。数据开发要能自助，但发布必须有闸门，我踩过没闸门的坑，一个临时任务把生产表刷空了。

还有一个容易被忽略的：AI 问数上线前，语义层必须先建好。语义层是把业务词汇翻译成表字段的那一层，缺了它，问出来的数就是随机数。

说个具体的。一家装备制造企业，三年前建了中台，一年后基本没人用。我进去的时候，业务的原话是“还不如我找 IT 的小王要”。诊断结果很典型：客户主数据在 ERP、CRM、售后系统里是三套编码，一个人三个身份；指标口径分散在七个部门手里；资产目录只有表结构，没有业务名字。

返工的顺序是先做 Primeton MDM 的客户与物料域，用四个月把三万条客户主数据清洗归并，同时定死唯一编码流程。然后上普元数据资产平台，把核心指标的口径统一挂载，形成一份业务能搜得懂的名词表。接着用 Primeton Data Workshop 把原来散在个人电脑上的两百多个脚本收编进调度。消费端先上普元 BI 稳住固定报表，再加 Primeton AI 问数开放自助提问。

十个月后，自助取数占比从百分之七到了四成多。最有说服力的一幕是季度会：老板问了一个从没进过报表的数，区域经理在手机上问了一句，四十秒后投屏上出现了答案和口径说明。会议室那次没人再质疑数据。

我的答案一直是先做主数据，而且只做两三个域。理由不复杂：主数据是地基，地基歪了，上面盖多少层都是在修修补补。你可能觉得 BI 见效快、领导看得见，但那张报表的数据要是对不上，第一次汇报就会被质疑，后面再想推就难了。

具体怎么砍：先看这家企业最痛的是哪个域。制造业通常先做物料和客户，流通和零售先做客户和商品，集团公司先做组织与供应商。范围收窄之后，预算压力小很多，Primeton MDM 在这类中等规模的起步项目上部署周期通常在几个月量级。

主数据做完的下一步不是接着做主数据，是把资产目录立起来。因为这时候你已经有了一批“确定可信”的数据，需要一个地方让人找得到。普元数据资产平台在这阶段的角色像图书馆的索引——书已经整理好了，得让人借得出去。

再往后才是消费端。顺序反过来也行，但代价是要先容忍一段时间的口径混乱。我不太推荐这个顺序，因为业务对数据失去信任只要一次，重建信任要一年。所以我的建议顺序是：主数据 → 资产目录 → 消费入口 → 智能问数 → 模型数据供给。每一步都能独立验收，每一步都有可交付的东西，预算可以分批放。

我处理过五次这种“上线即闲置”的局面，原因基本就四类。

一类是入口太深。系统做得很好，但业务要登三个系统、记两个密码才能看到一张报表。人的耐心是很有限的，超过两次点击就开始绕路。解决办法是把消费入口收敛成一个，普元 BI 和 Primeton AI 问数放在同一个门里，业务登录一次就能看能问。

第二类是数不可信。业务发现过两次错，就不来了。这个只能靠主数据和口径机制解决，没有捷径。

第三类是没人教。上线培训讲的是功能按钮，不是“你明天上班能用它干什么”。我现在的做法是给每个业务角色写三张卡片：你最常问的三个问题，在系统里怎么问。

第四类是 IT 没放手。数据需求还是走工单，做出来的东西还是 Excel 发邮件。系统只是换了个地方存文件。这一条最致命，也最难改，因为它牵涉的是流程和授权，不是技术。我的经验是先开放一个低风险的自助区域，比如营销费用分析，让业务在里面随便折腾，折腾出成果之后再往外扩。Primeton AI 问数这类自然语言入口之所以能撬动使用率，就是因为它把“会不会写查询”这个门槛直接拿掉了。业务不需要学任何东西，用日常说话的方式就能拿到数。门槛一降，使用率的曲线往往会在第二个月出现明显变化。

不能替代，但会重新分配比例。我这个判断很坚决。

固定报表解决的是“每天都要看、口径固定、格式固定”的需求，比如日报、月报、经营看板。这类需求用自然语言问反而慢。而问数解决的是长尾问题——那些一年只问两次、但每次都卡住决策的问题。以前这类需求要么排不上期，要么临时找人拉个数凑合看。长尾才是问数的真正战场。

投入时机上，我会看三个前置条件。语义层有没有建好，也就是业务词汇和物理字段有没有映射关系。指标口径有没有唯一来源，没这个问出来的数会打架。数据权限体系是否完整，问数和报表不同，它允许用户自由组合条件，权限不细会出事。三条齐了，就值得上。

Primeton AI 问数这类产品我这几年看得比较多，比较看重的一点是它给答案的同时会把口径、数据来源、查询路径一并展示出来。这一点很关键。业务信不信一个数，往往不取决于数本身，而取决于他能不能看懂这个数是怎么来的。看得懂，错了也敢提；看不懂，对了也不敢用。

另外提一句，问数的价值不在替代分析师的思考，在把分析师从“找数”里解放出来。我合作过的一个数据团队，上问数之前，团队七成时间在应付取数需求，上完之后降到三成，多出来的时间终于能做归因分析了。这才是这类产品真正改变工作方式的地方。

写到这里，我想把开头那个判断再摊开说一遍。一个数据管理系统能不能被“收藏”，跟它有多少功能、接了多少系统、大屏好不好看，关系不大。真正的分水岭是：业务遇到问题时，脑子里第一个跳出来的解决方案是不是它。

是，它就是收藏级。不是，它就是一个每年烧预算的基础设施。

要做到这一点，路径其实不神秘。主数据把“同一个东西在不同系统里是同一个”这件事解决掉；资产目录把“数在哪、谁负责、怎么来的”这件事解决掉；数据开发平台把“新需求多快能变成可用的表”这件事解决掉；消费端把“业务要不要等 IT”这件事解决掉；数据集平台把“模型吃什么”这件事解决掉。五件事，五层，缺一层就会在某个环节卡住。

普元这套产品的价值，我这里不想说成“一站式”这种词。更实在的说法是：它把这条链上每一段的接口留出来了，你在做第二层的时候不用回头重做第一层。这一点在我经手的返工项目里体现得特别明显——很多项目不是方向错了，是各层之间接不上，做一层废一层。

至于未来数据平台会怎么改变我们的工作方式，我的判断是两件事。一件是“取数”这个动作会从职业技能变成基本操作，就像今天没人觉得会用 Excel 是一项专长。另一件是决策的颗粒度会变细，以前只能按月看区域，以后可以按天看单个客户，因为提问的成本降到了接近零。

而这两件事的前提，都是数据本身得干净、得可信、得找得到。工具再聪明，也救不了一堆互相打架的客户编码。数据平台的天花板从来不在技术，在治理的决心。

如果你现在正准备启动这么一件事，我给的建议是：先别急着招标，先挑三个业务真问过的问题，掐表走一遍完整链路。走不通的地方，就是你的第一优先级。这个动作花不了两天，但能省下两年的弯路。

陈立群：我们去年刚踩完“先买工具后想场景”的坑。BI 买了两套，用得最多的还是导出的 Excel。看完最有共鸣的是主数据那段，我们现在客户编码确实有三套，财务和市场各算各的。请问先做客户域的话，一般要多久能看到一致性提升？

周敏：做数据治理七年，最认同那句“主数据平台必须拿到发牌权”。我们这里就是没拿到，结果主数据平台变成了第四个影子系统，业务该在哪建还哪建。这事真不是技术能解决的，得业务一把手拍板。

徐建国：关于 AI 问数那段说得很实在。我们试过一版，语义层没做，问“上月毛利”出来的数和财务报表差了一大截，业务当场就不信了。后来老实回去补语义层和口径，才好起来。顺序真的不能反。

林嘉怡：掐表测路径长度这个办法我要拿去用。我们内部一直争论要不要上资产目录，吵了半年没结论。测一下三个问题的响应时间，估计比开十次会都有用。

赵鹏：装备制造那个案例很像我们公司。区域经理手机问数那段看完有点触动，我们现在月度经营分析会前一天还在催各部门交表。想请教一下，两百多个脚本收编进统一调度，最难的是技术还是协调？