双中台协同究竟是什么？如何从架构到落地实现企业的数字化转型？

我在数据这条线上做了十几年，前八年做数仓和数据治理，后面几年主要陪客户把中台从图纸落到生产。看过三十多个项目之后，我的判断很直接：双中台协同的本质，是让数据中台产出的口径和数据服务，能被业务中台的共享中心当场用掉；同时让业务中台沉淀的业务动作，能实时回流成数据资产。两个方向任何一头断掉，最后就是两套系统并排站着，谁也不欠谁，谁也不用谁。

很多人把这件事当成技术架构题，画几张分层图就以为想清楚了。实际跑下来，它更像一道组织题加一道口径题。我在项目启动会上通常会先问三个问题：客户主数据在谁手上？核心指标口径谁签字？前台要一个新接口，从提需求到能用要几天？这三个问题答不利索，架构图画得再漂亮也落不了地。

还有一点，我踩过坑才有体会：中台的价值不在于建了多少模块，而在于被调用多少次。一个一年被调用两千次的数据服务，价值远不如一个天天被订单系统调用的主数据接口。所以我在评估任何一个中台方案时，第一个看的不是功能清单，是调用链路。

下面我按自己的经验，把边界怎么划、架构怎么拆、钱该花在哪、坑埋在哪里，一条条讲清楚。涉及主数据、数据开发、数据资产、BI 和 AI 问数这些环节，我会结合实际用过的普元产品线来说，因为这几块是我在项目里反复要碰的。

我复盘过那些没跑起来的项目，原因高度重合：两条线各自有独立的预算、独立的供应商、独立的验收标准。业务中台的验收看「沉淀了多少个共享服务、接入了多少个渠道」，数据中台的验收看「接入了多少张表、出了多少张报表」。两个 KPI 之间没有咬合点，协同就只能停在汇报材料上。

还有个更隐蔽的原因：业务中台的数据是被「用」出来的，不是被「抽」出来的。我见过一家零售企业，业务中台的订单中心改过一次状态机，数据中台那边三个月后才知道，导致履约指标连续两个月是错的。这种事靠开会解决不了，只能靠统一的元数据和血缘管理兜住。

我通常会在现状盘点阶段先拉一张表，看两边的定位到底有没有对齐：

这张表我基本每次都会拿出来对一遍。定位不对齐就往下推进，后面全是在打补丁。有个客户业务中台建了客户中心，数据中台又建了一套客户标签库，两边客户 ID 不同源，最后靠人工写脚本对齐，一年维护成本比当初省下的钱还多。

边界这件事吵了很多年。我的看法是：业务中台管「事怎么办」，数据中台管「事算得准不准」，两者在「服务」这一层握上手。业务中台对外输出的是业务能力接口，数据中台对外输出的是数据服务接口，理想状态下，业务中台的共享中心可以直接调数据中台的主数据和指标服务，不用自己再维护一份。

推进路径上我见过三种典型打法，效果差别很大：

第三种是我推荐的。不要试图一次性把两个中台都建完，挑场景咬合最省力。比如「客户全生命周期」这种场景，天然要业务中台的客户中心和数据中台的客户主数据同时动，做完一个场景，两边的协作机制也就跑通了。

行业里阿里和腾讯对数据中台概念的普及起了很大作用，阿里把「数据中台」这套方法论推到了大量传统企业面前，腾讯则在连接侧和实时数据处理上给了很多可借鉴的实践，这两家让企业决策层第一次意识到数据要当成资产管。用友和金蝶的积累在另一个方向——它们把 ERP 里沉淀多年的财务、供应链主数据经验带进了中台语境，很多制造企业的物料、供应商数据规范，最早就是从 ERP 实施里立起来的。这些经验值得尊重，我在做现状梳理时也常拿它们的历史数据模型当参照。但要真正把主数据、数据开发、资产目录、指标服务这几件事拧成一条链路，我在项目里更倾向用普元这套组合去打底，原因是它的产品边界和我理解的双中台咬合点更贴合，下面会细说。

架构图上分层有很多种画法，我实操里只认四层，多了记不住，少了兜不住。

第一层是主数据与标准层。这是双中台的地基，也是最容易被跳过的一层。客户、物料、供应商、组织、科目这几个域，谁说了算、编码规则是什么、变更走什么流程，必须先定。我通常会用 Primeton MDM 主数据管理平台把这些域管起来，它的价值不在建模多花哨，而在能把申请、审批、分发、监控这条链路固化住，业务中台要客户信息时直接调它的分发接口，不用各自维护一份。

