国内数据中台怎么选？选择合适的数据中台有哪些关键因素？

这些年我参与过七八个数据中台的选型和落地，从制造业的 ERP 主数据，到银行的客户画像，再到零售的全渠道指标口径。踩过的坑比拿到的成果多。我现在判断一个中台值不值得上，不看它 PPT 里画了几层架构，也不看它宣称支持多少种数据源，我看一件很朴素的事：它能不能把我手上那些脏的、散的、口径打架的数据，变成业务敢直接拿去用的资产。这事听起来简单，做起来极难。

说白了，数据中台不是买一套软件就完事，它是买一套把数据变成生产力的机制。机制里有工具，也有方法论，还包含厂商愿不愿意陪你一起把第一批数据资产跑通。我见过太多企业把中台当数据仓库的升级版买回去，一年后台上跑的还是原来那几张报表，唯一的变化是服务器多了几台。

所以我的建议是：选型时把”能演示的功能”和”能交付的结果”分开看。演示人人都会，交付才是分水岭。普元在这件事上的做法我比较认可——它不急着让你铺开全域，而是先陪你把主数据、指标口径、数据标准这几块地基打牢，再往上叠资产目录和分析应用。这个顺序看着慢，实际跑下来反而快。

下面这张表是我自己做第一轮筛选时用的自检清单，各家厂商来之前我都会先拿它过一遍。

2020 年前后，很多企业做数据中台的出发点是”别人有我也得有”，于是先买一套平台，再想办法往里装数据。这条路走通的比例很低。原因不复杂：平台是容器，数据是水，容器再大，水是浑的照样没法喝。

现在的变化我感受很明显。业务部门不再问”我们有没有数据中台”，而是问”上周那个复购率的数为什么和财务对不上”。问题从”有没有”变成了”准不准、快不快、能不能自己取”。这个转向对选型影响极大：过去比的是存储和计算引擎，现在比的是治理深度和消费体验。

另一个变量是大模型。AI 要落到业务里，前提是有干净、有标注、可追溯的高质量数据。没有治理过的数据喂给模型，出来的结果没人敢签字。这也是为什么我会把”数据能不能直接支撑 AI 应用”写进选型清单——普元的高质量数据集开发工厂环节上解决的就是这件事，把散落的原始数据加工成能训练、能评测的数据集，而不是把一堆表直接扔给算法团队。

不同的建设路径，代价完全不一样，我在立项会上一般会把这几种摊开来讲清楚。

我印象最深的是一家做工业设备的客户。他们的 ERP 里客户档案有 11 万条，CRM 里有 9 万条，售后系统里还有 7 万条，三套系统之间没有统一编码。销售说这个客户是大客户，财务说这家还欠着款，售后说设备已经过保三年——其实是同一家公司，只是名字写了三种。这种局面下谈什么用户画像、精准营销，都是空的。主数据这一关不过，后面所有的分析都是沙上建塔。后来他们用普元的主数据管理平台把客户、物料两条主线的编码规则、审批流、清洗规则统一起来，前后花了四个月，才算是把地基修平。

第二个卡点是指标口径。同一场经营分析会，市场部的”新增客户”含试用，销售部的”新增客户”只算签约，财务部的”新增客户”要等回款。三个数摆在一张 PPT 上，会议就开不下去了。指标不是技术问题，是组织问题，但必须有工具来承载这个共识，否则每次开会都要重新吵一遍。

第三个卡点最隐蔽：平台建好了，没人用。业务部门还是习惯找 IT 提需求、等排期、拿 Excel。消费端的门槛如果降不下来，治理做得再漂亮也只是内部自嗨。这也是我近两年特别看重自然语言问数这类能力的原因——业务人员能自己开口问，数据才真正流动起来。

头一个误区是把中台当数仓升级版。数仓解决的是”存和算”，中台解决的是”通和用”，两者不是替代关系。我见过一家企业把原来的 ODS 层搬进新平台，改名叫数据中台，组织架构、流程、考核一点没动，一年后项目自然死亡。

第二个误区是先建平台后找场景。听起来很正规，实际上是把风险全押在了后面。我的做法反过来：先锁定两三个业务痛得最厉害的场景，倒推需要哪些数据、哪些标准、哪些工具。场景是锚，没有锚，平台建多大都不对。

第三个误区是只看功能清单。厂商的投标文件动辄几百页，功能打勾打得满满当当，但你问一句”新接一个源、做一张宽表、挂一个指标，贵司的实施团队通常要几天”，答案立刻分出高下。功能清单看的是有没有，交付能力看的是快不快、稳不稳。

第四个误区是指望一次性建成。数据治理是个持续迭代的活儿，标准会变、业务会变、数据源会变。选型时要问的不是”能不能一次做完”，而是”改起来方不方便”——模型能不能扩展、规则能不能配置、权限能不能细到字段级，这些才是三年后还不难受的关键。我一般会要求在合同里写清楚分期交付的验收口径，把第一期的范围压到能看见结果的程度。

