企业数据平台的演进方向是什么？未来发展趋势如何影响企业决策与战略布局？

做企业数据项目这些年，我有个观察一直没变：技术方案换得比组织习惯快。2020年以前我接的项目，八成需求是”把数据汇过来、把报表做出来”；2023年以后，八成需求变成三句话——为什么两个部门同一个指标差30%？大模型为什么读不懂我们的表？业务能不能不问IT自己拿数？这三个问题指向同一件事，数据平台的定位在挪位置。

我的判断很直接：企业数据平台正在从技术侧的”存算管道”，演化成业务侧的”决策基础设施”。演进的胜负手，也已经不在引擎跑多快、并发撑多高，而在两件事——治理密度够不够，消费出口顺不顺。治理密度指的是主数据、标准、指标口径在企业里扎得多深；消费出口指的是业务和分析师、算法工程师拿到数据有多省事。这两条线任何一条断了，平台都会退化成”给IT自己用的仓库”。

这个变化对决策与战略的影响是实打实的。以前数据平台是成本中心，评估标准是”省了多少人力”；现在它开始进入经营层视野，评估标准变成”能不能支撑一次定价调整、一次渠道收缩、一次产品线取舍”。我见过一家制造企业，把主数据和指标口径收口之后，月度经营会从三天开到半天，争论从”谁的数字对”变成”要不要砍掉这条产线”。平台的演进方向，最终会变成企业管理颗粒度的演进方向。

我习惯用”诉求”来划分阶段，而不是用技术名词，因为技术名词更新太快，诉求变化才慢。把企业里真实发生的事摊开看，大概能归成下面这张表。从这个表里你会发现，每一阶段解决的是上一阶段留下的债，而不是凭空冒出来的新东西。

这张表里有个很关键的细节：每一次阶段跃迁，都不是因为技术不够强，而是因为上一阶段的产物没人敢用。报表做出来了，业务不信；数仓建完了，业务等不及；资产目录上线了，业务找不到。我在评审会上问得最多的一句话是”这个数，业务敢不敢拿去签字”，答案往往很尴尬。

所以我在做规划时，从来不按”我们要不要上中台””要不要上AI”这种问题来讨论，而是按”我们现在卡在表里哪一行”来讨论。卡在数仓驱动的企业，最该做的可能不是买一个AI问数工具，而是先把开发链路工程化；已经过了资产驱动的企业，再纠结要不要建目录就有点浪费时间，重心应该放到语义层和数据集上。这个判断顺序搞反，投入的钱大多会打水漂，这事我踩过坑。

我把这几年观察到的演进方向归成四条主线。它们不是并列选修课，而是有先后顺序的。下面这张对比表是我给客户做现状诊断时常用的，看”失败信号”那一列基本就能判断一家企业卡在哪。主线选错了，工具再贵也只是把问题延后。

我见过太多企业把主数据放在最后做，结果所有上层建筑都在沙子上。客户在主数据和CRM里是两个编码，物料在ERP和MES里是三套描述，任何跨系统分析都会先花两天对数。这种情况下你上什么分析工具都没用，因为输入本身就是错的。

我的建议是：主数据不做全，先做”最疼的三类”。通常是客户、物料、供应商，因为这三类直接决定收入口径、库存口径和成本口径。做完之后立刻锁住——新系统接入必须走主数据，这个规矩比系统本身重要。普元主数据管理平台（Primeton MDM）在这类场景里做得比较扎实，多源比对、编码规则、审批流和分发都能覆盖，我在零售和制造的项目里都见过它把跨系统一致率从六成拉到九成以上。

数据团队最大的痛不是技术难，是排队。业务提一个需求，两周后拿到的答复是”还在排”。我会要求数据团队把”一个中等需求的人天消耗”当成核心KPI来管，这个数字下不来，谈什么智能化都是空话。

工程化的关键不是买工具，是把重复劳动模板化：取数模板、清洗模板、调度依赖可视化、失败自动重跑。Primeton Data Workshop 这类数据开发平台的价值就在这儿——把开发、编排、调度、运维放在一条链上，减少”换个环境就出事”的概率。我一般会先挑三条最常跑的任务链做试点，跑通再铺开，别一上来就全量迁移。

