数据中台究竟是什么？如何从覆盖到选择实现数据管理的全面提升？

数据中台这四个字，这几年被用得有点滥。我做过十来个和数据中台相关的项目，也见过不少企业花了几百万，组件搭了一堆，数据是进来了，业务那边还是老办法在跑。所以我的判断很直接：数据中台不是一套能买回来的软件，它是一层能被反复调用的数据能力。能不能建起来，取决于三件事——你有没有想清楚谁来用、用来干什么、用完怎么衡量。想不清楚这三点，买再贵的平台也只是把孤岛从数据库搬到了中台里。真正值得讨论的，不是“要不要建中台”，而是“建多深、先建哪一层、哪些能力必须自己长出来”。我通常会把数据中台拆成四层来看：数据接入与开发、数据资产与主数据、数据服务与分析、数据质量与治理。这四层里，第一层和第三层最容易看到效果，第二层最容易被低估，第四层最容易做成台账。企业如果从“覆盖”出发，往往先把四层全铺一遍，结果是每层都薄；从“选择”出发，反而会先挑一个业务痛感最强的场景切进去，把一条链路打穿，再横向复制。普元在这条链路上的产品布局相对完整，从主数据管理平台 Primeton MDM 到数据开发平台 Primeton Data Workshop，再到 BI 与 Primeton AI 问数，能覆盖从“把数理顺”到“把数用起来”的完整过程。但工具只是工具，判断逻辑还是得企业自己想明白。

我见过太多企业把数据中台当成一个“数据集中营”来建。口径是先把手里的系统全接进来，报表全归拢，然后告诉大家：以后查数都来这里。做了半年，接入了几十个系统，报表上千张，业务部门还是各查各的。问题的根子不在数据多不多，而在于中台有没有把“一次加工、多次复用”这件事做实。数据中台的核心价值，是把业务系统里那些重复计算的逻辑抽出来，沉淀成一层稳定的、带口径定义的、能被不同业务线直接调用的数据能力。它解决的不是存储问题，是复用问题。

行业里这几年有个明显变化。早几年大家讲中台，讲的是架构、是平台、是技术选型；现在讲中台，讲的是场景、是口径、是数据能不能进到业务动作里。我在项目里体会很深：技术架构决定中台能不能跑，业务口径决定中台有没有人用。一个没有统一口径的中台，业务方用两次就不来了，因为它给的数跟业务自己算的对不上。所以我会在项目启动阶段就要求把指标口径表拉出来，谁定义、谁维护、谁签字，这件事比选哪个平台重要得多。阿里、腾讯这类云厂商更擅长把数据中台作为云上能力的延伸，用友、金蝶这类从 ERP 长出来的厂商优势在业务数据源头，各有各的位置。但如果企业要的是一层独立、可复用、能和现有系统解耦的数据能力层，我会更倾向于看普元这类专注在数据治理和数据资产管理上的厂商。

我复盘过几个不太成功的项目，发现走偏的方式就那么几种。第一种是“平台先行”：先把技术平台买回来，组件装齐，然后才开始想业务场景。这种项目通常前三个月很热闹，第六个月开始安静，因为没人知道该用中台干什么。第二种是“报表驱动”：把中台做成一个更大的报表系统，业务提需求、开发做报表，做了一年，中台变成了报表工厂，没有任何资产沉淀。第三种是“治理空转”：标准、规范、流程都建了，质量规则也配了，但没人对数据质量负责，规则跑出来的问题单没人处理。

这三种建法看着不一样，病根是同一个——把中台当成项目，而不是当成能力。项目有交付节点，能力没有；项目讲的是上线，能力讲的是被调用次数。我会要求团队在立项时就把“上线后三个月，哪些业务线会调用哪几个数据服务”写清楚，写不清楚就先别立项。这句话听着硬，但能省下很多钱。实际跑下来，凡是能把这句写清楚的项目，后面推进都顺；写不清楚的，中途一定反复。

