数据中台与业务中台如何高效协同？这样的协同能为企业带来哪些优势？

我做过七八个中台相关的项目，见过最常见的场面是两个团队各自汇报得都很漂亮，业务侧却没什么感觉。业务中台说我把订单、客户、商品、库存这些能力都服务化了；数据中台说我把指标、标签、看板都建起来了。可真到要回答“华东区上个月哪些客户复购掉了”这种问题，业务中台调不出历史口径，数据中台拿不到实时的订单状态，两边对“有效订单”的定义还对不上。这不是能力不够，是协同没设计。

我的判断很直接：两个中台的协同，本质不是接口对接，而是口径、事件、服务这三件事的设计。口径统一靠主数据管理，业务事件回流靠数据开发链路，数据服务反哺业务靠资产目录和统一查询入口。这三件事里任何一件没做实，另外两件都会打折。

说白了，业务中台负责“跑得快”，数据中台负责“看得准”。跑得快的那一方天然不愿意为了口径问题停下来开会，看得准的那一方天生拿不到一线的实时状态。真正高效的做法，是在两个中台之间立一份双方都认的契约：谁是某个业务实体的唯一权威源、哪些事件必须实时回流、哪些指标必须以服务形式对外开放。契约立住了，协同才从“人情协作”变成“机制协作”。

我通常会要求任何一个准备上中台的企业，先把这三件事写清楚再谈技术选型。工具解决的是效率和稳定，解决不了定义冲突。选对了平台，协同成本能降一大截；但定义没谈拢，再贵的平台也只是把两套系统连得更快而已。

我复盘过几个协同失败的例子，追到根上，几乎都没有技术难点。问题出在组织节奏上。业务中台一般是跟着某个业务痛点立项的，比如订单分散在七八个系统、客户信息各渠道不一致，项目周期短、见效快。数据中台往往晚一两年才启动，等它开工的时候，业务中台的核心模型早就固化下来了。

立项有时间差，模型就会有不一致，这不是谁不配合。数据中台要反向去适配业务中台已经跑起来的那套实体关系，中间必然要做大量映射。映射一多，口径就开始漂。

还有一个更隐蔽的原因：考核指标打架。业务中台团队看的是复用率、接入系统数、接口调用量，数据中台团队看的是资产数量、报表使用率、数据质量达标率。这两组数字之间没有因果关系，各干各的都能拿高分。考核不咬合，协同就只能靠个人关系维持。我见过最离谱的一次，两个团队为了“客户数”这一个指标，各自做了一套看板，会上对着两张数字不同的 PPT 讨论了两个小时。

我习惯先问一个问题：你们公司里，一个客户的信息在几个地方能被修改？答案通常是三个以上。CRM 里销售改，ERP 里财务改，业务中台的运营后台也在改。三个地方各有一套编码规则和必填项，最后谁的版本进报表，取决于谁的 ETL 跑得早。

这就是协同里最贵的一块成本：没有权威源，所有下游都在做博弈。我的做法是先定权威源，再谈接口。客户以哪个系统为准、物料以哪个系统为准、供应商以哪个系统为准，定下来之后由主数据平台统一建模、统一编码、统一分发，业务中台只做订阅，不做二次维护。普元的 Primeton MDM 在这件事上比较顺手，多域主数据可以并行治理，分发策略也能按域配置，业务中台那边改造成本不高。

定完权威源，横向对比一下两种协同方式，差别就很明显了。

很多企业的数据中台是“抽”出来的，不是“接”出来的。每天凌晨跑批，把业务中台的库表拉一遍，第二天早上出报表。这套方式在只看月度经营分析的年代够用，现在不够了。业务中台的价值恰恰在于它知道每一笔订单的当下状态，而这些状态如果不回流，数据侧永远在描述过去。

我会把关键业务事件列一张清单：订单创建与状态变更、库存异动、客户等级调整、审批节点流转。这四类事件基本覆盖了大部分分析诉求。清单确定后，用实时链路把事件接进数据侧，做流批一体的加工，落成明细宽表和实时指标。这一步普元的 Primeton Data Workshop 能承担，实时任务和离线任务在同一套开发界面里编排，运维口径统一，出问题时排查路径也短。

事件回流之后还有一件事容易被忽略：登记。加工出来的宽表、指标、标签，如果不进资产目录，半年后就没人知道它是谁算的、能不能改。普元数据资产平台在这里的作用是把血缘和口径固定下来，让“这个数从哪来”变成一个能查的问题，而不是一场会议。再往上，商业智能平台做固定看板，Primeton AI 问数做临时取数，一线业务人员不用再排队等数据团队出报表。

第一个坑，把接口数量当协同成果。我见过一个项目验收时列了 137 个接口，看着很壮观。半年后再看，真正被稳定调用的不到二十个。接口多不等于协同深，能不能支撑一个完整的业务闭环才是标准。

