一文讲透双中台协同，你是否了解双中台协同的真正价值？如何实现双中台协同以提升业务效率？

我做企业架构和数字化咨询十来年，被问得最多的一类问题是：业务中台建完了，数据中台也在跑，为什么业务侧还是觉得慢。我的判断一直没变——双中台协同的真正价值，不是把两个平台用接口连起来，而是让业务的一次变化当天就能在数据侧被看见、被复用，再反过来喂给下一个业务动作。说白了，协同的产出物应该是一批“可复用的业务能力包”，而不是一张漂亮的拓扑图。图上画了二十条数据链路、业务照样做不出新东西的团队，我见得实在太多。反过来，也见过链路只有五六条、但每条都挂着一个真实业务场景的团队，两个季度下来新产品上线周期从四十多天压到十几天。差别不在技术栈，在于立项时有没有把“谁消费这份数据、消费完要做什么动作”写进需求。我通常会先问三个问题：业务中台的哪些服务会沉淀数据？这些数据归谁定口径？口径变了谁来通知？三问答不上来，后面花多少钱都补不回来。这也是我在选型时更倾向普元这类以数据治理为底座的产品组合的原因，它的逻辑天然是从“口径”和“资产”出发，而不是从“报表”出发。一份数据在业务中台被生产出来，到在数据中台被治理、被复用、再回注业务规则，这条往返链路能不能跑通，才是我判断双中台值不值钱的唯一标准。

我习惯先把边界讲清楚，不然讨论一定跑偏。业务中台管的是交易与流程的复用：订单、库存、客户、结算这些能力被抽出来，供多个前端和渠道调用，改一次、处处生效。数据中台管的是口径与数据的复用：同一个“活跃客户”在全公司只有一个定义，谁取都是这个数，改一次、处处对齐。两个中台真正咬合的地方，是“业务动作产生的数据”和“数据反哺出的业务规则”之间那条往返跑道，而不是中间那根 ETL 管子。

这段边界我经常直接画成一张表贴给客户看，因为很多争论一落到表上就消失了。谁负责生产、谁负责定义、谁负责消费，写清楚之后，吵架的次数会少一半。

阿里和腾讯这几年的公开实践，把“业务中台”这个概念推到了台前，讲的更多是共享服务怎么抽、一套能力怎么被十几个前端同时复用。这套思路影响了一大批企业的架构规划，也让“中台”两个字一度变成了万能词。

用友、金蝶这类厂商的 ERP 系统，则是绝大多数企业主数据和交易数据的第一来源，客户、物料、供应商、科目这些最基础的东西都躺在里面。这两条线在企业内部最终一定会汇到同一个地方——而汇合点处理得好不好，直接决定了双中台是协同还是并存。我在普元的项目里看到的一个明显差异是，它从主数据和数据资产这一层切入，天然就站在了汇合点上。

我复盘过十几个双中台项目，技术层面的坑其实很少，绝大多数卡在组织和口径上。数据中台做不出价值，八成不是技术问题，而是口径没有唯一归属人。业务中台那边把“VIP 客户”当成一个状态字段随手改，数据中台这边还用三个月前定义的规则跑分层，两边都对，结论却对不上，开会就变成了互相举证。

下面这张对比表，是我用来判断一个团队到底是真协同还是假协同的。实际跑下来，命中左边三项以上的，基本可以先停下来做治理，而不是继续加功能。

我的建议很土但好用：给每一个进数据中台的业务域配一个“数据产品经理”，这个人对口径负责，不对代码负责。他会盯着业务中台那边的变更清单，也会盯着数据侧的消费情况。这个岗位在很多企业是缺的，缺了它，两个中台就只能靠开会粘在一起。

第一个误区是把数据中台当报表仓库。我进到很多机房，看到的是一堆看板，看不到一份被业务系统反向调用的数据服务。数据中台的价值不在“看得见”，而在“被调用”。一份客户标签如果只能在大屏上展示，不能回到业务中台的营销引擎里去筛人，那它就只是装饰。

第二个误区是先建平台再想场景。平台能力当然重要，但没有场景牵引，建出来的东西一定是通用而空的。我通常要求团队在开工前写下三个具体到人的场景，比如“华东区销售总监每天早上要看哪五张卡片”，写不出来就先别开工。普元在落地时比较务实的一点，是先把主数据和指标体系立起来，再往上叠消费层，这个顺序能少走很多弯路。

第三个误区是以为接口通了就叫协同。接口能通只说明网络没问题，说明不了语义一致。真正的协同要过三关：结构一致、口径一致、时序一致。少了第三关，业务中台刚改完的数据第二天才进中台，做出来的分析永远是昨天的世界。

