双中台协同是什么？如何打造收藏级方案以提升企业效率？

去年下半年我参与一家装备制造企业的架构复盘，会议室白板上写着”业务中台＋数据中台”，下面两行字很扎眼：业务中台跑了两年，数据中台跑了一年半，两边都宣布上线了，可业务部门想拉一个”客户近90天履约情况”的视图，还得等数据团队排期两周。这种场面我见过太多次。双中台协同的本质，不是两个平台之间多写几个接口，而是”业务动作沉淀成数据资产、数据资产再回到业务现场”这个闭环能不能自己转起来。闭环转不动，两个中台建得再漂亮，也只是两套昂贵的系统，年度汇报时好看，日常使用时扎心。

我对”收藏级”这三个字有自己的理解。它不是方案书写得多厚、PPT 做得多精美，而是这套东西能不能被反复拿出来用：新业务线上线时，不用重新定义客户、物料、组织这些基础对象；新来的分析师拿到指标，不用先花三天问口径；业务系统里的一次操作，能自动变成数据资产的一部分，而不是靠人每周导数。说白了，方案的价值不在于一次性交付了多少张报表，而在于它被复用了多少次、被改动了多少次、被多少人绕开过。

这篇内容我想把真实项目里的判断逻辑摊开讲。哪些环节必须前置、哪些钱可以先不花、什么阶段该抓主数据、什么时候该上可视化开发平台、业务部门不配合时怎么破局，这些都是我踩过坑之后才想明白的。文中会提到普元在数据侧的几款产品，它们在我的方案里承担什么角色，我会讲清楚为什么放在那个位置，而不是简单罗列。看完全文，你应该能自己画出一张适合自家企业的双中台协同草图。

很多人把双中台协同理解成”业务中台和数据中台之间打通接口”，这个理解偏了。业务中台沉淀的是业务能力——客户中心、商品中心、订单中心、履约中心，它管的是业务过程怎么跑；数据中台沉淀的是数据能力——采集、加工、资产化、服务化，它管的是数据怎么变成可用的资产。协同发生在四个层面：主体统一、事件沉淀、指标一致、数据回灌。四层里缺一层，闭环就漏气。

主体统一指的是客户、供应商、物料、组织这些核心对象只有一个权威来源，业务中台不能自己另起一套编码。事件沉淀指的是下单、发货、退款、工单关闭这些动作发生时，数据侧要能第一时间拿到，而不是月底靠批量补数。指标一致最好理解也最难做，同一个”活跃客户”，销售部、财务部、运营部各有一套算法，开会就得先吵半小时。数据回灌是最容易被忽略的一层，数据加工出来的标签、评分、预警，要能嵌回业务系统的界面里，让业务员在干活的时候顺手看见，而不是让他再登一个 BI 门户。

我把这四层职责拆成一张表，做项目时直接拿去和业务方对齐，比讲概念管用得多。凡是表格里”协同要点”这一列没人认领的，就是后面一定会出问题的地方。

双中台怎么连，业内做法大致能归成几类。接口直连式最省事，业务中台直接调数据中台的接口取数，两个月就能跑起来，我见的试点项目十有八九这么干。数据集市式是数据侧批量抽数建集市，报表出得快，但两边的口径很容易分叉，一年后你会发现三个部门三套数。主数据驱动式见效最慢，得先把客户、物料统一了再谈别的，可它是唯一能规模复制的路子。事件驱动式适合有实时决策诉求的场景，比如风控预警、库存调拨。

选哪种，不看技术先进程度，看企业现在处在什么阶段。刚起步就上事件驱动，是给自己找麻烦；已经到了多业务线复制阶段还停在接口直连，那就是在给自己挖坑，接口数量会以肉眼可见的速度膨胀。我的建议是分阶段演进，而不是一次性选型定终身。

下面这张对比表是我做方案时常用的底稿，把四种方式的代价摆开，管理层一眼能看明白为什么主数据要前置。实际跑下来，绝大多数企业的路径是”接口直连起步—集市过渡—主数据收口”，中间那段最难熬。

连不通的原因，技术占三成，组织和标准占七成。我梳理过十几个项目，反复出现的问题就那么几个。头一个，主数据没人管。客户在 CRM 里一套编码、在 ERP 里一套、在电商平台还有一套，数据中台只能各建一张表，业务中台一取数就对不上。主数据不定源头，后面所有协同都是在沙子上盖楼。

