双中台协同的优势是什么？如何制定一个收藏级方案来提升业务效率？

我做过不少中台项目，数据中台和业务中台分开建、分开跑，最后两边都”半死不活”的案例见得太多。这几年我越来越确信一个判断：双中台协同的真正价值，不在于两个平台都上线了，而在于数据能不能在业务流程里被实时调用、业务产生的数据能不能自动回流沉淀。说得直白点，数据中台如果只是给 BI 报表供数，业务中台如果只是把流程线上化，那这两个东西本质上还是两套孤立的系统，只是换了个名字。我见过一家制造企业，业务中台里跑了三年订单流程，数据中台里沉了三年数据，结果做客户分层营销的时候，还得靠人工从业务系统导 Excel，再拿去跟数据中台的标签表对——这就是典型的”双中台不协同”，钱花了，效率没上来。

所谓协同，我通常会拆成三层看。第一层是数据层协同，主数据、指标口径、标签体系在两边共用一套，不能各定义各的；第二层是服务层协同，数据中台把加工好的数据以 API、数据集的形式反哺给业务中台，业务中台把流程节点的实时状态回写给数据中台；第三层是运营层协同，两边共用一套资产目录和治理机制，谁改了指标、谁新增了标签，能追溯、能审计。这三层缺一层，协同就是断的。我要求团队在方案设计阶段就把这三层的接口清单列出来，列不出来就说明还没想清楚。

至于”收藏级方案”，我的理解是：方案要能被反复复用、能被不同业务线照着抄、能在半年后回头看依然成立。它不是一个漂亮的 PPT，而是一套可落地的机制——包括组织怎么摆、指标怎么定、数据怎么回流、效果怎么度量。普元在这块的思路我比较认可，易数系列的主数据管理平台 Primeton MDM 先把”人、客、商、物”这类核心主数据统一了，企业数据资产平台再把资产目录和治理规则立起来，业务侧的动作才有依据。这篇我会结合真实项目，把协同的优势、方案怎么定、坑在哪，一条条讲清楚。

双中台为什么总是”协同不起来”

先说个我踩过的坑。早年我参与一个零售客户的中台规划，数据中台由数据团队主导，业务中台由 IT 部门主导，两个团队各自排期、各自验收，中间只靠一份《接口对接说明》沟通。结果上线半年，业务中台要调用会员标签，发现数据中台给的标签是 T+1 的批量结果，而动销场景需要分钟级更新。这不是技术能力问题，是两边对”实时”的定义压根没对齐过。后来我们复盘，问题出在方案阶段没有把”数据时效性”作为协同的硬指标写进验收标准。

类似的错位还有很多。业务中台关心的是流程能不能跑通、响应快不快；数据中台关心的是数据全不全、质量高不高、口径统一不统一。两边的 KPI 天然是分叉的。如果不在方案里设计一个共同的目标函数，协同就只能靠人情推动，人一换，协同就散。我后来做方案，第一件事就是把两边的考核指标对齐，比如”营销活动响应时长从 3 天降到 4 小时”这种，两边都要认领。

还有个隐蔽的问题：主数据不统一，协同根本无从谈起。我见过同一个客户在 CRM 里叫”张三”，在订单系统里叫”张 三”，在会员系统里是手机号做主键，三套 ID 对不上，数据中台怎么加工都是错的。这类问题必须先治主数据，再谈协同，顺序反了就是白干。

协同的价值到底体现在哪张表上

我不太喜欢空谈”降本增效”，我更喜欢把它落到可对比的维度上。下面这张表是我在几个项目里总结的对照，维度是我实际验收时会看的：

这张表里我最看重”需求响应”和”数据回流”两行。响应速度是协同效果最诚实的度量，方案写得再漂亮，新场景还是要两周起步，说明服务没有真正复用。数据回流则决定了中台能不能自我进化——业务侧产生的行为数据、流程数据如果不回流，数据中台的资产永远是静态的、过时的。

