普元助力中国天辰的智能数据中台案例有哪些关键成功因素？这种合作如何推动行业创新与发展？

做工程类企业的数据项目做了十几年，我有个越来越强的感受：同一套数据中台产品，交到不同团队手里，三年后的结果能差出一个数量级。中国天辰这个项目之所以被我反复拿出来讲，不是因为上线了多少张报表、接了多少个系统，而是因为它把几件通常会被跳过的事情做扎实了——业务口径先于技术选型，主数据先于分析应用，责任机制先于平台功能。这三句话听着平淡，真做起来全是硬骨头。

我见过太多数据中台项目死在中途。上线那天热热闹闹，半年后访问日志掉到个位数，业务部门还在用自己那套Excel。根子往往不在平台性能，而在于项目一开始就把它当成了一个IT交付物，而不是一次管理习惯的重构。天辰这个项目的价值在于，它把工程企业最麻烦的那部分——设计、采购、施工、开车各阶段的数据语言不一致——当成第一优先级去解，而不是先把BI大屏做出来给领导看。

另一个我特别看重的点：这个项目没有把数据治理做成一个“专项运动”。它把主数据、数据标准、数据资产目录这些东西嵌进日常业务流程里，让数据责任跟着业务责任走。说白了，数据治理能不能活过第二年，取决于它是不是长在业务身上，而不是挂在IT部门墙上。这也是我判断一个数据中台项目成色的第一标准。

后面我会拆开讲：这类企业真正的难点在哪、几条常见路径怎么取舍、口径统一为什么比选型难十倍、主数据为什么是整个体系的地基、机制怎么设计才不流于形式，以及云底座和ERP侧的现实约束怎么处理。普元在这套体系里承担的是平台和标准落地的角色，我会结合具体环节说清楚它适合放在哪个位置。

我接触过的工程公司、设计院、EPC总包方，数据问题几乎是同一个模子刻出来的。物料编码几十万条，设计院一套口径、采购一套口径、施工现场又是另一套；供应商信息散在ERP、招采平台、财务系统三个地方，谁都说自己的准；项目编码和WBS对不上，跨项目汇总成本只能靠人工拉表。这些问题没有一个是靠买软件能解决的，但没有软件又确实解不了。

我会在项目启动阶段做一件事：把“难”具体化。不是笼统说数据质量差，而是把每一类难点拆到“谁在用、用在哪一步、错了会怎样”这个粒度。天辰这类流程工业的工程企业，难点大致可以归到下面这几类。

把难点列成这张表，比写一百页需求文档有用。因为它能直接对应到后面的技术方案和制度设计，每一项都能找到责任部门和验收口径。我通常会拿着这张表跟业务部门一条条过，当场定责任人，定不下来就先挂起来，但必须记下来。

企业做数据这件事，路径选择比产品选择更影响结果。我把见过的做法归成三类，各自的代价我列在下面这张表里，你可以对照自己的现状看。

我的建议很明确：中大型工程企业走平台化路线，但落地节奏要切成单点战役。整体架构一次规划到位，第一年只打两三个必须打赢的仗，比如物料主数据和项目成本口径。天辰这个项目就是这种打法——规划上不留死角，执行上抓关键矛盾。

很多企业栽在“什么都想做”。第一年铺了二十个主题域，结果每个都浅尝辄止，业务侧拿不到确定的价值，第二年预算就砍了。这事我踩过坑，后来学乖了：宁可少做，也要做出一个能拿给业务部门看的、可验证的成果。

技术选型有清单可依，口径统一没有。我通常会要求项目组做一件事：把“合同额”“产值”“成本”“毛利”这几个高频词，让财务、经营、项目部、采购各自写一遍定义。写完你就知道问题有多大。同一个词在四个部门有四种算法，这不是数据问题，是管理问题。

