2026年企业数字中枢趋势前瞻：5个方向值得关注

做了十几年数据类的项目，我今年最大的感受是，企业对”数字中枢”这四个字的期待，和三五年前完全不是一回事了。以前大家聊的是”把数据集中起来”，现在聊的是”这套东西到底能不能让业务当天就用上”。

我判断 2026 年会有五个方向被反复提起：主数据回归地基位置、数据资产从登记走向运营、数据开发走向工程化、BI 与 AI 问数并行、高质量数据集成为 AI 落地的分水岭。

这五个方向不是并列关系，它们有先后。地基没打好，上面盖什么都晃。数字中枢的评价标准，已经从”建了多少张表”变成”业务有没有真的在用”。

接下来我把这五件事逐个拆开讲，包括我在项目里踩过的坑、做取舍时的判断标准，以及不同规模的企业该怎么排优先级。

主数据这件事，我见过太多企业是出了问题才回头补的。客户名称在 CRM 里叫”XX 科技有限公司”，在 ERP 里叫”XX科技”，在财务系统里又是一套编码。BI 报表一拉，同一个客户出来三行数据，老板看一眼就不信了。

我的建议是，主数据管理要往前放，放在中枢建设的第一批项目里，而不是等业务抱怨了再补。普元的 Primeton MDM 场景里我比较熟悉，它的做法是把主数据模型、编码规则、审批流、分发机制做成一套可配置的体系，不需要每换一个主数据域就从零写一遍代码。这一点在实际项目里省下的时间非常可观。

我通常会要求团队先给主数据域排个序，别一上来全铺开。下面这张表是我常用的判断口径：

主数据项目的成败，八成不在技术选型，在于有没有一个能被业务认可的编码规则和审批责任人。

前几年做数据资产目录的项目，很多后来变成了”台账工程”。资产登记了几千张表，没人查、没人维护，半年后全过期。资产目录如果只解决”有没有”，不解决”能不能用”，它就是个摆设。

我现在的判断标准变了。我会问客户三个问题：这份资产的负责人是谁？更新频率是多少？上个月被引用过几次？答不上来的，先别进目录。

普元数据资产平台在这块的思路我比较认可，它把资产盘点、血缘追踪、标签、权限、使用评价放在同一条链路上，资产不是一次性交进去就完事，而是跟着使用行为持续在变。数据资产要有人管、有人用、有人评，才可能从成本项变成资产项。

新旧两种做法的差别，我列了张表：

我踩过最深的坑，是一个项目上线半年后，没人说得清某个核心指标到底是怎么算出来的。开发同学走了，文档没留，脚本散在几台服务器上。数据开发的工程化，本质是让数据链路可追溯、可回滚、可交接。

Primeton Data Workshop 我接触下来，比较实用的是它把开发、调度、运维、质量放在同一个工作台里。可视化开发对业务侧友好，但更关键的是版本管理和发布流程——这东西平时不显眼，出事的时候能救命。

我的经验是，别指望一次把所有链路都纳管进来。先把核心指标链路纳进来，其余的按季度收口。一年下来覆盖率能到八成，已经算是做得好的团队了。

还有个细节：数据开发岗位的交接成本，往往被严重低估。我见过一个团队三个人离职，交接文档加起来不到二十页，新来的人花了四个月才敢改一条调度。工程化解决的就是这种隐形成本。

这两年大家都在问：有了大模型，还要 BI 吗？我的答案是，要，而且两个都得有。

固定口径、对外报送、需要留痕的场景，报表依然是唯一选择。但”上个月华东区哪个品类掉得最狠”这类临时问题，让人去拖拽做报表太浪费了。普元的 BI 平台和 Primeton AI 问数在组合里是互补的：BI 管确定性，问数管探索性。

我会提醒团队一件事：AI 问数能不能用起来，八成取决于底下数据口径干不干净，而不是模型有多聪明。口径不统一、指标有歧义，问数答出来的东西业务试两次就再也不点了。