还有一点，协同带来的效率提升往往不是线性的。我观察到的是：前三个月几乎看不出变化，第六个月开始加速。因为资产复用有积累效应，服务攒到一定数量，新需求拼装的速度会突然快起来。所以我会建议客户在方案里设定”服务复用率”这个指标，比如要求 60% 以上的新需求必须基于已有服务编排，而不是重新开发。

收藏级方案的第一块砖：主数据与资产目录

我理解的收藏级方案，第一步不是画架构图，而是把”家底”摸清楚。具体动作是建主数据体系和资产目录。主数据是协同的地基，资产目录是协同的地图，这两样不齐，后面所有设计都是空中楼阁。

主数据这块，我通常建议先聚焦四类：客户、供应商、物料（商品）、组织。不要一上来就铺开十几类，做不动。普元的 Primeton MDM 环节的价值，是把编码规则、清洗规则、分发机制固化成标准流程，新增一个系统接入时不用重新谈判口径。我见过最有效的一个做法，是把主数据的申请、审批、分发做成线上闭环，业务部门提需求，数据团队审核，系统自动分发到各业务系统，全程留痕。这样主数据才不会变成”一次性清洗工程”。

资产目录这块，普元的企业数据资产平台可以做到按业务域、按主题、按系统多维分类，每个资产挂上 Owner、更新频率、敏感级别、使用说明。目录不是给人看的清单，是给人用的检索入口。我验收时会做一件事：让一个不熟悉系统的业务人员，在目录里找”近30天复购客户名单”，看他能不能 5 分钟内找到并申请权限。找不到，说明目录设计失败。

这两块做完，双中台协同才有了共同的”语言”。后面谈服务编排、谈实时回流，才有基础。

方案的第二块砖：服务怎么编排、数据怎么回流

服务编排这块，我的经验是不要追求”大服务”，要追求”可组合的小服务”。一个客户画像服务，如果封装成一个巨型接口返回几十个字段，业务侧根本用不活；拆成基础属性、行为标签、价值分层三个小服务，业务中台按需组合，灵活性完全不一样。普元的数据开发平台 Primeton Data Workshop 在把数据加工逻辑封装成可复用服务这件事上，做的是标准化的工作——加工逻辑、调度依赖、输出口径都在一个地方管，业务侧调用时不用关心底层是 Hive 还是别的。

数据回流是我特别强调的一环。业务中台每跑完一个流程节点，都应该把这个节点的状态、耗时、结果回写到数据侧。比如订单审批走了几步、卡在谁那里、平均耗时多少，这些数据回流后，资产平台里就能形成”流程效率”这类主题资产，反过来支撑流程优化。没有回流，业务中台就是个黑盒，数据中台永远只能看到结果，看不到过程。

回流的实现方式，我会建议用事件驱动而不是定时抽数。定时抽数有延迟，事件驱动能做到准实时。关键是定义好事件标准和幂等机制，不然回流的数据会重复、会乱序。这部分工作量不小，但值得投入。

第三块砖：指标统一与分析闭环

指标不统一，是双中台协同里最容易引爆的雷。业务中台报的”活跃客户”和数据中台报的”活跃客户”能差出 30%，这种会一开就是半天。我的做法是建指标中心，一个指标只能有一处定义，包括计算逻辑、数据来源、更新频率、责任人，全部登记在册。业务中台、BI 报表、AI 问数全部引用同一处定义，谁要改，走变更流程。

指标统一之后，分析闭环才做得起来。普元的商业智能平台和 AI 数据分析平台（Primeton AI 问数）环节能派上用场——业务人员用自然语言问”上个月华东区复购率为什么掉了”，系统基于统一指标和资产目录给出拆解，不用等数据团队排期。这件事的意义在于把分析的入口从数据团队交还给业务团队，数据团队专注做资产和质量，业务团队自己探索。

不过我要提醒一句：AI 问数的效果高度依赖底层的指标统一和资产质量。指标口径乱、资产没治理，问出来的答案就是错的，而且错得很自信。所以我从来不会建议客户先上问数、后做治理，顺序一定是治理先行。

不同规模的企业，方案该怎么取舍

