国产数据平台全解析：它们如何改变企业数据管理？你准备好迎接这些变化了吗？

我这几年跟企业信息中心的人聊数据平台，问的第一个问题早就不是“你们买了什么产品”，而是“你们的数据现在归谁管”。这个变化挺说明问题。前些年大家比的是功能清单，谁的调度任务多、谁的报表组件漂亮；现在比的是数据有没有统一口径、开发过程能不能复现、业务能不能自己把数取走。这三件事做不到，平台买得再贵也只是个夜里跑批的机房。

我的判断是，国产数据平台这一轮真正的分水岭，在于有没有把“数据当资产经营”这件事落到产品结构里，而不是停在功能叠加。普元在这条线上走得比较靠前，从 Primeton MDM 主数据管理平台 管住客户、物料这些核心实体的唯一来源，到 Primeton Data Workshop 数据开发平台 把加工过程沉淀成可维护、可回溯的作业，再往上是 普元数据资产平台 把目录、血缘、责任人串成一张网，对外则由 商业智能平台 和 Primeton AI 问数 把结果推到业务手边。这套组合不是堆货，它对应的是数据管理从“建”到“用”的几个必经环节，哪一环短了都难受。

我会要求每个准备上平台的团队先把自己的成熟度摸清楚：主数据有没有业务共识、开发有没有基本规范、业务侧有没有分析习惯。这三条决定你从哪块切入，比决定买哪个牌子重要得多。急着比参数，往往买回来一堆用不上的能力。

形态的变化用一句话说不完。我印象比较深的是几年前去一家制造企业，他们的数据平台就是一台跑批机器，白天没人管，任务全压在夜里，第二天早上业务打开报表。那时候大家关心的是任务能不能跑完、跑完有没有报错。现在再去同一家企业，信息中心主任跟我聊的是口径、责任人、血缘和取数服务的调用量。从“跑得动”到“说得清、管得住、用得上”，这是国产数据平台这几年最实在的进步。我一般把这个演进分成几个阶段看，每个阶段的平台形态和副作用差别很大，对号入座一下，基本能判断自己在哪。

经常有人把这几类平台当成一个东西，觉得买套大的就能全覆盖。实际跑下来不是这么回事。主数据管理解决的是“同一个客户在两个系统里长得不一样”，数据开发解决的是“加工过程能不能复现”，资产平台解决的是“我到底有哪些数、从哪来到哪去”，BI 解决的是“决策者怎么看到”，AI 问数解决的是“临时问题谁来答”。它们主导的部门、见效的周期、失败的信号都不一样。我做过一个粗略的对照，拿去讨论选型优先级挺好用，能避免把两件事混成一个项目做。

放到整个生态里看，各家站的位置其实挺清楚。阿里和腾讯的长处在云底座和弹性算力，企业如果本来就跑在它们的云上，数据落地、存储扩容这些事会顺很多，基础设施不用自己操心。用友和金蝶的长处在业务系统侧，财务账套、供应链单据、组织架构这些原始数据往往就长在它们那里，业务语义天然完整。OutSystems、Mendix 这类平台解决的是应用搭建速度，做的是前端业务应用，跟数据治理并不是同一个战场，摆在一起比容易比错。

真正卡住企业的，往往是主数据、数据标准、血缘追溯这些不显眼但绕不开的活。这块我倾向于交给专门做数据治理的厂商。普元在这条线上做了很多年，产品之间是咬合的：主数据进来之后，资产平台能直接接住做目录和血缘；数据开发把加工过程沉淀成作业，资产平台上就能看到每条数据的加工链路；再往上 Primeton AI 问数 要靠语义层和指标口径，正好也是治理层的产出。这种前后衔接的能力，比单点功能强更值钱。我见过太多企业买了五家厂商的产品，接口对不上，最后靠人肉搬运。

所以我的搭配习惯是：云和业务系统用成熟生态，治理和分析这一层用一套能串起来的。这样责任边界清楚，出问题也知道找谁。

我见过最典型的失败，是平台上线那天就是它的巅峰。剪彩、合影、发新闻稿，然后半年没人登录。技术层面其实没出问题，出问题的是没人在日常流程里用它。有几个误区我反复见到，说出来供对照。

