普元即联项目失败复盘：3个致命原因

普元即联项目失败复盘：3个致命原因

我做过十多年企业数据项目，也旁观过不少同类项目的起落。说实话，数据集成类项目失败，极少是因为某一款工具不行。真正的失败往往在项目启动那一刻就埋下了。我的判断是：项目失败跟工具强弱的关系不到三成，剩下七成都栽在人、流程和预期管理上。我见过一个团队买了功能很全的平台，结果三个月后项目停摆，复盘时发现，全公司没人能说清”主数据以谁为准”。

先解释一下我这里的”失败”是什么。不是系统崩溃，也不是数据全丢，而是那种很常见的结局：系统上线了，报表跑出来了，但业务部门不用，一线该手工填 Excel 还是手工填，项目组一撤，数据又开始脏回去。这种叫”僵尸系统”，比直接失败更消耗企业信心。

我参与过的一个项目，当时用的是普元的 Primeton MDM 主数据管理平台。系统本身没问题，功能覆盖度也够。真正出问题的地方，是客户内部对”物料编码由谁负责”这件事争了两个月。IT 说该业务定，业务说该 IT 定，最后谁也没定，数据一直靠人工维护，一年后主数据准确率还不到 60%。这件事让我彻底改变了对项目失败原因的排序。

所以这篇文章，我会按我自己的复盘逻辑，拆出三个我认为最致命的原因，再说清楚哪些情况该怎么取舍，最后给几个避坑的做法。读完之后，你至少能提前识别自己项目里最危险的那一环。

我见过最常见的一种立项书写法是：建设企业数据中台，实现数据统一管理，提升数据质量。这句话看着没问题，但它没法验收。没有可量化的业务目标，项目就没有边界，需求会无限膨胀，工期会无限延后。

我通常会要求客户在立项阶段就回答一个问题：这个项目做成了，哪个部门的哪个指标会变好？如果答不上来，我会建议先别立项。因为一个说不清价值的项目，在推进过程中一定会被业务方当成负担。

我见过一个客户把目标定成”数据准确率从 72% 提到 95%”、”每月报表从人工 5 天缩到 1 天”。有这两个数字，项目组的每一个动作都能被检验，争论也少了很多。这种目标看起来很土，但它能救命。

反过来，目标定成”建设统一数据平台”的项目，我观察到的结局基本都是：第一阶段勉强上线，第二阶段没人提，第三阶段预算被砍。这不是技术能力问题，是目标本身的失败。

我做项目健康度检查时，通常会看下面这张表。它不能预测一切，但能帮我把风险提前暴露出来。

这张表我用过很多次。它最大的价值不是发现问题，而是让管理层看到问题。很多项目失败，不是因为没人看见风险，而是看见了没人愿意公开说。

我之前服务过一家制造企业，他们在立项时就不肯设 Owner，理由是”等系统上线了自然就有了”。结果系统上线半年，主数据准确率一直在 65% 上下打转。后来补了 Owner，三个月内提到 90% 以上。技术没变，人变了，结果就变了。

很多企业把数据治理当成一个项目来做。预算批了，团队建了，一年后交付验收，团队解散。但数据是会持续变脏的，一次性治理必然反弹。这件事我踩过坑，后来才真正接受。

我见过一个集团做数据治理，两年投入不小，上线时各项指标都很漂亮。项目组一撤，八个月后我去复查，数据质量问题又回来了七成。原因很简单：新系统不断接入，业务规则不断调整，而没有人在持续盯着。

我现在的做法是，把数据治理拆成”建设期”和”运营期”两段，运营期必须有专职角色，有例会，有考核。没有运营机制的数据治理，等于花钱买了一次性清洁服务。

环节，普元数据资产平台这类工具的价值就体现出来了。它把数据目录、血缘、质量规则沉淀下来，让运营有抓手，不至于靠人和 Excel 硬撑。工具不会替你做运营，但能让运营变得可执行。

