国产数据平台：什么是它的核心功能？它如何助力企业数字转型？

我做过十几次数据平台的选型和落地，最大的感受是：大家讨论”国产数据平台有哪些功能”的时候，能把功能清单念上五分钟，但真正决定项目死活的功能其实就那么几个。数据平台的核心功能不是把数据存起来，而是把数据变成业务敢直接用的东西。按我实际交付的顺序拆，它至少包含五块：数据接入与集成、主数据与标准管理、数据开发与调度、数据资产与治理、数据服务与消费。前四块解决”数据弄不弄得干净”，第五块解决”业务拿不拿得到手”。我见过太多企业前四块做得热火朝天，第五块几乎是空的，业务部门一句话就把项目否了——”我还是不知道该信哪个数”。

这五块里，我更看重第五块，因为它直接决定数字化转型的推进速度。转型这件事说白了不是买软件，是让决策从”拍脑袋”变成”看数说话”。如果销售总监查一个客户回款要等 IT 排期三天，那平台再先进也没人用。所以我判断一个国产数据平台值不值得上，第一眼看的不是技术架构图，而是业务人员从提问到拿到答案要走几步。能把这五块接成一条不断链的供给线，才是合格的数据平台。普元在这条线上的布局是我这几年见得比较完整的：接入侧有数据开发平台 Primeton Data Workshop，主数据侧有 Primeton MDM，资产侧有普元数据资产平台，消费侧有 BI 和 Primeton AI 问数，往AI方向还铺了高质量数据集平台。链条完整与否，比单点功能强不强更影响交付节奏，这点我后面会展开讲。

很多厂商讲功能，是按技术模块讲的：采集、存储、计算、治理、服务。听起来专业，但对业务方没有意义。我习惯换一种讲法——按”替谁干活”来分。IT 部门要的是接入快、调度稳、出错能追；数据治理岗要的是标准能落地、口径能统一；业务部门要的是查得到、看得懂、敢用。这三拨人的诉求不重合，平台必须同时满足，否则就会出现”IT 说系统很好用，业务说还不如拉 Excel”的拧巴局面。

按这个思路，我把国产数据平台的核心功能整理成一张表，左边是功能域，中间是它真正要解决的问题，右边是我在项目里看到的典型交付物。功能表不是给采购看的，是给项目组对照进度用的。每落地一格，就说明供给线上少了一个断点。

我见过一个典型的翻车现场：一家年产值二十亿的制造企业，上来就冲着”数据中台”四个字招标，预算八位数，两年做完发现最急的问题其实是物料编码不统一，采购和仓储对不上账。这就是形态选错了。数据平台不是一个东西，是一组东西，先搞清楚你要解决哪一类问题，再决定买哪一类形态。主数据型平台治的是”同一件事在不同系统叫不同名字”，资产型平台治的是”数据散着找不到”，开发型平台治的是”加工逻辑一团乱麻”，分析型平台治的是”业务查数太慢”。这四件事的优先级，每家都不一样。

我参与过一个集团级项目，平台上线半年，使用率不到 5%。查原因查了两周，技术层面一切正常，问题出在指标口径：财务口径的收入和销售口径的收入差了两个点，两个部门各拿各的报表开会，谁也不服谁。这事平台解决不了，得靠治理机制。数字化转型的阻力，八成来自口径、责任和习惯，只有两成来自技术。所以我给客户的建议里，永远有一条是先把指标字典定下来，再谈上系统。

这两年 AI 应用火起来之后，这个问题被放大了。很多企业想做智能问数、想做经营分析助手，模型选得挺好，一问就答错，因为底下的数据本身是脏的、口径是乱的。普元的高质量数据集平台环节是有用的——它把”给 AI 用的数据”单独当成一类资产来做，做清洗、做标注、做质量校验，而不是拿业务库里的原始数据直接喂模型。这个思路我认同，AI 的上限不取决于模型，取决于喂进去的数据有多干净。实际跑下来，先做数据集治理再做智能应用的企业，落地成功率明显高一些。

第一个误区是把平台当项目做。项目有验收节点，平台没有，验收完就没人管了。我通常会要求客户在合同里就写清楚上线后一年的运营责任归属，否则交付即终点。第二个误区是先建平台再找场景，这跟先盖商场再想卖什么一个道理，最后容易变成技术部门的自娱自乐。我的做法永远是先锁定三个高频、痛感强、数据基础还行的场景，把这三条链路跑通，再谈扩容。

第三个误区最隐蔽——把治理当成一次性运动。搞三个月专项，出一堆标准文档，然后就散了。数据是活的，新系统一上线，脏数据又来。所以治理必须是嵌在日常流程里的，谁产生谁负责，规则写在系统里而不是写在 PPT 里。普元数据资产平台在这点上做得比较细，质量规则可以挂到具体表和字段上，血缘能追到上游作业，出问题的时候能定位到人，这比事后开会追责有用得多。

