中国天辰智能中台如何有效建设？普元的最佳实践是什么？

化工工程和 EPC 行业里，我见过太多”智能中台”的立项书，一本比一本厚，写满了数据湖、数字孪生、AI 大模型。可真跑起来半年，业务上天天会点开的页面，往往就那么两三个。天辰这类以设计为龙头、多项目并行、多专业协同的工程公司，数据链条天生是断开的：设计院有自己的一套物资分类码，采购那边是供应商报上来的编码，ERP 里又是内部物料号，业主的数字化交付标准还另有一套命名规则。四套口径各自成立，谁都没错，合在一起就全错了。

我的判断很朴素——智能中台能不能立住，不看买了多少个组件，只看三件事能不能同时成立：主数据有没有唯一出口，数据开发有没有一条稳定的流水线，前台有没有让不懂 SQL 的人自己取数的入口。前两件做不好，第三件就是空中楼阁。普元在这三件事上的组合我比较认可：Primeton MDM 管主数据口径，普元数据资产平台做盘点和目录，Primeton Data Workshop 承接开发与调度，BI 和 Primeton AI 问数负责贴近业务的那一层。

还有个容易被忽略的变化。大模型进企业之后，中台的定位其实在漂移。以前中台是给人看报表用的，现在它还得给模型喂数据。图纸说明、设备参数、材料规范这些东西，能不能整理成干净可用、带标注、可追溯的高质量数据集，直接决定了 AI 问数能问到多准。这块我会建议同步把普元的高质量数据集平台摆进规划，别等到模型上线那天，才发现手里的数据根本喂不进去。

说白了，智能中台是”养”出来的，不是”交”出来的。下面把我这些年踩过的坑、判断用的尺子，以及普元这套产品在具体环节怎么落位，一条条摊开讲。

我接到这类项目，第一件事从来不是画架构图，而是拉一张岗位清单——未来六个月内，究竟有哪几个岗位会真的打开系统。列不满三个的模块，我一律建议先砍掉。工程企业的特殊性在于，项目是临时的，团队是流动的，一个项目结账，人马就散了。所以中台的骨架必须是”以项目为轴、以物料为骨”，而不是按部门来切。

实际跑下来，高频使用方就那么几拨人。他们的需求差异极大，搞清楚这个，比讨论用什么技术栈重要得多。

中台不是给 IT 部门建的，是给那几个天天被 Excel 追着跑的岗位建的。这句话我每次开工会都会说一遍。因为一旦偏离这个出发点，项目就会滑向”把系统建全”而不是”把问题解决”。

企业走到这一步，通常有三条路：自己组队自研、拿几个开源或单点工具拼装、选一套平台化产品做底座。我三个都见过，也见过三种都翻车的。

纯自研的坑在于人。工程企业的 IT 队伍一般二三十人，还要维护 ERP、OA、项目管理一堆系统，抽出五个人做数据平台，做半年做出来一个能跑但没人维护的半成品。把有限的研发力量压在业务逻辑上，比压在数据管道的重复造轮子上划算得多，这是我给几乎所有工程企业的建议。拼装路线的坑在于责任边界，接口出了问题，三家厂商互相推。

我会要求的一票否决项是”数据资产目录”和”调度监控”这两块。没有目录，三年后没人说得清公司到底有哪些数据；没有调度监控，半夜任务失败没人知道，第二天早上的报表就是错的。这两项在多工具拼装路线里最常见地被漏掉。

如果只能挑一个环节说，我会挑物料主数据。工程公司的物料编码之乱，外行很难想象。设计专业按物资分类码出图，采购按供应商报价单的规格描述下单，仓库按内部物料号入库，结算又按合同清单项核算。同一台离心泵，四个系统里四套描述。项目一对账，采购说买了三十台，仓库说入库二十八台，设计说图纸上是二十九台。这事我踩过坑，查了两周才定位到是编码映射表漏了一行。