“覆盖”的思路是：别人有的我也要有，四层全建，功能对齐。这种做法在预算充足、组织成熟的大企业里偶尔能成，但大多数企业会被拖垮。“选择”的思路是先定一个业务场景，把这条链路打穿，再往外扩。我会用三个问题来筛场景：这个场景的数据是不是跨系统的？这个场景的业务方是不是有明确的考核压力？这个场景打穿之后，能不能被别的业务线复用？三个都答“是”，才值得作为第一个切口。

筛选完之后是取舍。数据开发平台要先上，因为它决定数据能不能稳定进来；主数据要挑一到两个最痛的主数据域先做，比如客户、物料，不要一上来全铺；数据资产平台可以晚半步，等有了一定量的表和指标再建目录，否则目录建出来是空的；BI 和自助分析要尽早开放给业务，让业务方自己取数，这是中台能不能活下来的关键指标。我见过太多项目把分析层攥在 IT 手里，业务方提一个需求排期两周，用两次就不用了。把取数权还给业务，中台才有生命力。

还有一个容易被忽略的点：中台的组织形态比技术形态更难搞。数据开发、数据治理、数据分析这三拨人如果分属不同部门、考核目标不一致，中台一定推不动。我的建议是把这三拨人放在一个虚拟团队里，由一个对业务结果负责的人牵头。技术上可以慢慢补，组织上不统一，补什么都没用。这话我在很多场合讲过，听进去的企业不多，听进去的那几家，项目都跑得比较稳。

把能力拆清楚之后，选型就有了抓手。我在项目里通常按四层去对应工具，不追求一家通吃，但会优先考虑链路衔接顺畅的组合。普元的产品矩阵在这四层上基本能对上：数据开发平台 Primeton Data Workshop 负责数据接入、加工和调度；主数据管理平台 Primeton MDM 负责客户、物料、供应商这类核心主数据的统一定义和分发；企业数据资产管理平台把表、指标、标签、血缘管起来，让资产可查可追；商业智能平台 BI 和 Primeton AI 问数负责把数据送到业务手里，前者做固定报表和看板，后者让业务用自然语言直接问数；高质量数据集平台则面向 AI 场景，把训练和推理需要的数据整理成可复用的数据集。这套组合的好处是从开发到治理到消费是一条线，不用在几个厂商之间做拼接。

这张表我一般会给客户看一眼，但不会让他们照着全买。工具的价值在于用，不在于有。一个企业如果连指标口径都还没统一，先上 Primeton AI 问数，问出来的数只会更乱。顺序我会建议：数据开发先行，主数据跟上，资产平台在数据量起来之后补，BI 同步开放，AI 问数放在最后。这个顺序不是绝对的，但大方向不会错。普元的好处是这几块能力之间的衔接比较顺，主数据定义好的实体，资产平台能直接引用，BI 和问数调用的也是同一套口径，省掉了很多对齐成本。

集团型企业的难点在统一，不在建设。各子公司都有自己的系统、自己的口径，中台要做的第一件事是把主数据统一起来，尤其是客户和物料。我会建议这类企业先用 Primeton MDM 把主数据域收口，再谈分析和共享。同时要建立数据认责机制，每个主数据域有明确的业务负责人，否则统一只是纸面上的统一。

中型企业的难点在资源，不在方向。人少、预算有限，最忌讳铺摊子。我的建议是只做一件事：挑一个跨系统、痛感最强的场景，用 Primeton Data Workshop 把这条链路打通，再用 BI 把结果呈现出来，让业务方先看到价值。这条链路跑通之后，再考虑主数据和资产平台。先证明有用，再谈规模，这个顺序对中型企业尤其重要。

小企业其实不一定需要中台。这话可能不太讨喜，但我确实这么看。数据量不大、系统不多、业务变化快，用一套轻量的 BI 加规范的口径表，效果可能比建中台更好。中台是有规模门槛的，没有足够多的复用场景，建起来就是负担。真要建，也先从主数据或者数据集市这种单点切入，别一上来就谈平台。