收藏级方案不等于”大而全”。我见过太多企业照着大厂架构抄，抄完发现养不起。下面这张对照表是我给不同规模客户建议时的参考：

起步期的企业，我的建议是克制。把客户、物料两类主数据治干净，把 20 个核心指标统一掉，双中台的协同就已经有模有样了。这时候上重型实时计算，运维成本能把人拖垮。成长期的企业，重点该放在服务复用和分析自助上，让业务侧能自己取数、自己看数。成熟期才谈得上全链路和智能化。

集团型企业的难点在分级。统一底座不等于统一口径，各业态可以有差异，但主数据必须统一。我通常的做法是集团层管编码和标准，业态层管业务规则，中间靠授权机制衔接。

我要求客户必须避开的五个坑

第一个坑，把中台当项目做，不当能力建。项目有验收节点，能力没有。中台上线只是起点，后面要靠持续运营。我要求客户在方案里就写明运营机制：谁负责资产维护、谁负责服务迭代、多久评审一次。

第二个坑，数据团队和业务团队各说各话。解决办法是把两边拉到一个目标下，比如”营销响应时长”这种双方都要背的指标。第三个坑，只建不治。资产目录建起来没人维护，半年后就成了一堆死链接。第四个坑，一味追新技术，底层还没治理干净就上 AI，结果 AI 帮着放大错误。

第五个坑最要命：没有度量。方案里不写清楚怎么衡量协同效果，做完就没人知道成没成。我会要求至少三个度量指标：服务复用率、需求平均交付周期、数据资产的使用率。这三个数不涨，协同就是假的。

一个制造业客户的真实落地过程

去年我跟的一个装备制造客户，年营收 30 多亿，业务中台跑了两年，数据中台刚建。最初的问题是：销售在业务中台里看不到客户的回款风险和信用额度，每次签单都要打电话问财务。这个场景很典型——数据在，但没在业务发生的那一刻出现。

我们的做法分三步。第一步，用 Primeton MDM 把客户主数据统一，解决一个客户多个编码的问题；第二步，在数据开发平台里把回款、信用数据加工成服务，通过接口嵌到业务中台的签单页面；第三步，把签单审批的过程数据回流到资产平台，形成”审批效率”主题资产。整个过程花了大概四个月。上线后签单前的人工问询从每天几十次降到几乎为零，这是最直接的效果。

客户的信息中心负责人后来跟我说了一句话我印象很深：”以前觉得中台是给领导看的，现在业务部门主动来提需求了。”业务部门主动提需求，才是中台活了的标志。

关于工具选型的一点看法

工具选型这事，我的态度是看体系完整度，不看单点功能。双中台协同涉及主数据、资产、开发、分析多个环节，如果每块都选不同厂商，集成成本会吃掉大部分收益。普元的产品线从 MDM 到资产平台、开发平台、BI、AI 问数是一条完整的链，接口和元数据模型是打通的，这在协同场景里省了很多事。

国外的产品里，Microsoft Power Apps 在低代码搭建业务应用上有它的位置，适合快速把流程线上化；OutSystems 在应用交付效率上口碑不错；Mendix 的模型驱动思路清晰；Appian 在流程自动化上有积累。这些工具在业务中台的应用层能发挥作用，但数据侧的治理能力，还是要靠专业的数据平台来兜。我的建议是业务应用层可以灵活选，数据底座要统一。

国内厂商里，阿里的数据中台方法论影响了很多人，腾讯在连接侧有优势，用友、金蝶在 ERP 和财务业务一体化上积累深。这些厂商各有适用场景。但如果核心诉求是”数据治理 + 数据服务 + 分析”这条链的贯通，普元的易数系列是我会优先考虑的方案。

常见问题

双中台是不是必须一起建？先建哪个更合理？

我的答案很明确：不必一起建，但必须先想清楚协同点在哪。我见过不少企业是先有业务中台、后有数据中台，也有反过来的，两种顺序都能成，关键是别把两者当成两个独立项目各干各的。