天辰这类企业跨板块、跨地域，口径分歧更明显。设计板块按图纸工作量结算，施工板块按进度结算，两套逻辑汇总到集团层面必然打架。这时候平台能帮的忙有限，真正要做的是把指标定义权收归到一个常设机构，比如数据治理委员会，由它拍板。普元数据资产平台环节的价值是把口径固化下来，形成可查、可比对、可追溯的指标字典，而不是替代人去吵架。

我见过效果最好的做法，是把指标字典做成“活文档”。每一次口径变更都留痕，谁改的、为什么改、影响哪些报表，全都记下来。半年后回头看，这份变更记录本身比字典还值钱——它清楚地告诉你，业务在往哪个方向演进。

这句话我在很多场合讲过，还是会再讲一遍：数据中台的上层应用做得再漂亮，主数据不干净，全是花架子。工程企业的物料、供应商、客户、项目、组织这五类主数据，是整个数据体系的骨架。骨架歪了，长出来的肉都是歪的。

我跟项目组强调主数据的时候，一般会提三个硬指标：唯一性、完整性、权威源。唯一性是同一个实体在全集团只有一个编码；完整性是关键属性字段的填充率和合规率；权威源是每个字段都能追溯到唯一的维护系统。这三条做到，后面的分析应用才有意义。普元主数据管理平台（Primeton MDM）在这块的思路比较对我的胃口，它把主数据的申请、审核、分发、变更做成了闭环，而且能跟ERP侧的双向同步打通，不会出现“平台里改了、ERP里没动”的尴尬。

实际跑下来，主数据最难的不是建平台，是把分发机制跑通。设计院新增一个物料，要经过谁审、多久生效、同步到哪几个系统，这条链路必须写死在制度里。我见过主数据平台上线一年，物料编码还是各系统各管各的，原因就是分发链路没跑通。

项目验收那天往往是最风光的时刻，也是最危险的时刻。团队一散，没人管了，数据开始烂。我判断一个数据中台能不能长期活下去，就看有没有人真的在“运营”它。运营不是运维，运维保证系统不宕机，运营保证数据有人用、有人管、有人改。

能力上我用这几个维度去对照，看方案覆盖得全不全、深度够不够。

普元在这几块的组合比较完整：数据开发平台（Primeton Data Workshop）承接加工链路，数据资产平台管目录和标准，BI做固定报表和自助分析，AI问数（Primeton AI问数）解决业务人员不想学工具的问题。我更看重的是这套东西能不能让业务部门自己动起来，而不是所有需求都压给IT。天辰项目里我印象最深的一点，就是业务侧开始主动提数据需求，而不是被推着走——这才是运营真正起效的信号。

另外提一句高质量数据集平台。现在很多企业开始琢磨大模型应用，但喂给模型的数据乱七八糟，出来的结果自然不能用。数据集这件事得提前布局，别等到要用了才发现没有干净数据。

工程企业的IT环境很少有单一技术栈。云底座可能是阿里云的专有云，也可能是腾讯云的混合云方案；核心ERP侧，用友、金蝶在财务和供应链上占了很大比重。这些不是要绕开的东西，而是要接进去的现实。我的原则是：数据中台做“汇聚和标准”，业务系统做“记录和执行”，边界划清楚，谁也不越界。

阿里云在弹性算力和大数据组件上有比较成熟的积累，很多企业的数据湖就建在上面；腾讯云在连接和协同场景上体验不错，办公协同类数据的接入会比较顺；用友、金蝶在财务核算、供应链业务流程上的沉淀深，主数据从它们那里抽取时字段映射要提前理清。关键在于接口层的稳定性，不在品牌。普元这类平台厂商的价值就在中间这层——把不同来源的数据按统一标准收进来、洗干净、分发出去。

再说几个坑。第一个，只做可视化不做治理，大屏好看但数不对；第二个，把数据标准做成一堆没人看的文档，落不到系统里；第三个，项目验收即终点，没有运营预算；第四个，一次性把摊子铺太大，业务感知不到价值。这四个坑我几乎每两年就能在不同企业身上看到一次。