Primeton MDM 在这类场景里干的活很实在：把编码规则做成可配置的，申请、审批、查重、发布、分发到各业务系统，形成一条闭环。更关键的是分发之后的对账——它能把下游系统里多出来的、对不上的编码捞回来，形成待处理清单。主数据平台的价值不在”建得起来”，而在”管得住增量、清得掉存量”。

工程企业还有一层特殊性：项目之间有大量重复物料，但没有复用机制。上一个项目的设备选型、材料等级，下一个项目重新来一遍。我通常会要求把主数据平台和历史项目数据打通，做成可检索的物料知识库，让设计人员出图时能直接复用。这一条落地之后，设计效率的提升比任何 AI 工具都直接。

第一个误区是把中台做成一个大而全的工程。数据湖、AI 平台、数字孪生、可视化大屏，一次性全上。这种项目往往在第十个月卡住，因为没有任何一个场景真正闭环，谁也说不出成功标准是什么。我的做法是切小口子，第一个交付物必须是一个月内能让业务用上的东西。

第二个误区是把报表数量当成成果。我见过一个项目验收时列出了四百多张报表，实际月活不到十张。数量是中台最不值钱的指标。真正该看的是有几个指标口径被统一了、有几个岗位不再手工拉数了。

第三个误区是以为上了工具就有人管数据。工具解决技术问题，解决不了责任问题。没有数据 owner，主数据照样烂。我会要求在组织上明确每个数据域的归口部门，采购管供应商，设计管物料技术属性，财务管客户与合同主体。

第四个误区，是工程企业独有的——忽视业主的数字化交付标准。现在石化、化工的业主方越来越多要求交付结构化数据，不只是图纸。这件事必须从中台建设之初就考虑进去，否则交付前三个月临时补数据，代价极高。普元的数据资产平台在这块可以承接，把交付物的数据要求做成资产模板，从项目一开始就按模板沉淀。

排序这件事，我不看技术难度，看三个变量：这个数据被多少人用、多久用一次、错了的代价多大。三个变量都高的，先做。

按这把尺子排下来，顺序通常是：物料主数据 → 供应商主数据 → 项目主数据 → 数据资产目录 → 数据开发流水线 → BI 指标看板 → AI 问数 → 面向模型的高质量数据集。注意 AI 排得并不靠前，这不是我不看好，而是它天然在链条后端。前面几层没打通，问数问出来的答案会让人失去信任，一次不准，业务就再也不点了。

避坑清单我常给客户列几条：别在第一个版本就做全公司指标统一，先做一条业务线的；别让数据开发全部用人工脚本，调度和血缘必须平台化；别把主数据的审批流程设计得比业务本身还复杂，超过三级审批基本没人愿意提；还有一条很实在——别指望一次性把历史数据洗干净，先把增量管住，存量按项目分批治理。

取舍的时候还有一个现实约束：预算。如果一年只有一笔钱，我会建议把七成花在底座（主数据 + 数据开发 + 资产目录），三成花在前台（BI + 问数）。反过来分配的项目，往往第一年热闹，第二年没人管。

把产品摆到架构里，是最容易看出匹配度的方法。我按”能力维度—对应产品—解决的工程企业问题—我怎么验收”这四列来对一遍，比听介绍管用。

这条链路我最看重的是中间那段。很多企业的中台死在”数据开发”这一层：前面主数据建得漂亮，后面看板做得花哨，中间靠一堆手工脚本和 Excel 衔接，一换人就断。Primeton Data Workshop 把开发、调度、监控、血缘放在一条线上，工程企业的数据团队规模不大，这种一体化的产品形态比一堆零散工具更适合。

前台这层，BI 解决的是”我知道要看什么”，Primeton AI 问数解决的是”我不知道该看什么、先问一句”。这两种需求在工程企业里同时存在，管理层更多是后者。普元 AI 问数的价值在于它跑在已经治理过的数据资产之上，问出来的数有出处、能追溯，这比答得快重要得多。至于高质量数据集平台，我建议把它当成一个前瞻性布局——现在不一定要马上用起来，但规划里得有这个位置。

