联邦政府的薪酬系统灾难 (Phoenix Pay)：一个用来发工资的新系统，为什么反而让几十万人领不到正确的工资？
把几十年的例外规则从旧系统搬到新系统，最难的是那些没人写下来的部分
联邦政府的薪酬系统灾难 (Phoenix Pay)：巅峰期加拿大联邦政府用来替换运行数十年的老旧系统的统一薪酬平台，覆盖数十万公务员的工资发放，由外部承包商负责实施；终局是上线后数十万公务员遭遇工资错误，修复成本从数亿加元膨胀到数十亿加元，政府最终决定另建新系统取代它。
加拿大联邦政府用来替换运行数十年的老旧系统的统一薪酬平台，覆盖数十万公务员的工资发放，由外部承包商负责实施
上线后数十万公务员遭遇工资错误，修复成本从数亿加元膨胀到数十亿加元，政府最终决定另建新系统取代它
5,776 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
上线后数十万公务员遭遇工资错误，修复成本从数亿加元膨胀到数十亿加元，政府最终决定另建新系统取代它。联邦政府的薪酬系统灾难 (Phoenix Pay)的结局不是某一次意外，而是上面这些判断在数年里不断叠加、又始终没有被纠正的必然结果。
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：2016 年上线后大规模工资错误集中爆发时
- •停止让有问题的系统继续承担全部发薪
- •停止依赖临时人力做长期修补
- •停止在没有并行比对的情况下推进替换
- •恢复旧系统作为并行校验基准
- •组织业务与工会共同梳理例外规则
- •按错误率验证就绪度，再逐步切换
影响数十万员工收入，处置需要与工会和政府同步。
工资发放恢复准确，替代系统在验证后分阶段接管。
Expert Post-Mortem Insights
Firsthand diagnostic analyses from entrepreneurs, VCs, alumni, and analysts.
这类项目在技术上的难点并不显眼：算工资本身不复杂，复杂的是几十年里积累的例外——某个工种的特殊津贴、某项历史追溯、某类员工的补偿算法。这些规则很多从未被写成文档，而是体现在老系统的代码和几位老员工的习惯里。新系统按明确的文档建设，于是那些「没有文档的部分」就丢了。更关键的是验证方式：上线前没有用新旧系统并行比对真实数据，错误直到发薪日才被发现，而发薪日是不容错的。之后的几年，政府只能用人力去补系统的漏洞，成本越滚越大。
在薪酬系统上，「并行验证」不是可选项，而是唯一可靠的验收方式。
Business Post-Mortem Memo · 联邦政府的薪酬系统灾难 (Phoenix Pay)
一个用来发工资的新系统，为什么反而让几十万人领不到正确的工资？
# Business Post-Mortem Memo：联邦政府的薪酬系统灾难 (Phoenix Pay) > 一个用来发工资的新系统，为什么反而让几十万人领不到正确的工资？ > Period: 2011 - 2024 | Industry: Enterprise SaaS > Peak: 加拿大联邦政府用来替换运行数十年的老旧系统的统一薪酬平台，覆盖数十万公务员的工资发放，由外部承包商负责实施 > Final: 上线后数十万公务员遭遇工资错误，修复成本从数亿加元膨胀到数十亿加元，政府最终决定另建新系统取代它 ## Overview 把几十年的例外规则从旧系统搬到新系统，最难的是那些没人写下来的部分。巅峰期加拿大联邦政府用来替换运行数十年的老旧系统的统一薪酬平台，覆盖数十万公务员的工资发放，由外部承包商负责实施；终局是上线后数十万公务员遭遇工资错误，修复成本从数亿加元膨胀到数十亿加元，政府最终决定另建新系统取代它。 ## Top-voted root causes 1. [Product & Tech] 旧系统的隐性规则未被完整迁移 (1,900 votes) 2. [Org & Culture] 为满足周期压缩测试 (1,596 votes) 3. [Capital & Finance] 救火模式消耗资源 (1,292 votes) ## Actionable lessons ### 替换运行了几十年的系统，先要把「没人写下来的规则」挖出来 > 用并行运行的结果比对，作为切换的硬性前提。 - ✅ DOs: - 把隐性规则显性化并逐条验证 - 在新旧系统并行运行期间比对每一笔结果 - ❌ DON'Ts: - 不要为满足上线节点压缩规则验证 - 不要把手工修补当作长期解决方案 ## Revival plans ### 先补齐隐性规则、并行验证，再切换发薪主流程 — 良略编辑部 Intervention: 2016 年上线后大规模工资错误集中爆发时 - Must cut: - 停止让有问题的系统继续承担全部发薪 - 停止依赖临时人力做长期修补 - 停止在没有并行比对的情况下推进替换 - Breakthrough moves: - 恢复旧系统作为并行校验基准 - 组织业务与工会共同梳理例外规则 - 按错误率验证就绪度，再逐步切换 - Expected outcome: 工资发放恢复准确，替代系统在验证后分阶段接管。 ## Community insights ### 老系统的可怕之处不在于它老，而在于它的规则有相当一部分只存在于经手人的记忆里。 — 良略编辑部 (前从业者) 这类项目在技术上的难点并不显眼：算工资本身不复杂，复杂的是几十年里积累的例外——某个工种的特殊津贴、某项历史追溯、某类员工的补偿算法。这些规则很多从未被写成文档，而是体现在老系统的代码和几位老员工的习惯里。新系统按明确的文档建设，于是那些「没有文档的部分」就丢了。更关键的是验证方式：上线前没有用新旧系统并行比对真实数据，错误直到发薪日才被发现，而发薪日是不容错的。之后的几年，政府只能用人力去补系统的漏洞，成本越滚越大。 - Alternative Move if Replayed 在薪酬系统上，「并行验证」不是可选项，而是唯一可靠的验收方式。 --- Source: 良略 · https://www.lianglue.com/c/phoenix-pay