有一种现象，在一些大型组织里并不陌生。

某位领导在任的时候，大手一挥：

“上系统！”

于是立项、招标、采购、建设、验收。

几百万，甚至几千万花出去。

汇报材料很好看：

“完成数字化转型。”

“实现业务流程再造。”

“建成一体化平台。”

“填补某领域空白。”

项目验收了，新闻稿发了，成果写进年度总结了，领导履历上也多了一项漂亮的“数字化建设成果”。

厂商拿到了合同款。

领导可能升职、调任，或者去了新的岗位。

但两三年以后呢？

真正使用系统的人开始发现：

不好用。

流程复杂。

数据不准。

系统之间互不相通。

接口改不动。

代码没人敢碰。

原厂维护费越来越高。

基层员工一边在系统里填一遍，一边还得用Excel再做一遍。

更糟糕的是，有些系统当初为了赶进度留下大量技术债，后来的技术人员只能天天“打补丁”。

这时候，新领导来了。

看了一圈：

“这是谁建的？”

大家告诉他：

“上一任领导时期建设的。”

然后往往出现一句非常有意思的话：

“以前的事情就不要再说了，现在研究怎么解决。”

听起来很成熟。

也很顾全大局。

但仔细想想：

如果所有历史决策造成的问题，最后都只能由后来的人负责解决，那么做决策的人，究竟为什么要对决策质量负责？

一、最可怕的不是项目失败，而是“成功属于个人，失败属于组织”

这可能才是问题的核心。

项目建设成功的时候：

是领导“高瞻远瞩”。

是领导“亲自部署”。

是领导“推动数字化转型”。

是领导“完成重大项目建设”。

这些都可以成为任期成绩。

可是三年以后系统不好用了呢？

往往变成：

“历史遗留问题。”

“当时条件有限。”

“需求发生了变化。”

“技术迭代太快。”

“厂商服务不到位。”

“现在讨论责任没有意义。”

你会发现一种非常奇怪的不对称：

成绩可以追溯到个人，责任却不能追溯到个人。

项目成功了，可以写进履历；

项目失败了，却留给组织消化。

如果一种管理机制长期允许这种情况存在，就很容易产生一个危险的激励：

做一个五年以后仍然好用的系统，不一定比做一个明年就能验收的系统更有价值。

因为前者考验长期治理能力，后者却更容易快速形成“成果”。

于是，真正重要的问题就来了：

一个人的任期只有几年，他为什么天然会替十年后的组织负责？

不能只靠觉悟。

制度必须解决这个问题。

二、为什么有些项目特别容易变成“前人栽雷，后人排雷”？

因为项目的生命周期和领导任期，往往根本不是一个时间尺度。

一个领导可能在一个岗位工作三五年。

但一套核心信息系统可能要使用十年。

一个数据平台可能影响未来很多年的数据治理。

一次网络架构设计可能决定后面无数系统怎么接入。

一个厂商的技术路线选择，甚至可能造成长期锁定。

问题就在这里：

决策者已经离开了，决策的后果却刚刚开始显现。

很多问题在验收的时候根本看不出来。

系统能登录吗？

能。

功能能演示吗？

能。

报表能出来吗？

能。

验收文档齐全吗？

齐全。

那就验收。

可真正决定一个系统是不是好系统的问题，往往需要几年以后才能知道：

5000个人同时使用卡不卡？

组织架构变化以后改不改得动？

厂商撤场以后自己能不能维护？

数据库升级怎么办？

接口标准不标准？

历史数据能不能迁移？

国产化替代以后还能不能继续使用？

业务部门愿不愿意天天用？

运维成本到底是多少？

安全漏洞能不能持续修复？

这些东西，恰恰很难在项目验收当天暴露。

所以很多项目出现了一种荒诞现象：

建设期人人鼓掌，运维期人人骂娘。

三、为什么新领导来了以后，通常不愿意追究前面的决策？

这里其实有很现实的原因。

第一，决策通常不是一个人完成的。

重大项目往往经过需求、论证、预算、采购、招标、合同、建设、测试、验收等多个环节。

最后签字的人很多。

于是出了问题以后，很容易出现：

“这是集体决策。”

“专家论证通过了。”

“采购程序合法合规。”

“验收组签字了。”

每个人似乎只负责其中一小块。

最后就出现一个管理学上的经典问题：

人人参与，最后却可能人人都不承担完整责任。

第二，失败很难定义。

系统现在不好用，到底是谁的问题？

是当初需求设计错了？

预算太低？

厂商能力不行？

采购规则导致只能选这个方案？

业务后来发生变化？

技术路线被淘汰？

还是后来的维护团队能力不足？

这些因素往往混杂在一起。

所以，追责不能变成简单的：

“项目现在不好用，所以当年的领导一定有问题。”

这同样不公平。

真正应该追究的，不是“结果不好”本身，而是：

当时有没有尽到与权力相匹配的决策责任。

这是非常重要的区别。

四、不是所有失败都应该追责，但有些失败必须能够倒查

技术项目当然允许失败。

如果一个组织要求：

