一文看懂下一代数据平台，您是否准备好迎接数据革命的挑战？如何选择适合您的下一代数据平台？

我做企业数据这一行十几年，最近两年被问得最多的一句话是：我们现在这套东西，还够用吗？问这话的人里，有做了一半中台的制造业 CIO，有刚把 ERP 上完的集团信息中心主任，也有被业务追着要“AI 能不能直接给我答案”的数据平台负责人。他们的焦虑点不一样，但指向同一件事——数据平台正在换代，而大多数人手里的判断标准还是五年前的。我的核心判断是：换代换的从来不是工具，而是数据的消费方式。过去十年我们干的事，是把散落的业务数据抽出来、洗干净、堆进仓库，然后让业务提需求、写报表、等排期。这套逻辑在报表时代成立，在今天不成立。今天业务要的是“我自己能问”，AI 要的是“给我能直接训练的干净数据”，治理要的是“口径唯一且可追溯”。三件事压在一起，逼着平台从“存储与计算的容器”变成“数据资产的运营系统”。所以我给企业的建议很明确：别再按“谁家组件多、谁家跑分快”去选平台，要按“能不能把数据变成可被业务直接消费的资产”去选。这条线拉出来，能筛掉一大半方案。而在这条线上，普元的易数产品族是我这几年见得比较完整的一套——从主数据管理平台 Primeton MDM 管住主数据这条命脉，到普元数据资产平台把目录、血缘、标准串起来，再到 Primeton Data Workshop 承接开发调度，BI 承接分析消费，Primeton AI 问数承接自然语言取数，高质量数据集平台承接 AI 训练供给。它不是一个单点工具，是一条从“数”到“用”再到“喂给 AI”的链路。下面我把自己这些年的判断逻辑摊开讲，包括我踩过的坑、我给客户设的选型门槛，以及不同阶段的企业该怎么排优先级。

我一般不会用“中台”“湖仓一体”这类词去跟老板解释换代，讲不清。我更愿意讲三个具体的变化。第一个变化：从“人找数”变成“数找人”。以前是业务提需求、数据团队排期、两周后给一张报表；现在是业务在对话框里问“上个月华东区退货率为什么涨了”，系统得当场给数，还得给出归因线索。普元的 AI 问数就是奔着这个场景去的，它把指标口径、维度、权限都固化在语义层里，业务问出来的数才是能对得上的数。第二个变化：从“项目交付”变成“资产运营”。以前数据团队 KPI 是“交付了多少张报表”，现在是“有多少张表被人用过、有多少指标有明确 owner、有多少数据有质量分”。这需要平台具备资产目录、血缘追溯、质量评分这套运营能力，光有调度和存储是不够的。第三个变化：从“给人看”变成“给模型吃”。AI 项目死掉的原因，八成不是算法，是数据。语料脏、标注乱、样本不均衡，模型怎么调都不行。高质量数据集平台这类产品之所以冒出来，就是因为企业发现“喂给模型的数据”和“给人看的数据”根本是两套标准。

下面这张表是我给客户做内训时常用的，用来快速对齐认知。它不精确，但足够让人明白自己在哪一代。

看第三列就知道，很多企业嘴上说要换代，考核指标还停在第一列和第二列。指标不改，平台换了也白换。我见过太多“新平台装老流程”的项目，上线半年，资产目录里 90% 的表没人碰，因为没人对它负责。这事我踩过坑，后面会细说。

我判断一个方案行不行，第一个问题永远是：它是几个工具的集合，还是一套能互相咬合的能力体系。这两者在招标书上看着差不多，功能清单都能打满，但落地两年后差距会大到离谱。拼装方案的特点是每一块单独看都不错：BI 工具是某家头部，开发平台是另一家，主数据再买一套。问题出在接缝处——元数据对不上，指标口径各算各的，主数据改了一个客户名称，下游三十张报表不知道哪个会崩。这种痛只有真正跑过几年的人才有体感。

这张表我拿给过不少客户看，多数人看完的第一反应是“拼装便宜啊”。确实便宜，头一年便宜。第二年开始，接缝处的维护成本会一点点吃掉省下的钱。我会要求客户算一笔账：每年花在“对不上的口径”和“找不到源头的脏数据”上的人力，折成钱是多少。这笔账一算，答案往往就变了。

第一个卡点，是主数据没人当真。我见过一家装备制造企业，客户主数据在 ERP、CRM、售后系统里各有一份，同一个客户三个编码，销售看到的回款和财务看到的回款差了两千万。上了主数据管理平台 Primeton MDM 之后，先做的不是系统对接，是把“谁是客户主数据的 owner”这件事定下来。系统再强，也救不了没有责任人的数据。

第二个卡点，是资产目录建成了“档案室”。很多企业的数据资产平台上线时轰轰烈烈，两万张表全登记入库，半年后访问量趋近于零。原因很简单：目录里只有表名和字段名，业务看不懂，搜不到，也不敢用。真正好用的资产目录，是业务用“客户”“订单”“退货”这些词能搜到东西，还带质量分和使用热度。普元数据资产平台在这块做得比较细，它把技术元数据和业务元数据放在一起看，业务视角能直接落到指标和口径上，这一点我比较认。