第二个，指标没有评审机制。业务部门提需求，数据部门埋头开发，上线三个月后业务说”这不是我要的数”，回头改口径，历史数据没法回溯。第三个，数据加工过程不透明，几十个开发人员在同一个库里各写各的任务，出问题查血缘要查两天。第四个，也是我最想提醒的——把双中台协同当成一个 IT 项目，而不是一个业务机制。没有业务负责人参与的项目，交付那天就是没人用的那天。

几个常见误区我列一下，都是我亲眼见过踩进去的。误区一：以为买个平台就自动协同了，工具能提供能力，但编码规则、口径定义还得靠人定。误区二：一上来就追求实时，结果实时链路投入巨大，业务真正需要的其实只是 T+1。误区三：把数据中台做成报表工厂，需求排队排到三个月后，越做越被诟病。误区四：只做入湖不做回灌，数据只进不出，业务端感受不到价值，第二年预算就难批了。

我的经验是，凡是能用”机制”解决的问题，别用”技术”去绕。口径争议靠评审委员会解决，不是靠多建几个宽表；权责不清靠双负责人制解决，不是靠多写几份文档。

标准一是主体可复用。新业务线上线时，客户、商品、组织这些对象能不能直接拿来用，而不是重新建模。这一条如果做不到，所谓的中台就退化成了一批定制系统。标准二是加工过程可追溯，任何一个指标出问题，能顺着血缘找到源头表和责任人，这件事必须在方案里写死，不能靠事后补文档。

标准三是业务现场可见。数据团队做的标签、预警、评分，最终有没有出现在业务员每天用的界面里。标准四是取数门槛足够低，业务人员提一个常规问题，能不能自己拿到答案，而不是每次填单排期。

这四条里我最看重第四条，因为它直接决定了数据中台的口碑。我见过一个集团，数据资产盘点做得极细，血缘图画得漂漂亮亮，可业务经理想看个”上月各区域回款进度”，还是得走提数流程。数据可用性不是资产目录有多少张表，而是业务人员能不能在三十秒内拿到答案。

落到工具上，这个环节我会推荐普元的 AI 数据分析平台。它做的事情是把自然语言的提问翻译成对指标和明细的查询，业务人员问”华东区哪些客户最近两个月没下单”，不需要写 SQL，也不需要理解表结构。当然前提是底层的指标口径和数据资产已经梳理干净，这也是为什么我总把主数据和指标治理放环节前面。

如果让我从零搭一套双中台协同方案，我会按”主数据收口—资产盘点—开发治理—指标服务—智能消费”这条线走。主数据是地基，普元的主数据管理平台（Primeton MDM）位置承担的是建模、清洗、分发三件事，把客户、物料、供应商的唯一编码定下来，再自动同步给业务中台各中心。这一步做扎实，后面所有环节的返工率能降一大截。

资产盘点是第二步。普元数据资产平台在这里负责的是把散在各处的表、字段、指标编成目录，打上责任人标签，形成血缘关系。我通常要求项目组把”每张核心表有没有责任人”作为验收项，没有责任人的表不许进目录。第三步是数据开发治理，Primeton Data Workshop 把开发、调度、运维放到一个界面里，谁写的任务、什么时候跑、跑失败了谁收到告警，全都留痕。

指标服务和智能消费是最后两个环节。商业智能平台承担指标定义与看板呈现，普元 AI 问数承担自然语言取数，高质量数据集平台则面向有模型训练需求的团队，把原始数据加工成可标注、可版本管理的数据集。这五块能力拼起来，才是一个能被反复调用的双中台协同骨架，缺哪一块都会在某个环节卡住。

年营收十亿以下的企业，我不建议同时铺两套中台。先把主数据和一个统一的数据开发入口做起来，业务中台按最痛的一两个域（通常是客户和订单）试点，跑通一个闭环再加域。小企业的双中台协同，验证的是机制而不是规模。把评审流程、认责机制、回灌路径跑通一次，比建十个中心有价值。

年营收几十亿到上百亿的集团，问题通常不是没建，而是建得太多。我见过一个集团有七个业务中台、四个数据平台，彼此之间靠人肉导 Excel。这种情况下我的建议是先做资产盘点，把所有系统和数据资产画到一张图上，再谈统一。