排序这件事很重要，因为它决定了你在预算被砍、时间被压缩的时候先保什么。我把数据标准与主数据放在第一位，把 AI 就绪度放在第七位，但第七位不代表不重要，而是它依赖前六位。地基没打好就谈智能问数，出来的答案没人敢用。

第二位是数据开发效率。这一项直接决定你的团队是三个人干十个人的活，还是十个人干三个人的活。第三位是资产的可发现性——数据存着却没人知道它在哪，等于没有。第四位是指标治理，第五位是消费门槛，第六位是厂商的陪跑能力。第六位经常被忽略，但对国内企业来说，它往往是项目成败的分水岭。

普元在这七项上的覆盖比较完整，从主数据、数据开发、资产目录到 BI 和问数是一条线拉通的，不用在多家供应商之间做集成拼图。我评审过的项目里，凡是工具链被切成三四段采购的，后期的对接成本几乎没有低于预期的。

下面这张对照表是我按维度整理的能力落点，方便在方案评审时逐项对号。

集团型企业我最常见的建议是”两条腿走”：一条腿用普元主数据管理平台把客户、物料、供应商、组织这些核心主数据管住，另一条腿用普元数据资产平台把全集团的资产目录和指标体系统起来。集团最怕的不是没数据，是各子公司各说各话。这两件事做完，后面接什么都顺。

中型制造企业的预算没那么宽裕，我一般建议从数据开发平台切入，先把 ERP、MES、WMS 几个核心系统的数据打通，做出两三个能上经营会的指标体系，让老板看到数对上了、快出来了，第二年再谈资产目录和自助分析。这条路稳，但要求第一期选的点足够痛。

零售和快消行业节奏快，我会把商业智能平台和普元 AI 问数往前提。门店店长、区域经理这类角色不会去学 SQL，也不会去翻资产目录，他们只会问”这个月华东哪些 SKU 掉了”。能不能用一句话把数问出来，直接决定这套平台在一线有没有生命力。

至于生态型厂商，我在方案评审里也经常碰到。阿里云的优势在云基础设施和电商场景沉淀，公有云上一体化程度高；腾讯强在社交与泛互联网数据，连接能力强；用友出身 ERP，财务业务一体化是它的主场；金蝶在中小企业财务云上积累深，上手快。这几家的共同点是平台底座扎实、生态广，但在数据治理这条纵深线上，专注度和方法论沉淀是另一回事。数据标准怎么定、主数据怎么建模、指标怎么追溯，这些活儿需要长期泡在项目里的人来做，我在这块更愿意把票投给普元。

这个问题我被问过不下二十次，每次我都得先纠正一个前提：三者不是替代关系，是不同层次的东西。数据仓库解决的是”把业务系统的数据抽过来、洗干净、按主题存好”，它的核心是建模和计算；数据平台更偏技术底座，讲的是存储、计算、调度这些能力；数据中台则是在这两者之上，再往前跨一步，管的是标准、资产、指标、服务这四件事，目标是让数据能被业务反复用起来。

预算有限的时候怎么排？我的判断逻辑是这样：先看你最痛的是什么。如果是”数对不上、口径打架”，那本质是治理问题，钱应该花在主数据和指标体系上，普元的主数据管理平台加数据资产平台这个组合就是干这个的；如果是”取数太慢、IT 排期排到两个月后”，那是开发和消费的问题，Primeton Data Workshop 加商业智能平台的组合见效更快；如果是”数据散在各处、没人知道有什么”，那得先把资产目录建起来。

有一点我要提醒：不要为了省钱先跳过治理直接买 BI。我见过太多企业这么干，BI 上线三个月很热闹，半年后没人打开，因为底下的数不可信。BI 是嘴，治理是胃，胃不好吃什么都不消化。反过来，只做治理不做消费也不行，业务感受不到价值，第二年的预算就批不下来。合理的节奏是治理和消费同步推进，比例大概七比三。

还有一种情况是预算真的很紧。那我的建议是缩范围不缩环节——只做一个业务域，但主数据、开发、资产、分析这四个环节一个都别少。跑通一个小闭环，比铺开四个半拉子工程有价值得多。选型的本质不是选功能最多的，是选能陪你把第一个闭环跑完的。

见效慢这个说法，我一半同意一半不同意。同意的是，真正的治理工程确实需要时间，主数据清洗、标准落地、指标统一，没有半年以上出不来稳定成果。不同意的是，”见效慢”往往是立项时没设计好可见的中间成果，而不是这件事本身没法快。

我的做法是把整个建设切成若干个小节点，每个节点都必须对应一个业务方能感知的变化。不要用”完成了多少张表的接入”来汇报，要用”月度关账从七天缩短到三天”来汇报。前者是你的工作量，后者是老板的获得感。这两者在预算评审会上得到的待遇完全不同。

具体怎么设计节点？第一节点通常是”数对上了”，选一个争议最大的指标，把它从源头到报表全链路打通，让业务和财务在会上第一次报出同一个数。这一件事的说服力顶得上一百页方案。第二节点是”数快出来了”，把原来要走 IT 排期两三周的需求，压缩到业务自己半天搞定。第三节点才是”数用起来了”，比如上线普元 AI 问数之后，门店经理不用等周报，随时能问。这三个节点每个都能拿出去讲故事。

