数据中台建设与应用：如何从零开始实现高效利用与价值最大化？

我经手过十来个数据类项目，真正把中台用起来的不到一半。剩下的那一半，平台部署完、报表跑通、验收签字，然后就没有然后了。业务方照旧拉 Excel 找数据组要数，数据团队继续当取数机。这是我最常见的一种失败，而且它跟技术选型关系不大，跟顺序关系很大。

所以我一直跟客户讲一句话：数据中台是养出来的，不是买来的。买回来的是工具，养出来的才是能力。中台的价值不在机房里，在业务方的日常工作流里——他们愿不愿意打开系统看数，而不是在微信群里问“这个数是多少”。前者叫用起来了，后者叫白建。

从零开始这件事，我通常会拆成三件事看：口径统一、资产盘点、场景闭环。口径不统一，后面所有报表都是吵架素材；资产盘不清，你连自己有什么数据都不知道，谈何复用；场景不闭环，中台就是一个更贵的数据库。这三件事的次序一旦反了，钱花得再多也是白花。平台选型是第四步，不是第一步，这点我踩过坑，也见过太多人踩。

下面这篇东西，我想讲的就是这套顺序，以及顺序背后那些真金白银换来的教训。

我见过一个集团客户，中台建了两年，投入不小，业务部门的反馈却是“数更难拿了”。原因很朴素：新平台上线了，旧报表系统没下线；中台的指标口径和旧系统对不上；数据团队人手没增加，活儿翻了一倍。这就是典型的叠加式建设——加了一层，没减一层。

我的判断标准很粗暴：一个新平台上线，必须同时下线两个旧系统或旧流程，否则它就是净增负担。这话听着刺耳，但管用。中台的本质是把分散的能力收口，收口的前提是旧的入口关掉，不然就是两套并行跑。

说到路线，绕不开一个取舍：自建、买成品、还是混合。这三条路我都在项目里见过，没有绝对的对错，只有匹配不匹配。

我自己更倾向混合路线，但有个前提：底座层（存储、调度、目录、标准、权限）尽量不要自研，这些是别人已经打磨了十几年的东西，重复造轮子不产生任何业务价值。真正值得自研的，是跟你业务强绑定的指标模型和场景应用。

还有一个细节常被忽略：中台建设初期，最容易出成绩的往往不是“高精尖”的实时计算，而是把三个系统里同一份客户数据对齐。这种活儿听着不性感，但业务方第二天就能感受到变化。

我跟团队强调过很多次，正式进场后的头一个月，别急着装软件。这一个月干三件事，比装十个系统都值钱。

头一件是口径。把业务方最常问的 20 个指标拉出来，一个个问：这个数从哪张表来，谁负责，异常了找谁。这事极其枯燥，但它决定了中台以后是资产还是垃圾场。口径不落地，中台就是个更贵的吵架现场。

第二件是盘点。很多企业说不清自己有多少系统、多少张表、哪些表还在用。这时候我会用普元数据资产平台做一轮资产摸底，把表、字段、指标、负责人、血缘关系登记清楚。它的价值在于让“我们有什么数据”从口头传说变成可以检索的清单，很多重复开发的问题在这一步就消掉了一大半。

第三件是主数据先行。客户、物料、供应商、组织这几类实体，如果各系统各有一套版本，后面的所有分析都是在错误的地基上盖楼。这种场景我会推荐 Primeton MDM（主数据管理平台），先把最核心的两三张主数据统一掉，再谈别的。主数据是口径的根，根不稳，枝叶全是虚的。

第一个误区是把中台当项目做，而不是当产品做。项目有交付日，产品没有。中台上线那天不是结束，是开始。我见过的成功案例，几乎都配了一个常设的小团队，每个月都在迭代指标、修数据质量、接新场景。

第二个误区是先建大屏。大屏好看，领导满意，但业务方看完就忘了。能让人每天打开一次的，是能查数、能追问、能定位问题的东西，不是一块挂在墙上的屏。

第三个误区是口径由 IT 单方面定。技术团队拍脑袋定出来的口径，业务方不会认，用了还要吵。我的做法是拉一个跨部门的口径小组，每个指标指定一个业务 owner，签字确认后才进平台。