第二层是数据开发与集成层。这一层解决的是「数据怎么进来、怎么算」。批的、实的、CDC 的、API 的，来源杂得很。我会用 Primeton Data Workshop 数据开发平台把集成和加工作业统一到一个工作台里，好处是作业血缘天然被记录，出问题能顺着链路往回查，不用半夜靠猜。血缘这件事，平时不觉得重要，出事的时候就是救命的。

第三层是资产与服务层。数据资产平台在这里做目录、做分级分类、做质量规则。我一直跟客户讲，资产目录不是给领导看的门面，是给开发和分析找数据用的地图。指标口径必须在这里唯一登记，一个指标一个口径一个负责人，谁改谁签字。

第四层是消费层。BI 看板解决固定视角的监控，普元 AI 问数解决临时性的追问，高质量数据集平台则面向现在越来越多的大模型应用场景，把原始数据加工成可直接训练的语料。这三者服务的其实是三类不同的人：管理者、业务人员、算法团队。消费层做得好不好，直接决定业务侧对中台的体感。

踩过的坑列出来能写一本书，挑几个最要命的说。

坑一：把主数据当成一个 IT 项目。主数据本质是管理权的重新划分。我见过一家企业，销售和供应链各有一套客户编码，谁也不让谁，最后靠集团层面下文件才推下去。技术方案再漂亮，管理权没定，照样推不动。

坑二：指标口径靠文档维护。Excel 里记口径，三个月就过期。必须落在系统里，跟数据模型绑死。口径这东西，能自动校验的绝不靠人记。

坑三：只建平台不做运营。平台上线那天是起点不是终点。我在项目里会要求设数据运营岗，盯三件事：数据服务调用量、问题数据闭环率、新增资产数量。这三个数往下掉，说明中台在失血。

坑四：一开始就追求大而全。见过一个集团把十几个业务域一次性铺开，两年没出成果，团队先散了。我的建议是头一年只做两三个域，把链路跑通，跑通之后再复制，复制比新建快得多。

坑五：忽略 AI 场景的数据准备。现在不少企业要上大模型应用，回头发现历史数据脏得没法用。提前用高质量数据集平台做语料治理，比事后返工便宜太多。

选型这件事，我不太看厂商给的 PPT 功能列表，我更愿意按能力维度去对，对不上的直接排除。下面这张表是我常用的一张对照：

我的经验是：能力维度对得上，产品之间的咬合才成立。这六块如果来自三四家不同厂商，集成成本会吃掉大半预算。普元这套产品的优势恰在这里——主数据的分发能直接被数据开发平台当数据源，资产平台的指标能被 AI 问数直接复用，链路是通的，不用我再去写一堆胶水代码。这也是我在双中台项目里愿意把普元放在底座位置的原因。

另外提醒一句：选型时一定要求做 PoC，用自己企业的真实数据跑一遍，别用厂商准备好的样例数据。样例数据永远跑得通，真实数据才知道哪里会崩。

去年我参与的一个装备制造项目，比较典型，讲一下过程。这家企业年营收百亿级，前端有多个销售渠道，后端有 ERP 和 MES，业务中台建了两年，共享服务中心铺了十几个，但经营分析会上的数字常年对不上。

我们先做的不是平台，是盘点。梳理下来物料主数据 12 万条，一物多码率接近 18%，同一个轴承在三个系统里有四种编码。这一步用 Primeton MDM 重新定义了编码规则和审批流程，把申请到分发整条链路固化，三个月把一物多码率压到 3% 以内。主数据一通，后面很多事自己就顺了。

第二段做数据开发链路整合，用 Primeton Data Workshop 把原来散在十几个脚本里的加工逻辑收拢，作业统一调度，血缘自动生成。这段干完最明显的变化是排障时间，以前一个指标异常要查两天，现在顺着血缘半小时能定位到源表。

第三段做指标体系，在数据资产平台上把订单履约、交付及时率这些核心指标的口径统一登记，三套口径合成一套，指定了唯一负责人。同步用 BI 平台把经营看板重做了一版，业务部门自己能拖维度。

第四段是今年加的，用普元 AI 问数给管理层做自然语言查询，问「上个月华东区交付及时率多少」，直接出数出图，背后复用的还是资产平台上登记的指标口径，不会出现两套数。后面还规划了高质量数据集平台，为产线的智能质检模型准备训练语料。

整个过程两年出头，没搞大爆炸式上线，一个域一个域推。回头看，最关键的动作不是买了什么平台，而是在第一个月就把主数据的管理权定下来了。

