联邦政府的薪酬系统灾难 (Phoenix Pay)：一个用来发工资的新系统，为什么反而让几十万人领不到正确的工资？

# 商业复盘备忘录：联邦政府的薪酬系统灾难 (Phoenix Pay)

> 一个用来发工资的新系统，为什么反而让几十万人领不到正确的工资？
> 周期: 2011 - 2024 | 行业: 企服与SaaS
> 巅峰: 加拿大联邦政府用来替换运行数十年的老旧系统的统一薪酬平台，覆盖数十万公务员的工资发放，由外部承包商负责实施
> 终局: 上线后数十万公务员遭遇工资错误，修复成本从数亿加元膨胀到数十亿加元，政府最终决定另建新系统取代它

## 核心概览
把几十年的例外规则从旧系统搬到新系统，最难的是那些没人写下来的部分。巅峰期加拿大联邦政府用来替换运行数十年的老旧系统的统一薪酬平台，覆盖数十万公务员的工资发放，由外部承包商负责实施；终局是上线后数十万公务员遭遇工资错误，修复成本从数亿加元膨胀到数十亿加元，政府最终决定另建新系统取代它。

## 社区公投头号死因
1. [产品技术] 旧系统的隐性规则未被完整迁移 (1,900 票)
2. [组织管理] 为满足周期压缩测试 (1,596 票)
3. [资本财务] 救火模式消耗资源 (1,292 票)

## 可执行教训
### 替换运行了几十年的系统，先要把「没人写下来的规则」挖出来
> 用并行运行的结果比对，作为切换的硬性前提。

- ✅ 推荐做 (DOs):
  - 把隐性规则显性化并逐条验证
  - 在新旧系统并行运行期间比对每一笔结果
- ❌ 绝不能做 (DON'Ts):
  - 不要为满足上线节点压缩规则验证
  - 不要把手工修补当作长期解决方案

## 救亡方案
### 先补齐隐性规则、并行验证，再切换发薪主流程 — 良略编辑部
干预时点: 2016 年上线后大规模工资错误集中爆发时
- 必须断腕:
  - 停止让有问题的系统继续承担全部发薪
  - 停止依赖临时人力做长期修补
  - 停止在没有并行比对的情况下推进替换
- 破局动作:
  - 恢复旧系统作为并行校验基准
  - 组织业务与工会共同梳理例外规则
  - 按错误率验证就绪度，再逐步切换
- 预期结果: 工资发放恢复准确，替代系统在验证后分阶段接管。

## 社区见解
### 老系统的可怕之处不在于它老，而在于它的规则有相当一部分只存在于经手人的记忆里。 — 良略编辑部 (前从业者)
这类项目在技术上的难点并不显眼：算工资本身不复杂，复杂的是几十年里积累的例外——某个工种的特殊津贴、某项历史追溯、某类员工的补偿算法。这些规则很多从未被写成文档，而是体现在老系统的代码和几位老员工的习惯里。新系统按明确的文档建设，于是那些「没有文档的部分」就丢了。更关键的是验证方式：上线前没有用新旧系统并行比对真实数据，错误直到发薪日才被发现，而发薪日是不容错的。之后的几年，政府只能用人力去补系统的漏洞，成本越滚越大。
- 如果重来一次的纠偏招式 在薪酬系统上，「并行验证」不是可选项，而是唯一可靠的验收方式。

---
来源: 良略 · https://www.lianglue.com/c/phoenix-pay