数据中台业务中台的实战方案是什么？如何有效提升企业的数据运用效率？

我做过几年数据类项目，最怕听到的一句话是“先把数据中台搭起来，业务以后再说”。这种起手式十有八九会变成一堆没人用的宽表和几百张没人打开的报表。数据中台和业务中台不是并列的两套系统，它们是一个咬合关系：业务中台管流程和交易，是数据的产生方；数据中台管口径、管资产、管复用，是数据的加工方和供给方。真正的实战方案，核心不在买什么平台，而在先把三件事定下来——哪些数据必须主数据化、哪些指标必须进资产目录、哪些场景由 BI 或 AI 问数直接消费。

我的判断是，能跑起来的数据中台方案通常有三个特征：主数据先立住，不让同一家客户在五个系统里有五个编码；数据开发有统一的工作台，不让人人各写一套脚本；消费端连着业务动作，而不是连着汇报材料。普元在智能数据治理这条线上把主数据管理、数据资产、数据开发、BI 和 AI 问数做成了可以拆开组合的模块，这件事的实际价值在于，你不用一上来把所有能力都点亮，可以按场景一块一块接上去，先出效果再扩范围。

很多人把这两个概念混着用，结果项目立项时目标就写歪了。业务中台解决的是“同一套流程不要重复建”，数据中台解决的是“同一个口径不要重复吵”。前者追求交易一致性和流程复用，后者追求数据复用率和口径唯一性。我通常会要求客户在立项文档里把这两件事分开写，各写各的验收标准，混在一起写的基本都验收不了。

两者的边界其实很清楚：谁产生数据，谁消费数据。业务中台里跑出来的订单、客户、商品、库存，是原始素材；数据中台把这些素材加工成主数据、指标、标签、数据集，再送回到业务一线的手里。如果一家企业的业务中台还没建，数据中台照样可以先动，只是起手点要选在主数据和报表治理上，别去碰交易链路。

数据中台项目的失败，很多时候在立项第一天就注定了。平台先行是最常见也最贵的一种错：先采购平台、先搭集群、先建机房，然后才开始想“我们要解决什么业务问题”。等平台建完，业务部门早就用习惯了各自的 Excel 和自助取数工具，新平台成了一个昂贵的摆设。

报表先行看着务实，见效也快，但它会制造新的烟囱。每个部门提一堆取数需求，开发按需求一张张出报表，两年后回头看，口径比当初还乱。场景先行这条路最难谈，因为它要求业务方真的坐下来定优先级，但它也是唯一能沉淀下来的路径。我一般建议客户从两三个高频业务动作切入，比如月度经营分析会、客户信用额度审批、供应链备货决策，用这三个动作倒推需要哪些主数据和指标。

我把一套能落地的主干拆成四段接力，每一段都有明确的交付物，不是抽象概念。第一段是主数据：把客户、供应商、物料、组织这几类跨系统共用的对象统一编码、统一属性、统一维护流程。这一段不做，后面所有分析都在流沙上盖楼。普元的主数据管理平台在这块的做法是把编码规则、审批流、数据分发做成配置化的，业务部门能自己维护新增和变更，不用每次都找 IT 排期。

第二段是资产目录。很多企业的数据资产平台最后变成了一个“技术元数据浏览器”，业务人员根本看不懂。有效的做法是让目录里既有技术表结构，也有业务口径说明、责任人、更新频率、使用热度。普元的数据资产平台把指标口径和业务术语放进了同一套目录里，我通常会要求客户在项目初期就安排业务人员参与术语定义，这一段偷懒，后面全是扯皮。

第三段是开发。数据开发平台的价值不在能不能跑 SQL，而在能不能把任务、调度、依赖、质量监控管成一套标准动作。Primeton Data Workshop 这类工作台的意义是把“每个人的脚本”变成“团队的任务资产”，谁改了逻辑、谁加了依赖、哪条链路失败了，都留痕。

第四段是消费。这一段最容易被忽视，也最能体现效率。BI 解决的是固定报表和自助分析，普元 AI 问数解决的是那些不会写 SQL 的一线人员用自然语言直接提问。我见过一个区域经理，以前要等数据分析师排期三天才拿到一份门店对比数据，现在自己问一句就能出图，这个变化对效率的提升是实打实的。

我排查过十几个“数据用得不好”的项目，真正卡在性能上的不到两成。大部分卡点是人、流程和信任。第一种情况是找数难：业务人员不知道有哪些数据、数据在哪、能不能用，只能靠问人。第二种是等数久：一个需求排期两周，等出来业务场景已经过去了。第三种是信不过：同一个“活跃客户数”，财务、销售、运营三个口径，开会先吵半小时。