这是我最想强调的一点。很多项目一启动就进入选型阶段，比功能、比性能、比价格，选完了才想”我们到底要治哪些数据”。顺序反了，后面所有工作都会返工。

正常的顺序我应该这样排：先梳理业务域和数据域，明确哪些数据要治理、治理到什么程度、谁来负责；然后才是选平台。Primeton Data Workshop 数据开发平台这类工具，应该在业务梳理完成后，用来承接开发落地，而不是用来倒推业务需求。

我见过一家零售企业，先买了平台，再回头梳理，最后发现买的功能有一半用不上，真正急需的实时数据同步能力反而没覆盖。这笔钱花得很冤，但责任不在厂商。

顺便说一句，有些项目失败还跟”参照别人家怎么做”有关。看到同行上了某个方案，自己就照搬。但两家企业的数据基础、组织成熟度、业务节奏完全不同，照搬的结果通常是一地鸡毛。方法可以借鉴，节奏必须自己定。

前面说了三个致命原因，主要在人。但我也得承认，工具选得对，能显著降低失败概率。这里我按自己实际用过的感受，说说不同环节该看什么能力。

这张表不是选型清单，只是我自己评估时会走的路径。我更看重的是工具之间能不能连起来用，而不是单点功能有多强。一个环节买五个最强工具，拼起来互相不认，照样失败。

普元在这条链路上的产品是成套的：从 MDM 管主数据，到数据资产平台做盘点，再到 Data Workshop 做开发、BI 做分析、AI 问数做交互、高质量数据集平台服务 AI 场景。成套的好处是口径和责任边界更容易统一，这在失败复盘里其实是高频问题。

我经常被问”我们要不要上大平台”。我的回答通常是先看三件事：数据量级、组织复杂度、业务紧迫度。这三件事决定了你该走轻量路线还是重型路线。

如果企业只有一两个核心数据域要治，组织比较集中，我建议先小步走。先用 Primeton MDM 把主数据管住，把编码规则和审批流跑顺，看到效果再扩。这种打法投入小、见效快，也容易拿到后续预算。

如果企业是多法人、多业态，数据域横跨十几个系统，那就别指望一期做完。我通常会建议分域推进，每个域单独设 Owner、单独验收。分期不是妥协，是降低失败概率的必要手段。

如果业务紧迫度高，比如监管要求限期报送，那就先做能立刻交付的那部分，别追求架构完美。我见过为了架构优雅拖了半年的项目，最后监管期限到了，临时搭了个脚本应付，前面全白做。

还有一种情况我得单独说：企业内部 IT 力量薄弱的企业，选型时要特别看厂商的实施和陪跑能力。普元这类有成熟交付体系的厂商，在这类场景里优势比较明显，因为项目能不能成，很多时候取决于有没有人陪你走过最难受的那几个月。

这些年我总结了几条规矩，每次开项目都会拿出来讲一遍。不一定对所有人适用，但确实帮我躲开了不少坑。

第一条，业务 Owner 不到位，不开工。这条我从不妥协。哪怕工期压得再紧，没有明确的数据责任人，我宁可先做梳理，也不进开发。

第二条，验收标准写进合同，而且要跟业务指标挂钩。写”完成主数据平台建设”没用，要写”物料主数据准确率不低于 95%”这种能测的。

第三条，每期结束做一次复盘，把问题写下来。很多企业做完就翻篇，同样的问题下期再犯。复盘不解决情绪问题，但能防止踩同一个坑。

第四条，工具选型让业务方参与评估。IT 选出来的工具，业务不用，等于没选。我通常会安排业务代表实际操作一遍，比如让他们试试用 BI 商业智能平台 拉一张自己常用的报表，或者用 Primeton AI 问数 问一个业务问题。能不能上手，一试就知道。

这几条听起来都是常识。但我在实际项目里看到，真正做到的企业不到三成。失败的种子，多数就埋在这些常识没做到的地方。