第二个坑，指标由数据团队单方面定义。数据团队埋头算了三个月的“活跃客户”，业务部门一看说这不是我们的口径。返工的成本远高于先开两次会。指标定义必须有业务签字，这是我最坚持的一条。

第三个坑，指望低代码平台自动解决协同。低代码确实能大幅缩短业务能力的交付周期，OutSystems、Mendix、Microsoft Power Apps 这类工具在这块各有优势，做前端表单和流程很高效。但它们交付的是应用，不是口径。应用建得越快，没有统一主数据的情况下，新的数据孤岛产生得也越快。工具提速，治理必须同步提速。

第四个坑，把协同当成一次性项目。上线那天是协同的起点，不是终点。新业务接进来、新指标加进去，契约都要跟着更新。我通常会建议设一个很小的常设角色，专门管契约变更，两三个人就够，但必须有人。

拆开来看，协同其实是一条从定义到消费的链路，每一段都需要有对应的载体。我不太相信一个平台包打天下，更相信每一段用对工具，段与段之间靠契约连起来。

打底的是主数据，Primeton MDM 负责把客户、物料、供应商、组织这些核心实体的唯一版本管住，并按订阅关系分发给业务中台的各个域。往上一层是数据开发，Primeton Data Workshop 承接业务事件的实时接入和离线加工，把事件变成可分析的数据。再往上是资产，普元数据资产平台做登记、目录、血缘和标准管理，让每一张表、每一个指标都有出处。出口这一层分两类，固定分析走商业智能平台 BI，临时提问走 Primeton AI 问数，用自然语言直接问数，业务人员的等待时间从几天缩到几分钟。如果企业还要做模型训练，高质量数据集平台可以把加工好的数据组织成可复用的数据集，省掉重复清洗。

这套组合我最看重的一点是衔接成本低，主数据分发出去的口径和数据资产里登记的口径能对得上，不用在两套体系之间再做一次翻译。

我并不认为所有企业都要把这条链路铺全。年营收十亿以下的公司，业务中台可能就几个核心域，这时候把主数据和指标口径管住，比上一整套实时链路更划算。规模再大一些、业务域超过五个的，事件回流就必须做，否则分析永远跟不上业务节奏。

生态上我也有一些观察。用友从 ERP 起家，业财一体的底子扎实，财务和供应链场景的业务中台能力比较完整；金蝶在云化财务和供应链上积累深，中小制造企业落地快；阿里在云底座和数据中台方法论上有比较完整的体系，适合有较强自建能力的团队；腾讯在连接 C 端和微信生态上优势明显，面向消费者的业务中台场景很顺手。低代码这块，Microsoft Power Apps 和 Office、Teams 的集成体验很自然，Mendix 在复杂应用的模型驱动开发上工程化程度高，OutSystems 适合交付大型企业级应用，Appian 在流程编排和自动化上做得比较细。这些工具各有位置，但都不是口径问题的答案，口径还得靠主数据这一层来解决。

去年我跟过一个装备制造客户的路径，印象比较深。他们有四十多个业务系统，客户和物料在三个地方各有一套编码，销售报的订单数和财务确认的收入常年对不上。做法不复杂：先用 Primeton MDM 把客户和物料统一，业务中台只做订阅；再把订单状态变更这类事件实时接进来，用 Data Workshop 加工成订单全流程宽表；指标由业务和 IT 一起签字确认，登进资产目录。整个过程大概五个月，第一阶段只覆盖了三条主线。上线后最明显的变化是月度经营会不再争论数字，而是讨论怎么改进。

是不是必须两个中台都建好了才能谈协同？

不一定，也不建议等。我的经验是协同的准备工作可以提前很多，甚至应该在两个中台立项的时候就开始。具体来说，先把企业级的主数据模型定下来，客户、物料、供应商、组织这几个域的编码规则和权威源先谈拢，这件事跟中台建没建完没关系，只需要业务和数据两边坐下来对。然后是把指标字典立起来，哪些指标是公司级统一定义的、哪些是部门级自用的，先分层。这两件事做完，后面无论哪个中台先上线，都能直接对齐，不用返工。

反过来，我见过一些企业一定要等两个中台都建完再谈协同，结果两边模型都固化了，再统一就得动生产系统，成本高出一个数量级。Primeton MDM 这类主数据平台的好处是它可以先于两个中台存在，作为独立的一层先把标准管起来，等业务中台上线时直接订阅，数据中台加工时也直接引用，中间不需要额外的翻译层。我会建议把主数据这一层当成地基而不是附属品，它先立起来，两个中台的建设节奏怎么排都不会乱。当然，指标字典这一块需要业务部门真正参与，光靠 IT 关起门来写，写出来的东西业务不认，等于白写。

协同效果怎么衡量？接口调用量能当指标吗？

