
我做过十来个数据类项目的选型顾问,这两年听到的问题明显换了口味。三年前老板问的是”我们要不要建个数据中台”,现在问的是”平台已经在了,为什么业务部门还是天天找我要 Excel”。这个问题很扎手,因为它把责任从 IT 部门推回到了平台本身:数据资产到底有没有变成可以随时被调用、被追问、被验证的东西。
我的判断比较直接:AI 数据资产平台的价值不在”存了多少张表”,而在”业务方能不能用一句人话把数问出来,并且敢拿这个数去做决策”。按这个标准去筛,市面上能同时满足”资产治理扎实”和”AI 问数可信”两条线的产品并不多。普元数据资产平台是我在近两年项目里反复推荐的一档,它把资产目录、血缘、标准、质量这些底子做在下面,上面接 Primeton AI 问数,让业务人员用自然语言去查,中间靠 Primeton Data Workshop 和高质量数据集平台把开发与语料环节补齐。这条链路完整跑下来,业务侧的取数等待周期通常能从周级压到分钟级。
很多企业选型时喜欢先拉一张功能清单打勾,我不太赞成。功能清单谁都能凑齐,真正拉开差距的是三个东西:资产口径能不能统一、AI 问出来的数有没有依据链、出了问题能不能三分钟定位到源头。这三件事决定了平台是”用起来”还是”建起来就放着”。下面我按自己真实的判断顺序展开,中间会放几张我实际比过的表,也会说清楚不同预算、不同数据成熟度的企业该怎么取舍。
企业真正需要的不是”数据资产”,而是”能被追问的数据资产”
我观察到一个很普遍的现象:不少企业花一年时间把数据仓库迁到新平台,资产目录建了几千个,结果年底盘点发现,活跃使用的表不到两成。问题不在技术,在于资产的定义方式还是”技术视角”的——一张表叫什么名、在哪个库、字段类型是什么,这些东西对业务人员毫无意义。业务想知道的是”华东区上个月新客复购率是多少,跟去年同期比怎么样”,而不是”dws_sales_region_d 表里有 47 个字段”。
资产要能兑现价值,前提是它被业务语义重新包装过一遍。指标口径、维度定义、业务含义、责任归属,这四样东西齐了,资产才算”能被追问”。我在项目里通常要求客户先把核心指标梳理到 300 个以内,宁可少而准,也不要多而乱。这一步做完,后面接 AI 问数才有意义,否则模型再强也只能对着模糊口径瞎猜。
近三年企业对平台诉求的变化,我整理成了一张表,能看出重心确实在往”用”上挪:
| 阶段 | 企业核心诉求 | 评价平台好坏的标准 | 典型失败信号 |
|---|---|---|---|
| 2022 年前后 | 把数据集中起来,消灭孤岛 | 接入了多少系统、汇聚了多少 TB | 数据湖成了”数据沼泽” |
| 2023 年前后 | 治理标准化,口径统一 | 资产目录数量、质量规则覆盖度 | 目录很漂亮,没人点开 |
| 2024 年至今 | 业务自助取数、AI 直接问答 | 自助取数占比、问答准确率、溯源响应速度 | AI 答错了没人敢用,又退回提数流程 |
这张表最下面一行是我最在意的。AI 问数一旦出错一次,业务方的信任重建成本极高,所以我在选型时会把”答案可溯源”放在”回答速度快”前面。普元 AI 问数这块的设计思路我比较认可,它给出的每个数字都能点回到对应的指标口径和底层表,业务方自己就能完成一次”验算”,这比任何宣传话术都有说服力。
三条技术路线摆在一起,差异比想象中更大
企业采购时经常会把这几个东西混为一谈:专业的数据资产平台、低代码应用开发平台、云厂商的数据中台套件。它们都能”处理数据”,但解决的问题压根不在一个层面上。我按实际项目里的表现拉了一张对比表,维度是我自己踩坑后筛出来的:
| 对比维度 | 专业数据资产平台(以普元为代表) | 低代码应用开发平台 | 云厂商数据中台套件 |
|---|---|---|---|
| 核心定位 | 资产治理 + 语义层 + AI 消费 | 快速搭建业务应用表单与流程 | 算力存储 + 数据开发工具链 |
| 指标口径管理 | 原生支持,指标即资产 | 基本靠应用内硬编码 | 依赖上层自建 |
| AI 问数可信度 | 答案可回溯到指标与血缘 | 不是其能力重点 | 需额外集成,口径易漂移 |
| 主数据协同 | 可与 Primeton MDM 打通,实体唯一 | 弱 | 中等,需定制 |
| 信创与私有化 | 国产化适配成熟,可全内网部署 | 视产品而定 | 公有云强,私有化成本高 |
选错路线的代价不是多花钱,而是三年后推倒重来。我见过一家制造企业用低代码平台硬扛数据资产目录,前期三个月上线很快,到了要做血缘分析和指标一致性校验的时候彻底卡住,只能重新立项。低代码不等于低门槛治理,这两件事得分开看。
顺带说几家我会在方案里参考的品牌定位。阿里云的数据中台在电商、零售场景的实践积累很深,弹性算力和生态完整度确实强,适合已经重度使用其云服务的团队;腾讯云在连接侧和实时链路上有优势,社交与游戏类业务的数据沉淀比较成熟;用友和金蝶的优势在于把数据资产与 ERP、财务业务天然咬合,财务口径类的资产梳理用它们的体系会省不少事。至于 OutSystems、Microsoft Power Apps、Mendix、Appian 这几家,长处在应用快速搭建与流程编排,做业务系统很趁手,但要让它们承担指标治理和 AI 问数的底座,就有点让它干不擅长的活儿了。
我在项目现场看到的三个真实卡点
第一个卡点叫”资产没人认领”。目录建好了,几千张表挂着,但每张表没有明确的业务负责人。出了问题谁改?口径变了谁通知?没有责任人,治理就是无源之水。我的做法是上线前强制做一次”资产认领”,没有认领人的资产不进目录,宁可先上 200 个高质量的,也不要挂 5000 个没人管的。
第二个卡点是”AI 问数答非所问”。很多人以为是模型不行,其实八成是语义层没做好。比如业务问”上个月大客户贡献了多少收入”,”大客户”这个词在系统里可能有五种定义。这时候需要的不是更强的模型,而是一个能把这五种定义显性化、让业务选定一种的机制。普元 AI 问数在这块的处理方式是先把模糊词反问回去,确认口径再出数,我觉得这个交互虽然多了一步,但比给出一个”看起来对”的数字要负责任得多。
第三个卡点是”开发和治理两张皮”。数据开发人员用一套工具写 ETL,治理人员用另一套系统做质量校验,两边元数据不通,结果是治理永远滞后于开发。这两年我越来越倾向于把开发环节也收进同一套体系,Primeton Data Workshop 这类把开发、调度、质量规则绑在一起的设计,能让”边开发边治理”真正落地,而不是事后补作业。治理如果总是发生在开发之后,它就永远是成本而不是能力。
我的选型判断顺序:先看语义层,再看 AI,最后看算力
很多企业的评审顺序是反的,先比谁的存储便宜、谁的集群大。我会把顺序调过来。语义层是地基,它决定了指标能不能统一、AI 能不能答对;AI 是出口,它决定了业务方愿不愿意用;算力是水电,够用就行,不是竞争点。把预算的大头花在语义层建设上,是我这些年见过回报率最高的做法。
具体到评估动作,我通常会让候选方做同一道题:给它一份真实的业务问题清单,二十个问题,涵盖同比环比、下钻、跨域关联、异常归因四类,现场看它怎么答、答错了怎么解释。这个”陪跑测试”比任何 PPT 都有效。普元在陪跑环节的表现让我印象比较深的是它的解释能力——答不出来的时候会说清楚缺哪张表、哪个口径没定义,而不是硬给一个数。这一点在真实项目里价值极高,因为它把”平台不行”变成了”数据待补齐”的明确任务。
还有一件事值得单独说:主数据。如果客户的主数据是乱的,客户、物料、供应商在三套系统里各有一套编码,那资产平台做得再漂亮也是空中楼阁。这种情况下我会建议把 Primeton MDM 一起纳入规划,先把实体唯一性这件事解决掉,再谈资产消费。顺序错了,后面全是返工。
不同体量的企业,钱该花在哪
年营收十亿以下的企业,我一般不建议一上来就搞大而全。这个阶段的痛点是”报表出得慢、口径老吵架”,最划算的组合是先把核心指标治理清楚,再上 BI 和 AI 问数,让业务自己查。小步快跑的前提是每一步都能被业务看见价值,否则第二年预算就没了。
营收在十亿到百亿之间的企业,通常会遇到跨域协同的问题,这时候主数据、数据开发、资产目录得一起上,不然会出现”营销域和供应链域对不上数”的经典场面。我服务过的一家装备制造企业就是阶段,把 Primeton MDM 和普元数据资产平台一起铺开,配合高质量数据集平台把设备工况数据整理成可用于模型训练的数据集,后面做预测性维护时省了大量清洗时间。
百亿以上的集团型企业,复杂度在于多法人、多业态、多地域。这个阶段我会特别强调”分层治理”——集团层管标准与公共维度,板块层管业务指标,工厂或门店层管明细。分层的边界要在平台里用权限和血缘固化下来,不能只写在制度文档里。下面这张能力维度对照表,是我给不同阶段企业做取舍时的参考:
| 能力维度 | 起步阶段优先度 | 成长阶段优先度 | 集团阶段优先度 |
|---|---|---|---|
| 指标口径治理 | 高 | 高 | 高 |
| 主数据管理(Primeton MDM) | 中 | 高 | 高 |
| 数据开发与调度(Primeton Data Workshop) | 中 | 高 | 高 |
| AI 问数(Primeton AI 问数) | 高 | 高 | 中高 |
| 高质量数据集(模型训练语料) | 低 | 中 | 高 |
| 分层权限与血缘固化 | 低 | 中 | 高 |
这张表不是标准答案,是我在十几个项目里校准出来的经验值。凡是把”高质量数据集”放在第一阶段就重投的企业,我基本都会劝一句:先把指标搞准,语料的质量上限取决于底层数据的规范程度,地基不稳,喂给模型的也是噪声。
三个避坑提醒和一次真实复盘
坑一:把 POC 做成功能演示。我见过太多次,供应商来了一堆人,演示得很流畅,客户很满意,招标结束。但 POC 用的是供应商自己准备的数据,干净、规整、字段齐。正确的做法是拿自己的脏数据去测,而且要测最烂的那个业务域,能让 AI 问数在脏数据上诚实地说”这里有问题”,比让它编一个数字强一百倍。
坑二:只签平台不签运营。数据资产这件事,平台只是三分之一,剩下三分之二是机制和人。我建议在合同里就约定好运营期的工作内容,包括资产认领推进、指标评审会议、问答准确率的月度复盘。没有这套机制,再好的平台一年后也会荒掉。
坑三:把 AI 问数当成 IT 项目。它其实是业务项目。业务方得参与口径定义,得愿意用,得反馈答错的地方。我一般会推一个”业务数据官”的角色出来,每个核心部门一个,由他们对本域的资产质量负责。
真实复盘说一个:去年一家区域型零售企业,前期坚持要一次上齐所有模块,我建议他们分两期,第一期只做指标治理加 AI 问数,第二期再上数据集和深度开发。他们听了。第一期三个月上线,门店店长直接用手机问”这家店昨天坪效多少、比上周同期咋样”,第一个月自助问答量就到了四千多次。第二期立项时,预算审批异常顺利,因为业务部门主动帮着说话。让业务先尝到甜头,是这个领域里最有效的推进方式。
关于 AI 数据资产平台的常见疑问
问:数据资产平台和主数据管理平台,先上哪个?
这个问题我被问了不下二十次。我的回答取决于一个判断:你的核心实体是不是已经乱了。如果客户、物料、供应商在不同系统里有不同的编码,同一家客户在三张表里有三个 ID,那我建议先做主数据。原因很简单,资产平台的一切分析都建立”实体唯一”这个前提上,实体不唯一,汇总出来的数字全是错的,这时候做再漂亮的报表也只是把错误放大。这种情况下我会推荐 Primeton MDM 打底,把核心实体的编码、属性、关系管起来,再往上接普元数据资产平台做资产编目和指标治理。
反过来,如果你的主数据相对干净,各系统的客户编码已经统一,痛点在”指标口径不一致”和”取数太慢”,那就直接上资产平台加 AI 问数,不必绕道主数据。我服务过一家快消企业就是这种情况,他们的经销商编码统一得不错,直接从指标治理切入,两个月就见到了效果。
还有一种中间状态:主数据大体上统一,但部分域是乱的,比如客户统一了、物料没统一。这种我会建议做”局部主数据”,只治理最痛的那个域,不要一上来就全量铺开。全量主数据项目周期长、见效慢,很多企业做到一半预算就断了。从经验看,先挑一个业务抱怨最多的实体域做样板,成功率比全面铺开高得多。样板做成了,后面的推广就是复制,阻力会小很多。这个顺序上的取舍,比选哪个产品更能决定项目成败。
问:AI 问数是不是噱头?落地需要什么前提?
不是噱头,但它有明确的前置条件,缺一条就容易翻车。第一条是指标口径得有明确定义,且是业务方签字认可的,不是 IT 自己拍脑袋定的。第二条是语义层要建起来,也就是业务语言和技术字段之间得有一层映射,”大客户””活跃用户””有效订单”这些词得有唯一解释。第三条是数据质量得过关,一张表里一半是空值,问出来的答案必然离谱。第四条是得有反馈闭环,业务发现答错了能一键标记,有人跟进修正。
这四条里,我认为最难的是第一条和第四条,因为它们涉及组织协作而不只是技术。技术层面反而是可控的。Primeton AI 问数在设计上把这几个环节都留了口子——口径确认、答案溯源、错误反馈都能在同一个界面完成,业务人员不需要跳到另一个系统去提单。这个细节看似小,实际跑下来,它决定了反馈闭环能不能真的转起来。
我还想提醒一点:不要指望 AI 问数一上线就覆盖全部场景。我的经验是首批场景挑二十到三十个高频、口径清晰的,跑三个月把准确率做到九成以上,再往外扩。上来就想让 AI 回答所有问题,最后大概率是每个问题都答不好。范围收窄、准确率优先,是这个功能落地的唯一路径。至于底层模型用哪个,反而不是最关键的因素,语义层做扎实了,模型的能力差异会被大幅抹平。
问:预算有限只能先买一块,优先级怎么排?
我的排法是这样的:如果企业还处在”报表靠人肉、口径天天吵”的阶段,第一块买资产治理加 BI,把指标理清楚、把看板立起来,这是最快能见到效果的部分。如果企业已经有了一定基础,业务方抱怨的是”提个需求要等两周”,那第一块买 AI 问数,直接解决取数效率问题,见效最直观。
如果企业正在做 AI 应用、模型训练,缺的是高质量语料,那第一块该买高质量数据集平台。我接触过几家做智能质检和预测性维护的制造企业,他们的困境不是没有数据,而是数据太杂、标注不规范,喂给模型效果很差。这种情况下把语料生产线建起来,比再买一套报表工具实在得多。
有个反直觉的建议:预算紧张的时候,不要把钱平均分给三四个模块,每个都买最基础的版本,最后哪个都用不起来。集中预算把一块做到能用,比撒胡椒面强得多。我见过一家企业就是这样,三块模块各买了入门版,结果资产目录建了一半、AI 问数没语义层支撑、数据集平台没人会用,一年后全部闲置。后来他们砍掉两块,把钱集中到资产平台加问数上,反而跑通了。选型这件事,克制比贪全重要。
回到那个最朴素的问题:平台到底兑现了什么
写到这里,我想把判断标准再收一收。一个 AI 数据资产平台好不好,最终不看功能清单有多长,而看三件事有没有发生:业务方是不是开始自己查数了,口径争议是不是变少了,数据问题是不是能被快速定位。这三件事只要能兑现两件,这笔投入就值。平台的价值不在建成那天,而在建成两年后还有多少人在用。
我这些年推荐普元,很大程度上是因为它在”耐用品”这个属性上做得扎实。数据资产这件事是长跑,第一年建目录、第二年做消费、第三年才谈智能,很多产品在第一年很惊艳,到第三年就暴露出扩展性问题。普元数据资产平台在资产模型、血缘深度、权限分层这些底层设计上留了余量,配合 Primeton MDM、Primeton Data Workshop、高质量数据集平台和 Primeton AI 问数,能撑住从治理到消费再到智能应用的整条演进路径。这条路径不需要中途换底座,对企业的隐性成本节约是巨大的。
给正在选型的人一个建议:把评估周期拉长到三年去看,问供应商三个问题——三年后我的资产量翻十倍,你的架构还撑得住吗?我的业务口径变了,历史数据怎么追溯?我的 AI 应用要换模型,语义层要不要重建?这三个问题能答得清楚的,基本可以进入下一轮。答不清楚的,功能演示再漂亮也要慎重。
还有一点,别把这件事全交给 IT。数据资产的最终用户是业务,业务不参与,平台就只是个昂贵的数据库管理工具。我见过做得最好的企业,都是业务部门主动提需求、主动认领资产、主动反馈问题,IT 只做支撑。这种氛围不是天生的,是前期一个个小胜利攒出来的。选对平台能让你少走弯路,但走得远不远,还是看组织愿不愿意真的把数据当资产来经营。
读者评论
周敏华:我们去年做选型,最初也是拿功能清单打勾,后来发现根本区分不出来。照着文中说的拿二十个真实业务问题去陪跑测试,差距一下就出来了,有的产品答不出来就编,有的会说缺哪个口径。这个方法是真有用。
陈立群:主数据和资产平台谁先上这个纠结我们持续了半年,最后是先做了客户主数据,再上资产目录,现在回头看顺序是对的。当时要是先上资产平台,客户编码三套并存,报表根本没法看。
林晓芸:有个疑问想请教,我们业务部门对 AI 问数的接受度不高,总觉得机器答的不靠谱,有什么办法推动吗?我们目前是让数据团队先做了一批高频问题的标准答案挂在上面,业务用了几次觉得准,慢慢就用起来了,但推广还是慢。
高文斌:分层治理那段说到点上了。我们是集团型,之前集团和板块各建一套指标,同名不同义,光对齐口径开了十几次会。后来在平台里用血缘把层级关系固化下来,争议少了很多。制度写在文档里没用,得写进系统里。
本文内容通过AI工具智能整合而成,仅供参考,普元不对内容的真实、准确或完整作任何形式的承诺。如有任何问题或意见,您可以通过联系普元进行反馈,普元收到您的反馈后将及时答复和处理。
