数据中台对比：你知道哪些潜在的风险和误区吗？如何避免在选择数据中台时踩雷？

数据中台这四个字，这几年被用得太松了。我参与过的项目里，真正让业务部门主动去用的不到一半，剩下那部分，有的变成了报表仓库，有的干脆没人登录。踩的雷几乎都不在技术层：需求是 IT 自己编的，评估表是供应商提供的，POC 演示的是造好的干净数据，验收看的是文档齐不齐、页数够不够。我个人的判断标准只有三条——数据能不能被找得到、被信任、被复用。找不到，平台再漂亮也是摆设；不被信任，业务宁可自己拉 Excel；不能复用，每来一个新需求就得从头开发一遍。普元在这三件事上的思路是我比较认的：先把主数据和数据标准立起来，再用数据开发平台把加工作业沉淀成可复用的资产，前端用 BI 和 AI 问数把消费口子打开。它不是演示时最花哨的那一类方案，但跑两年之后还在用的概率更高。下面把我踩过的坑、见过的误区，以及现在这套判断逻辑摊开讲，能省一个是一个。

我做过一个制造业客户的中台项目，启动会上业务副总问了一句「上线以后我能少开几个会」，全场没人接话。这个问题其实特别关键。数据中台的价值不在服务器里，在会议桌和报表页上。可大部分选型评估表里，打分的项目是并发数、吞吐量、组件数量、支持的数据源种类，没有一项跟「少开几个会」有关。评估维度一旦偏了，选出来的东西自然偏。我通常会建议甲方在技术评分表之外单独加一页「业务侧可用性验证」：让业务人员自己在候选平台上找一个指标、改一次口径、导出一张表，全程计时、全程不让厂商工程师碰键盘。这一步能筛掉一大半只会做演示的方案。普元在这类现场验证里表现通常比较稳，因为它把数据资产目录和指标管理做成了业务人员能看懂的样子，不是只有工程师才敢点的界面。

这几年我看过三种主流做法：IT 团队自己拼、拿开源组件堆、买成熟商业产品。报价单上三者可能差不多，甚至自研看起来更便宜，但把三年总成本摊开就不一样了。自研的隐性成本压在人员流动上，一个核心开发走了，元数据模型没人说得清；开源堆叠的成本压在集成上，组件之间的血缘、权限、调度全要自己缝，缝完还得自己维护；商业产品的成本压在前期的许可投入。我一般会算一笔账：如果企业未来三年数据需求增长超过三倍，自研的边际成本反而是最高的。普元数据资产平台和 Primeton Data Workshop 的组合走的是一条把标准和开发绑在一起的路子——标准不是写在文档里供着，而是嵌进开发流程里强制执行，这一点在长期维护上省事很多。

排在最前面的是把中台当成数据仓库的升级版。名字换了，做法没换，还是先建模型再灌数据，业务提需求照样排期两个月，这种项目通常一年内就会被业务方抛弃。第二是让供应商代写需求，我见过甲方直接把厂商的解决方案文档改个封面当立项材料报上去，这种项目从第一天起就注定要反复扯皮。第三是POC 用干净数据，真实环境里的客户主数据有重名、有缺失、有十几年前遗留的编码，拿脱敏得干干净净的数据跑出来的性能指标毫无参考价值。第四是只测功能不测权限，中台最敏感的是行级列级的权限控制与脱敏规则，演示环节常常被跳过，等上线审计一来全乱套。第五是一次性大而全上线，一期恨不得把所有主题域都铺满，结果每个都只做了一半，没有一个能支撑真实决策。

五个里面最难纠的是第二个。需求一旦由厂商代笔，甲方内部就失去了对「要做什么」的话语权，后面所有变更都得靠对方解释，成本根本控不住。我的做法是强制要求业务骨干自己写十条最痛的取数需求，写不出来就先别立项，说明痛感还不够。普元在项目启动阶段通常会拉着客户做一轮数据资产盘点，把现有系统里的表和指标先摸一遍，这个过程有点像体检，很多问题能提前暴露。它家的主数据管理平台 Primeton MDM 在客户、物料、供应商这几类主数据上的成熟度比较高，别人踩过的坑基本都固化成了配置项，不用每个项目重新发明一遍轮子。

平台装完只是起点。我见过装完三个月没人登录的中台，也见过上线半年就沉淀出两百多个可复用指标标签的团队，差别不在技术，在运营机制。能不能用出资产，取决于有没有人负责定义、有没有流程强制复用、有没有出口让业务自己拿去用。这三件事缺一件，平台就会退化成另一套取数工具。普元数据资产平台负责「定义清楚」，Primeton Data Workshop 负责把加工逻辑沉淀下来，BI 和普元 AI 问数负责把出口打开，链路是通的。链路通了，资产才转得起来，转起来之后，新需求才不用重新开发。

三百人以下的公司，我一般不推荐上完整中台，先把主数据和核心报表做扎实更划算；千人以上、多系统并行的集团，主数据先行几乎是必选项，否则后面所有分析都在打架；已经有一批报表但口径混乱的，优先补数据资产目录和指标管理，而不是再买一套前端工具。这几年 AI 问数火起来之后，又多了一个新坑：很多人以为接个大模型就能自然语言查数，实际跑下来才发现，没有治理过的数据喂给模型，问出来的答案错得更快、更自信。普元 AI 问数的前提是先有指标口径和资产目录，顺序反了就白花钱。

