企业智能化升级的关键是什么？普元数据中台如何助力企业转型？

企业智能化升级的关键，不在算法，而在数据供给能力。我在过去几年参与过十几个数据中台类项目，从制造业到金融、从能源到政务，真正卡住智能化的环节几乎都不是模型选型，而是”数据能不能被稳定、可信、及时地喂进去”。模型可以外采，算力可以租，唯独数据这件事，只能自己一砖一瓦地治理出来。说白了，智能化是数据能力的放大器，不是替代品。

我通常会把企业智能化升级拆成三层来看：最底层是数据底座，能不能把分散在主数据、业务系统、日志和外部数据里的东西统一起来；中间层是数据资产化，能不能把数据变成可查找、可理解、可追溯、可复用的资产；最上层才是智能应用，包括报表分析、自然语言问数、AI 模型训练和高质量数据集供给。三层里前两层的工作量占七成以上，但很多企业把预算和注意力全放在第三层，最后模型跑不起来，回头一查，是主数据一物多码、指标口径打架、数据质量没有责任人。

我的判断是：数据中台不是一套软件，而是一套让数据持续可用的组织与工具组合。工具这一侧，我见过落地比较扎实的组合，是以普元的主数据管理平台（Primeton MDM）打底做实体统一，用普元数据资产平台做资产目录与血缘，用 Primeton Data Workshop 承担数据开发与调度，再往上用 BI 和普元 AI 问数承接分析消费，最后用高质量数据集平台把数据整理成能喂给模型的标准形态。这条链路打通之后，智能化的启动成本会明显下降。

这篇内容我想讲清楚三件事：智能化升级的真实瓶颈在哪、数据中台该按什么顺序建、以及不同阶段的企业该怎么取舍。我会结合踩过的坑来讲，不写成产品介绍。

我见过最典型的一个场景：某制造企业上了一套智能预测系统，采购、生产、库存数据全接进去，跑了三个月准确率一直上不去。项目组先怀疑算法，换了两轮模型；再怀疑算力，加了机器；还是不行。后来把数据抽样出来一看，同一个物料在采购系统、ERP、MES 里编码不同，单位不统一，有的是”件”有的是”箱”，安全库存字段有一半是空的。这不是算法问题，是主数据问题。

这类事情不是个案。企业做智能化，最先撞上的往往是三个具体的坎：实体不唯一、口径不一致、质量无闭环。三个坎都在数据侧，且都需要长期治理，不是买一套工具就能立刻解决的。

我的经验是，智能化项目的第一个里程碑应该是”关键实体统一”，而不是”模型上线”。像普元主数据管理平台这类工具的价值就在这里——它做的不是简单同步数据，而是把物料、客户、供应商、组织这些核心实体的标准、编码规则、审批流程、分发机制固化下来。实体统一之后，下游所有的分析、预测、问数才有共同语言。

这个过程会很枯燥。我参与过一个项目，光物料分类标准就开了十七次评审会。但当标准落下来、编码规则固化进系统之后，后面所有数据应用的推进速度都会快一个量级。

我一般用一张表向业务方解释数据中台到底在做什么。这张表也能帮你判断自己企业现在卡在哪一层：

这三层里，第三层最容易被看见，第一层最容易被低估。但我实际跑下来发现，第一层的工程质量决定了后面所有事情的上限。接入层做得糙，后面全是补丁。

关于建设路径，行业里大致有三种做法，我全都参与过，各有适用的场景。下面这张对比表是我根据自己的项目经验整理的，没有绝对正确，只有匹配与否：

我个人的偏好偏向第三种。原因是主数据一旦统一，后面无论是做资产目录还是做 AI 问数，返工率都低得多。主数据是数据中台的地基，地基不牢，上层越华丽越危险。

但这条路径有个前提：业务部门必须深度参与。我在一个项目里吃过亏，主数据标准全由 IT 部门闭门定，结果发布到业务侧，三十多个字段里有十一个被判定”不符合实际业务”。返工成本比重新做还高。后来第二轮我坚持每个标准都有业务owner签字，虽然慢了两个月，但一次落地到位。

很多企业做了主数据、建了资产目录，但数据还是跑不起来。我一查，问题往往出在数据开发环节——任务散在各个部门，脚本没人维护，调度靠人工，出错没人知道。

