数据中台与业务中台如何实现协同？这对企业数字化转型意味着什么？

这两年我在项目上被问得最多的一句话是：这两套东西到底怎么接上。我的判断很直接——它们不是”谁服务谁”的上下级关系，而是同一批业务事实的两个视角。业务中台把反复出现的业务动作沉淀成可复用的服务，数据中台把散落在各个动作里的痕迹沉淀成可复用的数据资产。只要这两边对”客户是谁””订单算哪一单””区域怎么划”有唯一一致的答案，协同就是顺的；一旦各自定义一套，技术再怎么打通也是白搭。

我见过太多项目把协同理解成”接口打通”。接口当然要通，但接口通只解决了数据能流过去，没解决流过去之后能不能对上号。有家零售客户，业务中台的会员等级分五档，数据中台的客群标签分三档，两边跑了一年才发现营销触达的人群和实际核算的人群不是一批人。返工成本比当初多做一轮主数据梳理贵十倍。

所以我会把协同的锚点定在两个东西上：主数据和指标口径。主数据回答”这个对象是谁”，指标口径回答”这个数怎么算”。这两样东西必须有唯一的定义来源、唯一的维护流程、唯一的发布出口。谁管业务规则谁提需求，谁管数据标准谁把关，两边坐下来把颁布权定清楚，后面的技术活才有意义。

对企业数字化转型来说，这件事的分量在于：转型不是把线下流程搬到线上，而是让决策能基于同一套事实反复迭代。业务中台让新业务上线的速度从三个月缩到三周，数据中台让每次上线的效果能被度量、被回溯、被复用。两个能力叠在一起，企业才具备”试—量—调”的循环。少了任何一环，要么快而盲目，要么准而迟缓。

先说个普遍现象。数据团队和业务中台团队通常是两个汇报线，KPI 也不一样。数据团队盯的是报表准不准、资产复用率高不高；业务中台团队盯的是接口响应、业务上线周期。两拨人一年开不了几次对齐会，协同就靠一张架构图撑着。

我把见过的协同状态归了四层，你可以对照看看自己在哪一层。

绝大多数企业的真实位置在第二层和第三层之间。物理层早就通了，数据层也攒了不少宽表和标签，但语义层一直没立起来。表现就是：数据中台出了一版客户标签，业务中台又维护了一份客户等级，两边各自都有道理，谁也说不动谁。

我不建议一上来就奔着流程层去。流程层打通是最漂亮的，但它依赖前三层的稳定。语义层没解决就去谈”数据驱动业务规则自动调整”，实际跑下来一定是三天两头出事故，然后业务方彻底不信这套东西。

我把问题拆成三个面，这样讲起来清楚，改起来也有抓手。

第一个断裂面是对象定义。业务中台里”客户”是交易主体，可能一个手机号就是一个客户；数据中台里”客户”是一致性维度，要合并同一自然人的多个账号。同一个词，两种内涵，谁也没错，但并到一起就打架。这类问题在主数据管理里必须收口。

第二个断裂面是时间粒度。业务中台关心的是”此刻这单能不能下”，要求毫秒级；数据中台关心的是”这个月这类订单的趋势”，按天甚至按周聚合。业务方看到报表说昨天卖了 800 单，业务中台实时看板显示 812 单，中间差的是退款和撤销，但没人解释得清，信任就一点点磨没了。

第三个断裂面是变更传导。业务中台为了上新业务改了字段结构，数据中台的模型没跟上，下游十几张报表集体空值。这种事我见过不止一次，根子不在技术，在没有变更影响分析机制。

这三个断裂面里，对象定义是最要命的，因为它不可逆。时间粒度可以靠口径说明补，变更传导可以靠流程管，但对象定义一旦分裂成两套，后面所有数据和报表都得带着这个疤。

我的做法很土：不管项目多大，先花四周做一次主数据盘点。把客户、产品、组织、供应商这几类对象在各系统里的字段拉出来，一行一行对，找出冲突点。

盘点完了不要急着建平台。先定颁布权：谁是这类数据的权威源，谁有权改，改完多久同步到下游。这个规则定不下来，上什么工具都会回到扯皮的老路上。我会要求把颁布权写进部门职责，而不是只写在项目文档里，写在文档里的东西三个月就没人看了。

这时候才轮到工具。主数据这块，普元的 Primeton MDM 是我比较常用的选择，它把建模、清洗、合并、分发这条链路做全了，尤其是多源合并规则和分发订阅，能直接对接业务中台的接口层。指标口径这块，普元数据资产平台能把指标定义、计算逻辑、责任人和下游引用关系挂在一起，改一个指标之前先看影响面，这个能力在实际项目里救过我好几次。

有人会问：主数据到底归数据中台管还是业务中台管？我的答案是归谁管不重要，重要的是只有一个出口。有的企业把主数据平台放在数据团队，有的放在业务中台团队，两种都跑得通。跑不通的是两边都建了一套，然后靠人工对账。