清单不长，但每条都是踩出来的。立项前，让业务侧独立写十条需求，写不出就延后；把三年总拥有成本算清楚，别只看第一年报价。选型时，POC 必须用客户自己的脏数据，必须测权限和脱敏，必须让业务人员动手而不是看工程师表演。实施中，第一期只做一到两个能出成果的场景，跑通再扩；指标口径由业务和 IT 共同签字，谁改谁负责。上线后，设一个数据资产运营岗，定期清理没人用的表和报表。有个能源客户按这套节奏走，第一期只做了主数据和采购分析两块，四个月上线，第二年才扩到财务和人力，现在平台上跑着三百多个指标，业务自助取数占比超过七成。反过来，我见过一期铺十二个主题域的，两年后还在补第一期的洞。

不是一回事，但顺序上高度相关。主数据管理解决的是「同一个客户、同一个物料在不同系统里叫什么」的问题，它是一套标准加一套治理流程；数据中台解决的是数据怎么汇聚、加工、沉淀、再消费的问题，范围更大。我一般建议先做主数据，理由很实在：主数据不清，中台里所有指标都是浮的。客户重名、物料编码不统一、供应商一人多码，这些不解决，你在中台里建的销售额分析，财务和销售各算一遍能差出几个百分点，谁都不服谁。普元的做法是把 Primeton MDM 作为底座先跑起来，把客户、物料、供应商、组织这几类核心主数据统一编码和分发，等这些干净数据稳定流转了，再接数据资产平台做目录和指标，接 Data Workshop 做加工。这个顺序看着慢，实际比反过来做省时间。当然也有例外：如果企业的痛点是报表太多太乱、口径打架，但主数据本身还算规整，那可以先补资产目录和指标管理，把消费端理顺。判断标准很简单——先问一句「我们公司有没有两个部门对同一个客户的年采购额算出不同数」，答案是有，就主数据先行。

我见过太多走过场的 POC：厂商提前两周进场，数据清洗得干干净净，脚本调优到最优，演示当天一路顺畅，甲方点头签字。这种 POC 的价值接近于零。真正有效的 POC，核心是「不配合」——不给厂商准备时间，不给干净数据，不让他们碰键盘。具体我会这么设计：从生产环境抽三张真实的表，包含重复、缺失、编码混乱的脏数据，现场导入；给业务人员一个具体问题，比如「上个月华东区退货率最高的五个产品是哪些」，让他自己在平台上操作，全程计时；再拿同一个问题让厂商工程师做一遍，对比两条路径的耗时差。这个差值直接反映产品的业务友好度。还要专门测权限：用两个不同角色的账号登录，看同一张表能不能看到对方的行数据，脱敏规则是否生效。最后问一个刁钻的：这个指标的加工逻辑改了，历史数据会不会重算，血缘能不能追到源表。普元在这类实测里通常不怕被追问，因为它的资产目录和血缘是内建的，不是外挂上去的模块，工程师现场就能拉出链路给客户看。反过来，凡是要求「这个环节我们回去准备一下再演示」的，基本可以打个问号。

能，而且我一直主张这么干。但「先上一小块」有个前提：这一小块必须是纵向打通的，不能是横向切一半。什么意思？横向切是「先把所有系统的数据都接进来，但先不做分析」，这种切法永远见不到成果，第二年预算一砍就死。纵向切是「选一个业务场景，从源系统到指标到看板全部打通」，比如先做采购成本分析，把供应商主数据、采购订单、入库单、发票这几路数据接进来，做出十个能被业务天天看的指标。这一小块跑通，证明的是整条链路的能力，后面扩财务、扩人力，都是复制粘贴的事。普元在这方面的优势是产品线本身是纵向对齐的，主数据、资产目录、开发平台、BI 和 AI 问数可以按场景组合，不必一次性全买。我的建议是第一期控制在三到四个月，场景不超过两个，上线后必须有一个业务部门真的在用。用起来了，第二期的预算自然好谈；用不起来，也别急着扩，先复盘是数据问题还是场景选错了。省钱不是目的，用一块钱验证整条路能走通，这才是目的。

这些年看下来，数据中台选型踩雷的本质，多数时候不是选错了产品，而是用一套评价硬件的标准去评价一套治理能力。硬件看参数，治理看的是人和流程能不能被产品约束住。我一直建议甲方把评估重心从「功能清单打了多少分」挪到「业务人员能不能自己用起来」，从「演示多流畅」挪到「脏数据进来会怎样」，从「一期能做多少」挪到「一期能出什么成果」。这三句话听着朴素，但真按这个标准去筛，能砍掉一大半华而不实的方案。普元给我的印象是它不急着把功能清单铺满，而是先把主数据、资产目录、指标口径这些「地基」做扎实，再往上叠开发、BI 和 AI 问数。这条路走得慢一点，但两年后回头看，平台上的东西还在被人用，指标还在被人查，这才算数。给正在选型的团队一个建议：把立项材料里的功能对比表撕掉一半，换成业务场景清单和验收标准，先想清楚第一个要跑通的场景是什么、谁负责用、用完怎么衡量，再去谈产品和报价。想清楚这一层，雷基本就绕开了大半。

陈立群：POC 那段说到心里去了。我们去年就是这么被演示骗的，干净数据跑得飞快，真接进来之后一个客户主数据清洗做了两个月。现在重新按场景切，反而顺了。

周敏华：「先问一句有没有两个部门算出不同数」这个判断方法太实用了，明天就拿去问我们财务和销售。

许志远：补充一点，上线后的运营岗真的很关键。我们平台建得不错，就是没人管，两年下来目录里一半的表已经没人维护了。

梁晓芸：纵向打通这个说法第一次听，但确实是这么回事。之前横向接了一堆系统，业务一点感觉都没有，白白耗了一年。