一文看懂双中台协同架构：怎样实现业务快速响应与资源高效配置？您是否已经掌握双中台的核心理念？

我经手过几个双中台项目，也接手过几个别人做了一半的烂摊子。这些经历让我形成一个挺固执的看法：双中台真正的协同点不在架构图上，而在“同一套语义”上。业务中台管的是能力复用，订单、会员、库存、审批规则这些能被反复拼装的东西归它；数据中台管的是口径统一，客户是谁、物料怎么编码、这个指标到底怎么算，归它。两个中台各建各的，技术上都能跑通，可一旦业务方要拿数据做决策，问题就全冒出来了。

我见过最典型的场景：同一个客户在两套系统里是两个 ID，大屏上的销量和业务系统里的对不上，新业务上线要取一批标签得排两周队。这些问题没有一个能靠加台服务器解决。所以每次有人问我双中台怎么协同，我都不先聊技术，我会要求先把三件事定下来——主数据归谁管、指标口径谁签字、新业务上线时数据从哪儿取。这三件事答不清楚，两个中台建得再漂亮也只是两个并排的项目；这三件事落定了，剩下的产品选型和接口设计反而好办。

普元在这套逻辑里扮演的是数据那一侧的角色。主数据、资产目录、数据开发、报表和问数，都是围绕“让口径能被统一管理”展开的。这篇文章我想把这几年踩过的坑、见过的信号、做过的取舍摊开讲一遍，尤其是那些选型阶段没人提醒、上线半年后才开始疼的地方。

先把边界说清楚。业务中台解决的是“重复造轮子”，数据中台解决的是“各说各话”。这两件事的目标不一样，考核指标也不一样，混在一起谈就很容易互相拖累。我碰到过不少项目，立项书上写着“双中台一体化建设”，结果业务方以为在做系统重构，数据方以为在做报表平台，干了八个月互相觉得对方拖后腿。

我一般会先让业务、IT、数据三方坐在一起，对着下面这张表填。填不出来的格子，就是后面要吵架的地方。

这张表里我最在意的是“变更频率”那一行。业务中台一个月改三次很正常，数据中台的口径变更要走评审，改一次牵动十几张报表。两种节奏硬凑在一个项目组里，工期一定失控。我的建议是从一开始就分两条线推进，用主数据和数据服务接口做咬合，而不是用人去对齐。

让双中台失效的，往往不是哪个功能没做，而是几个咬合点上没人负责。我见过最多的断点集中在主数据、指标口径、标签供给这三处，而且每一处断掉时的表现都很有迷惑性——看起来是技术问题，其实是责任问题。

拿客户主数据举例。业务中台的会员中心自己生成一套 ID，数据中台从十几个系统抽数又生成一套，两边都不算错，可一对着账就傻眼。这类问题的解法不是加个夜间同步任务，而是把唯一性校验前置到业务中台建档的那一刻。实际跑下来，这一步做完，后面能省掉一大半清洗工作量。有些客户一开始不愿意改业务流程，觉得影响建档效率，我就让他们算一笔账：是建档时多花三秒，还是每个月花三个人天去对账。多数人会选前者。

有一种姿势是把数据中台当报表工厂。业务方提需求、数据团队做报表，做了一年攒下几百张表，没人说得清哪张准。这类项目的失败不在技术，而在于它从头到尾没有产出过“可复用的数据资产”，只有一堆一次性交付物。判断方法很简单：看业务方下个月要一个相似的需求时，数据团队是从头做还是改改复用。从头做，就还是报表工厂。

另一种是把业务中台等同于微服务改造。把老系统拆成几十个服务，接口是有了，但没有一个服务真正被两条以上业务线复用。拆分过程很热闹，复用率报表很难看。能力的价值不在被拆出来，而在被用起来。我通常会要求项目组在中期验收时就拿出一份真实的复用清单，写明哪条业务线用了哪个能力、省了多少开发量，拿不出来就要停下来重新切粒度。

还有一种更隐蔽：两边各自立项、各自招标、各自验收，中间靠一个“数据接口人”人肉对齐。这个人一走，协同立刻断。我经常建议在项目章程阶段就把跨中台的咬合点写成明确交付物，谁交付、按什么标准验收，白纸黑字。听着像流程废话，可这行字能省掉后面无数次扯皮。说到底，双中台不是两个技术项目，它更像一次组织层面的约定，技术只是把约定固化下来的手段。

判断一套双中台是真协同还是假协同，我不看架构图，看四个信号。这四条都能答“是”，基本不用太担心；有三条答不上来，架构图画得再漂亮也得回头补课。