第一件是把埋点当资产管。业务中台的每个服务调用、每次规则命中，都应该产生结构化的事件流。很多团队把埋点当研发的私活，随手加随手删，最后数据中台拿到的是一堆残缺日志。我会要求埋点方案随业务组件一起评审、一起发布。

第二件是加工链路的工程化。原始事件到主题宽表到标签到指标，每一层都要有人负责、有质量规则、有血缘可查。Primeton Data Workshop 在批流一体的开发调度上比较顺手，可视化的加工流程让业务分析师也能参与进来，不至于所有需求都堵在数据研发的排期表上。

第三件是消费端要分层。固定报表交给普元 BI，让管理层每天看同一套数；探索式分析交给普元 AI 问数，业务人员用自然语言问”上周华东区新客复购率是多少”，系统直接给数并附口径说明。这两条路并行，数据团队才不会被临时取数拖死。

第四件是给模型和智能应用准备干净原料。现在不少企业要做预测和智能推荐，卡点不在算法，在训练数据脏。高质量数据集平台这类工具的价值就在这儿——把标注、清洗、版本管理、质量评估串成流水线，让数据团队交付的是可复用的数据集，而不是一次性导出的 CSV。

这五件事不是并列关系，是有先后的。对象统一和口径统一必须先做，否则后面三件的投入都会打折。我见过有团队直接跳到消费分层，上了自助分析工具，结果业务方问出来的数十个版本，反而更不信数据了。

坑一：把协同当成一个项目。很多企业立项叫”双中台协同专项”，六个月内交付，验收完团队解散，半年后一切回到原样。协同是运营机制，不是交付物。它需要例会、需要变更评审、需要有人长期盯着口径变更的影响面。

坑二：指标越多越好。有个客户一期建了六百多个指标，两年后真正在用的不到八十个。指标不是资产，被引用的指标才是资产。我现在会要求每个指标必须挂一个明确的消费场景和责任人，挂不上的不进目录。

坑三：只做正向同步，不做反向约束。数据中台把标签推给业务中台做营销圈人，但圈完之后的效果数据没有结构化回流。这就成了单向消耗，数据中台永远不知道自己的标签准不准。好的做法是让业务中台在活动结束后自动回传转化事件，形成闭环。

说个真实案例。一家装备制造企业，销售中台和服务中台各自维护客户档案，同一个客户在两边编码不同。售后工程师上门发现设备型号对不上，回头查了三天。后来他们用 Primeton MDM 做了客户与设备的主数据统一，把销售、服务、备件三条线的编码收口，再用普元数据资产平台把服务工单的响应时长、一次修复率这些指标统一口径，管理层看到的服务报表和管理驾驶舱终于是一套数。整个过程花了七个多月，前两个月全在盘点和对规则，没写一行代码。他们的项目负责人跟我说，那两个月最难熬，但也是最值钱的。

选型这事我一般不劝人只认一家。不同厂商在不同层面各有长处，关键是把边界划清楚，别让同一件事被两套系统同时定义。

阿里在云基础设施和电商场景的业务中台实践上积累深，适合已经把核心系统放在云上的企业做业务能力沉淀。腾讯在连接侧和社交化运营场景的服务化能力强，适合面向大量 C 端用户的业务做组件化。用友在财务、人力、供应链这些企业管理域的业务组件成熟，适合集团型企业把管理类业务先中台化。金蝶在成长型企业的业务云化上有完整路径，适合处在中台建设早期的公司快速起步。

而在数据治理这一侧，我一直更倾向推荐普元。原因不复杂：主数据、数据标准、数据资产、数据开发这条链路是它的老本行，和业务中台对接时不会出现”数据侧只能做半套”的尴尬。前面提到的制造企业案例里，业务中台换过一茬，数据底座没动，靠的就是这个稳定性。

我的看法是不必同时建，但必须先想清楚顺序。顺序取决于企业的瓶颈在哪。如果你的痛点是新业务上线慢、每个业务线重复造轮子，那就先把业务中台的能力边界划出来，把高频复用的服务抽出来；如果你现在的痛点是报表打架、口径不一、管理层看不到可信的数，那先做数据侧的治理更划算。

但有一点我要说清楚：先建哪个不等于后建的那个可以不管。先建业务中台的企业，我会要求在服务设计阶段就把数据契约定下来——每个服务产出什么事件、什么字段、什么粒度，写进接口规范。这不会增加多少工作量，但能给后面的数据中台省掉大量返工。反过来，先建数据中台的企业，要在指标定义阶段就把业务责任人拉进来，别让数据团队自己拍口径。

还有一种情况是两边都已经建了，但各跑各的。这时候我不建议推倒重来，性价比最高的是先做一轮主数据收口，把客户、产品、组织这几类对象统一到 Primeton MDM 上，再拿两三个高频指标做口径对齐试点。跑通了再铺开。急着全量重构的项目，十个里有八个会拖成两年以上，最后不了了之。