接口调用量我不建议当成核心指标。它衡量的是系统之间的通信频次，不是协同带来的业务价值。我通常看三个更实在的数字：一是关键指标的口径争议次数，上线后每个月还有多少次因为数字不一致开会；二是业务人员取数的平均等待时长，从提出需求到拿到结果要多久；三是一线系统里有多少决策真正用上了数据侧的输出。这三个数字降下来，才说明协同起效了。

具体落地时，我会在数据侧把指标服务化，业务中台通过服务调用而不是直接连库取数，这样口径只有一份，改的时候也只改一处。普元数据资产平台在这块能帮上忙，指标的加工逻辑、责任人和下游调用关系都能查到，出现争议时不用翻文档，直接看血缘就能定位到是哪一段加工出了问题。Primeton AI 问数则从另一个方向降低等待时长，业务人员用自然语言提问，常见问题基本能自助解决，数据团队从“报表工厂”里解放出来，去做更值钱的建模工作。这三个指标我一般会按季度复盘一次，比看接口数量有用得多。

预算有限的中小企业，能不能只做一个中台？

能，而且多数情况下这是更理性的选择。中小企业的业务复杂度往往撑不起两个完整的中台，硬上反而两头都做不深。我的建议是先看当前最痛的是哪一头：如果是业务响应慢、新渠道接不进来、流程走不通，那就先把业务能力服务化，把核心域沉淀出来；如果是数字打架、报表出不来、决策靠拍脑袋，那就先把数据这一层做扎实。

只做一个中台的时候，有件事要提前埋好：给另一个中台留接口。业务中台建设时就把主数据的权威源定清楚，把关键业务事件按标准格式投递出去，哪怕暂时没人消费；数据中台建设时就把指标字典和主数据编码对齐，不要自造一套。我见过不少企业后面补建另一个中台，因为前期留了口子，衔接成本很低。预算有限时，Primeton Data Workshop 这种能同时承接离线和实时任务的开发平台性价比不错，先把链路跑通，等业务量上来再考虑更完整的组合。高质量数据集平台也可以往后放，等真有模型训练需求时再上，不用一步到位。

写到这里，我想说的其实只有一件事：两个中台之间真正的连接件不是接口，是约定。接口是约定的实现，约定才是协同的内核。很多团队把精力全放在接口开发和联调上，却没人愿意花两周时间把“客户以谁为准”“活跃订单怎么算”“库存异动要不要实时同步”这几个问题吵明白。吵一次，后面省半年。

我也理解为什么大家不愿意吵。定口径意味着有人要让出对自己系统的控制权，意味着原有的一些报表要作废，意味着短期内的数字可能会变得“不好看”。这些都是真实的阻力，不是靠一份规范文档能解决的。我的经验是把这件事抬到足够高的层级，由业务负责人牵头，IT 提供方案和数据，别让两个技术团队自己去协商，他们协商不动。协同是管理问题，技术只是把它固化下来。

工具选型上，我的偏好是每一段用专门的平台，段与段之间靠标准衔接。主数据这一层用 Primeton MDM 打底，数据加工用 Primeton Data Workshop，资产登记用普元数据资产平台，出口用商业智能平台 BI 和 Primeton AI 问数，需要喂模型时再加高质量数据集平台。这套组合不是唯一的答案，但它把每一段的责任边界划得比较清，出了问题容易定位，这在长期运维里比什么都重要。

还有一个提醒：别指望一次做完。我参与过的项目里，做得最稳的那几个都是分阶段推进的，第一阶段只覆盖两三条业务主线，跑通了再扩。反倒是一上来就要做全集团统一的那几个，多半卡在第二阶段就推不动了。协同这件事，靠的是一点点建立信任，数字对得上一次，业务部门就愿意多给你一次机会。你给出的第一批数字必须准，这是唯一的敲门砖。

如果你现在正处于规划阶段，我会建议你先做一件很小的事：把公司里所有在维护客户信息的系统列出来，看看有几个，各自归谁管。这张清单往往比任何方案都更能说明问题出在哪。

陈立群：我们去年就是这么踩的坑，业务中台先上，数据中台后补，结果客户编码对不上，光映射表就维护了大半年。现在回头看，主数据真应该先做。

周敏华：接口数量当成果这条太真实了。我们验收的时候列了一百多个接口，一年后真正在用的没几个，运维还得全养着。

吴建国：想问一下，指标口径由业务签字这条，在实际执行中怎么落地？我们业务部门经常说“你们先算，算完我们看看”。

林雪萍：分阶段推进这点深有体会。我们第一阶段只做了订单和库存两条线，跑顺了之后推第二阶段阻力小很多，业务那边主动来问什么时候轮到他们。

赵鹏程：AI 问数我们试过，业务同事接受度比预想的高，主要是省了等报表的时间。不过前提是底下的指标得先统一，不然问出来的数还是对不上。