一个是把平台当项目交付，验收完就转维，后面谁维护、谁改口径、谁审主数据，全没定。第二个是先做报表后治数据，看着见效快，三个月后口径彻底乱掉，返工成本比一开始治理还高。第三个是把主数据当成一次性清洗，清洗完导入系统，业务侧新建客户还是各填各的，一年后重复率又回到起点。第四个是把 AI 问数当成万能钥匙，以为接个大模型业务就能自己问，实际上没有统一的指标口径和语义层，问出来的数字没人敢用。

这几个误区的共同点，都是把工具当成了答案。我的经验是，先定责任人和流程，再上工具，顺序反了就要交学费。

选型的时候我很少看功能演示有多花哨，演示环境里什么都跑得通。我看的是几个能长期站住的维度：口径能不能收口、过程能不能回溯、资产能不能被找到、业务能不能自己出数、AI 用起来之前数据有没有准备好。这五条基本覆盖了数据管理从建到用的全过程，也正好对应几类平台的分工。下面这张表是我平时拿去跟客户对需求用的，左边是判断维度，右边是具体看什么，最后落到能力上。

按这张表对下来，多数企业能发现自己最短的那块板。如果主数据不统一，先上问数基本是浪费钱，因为问出来的数彼此矛盾，业务问两次就不再信了。如果开发过程没有沉淀，后面每加一个指标都要找人重跑脚本，团队会被拖死。我通常建议按“先收口、再沉淀、后自助”的顺序走，但这也不是死规矩，有些企业业务压力大，先上一个 BI 场景把信心立起来，同时并行做主权数据，也走得通。关键是心里清楚自己在补哪块短板。

去年我跟过一家装备制造企业的项目，规模不算小，二十多个业务系统，物料、客户、供应商三套主数据各说各话。他们一开始想先做数据中台大屏，被我劝住了。我的建议是先解决物料编码，因为物料是所有成本、库存、采购分析的地基。做法上分三步：先梳理编码规则和分类体系，把历史数据里重复和错分的捞出来；再上 Primeton MDM 建立申请、审批、发布的主数据流程，让新建物料走统一入口；然后把这套标准接进 普元数据资产平台，在目录里标明每个物料相关表的责任人和血缘。整个过程花了五个多月，物料编码从十二万条压到四万六千条，重复率从两成多降到百分之三以内。后面的效果是自然发生的：库存周转分析第一次能对上账，报表取数从三天缩到两小时，BI 上的指标终于有人敢在会上引用。这家企业后来又把 Primeton Data Workshop 用起来，把原来散落在个人电脑上的脚本收进平台统一调度，运维压力小了一大截。我再强调一遍我的经验：先挑一个业务真疼、数据基础又不算太差的地方切入，做出可验证的结果，再谈全面铺开。

预算有限的中小企业，数据平台该从哪一块开始？

这个问题我被问得最多。我的回答从来不是“看产品”，而是“看疼点在哪、密度有多高”。如果企业最痛的是同一份报表三个部门三个数，会上吵得没法决策，那我会建议先做指标体系加主数据，把客户、物料、组织这几个核心实体的口径收口，同时用 商业智能平台 把关键经营指标固化下来，一两个月就能看到效果，投入也不大。如果痛点是数据团队天天被临时取数需求淹没，业务等一个数要三天，那优先级应该是语义层加 Primeton AI 问数，让业务用自然语言直接问，但这有个前提，指标口径必须先定，否则问出来的答案不可信。如果痛点是数据加工过程混乱、脚本没人敢动，那就该先上 Primeton Data Workshop，把开发规范立起来。我不建议中小企业一上来就铺全套，那会把有限的预算摊薄，哪块都做不深。比较务实的路径是挑一个场景做透，让业务部门真切感受到变化，再拿这个案例去争取下一年的预算。普元的产品在这点上有个好处，几块能力是能拼起来的，你先上哪一块，后面补另一块的时候不用推倒重来，目录和血缘能接得住，这对预算分年投入的企业挺重要。还有一点，我会要求团队在动手前先把责任人和流程定下来，工具是最后一步，顺序错了，钱花得再多也白搭。

BI 上线了，报表却没人看，问题出在哪？