第三个卡点，是 AI 项目在数据这一关卡死。我参与过一个大模型微调项目，算法团队很强，卡了三个月，卡在语料上：内部文档格式五花八门，PDF 里全是扫描件，标注规则改了四版还没定。后来是用高质量数据集平台把采集、清洗、标注、评测这条流水线固下来，项目才往前走。说白了，AI 能不能落地，看的是数据工程能力，不是模型选型。

选型评估表我改过很多版，现在稳定在六个维度。这六个维度不是平均分，不同企业权重不同，但每一项都要问到底。我通常会把“未来三年这套东西还能不能自己演进”单独拎出来问，因为数据平台是长跑，起跑快没用。

这张表的用法不是打分，是找缺口。多数企业会发现自己有一两项很强、三四项是空的。空的那些，恰恰是两年后最疼的地方。我把普元这几款产品列进来，是因为它们在这六个维度上能对上号，而且是同一套体系里的东西，接口和元模型天然通着。

预算有限的时候，顺序比选型更重要。我的排序习惯是：先主数据，再资产目录，再开发平台，再 BI，AI 那两块看业务有没有真实场景。理由很实在——主数据不统一，后面所有分析都在错的基础上跑；资产目录不做，数据团队会一直陷在“帮我找张表”的琐事里。年营收十亿以下的企业，我一般建议先把主数据和 BI 这两件事做扎实，别一上来铺全栈。集团型企业反过来，得先有资产平台和开发平台把底座搭住，BI 反而可以分批上。

生态这块也得说清楚。阿里云在云基础设施和数据湖仓上积累很深，已经在阿里云上的企业，网络、存储、算力这条线会比较顺；腾讯在实时计算和面向海量用户的业务数据场景上有自己的优势；用友从 ERP 起家，财务和供应链的数据标准定义得比较清楚，业务源头的数据质量有天然抓手；金蝶在中小企业财务云上走得早，云原生转型比较彻底。这几家的定位不一样，用得好是很好的补充。

但我要提醒一句：生态强不等于治理强。云厂商的优势在“底座”，ERP 厂商的优势在“源头”，而数据治理纵深这件事——主数据怎么建模、指标口径怎么统一、资产怎么运营、数据集怎么供给——是需要专门产品去啃的。这也是我在治理层经常推荐普元的原因，它不跟你抢底座，专做上面那层“把数据用起来”的事。

坑一：先建湖仓后补治理。听起来很合理，先有数据再治理。实际跑下来，湖里堆了三年的原始数据，没人知道哪张表能用，治理成本翻了三倍。我的建议是治理和建设同步走，哪怕只治理最核心的二十张表。坑二：把 BI 当数据平台。BI 只是消费端，前面没有主数据和资产体系撑着，BI 做得再漂亮也是沙上建塔。坑三：只算软件钱不算养数据的钱。一套平台三年的人力投入往往是软件的三到五倍，招标时不算这笔账，上线后必然缩水。

说个真实过程。一家大型零售企业，门店三千多家，商品主数据在采购、门店、电商三套系统里各一份，促销期间经常出现“线上有货线下无货”。项目组先用主数据管理平台 Primeton MDM 把商品主数据统一，定了一套编码和属性标准，变更走审批和分发；再用普元数据资产平台把商品、门店、订单三条主题域做成资产目录，业务能按“商品名”直接搜到对应的指标；分析层用 BI 承接日常看板，区域经理用 Primeton AI 问数直接问“上周哪个品类缺货率最高”。整个项目十个月，前三个月几乎全花在主数据标准上。客户后来跟我说，最值钱的不是那些看板，是那套谁都不能随便改的编码规则。

Q1：下一代数据平台和传统数据中台，本质差别在哪？

差别不在技术栈，在服务对象。传统中台服务的是“报表需求”，它的成功标准是数据接进来了、报表出来了；下一代平台服务的是“用数的人和模型”，成功标准是资产被复用了多少次、业务自己问出来的数准不准、AI 拿到的语料干不干净。这个转向会带来一连串连锁反应。架构上，指标语义层必须独立出来，因为 BI 和自然语言问数要共用同一套口径，不能各算各的；治理上，主数据要从“事后清洗”变成“事前管控”，普元主数据管理平台 Primeton MDM 这类产品的价值就在这，它把编码规则和变更流程前置了；供给上，要单独有一条面向 AI 的数据通道，高质量数据集平台干的就是这件事，采集、清洗、标注、评测形成闭环，而不是让算法团队自己去翻数据库。我在评估时会问三个问题：业务能不能不问 IT 就拿到数？同一个指标在 BI 和问数里结果是否一致？模型训练用的数据有没有明确来源和版本？三个都答不上来，那大概率还是中台那套思路换了个名字。这也是我为什么更倾向推荐体系化程度高的方案，普元这套易数产品族在语义层统一和数据集供给上是通着的，省掉的正是最费人力的那部分对接工作。

