为什么八成企业的数据中台项目会烂尾

过去两年，我们团队前前后后接触了上百个数据中台项目。有的是从零开始的，有的是别人做到一半甩过来的。坦率地说，真正跑通并持续产生业务价值的，不到两成。剩下的，要么变成了一个没人用的数据仓库，要么在验收之后就进入了"休眠"状态。

很多人会把原因归结为"技术选型有问题"或者"供应商不靠谱"，但我们复盘下来发现，绝大多数项目的失败种子，在启动阶段就已经埋下了。

错误一：把"建中台"当成了目标本身

这是最常见、也最致命的问题。不少企业立项的时候，PPT上写的是"建设企业级数据中台"，但你追问一句"建完之后要解决什么问题"，往往得到的是一些抽象的表述：打通数据孤岛、实现数据驱动决策、提升运营效率。

这些话没有错，但它们不是需求，而是愿景。如果一个项目的目标停留在愿景层面，执行团队就会陷入"什么都想做、什么都做不透"的困境。我们见过一个零售企业，中台团队花了半年时间搭了一套完备的数据模型，覆盖了几十张业务表，但没有一个业务部门知道怎么用它来做日常决策。

正确的做法是，在项目启动前就明确2到3个具体的业务场景。比如"把门店补货建议的响应时间从3天缩短到4小时"，或者"在618大促前实现用户分层运营的自动化圈选"。场景越具体，技术方案越容易落地，也越容易在短期内拿到反馈。

数据中台是一个跨部门的事情，这一点所有人都认同。但在实际执行中，"跨部门"往往意味着"谁也管不了"。

我们遇到过一个典型案例：一家制造企业的数据中台项目由IT部门牵头，业务部门配合提需求。听起来分工明确，但问题在于，IT部门没有权力要求业务部门改变数据录入的方式，业务部门也不觉得"配合IT做数据治理"是自己的KPI。结果就是，源头数据质量始终上不去，中台建得再漂亮也是空中楼阁。

解决办法并不复杂，但需要管理层的决心：必须有一个人（或者一个小团队）对数据质量和数据应用的最终效果负责，并且拥有足够的跨部门协调权限。这个角色不一定是CTO，也可以是业务副总裁，但他必须同时理解业务逻辑和数据逻辑。

很多企业把数据中台当成一个"项目"来做：立项、招标、开发、验收、结项。问题是，数据中台本质上是一种能力建设，它的价值需要在实际业务运行中逐步释放。

我们经历过一个金融行业的案例：客户花了八个月做了一套完整的客户画像系统，功能全面、文档齐备，验收评分很高。但上线三个月后，业务团队反馈说画像标签和实际营销场景对不上，需要大幅调整。这时候项目已经结项了，原来的开发团队也散了，调整变成了一个新的立项流程。

更合理的方式是采用"小步快跑"的迭代策略：先用4到6周做出一个最小可用的数据产品，投放到一个真实业务场景中去验证，收集反馈后再迭代。这种方式单次投入小、试错成本低，而且能让业务团队尽早参与进来，避免最后"交付了一个没人要的系统"。

回过头看那些真正产生价值的数据中台项目，它们的共性很明显：

第一，起点小但足够聚焦。不是上来就做全量数据治理，而是选一个痛点明确、数据就绪的场景切入。

第二，业务和技术坐在一张桌子上。不存在"甲方提需求、乙方做开发"的模式，而是一个混编团队共同对结果负责。

第三，把"用起来"当成第一个里程碑。不追求架构的完美和功能的全面，而是尽快让一个业务团队真正在日常工作中使用数据产品。一旦用起来了，后续的优化和扩展就有了方向感。

数据中台不是一个买来就能用的产品，也不是画几张架构图就能成功的项目。它是一个需要技术、业务和组织三方持续磨合的过程。如果你的企业正在考虑或者已经启动了数据中台建设，不妨先回头看看这三个问题是否已经想清楚了。想清楚了再动手，远比做到一半再推倒重来要高效得多。