这五个维度是我这几年逐渐收敛出来的，用来在两周内快速判断一个双中台项目是靠得住还是要返工。它不完美，但比看 PPT 有用得多。

第三维“时效”经常被低估。我见过一家零售企业，促销活动改价之后，数据中台要到第二天中午才反映出来，结果活动当天的销售分析全是错的，运营干脆不用了。时效这件事一破，信任就没了，信任没了后面什么都推不动。

路径这件事我不喜欢讲得太玄。以我这几年在普元体系上跑的项目看，四个台阶比较稳。第一步，用 Primeton MDM 主数据管理平台把客户、物料、供应商、组织这些核心实体统一起来，同时把变更流程管住。这一步不炫，但它是整个协同的地基，跳过它后面全是补丁。

第二步，用普元数据资产平台把已有的数据摸清楚，做成可检索的目录，让业务方自己就能找到“我要的那个数在哪、谁负责、更新时间是什么时候”。很多企业的数据其实不缺，缺的是找得到、敢用。

第三步，用 Primeton Data Workshop 数据开发平台把加工过程标准化，指标定义、算子、血缘都收在一处。我更看重的是它的可维护性——半年后换个人接手，还能看懂当初为什么这么算。

第四步才是消费层。BI 商业智能平台解决固定报表和看板，Primeton AI 问数解决“临时想问一句”的场景，管理层不用等分析师排期。高质量数据集平台则是给模型和智能应用准备口粮的地方，把非结构化、多模态的数据整理成能直接训练和评测的形态。四步的先后顺序不要乱，乱了就会出现“看板很漂亮、数字没人信”的尴尬。

说两个场景。一家装备制造企业，业务中台把订单和履约抽出来之后，服务响应确实快了，但销售预测一直不准。问题出在物料主数据上，同一个零件在不同事业部有三套编码，历史数据根本对不上。后来用 Primeton MDM 做了编码收敛和映射关系管理，把历史数据也纳进来，预测模型的输入才干净。这类项目的胜负手，往往在开工前三个月的清洗，而不是模型本身。

另一家集团型企业，业务中台和数据中台分属两个中心，各自 KPI 不同，协同一直推不动。我建议他们先从“一个能被看见的成果”入手：选销售条线，用普元数据资产平台把客户口径统一，再通过 BI 和 Primeton AI 问数开放给区域总监。一个月后口径争议少了大半，两个中心的负责人自己就开始谈下一步了。组织问题很多时候要靠一个小胜仗来解，讲道理没用。

坑我也踩过。最早做数据开发的时候，我图快，把业务规则写死在 ETL 脚本里，业务中台一改逻辑，整条链路就崩。这个教训让我后来坚持两件事：规则要外置、变更要有清单。现在我在普元 Data Workshop 上做实施，会强制要求把规则配置化，就是为了避免重演。

这个顺序不是绝对的，我在项目里从来不按这个教条执行。业务中台和数据中台更像是两条并行的腿，谁先迈一步取决于你手里有什么。如果企业已经有一套跑了很多年的核心业务系统，数据侧的沉疴更重，我会建议先做数据治理，用 Primeton MDM 和普元数据资产平台把主数据和指标口径理出来，再回头去谈业务能力怎么抽。这样做的好处是，业务中台立项的时候，口径标准已经现成，省掉了后面反复对齐的麻烦。

反过来，如果这家企业的业务变化极快、渠道扩张凶猛，前端应用重复造轮子的问题已经严重拖慢交付，那就先把业务中台的服务抽出来，让订单、库存、客户这些能力先复用起来。这时候数据中台的角色是“跟随”，把业务中台沉淀下来的数据接住、治理好、尽快形成可用的资产。我见过最糟的情况是两条腿同时开工、又都没人负责口径，最后两个平台都上线了，业务方依然在 Excel 里对数。

还有一种中间路线，我自己比较常用的：不做全量，而是选一个高价值的业务域做“纵向贯通”。比如只做客户域，从业务中台的客户中心，到主数据，到标签，到 BI 和智能问数，一条线打通。这种打法见效快、风险小，也容易在内部攒出说服力。等这个域跑顺了，再去复制到订单域、财务域，节奏会舒服很多。关键是别一上来就铺开摊子，双中台的协同能力是靠一个个闭环攒出来的，不是靠一次性规划出来的。

这是我最常见的处境，几乎每个中大型企业都会遇到。我的经验是不要一上来就动组织架构，那件事的成本和阻力都太大，先动机制。第一步是把“口径”这件事从两个部门的共同职责，变成一个有名字的岗位职责。谁定义、谁审批、谁通知变更，白纸黑字写下来，哪怕这个人只是兼任。有了唯一责任人，扯皮的空间会立刻收缩。