“只要项目最后效果不好，当年的决策者一律处分。”

那最后一定会导致另一个极端：

没人敢创新。

没人敢试新技术。

没人敢拍板。

所有人都选择最保守的方案。

所以我们真正需要建立的，不是简单粗暴的“终身追责”，而是：

重大决策可追溯制度。

什么叫可追溯？

当初为什么要建设？

是谁提出需求？

谁做的可行性论证？

为什么选择这条技术路线？

为什么选择自研而不是采购？

为什么选择集中式而不是分布式？

为什么预算这么定？

有没有充分调研一线用户？

有没有做试点？

有没有考虑后续维护？

有没有考虑厂商退出机制？

源代码、接口、数据库、技术文档有没有约束？

有没有评估未来五年的总拥有成本？

当初专家提出过哪些风险？

领导最终为什么仍然决定推进？

这些东西都应该留下记录。

几年以后项目出现重大问题，再回头看。

如果当时的信息条件下，这个决策是合理的，只是后来技术环境发生巨大变化——

不应该追责。

如果经过充分论证、规范程序，项目仍然因为不可预见因素失败——

也不应该简单追责。

但是，如果当时已经有人明确提出严重风险，却被人为压下去了；

如果明知道需求没有搞清楚，为了赶年度节点仍然强行立项；

如果明知道系统无法维护，却为了尽快验收选择短期方案；

如果专家意见只是走形式；

如果基层用户明确反对，却没人真正调研；

如果厂商方案明显存在长期绑定，却没有退出机制；

如果为了形成“任期成果”，把三年的建设周期压缩成一年；

甚至存在利益输送、违规干预采购、弄虚作假——

那么几年以后问题集中爆发时，

为什么不能倒查？

这才是“决策留痕”的真正意义。

不是为了秋后算账。

而是让每一个拥有重大决策权的人知道：

你今天签下的字，不会因为明天调走就自动失效。

五、最需要改变的，其实是“验收即成功”的逻辑

很多项目最大的问题，就是把“项目验收”当成了“项目成功”。

这是完全不同的两件事。

验收证明的是：

供应商完成了合同约定的交付。

但真正的项目成功应该看：

这个东西到底有没有给组织创造长期价值。

一套系统花了2000万元。

第一年验收通过。

第二年使用率下降。

第三年基层重新用Excel。

第四年因为无法升级又重新立项。

第五年花3000万元建设“新一代平台”。

然后旧系统废弃。

如果只看第一年的验收材料：

这是一个成功项目。

如果看五年的全生命周期：

这可能是一场昂贵的失败。

所以重大信息化项目真正需要的不是一次验收，而应该至少有：

建设验收 + 运行评价 + 后评价。

比如：

上线一年以后评价一次。

三年以后再评价一次。

评价什么？

系统实际使用率。

用户满意度。

故障率。

业务效率到底提升多少。

有没有实现当初承诺的目标。

运维成本是否超过预算。

是否高度依赖原厂。

有没有重复建设。

有没有形成新的数据孤岛。

基层有没有大量使用Excel、微信群、线下表格绕过系统。

这些才是真正的答案。

六、尤其应该建立一个指标：项目“实际寿命”

这是我认为很多单位特别值得统计的数据。

不要只统计：

今年上线了多少系统。

今年完成了多少项目。

今年投资了多少钱。

还应该统计：

过去十年建设的系统，现在还有多少在正常使用？

假设一个单位十年投资了5亿元建设信息化系统。

结果：

20%的系统已经废弃；

30%的系统几乎没人使用；

20%的系统需要重新建设；

只有30%的系统真正长期运行。

那这个单位真正应该反思的，绝不仅仅是技术人员能力。

而是：

决策机制可能出了问题。

甚至可以建立一个非常扎心的指标：

“重大信息化项目五年存活率”

哪个部门建的系统五年以后还在稳定使用？

哪个领导任期内推动的项目五年以后仍然创造价值？

哪个厂商交付的系统五年以后维护成本仍然合理？

全部统计。

这时候，真正优秀的项目才会浮现出来。

七、厂商也不应该“验收完，责任清零”

还有一个经常被忽略的问题：

供应商。

有些项目建设的时候，厂商PPT做得极其漂亮。

“平台化。”

“智能化。”

“中台化。”

“一体化。”

“全生命周期。”

“自主可控。”

“统一门户。”

“数据赋能。”

什么词热就写什么。

但项目验收以后：

原来的售前走了。

项目经理走了。

核心开发走了。

最后只剩一个运维工程师面对一套没人敢改的系统。

然后告诉甲方：

“这个属于新增需求，需要另外付费。”

于是出现一个非常讽刺的局面：

领导完成了项目。

厂商完成了合同。

验收专家完成了签字。

财务完成了付款。

只有真正使用系统的人，没有完成工作。

因为系统不好用。

这说明评价供应商也不能只看：

“有没有按期验收。”

还应该看历史项目。

这个厂商五年前建设的系统现在怎么样？

用户还在用吗？

维护贵不贵？

升级容易吗？