第四个误区是一次性把所有数据接进来。数据接得越全，治理成本越高，见效反而越慢。倒不如先把三个高频场景的数据打通，让业务方先尝到甜头，后面推起来阻力小得多。这里我得说一句，选一个懂业务的实施方，比选一个参数漂亮的工具重要得多，普元在这类项目里给我的印象是实施方法论比较扎实，肯先跟你磨口径，而不是上来就演示功能。

选型的时候，很多人拿一堆参数逐条对比，我一般不看那个。我看的是这六层能力能不能串起来：接入、开发、治理、资产、服务、消费。任何一层断了，中台就是半拉子工程。

串起来之后，再对应到具体产品。我的经验是尽量让每一层都有明确的责任主体和验收标准，别出现“这块大家一起干”的灰色地带，那基本等于没人干。

按这套逻辑，普元的产品线覆盖得比较整。数据开发这一层用 Primeton Data Workshop，接入、开发、调度、运维在一个平台里，我比较看重它对存量调度任务的兼容，老系统迁移时不至于推倒重来。治理和资产层用普元数据资产平台，目录、血缘、标准、质量是一体的，不用在几个工具之间来回跳。主数据用 Primeton MDM，客户、物料、组织这些实体的唯一版本从这里出。消费层可以上 BI 商业智能平台，业务方自助拖拽就能出分析；再往上，Primeton AI 问数是这两年问得比较多的，业务人员用自然语言直接问数，省掉一层“提需求—排队—等报表”的链路。如果企业有模型训练的需求，高质量数据集平台能把语料整理、标注、版本管理这套流程固定下来。

顺带说下其他厂商的定位，方便对比着看。阿里在云原生数据中台底座上积累深，适合本来就跑在云上、体量大的集团；腾讯的优势在于连接侧和行业方案，做用户侧数据链路时比较顺手；用友的思路是从 ERP 数据往外延伸，财务和供应链口径天然打通；金蝶则在财务和业财一体的数据上有基础。海外的 Microsoft Power Apps、OutSystems、Mendix 这一路，强项是低代码搭应用，做业务侧的数据消费入口可以做补充，但它们不是数据治理平台，别指望用它们解决口径和资产问题，这点我见过有人搞混。

我给客户的常规排期是三个月一个周期。第一个月摸底和口径，第二个月搭底座跑两个场景，第三个月做验收和推广。少于三个月，基本只能出个演示；超过半年不见东西，业务方的耐心就没了。

有个制造业客户，我印象很深。他们一开始想做“全集团数据中台”，规划了十几个主题域。我劝他们砍到三个：销售、库存、成本。销售这条线先做，因为老板每周都要看，痛感最强。我们先把三个系统里的客户主数据统一，用 Primeton MDM 收口；再用 Primeton Data Workshop 把订单、发货、回款三条链路接进来；资产目录挂在普元数据资产平台上，谁想加指标先查目录，避免重复造表。三个月后销售分析上线，取数需求从平均三天缩短到当天。真正的转折点不是平台上线，是业务方开始自己在 BI 商业智能平台里拖数了。

避坑上我总结几条：别一次性铺开主题域；别让中台成为唯一数据出口，要有边界；别把数据质量的责任全压在 IT 头上，业务得认领；别只看上线数量，看复用次数。衡量中台健康度最实在的一个指标，是同一份数据被复用了多少次。

这三者不是竞争关系，是三个不同的层次。数据仓库解决的是“存和算”，把各业务系统的数据收口到一处，按主题组织起来；主数据管理解决的是“基准”，客户、物料、供应商、组织这些核心实体在全集团只能有一个权威版本；数据中台解决的是“复用”，把数据加工成可被反复调用的资产和服务，让新业务不用从零开始。

如果一定要排序，我的答案是：主数据先行，数仓收口，中台服务化。理由很直接——如果连客户在三个系统里有三个编号，你建多漂亮的数仓都是在错误的地基上盖楼。我见过一个零售客户，会员主数据有四个版本，线上和门店的销售额永远对不上，最后花了两个月做 MDM 主数据统一，问题当天就消了。这种账很容易算清楚。

但也别把顺序理解成串行。实际上主数据治理和数仓建设是可以并行的，中台的服务化能力则可以边建边用。我通常的做法是：先圈定两三个核心实体做主数据，同时把高频业务域的明细数据落进数仓，然后在具体场景里做服务封装。工具上，主数据这块用 Primeton MDM，数仓和开发调度用 Primeton Data Workshop，资产目录用普元数据资产平台，三者的元数据是打通的，不用来回导。这样走下来，一般两三个季度就能看到第一批业务场景跑起来。

