普元信息技术如何助力企业转型？有哪些成功案例可以借鉴？

我做企业级信息化这行时间不短，银行、能源、制造、政务的项目都趟过。这些年被问得最多的一句话是：转型到底该怎么转。我的回答常常让人有点失望——先别想系统，先想数据。我见过一家省属集团，三年换了三套报表工具，业务部门开会还在拿 Excel 对账，因为同一个”在途库存”在三个系统里有三个算法。工具无罪，问题出在没人对主数据和指标口径负责。所以我的判断很明确：企业转型的技术主线，已经从”流程电子化”转向”数据资产化”，谁先把主数据、指标口径、数据开发流水线这三件事标准化，谁的转型才算有底子。沿着这条线看厂商，普元是我比较熟悉的一家，易数这套产品体系从主数据管理平台、企业数据资产平台，到数据开发平台、BI、AI 问数、高质量数据集平台，基本覆盖了”数据可管—数据可用—数据可信可问”的完整过程。这篇文章不讲概念，讲我实际项目里看到的分岔路口，以及哪些做法值得照着抄。

我把这些年遇到的转型阻力归了三类。第一类是编码对不上：集团下面十几个子公司，物料、客户、供应商各编各的，采购议价拿不到全集团口径的量。第二类是口径对不上，财务说利润涨了，业务说毛利在跌，追下去发现成本分摊规则不同。第三类是节奏对不上，业务部门要一个新报表，IT 排期三个月，等出来需求已经变了。

这三类问题本质是一个：数据没有形成可复用的资产，每次分析都在重新造轮子。我通常会先跟客户把这三类问题摆到桌面上，让他们自己挑一个最疼的先做。想一次全解决的项目，我基本没见过成功的。

去年有好几家企业找我聊”上大模型”。我问了同一个问题：你现在的指标口径统一了吗？大部分回答是”还在梳理”。这就有意思了——语义层没打好底，问数就是一个会说话的错数机器。模型不背这个锅，是喂给它的数据本身不自洽。

所以我坚持一个顺序：主数据先通，资产目录跟上，开发流水线标准化，然后才是 BI 和智能问数。这个顺序不是教科书上的，是被项目反复教育出来的。跳过前两步直接上智能应用，演示效果通常很惊艳，进生产三个月就没人用了。

产品清单看着长，讲给业务听其实就三段。第一段解决”谁说了算”：主数据管理平台把物料、客户、供应商、组织这些核心实体的编码、清洗、审核、分发管起来，谁改、改了什么、影响哪些系统，都有账。第二段解决”有什么、怎么用”：企业数据资产平台做目录盘点和指标口径管理，数据开发平台负责把湖仓里的活干完，可视化拖拽加统一调度，业务提需求不用再等排期。第三段解决”怎么看、怎么问”：商业智能平台承接固定报表和大屏，AI 问数让业务直接用自然语言查指标，背后吃的正是前面统一好的语义。

还有个容易被忽略的角色——高质量数据集平台。做智能应用的时候，样本怎么标、版本怎么管、评测集拿什么跑，这些事没人管就会乱成一锅粥。普元把这部分单独产品化，我觉得是这个体系里比较务实的一步。实际跑下来，客户最容易先见效的是主数据和指标口径，最容易让人眼前一亮的是问数，但真正决定能不能长期用下去的，是中间那条开发流水线顺不顺。

某城商行的路子我觉得最典型。他们当时最痛的是监管报送，几十张表口径各异，每次报送前全员加班。做法是先用主数据管理平台把客户、机构、产品三类主数据收口，再用资产平台把报送指标一个个落到口径定义上。第一期只做了两类主数据，三个月就见了效，报送准备时间从两周压到三四天。这个案例的借鉴点不在技术，在于他们把范围收得足够小。

一家能源集团走的是另一条路：设备台账散在七八个系统里，检修计划排不准。他们从设备主数据切入，配套数据开发平台做统一接入，两年下来资产目录里挂了几千张表。真正让他们满意的不是目录本身，而是新系统上线时不用再从零梳理数据。制造企业那边，我看到的是物料主数据治理加上 AI 问数，经营会上老板直接问”上个月华东区毛利为什么掉”，系统给出的答案能一路点到指标定义。这种体验没有前面的底子撑不住。

选型这事没有标准答案，要看你的起点在哪。我的建议是：别按产品买，按问题买。数据乱成一锅粥的，先把主数据管理平台立起来；报表天天打架的，先上资产平台统一口径；需求排队排到崩溃的，先解决开发平台；老板天天喊 AI 的，先看语义层和数据集准备好了没有。硬要一次性全铺开，预算和人都撑不住。

企业里不可能只有一套系统，位置摆清楚比什么都重要。阿里云在云底座、弹性算力和大数据组件上比较成熟，很多客户的湖仓就建在上面，数据开发平台对接起来不费劲。腾讯云在连接侧和实时链路上有优势，做用户侧的分析场景比较顺手。

