数据中台死亡复盘：三年、两千万、十个工程师，最后留下了什么？

这篇文章不想再重复那些关于数据中台的宏大叙事。我想讲的是一个在无数家公司里反复上演、却很少被人公开复盘的故事中台是怎么死的死在哪里谁该负责以及——下一次我们能不能不再犯同样的错某家中型制造业企业2020 年前后跟上数字化转型的浪潮决定建数据中台。战略咨询公司的 PPT 做得很漂亮统一数据资产、打通业务孤岛、支撑智能决策。董事会被说服了预算批下来两千万起步招了十个工程师专门成立数据中台团队。第一年热火朝天。数仓搭起来了数据采集管道铺起来了元数据管理平台选型完毕指标体系文档洋洋洒洒写了两百页。第二年开始出现裂缝。业务部门说要的报表数据团队排期排到三个月后好不容易上线的自助分析平台销售团队打开用了一次说太难用了然后关掉继续发 Excel数据口径的争议会议开了一个又一个财务的收入和业务的收入对不上每次月度经营会议前都要消耗大量人力去对数。第三年中台团队开始士气涣散。几个核心工程师离职项目推进缓慢。新来的 CTO 对中台的必要性产生了质疑。年底一次组织架构调整数据中台团队被并入 IT 部门负责人降级预算腰斩。两年后原来的中台系统基本处于维护状态没有新功能开发没有业务部门主动要求接入。两千万的投入换来一套没人用的平台和若干份厚厚的技术文档。这不是一家公司的故事这是过去五年里中国数百家企业数据中台项目的集体缩影。也正因为这样的故事看得太多了我反而越来越觉得光讨论中台成败还不够更重要的是回到那些真正决定项目能不能落地的基础工作上。刚好我最近看到一份数仓建设解决方案内容很全面从数据标准规范到数据仓库搭建再到报表体系建设基本把企业最容易卡住的几个关键环节都梳理到了。如果你也在做数据建设这份资料可以拿来参考。需要自取https://s.fanruan.com/7igmg复制到浏览器一、原因一把平台当成了终点数据中台项目最常见的死法是把建平台本身当成了交付目标。立项时KPI 是这样定义的完成数仓分层建设、接入 N 个数据源、建立指标体系、上线自助分析平台……这些全是平台侧的指标没有一条是业务侧的指标。于是团队的注意力全部集中在把平台建起来上而不是让业务用起来上。这两件事听起来相似实则天壤之别。把平台建起来是一个工程问题——有钱、有人、有时间总能做到。让业务用起来是一个组织问题——你需要改变业务部门的工作习惯需要让他们相信数据比他们的直觉更可靠需要让取数这件事变得足够简单简单到比发消息给数据团队更快。工程问题可以靠资源堆出来组织问题不行。大多数数据中台项目在立项那一天就注定了失败的结局——因为他们定义成功的方式从来不包括业务部门真实使用率这个指标。二、原因二数据管道是隐藏的最大债务如果你去问那些数据中台项目的工程师最耗时间的是什么答案几乎清一色数据接入。这个答案让很多外行人感到意外。不是建模吗不是指标体系吗不是分析逻辑吗不是数据接入。一家中型企业的数据源往往比想象的要复杂得多ERP 系统可能是十年前部署的 SAPCRM 是 Salesforce 或者国内某个 SaaS生产系统是定制开发的 MES财务系统是用友或者金蝶电商数据来自天猫、京东、抖音各自的 API还有大量散落在各部门服务器上的 Excel 文件和 Access 数据库。每一个数据源都需要单独开发采集逻辑处理格式差异、编码差异、时区差异、增量逻辑、断点续传、数据质量校验……一个经验不足的团队光是把这些数据管道铺通就要耗掉整个项目 60% 以上的时间和人力。然后还没完。业务系统在升级API 接口在变数据格式在调整每一次上游变动都会打断下游的数据管道触发一轮又一轮的紧急修复。数据管道不是建完就能放着不管的资产它是需要持续维护的技术债务。很多中台项目到了第二年开始疲态尽显根本原因就在这里团队的大部分精力被困在数据管道的维护地狱里出不来根本没有余力去做真正有业务价值的分析建模工作。这是一个在立项阶段普遍被低估的成本。两千万的预算有时候有一半消耗在把数据搬过来这件事上。正因如此使用FineDataLink这类专业数据集成平台的团队往往能在这个环节省出大量精力——可视化配置数据源、自动处理增量同步、监控管道健康状态把原本需要三个工程师维护半年的管道工作压缩到一个人兼管的程度。这不是产品广告而是一个现实的工程选择把时间花在刀刃上而不是让最贵的人力去写 ETL 脚本。中台项目失败的团队大多数都在这个环节用了最笨的方式。三、原因三指标体系是一场政治战争数据中台有一项工作技术含量不高但往往是整个项目最消耗精力的环节统一指标口径。什么是活跃用户按登录算还是按有效操作算时间窗口是 7 天还是 30 天跨平台用户怎么去重什么是销售额含税还是不含税退款要不要扣减促销补贴算不算收入这些问题听起来是技术问题实质上是部门问题。销售部门希望销售额的口径尽量宽松因为这直接影响他们的绩效考核。财务部门需要严格的口径因为他们要对报表负责。市场部门有自己的获客成本计算方式和 CFO 认可的方式相差 30%。数据团队夹在中间每次统一口径的会议都是一场拉锯战。最后的结果往往是各方妥协出一个都不满意但都能接受的定义然后在实际使用中各部门悄悄回到自己原来的算法继续在决策会上拿着不同口径的数字互相攻击。这个问题没有技术解。它需要的是足够高层级的推动者——一个有权力拍板、敢于在部门利益面前坚持统一标准的 CDO 或者直接向 CEO 汇报的数据负责人。而大多数企业的数据团队在组织层级上根本没有这种权力。技术可以建出完美的指标平台但如果没有组织权力去推动口径统一这个平台永远是空转的。这是数据中台失败最深层、也最少被正视的原因。四、原因四自助分析是个美丽的谎言数据中台的标配愿景之一是让业务部门自己分析数据不再依赖数据团队取数。这个愿景很美也基本是谎言。不是说自助分析这个方向是错的而是大多数企业在推进自助分析时犯了一个根本性的错误他们低估了业务人员的学习成本也高估了业务人员改变工作习惯的意愿。一个典型的失败路径是这样的技术团队选了一款功能强大的 BI 工具部署完毕组织了两次培训然后等着业务部门自己用起来。结果是销售经理说我不会用让数据的同事帮我拉一下市场总监说这个图表不是我想要的样子能不能改财务说我还是直接导出 Excel 方便。三个月后自助分析平台的日活用户是数据团队自己的五个人。为什么会这样因为业务人员每天面对的是业绩压力、客户电话、审批流程没有时间也没有动力去学习一套新工具。除非这套工具比他们现在的方式发微信给数据同事 等一天 收到 Excel更快、更简单、更符合他们的思维习惯。这个门槛比大多数技术团队预想的要高得多。真正能在企业里被广泛使用的 BI 工具往往不是功能最强大的那个而是上手最快、最贴近业务语言的那个。这也是为什么FineBI这类工具能在很多企业里活下来——它不追求技术人员的极客感而是在设计上反复打磨业务人员第一次打开能不能在十分钟内自己做出一张有意义的图这个体验。自助分析能不能真正落地工具的易用性是决定性变量而不是功能清单的长短。五、那两千万最后留下了什么复盘完四个原因我们可以回答标题的问题了。两千万的投入三年的时间十个工程师最后通常留下这些东西留下来的一套基本可用的数据仓库底座这是真实资产虽然维护成本持续存在若干条数据管道接通了主要业务系统的数据采集一批成长起来的数据工程师他们很快会离职去下一家公司继续建中台以及厚厚的技术文档和无数次指标对齐会议的会议纪要。消失的那个统一数据资产、智能决策支撑的愿景建设初期的团队热情和组织推动力以及本可以用来做其他事情的两千万。这个结果比完全失败更令人沮丧——因为它是一种半完成状态既没有成功到值得复制也没有失败到可以彻底放弃就这样悬在那里消耗着维护资源等待下一轮组织变动来决定它的命运。六、下一次能不能不一样数据中台没有原罪但它的死亡方式高度可预测高度可避免。如果要从这些失败里提炼出几条真正有用的教训我会说第一从最小可用价值开始而不是从最完整架构开始。找到一个业务部门最痛的数据需求在三个月内用最简单的方式解决它让他们看到数据的价值。然后再扩展。不要等到平台建好了再去找用户。第二数据管道是基础设施不是可以自研的工程项目。把时间花在建数据管道上是投资回报率最低的选择。这个环节用成熟的集成工具替代自研释放出来的工程师时间用来做更有价值的建模和分析。第三指标体系的推动者必须有组织权力。如果数据负责人没有跨部门的话语权指标统一就是空话先解决组织问题再建技术平台。第四BI 工具的选型要以业务人员的使用率为标准而不是技术能力清单。一个功能砍掉一半但业务每天都在用的工具远比功能完整但只有数据团队在用的工具有价值。第五承认数据中台是一个长期工程而不是一个项目。它没有竣工时间只有持续迭代。用项目制的思维去做是它失败的组织根源。这五条没有一条是新发现都是行业里被反复说过的话。但奇怪的是每一轮新的中台热潮来临同样的坑还是会被踩进去。也许真正需要复盘的不只是技术选型和项目管理而是我们对数字化转型这件事本身的认知方式——它从来不是一个可以用钱和人堆出来的工程问题而是一个需要组织、文化、技术三者同时进化的系统性命题。这个命题没有捷径也没有标准答案。它只有一条路从真实的失败里一次次提炼出真实的教训。