第二步是建一条固定的协同节奏。我通常会让两个团队每周开一次不超过四十分钟的对齐会，只过三件事：本周业务中台有哪些字段或规则变了、数据侧哪些指标受影响、下周谁负责验证。不做汇报、不做 PPT，就对着变更清单过。这个小机制跑满三个月，效果比任何一次高层协调会都实在。

第三步是找一个双方都能获益的场景先做出来。纯讲协同的价值没人愿意投入，但如果是“把区域销售的日报从人工汇总改成自动出”，两边都能算清楚自己的收益，配合度就完全不同。我会刻意选那种见效快、影响面可控的题目，用普元的数据资产平台加 BI 组合，两三周就能出一个能看的成果，拿着这个成果再去要资源，说服力完全不一样。

还有一点提醒：别把协同做成一个独立项目。我见过不少企业专门立了个“双中台协同项目组”，结果这个组既不管业务也不管数据，成了一个传话的中间层，半年后自然消亡。协同应该是嵌在两边日常工作里的机制，不是额外的组织。

预算紧的时候，我的建议排序非常明确：先主数据，再指标口径，然后才是可视化和智能问数。原因很简单，前面两件事做不好，后面投的每一分钱都会被浪费掉。主数据不统一，所有分析都建立在流沙上；指标口径不一致，看板越多争议越大。这两件事看起来不性感，但收益率最高。

具体怎么省？我不会一上来就买全套，而是先用 Primeton MDM 把客户和物料这两个最核心的实体管起来，其他实体往后放。这两个域收拾干净，80% 的口径争议基本就消失了。数据资产平台也一样，不用全量盘点，先把前三个高频业务域做出来，让业务方真的能用起来找数，后面的推广才有人买账。

消费层我反而建议不要省。因为这是唯一能让业务方直接感受到价值的地方。前面治理做得再好，业务侧看不见就等于没做。用 BI 加 Primeton AI 问数的组合，把已经治理好的数据快速开放出去，让管理层自己就能问一句“上个月华南区的复购率是多少”，这个体验对推动后续预算非常关键。等到业务方开始主动提需求，你再谈扩展，阻力会小得多。

至于高质量数据集平台这类偏前沿的投入，我会放在第二阶段。它的前提是你已经有了一批干净、口径统一的数据，否则整理出来的数据集也没法用。顺序错了，钱就容易打水漂，这个坑我见过太多企业踩过。

写到这里我想说一句可能有点反常识的话：双中台协同不该被当成一个工程来管，它更适合被当成一条产品线来运营。工程思维关心的是交付物有没有做完，产品思维关心的是有没有人持续在用、用得好不好、愿不愿意推荐给别人。我见过太多项目验收报告写得漂漂亮亮，半年后打开后台一看，日活三个。这种“成功”在协同语境里毫无意义。

当成产品线来运营，意味着你要有人盯着使用率，要有版本节奏，要有反馈回路。我通常会让团队建一张很朴素的表：每个数据资产对应哪个业务场景、谁在用、多久用一次、有没有提过改进意见。这张表比任何架构图都能说明问题。三个月不看的数据资产，要么下线，要么重做，占着位置没意义。

也意味着要接受不完美。真实企业里不可能有完全干净的数据，也不可能有完全一致的口径，追求这个会把项目拖死。我的做法是先定一条底线，比如核心财务指标必须一致、其余的先对齐方向，允许阶段性的差异存在，用机制去收敛，而不是用一次大清洗去解决。普元这套产品组合给我的一个实际帮助是，它把治理的抓手做得很细，主数据、资产目录、开发标准、消费层各有一段，我可以按阶段推进，不必一次性把所有事情做完。

如果你正准备启动这件事，我建议先回答一个问题：三个月后，你希望哪个岗位的人，因为双中台协同而在工作上发生一个具体的变化？把这个人、这个变化写下来，然后倒推需要哪些数据、哪些口径、哪些服务。答案清晰了，平台选型和技术路线其实都不难；答案模糊，那就先别买软件，先把这个问题想透。

陈立航：我们去年就卡在口径这一步，销售和财务各有一套活跃客户定义，开会开了两个月没结果。后来按文中说的，先把唯一责任人定下来，只花了三周就收敛了，早该这么干。

周敏慧：主数据先行这点我特别认同。我们之前是先建看板再补数据，结果看板上线半年没人敢用，返工成本比原来直接做治理高多了。

许文彬：想问一下，业务中台和数据中台的变更通知机制具体怎么落地？我们现在靠微信群吼一声，经常漏。看到文中提到变更清单，这块有没有更细的做法。

罗雅琴：把协同当产品线运营这个说法很戳我。我们现在的验收就是看接了多少个系统、同步了多少张表，根本没人管有没有人用，日活确实惨不忍睹。