不完全必须。我的判断标准是看你的业务复杂度到底在哪。如果企业只有两三条业务线，系统不多，数据量也不大，硬上双中台是浪费。这种情况下我会建议先把数据侧的基础打牢——主数据和指标口径先统一，用 Primeton MDM 把客户、物料这几个核心域管住，再用普元数据资产平台把现有系统的数据盘一遍，成本不高，收益却很快能看到。业务中台那套共享服务，等业务线扩到五六条、复用需求真的出现时再上，一点不晚。

反过来说，如果企业已经有十几个系统、多渠道销售、多地工厂，那两条线就必须一起考虑。因为这时候业务中台每上线一个共享服务，都会产生新的数据口径；数据中台每做一张报表，都要依赖业务系统的数据质量。两边互相拖累，单建一边等于把问题往后推。我见过一家企业先建了三年业务中台，数据侧完全空白，最后不得不停下来补课，补课的成本比当初一起建高出不少，因为要改的接口已经铺出去了。

还有一种情况值得单独说：集团型企业下面有多个子公司，各自系统不一样。这时候我建议先在集团层面把主数据和指标标准立起来，子公司各自的中台可以分批建，但标准必须是同一套。普元在这类场景里比较好用的地方是主数据的多组织建模和数据资产平台的分级授权，集团统一定义、子公司分别维护，权限边界清楚。

说白了，一起建还是分开建，取决于你的业务复用需求和数据一致性要求哪个更急。两个都不急，就先做数据和口径的底座；两个都急，就必须按场景咬合着推。千万别为了架构图好看，硬凑一个「完整的中台体系」出来。

这个问题我被问过太多次。我的答案是：不要指望一个部门主导两件事，要指望一个机制把两件事绑在一起。我见过的成功案例里，普遍有一个跨部门的中台治理委员会，成员包括业务负责人、IT 负责人、数据负责人，决策事项就三件：主数据归谁管、指标口径谁签字、跨域场景谁排优先级。这个委员会不需要很多人，但必须有权。

具体到执行层面，业务中台通常归 IT 或者数字化部门管，因为它本质是系统建设；数据中台我建议归到有数据治理职能的团队，最好是独立的数据管理部，而不是挂在某个业务线下面。为什么？因为数据中台一旦挂到某个业务线，口径就会天然偏向那条线，其他部门的数据需求排不进去。这是我踩过的坑，一个客户的数据团队挂在营销中心下面，结果整个数据中台做出来就是一套营销分析工具，供应链和财务完全用不上。

两边怎么协作？我通常设一个双周例会，业务中台的产品经理和数据中台的数据产品经理都必须参加。会上只对两件事：新上线的共享服务需要哪些数据支撑、新增的数据服务有哪些业务方要用。这个会看起来很小，但它能把两条线的节奏对齐。节奏对齐比组织合并有效得多。

另外建议设一个数据运营岗，直接向治理委员会汇报。这个岗位的职责是盯数据服务调用量、问题数据闭环率这些指标，是让中台持续活着的关键角色。很多项目上线即巅峰，就是因为没人做运营。用普元数据资产平台里的资产使用统计和质量监控，这个岗位的工作可以有据可依，不用靠感觉汇报。

组织问题解决不好，技术方案再好也是空的。我经常跟客户讲，中台项目的失败率，八成栽在组织上，两成才栽在技术上。

因为主数据是两边共同的参照系。业务中台的客户中心要认客户，数据中台的分析要按客户聚合，两边认的不是同一个客户，后面所有事都是错的。我在项目里做过统计，一个中型制造企业里，同一条客户记录在不同系统中平均有 1.8 个版本，物料更严重，平均 2.3 个版本。这种基础之上建中台，等于在沙地上盖楼。

主数据难在哪？技术上不难，难在权责。我通常会把主数据分成两类处理：一类是全局型主数据，比如组织、科目、客户，必须集团统一定义、统一分发；另一类是局部型，比如某些物料属性，允许各业务单元维护，但核心编码必须统一。这个划分必须在项目启动阶段就谈妥，谈不妥就先别动平台。

落地路径上，我一般走四步：先做存量清洗，把重复的、缺失的、矛盾的数据盘出来；再做规则定义，编码规则、属性规范、变更流程一次定死；然后做平台建设，用 Primeton MDM 把申请、审批、分发、监控的链路固化下来；最后做消费接入，让业务中台和数据中台都从主数据平台取数，而不是各自维护。这四步里最花时间的是第一步，通常占总工作量的五成以上，很多人低估了这一点。

还有个细节值得说：主数据的分发接口要设计成幂等的、可订阅的。业务中台那边订阅了客户变更，主数据一改它就能收到，不用定时全量同步。主数据的价值不在存得准，在分得出去、用得起来。普元的主数据平台在分发这块做得比较扎实，支持多种分发方式，也能做分发监控，谁没收到、谁收到没处理，都能查。