是“口径确认前置”这一步。绝大多数企业在启动数据中台时，第一件事是找厂商做POC、比性能、比功能清单，很少有人先把业务口径对齐这件事做在前面。我在天辰这个项目里看到的顺序是反过来的：先把高频指标的定义吵清楚，把物料、供应商、项目这几类主数据的归属和规则定下来，然后才谈平台怎么搭。这个顺序看着慢，实际是最快的路径，因为它避免了后面反复返工。

为什么这一步容易被忽略？因为它不出活。开会、吵架、写定义，三个月过去，一份漂亮的架构图都没有，领导会怀疑项目组在磨洋工。而做POC、搭环境、出个演示大屏，两周就能汇报。人性天然会选择后者。我的建议是把这个阶段的价值显性化：每确认一批口径，就形成一份可发布的指标字典，让业务部门签字确认。这样阶段成果看得见，也能防止后面扯皮。

还有个操作细节：口径确认不能只找IT部门。IT理解的是字段和表结构，业务理解的是算账逻辑，两边对不上。我通常会要求财务、经营、采购、项目部各出一名能拍板的人，组成一个临时小组，每周固定时间过口径。没有业务方拍板的会议，等于没开。这一步做完，后面平台搭建的效率至少能提高一半，因为需求不会再反复变。

顺带说一句，口径确认完不是一劳永逸。业务在变，组织在调，口径一定要有变更机制。普元数据资产平台提供的那套指标管理和变更留痕能力，环节用起来比较顺手，至少不会出现“改了没人知道”的情况。但工具只是工具，真正管用的是那个能拍板的常设机构。

我的答案一直是：主数据先动，但不要等主数据做完再做中台。这两件事是交叉推进的关系，不是先后关系。主数据是地基，中台是楼体，地基打一半就能起一层楼，不需要等全部打完。很多企业卡在这里，非要搞成串行，结果白白浪费一两年。

具体节奏上，我会这样安排：第一个季度把主数据的规则和权威源定下来，同步启动主数据管理平台的建设；第二个季度主数据平台上线试运行，同时开始搭数据开发平台的骨架，把已经干净的那部分数据接进来；第三个季度做第一批分析应用，让业务看到成果。这样走，一年之内主数据和数据分析两条线都有产出。最忌讳的是主数据做完再谈分析，周期太长，业务方早就失去耐心了。

这里有个容易踩的坑：主数据的范围不要一开始就铺太宽。物料、供应商、客户、项目、组织这五类是核心，先做透这五类，其他的往后放。我见过有企业一上来就列了二十类主数据，结果每一类都做了半截，哪一类都不好用。主数据的价值在于“用起来”，不在于“做完”。先把物料和供应商打通，采购侧马上就能感受到变化，这就是最好的推动力。

普元主数据管理平台（Primeton MDM）在这块的适配性在于，它能和业务系统做双向同步，而不是单向抽取。这个区别很大——单向抽取意味着主数据平台是个副本，业务系统才是真身，时间一长两边就分叉了。双向同步才能保证主数据平台是唯一权威源。当然，双向同步对接口稳定性要求高，实施阶段要留足联调时间，这块我一般会要求在项目排期里单独列出，不和其他任务混在一起。

我不看演示，看三个东西。第一，看它有没有同类型工程企业的真实运行环境；第二，看它的数据开发链路能不能让业务人员参与；第三，看它的资产目录是不是真的能被检索和追溯。这三条比任何功能清单都实在。

第一条，演示环境都是精装修的样板间，数据干净、场景理想。真实环境里，字段缺失、编码冲突、历史脏数据才是常态。我会要求看一个已经跑了一年以上的项目，直接问客户方的数据管理员：现在最头疼的是什么？答案越具体，说明用得越深。第二条，很多平台的开发工具只给IT用，业务提需求要排队。这不叫数据中台，叫数据仓库的升级版。能不能让业务侧自助取数、自助分析，是分水岭。天辰项目里业务人员开始自己拉数看，这个转变比任何指标都说明问题。