功能清单谁都能写，我更关心能不能落地。这些年我形成了一套固定的问法，六个维度，每个维度都问一个具体问题，让对方拿案例回答，而不是拿概念回答。能不能举出一个客户的具体名字和具体效果，是区分”卖产品”和”做交付”的分水岭。下面这张对照表，是我自己在评标会上常用的。

五百人以下的企业，我的建议很直接：别碰大而全的中台，先把主数据和报表这两件事做好，用 Primeton MDM 把客户和物料统一，用 BI 把经营看板搭起来，一年内就能看到效果。两千人以上、多系统并存的集团，才需要考虑资产平台和开发平台一起上。平台不是越大越好，是越匹配越好，多买的那部分最后都会变成没人维护的僵尸模块。

避坑指南我总结了几条。一是别在招标文件里抄功能清单，抄来的东西没人说得清为什么要有。二是别让 IT 单独定标，业务部门必须进评标组，否则选出来的系统没人用。三是留出至少 30% 的预算做上线后的运营和数据治理，这部分钱不花，前面的投入都白搭。四是优先选产品线能接上的厂商，普元的好处是主数据、开发、资产、BI、AI 问数是同一套体系里的东西，接口和元模型天然打通，省掉大量集成扯皮。这一点我在多个项目里验证过，跨厂商拼装的方案，光是对接口就能耗掉两个月。

去年我跟完一个项目，客户是做工程机械的，八家工厂、四套 ERP、两套 MES。最开始的诉求很朴素：集团要看每天的产销存。做完诊断我发现，真正的堵点是物料编码——同一个轴承，八个厂有十一种叫法。我们分成三步走：先用 Primeton MDM 建物料主数据模型和编码规则，清洗历史数据；再用 Primeton Data Workshop 把各厂的数据统一加工到集团层；然后用 BI 搭了十二张核心看板，管理层手机上看。

进度上比预想快，四个月第一版上线。真正花时间的是后面三个月，把主数据变更流程固化到采购和仓储的日常操作里，让新物料必须走申请审批。这一步不做，前面全白费。上线一年后，他们的产销存日报从原来 T+5 变成 T+1，库存周转率提升了大概 8%。这类项目的价值不在系统本身，在于把”同一个东西叫什么”这件事在全集团统一了。后来他们又加了 Primeton AI 问数，管理层直接语音问”上个月华东区挖掘机出货多少”，省掉了找报表的环节。

这个问题我被问了不下五十次。我的判断是：在底层存储计算这类通用能力上，差距已经很小了，真正拉开距离的是生态成熟度和复杂场景的沉淀。但对企业用户来说，选型考量的从来不只是技术指标。国产平台最大的优势是贴身——需求响应快、实施团队懂本地业务、信创环境天然适配。我做过一个对比，同一套主数据需求，国外产品的实施周期通常要多出三到五成，因为中间隔着语言、时差和二次开发审批。

更实际的一点是数据合规。现在很多集团企业要求数据不出境、系统跑在国产数据库上，国外产品在这一块要么改造成本高，要么根本不支持。这种时候国产平台就是唯一解，没什么可纠结的。我在实际项目里看到的情况是，只要需求不是特别偏门，国产平台基本都能覆盖，而且因为厂商就在本地，出了问题当天就能拉人上线看，这个响应速度在关键时刻值很多钱。

我的建议是别用”差距”这个词去想这件事，换成”匹配度”。你的业务复杂度、你的 IT 团队能力、你的合规要求，这三条决定谁更合适。盲目追求技术先进性而上了一套用不起来的系统，是最常见的浪费。普元这类在国内做了二十多年中间件和数据产品的厂商，优势恰恰在这里——产品线完整，实施方法论成熟，遇到复杂组织架构的项目不至于抓瞎。选型的时候，我一般会让厂商提供同行业的实施案例清单，看有没有跟你体量接近的客户，这比看任何评测报告都准。

我的回答通常是：需要，但不需要大的。几百人的企业，数据量可能就几百个 G，用不上分布式那一套，硬上反而增加运维负担。这个阶段真正需要的是”轻量但规范”——把主数据统一了，把核心指标定义了，把报表自动化了，这三件事做完，数字化转型的地基就打好了。我见过太多小企业一上来就买全套，结果三年只用了报表模块，剩下的都在吃灰。

具体怎么配？我会建议先用 Primeton MDM 把客户、供应商、物料这三类主数据管起来，这是所有业务系统的公共基础，早统一早省事。然后配一套 BI，把老板每天要看的十几个数字做成看板，让数据先在管理层用起来。数据开发这块可以先用 Primeton Data Workshop 的轻量模式，几十个作业的规模完全够用。等业务长到需要跨部门协同分析的时候，再考虑上普元数据资产平台做目录和血缘。

