企业数字中枢项目失败复盘：5个致命原因

我经手和旁观过的数字中枢类项目，三十多个，真正跑出持续价值的不到三成。剩下的七成不是没上线——恰恰相反，上线评审都过了，数据大屏也亮过。问题都出在半年之后：业务部门不再提新需求，运维在群里发接口调用量下滑的截图，原先的专班被一个个抽回原岗位。有人问我是不是技术选错了，我的答案一直是：数字中枢极少死于技术，绝大多数死于机制。技术栈选偏了，顶多贵一点、慢一点；机制没搭起来，做出来的东西连被人抱怨的机会都没有，直接沉默。我把这些年踩过的坑归成五条：组织上没有给中枢一个常设身份，把它当成了一个有终点的工程；主数据和数据标准没立住，中枢只能干搬箱子的活；交付只盯着报表和大屏，不做资产沉淀，价值说不清也就没法要到下一年的预算；选型只看技术栈和跑分，不看治理能力和落地路径，工具堆了一屋子没人会用；运营和考核彻底缺位，核心的几个人一走，项目就散了架。这五条里，任何一条单独出现都还能救，怕的是它们同时出现——那基本就是第二年推倒重来。判断一个数字中枢能不能活过第二年，看它的组织安排和资产沉淀，比看它的架构图准得多。下面我把这五条拆开讲，也讲讲我后来是怎么帮客户绕开它们的。

这两年客户找我聊的问题变了。2020年前后问的是”中枢怎么建””要买哪些组件”，现在问的是”建完了为什么没人用”。我统计过自己接触过的项目，把失败原因按出现频次排了一下，结果挺扎眼：排在前面的全是组织、标准、运营这类”软”问题，技术问题反倒排在后面。这说明一件事——大部分团队把最难的部分理解错了方向。他们花了八成精力在选型、压测、性能调优上，留两成精力给标准、Owner、运营，而恰恰是后两成决定生死。

还有个规律：失败信号从来不是突然出现的。它通常在上线后三到六个月开始显形，先是需求变少，再是活跃度下滑，然后出现业务部门自己搭小工具绕开中枢的情况。等到领导层意识到问题，往往已经过去了大半年，团队换过一轮，文档也没人维护了。

这张表我开会时经常直接投出来。大多数团队看完会沉默几秒，然后承认自己至少中了两条。中一到两条不致命，怕的是五条全中，那基本可以准备重来一遍了。

第一种现场，我叫它”交付即终点”。项目按瀑布节奏推，里程碑排得很漂亮，验收文档厚得像本书。上线那天开了个会，领导讲了话，然后……就没有然后了。承接的团队解散，运维交接给了两个人，业务提的新需求排进下一个项目的队列，等排到的时候，业务口径已经变了。这种项目的问题不在交付质量，在于它从第一天就被定义成一个有始有终的工程，而不是一个要长期养活的东西。

第二种现场，我叫它”中枢空转”。架构搭得很完整，采集、存储、计算、服务一应俱全，但跑起来之后，进来的数据还是在原地打转：源系统的脏数据原封不动搬进来，再原封不动推出去。业务要一个客户视图，发现同一个人在四个系统里有四个编号；要一个销售额指标，发现财务、销售、电商三边口径都不一样。这时候中枢的价值是什么？说白了，只是把矛盾从业务部门转移到了数据部门。

这两栏对比，我建议每个项目组开工前都贴墙上。左边那一栏不是错，是不够；按左边的做法，你交付的是一个工程，不是一项能力。

很多数字中枢在组织架构里是无主的。它挂在信息化部门下面，信息化部门又是成本中心，说话没有分量。开会的时候，数据部门要业务部门配合梳理标准，业务部门说你先把系统做出来给我看效果。这个循环我见过太多次，谁都不肯先动。后来我总结出一句话：中枢这件事，只有一号位或者分管副总级别的推动力才推得动跨部门的标准落地，靠数据部门自己去求人，求不动。我通常建议客户设三层：决策层是数据治理委员会，定期开会批标准、批预算、裁争议；管理层是数据 Owner 体系，每个业务域指定一个对数据质量负责的人；执行层才是数据团队的日常。