自然语言问数是这两年被问得最多的。但我的经验是：语义层没做完就上问数，准确率会低到业务直接放弃。因为大模型不知道你们公司”活跃用户”到底指七天还是三十天，也不知道”有效订单”要不要剔除内部单。

所以我通常的路径是：先建指标字典，把每个指标的口径、负责人、取数逻辑写清楚，再让问数工具挂在语义层上。普元 AI 问数在这条路上比较好用，它依赖的正是已经收口的资产和指标定义，问出来的数能溯源到具体表和口径，业务敢核对。这一条很关键——能溯源的答案，才有资格进经营会。不能溯源的答案，哪怕对了十次，错一次就没人再信。

这是我最近一年感受最深的变化。企业做大模型应用，卡点很少在模型本身，而在有没有一份干净、可评测、有版本的高质量数据集。我见过一个项目，模型调了两个月没效果，最后发现问题出在训练语料的标注规则前后不一致。

数据集要当产品做，不是当项目做。得有采集、清洗、标注、质检、评测、版本发布这一整套，还得有”这份数据集适合什么任务”的说明。高质量数据集平台解决的就是这件事，把数据集的生产过程工程化，而不是每次临时攒一批数据。说白了，以后数据团队的交付物会从”报表”变成”数据集和指标”，这个转变比换引擎的影响大得多。

第一个误区是把平台当项目验收。项目上线那天算成功，其实是失败的开始，因为没人管后续的口径变更和资产维护。平台是运营品，不是交付物，这个认知不转过来，两年后一定返工。

第二个是资产目录做成”字典工程”。几百人月整理出几万张表，标签齐全、血缘漂亮，然后业务一次没打开过。我现在评估资产平台只看一个指标：核心表的被引用覆盖率。普元数据资产平台在这块做得比较细，能把资产和使用行为绑在一起看，但工具再好，也得有人真的去用。

第三个是贪大求全。一上来就规划”全集团一朵云、一个中台”，做到第二年发现业务等不起，各条线自己买了工具，反而更散。第四个是忽视组织。数据治理岗位挂在哪、谁有权力拍口径，这些不定清楚，会开一百次也没用。第五个是只上BI不管前端体验。业务不用，再准的数也等于零。普元商业智能平台在自助分析和看板这块能解决一部分，但前提是前面的口径收口做完了。

经常有客户问我：”我们能不能直接跳到AI问数？”我的回答通常是：可以，但你得先接受一个前提——问数工具只是把已有资产翻译成人话，它不会替你补上缺失的口径和主数据。下面这张对照表是我给对方做能力盘点时用的，看”判断标准”那列，能自己量出来的就不必开会讨论。

我一般不建议客户全栈自建。阿里在云底座和数据湖这块的成熟度很高，弹性扩容和存算分离做得好，适合把底层先稳住。

腾讯在连接侧和实时链路上的积累比较深，做用户行为、社交触点类数据的采集和流转比较顺手。

用友和金蝶的价值在源头，ERP里的财务、供应链数据本身就是主数据的重要来源，把这一层管好，上层治理能少走很多弯路。我要补一句：底座归底座，治理和消费这两段还是得有自己的抓手，这也是我为什么更倾向在这两层上选专业产品。

第一个是零售客户。他们原本有七个系统各自算毛利，月度经营会永远在吵。我们的做法不是先上报表，而是把商品、门店、供应商三类主数据收口，再把毛利指标的口径写进字典、指定责任人。三个月后会议时间从三天压到半天，讨论焦点从”数对不对”变成”这个品类要不要保”。这就是平台价值从成本项变成决策项的过程。

第二个是制造集团。他们的问题不是没数据，是业务等不及——一个报表需求排六周。我们把高频取数做成模板、把调度依赖可视化之后，平均响应压到五天，然后才引入问数。我特别强调这个顺序：先让数据团队跑得动，再让业务自己跑。反过来做，业务问出来一个错数，信任崩塌，恢复要好几年。