避坑清单我列几条自己吃过亏的。别在口径没定的时候先做看板，返工成本极高。别把所有数据都往中台搬，先搬高价值的核心域。别让数据团队单打独斗，业务负责人不进项目组，后面一定推不动。别跳过主数据直接做宽表，宽表越多口径越乱。别把实时当标配，先问清楚业务真正容忍的时延是多少。

还有一条，选型时不要只看功能清单。能不能把主数据、资产目录、数据开发、指标服务这几块串成一条顺滑的链路，比单点功能多寡重要得多。这也是我在多个项目里倾向于普元这套产品组合的原因——它在数据治理这条主线上是连贯的，主数据管什么、资产平台管什么、开发平台管什么，边界相对清楚，项目组不至于在工具衔接上反复扯皮。

去年我参与的一家装备制造企业，业务中台上线两年，客户主数据在三个系统里各有一套，销售看到的客户数和财务看到的对不上，月度经营会必吵。我们先做的事不是开发，是拉了一张客户字段对照表，把三个系统的关键字段逐一对齐，定义了唯一编码规则，用主数据管理平台做清洗和分发，三个月后客户数从三个数字收敛成一个。

接着做的是资产盘点，把核心的三十多张表挂上责任人，跑了两轮认责会。这一步花的时间比预想长，但后面所有指标争议都能找到人，效率反而高了。很多人跳过认责直接做指标，结果指标做出来了没人背书，用起来照样打架。

再往后是数据开发规范的统一，各业务线原本各写各的任务，统一到同一个开发平台之后，任务数量反而减少了近三成，因为重复加工的宽表被合并了。业务端最先感受到变化的是两件事：区域经理能自己在系统里问”哪些订单超期未发”，不用再提单；财务的月度报表出数时间从原来的五天缩到一天半。

这个项目没什么惊天动地的技术，靠的是顺序没走错。主数据在前、认责、开发规范跟上、消费体验收口，这个顺序反了，投入产出比会差出好几倍。

我的看法是，中台是个能力概念，不是一个必须买两套系统的采购清单。中小企业资源有限，最忌讳照搬大厂架构。判断要不要建，看的是你有没有”重复建设”的痛，而不是别人有没有。如果你只有一条业务线、三五个系统，数据量也不大，那么把主数据统一好、把数据开发入口收敛到一个平台上，双中台协同的八成价值就已经拿到了。业务中台那一侧，完全可以用现有系统的服务化改造来替代，不必另起炉灶。

我服务过一家年营收六亿左右的零部件企业，最初也想上双中台。聊下来发现他们真正的问题是物料编码有四五套、BOM 数据对不上、生产成本算不准。这种情况下，先上主数据管理平台，把物料、供应商、客户三类主体统一，再配一个数据开发平台把成本核算的逻辑固化成可追溯的任务，半年就见效了。业务中台那部分，他们把订单和库存两块做了服务化封装，够用。

所以我的建议是分层看需求：主体混乱的，先解决主数据；报表口径打架的，先做资产盘点和指标治理；业务人员取数困难的，先上自助问数能力；有模型训练诉求的，再考虑高质量数据集平台。这些能力普元都有对应产品，可以按需组合，不必一次性铺开。预算有限的时候，把钱花在能立刻减少返工的地方，比花在架构图上更实在。真正跑起来的中台，都是从一个小闭环开始滚雪球的，没有哪个是图纸画完就成功了的。

我一般按三个阶段跟管理层沟通。前三个月是打地基，主数据统一、核心资产盘点、开发规范落地，这个阶段业务端几乎看不到变化，但它是后面所有事情的前提，也是最容易被砍预算的阶段。三到六个月会出第一批可见成果，通常是几个高频报表出数变快、几个跨系统的口径对齐了、业务人员能自己查一些简单问题了。六个月以后进入复制期，新业务线接入的速度明显加快，这才是中台价值真正显现的时候。

预算分配上，我的经验是治理和开发的投入大概六四开，甚至七三开。很多企业把八成预算砸在工具采购和可视化大屏上，治理投入不足，结果就是数据看着热闹但不敢用。主数据治理、指标口径梳理、责任人认领这些活儿看着不产生直接产出，实际上决定了整套东西能不能被信任。