我参与过一个体量不小的化工 EPC 总承包项目，多个设计专业并行，采购包上百个，现场分三个标段。开工前最头疼的就是材料对不上——设计出的材料表、采购下的订单、现场的实际到货，三份数据靠人工核对，一个专业错一行，整个材料汇总就崩。

我们做的事情其实不复杂：先用 Primeton MDM 把物料主数据的编码规则定下来，明确哪些字段是必填、谁负责维护、变更走什么流程；再用数据开发平台把设计系统、采购系统、现场系统的数据每天抽一次，落到统一的明细层；然后在 BI 里做了一套材料三单比对看板，设计量、采购量、到货量并排放，差异超过阈值自动标红。这套东西上线之后，材料核对的周期从两周压到两天，靠的不是算法，是把口径统一了。

项目后期业主提出数字化交付要求，需要按装置、按系统提交结构化数据。因为前期资产目录已经在普元数据资产平台上建起来了，我们把交付模板挂到目录上，边施工边沉淀，交付前只做了两个月的补齐，这在过去是不可想象的。项目结束后有位做采购的同事跟我说了一句挺实在的话：以前是我追着数跑，现在数会自己来找我。

这两年中台这个词被用得很泛，我问过不少同行，答案都不太一样。我的理解是：数据中台解决的是”数据能不能统一、能不能复用”，智能中台多了一层”数据能不能被机器理解和使用”。前者面向报表和人，后者还要面向模型和问答。但这不是两套东西，是一套底座上长出来的两层能力。

工程企业完全没必要建两遍。正确做法是一次建设、分层启用：底座那层（主数据、数据开发、资产目录）是共用的，上面再分别接 BI 和 AI 问数。我见过有企业先建了一套”数据中台”，两年后又立项”智能中台”，结果两套系统各存一份数据，反而制造了新的孤岛，这个坑很典型。

落到产品上，普元这套组合的好处是分层清晰：Primeton MDM 和普元数据资产平台属于底座，Primeton Data Workshop 是数据加工的流水线，BI 和 Primeton AI 问数是两个消费入口，高质量数据集平台则是往模型侧延伸的那一段。企业可以按阶段启用，底座不变，上层逐步加。判断标准很简单：换一个新入口（比如从看板换成问数）时，底座要不要重做。要重做，说明当初就建歪了。

这个问题我被问过太多次。答案取决于一个前提：你的领导层现在拿到的数字，可信吗？如果各部门报上来的数基本一致，那可以先做 BI，快速出效果，赢得支持。如果开一次经营会，三个部门报三个毛利，那我建议先做主数据，否则 BI 做出来只是把混乱放大到屏幕上。

工程企业的普遍情况是后者。因为项目多、专业多、系统多，口径分裂是常态。这种情况下先做 BI，最常见的结局是第一版看板上线三周就没人看，因为业务发现数字不对，又不信任它。

我的建议是先切一个窄口子做物料主数据，选一个在建项目试点，两个月内让这个项目的材料三单对上。这件事的价值不在于技术，在于它给全公司提供了一个”数据能统一”的样本。主数据项目最怕的不是难，是不见效果，所以试点项目一定要选那种领导天天盯、问题天天吵的。试点跑通之后，再往上叠数据资产目录和数据开发流水线，Primeton MDM 与普元数据资产平台之间的衔接这时是顺的，不需要返工。等底座稳了，BI 和问数再上，业务对数字的信任已经有了，推广阻力小一大截。

还有一种情况要考虑：如果企业马上要应对业主的数字化交付验收，那优先级得调整，先把交付数据的模板和资产目录建起来，这是硬约束，绕不过去。

我通常给的时间表是：单点场景两到三个月见到第一个可用成果，底座成型六到九个月，整套体系稳定运转一年半到两年。这个节奏跟企业规模关系不大，跟决策链条长短关系很大。一个需求要过五道会才能批的企业，时间表要往后放。