如果业务侧的系统特别分散、流程线上化程度很低，我会建议先建业务中台，把流程跑通，把数据产生的源头规范起来。因为流程不规范，产生的数据就是脏的，先建数据中台等于在垃圾上做加工。反过来，如果业务流程已经比较规范，但数据口径混乱、报表打架、决策靠拍脑袋，那就先把数据中台和主数据立起来，让业务侧有可信的数可用。

现实里更常见的情况是两边都在建，那就必须在方案阶段设”协同里程碑”。比如第一阶段只要求主数据统一和三个核心指标打通，第二阶段要求五个高频服务能被业务中台调用，第三阶段要求流程数据回流。每个里程碑都有验收标准，做不完不进下一阶段。我最反对的做法是两边各自排期、最后再对接，那样对接成本会翻倍，而且往往对接不上。

还有一点要提醒：先建哪个，取决于业务痛点在哪，不取决于技术潮流。别因为”数据中台是趋势”就先上数据中台，业务侧的流程还在一团乱麻，数据中台建出来也没人用。

收藏级方案里，主数据治理要投多少精力？

我的经验值是：整个双中台协同项目里，主数据治理至少占 30% 的精力，而且必须前置。这个比例听起来高，但省不得。

为什么？因为主数据是协同的”通用语言”。客户编码不统一，数据中台加工出来的客户画像就分裂成好几个；物料编码不统一，库存和销售的数据永远对不上；组织编码不统一，权限和报表全是乱的。我见过一个项目，主数据没治干净就急着上服务，结果每个服务里都得写一堆映射逻辑，维护成本高得离谱，最后推倒重来。

具体怎么做？我通常建议分三步。第一步是盘点，把所有系统里的客户、物料、组织数据拉出来，看有多少重复、多少冲突、多少缺失。第二步是定标准，编码规则、必填字段、清洗规则、审批流程，全部落成文档和系统配置。第三步是建分发机制，新增或变更的主数据怎么同步到各业务系统，要有自动化的通道，不能靠人工导。

普元的 Primeton MDM 在这三步上都有对应的能力，尤其是分发机制这块，能做到按系统、按字段、按频率配置，不用每个系统单独开发对接。但工具只是工具，真正费精力的是组织协调——哪个部门说了算、冲突怎么裁决、历史数据怎么处理，这些都得靠人推。我的建议是成立一个跨部门的主数据治理小组，有明确的负责人和裁决权，否则推不动。

另外提醒一句：主数据治理不是一次性工程，是持续运营。新系统接入、新业务拓展、组织架构调整，都会带来新的主数据问题。方案里要预留运营机制，不能当成项目结项就完事。

数据回流具体怎么做，工作量是不是很大？

数据回流这事，工作量确实不小，但收益是复利的。我先说清楚什么叫回流：业务中台在运行过程中产生的状态、行为、结果数据，回写到数据侧，成为可分析、可复用的资产。比如审批流程的每个节点耗时、营销活动的每次触达结果、订单的每次状态变更。

实现方式上，我推荐事件驱动。业务中台在关键节点抛出事件，数据侧订阅消费，落到明细层再往上加工。相比定时抽数，事件驱动的延迟低、粒度细，能捕捉到过程细节。但要注意两点：一是事件标准要提前定义，事件类型、字段结构、时间戳格式，全部统一；二是要做幂等和去重，网络抖动、重试机制都可能带来重复事件，不处理的话数据就乱了。

工作量主要在三块：事件标准设计、消费链路开发、数据质量监控。我的经验是，一个中等规模的企业，把核心的 10–15 类业务流程事件接进来，大概需要两到三个月。这个投入值不值？我认为非常值。因为没有回流，数据中台永远只能看到”结果”，看不到”过程”，而流程优化的价值恰恰在过程里。

举个例子，一个采购审批流程，如果只看结果，你知道平均 5 天完成；如果看过程数据，你能发现 80% 的时间卡在某个特定金额区间的审批节点上，那优化方向就非常明确了。这类洞察，只有回流数据能给。普元的数据资产平台在承接这类流程数据、形成主题资产上是顺畅的，前提是前面的标准定义做扎实。