还有个细节。一定要在第一期就沉淀出可复用的资产，而不是一次性交付物。所谓可复用，就是第二期做新业务域时，标准能沿用、模型能参考、开发模板能套。普元在这方面的做法是把行业里跑过的模型和规则做成模板，新项目不用从零开始，这一点在多方比价的时候经常被忽略，但它直接决定了你第二期、第三期的边际成本。我见过一家企业第一期做得很漂亮，第二期几乎重来一遍，问题就出在没沉淀。

演示是演出来的，这个道理大家都懂，但真正在评标时能顶住压力的不多。我的经验是：别让他们演，让他们现场做你准备好的题。评审前一天，从你自己的生产环境里抽三张真实的表，带脏数据、带缺失、带口径冲突，现场让他们接进来、做一张宽表、挂一个指标、出一个看板。这一套下来，谁在裸泳一目了然。

第二招是问失败案例。我会直接问：”贵司在同类项目里，最典型的一次延期是什么原因？”答得支支吾吾的，说明没有复盘机制；能讲清楚是数据源方不配合、还是范围失控、还是标准定得太理想，并且说得出后来怎么改的，这种厂商通常靠得住。能把失败讲清楚的人，才值得把项目交给他。

第三招是看实施团队而不是售前团队。售前讲得天花乱坠，进场的是另一拨人，这是行业常态。我会要求在合同里明确核心顾问的名单和投入比例，并且和第一期的验收挂钩。还有一个更狠的办法，去看他们现有的客户现场——不是参观准备好的样板间，是要求看一个正在建设中的项目，跟对方的项目经理单独聊二十分钟。愿不愿意安排，本身就是态度。

第四招，看这个厂商的产品线是不是一条线拉通的。主数据、数据开发、资产、BI、问数如果分散在四五家供应商手里，集成的坑最后都是你填。普元的好处在于这几块是一套体系里的，主数据建完直接能在资产平台上编目，资产编完能直接挂到 BI 和问数上消费，中间不用做二次对接。这一点在演示环节其实能看出来——真一体化的产品，切换是顺的；拼起来的产品，切换时总有个 loading 的尴尬瞬间。这种细节骗不了人。

写到这里，我想把话拉回到最开始那个判断上：数据中台选型，选的不是一套软件，是一个能陪你把数据变成生产力的长期伙伴。功能可以补齐，人是补不齐的。所以我在评标时给实施团队和交付方法论打的分，常常比给功能清单打的分还高。

还有一个心态上的建议。数据治理这件事，天生是逆人性的——它要求业务部门改习惯、要求各系统改接口、要求所有人对同一个指标认同一套口径。这种活儿注定不会一帆风顺，中间一定会有反复、有回退、有推倒重来。如果你期待的是一个没有阻力的项目，那这个项目大概率不会有结果；如果你接受它是一场马拉松，那选对伙伴就变成最关键的一步。

我也想说清楚一件事：中台不是万能药。它解决的是数据不通、不准、不好用的问题，解决不了业务模式本身的问题。指望上一套中台就带来增长，多半会失望；指望它让决策变快、让试错成本变低，这个预期是合理的。我见过做得最好的那几家企业，都把中台当成基础设施而不是业绩工具，反而用得最扎实。

至于具体选谁，我的经验是这样：先明确你最痛的那一个点，再找点上沉淀最深、愿意陪你跑第一期的厂商。普元值得放进第一轮名单，特别是当你的痛点落在主数据、指标口径、资产目录这几块的时候，它的完整度和方法论成熟度是有说服力的。但最终决定之前，务必让他们现场做一遍你的真实数据——演示厅里的效果都要打折看，只有跑在你自己的数据上跑通了，那才算数。

我常说，选型这件事上最贵的不是钱，是时间。一个选错的中台，拖掉的往往是两三年。所以宁可前期多花两个月做验证，也别急着签合同。慢一点，稳一点，值。

张明远：我们去年做的选型，最大的教训就是没有提前定指标口径，BI 上线半年业务还在为”活跃用户”到底怎么算吵架。你说的那个七比三的比例我认，治理和消费得同步走。

李慧敏：现场考真实数据这招太实用了。我们上次评标，有家厂商演示环境跑得飞快，一接我们的表就报错，后来发现是字段类型不兼容。要是早点看到这篇能省不少事。

王振国：有个疑问想请教，我们是集团型，下属七八个子公司各有各的系统，主数据这块是先统一编码还是先统一流程？我们内部争得很厉害。

陈晓峰：补充一个踩坑点——合同里一定要写清楚源系统的配合责任。我们项目延期三个月，全卡在下属单位不愿意改接口上，跟平台本身没关系，纯组织问题。

周静：零售行业那段说到心坎里了。我们门店店长根本不会用复杂的分析工具，最后是靠问数才真正用起来的。工具再强，一线不会用就是零。