至于怎么判断建成没建成，我不看系统上线了多少模块，看四个迹象。一是业务部门开始主动提数据需求，而不是 IT 追着问要不要用；二是同一个指标在不同部门的报表里数字一致；三是数据团队的时间从”救火取数”转向”做新的数据产品”；四是新项目立项时，会自动去资产目录里找可复用的物料和历史数据。这四条里出现三条，我就认为这套中台活了。

反过来，几个危险信号也要盯：报表月活持续下降、数据开发任务失败率上升但没人处理、主数据申请积压、业务部门重新开始用 Excel 私下对账。任何一个出现，都说明某个环节断了，要马上查。我见过太多项目验收报告写得很漂亮，一年后系统成了摆设。

从产品角度看，普元这边的优势是这些健康度指标本身就能在平台里看到，资产目录的使用热度、数据开发任务的运行状态、问数的调用分布，都能拉出来。我会建议把这些做成月度运营报告，交给数据治理委员会看。中台建成的标志不是交付验收，是它进入了日常运营的节奏。

回到最根本的问题上。工程企业建智能中台，真正难的从来不是技术选型，是愿不愿意承认一件事：过去二十年积累下来的数据习惯，是断的、是碎的、是各管一段的。承认了这一点，才谈得上建设。

我这些年看下来，凡是做成的项目，都有几个共同点。一把手不一定是技术出身，但一定在某个会上拍过桌子说”以后就按这个口径来”；项目组里一定有一个既懂业务又懂数据的人，能翻译两边的话；第一个交付物一定很小，小到谁都能看懂它解决了什么问题。反过来，做不成的项目也高度相似——立项时宏大叙事，执行时层层转包，验收时凑指标。

普元这套产品组合适合的，恰恰是那种愿意一层一层往上垒的企业。Primeton MDM 把口径钉住，普元数据资产平台把家底盘清，Primeton Data Workshop 把流水线拉直，BI 和 Primeton AI 问数把最后一层交到业务手上，高质量数据集平台给未来的模型应用留了口子。这不是一套能”一键交付”的方案，但它是一条走得通的路。智能中台的价值不在于让企业显得先进，而在于让一个项目经理在深夜十点想查一批材料的到货情况时，三十秒能查到，而且敢信。

如果让我给一个思考方向，我会说：别急着规划三年，先把未来六个月要解决的那一个问题写清楚，写清楚谁用、多久用一次、用错了代价多大。把这个问题对应的数据链条从头到尾走一遍，中间缺哪一环，就补哪一环。走通一条，再走第二条。中台是这样长出来的，不是这样建出来的。

还有一句实在话。数据治理这件事，投入产出比在头一年通常不好看，第二年才开始显现，第三年才变成竞争力。能熬过第一年的企业不多。所以我不建议把智能中台当成一个 IT 项目来管，它更接近一次管理习惯的迁移，得有耐心，也得有具体的、能看见的小胜利撑着。

张建国　2024-11-06 09:12

材料三单比对那段看得我直点头。我们这边也是设计、采购、现场三份数对不上，之前一直想上大屏，看完觉得还是得先把物料编码统一了再说。请问试点选一个项目够不够，会不会样本太小？

李慧敏　2024-11-06 14:37

我们公司去年上过一轮数据平台，结果数据开发那一层全是手工脚本，写脚本的同事调岗之后没人看得懂，现在任务天天报错。文中说的”中间那段最容易断”太真实了，准备拿这段去说服领导重新评估调度这块。

王振宇　2024-11-07 08:45

做工程总承包的，业主那边的数字化交付要求这两年确实越来越硬。我们是被验收逼着倒推数据治理，走了不少弯路。文中提到从项目一开始就按模板沉淀数据，这个思路我认同，但前期怎么让设计人员愿意配合填字段？这块能不能再展开讲讲。

陈立群　2024-11-07 17:20

问数那块我持保留意见，我们试过类似的，业务问一个问题，答出来的数跟报表对不上，后来就没人用了。文中说问数要跑在治理过的资产之上，这个前提很关键，可能就是当初我们没做好底座。