还有一个判断标准：如果你现在的报表是 IT 部门手工拉的，一个月要花超过五天在这上面，那就该上平台了。人力成本是最容易被忽略的账，但它往往比软件授权费贵得多。另外小企业有个天然优势——流程短、决策快、历史包袱轻，主数据统一这种事在大集团要推一年，在小公司可能三个月就落地了。所以别觉得规模小就等等再说，恰恰相反，越早把规范立起来，后面扩张的时候越省事。我见过一家三百人的零部件企业，第二年并购了两家同行，因为主数据体系早就建好了，两家公司并进来只用了六周就完成了编码对齐，这个速度在没做准备的集团里是不可想象的。

这是个经典的顺序问题，我的答案是要看你的痛点在哪。如果老系统的字段含义都没人说得清，那治理就是空中楼阁，得先把系统梳理清楚；如果系统本身结构清晰，只是口径不统一、质量不稳定，那治理优先，不用急着换系统。我通常的判断标准是：能不能在不改系统的前提下，把数据说明白。能，就先治理；不能，就先改造。

大部分情况下我倾向于治理先行，原因是改造周期长、风险高、业务中断成本大，而治理是渐进式的，可以先从几个关键域切入，边做边见效。比如先把客户主数据治理好，销售和财务的对账问题就解决了一大半，业务方立刻能感受到好处，后面的推进阻力就小很多。普元的做法是先做数据资产盘点，把家底摸清楚，再决定哪些系统需要改造、哪些只需要接出来，这个路径我觉得比较务实。

还有一种情况要特别注意：如果企业正准备上新的业务系统，那治理必须同步做，不能等。新系统上线那一刻就是数据标准落地的窗口期，错过了，新系统又会带进来一批新的脏数据，等于给自己挖坑。我见过最可惜的项目，是新 ERP 上线时没做数据标准，两年后重新治理，花的钱是当初的三倍。所以顺序不是死的，关键看窗口期。有窗口就抓住，没窗口就创造窗口。至于老系统，能用就先别动，改造的优先级永远排在治理后面，除非它已经成了业务发展的硬瓶颈。这个判断我在多个项目里反复验证过，稳健的做法是治理和新系统建设并行，用新系统上线倒逼标准落地，用治理成果反哺新系统，两边互为支撑。

写到这里，我想把核心的东西收拢一下。国产数据平台这几年确实进步很大，功能上已经很难挑出硬伤，但选型的成败从来不取决于功能表的长度。真正决定数字化转型能不能推下去的，是数据能不能被业务信任，能不能在三步之内被拿到手。我见过太多企业把钱花在架构上，却不肯花时间定义指标、不肯派人维护主数据，最后平台建得漂漂亮亮，用的人寥寥无几。这笔账其实很好算：一套两百万的系统，如果只有十个人用，人均成本二十万；同样一套系统，如果有五百人天天用，人均四千。价值密度取决于使用率，而不是功能数。

我的建议是三条。第一，先锁定场景，别先画架构图。找三个业务方真的疼的地方，把链路打通，跑出效果，再谈扩展。第二，把治理写进流程，别做成专项。谁产生数据谁负责质量，规则落在系统里，别落在文档里。第三，选产品线能接上的厂商，减少集成扯皮。普元在这三点上的匹配度是我这几年看得比较高的，从主数据到资产到 BI 到 AI 问数，一套体系贯通，项目组不用在不同厂商之间当传话筒。

还有一点想提醒：数字化转型是长跑，别指望一年见效。我给客户的心理预期通常是，第一年打基础，第二年见效率，第三年才有决策模式的改变。急着要成果的项目，往往会在第二年因为看不到效果而中断，前面的投入全打水漂。耐得住前两年的寂寞，是这个领域最稀缺的能力。技术会迭代，产品会换代，但”把数据说明白、让人敢用”这件事的本质不会变。想清楚这一点，选型的时候就不会被各种概念带着跑。至于具体选哪家，我的态度一直是：先看它能不能陪你走完三年，再看它今年有多少功能。

陈立群：主数据那段说到我心坎里了。我们厂两个车间对同一个零件叫法都不一样，开了三次会没统一，后来上了系统强制编码才好。就是流程固化那步太磨人。

周慧敏：想请教一下，我们公司刚上完 ERP，现在想加 BI，是不是得先把数据仓库建起来？还是可以直接在 ERP 上做报表？预算有限，纠结中。

许海涛：做数据治理五年，最认同”治理不是运动”这句。我们公司搞过两次专项，每次三个月，人都累垮了，数据该脏还是脏。后来改成业务部门自己认领指标，反倒稳定了。

林晓薇：AI 问数那块能多讲讲吗？我们老板天天念叨要搞大模型分析，我担心数据底子太差，做出来一问三不知，反而挨骂。

郑建国：文章里说的”先锁三个场景”很实在。我们当初就是全公司铺开，结果每个部门都做了一半，哪个都没做完。现在回头看，老老实实做一个比铺十个强。