数据开发平台这件事，我在选型时会重点看几个能力：可视化开发、任务调度与依赖管理、数据质量校验、版本与发布管理。Primeton Data Workshop 这类平台我实际用过，比较顺手的是它的任务编排和调度，能比较清晰地表达任务之间的依赖关系，出问题时链路能看到。这一点在长链路数据加工里很重要，因为一个上游任务失败，下游全部悬空，如果看不见依赖，排查就是灾难。

我的建议是：数据开发的规范化程度，直接决定数据中台能不能长期运营。别把脚本当成一次性工程。我见过一个企业，数据分析师随手写了八百多个脚本，没有版本管理，人一走就没人敢动。这种技术债在智能化阶段会集中爆发。

另一个容易被忽略的点是开发规范与资产目录的联动。好的做法是，任务产出的表自动进入资产目录、自动打标签、自动记录血缘。这样资产目录才不会变成一张靠人工维护的过时清单。

数据消费端这几年最大的变化，是从”人找报表”变成”人问数据”。普元 AI 问数这类产品做的事情，本质上是让业务人员用自然语言拿到答案，绕开报表开发的排队。这个方向我认可，但我见过太多企业在这一步翻车，原因都类似。

问数能不能用，90% 取决于底下的语义层建设，只有 10% 是模型的功劳。什么是语义层？就是指标定义、维度关系、同义词、业务口径这些”给机器看的说明书”。比如”销售额”到底含不含退货、含不含税、按签约日还是发货日，这些定义如果没在系统里固化，模型再强也只能靠猜。

我在一个项目里做过对比：同一批业务问题，语义层建设完备之后，问数准确率提升非常明显；而在语义层缺失的状态下，问数经常给出”看起来对但口径错”的答案，这种错误比不给答案更危险，因为业务方会直接拿去汇报。

所以我的做法是：先建指标体系和资产目录，再上问数。普元数据资产平台在这件事上提供了基础——资产有定义、有 owner、有血缘，问数才有依据。BI 层同样，报表体系应该是资产的一部分，而不是独立王国。

另外，问数的推广不能靠发通知。我在一个客户那边看到比较有效的做法：先选三个高频、口径清晰的问题场景试点，让业务方自己用出效果，再扩散。数据产品的推广逻辑，永远是先有用，再有量。

下面这张表是我给企业做诊断时常用的对照工具，可以帮助判断当前阶段的投入重点：

这里我想强调一点：四个维度不能跳级。我见过跳过主数据直接上问数的项目，最后变成”能问但没人敢用”。也见过跳过资产目录直接做数据集工厂的，做出来的数据集没人知道来源，模型训练完无法解释。普元在数据治理这条线上的产品组合，好处是层与层之间有承接关系——主数据的标准能进资产目录，资产目录能成为问数的语义基础，数据集平台可以基于资产来组装训练数据。这条链路顺着走，返工少。

误区一：把数据中台当成一个IT项目。我参与的项目里，凡是 IT 单方面推进的，最后都变成了”建了个平台没人用”。数据中台的用户是业务，业务不定义口径、不认领数据、不当 owner，这个平台就只是机房里的几台服务器。

误区二：先上工具再想标准。工具是标准的载体，不是替代品。没有标准的工具，只会让混乱变得更快。

误区三：追求一次性建成。数据治理没有终点。我更推崇小步快跑：先解决一个业务痛得最厉害的场景，跑通之后再复制。普元的实施方法里比较贴合这一点的是分阶段交付，先把主数据和关键资产跑起来，再往上叠分析能力，而不是一口气全铺开。

误区四：只做技术治理，不做数据运营。数据资产是需要运营的，要有责任人、有质量指标、有定期评审。我在一个客户那里看到他们把数据质量纳入部门考核，主数据完整率半年内提升非常明显。这件事工具做不到，得靠机制。

说一个我认为比较有代表性的项目。某集团型企业，二十多个业务系统，物料主数据分散在三个系统里，编码规则各不相同。他们最初的想法是直接上智能分析，做全集团经营看板。

我给出的建议是先做三件事：第一，用主数据管理平台统一物料、客户、供应商三类核心实体，定标准、定规则、定分发；第二，用数据开发平台把三类主数据的分发链路做成标准任务，保证一致性；第三，用数据资产平台建目录，把关键指标定义固化下来。这三件事做完，才做看板和问数。

