福利系统的失控预算 (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