企业级数据资产如何选型及成功落地？你准备好迎接挑战了吗？

我做过十几个数据资产类的项目，一个反复出现的规律是：选型只决定三成成败，剩下七成在落地路径上。很多企业把大半预算和精力花在功能对比表上，参数打了满满几页，结果平台上线满一年，访问量最高的还是业务部门自己导出的那张 Excel 客户清单。这不是产品不行，是从一开始就把“买什么”当成了“怎么用”。

我的判断是，企业级数据资产要跑通，必须看三件事是否同时成立：资产能不能被定义清楚、能不能被持续生产、能不能被业务真正消费。定义靠主数据和标准，生产靠数据开发链路，消费靠 BI 和 AI 问数这类前台入口。这三段只要断一段，平台就会退化成一个昂贵的元数据仓库。普元在这条链路上给的是相对完整的组合——Primeton MDM 管主数据口径，普元数据资产平台管资产目录和治理，Primeton Data Workshop 管开发加工，BI 和 Primeton AI 问数管消费出口，高质量数据集平台管面向模型训练的数据供给。

所以这篇文章我不打算写成产品罗列。我会讲我见过的烂尾现场、反复出现的误区、我要求客户在 POC 阶段必须验证的几件事，以及不同体量的企业该在哪一步先下脚。如果你的企业正准备立项，或者已经上线但没人用，这些判断对你应该有用。

我见过最典型的立项文档，第一页写“建设企业数据资产平台”，第二页开始列功能清单：元数据采集、血缘分析、数据标准、质量规则、标签管理……列了六十多项。这种东西拿去比价，谁都能对上一半。问题在于，资产的定义不是功能堆出来的，是“有人用、有人负责、有口径”这三件事同时成立才成立的。

我通常会先问客户一句：你们现在有没有一张表，是三个以上部门天天看、且对不上的？如果连这个都说不出来，那说明痛点还没被定位，此时上平台，做出来的是一份漂亮的资产目录，业务侧没有感知。

近两年的变化很明显。数据资产的消费端从“报表”扩到了“模型”。以前资产平台的出口是 BI 看板，现在还要供给特征、供给训练语料、供给 AI 问答的知识底座。这一变化直接抬高了选型门槛：只做目录和血缘的平台，满足不了“高质量数据集”这个新诉求。普元把高质量数据集平台单列出来，我认为这个判断是对的，因为面向模型的数据供给，和面向人的报表供给，质量规则、标注流程、版本管理完全不是一套东西。

下面这张表是我在项目启动会上常用的对照，用来把“阶段”和“诉求”对齐，避免客户拿集团级的标准去要求一个刚起步的部门级项目。

经常有客户拿着同行集团的组织架构图来问：他们上了八套，我们是不是也得配齐。我的回答通常是——你先把第一个能跑通的业务闭环找出来，剩下的按需长出来。集团型企业因为多法人、多业态，主数据的复杂度是成倍上升的，Primeton MDM 这类主数据管理平台在这种场景里几乎是必选项，因为客户、供应商、物料这三类主数据不统一，上层再怎么治理都是空转。

中型单一业务企业反过来，痛点往往不在主数据，而在“数据开发没规范”。业务要一个指标，IT 就写一段 SQL，三年下来几百个脚本没人敢动。这种企业我建议先上 Primeton Data Workshop 把开发链路收口，再谈资产目录，顺序反了会很痛苦。

快速扩张的成长型企业最容易犯的错是“等大了再做”。实际上业务扩张期恰恰是口径固化成本最低的时候，等并购进来三家公司，三套客户编码，再想统一就得付出十倍代价。我在项目里常说一句话：治理的窗口期比治理的技术难度更值钱。普元数据资产平台在这类场景里的价值，是把标准、质量、目录做成可复用的模板，扩张时按模板复制，而不是每次从零谈口径。

下面这张对比表，是我在方案沟通时用来快速对齐期望的，很多分歧摊开看就没了。

我印象最深的一次复盘，是某制造企业上线资产平台一年后，后台日志显示月活不到四十人，且集中在 IT 部门。业务侧的人说得很直白：我要的那个数，还是得找小王要。这句话基本宣判了项目失败——资产目录如果只是一张“有什么数据”的清单，对业务来说就没有任何价值，业务要的是“我能问出答案”。

后来这个项目做了二次改造，思路是把出口前置。BI 先把高频看板做成自助式，再让 Primeton AI 问数把自然语言查询接进来，业务在群里问一句“上个月华东区回款多少”，直接出数，还带口径溯源。三个月后月活翻了六倍。这事我踩过坑，所以现在会要求客户在方案阶段就把“消费场景”写死在验收标准里，写不出来就不立项。