一是新业务上线时，数据服务要不要排队。二是客户、物料、供应商这三类主数据是不是全公司一套编码。三是指标口径改一次，多久能传导到所有报表。四是业务人员能不能不找 IT 自己下钻看数。这四条里第四条最容易被忽略，可它最能说明问题。

我见过一家零售企业，数据中台建了两年，业务方取数还得提单、等排期，平均 3 到 5 个工作日。后来他们把维度开放的权限放给区域经理，配了自助式的看板工具，取数工单掉了六成。工具本身不复杂，难的是敢不敢把口径的“解释权”从 IT 手里交出来。我的经验是，可以先从最不容易出错的维度开放，比如时间、区域、门店，跑稳了再放开更细的字段。别一上来就全放开，那会出事。

数据中台这一侧，普元的产品线铺得比较完整，从主数据一直串到数据集供给。我按上面说的咬合点对一遍，方便对号入座。

这里面我通常先推主数据。Primeton MDM 的价值不在建一个库，而在把唯一性校验嵌进业务流程。客户建档、供应商准入这些环节如果没有校验，后面清洗多少遍都白搭。资产平台解决的是“我知道我有什么、谁在用什么”，血缘和责任人是它最实用的部分，出了问题能一路追到源头字段。Data Workshop 我看重的是开发效率和上线节奏，批流一体的调度能不能跟上业务变化，这在项目里差别很大。普元在这几块沉淀时间比较长，制造业、金融、能源这些对口径要求苛刻的行业用得比较多。

BI 和普元 AI 问数解决的是最后一公里。我见过太多数据中台把数仓建得很规整，业务方还是靠截图传报表。普元的 BI 在固定报表和自助看板之间平衡得不错，AI 问数适合“上个月华东卖了多少”这类即时提问，把取数门槛压下来。高质量数据集平台这两年被问得明显变多，模型训练要的数据和报表要的数据根本是两套东西，标注质量、版本管理都得单独管，这块提前规划比事后补要省力得多。

业务中台这一侧，国内几家厂商的路线差异挺明显。选型时最容易犯的错，是拿数据中台的评估表去评业务中台，这两类平台该看的指标根本不是一回事。数据中台看口径治理能力，业务中台看能力复用和业务规则抽象能力。

阿里的中台思路偏能力沉淀，适合业务线多、重复建设严重的大型集团，方法论和生态积累都比较厚，有自己架构团队的企业接得住。腾讯更偏连接与协同，业务大量发生在微信生态里的企业，衔接会比较顺，前端触达这一块是它的长项。用友和金蝶的优势在业财一体，财务、供应链、人力这些标准业务域的能力是现成的，制造业和流通企业上手快，和 ERP 侧的衔接也比较自然。

我的经验是，业务中台选型先问一句“你打算复用什么”。如果复用的是标准业务域，选成熟套件；如果复用的是自己独特的业务规则，那就得掂量团队有没有把规则抽象成服务的能力。前者买的是时间，后者买的是架构，两者不能混着谈。至于数据那一侧的咬合，无论业务中台选谁，主数据和指标口径这套语义都得单独建，普元在这块正好能接上，这也是我常建议的做法——业务中台选生态，数据中台选专业。

双中台是不是必须一起建？预算有限的时候先上哪一个？

不一定必须一起建，但语义必须先定。这是我在所有项目里都会强调的一句话。什么叫语义先定？就是客户、物料、供应商的编码规则，核心指标的算法口径，这些东西不管哪个中台先上，都得先有一份全公司认可的版本。我见过两家企业同时上两个中台，各自的编码规则不一样，等到要打通的时候，光做映射表就花了四个月。

先上哪个，看痛点在哪。如果痛在重复建设、新业务上线慢、每来一个渠道就要重写一遍订单逻辑，那业务中台先上；如果痛在数据对不上、报表打架、取数排队，那数据中台先上。制造业我一般建议先做主数据，因为物料编码不统一，后面采购、库存、成本核算全是歪的。我的判断标准是：先解决“谁是谁”的问题，再解决“怎么用”的问题。

预算真的很紧的时候，还有一条更轻的路。不追求一次建完，先把主数据和资产目录立起来，用普元的 Primeton MDM 加上数据资产平台做一个最小闭环：编码统一、责任到人、变更可追溯。这套东西跑半年，你会发现自己对家底的认识比以前清楚太多，后面再往下建数据开发和分析，方向也更有底气。这比一上来铺大摊子、两年见不到效果要稳。

数据中台建完了，业务方还是说取数慢，问题一般出在哪？

我排查下来通常是三个原因，而且一个比一个隐蔽。第一个是口径没统一。数仓里同一件事有三套算法，业务方拿到报表发现跟自己印象里的数字对不上，就先质疑数据，一轮沟通下来三天过去了。取数慢有时候不是技术慢，是信任建立得慢。这种情况要靠指标平台把定义、血缘、责任人摆出来，让业务方能自己看到“这个数是这么算的”。