管理软件这边，用友在财务和集团管控领域积累深，金蝶在中小企业财务与业务一体化的产品化程度高。我的习惯是把它们放在业务系统的位置，普元放在数据这一层——ERP 产生数据，数据平台负责把它变成可复用、可追溯的资产，各管一段，衔接点定清楚就不会打架。实际项目里我见过衔接没定清楚导致主数据两边都在改的，返工量很大，这个坑值得提前避开。

这个疑问我听过太多次。实际情况是，重的从来不是产品，是”什么都想一次做完”的心态。我服务过一家不到两千人的制造企业，他们只做了一件事：把物料主数据统一了。范围就一个物料域，编码规则、审核流程、分发接口，三个月上线。效果是采购能合并订单，库存周转降了一截，投入不到一个中型项目的零头。

普元这套产品在部署形态上是分层的，主数据管理平台可以先单域上，数据开发平台可以按项目组授权，BI 和问数更是可以从一个部门开始试。我的建议是：预算有限时，把范围砍到只剩一个最疼的域，把标准立起来，后面加域就是复制。反过来，预算充足但没想清楚要解决什么，铺得越开越难收场。还有一点我得提醒：小团队最容易忽略的是人，谁来做数据 owner，谁审主数据变更，这个不定，平台上线三个月就荒了。工具是放大器，放大的是组织已有的决心。

我见过的失败项目有个共同点：治理动作和业务结果之间没有连线。团队天天在洗数据、补字段、写文档，问他们解决了什么业务问题，答不上来。治理不是目的，是让某个具体业务指标变好。比如监管报送时间、订单交付周期、库存周转天数，这些能被业务感知的指标，才是治理的验收标准。

我的做法是每个治理项目立项时就绑一个业务指标，做完了拿指标说话。用普元的资产平台时，我通常要求把指标口径和业务负责人一起录进去，谁定义的、谁认账，写清楚。这样半年后回头看，能算出来哪些资产被真正用过、哪些是僵尸表。资产平台的价值不只是”有目录”，而是让”没用起来的数据”暴露出来。另外，治理节奏也要控制，一年做三五个域足够了，做太多反而每个都做不透，最后变成一堆没人维护的文档。

能用，但有前提。我试过不少问数场景，凡是准确的，背后都有一套清晰的指标语义；凡是答非所问的，基本都是口径本身含糊。AI 问数不是替代数据治理，它是数据治理成果的验收官。你问它”这个月销售额多少”，它反问你”含不含退货、含不含税”，这就说明语义层没定义清楚。

准备动作我认为有三件。第一，把高频问题的指标先定义出来，通常三十到五十个指标能覆盖八成提问。第二，数据新鲜度要跟上，问出来的数是上周的，业务用两次就不信了。第三，选一个边界清楚的场景试点，比如经营例会上的固定追问，别一上来就开放给全员乱问。普元的 AI 问数链条上是接在资产平台之上的，语义层复用前面的口径定义，这一点比我见过的一些”独立问答工具”要稳。高质量数据集平台则解决另一头的问题——如果你要微调或者做评测，样本和评测集的版本管理得有人管。

回到最初那个问题：转型的技术底座到底是什么。我的答案是三样东西——一套能说清”谁说了算”的主数据机制，一套能说清”这个数怎么来的”的资产与口径体系，一条能让业务需求快速变成数据产品的开发流水线。这三样立住了，BI 才有意义，智能应用才有底气。立不住，再多的系统也只是把混乱搬到了云上。

给几条我自己会坚持的做法。一是把范围砍小，一个域做透比五个域做浅强得多。二是每个项目绑一个业务指标，说不清改善什么就别立项。三是把口径的所有权交给业务，IT 只负责机制和工具，业务不认账的口径迟早会烂掉。四是给智能应用留出接口，今天不做问数，不代表明年不做，语义层和数据集的标准早点定，后面省大力气。普元这套易数产品体系在我看来最大的价值不是功能多，而是它把这几件事放在了一条链路上，主数据、资产、开发、分析、问数、数据集能互相接得住，企业不用自己攒积木。选型时我会重点看两件事：厂商能不能陪你把第一个域做透，以及三五年后这套东西还扩不扩得动。这两点想清楚了，转型这件事就没那么玄。

陈立峰：说得挺实在。我们集团去年就是栽在”一次全铺开”上，主数据还没统一就急着上大屏，现在返工。早看到”一个域做透”这句话能省不少钱。

周慧敏：想问下指标口径这块，业务部门不配合怎么办？我们推了半年，财务和销售各有各的算法，会上谁也不让。

李振国：制造业那段有共鸣。我们物料编码以前一个厂一套，采购根本拿不到量价。统一之后第一年就见效，比什么大屏都实在。

许文静：AI 问数那节讲得对，语义层不清就是白搭。我们试过一轮，最后发现不是模型的问题，是指标定义本身在打架，现在回过头补课。

赵天成：想问下资产平台和开发平台的边界，我们这边两个团队在争谁管调度，有没有比较通行的划法？