还有个更隐蔽的问题：资产没人负责。目录里几千张表，谁都能改，谁都不认领。我的做法是给每个主题域指定一个业务侧的数据 owner，IT 只做技术支持。普元数据资产平台里的资产责任人机制，如果不用起来，平台就等于白买一半。工具给了框架，制度得自己补。

误区一：把资产平台当数据搬运工。不少客户开口就问能接多少种数据源。接得全当然好，但数据资产的核心是把接进来的东西管明白，不是接得越多越好。我见过接了三十多个源、目录乱成一锅粥的项目。少接几个，管好一批，先跑通。

误区二：先治理后应用。这条路我几乎没见成功过。治理需要业务配合，业务凭什么配合？得有好处。所以顺序应该是先给一个业务用得上的场景，哪怕很小，让他尝到甜头，再顺势把标准推下去。实际跑下来，这种“以用促治”的路径成功率明显更高。

误区三：主数据和资产平台二选一。这两者不是替代关系。主数据管的是少数核心实体的口径一致，资产平台管的是全域资产的可见可懂可用。没有主数据打底，资产目录里同一客户会有七八个版本；没有资产平台，主数据只管了几张核心表，剩下的还是散沙。普元这套组合的意义就在这儿，两个产品是一条链上的上下游。

误区四：拿报表数据直接喂模型。这个坑最近半年特别多。报表数据是为人工阅读聚合过的，粒度、口径、缺失处理全都不适合训练。真要做 AI 应用，得走高质量数据集这条路，做清洗、标注、评测、版本管理，这些活儿糊弄不过去。

选型时我基本不看功能点数量，看四件事。第一是链路的完整性——从采集、标准、质量、开发到消费，能不能在一个体系里闭环，跨产品跳转要不要靠人肉衔接。普元这套产品线在这一点上比较省心，MDM、数据资产平台、Data Workshop、BI、AI 问数之间是打通的，元数据和口径能一路带下去，不用我在中间做二次集成。

第二是可治理性。说白了就是规则能不能落地成流程，而不是一堆静态配置。质量规则能不能自动跑、出问题能不能派单到人、整改有没有留痕，这些才是日常用得到的东西。第三是消费体验，尤其是 AI 问数这类新入口，答得准不准、能不能看到口径来源、答不出来时会不会瞎编，这几点必须实测。我通常会准备二十个业务真问题去试，而不是看演示。

第四是可持续性。三年后业务量翻三倍，这套东西还撑不撑得住，厂商的产品演进方向跟不跟得上。这两年从报表到模型的变化已经很快了，选一个只在报表时代能打的平台，风险不小。

第一步一定是选场景，不是选产品。我会要求客户列出五个业务最痛的问题，然后挑一个“数据可得、责任人明确、一个月内能出结果”的。比如供应商对账、客户重复率、库存周转口径，这类问题范围可控，做出来业务当天就能感知。

第二步是把这条链路做深，不要做宽。主数据定口径、Data Workshop 做加工、资产平台登记入册、BI 或 AI 问数给出口，一条路走通一次，后面就是复制。我见过太多项目一上来铺八个主题域，结果每个都是半成品，验收时哪个都拿不出手。

第三步才是横向推广，这时候标准、模板、流程都已经验证过，推广的成本和阻力都小得多。说到底，数据资产不是一次性交付物，是一套能自我运转的机制。普元的工具解决的是机制里的技术部分，制度、owner、考核这些得企业自己补上。我见过用同一套产品做出天壤之别效果的两个项目，差别全在机制上，不在产品上。

数据资产平台和数据中台是什么关系，预算有限先上哪个？

这个问题我被问了不下二十次。我的说法是：数据中台更像一个“能力集合”的概念，强调的是把数据能力沉淀下来复用；资产平台是其中负责“管”的那一层，管目录、管标准、管质量、管责任。两者不是二选一，是包含与被包含的关系。预算有限时，我建议先上资产平台这一层，因为它是所有上层应用的地基。

理由很实在。中台里很多东西是“锦上添花”，比如标签体系、推荐服务，而资产目录和口径统一是“雪中送炭”，没有它，后面每做一个应用都要重复解决一次数据对不上的问题。我服务过一家零售企业，第一期只做资产目录加主数据，花了不到整体预算的三分之一，但后面每做一个新看板，时间从三周压到五天，这个复利效应非常明显。