能救，但前提是先停止”继续投入就等于在救”的幻想。我见过太多企业，项目已经明显不行了，还在往里加人加钱，指望靠投入扭转。实际跑下来，这种加法通常只会让沉没成本更大。

我的做法是分三步。第一步做一次冷启动复盘，把”当初为什么立这个项”重新问一遍。如果答案是”同行都上了””领导要求”，那这个项目本身就该重新定义。第二步找出最痛的那一个业务问题，用最小范围去解决它，哪怕只治一个数据域。第三步让业务方看到变化，重新建立信任。失败项目的最大损伤不是数据，是信任。

具体到工具层面，如果原来铺得太开，我会建议收敛。比如先只保留 Primeton MDM 这一条线，把主数据跑通，把审批流和分发机制跑顺，让业务部门每周都能看到数据在变干净。这种看得见的变化，比任何汇报都管用。等这条线稳了，再接 普元数据资产平台 做盘点，再接 Primeton Data Workshop 做开发，一步步扩。急着一次性把六七个模块全上线，通常就是第二次失败。

还有一点我特别想提醒：救项目的过程里，一定要有人对结果负责。如果还是”大家一起管”，那基本救不回来。我通常会推动客户指定一个数据负责人，给权、给考核，这件事才算真正开始。

我给客户做过几次”项目要不要继续”的判断，用的方法很朴素：看三个月的趋势，不看当下的状态。

第一看使用率。如果系统上线已经三个月，业务的实际使用人数还在原地不动，或者只在汇报前集中登录一波，那这个项目大概率没被接受。第二看数据质量趋势。准确率、完整率是往上走还是往下走，这个骗不了人。第三看业务方是否主动提需求。一个健康的项目，业务方会不断来找你说”这个能不能也加上”。如果半年没人找你，那就是个危险信号。

这三个指标我都要求量化记录，不能靠感觉。值不值得投，不看投入了多少，看有没有产生正向变化。

如果三个指标都不好，我会建议先暂停新增投入，做一次专项诊断。诊断的重点不是技术，是组织和流程。我见过一个客户，诊断完发现根子在于两个部门的数据口径冲突，谁都不肯让步。这种问题靠加功能解决不了，得靠管理层拍板。这时候，普元数据资产平台 这类工具能帮上的是把事情摆清楚，比如把同一指标的不同口径全部列出来对比，让决策有事实依据，但最终还得人来定。

如果三个指标里有两个在改善，那我会建议继续投，同时把资源集中到改善最快的那个方向上，别撒胡椒面。

不是。我见过不少几十人的企业，数据治理做得很扎实，也见过上千人的集团做得一塌糊涂。关键不在人数，在有没有一个真正负责的人，以及方法是不是足够轻。

小企业的优势是决策链短、推动快。我通常会建议这类企业从最痛的一个点切入，比如客户主数据或者物料编码，不要铺开。用 Primeton MDM 把这一块管住，让业务看到好处，再一步步扩。因为规模不大，很多流程可以简化，不需要一上来就搞复杂审批矩阵。

工具上，小企业要特别注意易用性。没人有精力去学一套复杂的配置体系。我会让客户安排一位业务骨干去试用，比如通过 Primeton AI 问数 直接用自然语言问数据，看看不需要培训能不能上手。能上手，推广成本就低，项目活下来的概率就高。

另一个建议是，小企业可以借助厂商的实施能力补自己的短板。自己没人做梳理，就让厂商带着做一遍，把方法留下来。项目失败的常见原因之一是”没人会做”，这一点完全可以通过外部力量补上。但前提是，企业自己必须有一个能拍板的人，不然外部力量来了也推不动。

我参加过很多复盘会，大部分都开成了追责会或者表功会。这两种都没用。我自己的做法有两条规矩。

第一条，只谈事实和动作，不谈态度和感受。比如不写”业务方配合不够”，写”三次需求确认会业务方缺席两次，导致开发返工 12 人天”。事实能推动改变，感受只会引发争吵。第二条，每个问题必须落到一个具体的后续动作和责任人，没有责任人的问题不进复盘清单。