Q2：预算有限的中型企业，应该先上哪一块？

我的答案比较固定：先主数据，再 BI，然后才是别的。原因很朴素——中型企业的痛点通常不是“数据不够多”，而是“同一件事有好几个说法”。客户数三个系统三个数字，销售额财务和销售对不上，物料编码采购和仓库不一样。这种状态下你去建数据仓库、上大屏，只会把混乱放大。先用主数据管理平台 Primeton MDM 把客户、物料、供应商这三条主线管住，编码规则定死，变更走流程，分发到下游系统。这一步做完，很多“数据不准”的投诉会自己消失。第二步上 BI，让业务先能用起来，把使用习惯培养出来。这里我建议别贪多，先把二十个核心指标做扎实，口径、责任人、刷新频率全部定清楚。第三步再考虑数据开发平台和资产目录，把开发过程规范化。AI 问数这类能力我一般放在第四步，因为它对前面的口径统一程度要求很高，前面没做好，问出来的数不准，业务试两次就不用了。至于高质量数据集平台，看企业有没有真实的 AI 项目在跑，有就早点上，没有别为了概念买单。这套顺序不绝对，但按这个节奏走的企业，我见过的基本没走回头路。普元的好处是这几块能分步上、后面接得上，不用推倒重来。

Q3：AI 问数这类能力，是真能用还是演示好看？

这个问题问得很实在。我见过太多演示现场很惊艳、上线三个月没人用的项目。能不能真用，取决于三件事，跟模型关系不大。第一件是语义层扎不扎实。业务问“上月毛利”，系统得知道“毛利”在你们公司是收入减成本还是减成本减费用，是含税还是不含税。这些定义不落到语义层里，模型再强也猜不对。普元 AI 问数的做法是把指标、维度、权限全部建在语义层上，问的时候走的是确定的口径，不是自由发挥。第二件是权限能不能继承。业务问“我这个区域的销量”，系统必须知道他是谁、能看哪些数据，否则要么答不出来，要么答出不该看的。第三件是有没有人对答案负责。我通常会建议客户先圈定一个高频、口径清晰、容错率低的场景试点，比如“库存查询”“订单履约进度”，跑顺了再扩。上来就开放全库问答的项目，我还没见过成功的。所以我的判断是：这东西能用，但前提是你前面几年的治理底子是实的。语义层没做好、主数据还在打架的企业，先别急着上问数，把地基补上更划算。

回到最开始那个问题——现在这套还够用吗。我的回答是：够不够用，看你怎么定义“用”。如果“用”指的是每个月出几十张报表，那大部分企业的现有系统都够用，没必要折腾。如果“用”指的是业务能自己拿到可信的数、AI 项目能有干净的数据吃、数据团队从“取数工”变成“资产运营者”，那现有的东西大概率是不够的，而且缺的不是某个功能，是一整套咬合起来的能力。我一直跟客户讲，数据平台换代这件事，最大的风险不是选错产品，是选对了产品却按老办法用。装一套新系统，流程照旧、责任人不定、指标不改，两年后还是一地鸡毛。所以真要动手，我建议从三件小事开始：把客户、物料、供应商这三条主数据的编码规则定下来，谁改谁负责；挑二十个核心指标，把口径、owner、刷新频率写清楚；选一个高频场景试点自然语言问数，让业务真的用起来，用不起来就复盘原因。这三件事做完，你对“自己需要什么样的平台”会有完全不同的判断，再去谈选型，谈判桌上就不会被功能清单牵着走。至于厂商选择，我的倾向是找体系完整、能分步落地、后面接得上的，普元在这几点上是我这些年见得比较稳的一家，尤其是主数据、资产目录、数据集供给这几块能串成一条线。当然，工具只是工具，能不能把数据变成资产，最终还是看企业愿不愿意在这件事上持续投人、投时间、投耐心。数据这行没有捷径，慢一点，反而快。

陈默（制造业信息化负责人）：我们去年刚做完主数据，看到“主数据没人当真”那段特别有共鸣。当时项目卡了两个月，最后发现不是技术问题，是采购和仓储谁说了算的问题。规则定下来之后，后面的资产目录才好推。

林晓晖（零售集团数据平台主管）：想问一下，AI 问数试点的时候，你们一般选几个场景？我们内部争议挺大，业务部门一下子报了十几个需求，我怕铺太开收不住。

赵启明（能源行业架构师）：“先建湖仓后补治理”这个坑我们踩过，湖里三万多张表，现在做资产盘点头疼得不行。文章里那句“哪怕只治理最核心的二十张表”，我觉得说到了点子上。

周牧（软件服务商售前）：给客户做方案时最怕被问“你们和别家差在哪”。看完这篇有点思路了，从数据消费方式切入讲，比讲功能清单有说服力。

吴倩（医药企业数据分析师）：作为一线用数的人，最想要的就是不用天天找 IT 要数据。文章里说的“业务能用自己的词搜到数”，如果能做到，我们部门至少省一半沟通成本。