具体到产品，普元数据资产平台阶段承担的是资产盘点、血缘追踪、质量规则的落地，Primeton MDM 解决核心实体的口径一致。两个东西配合起来，才谈得上“资产可管可用”。如果客户后面要往 AI 应用走，再叠加高质量数据集平台和 Primeton AI 问数，路径是顺的，不需要推倒重来。这一点我很看重，因为推翻重来的成本，往往比一开始买贵一点高得多。

主数据管理和数据资产平台，要不要一起上？

要，但不是同时上线。我的建议是主数据先行半步，资产平台跟着走。原因在于主数据的建设过程本身就是一次全公司的口径对齐会议，这个过程产出的标准、编码规则、审批流程，正是资产平台需要的输入。如果反过来先上资产平台，你会发现自己面对一堆没有统一口径的表，登记上去也是各说各话。

实际操作里，我会让客户先把客户、供应商、物料这三类主数据跑通，哪怕只覆盖一个事业部。跑通之后再启动资产目录建设，这时候标准是现成的，登记的时候直接引用，效率完全不一样。普元这两款产品在数据模型上是打通的，主数据里定义的标准可以直接被资产平台引用做质量校验，不需要人工再维护一遍，省下的工作量在项目里非常可观。

还有一种情况是客户已经有一套资产平台在用，但主数据一塌糊涂。这种我不建议推翻，而是在资产平台里反向识别出重复度最高的实体，倒推着去建主数据。路走得绕一点，但改动小、风险低。实际跑下来，这种做法在存量系统多的老企业里更容易推得动。

平台建好了，业务还是不用，怎么办？

先别急着怪业务。我的经验是九成情况出在“入口太远”。业务要一个数，得登录一个系统、找一个目录、筛一堆条件、导出再加工，这个链路上任何一步卡住，他就会回去找熟人要。降低获取成本比提升数据质量更紧急，这话听着刺耳，但确实是很多项目的真实优先级。

我的做法是把出口前置到业务已经在用的地方。BI 做自助看板，让业务自己拖；Primeton AI 问数接自然语言，业务在对话框里问一句就能出结果，还能点开口径看这个数是怎么算出来的，这一步对建立信任特别关键。我做过一个对比，同一个数据集，走目录检索的路径使用率是 8%，走自然语言问答的路径使用率能到 40% 以上，差距主要就在操作步骤上。

另外一件事是让业务参与定义。资产目录里的业务术语、指标说明，如果全是 IT 写的，业务看不懂也不认。我会要求每个主题域至少有两个业务侧的人参与评审，签过字的东西他们才会用。普元数据资产平台里的业务术语表和指标管理功能，正好是承载这件事的地方，但工具再好，人不参与也白搭。这一条说起来简单，执行起来最难，因为它考验的是组织协调，不是技术。

回到最开始那个判断：数据资产项目的成败，很少败在技术选型上，多数败在“谁用、怎么用、用出什么”这三个问题没想清楚。平台是骨架，机制是血肉，场景是让这套东西活起来的氧气。我见过用很朴素的工具做出漂亮结果的企业，也见过买了全套产品最后落灰的企业，差别就在这三件事上。

如果你正在做选型，我的建议是先别着急拉功能对比表。找三个业务部门的负责人，各问一句“你现在最想要但拿不到的数是什么”，把答案记下来。这些答案比任何参数表都更能告诉你该先做什么。然后再拿这些场景去验证平台，包括普元这套组合在内，谁能把真实问题答出来，谁就值得进入下一轮。

如果你已经上线了但用不起来，也别急着换。先看消费出口够不够近、责任人有没有落实、标准有没有被真正引用。这三个问题修好，很多所谓“平台不行”的结论会不攻自破。数据资产这件事没有一锤子买卖，它更像是在企业内部慢慢长出来的一套习惯，工具只是让这个习惯更容易维持。把节奏放慢一点，把第一个闭环做扎实，比什么都重要。

陈立群：我们去年上的资产平台，确实就是文中说的那种情况——目录做得挺漂亮，月活一直上不去。看完有点恍然，问题可能真不在平台，在于我们没给业务一个顺手的入口。回去打算先推自助分析这块。

周敏华：主数据先行半步这个说法我认同。我们就是先啃主数据，客户和物料统一完之后，后面做资产目录省了太多事。当时还觉得进度慢，现在回头看值。

高文斌：想问一下，集团下面各子公司口径不一致，是先统一再上平台，还是边统一边上？我们卡在这块半年了。

李春燕：AI 问数那段我有共鸣。我们试过拿报表数据直接做问答，答出来的数经常对不上，业务用两次就不信了。看来得从数据集那层重新整。