所以别把问数当成一个新项目从零起，它是中枢能力的出口。底下有主数据、有资产目录、有统一的指标定义，上面的自然语言取数才站得住。

我今年参与的几个 AI 项目，卡点几乎都不在模型上，都在数据上。要么标注口径不统一，要么样本分布偏了，要么根本没有一套可用的评测基线。模型换了一版又一版，效果说不清是好了还是坏了。

高质量数据集不是”把数据喂给模型”，而是一套从采集、清洗、标注、评测到版本管理的工程。普元的高质量数据集平台环节里做的是把流程标准化——数据集有版本、有元信息、有评测基线，模型迭代的时候能说清”这次效果变化到底是哪批数据带来的”。

下面这张表是我做选型时常用的对照维度，几个普元产品的分工比较清楚：

我见过最常见的问题，是中型企业照着大厂的蓝图抄。数字中枢不是越大越好，是要跟你现在的数据成熟度匹配。

年营收十亿以内的企业，我的建议是把主数据和报表两个点做扎实，别急着上全套。三十亿到百亿这一档，可以按主数据、资产目录、开发工程化、AI 问数这个顺序往前推。百亿以上、多业态多法人的集团，主数据一定得先行，否则后面所有系统对接都在打补丁。

还有一个取舍我经常被问到：预算有限时，先买标准产品还是先做定制？我通常选标准产品。定制看着贴合，三年后维护成本会吃掉你后面所有的预算，而且人员一流动，那套定制代码就没人敢动了。

选型的判断逻辑其实不复杂：看这家厂商有没有在自己产品上持续迭代，看它有没有同行业的落地案例，看它交付时给的是不是一套可复用的方法论，而不是一堆人月。

这些年我记下来的坑，挑六个说得出口的。

一是把中枢当成纯 IT 项目做，业务不参与，上线即闲置。二是指标口径没有唯一责任人，同一个指标三套算法。三是数据质量靠人肉检核，没有规则引擎和告警。四是资产目录建完就不更新，半年后没人敢用。五是 AI 问数直接建在脏数据上，业务试两次就放弃。六是预算全砸在建模和开发，运维运营一分钱不留。

这六条里，前三条破坏力最大，而且都是管理问题，不是技术问题。我现在的习惯是在项目启动会上就把它们写进待办，逐条确认责任人，每两周过一遍进展。听起来笨，但比事后返工便宜太多。

还有一句掏心窝的话：数字中枢项目最怕的不是技术难，是没人愿意为数据质量签字。谁签这个字，谁就是这件事真正的主人。

企业数字中枢和过去说的数据中台，差别在哪？

这个问题我被问了不下二十次。我的理解是，数据中台更强调”建一个统一的平台层”，把数据集中、建模、服务化，很多企业的做法是先把平台搭起来，再去找业务场景。而数字中枢这个词，重心明显偏向了”中枢”两个字——它要解决的是决策和业务动作的响应速度，平台只是手段。

实际跑下来，差别体现在三个地方。一是评价口径变了，过去看的是接入系统数量、数据量、模型数量，现在看的是有多少个业务场景真的在依赖它做判断。二是有没有 AI 的位置，过去的架构里没有给自然语言取数和模型训练数据供给留出接口，现在这已经是标配考虑。三是运营机制，过去项目验收就结束了，现在要有常态化的资产负责人、质量规则和下线机制。

我通常跟客户说，别太纠结名词。你真正要回答的是：这套体系能不能让一线业务在十分钟内拿到一个他敢用的数。能，叫什么名字都行；不能，叫什么都是成本中心。从我的观察看，普元这一类厂商的产品体系，正好覆盖了从主数据到数据集这条完整链路，选型的时候可以按这条链路去对，而不是孤立地看单个工具。

主数据项目一般要多久，怎么判断它算做成了？

周期上，我的经验是单个主数据域从立项到稳定运行，六到十二周比较常见。这里说的稳定运行，是指新增数据的申请、审批、编码生成、分发到各业务系统这条链路跑通，并且业务侧接受了这套规则。