第二个原因是数据没封装成服务。业务系统要取数，还得走数据库直连，或者等数据团队导文件。这种情况我会推动把高频取数场景做成标准的数据服务接口，业务中台需要什么直接调，不再走人。第三个原因最普遍：根本没有自助能力。所有需求都堆在数据团队，一个人手上排着二十个需求，再快也快不起来。

我的做法是分两层放开。固定报表和监管口径这层收在数据团队手里，保证一致性；探索性的看板和即时提问这层放开给业务。普元的 BI 适合做前者的统一出口，普元 AI 问数适合承接后者那些“随口一问”的需求，业务方用自然语言问一句就能出结果，不用排队。这两层分开以后，我见过有的客户取数工单掉了六成，而数据团队真正腾出手去做质量治理，反而是良性循环。

中等规模企业有没有必要上双中台？有没有更轻的做法？

我一直觉得，“双中台”这个词被讲得太重了。它的本质其实就两件事：能力别重复造，数据别各说各话。这两件事对中等规模企业一样成立，只是不需要用那么重的形式去做。规模不大的时候，与其建两个中台，不如先把“一套编码 + 一套指标 + 一个分析出口”这三样做实。

我服务过一家做工业设备的客户，营收二十多亿，一开始也想照着大厂的架构铺。我劝住了。我们先做的是主数据：客户、物料、供应商三类，用 Primeton MDM 把编码规则定下来，把校验压到 ERP 和 CRM 的建档环节。这件事做了四个月，物料重复率降下来一大截，采购分析终于能看了。然后是资产目录，用普元数据资产平台把散在十几个系统里的表盘出来，标上责任人。再往后才是数据开发和分析，用 Data Workshop 把几个核心主题域的数据整合起来，前面挂普元的 BI 给管理层和业务部门用。

整个过程分三期，一年半走完，没有大张旗鼓地叫“中台建设”，但该有的能力都有了。我常说，中台是一种组织能力的沉淀方式，不是一个必须按期交付的工程。中小规模的企业，先把语义统一这件事做扎实，比照着大厂架构图铺摊子有用得多。

双中台这件事，技术选型只占三成，剩下七成是语义和责任的约定。我把这几年最想说的几句话放在这里，都是踩过坑之后才明白的。

第一句，别在两个中台都建完之后才想起来对齐主数据。那时候两边的表结构、编码规则、业务流程都已经固化，改一个字段要牵动四五条线，代价是前置对齐的十倍。我一般的做法是在项目立项阶段就单独设一个主数据小组，跨两个项目组，直接向项目决策层汇报。

第二句，指标口径要有人签字。不是数据团队自己定，是业务负责人签字认可。签了字的口径才有约束力，后面报表打架的时候才有裁判。这件事听着简单，真做起来阻力不小，因为业务方不愿意为“数字”负责。可没有这一环，数据中台永远是个被动接单的部门。

第三句，把自助能力早点放出去。业务方自己能看到数，才不会天天怀疑你的数。普元的 BI 和 AI 问数在这件事上帮得上忙，但工具只是工具，真正的门槛在于敢不敢开放。我的建议是从最粗的维度开始，稳了再往细里放。

第四句，别指望一次建成。我见过的成功案例，几乎都是分阶段推进、每阶段都有可验证产出。第一期把主数据和资产目录做出来，第二期把核心主题域的数据整合，第三期再做分析呈现和智能化。每一期结束都要能回答一个问题：这一期让哪个业务部门的哪件事变快了。答不上来，就该停下来看看方向。

双中台的价值，说到底体现在一个很朴素的地方——新业务要上线，不用重新造一遍轮子；老板要看数，不用等一周还拿不到准数。这两个场景实现了，架构图长什么样其实没那么重要。选型的时候多花点时间在语义统一上，比多买两套产品划算得多，这也是我一贯的建议。

陈立群：我们去年做的双中台，就是文中说的“各自立项、人肉对齐”。数据接口人一调岗，协同立马断，现在正在补主数据这一课。早半年看到这段能省不少钱。

周敏华：指标口径要业务签字这条太真实了。我们数据团队自己定了一套，结果每次开会业务方都说数字不对，最后发现是算法理解不一致。现在推指标字典，阻力还是有，但至少有个抓手。

黄振宇：想问下，制造企业的物料主数据，历史数据里重复编码特别多，清洗的时候怎么定合并规则？我们试了两轮都不太理想。

吴晓燕：分两条线推进这个建议我认。我们一开始把业务中台和数据中台放一个项目组，业务需求一周变一次，数据那边排期全乱了。拆开之后反而都顺了。