有没有厂商锁定？

历史项目出现严重问题没有？

如果一个厂商不断：

投标—建设—验收—收款—撤场—留下技术债，

下一次竟然还能凭一份漂亮PPT继续中标，

那采购评价机制本身就值得反思。

八、真正合理的机制应该是：权力可以离任，责任链不能离任

这不是说：

领导退休十年以后，一个服务器坏了都要找他。

那当然荒唐。

真正应该追溯的是：

重大决策责任。

可以建立一套非常清晰的机制：

第一，重大项目建立“决策责任档案”

把关键决策、论证意见、风险提示、最终决定全部留档。

不是只保存最终会议纪要。

尤其要保存：

反对意见。

因为几年以后，反对意见可能比赞成意见更有价值。

第二，建立项目后评价

项目上线1年、3年、5年以后重新评价。

不要让建设部门自己评价自己。

真正使用系统的一线部门必须有足够权重。

第三，把长期效果纳入干部评价

不要只写：

“任期内建成XX平台。”

还应该看：

“离任三年以后，这个平台怎么样了？”

真正优秀的管理者，不应该只留下剪彩照片。

而应该留下：

几年以后仍然好用的东西。

第四，建立厂商历史履约档案

不是只看本次投标材料。

而要看：

这个厂商过去五年做过什么。

系统现在活没活着。

维护怎么样。

有没有大量投诉。

有没有严重延期。

有没有厂商锁定。

有没有反复追加预算。

第五，重大项目必须设计退出机制

任何核心系统立项的时候，都应该问一句：

“如果三年以后这个厂商倒闭了怎么办？”

数据能不能导出来？

接口是不是开放？

文档是否完整？

源代码如何管理？

数据库结构是否掌握？

能不能由第三方接手？

如果这些问题回答不了，

那所谓“自主可控”，很可能只是换了一种被绑定。

九、为什么一定要允许“回头看”？

因为如果永远不允许回头看，

组织就无法学习。

很多人一听“追溯历史决策”，第一反应就是：

“不要翻旧账。”

但问题是：

如果旧账永远不能翻，

同样的错误怎么避免再发生？

一个系统失败了。

大家花3000万元重新建设。

五年以后又失败。

然后再花5000万元重建。

每一次都说：

“历史问题不讨论，我们向前看。”

听起来特别积极。

实际上可能意味着：

组织花了十年时间，却一次经验都没有积累下来。

真正成熟的组织不是“不翻旧账”。

而是：

翻旧账，但不搞运动式追责；复盘决策，但区分正常风险与失职违规；允许创新失败，但不允许不负责任。

这才是现代治理真正需要的能力。

十、一个非常简单的问题，就能检验很多项目

以后再有人提出建设一个几千万的平台，

不妨先问决策者一句：

“如果五年以后还要对这个项目做一次评价，你今天还会不会签字？”

如果答案依然是：

“会。”

那说明他可能真的相信这个项目长期有价值。

如果一想到：

五年以后还要看使用率；

五年以后还要看维护成本；

五年以后还要看用户满意度；

五年以后还要看系统有没有废弃；

五年以后还要重新检查当年的决策依据；

很多原本非常着急的项目，

可能突然就不那么着急了。

很多所谓的“创新项目”，

可能突然就需要重新论证了。

很多原本几十页的漂亮PPT，

可能也需要增加几页真正重要的内容：

五年以后怎么办？

写在最后

一个好的制度，不应该让后来的人永远替前面的人擦屁股。

但一个好的制度，也不能因为后来效果不好，就简单粗暴地处罚当年的决策者。

真正需要建立的是一种更成熟的责任观：

权力有任期，责任有边界，但决策必须可追溯。

我们当然不能要求任何领导预测十年后的技术变化。

但完全可以要求：

在掌握当时信息的情况下，

有没有认真调研？

有没有听取不同意见？

有没有充分论证？

有没有考虑长期运维？

有没有评估真实需求？

有没有防范厂商锁定？

有没有为了短期政绩牺牲长期利益？

有没有履行一个重大决策者应尽的责任？

如果这些都做了，

即使项目最终失败，也应该允许失败。

但如果这些都没做，

只是因为：

“领导已经调走了。”

就从此没人再问，

那才是最大的问题。

因为一个组织最危险的，从来不是做错一次决定。

而是：

做错了决定，却不知道为什么错；
花掉了几千万，却没人总结为什么花错；
换了一批领导，又按照同样的方式重新来一次。

钱是组织的钱。

系统是员工每天要用的系统。

技术债是后来的人要背的技术债。

时间成本是无数普通员工每天一点一点付出的成本。

所以真正值得建立的文化，不应该是：

“人走了，责任也走了。”

而应该是：

“可以换领导，但不能换掉历史；可以向前看，但必须知道过去为什么走错。”

更重要的是：

成绩既然可以写进履历，责任就应该能够进入档案。

只有当决策者知道——

今天做出的重大决定，

三年以后、五年以后，

依然有人会认真评价它，

一个组织才可能真正从

“对验收负责”

走向

“对结果负责”。