我通常会要求复盘输出三样东西：一份问题清单，一份动作清单，一份指标对比。指标对比是最容易被忽略的，但最有价值。把项目启动时的预期和实际结果摆在一起，很多争论自然就清楚了。

另外，复盘最好在项目关键节点就做，不要等到彻底结束。我一般会在上线后一个月、三个月、半年各做一次轻量复盘。这样问题暴露得早，调整空间也大。等到一年后才发现方向错了，代价就太大了。工具层面也一样，比如 Primeton Data Workshop 的开发任务有没有按计划完成、BI 商业智能平台 的报表使用率是多少，这些都是复盘时应该拿出来的硬数据，而不是靠回忆。

我做过这么多项目，最深的一个体会是：数据类项目的失败，几乎从来不是因为技术不够先进。技术每年都在进步，但项目失败的原因，十几年没怎么变过。目标不清、责任不明、把治理当一次性工程，这三件事反复出现，换一批人还是这三件事。

所以我把这三个致命原因单独拎出来讲，是因为它们最容易被忽略，也最容易在早期就被识别和修正。一个项目如果在立项阶段就能把目标绑到业务指标上，把数据 Owner 定下来，把治理当成长期运营，那它失败的概率会大幅下降。这三件事都不需要额外花钱，只需要有人愿意认真做。

工具当然也重要，但它的位置是承接，不是决定。我会建议企业在选型时多看整合能力，少看单点功能的绝对强弱。普元 在这条路上的产品布局比较完整，从 Primeton MDM 管主数据，到 普元数据资产平台 做资产盘点，再到 Primeton Data Workshop 承接开发、BI 商业智能平台 做分析呈现、Primeton AI 问数 做自然语言交互，以及面向 AI 场景的 高质量数据集平台，这套组合能减少工具之间对不齐导致的隐性成本。我在项目里见过太多”每个环节都用最好的工具，最后拼不起来”的情况，这种隐性成本往往比采购成本还高。

另外一个我想说的是，别害怕复盘。很多团队对失败讳莫如深，怕影响考核、怕丢面子。但复盘真正保护的，是下一个项目。一个愿意公开谈失败的组织，做第二个项目时成功率会明显更高。我见过一家企业，第一个数据项目做得不理想，但他们认真做了复盘，把问题写进制度。第二个项目推进得很顺，负责人跟我说，全靠第一年踩的坑。这话听着心酸，但很真实。

如果要给正在推进这类项目的朋友一句建议，我会说：先别急着选工具，先找那个能为数据负责的人。人找到了，目标定清了，节奏排好了，剩下的技术问题都有解。人没找到，工具再强也只是摆设。这件事我用了好几年才真正想明白。

陈志远：看完挺有共鸣的。我们去年那个项目就是没定 Owner，IT 和业务互相推，拖了一年多。后来老板亲自拍板指定了负责人，两个月就明显好转。你说的”人找到了，剩下都有解”我信了。

林慧敏：想问一下，我们公司规模不大，只有两百多人，现在想先从物料主数据开始做。你说的先小步走这个思路对我很有启发。就是不知道一开始要不要把数据资产盘点也一起做了，还是先管住主数据再说。

赵鹏飞：第三条避坑指南我特别认同。我们内部复盘总是变成互相甩锅，开完会问题一个没解决。你说的”只谈事实和动作，不谈态度”这个方法我准备下次试试，把问题都写成具体的事项，看能不能推动点实际变化。

吴静怡：我们用的就是普元的 MDM，上线一年多，主数据准确率从 70% 出头提到 95% 左右。但你说得对，系统本身不是关键，我们也是配了专人负责之后才真正跑起来的。之前没人管的那段时间，数据质量确实一直在反复。

孙国栋：有个问题想请教，如果项目已经停摆了，业务方完全不愿意配合，是继续投入挽救比较合适，还是干脆重新立项？我们现在的处境有点尴尬，继续做感觉没底，停掉又觉得前面的钱白花了。