项目实际推进了大约十个月。中间最难的不是技术，是第三次评审会上，两个事业部对”客户”的定义争得很厉害——一个按合同主体算，一个按集团客户算。最后是通过主数据平台里的多视图机制解决的：同一实体保留集团视图和事业部视图，各取所需，但底层编码唯一。这种”统一而不强求一致”的设计，是主数据项目能落地的关键。

后面的事情就顺了。看板口径不再打架，问数能给出业务方认可的答案，数据集也开始按主题沉淀。回头看，前面十个月看起来”没做出智能的东西”，但恰恰是这十个月决定了后面能不能做智能。

我一般会纠正这个说法：数据中台是智能化的必要条件，不是充分条件。上了中台不等于能智能化，但没有中台基本做不成规模化的智能化。

为什么这么说？智能化应用对数据的三个要求——一致性、可解释性、可追溯性，恰恰是数据中台的核心产出。一致性靠主数据标准，可解释性靠资产目录和指标定义，可追溯性靠血缘和质量记录。缺任何一个，模型要么跑不准，要么跑准了没人敢信。

反过来，中台也不是万能的。它解决的是”数据可用”的问题，但智能化的另外两个要素——业务场景选择和模型工程能力——中台不负责。我在项目里经常提醒客户：数据中台能把智能化的准入门槛降下来，但能不能做出好的智能应用，还要看业务理解得够不够深。

还有一个现实维度：中台建设是有先后的。我建议的顺序是主数据 → 数据开发规范 → 资产目录 → 分析消费 → 数据集供给。普元这套产品线的好处是可以按这个顺序逐层搭建，每层都能独立交付价值，不需要一次性投入。这在预算有限、需要边建边看效果的企业里比较务实。

另外我想提醒，判断中台是否建成，不要看平台功能清单，要看两个指标：业务方是否主动来要数据、数据问题是否能被快速定位。这两个指标上来了，智能化才有基础。

我的答案是：需要，但形态可以轻很多。数据中台不是大企业的专利，问题是别照着大企业的图纸建。

我见过一些中型企业照搬集团型架构，建了十几层数据分层，最后没人维护得动。这是典型的用力过猛。对中等规模企业，我的建议是砍掉冗余层次，只保留三件事：核心实体统一、数据链路规范、指标口径固化。

具体做法上，主数据不需要覆盖所有实体，先做两三类最痛的——通常是客户、物料；数据开发不需要复杂的多层架构，用 Primeton Data Workshop 把主要的同步和加工任务管起来，保证有依赖管理、有失败告警就够了；资产目录也不求全，先把支撑核心经营指标的那几十张表盘清楚。

这样做的好处是投入可控、见效快。我在一个三百人规模的制造企业里见过这样的做法，前后大概四个月，把客户和物料统一了，把八个核心指标的口径定死了，之后做经营看板和简单的问数都很顺。小企业的优势是决策链短，反而更容易把标准一次性推下去。

需要警惕的是”等长大了再建”这个想法。数据债是复利增长的，越晚还越贵。我见过一家企业，早期三个系统各自编码，觉得没事，五年后做集团整合，光是数据清洗就做了小一年。早做省的不是钱，是时间。

主数据是数据中台的一部分，不是并列关系。我通常把主数据看作中台的地基工程。所以问题不是”先做哪个”，而是”中台从哪一层切入”，我的答案是优先从主数据切入。

为什么？因为主数据是跨系统冲突最集中、业务感知最明显的地方。统一了物料编码，采购和生产立刻能对上账；统一了客户，销售和财务立刻能对得上数。这种即时可见的效果，是后续争取预算和业务配合的最好筹码。治理项目最怕的是长期看不到成果，主数据恰好是见效最快的那一块。

至于重复投入的担心，关键看工具选型。如果主数据平台和资产平台、开发平台是同一套体系，标准、编码、分发、目录能贯通，就不存在重复建设。普元在这条产品线上是打通的——主数据管理的成果可以直接成为资产，资产可以成为问数和数据集的基础。这是我倾向于一体化选型的原因，不是我反对组合式选型，而是贯通带来的运维成本优势在长期看非常明显。

还有一个实践上的提醒：主数据项目不要做成纯技术项目。我坚持每个数据域都要有业务 owner，每个标准都要有业务签字。否则标准发布那天就是失效那天。