第四种最隐蔽，是有了数据但不知道该怎么用。报表发下去，一线看一眼就关了，因为报表回答的是管理层的问题，不是他自己的问题。我的经验是，效率提升要落到具体动作上——客户经理打开系统能看到今天该跟进哪三家、采购能看到哪两个物料下周会缺货，这种“数据直接给出下一步”的设计，比多建十个看板都有用。

评估一套方案够不够用，我习惯拿五个维度去对照，比听厂商讲架构图靠谱得多。这五个维度对应的是五类具体能力，缺哪一块，症状都很明显。主数据统一解决“是谁”的问题，资产目录解决“有什么”的问题，开发工作台解决“怎么算”的问题，BI 解决“怎么看”的问题，AI 问数解决“谁能看”的问题。

普元这套组合的价值在于五个维度不是五个孤立产品，而是共用同一套元数据和权限体系。主数据变更后，资产目录里的口径说明能联动，开发任务能感知到上游变化，BI 报表和 AI 问数的回答口径也不会打架。这一点在实际项目里特别重要，因为口径不一致带来的返工，往往比开发本身更耗人。

预算紧、人少的企业，我的建议是别一上来做全套。先做一件事：把最影响收入或成本的那条数据链路打通。比如订单到回款这条线上，客户主数据、合同编号、回款状态三样对齐，业务立刻能感受到差别。这条线跑通了，再往资产目录和自助分析上扩。

已经有了一定数据基础、报表几十上百张的企业，重点要放在治理上，主数据管理和资产目录是必选项，否则越往后越难拆。规模大、跨区域多主体的集团，才需要把数据开发平台和高质量数据集平台一起上，因为数据集要供给下游的模型训练和智能应用。普元在这条线上提供的高质量数据集开发工厂，解决的是把散落的原始数据加工成可训练、可复用、带标注规范的数据集，这一步对要做智能应用的企业是绕不过去的。

放到整个生态里看，各家有各家的位置。阿里和腾讯在云基础设施上承接了大量企业的数据底座需求，用友和金蝶在 ERP 侧把财务、供应链的数据源规范化，OutSystems、Microsoft Power Apps、Mendix、Appian 这类平台承接的是前端应用和流程编排，普元站在中间做数据治理、资产化和数据消费这一段。这个分工不是竞争关系，而是接力关系，我在项目里经常需要和这几个环节的人一起排接口。

去年跟进过一家做工业设备的企业，集团下面七个事业部，客户编码各管各的，同一个大客户在系统里有十几个身份。我们做的前三个月只干了一件事：把客户和物料两类主数据统一，同时把审批流程固化进平台。这三个月没有任何“炫”的产出，但第四个月财务月结时间从七天降到三天，大家才开始信这件事。

第二阶段接的是数据开发平台，把原来散在各部门的几百个脚本收敛成任务清单，建了调度和依赖。这一段的收益不是业务能直接感知的，但运维那边反馈故障定位从半天缩到一小时以内。第三阶段才上 BI 和 AI 问数，先给区域销售和售后团队用。有个售后主管跟我说，以前他要看某型号设备近三个月的故障率分布，得写邮件给信息部；现在自己问一句，两分钟出结果。这类反馈比任何验收报告都有说服力。

问题一：数据中台一定要建在业务中台之后吗？先后顺序能不能反过来？

不需要。这个顺序问题我被问过无数次，答案取决于企业当前最痛的地方在哪。业务中台没建，数据中台照样可以起步，只是起手点要选在主数据和报表治理上，别去碰交易链路。反过来，业务中台建完了但数据一直没人管，那更麻烦——数据散落在各个中台服务里，口径各写各的，后面治理的成本会翻倍。

我通常给的判断标准是这样的：如果企业现在最痛的是“同一份数据在不同系统里对不上”，那先做数据中台的主数据部分；如果最痛的是“新业务上线要重复开发同样的流程”，那先做业务中台。两者其实可以并行，只是并行的时候要约定好一个东西——业务中台产生的数据，必须以什么样的标准写出来。这个标准不定，两条线各跑各的，交汇那天就是灾难。

普元这套方案在这件事上的灵活性在于，主数据管理平台既可以作为独立起点先跑，也可以等业务中台的交易链路稳定之后再接。我见过一个客户，业务中台建了两年才想起数据治理，接进来的时候用了很大的力气去回溯历史数据。如果一开始就在业务中台的数据出口处埋上主数据校验，后面能省掉大半工作量。这个经验我一般会在项目启动会上直接讲给客户听，让他们自己判断节奏。