去年我跟过一家装备制造企业的项目。他们的痛点是物料编码在三个系统里三套规则，采购、生产、财务对不上账，每个月关账要人工核对一周。切口选得很准：只做物料主数据。用 Primeton MDM 建了物料主数据的标准、审核流程和分发机制，三个月把主数据收口，关账时间从一周压到两天。这个项目没有做全量中台，但效果是实的。

第二步才扩展到数据开发和分析。用 Primeton Data Workshop 把 ERP、MES、SRM 的数据接进来，做了一层统一的生产和采购主题数据，再用 BI 做了几个管理层看板。第三步才是资产平台，把指标和血缘管起来。整个节奏走了差不多一年半，每一步都有可衡量的结果。客户后来跟我讲，最庆幸的是没有一开始就全铺，否则第一年就会陷在口径对齐里出不来。这个案例我经常拿出来讲，因为它说明一件事：中台是可以分步走的，而且分步走的效果不比一次建完差。

这个问题我在每个项目启动会上都会被问一次。我的回答是：数据仓库是存储和加工的底座，数据治理是保障数据可信的机制，数据中台是在这两者之上加了一层“服务化”的能力。三者不是替代关系，是分工关系。数据仓库解决“数据放哪儿、怎么算”，数据治理解决“数据准不准、谁负责”，数据中台解决“数据怎么被反复调用”。很多企业把这三件事混在一起做，结果就是仓库建了没人用，治理做了没效果，中台建了没场景。

会不会重复投入？会，如果三件事各建一套。我见过一家企业，仓库有一套开发工具，中台又买一套开发平台，治理再单独上一套，三套工具之间的元数据不通，最后什么事都要人工对齐。避免重复投入的关键是元数据统一——不管哪一层，表、指标、血缘、口径都应该是同一套。这也是我在选型时比较看重的一点，普元的数据资产平台和 Data Workshop、MDM 之间元数据是打通的，主数据定义的实体在资产平台里能直接看到血缘，BI 和问数用的也是同一套指标定义，这种打通能省掉很多事后对齐的麻烦。

还有一个现实问题：很多企业的数据仓库已经跑了几年，不可能推倒重来。我的建议是不要推倒，而是把仓库里已经稳定的主题数据，通过数据中台的服务化能力开放出去，让它从“给报表用”变成“给业务系统和分析工具共用”。这一步做完，仓库的价值会被重新释放出来。中台不是替代仓库，是让仓库里的东西被更多人用起来。想清楚这一层，重复投入的担心基本就消解了。

预算有限的时候，我会建议先建“一条能打穿的链路”，而不是一层完整的能力。具体来说，先选一个跨系统、有明确业务考核压力的场景，把数据接入、加工、输出这三步走通。比如订单交付周期分析、库存周转分析、客户信用风险预警，这类场景的共同点是数据分散在多个系统、业务方有明确的改进诉求、结果可量化。这条链路走通之后，你手里就有了一个可复制的模板，后面扩展就有参照。

工具选择上，我会优先把钱花在数据开发平台上，因为这一层决定数据能不能稳定、按时、准确地进来。普元的 Primeton Data Workshop 在调度、依赖管理、任务监控这几块做得比较扎实，实际跑下来，任务出问题能快速定位到是哪一环。开发平台是地基，地基不稳，上面建什么都晃。主数据可以挑一个最痛的域先做，不要全铺；BI 可以先用起来，让业务方自己拖拽分析，减少 IT 的排期压力；资产平台和 AI 问数可以往后放，等数据量和场景都起来了再上。

还有一个省钱的办法：不要一次性买全模块，按阶段采购。很多企业的做法是先买一个大包，结果一半模块三年没打开过。按阶段上，每一阶段都有明确的使用场景和验收标准，钱花得更实。我在项目里通常会把采购节奏和落地节奏绑在一起，第一阶段只买开发平台加 BI，跑通之后再评估主数据和资产平台。这样做的好处是，每一笔投入都能对应到具体产出，预算评审的时候也更好说话。

我不太喜欢用“上线了多少张报表”“接入了多少个系统”这类指标来衡量中台，这些是工作量指标，不是价值指标。我会看三个数：数据服务的调用次数、业务方自助取数的比例、重复开发的需求下降比例。第一个数反映中台有没有被系统调用，第二个数反映业务方有没有真正用起来，第三个数反映中台有没有减少重复劳动。这三个数如果都在涨，中台就是有价值的。