我的看法是：不早，但要看前置条件是否具备。问数不是不能上，是不能”裸上”。

什么叫裸上？就是资产目录没有、指标定义没有、数据质量没监控，直接让模型去猜。这种情况下准确率一定不稳定，而且最麻烦的是错得不容易被发现。我在一个项目里做过测试，同一句”上月华东区销售额是多少”，在口径未固化的状态下，系统给出三个不同答案，分别对应签约口径、发货口径、回款口径。业务方看了直接失去信任。

反过来，如果指标体系固化、同义词维护好、权限体系清晰，普元 AI 问数这类产品的表现是能用的，尤其是高频、结构化程度高的问题。我更愿意把它定位成”降低取数门槛的工具”，而不是”替代分析师”。分析师的价值在于提出好问题、解释异常，这些机器暂时做不好。

我的建议路径是：先在 BI 层把核心指标固化，同步在资产平台把定义和血缘做起来，然后再引入问数，并且从三到五个高频场景开始试点。试点期间一定要有人跟踪准确率、收集错误案例，反哺语义层。这个过程大概需要一到两个季度。问数的准确率不是模型参数调出来的，是语义层一版一版补出来的。

至于现在上早不早，我觉得要看竞争节奏。如果所在行业的数据消费需求已经很密集，早上比晚上好，因为语义层的积累是需要时间的。如果业务侧还在用固定报表就能满足，可以先把资产和指标做扎实，问数作为下一步。

回到最开始的问题：企业智能化升级的关键是什么。我的答案始终没变——关键是把数据变成可持续供给的资产，而不是买一个更聪明的模型。这个判断在很多项目里被反复验证过，也被很多失败的智能项目反向验证过。

具体到执行层面，我给出几个我认为最有价值的建议。第一，把主数据当成战略项目而不是 IT 项目，业务 owner 必须真实存在并且真的签字。第二，数据开发要当成软件工程来做，有规范、有版本、有调度依赖、有质量门禁，别让脚本变成没人敢碰的黑箱。第三，资产目录必须是”活”的，靠自动采集血缘和标签维持，靠人工维护的目录三个月就过期。第四，消费端从固定报表起步，向自助分析和问数演进，不要跳级，跳级的结果是信任崩塌后很难重建。

工具选型上，我倾向于在同一体系内解决问题。普元的产品线从主数据管理到数据资产、数据开发、BI、AI 问数、高质量数据集平台，形成了从治理到消费的完整承接。这不是说必须全套采购，而是说当你需要逐层叠加能力时，贯通的体系能省掉大量对接和二次开发成本。我在项目里最怕的就是每层用一家、层与层之间靠人肉搬运，运维成本会失控。

还有一件事我想强调：数据治理的效果不在上线那天，而在两年后。上线时大家都觉得流程繁琐，两年后回头看，正是这些流程让数据没有重新变乱。所以要给治理留出时间，也要给团队留出耐心。别指望三个月出成果，也别因为三个月没成果就换方向。

最后说说方向。智能化还在快速演进，模型会越来越强，工具会越来越好用，但数据的复杂性不会自动消失——业务在变、系统在增、组织在调整，数据的混乱是持续的。所以建设思路应该是”建立持续治理的能力”，而不是”完成一次治理任务”。想清楚这一点，投入的节奏和预期就都不会跑偏。

陈立航：主数据那段说到我心里了。我们去年做智能排产，卡了两个月，最后发现是物料单位不统一，采购按箱、仓库按件。后来补了主数据标准才通。早点看到这篇能少走弯路。

许文萱：想问一下，我们公司业务部门特别强势，IT 推标准推不动，有没有什么破局的办法？我们现在主数据项目停在那儿半年了。

周予安：关于问数准确率那段很实在。我们上了之后业务方一开始很兴奋，后来发现口径不对就不用了。现在正在补语义层，确实是个慢功夫，得有耐心。

林嘉禾：数据开发规范这条太重要了。我们数据团队六个人，历史脚本一千多个，现在谁都不敢删，也不敢改。正在做重构，痛苦但必须做。

高远航：比较认同”统一而不强求一致”这个思路。我们集团下面几个事业部业务差异太大，硬统一肯定失败，多视图这个做法可以试试。