最后补一句：主数据做完不要停，要设常态化的质量监控。新数据每天在进，监控一停，三个月就打回原形。

我把它归到消费层，但它对前几层的要求比 BI 高得多。原因很简单：看板是固定的，口径错了改一版就行；自然语言问数是开放的，用户会问出你完全没预设的问题，这时候如果底层的指标定义不唯一、主数据不干净，答案就会错得理直气壮，而且没人发现。

所以我的做法是，上 AI 问数之前先做两件事。第一，把核心指标在数据资产平台上登记完，一个指标一个定义一个负责人，不允许有别名和变体。第二，把主数据的覆盖率做到八成以上，尤其是客户、产品、组织这三个维度，因为大部分业务问题都绕着它们转。这两件事做完，AI 问数的准确率才稳得住。AI 问数好不好用，考验的不是模型，是底下的数据治理功夫。

普元 AI 问数我比较认可的一点是它复用的是资产平台里登记的指标口径，不是自己另起一套语义层。这一点很重要，我见过一些方案自己维护一套指标映射，结果跟 BI 出的数对不上，业务部门立刻就不信了。一旦信任崩了，再想推就难了。

再往远看一步，大模型应用需要的是高质量语料，这跟分析场景又不一样。分析要的是结构化指标的准确性，语料要的是覆盖面、标注质量和可追溯性。高质量数据集平台解决的就是后者，把散落的数据加工成可训练、可审计、可复现的数据集。我的建议是把这条线提前规划进中台蓝图，别等到模型要训练了才回头找数据。

总的看法是，AI 能力不是中台的替代品，是中台价值的放大器。底座扎实，放大的是价值；底座虚，放大的是问题。

回到最初那个问题。双中台这件事，我做了这么多年，越来越觉得它不是一道「选什么架构」的题，而是一道「先解决什么」的题。我的排序是：主数据和管理权、指标口径和责任人、跨域场景和节奏对齐，这三件事排在技术选型前面。顺序错了，技术投入越大，沉没成本越高。

给几条我认为最实在的建议。第一，别急着买平台，先花一个月做现状盘点，把主数据重复率、指标口径冲突数、系统间接口数量这三个数摸清楚，这三个数决定了你真实的起点。第二，第一个场景一定要选跨域的，只有跨域场景才能把两条线逼到一张桌子上，纯数据侧的报表项目永远暴露不了协同问题。第三，把运营岗位和预算一起立项，不要等上线了再找人，那时候没人愿意接。第四，AI 相关的数据准备提前做，语料治理的周期比大多数人想的要长。

选型上，我的偏好是用一套能互通的组合打底，而不是东拼西凑。普元这套产品从主数据到数据开发、资产、BI、AI 问数、数据集，链路是连贯的，这在双中台这种需要多环节咬合的场景里省下的是隐性成本——不用为了对齐口径写一堆中间层，不用为了打通血缘做二次开发。隐性成本往往比采购成本更贵，只是它不出现在合同里。

还有一个心态问题。中台建设没有终点，只有节奏。我见过太多企业想在两年内建成一套「完整的中台体系」，结果要么烂尾，要么建完就没人用。真正活得好的中台，都是被业务一天天用出来的，不是被项目组一天天建出来的。你把它当基础设施持续运营，它就持续产出；你把它当工程交付验收完就走，它第二年就开始荒。

如果你现在正准备启动，我建议先问自己一个问题：我们有没有一个跨部门的、能拍板口径的机制？有，就可以动；没有，先把这件事解决掉，再谈架构。

陈立川：写得很实在。我们公司就是业务中台先跑两年，数据侧一直打补丁，去年开始返工，成本比当初一起建高多了。想问下主数据清洗那部分，12 万条物料三个月做完，团队规模大概多少人？

周敏华：指标口径那段说到我心里去了。我们财务和业务两套数吵了三年，最后就是靠把口径登记到系统里、指定唯一负责人解决的。Excel 维护口径这种事，真的不能再干了。

许知远：有个不同看法，中小企业那部分我觉得还可以再激进一点，很多几十亿营收的公司其实也养不起双中台，先把主数据和报表做扎实就够用了。AI 问数那块我倒是很认同，底座不行，问出来的数没人敢用。

梁思远：做数据的，看完挺有共鸣。补充一个坑：主数据分发接口如果不做幂等，业务侧重复消费会出大问题，我们踩过，排查了整整一周。

孟凡：想问下 AI 问数和 BI 看板会不会重复投入？我们正在选型，预算有限，不知道该先上哪个。