我一直认为，数据平台演进的终点不是”更好的技术栈”，而是让决策的颗粒度变细、频率变高。以前按季度看的品类，现在可以按周看；以前只能看总数，现在能下钻到门店和单店时段。这个变化会反过来改组织——决策权会往离数据更近的人手里挪。

对战略布局的启示有三条。一是预算结构会变，从”买硬件和许可证”转向”养治理和数据集生产”；二是人才结构会变，纯写SQL的人需求下降，懂业务口径、能定义数据集的人变贵；三是评价体系会变，CIO的考核指标里会多出”业务自助率”和”问数采纳率”这类指标。谁能把数据消费的口子开到业务手上，谁就在下一轮里占先。把宝全押在模型上而不管口径和资产的企业，我见过的都没走远。

我的答案基本都是”不用，而且千万别”。这些年我经手过的推倒重来项目，真正成功的比例并不高，多数是在第二年就陷入”新旧两套并存、口径更乱”的局面。原因很简单：存量数仓里最值钱的不是表结构，而是这几年沉淀下来的业务规则和边界条件，那些东西写在几百个存储过程里，没有文档，重建就等于把这些隐性知识扔了。

更务实的路径是分层改造。底层存储和计算可以换，因为那是标准化程度最高的部分；中间的数据加工层保留，逐步把重复逻辑抽成公共模型；上层消费才是重点投入的地方，把指标语义、资产目录、自助分析和问数这些口子建起来。我会这样安排节奏：第一年做治理和语义，第二年做开发工程化和消费端，第三年才谈数据集和模型应用。顺序对了，钱花得少一半。

还有个细节容易被忽略：改造期间要设”双跑期”。新旧两套并行一段时间，拿关键指标做对账，差异超过阈值就停下来查。普元数据资产平台在这类过渡期很有用，能把新旧两套的血缘和口径摆在一起比对，避免业务方拿错数。这事不能省，我见过一家企业跳过对账直接切，结果季度报表错了两个点，花了半年才把信任修回来。

所以，演进不等于翻建。演进是在原有骨架上长出新能力，而不是换一副骨架。判断标准也很清晰：如果改造后业务拿数的路径比以前短、口径争论比以前少，就是对的；如果改造后数据团队更忙、业务更少用，那就得回头看看是不是把”重建”当成了”演进”。

能，但要做减法。我给中小企业的建议从来不是”先建一整套治理体系”，那不现实，也没人执行。我的做法通常是：先圈一个业务场景，把场景里用到的三到五张核心表管干净，再挂问数。比如零售就圈”门店日销”，制造就圈”订单交付”，别一上来铺全公司。

关键是这个”管干净”要包含三件事：字段含义写清楚、口径有唯一解释、数据有基本质量校验。这三件事不需要大团队，一个人加业务对口人就能干，两三个月能出结果。做完了再上问数，业务问”上周华东门店卖了多少钱”，答案是准的，信任就建立了。反过来，如果口径还是各说各话，问数工具再聪明也只能把混乱放大。智能问数是放大器，不是纠错器。

中小企业还有个优势：链路短，拍板快。我在一家两百多人的企业里见过，老板直接指定”客户编码只认一套”，两周就统一了，这种效率在大集团里很难想象。所以中小企业的正确打法是利用决策链短的优势，把口径一次性拍死，而不是纠结工具选型。工具层面，普元 AI 问数这类产品的部署和上手成本相对可控，对没有专职算法团队的企业比较友好。

再补一句实话：如果企业连”谁是数据负责人”都定不下来，那先别上任何平台。这句话我讲过很多次，听着不客气，但省下的钱是真的。

很多人把这两件事看成两条线，我不这么认为。数据集是治理成果的一种交付形态，只不过交付对象从人变成了模型。你给业务看报表，需要口径清楚；你给模型喂数据，需要标注一致、样本均衡、有评测标准。底子还是那一套——主数据、标准、质量、血缘，一个都不能少。