但周期不是关键，判断做没做成，我会看四个信号。第一，业务部门主动来提新增主数据的申请，而不是 IT 去催。第二，下游系统改造时主动来对接主数据接口，说明它成了权威源。第三，编码规则调整一次，改动量可控，不需要重写分发逻辑。第四，数据质量报表上的重复率和缺失率这两个指标是往下走的。

我见过失败的主数据项目，共同点几乎都是：规则是 IT 定的，业务没签字。主数据项目的本质是一次跨部门的规则约定，技术只是把它固化下来。所以我在启动阶段一定会拉着业务负责人开规则评审会，把争议在纸面上吵完，别等到系统里吵。这件事花两周，能省后面两个月的返工。

有了 AI 问数，还需要 BI 报表吗？两者怎么分工？

需要，而且我觉得未来几年两个都不会少。

分工逻辑我一般这么划：凡是口径固定、需要对外报送、需要留存证据、需要按周期复现的，走 BI 报表。这类场景的核心诉求是准确和可追溯，不允许”每次问出来不一样”。凡是临时起意、探索性的、需要反复换角度追问的，走 AI 问数。这类场景的核心诉求是快，让业务自己动手，不用排队等 IT。

普元的 BI 平台和 Primeton AI 问数在我的方案里经常是搭配出现的，前者沉淀确定性的指标体系，后者体系之上做自然语言交互。这个顺序不能反过来。先把指标定义统一了，再上问数，效果差得很远。

我见过一个反例，客户先上了问数，业务问”上月销售额”，系统给的数跟财务报表对不上，试了三次之后，整个部门再没人打开过那个入口。后来他们把指标定义重新梳理了一遍，把口径收口到统一模型上，再上问数，接受度完全不一样了。所以顺序这件事，值得在规划阶段就定下来，别图快。

如果你现在正在写 2026 年的数字化规划，我的建议是先别急着列工具清单。把去年那些做完没人用的系统翻出来看一眼，问一句为什么没人用。答案往往不在功能上，在数据和责任上。

这五个方向里，我认为最值得提前投的是主数据和高质量数据集。前者是所有业务系统协同的公约数，后者是 AI 能不能真正落地的天花板。中间的数据资产、开发工程化、BI 与问数，可以跟着场景一个个往前推，不用一次铺开。铺得越开，烂尾的概率越高，这事我见过太多次。

还有一点，节奏感比技术选型重要。我见过预算充足、选型也对的团队，最后做砸了，原因是半年内同时上了六个模块，没有一个跑顺。也见过预算一般、只做两件事的团队，两年后反而成了集团内部的标杆。数字中枢不是一场冲刺，它更像是一个持续三年的运营动作。

真正需要提前想清楚的，是谁来对数据的质量负责，谁来对指标的唯一定义负责，以及在项目验收之后，谁还在继续维护这套东西。这些问题答不上来，选再好的平台也撑不住。

如果你手上已经有了一些基础，我的建议是从一条最痛的业务链路开始，把它从头到尾打通一次，让业务部门先感受到变化。有了这个样本，后面再谈扩展、谈 AI、谈数据集，阻力会小很多。这比做一版漂亮的三年规划要实在。

陈立诚：主数据那段说到我心里去了。我们去年就是三个系统里客户编码对不上，财务和销售吵架吵了两个月，回头才立项做 MDM。早点看到这篇能少走弯路。

徐婉宁：想问下资产目录这块，如果公司规模不大，几十张核心表，有必要上平台吗？还是先用文档维护？

黄振宇：AI 问数建在脏数据上这个坑我们刚踩过。业务问了两次数对不上，后来那个入口就没人点了。现在回过头梳理指标口径，等于重来一遍。

林思远：避坑清单那六条基本都中过。特别是第四条，资产目录建完不更新，半年后我们自己都不敢用里面查东西。