数据中台烂尾，表面上是平台闲置、报表无人使用，实质上是建设目标与业务价值脱节。企业把“接入多少系统、建设多少模型、完成多少治理”当成项目成果，却没有回答一个更关键的问题：数据是否改变了经营决策，或让某项业务动作变得更有效。
先判断：问题出在平台还是机制
诊断不能从技术模块开始，而应从立项目标倒查。将原始目标分为“已产生业务价值”“已上线但未被使用”“尚未完成”三类。如果前一类占比很低，说明问题通常不是某个功能缺失，而是整体逻辑失效。
常见病根有三种。第一，平台由技术部门主导，接入和治理先于业务场景，导致数据集中却无人使用。第二，治理过度工程化，一开始就追求全量标准、全面稽核和完整血缘，项目周期不断拉长，业务迟迟看不到收益。第三，责任错位：业务不对使用效果负责，数据团队不掌握业务资源，技术团队也不承担价值结果，最终形成“谁都参与、没人负责”。
修补还是重建
决策应围绕三个问题展开：现有平台是否已经解决过至少一个核心业务问题；业务部门是否仍然信任其中的数据；已经接入的数据、验证过的口径和跑通的模型是否具备复用价值。
如果平台部分可用，通常应保留底座，转向场景重建；如果数据资产仍有价值，应“弃壳留核”；如果数据质量低、口径混乱，且旧平台已经形成“数据不准、使用麻烦”的组织认知，则继续修补可能只是延长失败。判断重点不是保住原项目，而是比较继续修补与重新启动的成本，以及重建后能否覆盖更高价值的业务场景。
用业务闭环反推架构
重建不宜从技术架构开始，而应先锁定一个能验证价值的场景。经营驾驶舱要服务具体决策，而不是堆叠指标；客户流失预警必须连接触达和反馈，否则模型得分没有业务意义；库存优化则应先统一库存周转、缺货和呆滞库存等基础口径，再考虑预测模型。
因此，数据架构应由业务动作反推：需要什么数据、采用什么口径、结果由谁使用、是否能进入执行系统。无法形成“识别—行动—反馈”闭环的场景，不应被包装成成功案例。
补救阶段可按三步推进：先用一至两个月完成场景锁定和数据摸底，再用两至四个月打通最小闭环，随后用三至六个月验证业务效果。评估时只看库存周转、客户挽回或决策效率等业务指标，不把接入数据源数量和模型数量当作成果。数据中台能否重生，取决于它是否重新赢得业务信任，而不是平台保留了多少功能。