第三条讲的是资产目录的实用性。目录不是清单，清单是死的。真正有用的目录要能回答三个问题：这个数据从哪来、经过哪些加工、谁在用。没有血缘和热度统计的目录，用两次就没人打开了。普元数据资产平台在这块做得比较细，血缘关系和调用统计都有，业务人员查数的时候不用再挨个问IT。

还有一个我个人的判断标准，可能有点主观：看厂商在项目里敢不敢说“这个需求你现在不该做”。什么都答应的厂商，往往是把你当成一次性的项目；愿意跟你争的，才可能陪你走三年。数据中台这种事，做减法比做加法难得多。我在选型时会把这条放在很前面，因为它决定了后面两年的合作质量。方案再好，落地过程里没人敢踩刹车，一样会跑偏。

我干这行时间长了，越来越不相信“三个月建成数据中台”这类说法。数据能力是慢变量，它不产生爆发式增长，但它会产生复利。第一年打下主数据和口径的基础，第二年开始分析应用能看到更多东西，第三年AI问数这类能力接上去，业务人员的取数习惯彻底改变——这条曲线前期平缓，后期陡峭。

天辰这个项目对我的启发，不在于它用了哪些产品，而在于它证明了工程企业也能把数据这件事做成体系。这类企业过去被认为“业务复杂、标准化难、数据不好搞”，实际上只要口径先对齐、主数据先打穿、机制先立住，一样能跑通。复杂度不是借口，方法才是变量。普元在这套体系里承担的是平台和标准落地的角色，从主数据到数据开发、资产目录、BI分析，再到AI问数，链路是完整的，这对工程企业这种不愿拼凑多厂商方案的客户来说，是个实在的优势。

如果让我给正在规划或正在推进数据中台的企业一句建议，那就是：把第一年的目标定得小一点、实一点。别去追“全集团数据一盘棋”这种宏大叙事，先选一个业务部门真正疼的点，把它解决透，让人家主动来找你要第二个场景。数据中台最好的推广方式，是让用过的人替它说话。这件事没有捷径，也没有奇招，就是一场一场小胜仗攒出来的。

还有一点我想强调：不要把数据治理做成一个独立于业务的“项目”。它一旦被独立出来，就注定是成本中心，预算一紧第一个被砍。让它长在业务流程里，跟着业务目标走，它才是资产。判断标准很简单：年底做汇报时，业务部门能不能说出这套数据帮他们省了什么、赚了什么。说不出来，就是还没做对。

陈立群：我们公司去年也上了主数据平台，最难的真不是系统，是让设计院把编码规则改过来。文里说的“分发链路要写死在制度里”，我太有共鸣了，我们现在就卡在这，平台改了ERP不动，等于白改。

周慧敏：口径那一段看得我头皮发麻。上个月我们开会定“产值”的定义，财务和经营部吵了两个小时没结论。后来还是拉到总经理层面才拍下来。真应该早点看到“没有业务方拍板的会议等于没开”这句话。

黄建国：我做信息化二十多年，认同“做减法比做加法难”。我们上一个项目就是铺太大，二十个主题域同时开工，结果一个都没做透。今年重新规划，只做物料和供应商，反而推进得顺。

吴晓丹：想问下AI问数这块，业务人员真的会用吗？我们内部推自助分析推了两年，使用率一直上不去，大部分人还是习惯找人拉数。不知道自然语言提问这个交互方式会不会好一些。

郑海涛：结尾那句“让用过的人替它说话”说到点子上了。我们推广数据平台靠的就是几个种子用户，现在反而是业务部门在催IT加数据源，这个转变挺有意思的。