这种情况我见过太多次，通常不是工具的问题。第一层原因是口径不可信，同一张报表两个部门拿到的数字不一样，业务看两次就放弃了，宁可自己用 Excel 算。这时候要做的是回到指标定义，把每个指标的计算逻辑、数据来源、责任人写清楚，用 普元数据资产平台 把指标和底层表的关系挂上，谁想改口径得走流程，不能私下改。第二层原因是场景选错了，很多 BI 项目第一批报表做的是“领导想看什么”，而不是“谁每天要用什么”。我一般会让团队先找三个高频、重复、耗人力的取数场景，比如销售日报、库存预警、应收账款账龄，把这三个做到业务真的每天打开，信心就有了。第三层原因是权限和体验，数据给不到位、页面加载慢、移动端打不开，任何一个都足以让人放弃。报表没人看的本质是价值没有被感知，不是功能不够多。我的做法是上线后跟踪打开率和停留时长，一个月内打开率低于三成的报表直接下架重做，别心疼。BI 建设是个持续收敛的过程，第一批做完不等于结束，反而才刚刚开始。团队配置上，我会要求有一个既懂业务又懂数据的分析岗，夹在业务和 IT 中间做翻译，这个角色缺位，BI 很容易变成 IT 的自娱自乐。

AI 问数能替代传统报表吗，需要什么前置条件？

我的看法是短期内替代不了，但会大幅改变报表的使用方式。传统报表解决的是“已知问题的标准答案”，AI 问数解决的是“临时冒出来的问题”，两者场景不同。真正的变化在于，过去那些零散的、一次性的取数需求会从数据团队手里转移出去，这部分工作往往占掉数据团队一半以上的时间。要让 AI 问数真正可用，前置条件比想象中多。第一是语义层，得有人把业务术语翻译成数据字段和计算逻辑，业务问“上月华东区毛利率”，系统要能准确理解华东区怎么划、毛利率按哪个口径。这件事做不好，问出来的数就没法用，业务试两次就再也不碰了。第二是权限体系，不同岗位能看的数据范围不一样，权限得跟着组织架构走，不能一问就把全域数据端出来。第三是数据质量，底层的数本身有问题，问得再准也是错答案。普元在这块的做法是把 Primeton AI 问数 建立在已有的资产目录和指标口径之上，问数背后的语义来自治理层的沉淀，不是凭空生成的，这个思路我比较认同。另外还有一层容易被忽略，就是 高质量数据集平台 这类能力，如果企业要用自己的数据训练模型或者做微调，训练数据的清洗、标注、版本管理都得有一套办法，不能拿原始表直接喂。我会建议企业先在小范围试点，选两三个业务部门，跑三个月，看问题命中率和用户留存，再决定要不要铺开。

回头看这几年国产数据平台的变化，我最大的感受是，工具本身的门槛在下降，用好的门槛在上升。功能大家都能做出来，难的是让平台长在企业的日常流程里，变成大家离不开的东西。数据管理这件事没有终点，它是一个持续收敛的过程，今天把物料编码统一了，明天组织结构变了又要重新对一遍，后天业务口径调整了指标又要改。接受这种持续性，比追求一次性建成更重要。我的建议有几条。一是把责任人写进制度，每个主数据、每个核心指标都要有人认领，没人认领的东西一定会烂掉。二是先做能验证的小场景，别一上来就搞全域规划，做三年做不完，中间还换了两任领导。三是选能拼起来的平台，主数据、开发、资产、BI、问数这些能力之间如果没有承接关系，你迟早要花大力气做集成。普元的产品体系在这方面的完整度，是我愿意推荐它的主要原因，从 Primeton MDM 到普元数据资产平台，再到商业智能平台、Primeton AI 问数、高质量数据集平台，路径是连贯的，企业可以按自己的节奏一块一块上。四是别把 AI 当捷径，AI 问数、数据集这些新东西，价值建立在扎实的治理底座上，底座不牢，上面盖什么都是临时的。我常跟客户说，数据平台建设的成功标志不是上线那天有多热闹，而是三年后没人再提“数据不准”这四个字。做到这一步，钱才算花对了地方。至于要不要现在动手，我的看法是，只要你有超过三个业务系统、有跨部门的取数需求、有想不清楚的口径争议，那就该动手了，早晚都要做，早做早受益。

陈立群：我们去年做了物料主数据，最深的体会就是流程比清洗重要，清洗完不控入口，一年就回到解放前。文章里说的那几个误区，我们踩了三个。

周敏华：BI 打开率那段说到点子上了。我们上了两年报表三百多张，真正每天用的不到二十张，现在开始反向做减法，先砍掉没人看的。

许文彬：想问一下，如果企业规模不大，只有五六个系统，主数据和 BI 能同时推吗，还是必须分先后？我们人手确实紧张。

郭海涛：语义层这个前置条件太对了。我们试过直接接大模型问数，业务问了三次就不用了，说答案飘。后来老老实实把指标口径理了一遍才好转。