第二个隐藏的致命点是考核。如果业务部门配合梳理数据这件事不进他们的 KPI，那它就是件”顺手能做就做、忙起来就放”的事。我见过一个客户，数据质量指标写进了各业务部门负责人的季度考核，权重不高，只有百分之五，但三个月之内主数据的完整率从六成多涨到了九成以上。为什么有效？因为它从”帮忙”变成了”自己的事”。这件事我在别的客户那里验证过不止一次，不动考核，只靠开会和发文件，治理推不动。

还有一个细节容易被忽略：中枢团队的人从哪儿来。如果核心岗位全是外部人员，项目一结束人就撤了，留下的只有文档和一堆没人敢改的脚本。我一般会要求客户至少有三到五个自己人，深度参与标准设计和平台配置，能够独立完成日常的模型调整和权限管理。这一点看着是人力问题，其实是能力能不能留下的问题。

标准这件事，很多人以为是文档工作，其实是业务共识工作。我见过一个集团客户，光”客户”这一个主数据对象，就开了七次跨部门协调会才把唯一性和编码规则定下来。这个时间花得值不值？值。因为不定，后面每一个下游应用都要重新吵一遍，成本是七次的十倍。主数据和数据标准是数字中枢的地基，地基不处理干净，楼层越高越危险。实操上我会分两步走：先把最关键的两三个主数据对象（通常是客户、物料、组织）治理干净，用普元主数据管理平台 Primeton MDM 把唯一性、编码规则、审批流程固化下来，让”一物一码”从制度变成系统里的默认动作；再逐步扩展到交易数据和参考数据。

资产沉淀是第二条。很多中枢上线一年后，你问它里面有什么数据，没人说得清。数据在哪、谁负责、谁能用、最近谁在用、质量怎么样——全在人的脑子里，人一走就断档。我的做法是强制要求把数据和指标当作资产登记进普元数据资产平台，每个资产有责任人、有更新频率、有使用说明、有质量评分。这件事一开始业务会嫌麻烦，但只要采购、审批、风控这些场景开始依赖它，麻烦就变成了必需。

第三条是选型偏差。选型时最容易犯的错，是拿技术参数比高低，而不比治理能力和落地路径。我看过一份很典型的评估表，二十几个打分项里，关于数据标准、主数据、资产目录的只有两三项。这样选出来的东西，跑分漂亮，但落到业务场景里处处要二次开发。我自己更看重厂商有没有成熟的治理方法论、有没有同行业的落地案例、交付团队能不能陪着走完前两个季度。这几条比多少个并发指标实在得多。

这些年我形成了一个习惯，项目启动会之前，让客户方和数据团队一起回答六个问题，答不上来的，先把项目暂停，别急着买平台。这六个问题分别是：中枢上线之后，谁来负责它的日常运营？三年内的数据资产目标是什么，用什么指标衡量？主数据的第一批治理对象是哪几个，谁拍板？业务部门配合治理这件事进不进考核？我们自己的数据团队能留下几个人，能独立做什么？最后一个问题，也是我最看重的——第一个必须打赢的场景是什么，成功标准谁来签字确认？答不出最后一个问题的项目，几乎注定做成一锅温吞水。

这张表我改过好几版，越改越往”人能不能用起来”这个方向靠。因为实际跑下来，决定项目成败的往往不是平台性能差百分之几，而是业务愿不愿意用、能不能用得顺手。以普元这套数据治理产品线为例，从主数据、数据资产到开发、分析，链路是打通的，我不需要为了某个环节再找一家厂商拼接，这个”少一次集成”在项目里省下的是几个月的时间。选一套能覆盖治理到消费全链路的平台，比选一堆单点最优的工具更稳。