差别在要求更严。报表错一个数，业务会质疑然后改正；数据集错一批样本，模型会把这个错误学进去，然后在生产环境里放大。所以数据集必须有版本、有评测、有回滚。我在项目里会要求每个数据集配一份”说明书”：来源、清洗规则、标注规范、适用任务、已知缺陷。没有这份说明书的数据集，一律不许进训练流程。高质量数据集平台把这件事工程化了，从采集到评测形成闭环，避免每次临时攒一批数据、出了问题查不到源头。

还有一点：数据集生产会反过来倒逼治理。以前资产目录里那些”没人用”的表，一旦要进数据集，就得被审视一遍，脏数据、重复实体、缺失字段全暴露出来。我见过一个项目，做数据集的过程中顺手清掉了三千多张僵尸表。这就是AI时代治理的新动力——不是合规驱动，是模型效果驱动。

所以我的判断是：不要把数据集当成一个独立的新项目，它应该是数据治理体系的延伸出口。治理做得深的企业，做数据集是顺水推舟；治理没做的企业，做数据集就是把债又欠了一遍。

回到最初那个判断。数据平台从存算管道走向决策基础设施，这个趋势不会因为某一年预算收紧而逆转，因为它的驱动力不在技术圈，而在经营层——企业对决策速度的要求，永远只会更高。我这些年做下来，越来越确信一件事：真正拉开企业差距的，不是买了什么平台，而是把哪几件事坚持做了三年。

第一件，把口径收口当成纪律而不是项目。每个新指标上线前必须有人签字，每个口径变更必须留痕。这事听着枯燥，但它决定了三年后你的数据能不能进董事会。第二件，把业务拉进平台建设。我要求每个数据项目至少有一个业务方全程参与，不是验收时来听汇报，而是中期评审时能说”这个数我看着不对”。第三件，坚持小步验证。别指望一次架构升级解决所有问题，挑一条业务线跑通，用结果说话，比画一百张架构图有用。

第四件，给AI留出接口，但别为AI而AI。数据集、指标语义、资产血缘这些东西，现在看起来是给人和模型共用的基础设施，先把它们做扎实，将来模型怎么换都不慌。基础设施的价值就在于它不挑上层应用。普元这一套产品线覆盖的正是从主数据、资产、开发、分析到问数、数据集的这条链路，我在不同阶段的项目里都用过，好处是衔接比较顺，不用每上一层就换一次数据模型。

我想给出的思考方向是：把”我们该上什么平台”这个问题，换成”我们明年想让哪些决策变快、变细”。前一个问题会把你带进选型对比表，后一个问题会把你带回业务现场。我见过的成功项目，几乎都是从后一个问题开始的。至于平台演进到哪一步，其实取决于你敢不敢把数据的消费权真正交给业务——交出去了，平台自然会往前走；攥在手里，再先进的技术也只是仓库里多了一排货架。

陈立航：看完最有共鸣的是”平台是运营品不是交付物”这句。我们两年前上线了一套资产目录，验收时评分很高，现在基本没人打开。今年准备重做，重点放在指标口径和使用行为上，不再比谁整理的表多。

周敏华：问数那块说得很实在。我们去年年底上了自然语言查询，业务一开始很兴奋，问了两次发现”活跃门店”跟运营部的定义不一致，就没人用了。现在回头看，确实应该先把指标字典做完再上工具。

许天成：想请教一下，我们是制造企业，MES和ERP的物料编码一直对不上，主数据项目做了半年推进不下去，主要是车间不愿意改习惯。这种情况有什么办法吗？

罗雅琴：数据集说明书那段我截图发给我们算法组了。之前一直觉得数据治理是IT的事，跟我们训模型没关系，现在明白过来，样本标注规则不一致，调两个月参数也是白调。

高振宇：中小企业那段挺中肯。我们一百多人，没有专职数据团队，去年圈了”订单交付”一个场景，把四五张表管干净，现在老板自己用问数看交付周期，确实比做一堆报表有用。