概況
Phoenix はソフトウェアの置き換えからサービス集中化へと移行したため、準備態勢は人事から給与までのシステム全体をカバーする必要があった。このイニシアティブは、数十年にわたる給与エンジンを置き換えると同時に、部門から新しい給与センターへの報酬業務の移行を伴った。Auditor General の2018年実施報告書は、重要な機能が削除され、テストが制限され、準備態勢の警告が軽視され、システムが2016年2月と4月の2段階で展開されたことを明らかにしている。計算エンジンは技術的に稼働可能に見えるかもしれないが、部門、データ、手順、サービス能力は未準備のままであった。
IBM の役割は、契約と承認された業務を通じて説明されるべきであり、一方的なベンダーの道徳物語によってではない。同社は、PeopleSoft ベースのシステムの設計、カスタマイズ、統合、実装を支援するインテグレーターとして選定された。Public Services and Procurement Canada がプロジェクト管理、ビジネス判断、タスク承認、立ち上げを管理した。ベンダーのパフォーマンスは正当な説明責任の対象であるが、公的な記録は、すべてのスコープ、テスト、キャパシティ、立ち上げの決定を IBM だけに帰することを支持していない。
最初の危機対策は、人、金銭、作業項目を混在させており、それらを1つの統計として扱うことはできない。Auditor General の2017年給与問題報告書は、未払いと過払いの従業員数と金額を日付付きで報告しており、一方で他の記録は未処理の給与要求を計上している。1人の従業員が複数の取引やケースを持つことがあり得る。要求は情報提供、非金銭的、または未解決である可能性があり、給与未払いと同じ程度の損害を証明するものではない。
集計上の正確性は、個人の苦難や古い在庫と共存し得る。数百万の支払いのうち高い割合が正確に処理されたとしても、各従業員が適時に正しい額を受け取ったことを示すものではない。調査サンプルでエラーが示された場合も、機械的に全労働力に投影することはできない。正確性、適時性、バックログの経過期間、影響を受けた従業員、過払いの回収、救済には、別々の分母が必要である。
人的対応は単一のプログラムではなかった。緊急給与前払い、費用の払い戻し、一般損害賠償、休暇クレジット、一括支払い、キャッチアップ条項、深刻な影響を受けた場合の請求は、異なる権限、交渉団体、資格期間、手続きに従っていた。自動補償は提出された請求ではなく、提出された請求は承認された請求ではなく、承認された請求は必ずしも同日に支払われた現金ではない。従業員救済には、給与台帳と同じように規律のある台帳が必要である。
コスト総額には明確な境界が必要である。当初のプロジェクト予算、予測された節約、年間の Phoenix 関連支出、累積安定化、損害賠償、過払い引当金、部門移行作業、Dayforce プログラムの見積もりは、それぞれ異なる質問に答える。期間とスコープを調整せずにそれらを合計すると、活動を二重にカウントし、除外事項を隠蔽することになる。代替コストの見積もりは請求書ではなく、年間支出は累積生涯コストではない。
Goss Gilroy と Auditor General は異なる作業を行った。委託された教訓研究は、監査ではないこと、結論はコンサルティング会社のものであることを明示的に述べている。これは文化、ガバナンス、変更管理に関する貴重なコンサルテーション証拠であるが、Auditor General の所見として引用することはできない。権限のラベルは事実の正確性の一部である。
Dayforce は依然として準備態勢プログラムであり、Phoenix が修復された証拠ではない。実現可能性調査、構成、模擬データテスト、計画された並行稼働、短縮された実装スケジュールは、活動と意図の証拠である。Auditor General の2026年近代化報告書は、計画が不完全な中でリスクに対処する機会を説明した。成功には、生産同等の結果の調整、管理された移行、部門の準備、従業員の救済、独立して執行可能なストップゲートが必要である。
給与は公共サービスの継続システムである
給与はしばしばバックオフィス機能として説明されるが、従業員にとっては継続的な公的義務である。支払いの遅延や誤りは、家賃、住宅ローン、食費、育児費、税金、手当、年金拠出、信用に影響を与える可能性がある。雇用主にとっては、同じエラーが支援業務、会計調整、回収義務、労使関係の結果を生み出す。雇用主が連邦政府である場合、給与の継続は制度の正当性にも影響する。国家は、公共サービスを提供する人々に対する最も日常的な約束を守ることができることを示さなければならない。
管理の境界は、計算の前から始まる。部門は、任命、異動、臨時代理、休暇、時間外、手当、団体協約の更新、退職、定年退職など、雇用イベントを作成または変更する。イベントは承認され、正しく入力され、タイムリーに送信されなければならない。給与ルールがその後、支払うべき額を決定する。給与センターは書類や手動操作を必要とする場合がある。Phoenix は給与を計算して支払うが、後続の修正、税金、年金、福利厚生、会計プロセスは同じ記録に依存する場合がある。
この連鎖は、「ソフトウェアのバグ」という診断が狭すぎる理由を説明している。計算エンジンは設定されたルールに従って動作する可能性があるが、ソースイベントが遅延しているか間違っている場合がある。正しい取引が古い作業の後ろで待機する可能性がある。部門の人事システムが異なるプロセスやデータ標準を使用する可能性がある。団体協約が一括更新を必要とする場合がある。修正が新しい取引を生成し、以前の過払いと相互作用する可能性がある。各引き継ぎには、所有者、サービス基準、例外ステータス、エスカレーションルートが必要である。
したがって、近代化は少なくとも4つの変更を組み合わせたものである：技術、運用モデル、労働力容量、組織行動。政府は地域給与システムを置き換え、多くの部門のサービスを集中化し、地域の報酬能力を削減すると同時に、組織に人事慣行の変更を求めた。準備態勢の決定は、これら4つの変更すべてが実際の規模で連携して機能するかどうかに答えなければならなかった。ソフトウェアが給与小切手を生成できることを示すテストは必要であったが、十分ではなかった。
公共部門の継続性には、フォールバックも必要である。新しいシステムや中央サービスが有効なイベントを処理できない場合、従業員は依然としてタイムリーな収入を必要とする。緊急前払いは直接的な害を軽減できるが、調整と回収作業を生み出す。耐久性のある緊急時対応計画は、誰が暫定金を承認できるか、税金と記録の扱い、調整のタイミング、従業員が基礎となる給与が修正される前にワークアラウンドによって引き起こされた金額の返済を求められないようにする方法を特定する。
ビジネスケースは節約、集中化、システム提供を組み合わせた
給与管理の変革イニシアティブは2009年に始まった。それは約29万人の従業員を100以上の組織で対象とし、レガシー給与システムを置き換え、報酬管理を統合することが期待された。公開されたビジネスストーリーには、より少ない報酬ポジションとより標準化されたサービスによる繰り返しの節約が含まれていた。これらの目的は本質的に不合理ではなかったが、準備態勢の証拠と矛盾する可能性のあるスケジュールと予算の圧力を生み出した。
当初のガバナンスの問題は、利益実現と早期の能力削除の結合であった。想定される節約が、新しい組織とシステムが安定した処理能力を示す前に経験豊富なポジションを排除することに依存している場合、プログラムはそのコンティンジェンシーを消費する。団体協約、異常なケース、部門の慣行を理解しているスタッフは、ソフトウェアの機能と交換可能ではない。彼らの知識は、移行中に最も価値がある可能性がある。
2018年の監査では、承認されたプロジェクト予算は約3億1,000万カナダドル、年間節約額は約7,000万カナダドルと見込まれていた。これらの数字は当初のイニシアティブとそのビジネスケースに属する。これらを、後の年間安定化費用や複数年の Dayforce 見積もりと、スコープ、インフレ、部門、運用コストを説明せずに直接比較すべきではない。予算は承認と計画の枠組みであり、実現コストには実際の支出が必要であり、約束された節約には測定されたベースラインと達成された削減が必要である。
ビジネスケースのガバナンスには、非財務的なサービスしきい値を含めるべきである。プログラムは、単に資本予算内にとどまる、または実装プロジェクトを完了するだけで成功を宣言すべきではない。求められる成果には、正確かつタイムリーな給与、バックログの経過期間、コール解決、従業員の苦難、部門のワークロード、手動介入、管理の信頼性が含まれるべきである。節約が部門や従業員への作業の移行や遅延によって達成される場合、公的な台帳はその移転を可視化すべきである。
強力な承認プロセスは、利益を段階的に実施する。経験豊富なポジションは、通常の支払い、複雑な変更、季節的なピーク、団体協約、従業員異動にわたってエンドツーエンドのパフォーマンスが実証されるまで保持される。節約は、システムと給与センターがボリュームを吸収できるという独立した証拠が示された後にのみ認識される。コンティンジェンシーはサービス要件として資金提供され、プロジェクトチームが自信を欠いている証拠として扱われるべきではない。
調達の説明責任は承認されたタスクと保持された権限に従った
IBM は、PeopleSoft ベースの Phoenix システムの設計、カスタマイズ、統合、実装を支援するため、2011年の公開競争で選ばれた。契約モデルは、政府が作業を指定するタスク承認を使用した。Public Accounts Committee の2018年 Phoenix 構築と実装に関する報告書は、Auditor General の所見と制度的対応を捉えている。これはガバナンスと証言に関する証拠であり、国王とベンダーの間で損害賠償を割り当てる民事判決ではない。
インテグレーターとプロジェクト所有者の区別は重要である。ベンダーは、受け入れた作業の有能な遂行、正確な助言、既知の制限のエスカレーション、契約遵守に対して責任を負う。クライアントは、ビジネス要件、スコープ承認、受け入れ基準、資金、業務準備、立ち上げに対して責任を残る。タスク承認モデルは、各変更が誰によって要求され、どのような証拠がそれを支持し、リスクがどのように変化し、誰が結果を受け入れたかを記録する場合、これらの境界を可視化できる。
議会のPACP 会合81の証拠は、IBM が依頼された作業を実行し、部門がプロジェクトマネージャーを務め、IBM がインテグレーターであったという PSPC の証言を記録している。この証言は帰属されるべきであり、ベンダーに責任がなかったという独立した所見として扱われるべきではない。しかし、IBM が一方的に要件と立ち上げゲートを管理したという単純化された主張を反駁するものである。
部門の2022年移行資料は、Phoenix サポートと安定化における IBM の役割を引き続き説明している。部門のブリーフィングは契約と運用の文脈に有用であるが、部門の説明に留まる。ベンダーのコスト、作業成果物、欠陥、決定は、契約、タスク承認、受け入れ記録、独立した技術的証拠と照らして検証されるべきである。
調達の修復には決定台帳が必要である。省略された機能、構成の妥協、欠陥の延期、テストの制限のそれぞれについて、ベンダーの助言、クライアントの決定、運用責任者、影響を受ける集団、残存リスクを特定すべきである。立ち上げ権限は指名され、展開を停止するのに十分独立していなければならない。商業的なスケジュール圧力は、失敗した受け入れ基準を、明示的な経営幹部とサービス所有者の説明責任なしに、導入後の機能拡張として再定義することを許されるべきではない。
要件は給与ルール、データ、運用手順であった
連邦給与は、法令、団体協約、分類、手当、休暇、年金、税金、雇用イベントによって形成される。複雑さは失敗を許さないが、エンジニアリングの義務を変える。要件は、法的および政策的ルールを、構成された計算、入力検証、ワークフロー、サービス手順、例外処理に変換しなければならない。簡素化には、雇用主、交渉団体、部門、政策所有者間の合意が必要であり、技術チームはルールを省略することで黙示的に簡素化することはできない。
Phoenix の実装は、予算とスケジュールに収めるために機能を削除または延期した。レガシーシステムや部門のアドバイザーがサポートしていた一部の作業は、手動になるか、新しい手順を必要とした。機能がスコープから外された場合、プログラムは人間に移行された作業をカウントし、受入機能に人員を配置し、ワークアラウンドをテストしなければならない。手動の指示が存在するだけではギャップは埋まらない。
データの所有権も同様に重要である。部門はタイムリーで正確な人事情報に責任を負い続ける一方、集中給与業務は多くの結果として生じる取引を処理する。システムは、入力時の検証、明確な拒否メッセージ、重複検出、ステータスの共有ビューを必要とする。部門がイベントが送信されたことだけを見て、給与センターが不完全なケースを見ている場合、従業員が調整メカニズムになる。
給与ルールの近代化は、管理されたカタログを生成すべきである。各ルールには、権限、平易な言葉での解釈、機械可読なロジック、例、エッジケース、テストケース、発効日が必要である。変更にはバージョン管理と回帰テストが必要である。カタログは、Phoenix が自動計算するルールと手動介入を必要とするルールを区別すべきである。エラー報告は、原因がソースデータ、構成、計算、処理遅延、またはポリシーの曖昧さのいずれであるかを特定すべきである。
この分類は、一般的な帰属エラーを防ぐ。Auditor General の後の財務監査では、サンプルの基本給および代理給のエラーの多くは、Phoenix の計算エラーではなく、データ入力と処理遅延に関連していることが判明した。それはシステムを成功にしたわけではない。給与サービスにはデータとプロセス管理が含まれる。しかし、是正措置をより正確にする。エンジンの交換だけでは、遅延した人事イベントや不十分な処理能力を修正できない。
テストは人物をシステム全体に追跡しなければならなかった
給与プラットフォームのテストには、孤立した計算の検証以上のものが必要である。エンドツーエンドのテストは、承認された人事イベントから始まり、部門システムとインターフェースを通過し、適切なルールを適用し、手動作業が必要な場合は給与センターに到達し、支払いと会計エントリを生成し、税金と年金記録を更新し、サポートスタッフと従業員が理解できるステータスを示す。修正と取消もテストされなければならない。
2018年の監査では、PSPC は Phoenix を十分にテストせず、計画されていたパイロットを中止したことが判明した。スケジュールが逼迫するにつれてテストは制限された。部門は主に自己評価を通じて準備態勢を報告し、既知の問題は残った。中心的な問題は、テストスクリプトが存在したかどうかではなく、結果が本番ボリューム、複雑なケース、実際のインターフェース、訓練を受けたスタッフ、2段階移行を代表していたかどうかであった。
準備態勢の証拠は敵対的であるべきである。テスターは最も失敗しやすいケースを必要とする：部門間の異動、代理給、遡及的な団体協約、無給休暇、退職、複数の手当、障害対応、差押え、回収。システムは不完全で矛盾したデータでテストされるべきである。パフォーマンステストには、クリーンな新しい取引だけでなく、ピークボリュームと蓄積された修正作業を含めるべきである。
運用準備態勢は容量計算である。タイプ別の予想受入作業、自動化された割合、処理時間、人員、訓練完了、学習中の生産性、手戻りを予測する。容量を新しい需要に加えて移行された在庫と比較する。モデルが新しいソフトウェアが即座に生産性を向上させると仮定する場合、独立したレビューアは証拠を要求すべきである。経験豊富なアドバイザーがすでに去っている場合、コンティンジェンシーは失われた専門知識を考慮しなければならない。
立ち上げゲートには二値の停止基準が必要である：重要な機能が完了しているか、適切に人員配置されたワークアラウンドがテストされているか、未解決の重大度1の欠陥がないか、調整が許容範囲内か、部門インターフェースが合格か、サポートと緊急支払い手順が実施されたか、プライバシーとセキュリティが受け入れられたか、正しい結果を示すのに十分な並行結果があるか。経営幹部は残存リスクを受け入れることができるが、受け入れは、リスクが顕在化した場合の従業員集団と救済策を明記しなければならない。
2016年の段階的展開は準備態勢の弱点を従業員の被害に転換した
Phoenix は2016年2月と4月の2段階で展開された。中央サービスの変更は同じ時期に行われた。従業員はその後、遅延、未払い、過払いを報告し、未解決の作業が蓄積した。立ち上げが引き金となったのは、複合システムを大規模に露出させたからである。根本原因には、スコープ、テスト、人員配置、訓練、部門の準備、データ、ガバナンスに関する初期の決定が含まれる。
2017年の監査は、2017年6月時点で政府が約2億2,800万カナダドルを51,000人の従業員に支払っており、59,000人の従業員が約2億9,500万カナダドルを政府に支払っていると報告した。これらは監査の方法に基づく日付付きの測定値である。110,000人の一意の人物を意味するわけではなく、集団は重複する可能性があり、すべての苦難、後の修正、またはすべての取引を意味するわけではない。Public Accounts Committee の報告書42は、2017年10月18日時点で520,000件の未処理給与要求という別の測定値を記録している。
その違い—従業員と要求—は基本である。1人が未払い、過払い、税務問題、およびいくつかの保留中の変更を持つことができる。1つの要求が複数の取引を生成する可能性がある。ケースは関連作業を束ねるか、サポート問い合わせを表す可能性がある。報告は、ソースが要求と言っているのに「520,000人の従業員」と書くべきではない。また、取引の減少が、同じ人数が救済されたこととして説明されるべきでもない。
未払いと過払いには非対称な測定もある。過払いは、検出されると政府にとって識別可能な債権を生み出すが、過去の記録は管理上の過払いと真の過払いを混合していた。未払いは、完全な集団として常に自動的に識別されるわけではなく、従業員、部門、または報酬アドバイザーが見つけるまで隠れたままになる可能性がある。2020年の PSPC の委員会ブリーフィングは、過払いの種類の区分と未払いの正確な追跡における限界を認めた。
従業員への影響は純額に還元できない。後の修正で総額は回復しても、利息、税金、手当、信用、時間、健康への影響が残る可能性がある。過払いは、従業員が迅速に報告した場合でも、回収への恐怖を生み出す可能性がある。説明責任には、従業員が最初に正しい給与を失った日、暫定支援が到着した日、基礎記録が修正された日、結果として生じた被害が解決された日が必要である。
現在の在庫は作業であり、被害者数ではない
給与センターのダッシュボードは、2026年6月17日時点で処理準備が整った198,000件の取引を報告した。そのうち約133,000件が財務影響あり、62,000件が財務影響なしまたは一般的な問い合わせ、3,000件が団体協約関連に分類された。また、サービス基準内、基準外で1年未満、1年以上の作業を区分した。
これらのカテゴリは、定義が数字とともに伝達される場合にのみ有用である。「処理準備完了」はワークフローステータスであり、すべての部門のすべての作業ではない。「財務影響」は未払い、過払い、または金額を指定しない。「財務影響なし」でも従業員の記録に影響を与える可能性がある。問い合わせはエラーではない場合がある。したがって、在庫は被害を受けた従業員の数ではなく、その減少が完全な修正や救済を証明するものではない。
同じダッシュボードは、最近の期間の受入および処理済み取引（手動および自動作業を含む）を報告した。処理量が受入を上回ると在庫は減少するが、修正や再開が追跡されない限り、品質を示さない。自動化は日常的な作業をより迅速に処理できるが、古くて複雑なケースは残る。優れたダッシュボードは、量と経過期間、初回精度、従業員数、手戻り、財務影響、解決確認を組み合わせる。
PSPC の現在の運用ページは、100以上の組織で43万人以上の現職および元公務員にサービスを提供するより広範な給与システムを説明しており、給与センターはそのサブセットに直接サービスを提供している。数百万の給与小切手と高い集計的な隔週精度率を報告している。この集団はダッシュボードの取引在庫や OAG の影響を受けた従業員数とは異なる。
集計精度は、「どの支払いが記載された精度基準を満たしたかの割合」として解釈されるべきであり、「どの従業員が問題を経験しなかったかの割合」ではない。人は未解決の古いエラーの後でも多くの正しい支払いを受け取ることができる。数百万の支払いのうちの小さな割合でも、深刻な個人の被害を表す可能性がある。指標には定義、分子、分母、期間、修正の扱いが必要である。
監査サンプリング、給与の公平性、個人の正確性
Auditor General の2024–25年度財務監査論評は、サンプルの従業員の29％が基本給または代理給にエラーがあり、21％が2025年3月31日時点で修正を必要としていると報告した。これらは監査方法に基づくサンプル結果である。統計的設計と信頼性分析なしに、全労働力に乗算して集団数を宣言することはできない。
監査はまた、給与費が全体として適正に表示されていると結論付けた。財務諸表の適正性は集計レベルでの重要性を使用し、従業員一人ひとりの給与を保証するものではない。政府は給与費を適正に表示しながら、個々の従業員に重大な個人的エラーが生じる可能性がある。機関の報告は、一方で他方を打ち消すことなく、両方の真実を提示すべきである。
OAG は、サンプルのエラーを Phoenix の計算ミスではなく、データ入力エラーと処理遅延に再度起因するとした。この区別は、是正をシステム交換だけでなく、部門の適時性、検証、容量に向ける。エンドツーエンドのサービスを免責するものではない。従業員は組織の境界を経験しない。彼らが経験するのは、正しい金額が届いたかどうかである。
2025年3月31日時点で、監査は約349,000件の未処理給与アクション要求を説明し、その半数以上が1年以上経過していた。また、4億7,200万カナダドル以上の未収過払い金、貸倒引当金、純債権額を報告した。過払い総額、引当金、純簿価は別々の会計指標である。経過期間は回収可能性や責任を証明しない。
説明責任のあるダッシュボードは、サンプルと集団の証拠を別々に表示すべきである。運用指標はすべての記録された取引をカバーできるが、独立した監査はサンプルと統制をテストする。監査で発見された例外は是正に反映されるべきであり、是正は再テストされるべきである。公的な読者は、定義が OAG、PSPC、Treasury Board、部門システム間で異なる場合にその旨を伝えられるべきである。
過払いの回収は二次的な被害を生み出してはならない
過払いは無料のお金ではないが、雇用主のシステムがエラーを引き起こしたか長期化させた場合、回収は単純な債務回収の演習ではない。政府は、金額、期間、税務処理、以前の修正、法的回収期間を確定しなければならない。従業員は理解可能な明細書と計算に異議を申し立てる方法を必要とする。回収スケジュールは、苦難や継続中の未解決の給与を考慮すべきである。
2022年の PSPC のPhoenix 過払いに関するブリーフィングは、管理上の過払いと真の過払いを組み合わせた日付付きの数字を使用し、特定された従業員、発生した金額、回収された金額、未収残高を報告した。これらの測定値は、日付、集団、償却、税務調整、定義を調整せずに、後の OAG 財務諸表債権と直接比較すべきではない。
管理上の過払いは、記録が一時的に相殺額を生み出す取引を通じて修正されるときに発生する可能性がある。真の過払いは、最終的に従業員に支払われるべきでないお金である。システムが過去のある時点でそれらを確実に分離できなかった場合、報告書はその旨を述べなければならない。合計額を従業員の債務とラベル付けすることは確実性を誇張し、不適切な回収措置につながる可能性がある。
未払いも、政府の債権として現れないため、同様に強力なプロセスを必要とする。従業員は欠落したすべてのイベントを再構築する負担を負うべきではない。部門と PSPC は、承認された雇用データと実際の給与を比較し、説明のない変更を特定し、不一致が続く前に人々に連絡するという積極的な検出を必要とする。利息、税金、手当への影響は、基礎となる修正にリンクされるべきである。
管理目標は、従業員と承認されたサポートスタッフが見える単一の調整明細書である。雇用イベント、期待給与、実際の給与、修正、前払い、過払い、回収、残存する紛争を日付別にリストすべきである。別々のシステムがインターフェースの背後で動作してもかまわないが、人は異なるチームから矛盾する残高を受け取るべきではない。
救済は一連の合意と請求であった
Treasury Board の請求と補償ハブは、複数の Phoenix 損害賠償プロセスを整理している。その構造自体が、「支払われた請求」が曖昧すぎる理由を示している。一部の補償は対象となる現職従業員に自動的にクレジットされ、一部の元従業員や遺産は申請する必要があり、一部の救済は一般損害賠償をカバーし、深刻な影響プロセスは個別の証拠を必要とした。
2019年の損害賠償合意は、署名した交渉団体をカバーし、その条件の下で最大5日間の休暇を含む一般補償を提供した。また、追加の金銭的および非金銭的被害のためのルートも作成した。休暇クレジットには価値があるが、元従業員に支払われる現金や請求後に裁定された損害賠償と同じではない。
別の2020年の PSAC 合意は、対象となる代表従業員に金銭的な一般損害賠償規定を使用し、団体協約の遅延実施に対処した。資格は対象の会計年度と雇用ステータスに依存した。合意の存在は、影響を受けたすべての人がその交渉単位に属していたか、最大額を受け取ったことを立証するものではない。
2021年のキャッチアップ覚書は、以前の合意の対象となる人々の特定の給付を調整した。これは別個の後発のメカニズムとして報告されるべきであり、2019年の条件に黙示的に統合されるべきではない。合意日、資格期間、支払日は異なる場合がある。
深刻な影響プロセスは、財政的費用、失われた投資収入、健康問題に関連する休暇、深刻な個人または財政的苦難などのカテゴリに対処し、適用される条件と証拠に従う。多くのカテゴリには閾値が適用され、一部は異なる扱いを受ける。提出された請求は、請求額が承認された証拠ではなく、承認された救済には現金ではなく休暇の回復が含まれる場合がある。
したがって、救済報告は集団を別々に示すべきである：自動的にクレジットされた、請求資格のある、請求受領済み、決定済み、全部または一部承認済み、拒否済み、支払済み、再開済み、未処理。また、中央値とテール処理時間も示すべきである。目的は会計だけではない。救済の遅延は当初の被害を深め、基本給が修正された後でも信頼を損なう可能性がある。
コスト報告にはスコープマップが必要である
Treasury Board の2024–25年度 Phoenix 支出報告書は、その会計年度の Phoenix 関連支出として9億3,750万カナダドルを報告した。ページには、次世代人事・給与作業、損害賠償と国王請求、機会費用などの除外事項が記載されている。これは年間のスコープ化された合計であり、2009年以降の Phoenix の累積コストではない。
異なるコストの質問には異なる台帳が必要である。当初の実装予算は、プロジェクトが支出を許可された金額に答える。年間安定化支出は、政府が記載されたカテゴリの下で1年間に支出した金額に答える。損害賠償は補償義務を報告する。過払い引当金は貸借対照表の見積もりであり、プログラム支出ではない。部門のスタッフ時間や遅延した政策作業は機会費用である可能性がある。Dayforce の見積もりは後継プログラムに関するものである。
議会予算官の2019年の代替コスト見積もりは、当時利用可能な仮定に基づくシナリオ見積もりであった。これは調達の受賞、承認された Dayforce 予算、または実際の請求書ではなかった。後の見積もりと比較することで、スコープと情報がどのように変化したかを示すことができるが、それは仮定と価格基準が保持されている場合に限られる。
コスト管理は、各ドルをプログラム、組織、会計年度、目的（運用、安定化、在庫処理、補償、回収、代替設計、部門移行、レガシー廃止）に割り当てるべきである。共通コストには配分ルールが必要である。公的報告は、年間合計を累積数値に調整し、変更を説明すべきである。節約は、移行された部門作業と継続中の手動プロセスを差し引いて報告されるべきである。
価値は最も安い立ち上げではない。それは、持続可能な管理で正確かつタイムリーな給与を提供するコストである。より高価な並行稼働は、エラーと従業員の被害の移行を防ぐ場合、良い価値になる可能性がある。逆に、新旧システムを無期限に延長することは、リスクを減らさずに重複コストを生み出す可能性がある。意思決定者は、スケジュール主導の宣言ではなく、明示的な終了基準を必要とする。
Goss Gilroy は教訓研究であり、監査ではなかった
政府のGoss Gilroy 教訓研究報告書は、文書レビューとコンサルテーションを通じて、2008年から2016年4月までのイニシアティブをレビューした。報告書は、監査ではないこと、意見と結論は Goss Gilroy に属し、必ずしも政府に属さないことを明示的に述べている。この免責事項は実質的な証拠の境界である。
この研究は依然として価値がある。ガバナンス、監視、変更管理、能力、テスト、プロジェクト文化に関する教訓を整理した。コンサルテーションは、参加者が圧力と意思決定をどのように理解したか、正式なプロジェクト文書が過小評価する情報を含めて明らかにすることができる。しかし、Auditor General の法定権限や保証方法を使用しておらず、インタビューに基づく観察は裁定された事実として提示されるべきではない。
OAG 報告書、議会委員会、部門ブリーフィング、Goss Gilroy 研究は、権限マトリックスを通じて一緒に読むことができる。各命題について、マトリックスは、情報源が記録を監査したか、証言を聞いたか、部門の方針を説明したか、参加者の見解を報告したか、勧告を発行したかを述べる。異なる権限を持つ情報源間の一致は結論を強化できるが、不一致は平均化されるのではなく可視化されるべきである。
このアプローチは、説明責任と公平性の両方を保護する。コンサルテーションの観察が個人に対する法的所見になるのを防ぐ。また、機関が運用上の教訓が監査を通じて生成されなかったという理由だけで、それを却下することを防ぐ。正しい対応は、観察を記録と現在の運用証拠と照らしてテストすることである。
安定化活動は解決と同じではない
PSPC の統合人事・給与戦略は、現在の Phoenix 安定化、バックログ削減、将来の Dayforce 作業を組み合わせている。統合されたフレーミングは賢明である。なぜなら、未解決の作業と代替設計が相互作用するからである。また、報告リスクを生み出す：あるストリームの進捗が別のストリームの成功と誤認される可能性がある。
2026年3月の進捗状況更新は、対象となる古いケースの集団の高い割合が処理され、1年以上経過した取引が減少したと述べた。「対象ケース」は完全な在庫ではなく、「処理済み」はそれ自体で各従業員が結果に同意したか、結果として生じる救済を受けたかを証明しない。分母と対象選択は可視化されたままでなければならない。
安定化には階層化された成果があるべきである。最初に、取引を処理する。第二に、結果として生じる給与と下流の税金、年金、福利厚生記録を検証する。第三に、従業員と問題が解決したことを確認するか、残存する紛争を記録する。第四に、人を該当する補償に結びつける。第五に、根本的な管理が変更され、ケースタイプが再発しないかテストする。
そうでなければ、在庫削減は正確性よりもクロージャに報いる可能性がある。ボリュームプレッシャーの下で、チームは作業を異なる方法で分割または結合したり、ステータス定義を変更したり、金銭的取引が残っている間に問い合わせを閉じたりする可能性がある。独立した品質サンプリング、再開率、従業員確認がそのリスクを制約する。最古のケースの報告は、集計的な改善が持続的なテールを隠すのを防ぐ。
安定化されたシステムは、廃止まで運用上の回復力も必要とする。セキュリティパッチ、ベンダーサポート、給与カレンダー、団体協約の変更、経験豊富なスタッフは、Dayforce が計画されているからといって軽視されてはならない。移行期間は最もリスクの高いフェーズである可能性がある：人々は新しいプラットフォームを学びながら、Phoenix を維持し、古い作業を処理する。容量モデルには、両方のシステムと部門の準備を含めるべきである。
Dayforce の計画は立ち上げの権利を獲得しなければならない
政府のDayforce 実現可能性報告書は、商業プラットフォームが連邦の人事・給与ニーズを満たせるかどうかを評価するために使用された調査、構成、テストを説明している。実現可能性調査は不確実性を減らすことができるが、模擬データと選択されたシナリオは、すべての部門、団体協約、レガシー例外にわたる正確な本番給与を証明しない。
2026年の OAG は、Dayforce 変革が2027年6月まで計画段階にあり、重要な部門移行コストを除いた暫定総額が42億カナダドル以上であると報告した。また、未解決の Phoenix エラーが新しいシステムに持ち込まれる可能性があり、給与ルールの簡素化が依然として不完全であると警告した。監査中および監査後に、プログラムはスケジュールを短縮した。より速い日付は証明責任を増大させる。減らすものではない。
PSPC のコミットメント追跡ページは、構成とテストのマイルストーンを説明している。将来を見据えたマイルストーンは計画である。報告は、イベントが発生し証拠が合格するまで、「予定」、「計画中」、または「目標」を使用すべきである。計画された並行テストは、完了した調整ではない。
立ち上げゲートは、代表的な部門と困難なケースに対して、遡及、給付、年度末効果を含む十分なサイクルにわたって、本番同等の並行給与を要求すべきである。すべての差異は分類され、所有され、解決されるべきである。テストは、Phoenix が常に正しい参照であると仮定するのではなく、期待給与、Phoenix 出力、Dayforce 出力、実際の従業員記録を比較すべきである。
移行管理は、クリーンなマスターデータを未解決のケースから分離しなければならない。未処理の取引には処分が必要である：移行前に解決、完全な履歴と指名された所有者で移行、または管理されたレガシープロセスで保持。過払い、前払い、休暇、税金、年金の残高には調整が必要である。従業員は移行中に自分の問題がどのシステムに属しているかを見ることができるべきである。
部門の準備は独立して立証されなければならない。各組織には、訓練を受けたスタッフ、マッピングされた人事プロセス、データ品質結果、インターフェーステスト、サポートルート、コンティンジェンシーが必要である。中央プログラムは、自己評価をサンプリングし、挑戦すべきである。停止権限は、公的なスケジュールが発表されたという理由だけで覆されることなく、部門またはウェーブを遅延できるべきである。
給与準備態勢と救済のための管理マップ
修復された説明責任システムは、8つのドメインを中心に組織化できる。要件所有者は給与ルールカタログを維持し、簡素化を承認する。調達所有者はベンダーの作業、助言、受入、欠陥を記録する。技術チームは構成とテストを行う。部門はタイムリーな人事イベントを所有する。PSPC は給与センターの運用とエンドツーエンドサービスを所有する。Treasury Board は雇用主政策と損害賠償フレームワークを所有する。財務所有者は給与と過払いを調整する。独立した立ち上げ権限は、証拠が移行を支持するかどうかを決定する。
各ドメインには観察可能な証拠が必要である。要件は構成とテストにトレースされる。ベンダータスクには受入記録がある。部門イベントは適時性と検証閾値を満たす。給与センターの容量は、コンティンジェンシーを考慮して予測需要を超える。在庫指標は、取引、ケース、要求、影響を受ける従業員を調整する。未払いと過払いには日付付きの定義がある。救済台帳は、給与エラー、結果として生じる被害、決定、支払いを接続する。
管理マップは従業員の尊厳を保持すべきである。スタッフは同じ履歴を複数のチームに繰り返したり、どの組織が問題を所有しているかを推測したりする必要はない。ケースマネージャーは、各部門が正式な責任を保持しながら、部門人事、給与センター、税務、年金、請求機能を調整できる。コミュニケーションは、既知のこと、まだ争われていること、次のアクション、予定日を述べるべきである。
自動化は説明責任を支援すべきであり、覆い隠すべきではない。ルールエンジンはデータを検証でき、ワークフローは例外をルーティングでき、分析は繰り返し発生する障害を特定でき、ダッシュボードは経過期間を表示できる。すべての自動化された決定は、ソースデータ、ルールバージョン、ステータス変更、人間によるオーバーライドを保持すべきである。閉じたコードは、監査や請求に必要な証拠を消去すべきではない。
独立した保証は立ち上げ後も継続すべきである。監査人は取引だけでなく従業員もサンプリングし、システム全体で記録を追跡すべきである。従業員代表は集約されたエラーと救済措置を見ることができるべきである。部門はデータの適時性について比較されるべきであり、中央処理にすべての責任を転嫁すべきではない。結果は、傾向を示すのに十分安定した定義で公開されるべきである。
結論
Phoenix は、政府がソフトウェアを購入して構成し、それを取り巻くサービスを再設計したため、公共調達の説明責任テストとなった。欠落した機能、不完全なテスト、削減された専門知識、断片化されたデータ所有権、弱い立ち上げチャレンジが相互作用した。IBM の契約上の役割は重要であるが、PSPC は作業を定義し、スコープを受け入れ、展開する権限を保持していた。正確な帰属は学習に不可欠である。
影響の記録にも同様の精度が必要である。従業員は人であり、取引、要求、ケースは作業単位である。未払い、過払い、バックログ、精度、監査サンプルには異なる分母がある。年間支出、累積安定化、損害賠償、代替見積もりには異なるコスト境界がある。在庫の減少は進歩である可能性があるが、すべての人が正しく支払われ、補償されたことを証明するものではない。
救済はシステムパフォーマンスの一部であり、外部の法的後付けではない。緊急支援、一般損害賠償、休暇、一時金、キャッチアップ支払い、深刻な影響の請求には、透明な資格、処理、成果の指標が必要である。基本給を数ヶ月または数年後に修正しても、税金、信用、健康、または失われた時間への影響が自動的に修復されるわけではない。
Dayforce はより強力な管理を構築する機会を提供するが、その機会は証明ではない。構成、実現可能性、計画された並行テストは、実際の人事イベント、給与ルール、部門、従業員にわたって再現可能な証拠に結実しなければならない。未解決の Phoenix 記録には指名された所有者と調整された移行パスが必要である。独立した立ち上げゲートはノーと言える能力を持たなければならない。
耐久性のある基準は単純である：政府は、誰がテストされたか、何が異なっていたか、例外がどのように解決されたか、従業員がどのように保護されるか、誰が展開を停止できるかを示すまで、給与システムの準備完了を宣言すべきではない。その証拠は、近代化をスケジュールから説明責任のある公共サービスへと変える。