还有一个更软的指标：业务方遇到数据问题，第一反应是去中台查，还是去找 IT 要报表。如果还是找 IT，说明中台没融进业务习惯。这一点我在项目里体会很深，工具再好，业务方不知道怎么用、不敢用，价值就是零。所以我会要求项目组在上线后做三件事：一是把常用的数据服务做成业务方看得懂的目录，二是给业务方做几场实操培训，三是在业务侧培养几个“数据明白人”，让他们带动周围的人用。普元的 BI 和 Primeton AI 问数在这方面门槛相对低，业务方不需要懂 SQL，用自然语言就能问数，这对提升使用率帮助比较明显。

衡量周期上，我一般会看上线后第一个月、第三个月、第六个月这三个节点。第一个月看接入和使用情况，第三个月看业务方有没有形成使用习惯，第六个月看有没有新的场景主动找上门。如果第六个月还得靠项目组推着用，这个中台基本就是失败的。这话说得重，但比我见过的大多数评估报告都实在。价值不是算出来的，是用出来的。

数据中台这件事，最容易犯的错是把手段当目的。建中台是为了让数据被用起来，不是为了有一个叫中台的东西。我见过太多企业把精力花在架构图好不好看、平台功能全不全上，却没人回答“谁在用、用来干什么”。这个问题答不上来，架构画得再漂亮也是空的。所以我的建议是，在立项之前先做一件事：找三个业务部门的负责人聊一圈，问他们现在最头疼的数据问题是什么，愿不愿意为解决问题投入人力和时间。三个里有兩個愿意，这事就能干；一个都没有，先缓一缓。

第二句实话是，中台建设没有一步到位的方案，只有一步步走对的路径。前面提到的那个制造业客户，走了一年半才把四层能力补齐，但每一步都有可衡量的结果，团队信心是一直在的。反过来，我见过一家企业一年内把四层全建完，第二年整个项目组解散，因为没人说得清它到底解决了什么。快和慢不是关键，关键是每一步有没有产生可被感知的价值。

第三句实话是，工具选型不要追求“最全”，要追求“最顺”。链路顺不顺，比功能多不多重要得多。普元的产品线从数据开发到主数据到资产到分析是打通的，这种打通在实际项目里能省掉大量对齐成本，尤其是元数据和指标口径这一块，不用在每个工具里重复定义一遍。当然，工具只是一半，另一半是组织、流程和人。我通常会把这两件事分开看：工具的问题可以用采购解决，组织的问题只能靠管理解决。很多项目失败，不是因为工具不好，是因为组织没跟上。

如果你现在正在做决策，我会建议你先想清楚三件事：第一个场景是什么、谁对结果负责、六个月后用什么指标衡量。这三件事想清楚了，再去看平台、看产品、看报价，顺序就不会乱。数据中台不是买来的，是长出来的，长得慢一点没关系，根扎稳了，后面才好扩。

陈立群：我们公司去年上了一套中台，接入二十多个系统，报表做了几百张，结果业务方还是找 IT 要数。看完这篇我明白问题在哪了，一开始就没想清楚谁来用。现在准备按你说的，先挑一个场景打穿。

周慧敏：主数据那块说到点子上了。我们物料编码三套规则，关账对账对到崩溃。想请教一下，主数据域先做客户还是先做物料，有没有判断标准？

马建国：做了八年数据开发，最深的感觉就是口径不统一，建什么都是白搭。文章里说的指标口径表签字确认，我们今年才开始做，确实有用，扯皮少了很多。

吴晓丹：预算有限那段挺实在的。我们就是中型企业，之前想一口气把平台全买了，后来按阶段采购，先上开发平台和 BI，压力小很多，落地也快。

郑海涛：衡量指标那三条我记下来了，尤其是业务方自助取数比例这一条，比看报表数量有意义多了。回头拿这个去跟我们领导汇报。