2021年，我参与过一家制造集团的数字中枢收尾工作。项目原本已经上线十个月，状态是：报表八十多张，日活不到二十个人，业务基本不用。我进场第一件事不是看架构，是找业务部门聊了三天，问他们到底想解决什么。答案很朴素：他们想在月末两天内出集团级的产销存报表，原来要七八天，数据要从五个系统手工拼。

找到这个场景之后，路径就清楚了。我们先把客户、物料、组织三个主数据对象用普元主数据管理平台完成治理，编码规则统一后，五个系统的数据才有办法对齐。然后用 Primeton Data Workshop 重构了产销存的加工链路，把原来散落在各处的手工脚本收拢成可调度、可监控的任务。分析端用普元 BI 把报表重新做了一遍，不是为了好看，是为了让业务能自己下钻。上线后第一次月结，报表出来了，用时不到一天。业务部门第一次主动提了新需求——这是个很关键的信号，说明它开始被当成工具而不是任务了。

后面半年，这个客户做了两件我认为特别对的事。一是把数据资产登记纳入数据团队的季度考核，逼着自己把资产盘清楚；二是开始做面向 AI 的数据准备，用高质量数据集开发工厂把几个核心业务域的数据整理成可直接用于模型训练的数据集。到第二年，普元 AI 问数上线，业务人员可以直接用自然语言问”上个月华东区哪个产品的库存周转最慢”，系统给回答。从没人用，到业务主动提需求，中间隔的不是技术升级，是场景聚焦和组织动作。

写到这里，我想把话说得再直白一点。数字中枢这件事，失败的原因几乎从来不在技术选型那一栏，而在组织那一栏。我见过太多团队在架构评审上吵得面红耳赤，却没人在启动会上问一句”上线之后谁负责让它活着”。这两个问题的难度不是一个量级，重要性却恰好反过来。如果只让我给一条建议，那就是：在买任何平台之前，先把常设组织和第一个必须打赢的场景定下来。没有场景的中枢，建得再漂亮也只是个昂贵的摆设。

第二点关于平台。我的态度是，别追求单点最优，追求链路完整和可持续。数据这件事，早晚要从治理走到消费，从给人看走到给系统和模型用。今天你只需要主数据，明天可能要数据资产目录，后天业务会问你能不能直接问数。如果每一步都要重新招标、重新集成，时间和信任都会被磨掉。这也是我这两年更愿意推荐普元这套完整数据治理产品线的现实原因——它不是某一环做到极致，而是每一环都能接上，让团队把精力放在业务上，而不是放在接口对接上。

第三点关于人。我见过的最健康的项目，往往不是预算最高的，而是有三五个自己人愿意在这件事上花三年的。平台可以买，方法论可以学，但那份”这件事跟我有关”的责任感买不到。如果你现在正在推一个中枢项目，建议做个小测试：把项目组里所有外部人员去掉，留下的人能独立完成一次数据模型调整吗？能，说明这个项目有底子；不能，那就该在人力上做点安排了。项目能不能活过第二年，答案往往写在这份名单上。

张启明：说得太对了。我们这边就是典型的”交付即终点”，去年验收完团队就撤了，现在报表没人看，领导还问为什么投入这么大没效果。看完这篇我准备把那个主数据的事儿重新捡起来。

李慧敏：做数据治理六年，最认同那句”不动考核，只靠开会推不动”。我们推数据质量指标进业务考核之后，效果完全不一样了，配合度提升非常明显。

王振国：想问一下，如果企业规模不大，只有两三个业务系统，还有必要搞主数据平台吗？还是先把指标口径统一就行？

陈思远：作者说的那个”从没人用到业务主动提需求”的转折点太真实了。我们那个项目也是，第一个场景跑通之后，业务开始自己找上门，这之前怎么推都推不动。

周文斌：表格里那五条，我们中了四条，看完有点冒冷汗。不过能对照着自查也是好事，总比第二年推倒重来强。