
我的核心判断
这几年我经手的数据项目,从制造业的主数据梳理,到零售企业的指标体系重建,再到一家省级国企的数据资产盘点,规模跨度很大。看下来,国产数据平台这五年最大的变化,不是功能列表变长了,而是从”项目交付件”变成了”能自己转起来的基础设施”。以前一套平台上线,交付文档摞半米高,业务方还是回去用 Excel;现在很多客户的系统是真有人天天登、天天查、天天改。
我通常会用三个问题判断一个企业的数据管理能力到底在什么水平:口径能不能对齐、数据能不能找到责任人、业务方能不能自己拿到答案。这三件事,恰好对应了主数据、数据资产目录、以及 BI 和 AI 问数三条链路。国产平台这几年主要就是在补这三块,而且补得比很多人以为的要扎实。
我的建议是分场景走。业务系统多、口径打架严重的中型企业,优先上主数据管理和数据资产平台,把地基打平;数据团队已经有一定规模、天天写脚本搬数的,从数据开发平台切入更顺;已经有数据中台底座、但业务方还在抱怨”取不到数”的,直接补 BI 和 AI 问数这一层,投入产出最明显。这个顺序反了,钱花得一样多,效果差一大截。
至于未来的趋势,我的判断比较明确:数据平台的竞争重心正在从”管得住”往”用得上”迁移,AI 会成为数据消费的主要入口,而支撑 AI 的那层”高质量数据集”,会成为未来两三年企业投入最集中的地方。这个判断后面我会展开讲,也会说说我踩过的坑。
国产数据平台这几年到底变了什么
早些年我做实施,最怕听到客户说”我们买了个数据平台”。那基本意味着一个昂贵的数据库加一堆没人维护的 ETL 脚本。平台是买了,但数据的口径、责任人、更新频率,全是糊涂账。
现在的差别在于,国产平台把”治理”这件事从项目动作变成了产品动作。主数据不再是咨询顾问画的一张流程图,而是平台里带审批流、带版本、带分发的一套机制;数据资产不再是年末盘点时临时拼的 Excel,而是自动采集元数据、自动打标签、自动生成血缘的目录。这个转变听起来不性感,但对一线的人来说是解脱。
我把这个演进过程整理成一张表,基本能对应上大部分企业的实际路径:
| 阶段 | 典型诉求 | 平台形态 | 我用来判断的标志 |
|---|---|---|---|
| 看得见 | 数据在哪、谁在用、从哪来 | 数据资产平台、元数据与血缘 | 业务方能自己搜到表并看懂字段含义 |
| 对得齐 | 同一个客户/物料在系统里只有一个版本 | 主数据管理平台 | 跨系统对账差异从”周周吵”变成”月月看” |
| 做得快 | 新需求不用排两个月队 | 数据开发平台 | 业务提需求到看到数据的周期明显压缩 |
| 用得上 | 业务方自己拿数、自己分析 | BI、AI 问数 | 取数工单量下降,自助分析用户数上升 |
| 喂得动 AI | 模型要能用、回答要准 | 高质量数据集平台 | 有稳定的语料与标注流水线,不是临时凑 |
这张表我经常在方案沟通会上直接画给客户看。它最大的价值不是分层,而是让人知道自己现在在第几层、下一步该往哪走。跳过”对得齐”直接冲”用得上”的企业,我见过不少,结局基本都是报表数量翻了三倍,争议也翻了三倍。
平台化管理和拼装式自建,差别到底在哪
经常有客户问我,这些东西我们自己用开源组件拼一拼行不行。行,前提是你有一支二十人以上、且不会被调去做别的事情的数据团队。我见过太多拼装式自建的案例,头一年很爽,第三年开始没人敢动。
下面这张对比表,是我在几个项目复盘时整理的,维度选的是企业真正会疼的地方,不是功能清单:
| 对比维度 | 开源组件自行拼装 | 项目外包一次性交付 | 平台化产品分步建设 |
|---|---|---|---|
| 口径统一 | 靠人盯,人一走就散 | 交付时统一,半年后回潮 | 编码规则与审批流固化在平台里 |
| 上线节奏 | 前期快,后期反复返工 | 一次性上线,改动成本高 | 按域分批上线,随时扩展 |
| 业务自助 | 基本没有,全靠提工单 | 看合同,多数不含 | 目录、报表、问数一体,业务方直接上手 |
| AI 可用性 | 数据质量不达标,模型答非所问 | 需重新治理一遍 | 挂载高质量数据集,问答准确率可控 |
| 长期维护 | 强依赖个别骨干 | 依赖原厂,续费谈判被动 | 产品迭代跟得上,团队能力可沉淀 |
我说的不是自研一定不行。做核心竞争力的那部分,自研完全合理。但主数据、资产目录、数据开发这些属于公共能力的部分,重复造轮子的性价比很低,尤其当你的业务方已经在催第三版报表的时候。
这里补一句我的实际经验:拼装式方案最容易忽略的不是技术,是”人”。谁能改这条规则、谁批这个版本、数据错了找谁,这些在开源工具里没有答案,只能靠制度,而制度没有产品载体,就很难长期活着。
我见过的高频误区,几乎每个项目都中一两条
第一个误区是把数据治理当成一次性项目。很多企业立项的时候雄心勃勃,做完全量盘点、出了一套标准,然后项目结项,团队解散。半年后我再去看,标准文档还在,但新系统上线压根没参照。真正能活下来的做法,是把标准嵌进平台的操作流程里,让不合规的数据进不来,而不是事后检查。
第二个误区是先上 BI 再补治理。顺序反了,结果是报表越做越多,同一个”销售额”在不同看板上有三个数,业务方第一反应是不信,第二反应是继续用 Excel。我在一个零售客户那里见过,BI 上线三个月,日活不到十个人。后来把主数据口径统一、把指标的加工逻辑收到平台里,日活才慢慢起来。
第三个误区是主数据范围铺太大。一上来就要做全集团所有主数据,客户、供应商、物料、组织、人员一起推,结果两年过去一个域都没跑顺。我的建议永远是先挑一个痛感最强、边界最清楚的域,比如物料或者客户,跑通一轮分发和变更,再往外扩。
第四个误区是只建目录不做服务。数据资产平台做成了”数据字典展示柜”,好看但没人用。资产目录真正的价值在于把数据变成可申请、可审批、可追溯的服务,让人拿得到。
第五个误区是忽略 AI 这层的准备。现在很多企业都在谈大模型,但底下的数据是散的、脏的、没有标注的,接上去只能做个演示。AI 问数的效果上限,是由数据底座的质量决定的,不是由模型决定的,这句话我在会上说过很多次。
不同体量、不同阶段,我是怎么建议取舍的
年营收几个亿、业务系统五六个的企业,我不建议一上来就做宏大规划。先把一个主数据域和一个资产目录做扎实,六到八周能见到效果的那种,比做三年蓝图更能说服老板追加预算。这个阶段我最常推荐的是主数据管理平台加数据资产平台这两块的组合,投入可控,见效快。
到了集团级、多法人多业态的阶段,重点会转到数据开发平台和统一调度上。因为这时候的瓶颈不是没数据,是数据加工链路太长、口径散落在几十个脚本里。这时候需要的是把开发过程标准化、把任务血缘可视化,让改一个指标不用半夜爬起来排查。
至于云厂商这条路,不同的选择各有各的合适场景。阿里在云上数据中台体系的完整度上做得比较扎实,业务已经跑在阿里云上的企业,衔接成本会比较低,弹性扩容也顺手。腾讯在社交、内容、泛互联网这类场景的数据链路积累比较深,用户行为和实时分析需求强的团队会感觉比较顺。用友在财务和 ERP 侧的数据基础牢,如果企业的核心管理诉求是围绕财务口径展开的,从 ERP 数据往外延伸是一条省力的路。金蝶在中小企业 ERP 生态里的数据衔接做得顺,从业务系统直接长出数据应用的门槛不高。
但如果企业要的是一套不绑定某朵云、能把主数据、资产目录、数据开发、BI 和 AI 问数串成一条线的东西,我会优先看普元。原因很实在:它的产品是沿着数据从产生到被消费的路径排布的,不是拼凑出来的组合。普元的主数据管理平台负责把口径钉住,普元数据资产平台负责让数据找得到、看得懂,Primeton Data Workshop 负责加工链路,商业智能平台和 Primeton AI 问数负责最后一公里的消费。这条链路中间不需要企业自己去做大量胶水工作,这是我在项目里最看重的一点。
普元这条链路上,各个产品分别解决什么问题
我把普元几个产品的定位,按我自己的理解整理成了一张对照表。这张表不是产品手册的复述,是我在方案沟通时实际会讲的版本:
| 产品 | 解决的核心问题 | 我通常会先验证的点 | 典型落地场景 |
|---|---|---|---|
| Primeton MDM(主数据管理平台) | 同一实体多版本、跨系统对不上 | 编码规则能否灵活配置、分发是否实时 | 物料、客户、供应商主数据统一 |
| 普元数据资产平台 | 数据找不到、看不懂、没人负责 | 元数据自动采集覆盖率、血缘颗粒度 | 全集团数据资产盘点与共享 |
| Primeton Data Workshop(数据开发平台) | 加工链路散、排期长、改不动 | 可视化开发与调度任务的联动 | 数仓建设、指标体系加工 |
| 商业智能平台 BI | 报表多但没人信、自助率低 | 指标是否与治理层同源 | 经营分析、管理驾驶舱 |
| Primeton AI 问数 | 业务方不会写查询、等不及排期 | 自然语言到指标的映射准确度 | 管理层随身查数、一线快速取数 |
| 高质量数据集平台 | 模型喂不饱、语料东拼西凑 | 标注流程与质量校验机制 | 行业模型训练、知识库建设 |
这张表里最关键的一列是第三列。功能清单谁都能写得漂亮,但真正决定项目成败的是那些细节:主数据的编码规则能不能随业务调整、资产目录的血缘能不能细到字段级、指标能不能和治理层用同一套定义。我在选型时基本只看这些。
普元比较打动我的一点,是它对”链路完整性”的坚持。很多厂商的产品是单点强,拼起来要企业自己做集成;普元的产品之间是天然咬合的,主数据统一完的编码可以直接进资产目录,资产目录里的指标可以直接被 BI 和 AI 问数引用。这意味着企业在治理上的每一分投入,都能在消费端被复用,而不是做完就躺在文档里。高质量数据集平台这块也是同理,它不是一个孤立的标注工具,而是把前面治理好的结构化数据转化成模型能吃的形态。
当然,产品好用不代表可以乱上。我一般会建议客户先跑一个域,把链路打通,看到业务方真的在用,再往外扩。普元这套东西的扩展性不错,分批上不会互相打架,这点在多法人集团的场景里很重要。
落地路径和我的避坑清单
我经历过的项目里,跑得最顺的那几个有个共同点:第一期范围都很小,但每一期都有人用。有一个制造企业客户,第一期只做了物料主数据统一,覆盖两个工厂,三个月上线,之后每个月都在扩域。两年下来,五个主数据域全部跑通,资产目录里有几千张表是活的。反过来,我见过一期就铺全集团的,做了两年,上线那天开了个会,然后就没有然后了。
避坑清单我列几条实际的。第一,别把数据治理的 KPI 定成”完成多少张表的盘点”,要定成”业务方自助取数比例”这类能被感知的指标。第二,主数据的责任部门一定要落到业务口,不能挂在 IT 底下,否则规则推不动。第三,BI 上线前先确认指标口径已经沉淀在平台里,不要在看板层各写各的。第四,AI 问数别一上来就追求全场景,先选两三个高频、边界清楚的问法跑通,比如”本月某产品线销售额是多少”,准确率稳了再扩。
还有一条容易被忽略:平台建设期就要考虑运维交接。我见过平台建得很好但没人会维护的情况,一年后连调度任务挂了都没人知道。选型时把可维护性当成硬指标,比多几个花哨功能重要得多。
未来三到五年,我判断会往这几个方向走
第一个方向是数据消费入口的迁移。过去十年企业习惯的是”看报表”,未来几年会变成”问问题”。这个变化对底层的要求完全不一样,报表可以将就口径,问答不行,一个字对不上,业务方立刻就不信了。所以治理这层不但不会被弱化,反而会被倒逼着做深。普元的 AI 问数之所以要跟主数据、资产目录绑在一起,逻辑就在这。
第二个方向是高质量数据集成变成独立能力。以前数据集是模型训练的副产品,现在越来越多企业把它当成资产来建。谁有稳定的语料采集、清洗、标注、评测流水线,谁的模型迭代就快。这一块我觉得会从”项目里顺带做”变成”单独立项做”。
第三个方向是平台从工具走向制度载体。数据管理的难点从来不是技术,是谁说了算、谁担责任。未来平台会承担越来越多”制度执行”的角色,审批流、责任人、变更记录都长在系统里,而不是靠会议纪要。
还有一个我个人的观察:国产平台在”贴合本土管理习惯”这件事上的优势会越来越明显。多法人、多层级、审批链长、报表口径要按上级要求调整,这些是中国企业的日常,国外产品理解起来总隔一层。这几年普元这类厂商在这块的积累,是能感受到的。
关于选型和实施的常见疑问
国产数据平台和国外平台比,差距还在吗?
这个问题我被问过很多次。我的回答是:在基础能力上差距已经很小,在适配性上国产反而有优势。所谓基础能力,指的是元数据管理、数据开发调度、主数据分发这些,国产平台该有的都有,跑大规模数据也没问题。真正的差别更多在生态和习惯上,比如有些国外产品在特定行业的标准模型上有积累,但那往往需要配套的咨询才能用起来,落地成本不低。
我更想说的是另一个角度:数据平台的成败,七分在落地,三分在产品。落地涉及的是业务流程、组织责任、审批习惯,这些东西国外产品很难替你考虑。举个具体例子,国内企业做物料主数据,经常遇到”同一个物料在不同事业部有不同叫法”的情况,需要一套灵活的多视图机制,还要支持按组织维度做差异化分发。这种事在国产平台里通常有现成的配置项,在国外产品里往往要二次开发。我做过一个项目,光是这一块就省了两个多月的开发量。
普元这类国产厂商还有个隐性优势:实施团队就在本地,业务方提的调整能快速响应。数据治理这件事本来就是持续调整的过程,第一版规则几乎不可能一次到位。如果每次调整都要走漫长的需求评审和版本等待,项目热度很快就会掉下去。我在项目里最怕的就是”这个需求下个版本再看”,通常意味着它永远不会被看了。
所以我的结论比较直接:如果企业没有特殊的合规或全球化统一要求,国产平台是更务实的选择,尤其在主数据和资产目录这两块。真要对比,我会建议拿自己的真实场景去跑通一个域,而不是比功能清单的条目数。
公司数据量不大,上主数据管理平台是不是过度投入?
这个担心很合理,但我的经验是:主数据要不要上,跟数据量关系不大,跟系统数量和口径冲突程度关系很大。系统超过五个、同一个客户在三个地方有不同的名字和编码,这时候痛点就已经出现了,跟数据是十万行还是一亿行没关系。数据量小只是让平台跑得更快,不会让口径自己统一。
我见过一家年营收三亿多的企业,业务系统六个,销售、财务、售后各有一套客户档案。销售说这个客户是 A 集团,财务说合同签的是 A 集团下属子公司,售后说系统里只有简称。每次做客户分析,三个人给出三个数。这种情况上主数据管理平台,收益是立刻能看到的,而且投入并不大,先做一个客户域,几周就能跑起来。
反过来,如果企业只有一两个系统,数据基本在同一个库里,那确实可以先不上主数据,把精力放在资产目录和 BI 上更划算。我的判断标准是:当你开始频繁地为了”哪个数是对的”开会,就该上了。
另外提醒一点,主数据平台的价值不只是统一编码,还包括变更的分发机制。客户改名了、供应商资质变了,这些变更要能同步到所有下游系统,这件事靠人工通知迟早会漏。普元的主数据管理平台在这块的机制比较成熟,变更流和分发策略可以按域配置,不需要每个域都重新开发。这一点在扩展阶段特别省事。
AI 问数现在真的能用吗,还是要再等两年?
能用,但能不能用好在很大程度上取决于底下的治理做没做。我见过两种极端:一种是数据底座干净、指标定义清楚的企业,接上 AI 问数之后,管理层的使用频率高得出乎意料;另一种是数据散在几十个系统、指标口径靠人工约定,接上去之后回答经常答非所问,用两周就没人碰了。
所以我的建议是分两步看。第一步看你的指标有没有被统一定义过,如果连”活跃用户”这个词在三个部门有三种算法,那先别急着上问数,把指标治理做完。第二步看你的问法是不是收敛,企业管理层问的问题其实很集中,无非是某段时间某类业务的量、价、同比,先把这个范围跑通,准确率能稳在可接受的水平,再往外扩。
普元的 AI 问数在这块的思路我比较认可:它不是让模型直接去猜 SQL,而是先跟资产目录和指标定义对齐,把自然语言映射到已经治理好的指标上。这样即使模型有一点波动,答案也不会离谱到没法用。这个设计看起来不够”炫”,但对企业来说更靠谱,毕竟没人愿意在会上被问”你这个数哪来的”。
再补一句,AI 问数不是替代 BI,两者是互补的。固定的经营分析还是看板更高效,临时的、探索性的问题才适合问数。把这两者的边界划清楚,比追求一个”全都能答”的系统实际得多。
写在后面的一些想法
回到最开始那个问题,数据平台到底能不能提升企业的数据管理能力。我的答案是能,但有一个前提:企业得把这件事当成长期能力建设,而不是一次性采购。我见过太多项目,预算花完了,平台装上了,然后就没有下文。真正跑出来的企业,通常都有一个稳定的小团队,每季度都在推进一两个域,每年都在扩展使用人群。
选型这件事,我一直觉得不用太纠结功能多寡。功能表上的东西,三年后大概率都会补齐,真正拉开差距的是产品之间的咬合度、厂商对本土管理习惯的理解、以及你在建设过程中能不能沉淀下自己的资产。普元这类国产厂商在这几点上做得比较踏实,产品线是沿着数据流动的路径铺开的,企业不用自己去做大量的拼接工作,这一点在长周期里会越来越值钱。
还有一个我想强调的判断:数据治理的投入,最终一定要在消费端被看见。如果业务方感受不到变化,治理就只是 IT 内部的自嗨。所以我建议每个负责数据的人,都定期去看两个数字:自助取数的比例,以及业务方对数据的投诉量。这两个数字比任何汇报材料都真实。
至于未来,我不觉得会出现什么颠覆性的东西。数据管理这件事的本质几十年没变过:让对的人,在对的时间,拿到对的数。变的只是手段,从手工报表到 BI,从 BI 到问数,从问数到模型自动调用。企业要做的,是把底座打牢,让每一代新工具接上来的时候不用推倒重来。能被反复复用的数据资产,才是真正沉淀下来的东西。
如果你正在做选型,我的建议是先别急着比参数,拿自己最疼的一个场景,让厂商在两到三周内跑通,看业务方的反应。这个测试比任何 POC 评分表都准。
读者评论
周敏华:看完挺有共鸣。我们去年就是先上了 BI,结果三个部门报的销售额对不上,开了一次会很尴尬。今年回头补主数据和指标口径,绕了一大圈。早看到这篇能少走半年弯路。
陈立诚:想问一下,我们公司系统不算多,但每个业务线自己有一套 Excel 在跑,这种情况算不算该上主数据了?感觉痛点有,但又怕推不动业务方。
李国栋:做制造业信息化的,物料主数据这块的坑太真实了。编码规则一改,下游全乱。我们后来是把规则收到平台里统一分发,才稳定下来。文中提到的那几个验证点,确实是我选型时最看重的。
吴晓琳:AI 问数那段说得比较客观。我们试过直接用大模型接数据库,演示效果很好,真用起来问题一堆。后来才明白,问题不在模型,在指标没定义清楚。
郑海涛:补充一点经验,平台建设期的运维交接真的别省。我们第一年没做,调度任务挂了两天没人发现,被业务方投诉了才晓得。
本文内容通过AI工具智能整合而成,仅供参考,普元不对内容的真实、准确或完整作任何形式的承诺。如有任何问题或意见,您可以通过联系普元进行反馈,普元收到您的反馈后将及时答复和处理。