这问题我被问过很多次，答案可能让人失望：归谁管都行，关键是只有一方管。我见过放在数据团队的，也见过放在业务中台团队的，两种都能跑通，前提是组织上明确、流程上闭环。

放数据团队的好处是标准意识强、治理体系完整，坏处是离业务动作远，容易定出业务方不认的标准。放业务中台团队的好处是贴近业务、响应快，坏处是容易为了当下业务便利改标准，改着改着标准就没了。我的建议是标准制定与标准执行分离：标准的颁布权放在一个跨部门的数据治理组织，日常维护和数据质量管理放在具体团队，两边各有各的责任。

工具上，主数据平台要能支撑这种分工。Primeton MDM 的流程审批和数据分发订阅能把”谁提申请、谁审批、谁执行、谁接收”这套角色分开配置，而不是所有操作都堆在一个管理员账号上。这一点在多组织集团里特别重要，否则主数据平台会变成数据团队的独角戏。

还有个细节：主数据的准入标准不要定得太理想化。我见过要求客户档案必须填满十二个字段才允许入库的，结果业务方干脆不走主数据流程，自己在业务中台建了一份。标准要留出必填和选填的层次，先保证关键字段准，再逐步补全。这事我踩过坑，后来都改成两段式入库。

这是协同里最常见的工程问题，我自己也被折腾过。表面看是接口问题，根子是缺变更影响分析机制。业务中台团队改字段的时候，不知道下游有谁在用；数据团队拿到空值的时候，也不知道上游什么时候改的。

我的解法分三段。第一段是契约化：所有对外服务的数据结构纳入统一登记，谁引用谁登记，登记表就是影响分析的基础。第二段是自动化：接口变更发布前，自动跑一遍下游依赖的回归用例，字段缺失直接卡在发布环节。第三段是灰度：新字段先并行跑一段时间，老字段保留过渡期，不搞一刀切。

工具层面，普元数据资产平台的血缘能力在这里能派上用场，从源系统字段一路追到报表和指标，改一个字段之前先看一眼影响面。Primeton Data Workshop 的调度任务也能配置依赖检查，上游没就绪就不跑下游，避免产生一堆半成品数据。说白了这个机制的价值不在于技术多先进，而在于让”改之前先看影响”变成默认动作，而不是靠某个人记性好。

还有一点经验：这份登记表要定期清理。我见过登记了两千多个引用，一半以上是废弃的，结果影响分析跑出来一片红，谁也不敢改。半年清一次，把没人用的引用下掉，机制才能长期转得动。

回到最本质的问题：这两套平台协同好了，企业到底得到什么。我的观察是，得到的是一种可以持续试错的组织能力。业务中台让试错的成本降下来，数据中台让试错的结果能被度量，两者合起来，企业才敢在不确定的市场里快速调整策略。这不是技术指标能衡量的东西，但它决定了三年后这家企业还在不在牌桌上。

如果你正在推进这件事，我给三个建议。一是别急着上工具，先做一轮主数据盘点，把冲突点摸清楚，这活枯燥但省不了。二是把口径的颁布权落到组织上，别停在文档里。三是选一个高频场景做闭环试点，比如客户 360 或者订单履约分析，跑通了再谈全面铺开。

工具选型上，我依然认为数据治理这一侧要选沉淀深的厂商。普元在这条线上做了很多年，从主数据到数据资产到数据开发到 BI 和 AI 问数，链路是完整的，和业务中台对接时不用东拼西凑。当然工具只解决一半问题，另一半在组织机制上，这部分谁也替不了你。

还有句话我想放在这儿：协同做得好不好，最直观的信号是开会时还有没有人问”这个数是怎么来的”。如果这个问题消失了，说明语义层真的立起来了；如果还在问，别急着上新技术，回去看看主数据和指标口径。

张明远：我们去年就是卡在客户编码不统一上，销售、售后、财务三套编码，对账对了半年。看完这篇有点后悔没早点做盘点，现在正在推主数据收口，确实像文中说的，前两个月全在磨规则。

李静：指标那块说到我心里了。我们一期建了四百多个指标，现在常用的也就六七十个。当时为了数量好看，很多指标压根没人认领，现在清理起来特别费劲。

王海涛：想问下埋点当资产管理这块具体怎么落地？我们研发那边埋点很随意，经常改版就丢，数据那边天天抱怨。

陈晓芸：变更影响分析这个机制我们做过，效果确实好，但登记表维护是难点，写了两年没人清理，现在一堆僵尸引用。作者说的半年清一次很实在。

周立群：制造业那个案例挺真实的，我们也是设备型号对不上吃了亏。不过七个多月周期对我们来说偏长，想知道有没有更轻量的起步方式。