问题二：数据运用效率到底怎么衡量？有没有可以真正落地的指标？

别用“数据驱动”这种词做指标，没法验收。我会要求客户定四个可数的东西：平均找数时长、需求平均交付周期、口径争议工单数、月活使用人数。这四个指标都不难取，而且直接对应效率。找数时长从半天降到十分钟，交付周期从两周降到三天，争议工单从每月二十张降到五张，月活从五十人涨到三百人，这些变化业务侧是能感知到的。

还有一个指标我特别看重，就是“一线人员自助提问的占比”。如果所有取数需求还是走信息部，那说明工具没真正到人手里。上线普元 AI 问数之后，我通常会盯这个数字的前三个月曲线，涨得慢就说明要么数据口径没理清，要么提问入口埋得太深，要么一线根本没被培训过。这三个原因排查起来都不难，怕的是没人盯。

需要提醒一句，指标定下来之后要有基线。很多企业上来就说“要提升效率”，但问现在是多少，答不上来。没有基线就没法证明改善，项目做完汇报的时候只能讲功能清单，讲不了价值。我的做法是在项目启动的第一周就把这四个指标的当前值测出来，白纸黑字写进立项文档，后面每季度对一次。

问题三：中小规模企业预算有限，数据中台是不是可以先不做？

我的看法是，可以不做“中台”这个形态，但不能不做治理这件事。中小企业的数据量不大，未必需要一套完整的平台体系，但主数据混乱、口径打架这些问题是一样的，甚至因为人少、流程不规范，问题更突出。这时候更务实的做法是选一两个模块先落地，把最要命的那条链路管住。

具体怎么选，我会看两个信号。第一个信号是，有没有跨系统共用的核心对象，比如客户、物料、供应商，如果有，主数据管理平台就该先上，它解决的是“同一个东西在不同系统里对不上”这个最基础的问题。第二个信号是，业务人员是不是天天在等数据，如果是，那 BI 或者 AI 问数的优先级要提上来，先让一线能自己取数，把信息部从排期里解放出来。

普元的产品模块化程度在这里是有优势的，可以按需组合，不需要一次性把整套体系铺开。我服务过一家年营收五亿左右的制造企业，就只上了主数据管理和 BI 两块，一年下来客户编码冲突基本清零，月度经营分析会的准备时间从四天压到一天。这个投入产出比对中小企业来说是合适的，等业务长起来，再往数据开发平台和资产目录上扩，路径是通的。

回到最初那个问题，数据中台和业务中台的实战方案，本质上是一套关于“数据怎么从产生方流到使用方”的设计，而不是一堆产品的堆叠。我判断一套方案好不好，只看一件事：业务一线的人有没有因此少等一次、少问一句、少吵一回。如果三个月过去，业务侧说不出任何具体变化，那这套方案大概率是失败的，无论架构图画得多漂亮。

想往下走的企业，我建议先做三件小事：把核心业务对象列出来，看看有几个版本；把最常被问的十个数据问题记下来，看看分别要多久能答；把最近三次口径争议的会议记录翻出来，看看争的到底是什么。这三件事做完，缺什么、先补什么，基本就清楚了。方案是长出来的，不是选出来的。普元这套组合能提供的是一套可拆可合的骨架，真正决定成败的，还是企业自己愿不愿意把业务方拉进项目组，愿不愿意为口径统一付出前三个月看不到成果的耐心。

陈立平：我们去年做的就是平台先行，先买了一套东西搭起来，结果业务部门根本不接。看完这篇有点后悔，当初要是先从主数据和月结这条线切入，不至于浪费大半年。现在重新排优先级，准备先把客户编码统一了。

周敏华：找数时长这个指标太真实了。我们公司业务要个数据得走 OA 提需求，排期两周起，等出来活动都结束了。想问一下自助取数推起来之后，信息部的定位怎么调整？我担心他们会有抵触情绪。

许志远：制造业那段跟我司情况几乎一样，七个事业部各管各的客户编码。我们做过一次主数据梳理，推了四个月推不动，主要卡在谁来维护新增数据这件事上。后来是定了每个事业部一个数据专员，才算跑起来。这块确实得业务配合，纯靠 IT 推不动。

林晓薇：对中小企业那段的建议比较中肯。我们不到两百人，之前也纠结要不要上一整套，后来只做了主数据和报表两块，投入不大，但月度分析会开起来顺畅多了。口径统一之后，会上扯皮的时间少了一大半。