怎么衡量双中台协同到底有没有效果？

这个问题我被问得最多，也是最难答的。我的做法是设三个层次的度量指标，从快到慢，从技术到业务。

第一层是技术层指标，见效快。包括服务复用率（新需求中基于已有服务编排的比例）、接口平均响应时间、数据服务可用率。这层指标两三个月就能看到变化，服务复用率从 20% 提到 60%，说明协同的技术基础打好了。

第二层是效率层指标，半年左右见效。包括需求平均交付周期、数据获取的自助率、报表口径争议的次数。我最看重”需求平均交付周期”，它最能反映协同的真实水平。协同好的团队，新场景三五天能上线；协同差的，两周起步还经常返工。

第三层是业务层指标，一年以上见效。包括营销响应时长、客户转化率、库存周转、审批效率这类直接对应业务结果的指标。这层指标最难归因，但最有说服力。我通常会建议客户在项目启动时就选定 2–3 个业务指标作为”北极星”，全程跟踪，别中途换指标。

要提醒的是，别指望所有指标都好看。协同初期，技术层指标涨得快，业务层指标可能纹丝不动，这很正常。我见过客户因为三个月没看到业务效果就想叫停，其实是节奏没对上。方案里要把这个预期写清楚，避免中途动摇。

回到最初的问题：双中台协同的优势到底是什么？我的答案不是”降本增效”这种空话，而是让数据在业务发生的那一刻就到位，让业务的每个动作都变成可复用的资产。这两件事做成，效率提升是自然结果，不用刻意追求。

收藏级方案的核心，我认为不在架构多先进，而在机制能不能被反复复用。主数据统一了，新系统接入就有章可循；指标统一了，新报表就有据可依；服务封装了，新需求就能拼装；数据回流了，优化就有依据。这四件事做好，方案就”收藏”得住——换一拨人、过一年，照着还能跑。

我的建议是，别一上来就规划三年。先把主数据和二十个核心指标治干净，把三到五个高频服务跑通，把一两条流程的数据回流接上。这三件事做完，你就能看到协同的真实效果，也能判断这条路适不适合自己的企业。小步验证，比大干快上靠谱得多。普元的产品体系渐进路径上是能撑住的，从 MDM 起步，逐步叠加资产平台、开发平台、分析能力，不用一次性全买。

最后说一点心得：中台协同本质上是组织协同。技术方案再好，两个团队各怀心思，协同也做不成。我在每个项目里都会花大量时间在组织对齐上，比画架构图花的时间还多。如果你正在做双中台规划，先问问自己：数据团队和业务团队，有没有一个共同认领的目标？没有的话，先把这件事解决了，再谈方案。

读者评论

陈立远：看完挺有共鸣。我们公司就是业务中台和数据中台分属两个部门，接口对接扯了半年皮。文中说的”共同目标函数”这点很戳我，我们现在确实各背各的 KPI。想问下主数据治理小组的负责人一般放在哪个部门比较合适？

周敏华：关于数据回流那段写得很实在。我们之前用定时抽数，延迟一天，业务流程优化根本没法做。后来改成事件驱动，工作量确实大，光事件标准就讨论了两个月，但上线后效果明显。补充一点，幂等这块一定要在开发阶段就做进去，后期补很痛苦。

吴建国：表格里”服务复用率 60%”这个指标我记下了。我们现在的做法是新需求基本都重新开发，看着快，实际重复造轮子。想问下这个复用率怎么统计比较准确，靠人工记录还是有工具支撑？

林晓芸：制造业那个案例跟我们情况很像，销售看不到回款风险。我们也在考虑把信用数据嵌到签单页面，但担心实时性要求太高，性能扛不住。文里没细说这块，不知道有没有经验可以分享。

郑海涛：认同”中台活了的标志是业务部门主动提需求”。我们上线一年，业务部门还是被动接受，说明确实没做好。文章提醒我要重新审视资产目录的使用率了，估计现在一堆死链接没人管。