福利系统的失控预算 (UK Universal Credit)：一个号称要「简化福利」的系统，为什么把预算简化成了原来的好几倍？
把制度重构和系统建设放进同一个项目，就等于把最难的变量绑在一起
福利系统的失控预算 (UK Universal Credit)：把制度重构和系统建设放进同一个项目，就等于把最难变的变量绑在一起
英国政府推动的福利制度改革项目，目标是把多种福利合并为单一按月发放的补贴，并用统一数字系统替代数十年的旧流程，被视为公共部门最大的数字化计划之一
预算从最初的十亿英镑级膨胀到上百亿英镑级，系统在 2013 年被整体重置，上线时间多次推迟，数年后才完成推广
2,788 votes cast
1 plans · 1 insights
投稿会先进入待审，通过后才进入公开目录和站点地图。
Root Causes Consensus Poll
Vote for the primary fatal error that caused this enterprise to collapse.
政策需求与系统开发并行推进
规则不断变动，开发成果反复作废，成本被动累积
需求未稳定即开始大规模建设
供应商按早期方案投入，后续改造消耗巨大
项目治理未能及时纠偏
问题在内部被反复上报但长期未形成有效调整，直到试点失败才重置
预算估算与实际支出相差数倍
财政资源被大量占用，公众对数字政务的投入产出产生质疑
Timeline: peak to collapse
项目启动与设计
项目立项，计划用统一数字系统承载合并后的福利发放，并对政策与流程做大范围重构
试点受阻与项目重置
早期试点暴露大量问题，项目被宣布重置，交付计划与供应商安排重新调整
分阶段推进与推迟
改为小步试点、逐步扩展的方式推进，上线时间多次推迟，成本持续上升
逐步完成推广
系统在缩减目标后分阶段铺开，但总支出已达初期估算的数倍，争议长期存在
Four-Dimensional Retrospective Breakdown
Background & Golden Era
项目的目标同时包含政策改革与系统建设：既要重新设计补贴规则与发放方式，又要在短时间内建成覆盖全国的数字平台；需求由政策层面持续调整，供应商在需求尚未稳定时就开始了大规模开发，测试与上线计划随之反复变动巅峰期的成绩单是：英国政府推动的福利制度改革项目，目标是把多种福利合并为单一按月发放的补贴，并用统一数字系统替代数十年的旧流程，被视为公共部门最大的数字化计划之一。此时的它拥有渠道、品牌与资本的合力，看起来没有任何理由会输。
Fatal Turning Point Miscalculation
政策细节在开发过程中不断变化，系统需要反复改造，成本随之快速上升；项目在推进数年后被整体重置，上线时间多次推迟，最终以分阶段、小步推进的方式替代原计划；到完成推广时，实际支出已达到最初估算的数倍，公众与议会对其效率持续质疑早期为了速度堆起来的技术债没有及时偿还，等到业务规模翻倍，系统已经无法支撑新场景，重构又意味着停掉增长，只能一路将就。
Internal Culture & Bureaucratic Hubris
工程团队疲于救火与打补丁，优秀工程师流失，剩下的人只能用更低效的方式维持系统运转，形成恶性循环。
The Collapse & Aftermath
预算从最初的十亿英镑级膨胀到上百亿英镑级，系统在 2013 年被整体重置，上线时间多次推迟，数年后才完成推广。福利系统的失控预算 (UK Universal Credit)的结局不是某一次意外，而是上面这些判断在数年里不断叠加、又始终没有被纠正的必然结果。
Battle-Tested Actionable Survival Rules
Distilled practical DOs and DONTs forged from costly corporate catastrophes.
政策与系统必须解耦：先定规则，再写代码
把需求冻结作为开发启动的前置条件，而不是并行推进。
- •在需求冻结后再启动大规模开发
- •用可验证的小范围试点暴露问题
- •不要在同一项目里同时改制度和造系统
- •不要让预算基于乐观的政策时间表
Revival Simulation: If you were the CEO at the inflection point, how would you save it?
History cannot be rewritten, but executive decision-making can be honed. Propose decisive divestitures and strategic bets, and let entrepreneurs & VCs vote on feasibility.
先冻结规则、再做可验证的小范围试点
Critical intervention point：2013 年试点暴露大量问题、项目被迫重置时
- •停止在政策未定稿时继续大规模开发
- •停止按原计划的全国时间表推进
- •停止用「按期交付」掩盖需求不稳定
- •把关键规则冻结并做成可复用的模块
- •用少数地区的小范围试点验证流程
- •按验证结果分批扩展并与公众沟通进度
涉及公共财政与民众权益，调整需与政策部门同步。
系统在稳定的规则基础上分批上线，成本增长得到控制。
Expert Post-Mortem Insights
Firsthand diagnostic analyses from entrepreneurs, VCs, alumni, and analysts.
从工程角度看，这个项目的需求一直在动：补贴怎么算、什么时候发、谁有资格、遇到特殊情况怎么处理——每一条都可能因为政策讨论而调整。而系统一旦开始开发，任何规则变动都意味着返工，返工的代价在大型系统里是按倍数计的。更麻烦的是，负责推进的机构同时承担政策与交付两件事，内部很难对「先冻结规则」形成共识，于是只能边改边做。几年下来，投入的时间和资金远远超过了原来的估算，最终不得不改成小步慢走的方式。
需求变更不是风险，需求持续变更才是。
Business Post-Mortem Memo · 福利系统的失控预算 (UK Universal Credit)
一个号称要「简化福利」的系统，为什么把预算简化成了原来的好几倍？
# Business Post-Mortem Memo：福利系统的失控预算 (UK Universal Credit) > 一个号称要「简化福利」的系统，为什么把预算简化成了原来的好几倍？ > Period: 2010 - 2018 | Industry: Enterprise SaaS > Peak: 英国政府推动的福利制度改革项目，目标是把多种福利合并为单一按月发放的补贴，并用统一数字系统替代数十年的旧流程，被视为公共部门最大的数字化计划之一 > Final: 预算从最初的十亿英镑级膨胀到上百亿英镑级，系统在 2013 年被整体重置，上线时间多次推迟，数年后才完成推广 ## Overview 把制度重构和系统建设放进同一个项目，就等于把最难变的变量绑在一起 ## Top-voted root causes 1. [Strategy] 政策需求与系统开发并行推进 (917 votes) 2. [Product & Tech] 需求未稳定即开始大规模建设 (770 votes) 3. [Org & Culture] 项目治理未能及时纠偏 (624 votes) ## Actionable lessons ### 政策与系统必须解耦：先定规则，再写代码 > 把需求冻结作为开发启动的前置条件，而不是并行推进。 - ✅ DOs: - 在需求冻结后再启动大规模开发 - 用可验证的小范围试点暴露问题 - ❌ DON'Ts: - 不要在同一项目里同时改制度和造系统 - 不要让预算基于乐观的政策时间表 ## Revival plans ### 先冻结规则、再做可验证的小范围试点 — 良略编辑部 Intervention: 2013 年试点暴露大量问题、项目被迫重置时 - Must cut: - 停止在政策未定稿时继续大规模开发 - 停止按原计划的全国时间表推进 - 停止用「按期交付」掩盖需求不稳定 - Breakthrough moves: - 把关键规则冻结并做成可复用的模块 - 用少数地区的小范围试点验证流程 - 按验证结果分批扩展并与公众沟通进度 - Expected outcome: 系统在稳定的规则基础上分批上线，成本增长得到控制。 ## Community insights ### 这类项目最难的部分从来不是技术，而是「规则什么时候不再变」。 — 良略编辑部 (工程师) 从工程角度看，这个项目的需求一直在动：补贴怎么算、什么时候发、谁有资格、遇到特殊情况怎么处理——每一条都可能因为政策讨论而调整。而系统一旦开始开发，任何规则变动都意味着返工，返工的代价在大型系统里是按倍数计的。更麻烦的是，负责推进的机构同时承担政策与交付两件事，内部很难对「先冻结规则」形成共识，于是只能边改边做。几年下来，投入的时间和资金远远超过了原来的估算，最终不得不改成小步慢走的方式。 - Alternative Move if Replayed 需求变更不是风险，需求持续变更才是。 --- Source: 良略 · https://www.lianglue.com/c/dwp-universal-credit