福利系统的失控预算 (UK Universal Credit):一个号称要「简化福利」的系统,为什么把预算简化成了原来的好几倍?
把制度重构和系统建设放进同一个项目,就等于把最难的变量绑在一起
福利系统的失控预算 (UK Universal Credit):把制度重构和系统建设放进同一个项目,就等于把最难变的变量绑在一起
英国政府推动的福利制度改革项目,目标是把多种福利合并为单一按月发放的补贴,并用统一数字系统替代数十年的旧流程,被视为公共部门最大的数字化计划之一
预算从最初的十亿英镑级膨胀到上百亿英镑级,系统在 2013 年被整体重置,上线时间多次推迟,数年后才完成推广
2,788 票が参加
1 プラン · 1 知見
投稿会先进入待审,通过后才进入公开目录和站点地图。
根本的敗因の国民的公投
企業の命運を決定づけた致命的死穴に投票してください。
政策需求与系统开发并行推进
规则不断变动,开发成果反复作废,成本被动累积
需求未稳定即开始大规模建设
供应商按早期方案投入,后续改造消耗巨大
项目治理未能及时纠偏
问题在内部被反复上报但长期未形成有效调整,直到试点失败才重置
预算估算与实际支出相差数倍
财政资源被大量占用,公众对数字政务的投入产出产生质疑
年表:絶頂から終局へ
项目启动与设计
项目立项,计划用统一数字系统承载合并后的福利发放,并对政策与流程做大范围重构
试点受阻与项目重置
早期试点暴露大量问题,项目被宣布重置,交付计划与供应商安排重新调整
分阶段推进与推迟
改为小步试点、逐步扩展的方式推进,上线时间多次推迟,成本持续上升
逐步完成推广
系统在缩减目标后分阶段铺开,但总支出已达初期估算的数倍,争议长期存在
4大視点からの徹底回顧分析
発展の軌跡と最盛期の礎
项目的目标同时包含政策改革与系统建设:既要重新设计补贴规则与发放方式,又要在短时间内建成覆盖全国的数字平台;需求由政策层面持续调整,供应商在需求尚未稳定时就开始了大规模开发,测试与上线计划随之反复变动巅峰期的成绩单是:英国政府推动的福利制度改革项目,目标是把多种福利合并为单一按月发放的补贴,并用统一数字系统替代数十年的旧流程,被视为公共部门最大的数字化计划之一。此时的它拥有渠道、品牌与资本的合力,看起来没有任何理由会输。
致命的転換点における戦略ミス
政策细节在开发过程中不断变化,系统需要反复改造,成本随之快速上升;项目在推进数年后被整体重置,上线时间多次推迟,最终以分阶段、小步推进的方式替代原计划;到完成推广时,实际支出已达到最初估算的数倍,公众与议会对其效率持续质疑早期为了速度堆起来的技术债没有及时偿还,等到业务规模翻倍,系统已经无法支撑新场景,重构又意味着停掉增长,只能一路将就。
内部組織カルチャーと過信
工程团队疲于救火与打补丁,优秀工程师流失,剩下的人只能用更低效的方式维持系统运转,形成恶性循环。
破綻の連鎖と終焉
预算从最初的十亿英镑级膨胀到上百亿英镑级,系统在 2013 年被整体重置,上线时间多次推迟,数年后才完成推广。福利系统的失控预算 (UK Universal Credit)的结局不是某一次意外,而是上面这些判断在数年里不断叠加、又始终没有被纠正的必然结果。
ビジネスの実践的生存ルール
高額な失敗の代償から導き出された実践的教訓(DO & DON'T)
政策与系统必须解耦:先定规则,再写代码
把需求冻结作为开发启动的前置条件,而不是并行推进。
- •在需求冻结后再启动大规模开发
- •用可验证的小范围试点暴露问题
- •不要在同一项目里同时改制度和造系统
- •不要让预算基于乐观的政策时间表
再生シミュレーター:もしあなたが当時のCEOなら、決定的な転換点でどう立て直すか?
歴史は変えられませんが、戦略思考は磨けます。過酷な事業整理と新たな勝負手を提示し、起業家や投資家による実現可能性投票で検証します。
先冻结规则、再做可验证的小范围试点
介入すべき時点:2013 年试点暴露大量问题、项目被迫重置时
- •停止在政策未定稿时继续大规模开发
- •停止按原计划的全国时间表推进
- •停止用「按期交付」掩盖需求不稳定
- •把关键规则冻结并做成可复用的模块
- •用少数地区的小范围试点验证流程
- •按验证结果分批扩展并与公众沟通进度
涉及公共财政与民众权益,调整需与政策部门同步。
系统在稳定的规则基础上分批上线,成本增长得到控制。
専門家による徹底見解
起業家、投資家、元社員、アナリストによる現場の分析
从工程角度看,这个项目的需求一直在动:补贴怎么算、什么时候发、谁有资格、遇到特殊情况怎么处理——每一条都可能因为政策讨论而调整。而系统一旦开始开发,任何规则变动都意味着返工,返工的代价在大型系统里是按倍数计的。更麻烦的是,负责推进的机构同时承担政策与交付两件事,内部很难对「先冻结规则」形成共识,于是只能边改边做。几年下来,投入的时间和资金远远超过了原来的估算,最终不得不改成小步慢走的方式。
需求变更不是风险,需求持续变更才是。
失敗分析メモの書き出し · 福利系统的失控预算 (UK Universal Credit)
一个号称要「简化福利」的系统,为什么把预算简化成了原来的好几倍?
# ビジネス失敗の回顧メモ:福利系统的失控预算 (UK Universal Credit) > 一个号称要「简化福利」的系统,为什么把预算简化成了原来的好几倍? > 期間: 2010 - 2018 | 業界: 法人向けSaaS > ピーク: 英国政府推动的福利制度改革项目,目标是把多种福利合并为单一按月发放的补贴,并用统一数字系统替代数十年的旧流程,被视为公共部门最大的数字化计划之一 > 終局: 预算从最初的十亿英镑级膨胀到上百亿英镑级,系统在 2013 年被整体重置,上线时间多次推迟,数年后才完成推广 ## 概要 把制度重构和系统建设放进同一个项目,就等于把最难变的变量绑在一起 ## コミュニティ投票の主要死因 1. [戦略意思決定] 政策需求与系统开发并行推进 (917 票) 2. [プロダクト技術] 需求未稳定即开始大规模建设 (770 票) 3. [組織マネジメント] 项目治理未能及时纠偏 (624 票) ## 実行可能な教訓 ### 政策与系统必须解耦:先定规则,再写代码 > 把需求冻结作为开发启动的前置条件,而不是并行推进。 - ✅ 推奨 (DOs): - 在需求冻结后再启动大规模开发 - 用可验证的小范围试点暴露问题 - ❌ 禁止 (DON'Ts): - 不要在同一项目里同时改制度和造系统 - 不要让预算基于乐观的政策时间表 ## 再生プラン ### 先冻结规则、再做可验证的小范围试点 — 良略编辑部 介入時点: 2013 年试点暴露大量问题、项目被迫重置时 - 断つべきもの: - 停止在政策未定稿时继续大规模开发 - 停止按原计划的全国时间表推进 - 停止用「按期交付」掩盖需求不稳定 - 打開策: - 把关键规则冻结并做成可复用的模块 - 用少数地区的小范围试点验证流程 - 按验证结果分批扩展并与公众沟通进度 - 期待される成果: 系统在稳定的规则基础上分批上线,成本增长得到控制。 ## コミュニティの知見 ### 这类项目最难的部分从来不是技术,而是「规则什么时候不再变」。 — 良略编辑部 (工程师) 从工程角度看,这个项目的需求一直在动:补贴怎么算、什么时候发、谁有资格、遇到特殊情况怎么处理——每一条都可能因为政策讨论而调整。而系统一旦开始开发,任何规则变动都意味着返工,返工的代价在大型系统里是按倍数计的。更麻烦的是,负责推进的机构同时承担政策与交付两件事,内部很难对「先冻结规则」形成共识,于是只能边改边做。几年下来,投入的时间和资金远远超过了原来的估算,最终不得不改成小步慢走的方式。 - やり直せるなら打つべき一手 需求变更不是风险,需求持续变更才是。 --- 出典: 良略 · https://www.lianglue.com/c/dwp-universal-credit