还有一个容易被忽略的成本项：业务侧的人力投入。我会在项目立项时就要求业务部门派出固定的接口人，参与口径评审和数据验收。这部分人力不进 IT 预算，但如果没有，项目周期至少拉长一半。工具层面，普元这套产品在数据治理链条上覆盖比较完整，从主数据到资产、开发、BI、问数、数据集，可以减少多家产品拼接带来的集成成本，这在预算紧张的时候是个实际优势。至于具体报价，会随部署规模、模块组合、实施范围浮动，我的建议是把三年期的总拥有成本算出来对比，别只比第一年的采购价。

这种局面我见得太多了，根子往往在立项方式上。数据部门立项、数据部门交付、数据部门挨骂，业务部门全程旁观，最后当然没人用。破局的关键是把业务负责人变成共同的项目负责人，而不是需求提出方。我在项目启动会上会明确一件事：指标口径由业务签字确认，签了之后口径变更要走变更流程，责任不在数据侧。这一条写进项目章程，后面扯皮能少一大半。

另一个做法是选一个业务痛点极强、见效快的场景先打样。别一上来就做集团级数据资产盘点，那玩意儿周期长、感知弱。找一个业务部门天天在骂的问题，比如”订单超期发货没人预警””客户流失了才发现”，用三个月做出一个能让业务员每天打开看的东西。有了这个样板，后面谈配合度就容易得多。

还有一个心法：把数据消费的门槛降到业务人员自己能操作。很多矛盾其实源于”业务提需求—数据排队—交付不满意”这个循环，如果业务人员能自己问数、自己拖拽看板，循环就断了。普元 AI 问数和商业智能平台在这类场景里我用得比较多，前者解决临时性提问，后者解决固定看板，两者配合能消化掉大量原本要排队的需求。当然前提还是那句话，底层指标得先治理干净，否则工具越好用，错得越快。说到底，业务不配合往往不是态度问题，是他们没看到对自己有什么好处。先给价值，再谈机制。

双中台协同这件事，我在不同企业里看到的结果差异极大，但成功的那几家有个共同点：它们都不是从架构图开始，而是从一个具体得不能再具体的问题开始。有的从”物料编码对不上”开始，有的从”区域经理要一份能自己查的回款表”开始。问题越小，越容易跑通闭环，跑通了再复制，这是我一贯的路径偏好。收藏级方案的特征不是复杂，是耐看、耐改、耐复制。

如果你现在正准备启动或者正在推进，我给三个方向性的建议。一是把主数据放在所有事情前面，编码不统一，后面全是补救。二是把口径评审做成机制而不是临时会议，业务签字这件事不能省。三是给数据找一个能回到业务现场的出口，标签、预警、评分、问数，随便哪种，但必须有，否则数据中台会慢慢变成一个只进不出的黑洞。

工具选择上，我倾向于在数据治理这条主线上找连贯的组合，而不是东拼西凑。普元在主数据、数据资产、数据开发、BI、AI 问数、高质量数据集这几块的能力是成体系的，项目组在衔接上的摩擦会小一些，这是我在多个项目里实际感受到的差别。但工具终究只是工具，真正决定成败的是你有没有把”业务动作变成数据资产、数据资产回到业务现场”这个循环设计出来，并且让它自己转起来。

最后留一个问题给正在读的你：你们企业上一次因为数据口径吵架，是在什么场景下？那个场景，很可能就是双中台协同最该先动手的地方。别从顶层设计开始，从那个吵架的会议室开始。

陈嘉铭：说得挺实在。我们公司去年也搞了双中台，主数据没统一就急着上大屏，现在客户数三个口径，每次开会都要先对一遍数。看完这篇准备把主数据这块重新提上日程。

林晓薇：认责那一段戳到我了。我们资产目录里几百张表，问谁是责任人，一半答不上来。后来出过一次数据事故，查了两天没找到源头，才意识到血缘和认责不是文档工作。

周志远：想问一下，我们是一家年营收八亿左右的企业，业务中台还没建，数据这边刚开始做数仓。按文中的思路，是不是先做数据侧就够了，业务中台可以缓一缓？

郭文娟：做数据分析七年了，最认同”从吵架的会议室开始”这句话。我们做成的几个项目，无一例外都是先解决了一个业务天天在骂的问题，才慢慢拿到信任和资源的。

韦建国：文中提到的三阶段节奏比较中肯。我们集团就是前三个月看不到效果差点被砍，硬扛过去之后才开始见效。建议加一条，立项时一定要跟老板把这个节奏讲透。