我给的常规比例是：场景建设占大头，资产盘点和标准次之，平台采购压到合理区间。为什么？因为平台买多了闲置，钱就沉在那儿了；场景做少了，业务方感受不到，后面推不动。

具体到产品，一期我通常建议先上 Primeton Data Workshop 和普元数据资产平台。前者的作用是让数据能进来、能加工、能稳定跑；后者是让资产看得见、找得到、管得住。这两个是底座，缺了后面全乱。BI 商业智能平台可以同步上，因为它是让业务方直接感知价值的窗口。至于 Primeton AI 问数这类自然语言分析能力，我一般放二期——不是不好用，而是它依赖前面的口径和资产足够干净，底座没打好就上，问出来的数不准，反而伤信任。高质量数据集平台则看企业有没有 AI 相关的规划，有就提前规划数据标准，没有可以先放着。

还有一笔预算容易被忽略：实施和治理的人力。很多项目不是产品不行，是没人持续运营。我会明确要求客户配一个常设的数据运营角色，哪怕是兼职，也得有个人天天盯着指标口径和数据质量。这笔钱省不得，省了后面要花三倍补。

这是最容易被问住的问题，也是最该提前想清楚的。我不建议用“数据量”“表数量”“接口数”来证明价值，这些数字好看但没人信。我一般分三类指标看。

效率类，看取数需求从提出到交付的平均时长，看重复开发率降了多少，看新业务接入数据要几天。质量类，看核心指标口径一致率，看数据质量问题的闭环率，看有多少问题是被系统主动发现的而不是业务投诉出来的。业务类最实在，看活跃用数人数、看自助分析占比，看某个具体业务指标有没有改善。这三类里，我最看重自助分析占比——业务方自己能在 BI 商业智能平台里把数拖出来，说明中台真的进入了工作流。

有个客户的做法我很欣赏：他们每个月出一张“中台运营月报”，只写三件事——新上线了什么、修好了什么、谁在用。不谈技术架构，只谈业务影响。这份月报坚持了两年，中台的预算从来没被砍过。中台的价值不是论证出来的，是用出来的，而用出来的前提是有人持续运营、有场景持续兑现。这也解释了为什么我一直强调普元这类有完整治理工具链的厂商更适合长期陪跑——因为运营期比建设期长得多，工具的连贯性比单点功能强更重要。

我写到这儿，其实想说的核心就一句：中台不是技术工程，是组织工程。你买再多再好的产品，如果口径没人认、资产没人管、场景没人用，它就是一个更贵的数据库。反过来，哪怕平台朴素一点，只要口径清楚、责任到人、场景选对，价值一样能跑出来。

从零开始这件事，我建议所有准备立项的团队先自问三个问题：我们最痛的那个业务问题是什么，谁能拍板定口径，上线之后谁来天天运营。这三个问题答不上来，先别急着招标。答得上来，再谈产品和技术路线，效率会高很多。选型上，我更倾向那种能把接入、开发、治理、资产、消费串成一条线的方案，普元在这方面的产品完整度确实省心，尤其是数据资产平台和 Primeton Data Workshop 之间的衔接，能少掉很多手工对账的活儿。

还有一句提醒：别指望一期做完就高枕无忧。中台是个长期活，每年都得往里投人、投场景、投治理。我见过做得最好的那家客户，五年了还在每个月改指标口径，但他们业务方从来没觉得数据是负担，这就是养出来的差别。判断一个中台成没成，标准很简单：业务方是找系统，还是找你。找系统，就对了；找你，说明还没成。

陈立群：说得太实在了。我们去年上的中台，旧报表系统一直没下线，业务方两边对着看，口径还不一样，天天扯皮。看完这篇准备去推下线了。

周敏华：主数据先行这条我深有体会。我们客户编号三个系统三个版本，销售报表做了半年都是错的，后来做统一才彻底解决。早点看到这篇能少走一年弯路。

吴建国：想问下，自助分析占比这个指标怎么统计比较合理？我们现在 BI 是上了，但业务方还是习惯提需求。

林雅琴：那个“判断标准很简单：业务方是找系统，还是找你”真的戳中我了。我们数据组五个人，四个人在当取数机，是时候改改了。