Prontidão do sistema Phoenix e reparação

Resumo

O Phoenix combinou uma substituição de software com uma centralização de serviços, portanto, a prontidão teve que cobrir todo o sistema de RH a folha de pagamento.A iniciativa substituiu um motor de pagamento de décadas enquanto transferia o trabalho de compensação dos departamentos para um novo Centro de Pagamento. O relatório de implementação de 2018 do Auditor Geral constatou que funções críticas foram removidas, os testes foram reduzidos, os avisos de prontidão foram desconsiderados e o sistema foi implantado em duas ondas em fevereiro e abril de 2016.
Um motor de cálculo poderia parecer tecnicamente operacional enquanto departamentos, dados, procedimentos e capacidade de serviço permaneciam não prontos.
O papel da IBM deve ser descrito por meio do contrato e do trabalho autorizado, não por meio de uma história moral de um único fornecedor.A empresa foi selecionada como integradora para ajudar a projetar, personalizar, integrar e implementar o sistema baseado em PeopleSoft. O Public Services and Procurement Canada controlava o gerenciamento de projetos, decisões de negócios, autorizações de tarefas e lançamento. O desempenho do fornecedor é um assunto legítimo de accountability, mas o registro oficial não apoia atribuir todas as decisões de escopo, teste, capacidade e lançamento apenas à IBM.
As primeiras medidas de crise misturaram pessoas, dinheiro e itens de trabalho que não podem ser tratados como uma única estatística.O relatório de problemas de pagamento de 2017 do Auditor Geral relatou contagens de funcionários datadas e valores em dólares para subpagamentos e sobrepagamentos, enquanto outros registros contavam solicitações de pagamento pendentes. Um funcionário pode ter várias transações ou casos. Uma solicitação pode ser informativa, não financeira ou não resolvida sem provar o mesmo dano que um contracheque ausente.
A precisão agregada pode coexistir com dificuldades individuais e um inventário antigo.Uma alta porcentagem da folha de pagamento processada com precisão em milhões de pagamentos não estabelece que cada funcionário recebeu o valor correto no prazo. Uma amostra de auditoria mostrando erros também não pode ser projetada mecanicamente para toda a força de trabalho. Precisão, pontualidade, idade do backlog, funcionários afetados, recuperação de sobrepagamentos e reparação precisam de denominadores separados.
A resposta humana não foi um único programa.Adiantamentos salariais de emergência, reembolso de custos, danos gerais, créditos de licença, pagamentos únicos, provisões de recuperação e reivindicações de impacto severo seguiram diferentes autoridades, grupos de negociação, períodos de elegibilidade e processos. A compensação automática não é uma reivindicação apresentada; uma reivindicação apresentada não é uma reivindicação aceita; uma reivindicação aceita não é necessariamente dinheiro pago na mesma data. A reparação do funcionário precisa de um livro-razão tão disciplinado quanto o livro-razão da folha de pagamento.
Os totais de custos exigem limites explícitos.Orçamentos de projeto originais, economias previstas, despesas anuais relacionadas ao Phoenix, estabilização cumulativa, danos, provisões para sobrepagamentos, trabalho de transição departamental e estimativas do programa Dayforce respondem a perguntas diferentes. Adicioná-los sem ajustar por período e escopo conta duplicadamente a atividade e oculta exclusões. Uma estimativa de custo de substituição não é uma fatura, e uma despesa anual não é o custo cumulativo vitalício.
A Goss Gilroy e o Auditor Geral fizeram trabalhos diferentes.O estudo de lições aprendidas encomendado afirma expressamente que não é uma auditoria e que suas conclusões são da empresa de consultoria. É uma evidência de consultoria valiosa sobre cultura, governança e gerenciamento de mudanças, mas não pode ser citada como uma constatação do Auditor Geral. Os rótulos de mandato fazem parte da precisão factual.
O Dayforce continua sendo um programa de prontidão, não uma prova de que o Phoenix foi reparado.Trabalho de viabilidade, configuração, testes com dados simulados, execuções paralelas planejadas e um cronograma de implementação encurtado são evidências de atividade e intenção. O relatório de modernização de 2026 do Auditor Geral descreveu uma oportunidade para abordar riscos enquanto o planejamento estava incompleto. O sucesso requer resultados reconciliados de produção, migração controlada, preparação departamental, remédios para funcionários e um ponto de parada independente e aplicável.

A folha de pagamento é um sistema de continuidade do serviço público

A folha de pagamento é frequentemente descrita como uma função de back-office, mas para os funcionários é uma obrigação pública recorrente. Um pagamento perdido ou incorreto pode afetar aluguel, hipoteca, alimentação, creche, impostos, benefícios, contribuições previdenciárias e crédito. Para um empregador, o mesmo erro cria trabalho de suporte, ajustes contábeis, obrigações de recuperação e consequências nas relações trabalhistas.

Quando o empregador é o governo federal, a continuidade da folha de pagamento também afeta a legitimidade institucional: o Estado deve demonstrar que pode honrar seu compromisso mais rotineiro com as pessoas que prestam serviços públicos.

O fronteira de controle começa antes de qualquer cálculo. Um departamento cria ou altera um evento de emprego: nomeação, transferência, designação interina, licença, horas extras, abono, atualização de acordo coletivo, rescisão ou aposentadoria. O evento deve ser autorizado, inserido corretamente e transmitido no prazo. As regras de pagamento determinam o que é devido. O Centro de Pagamento pode precisar de documentos ou ação manual. O Phoenix calcula e emite o pagamento, mas processos posteriores de correção, imposto, pensão, benefícios e contabilidade podem depender do mesmo registro.

Essa cadeia explica por que o diagnóstico de “bug de software” é muito estreito. O motor de cálculo pode operar de acordo com regras configuradas enquanto o evento de origem está atrasado ou errado. Uma transação correta pode esperar atrás de trabalho antigo. Um sistema de RH departamental pode usar um processo ou padrão de dados diferente. Um acordo coletivo pode exigir atualizações em massa. Uma correção pode gerar uma nova transação e interagir com um sobrepagamento anterior. Cada transferência precisa de um proprietário, padrão de serviço, status de exceção e rota de escalonamento.

A modernização, portanto, combinou pelo menos quatro mudanças: tecnologia, modelo operacional, capacidade da força de trabalho e comportamento organizacional. O governo substituiu o Sistema Regional de Pagamento, centralizou serviços para muitos departamentos e reduziu a capacidade local de compensação, enquanto pedia às organizações que mudassem as práticas de RH. Uma decisão de prontidão tinha que responder se todas as quatro mudanças funcionavam juntas em escala real. Um teste que mostrasse que o software poderia produzir um contracheque era necessário, mas não suficiente.

A continuidade do setor público também requer um plano de contingência. Se um novo sistema ou serviço central não puder processar um evento válido, os funcionários ainda precisam de renda oportuna. Adiantamentos de emergência podem reduzir danos imediatos, mas criam trabalho de reconciliação e recuperação. Um plano de contingência durável identifica quem pode autorizar dinheiro provisório, como é tributado e registrado, quando é reconciliado e como os funcionários evitam ser solicitados a reembolsar um valor causado pela solução alternativa antes que seu pagamento subjacente seja corrigido.

O caso de negócio combinou economia, centralização e entrega do sistema

A iniciativa Transformação da Administração de Pagamentos começou em 2009. Esperava-se que atendesse aproximadamente 290.000 funcionários em mais de cem organizações, substituísse o sistema de pagamento legado e consolidasse a administração de compensação. A narrativa pública de negócios incluía economias recorrentes com menos cargos de compensação e um serviço mais padronizado. Esses objetivos não eram inerentemente irracionais, mas criaram pressões de cronograma e orçamento que poderiam conflitar com as evidências de prontidão.

O problema original de governança foi o acoplamento da realização de benefícios à remoção precoce de capacidade. Se as economias projetadas dependem da eliminação de cargos experientes antes que a nova organização e sistema demonstrem produção estável, o programa consome sua contingência. Funcionários que entendem acordos coletivos, casos incomuns e práticas departamentais não são intercambiáveis com recursos de software. Seu conhecimento pode ser mais valioso durante a migração, quando defeitos e exceções de dados aparecem.

A auditoria de 2018 descreveu um orçamento de projeto aprovado de cerca de C$ 310 milhões e uma economia anual esperada de C$ 70 milhões. Esses números pertencem à iniciativa original e ao seu caso de negócio. Eles não devem ser comparados diretamente com uma fatura anual de estabilização posterior ou uma estimativa plurianual do Dayforce sem explicar escopo, inflação, departamentos e custos operacionais. Um orçamento é um envelope de autorização e planejamento; um custo realizado requer despesa real; uma economia prometida requer uma linha de base medida e uma redução alcançada.

A governança do caso de negócio deve incluir limites de serviço não financeiros. Um programa não deve declarar sucesso apenas porque permanece dentro do orçamento de capital ou encerra um projeto de implementação. Os resultados exigidos devem incluir pagamento correto e pontual, idade do backlog, resolução de chamados, dificuldades dos funcionários, carga de trabalho departamental, intervenção manual e confiabilidade do controle. Se as economias forem alcançadas transferindo trabalho ou atraso para departamentos e funcionários, o registro público deve tornar essa transferência visível.

Um processo de aprovação robusto estagiaria os benefícios. As posições experientes seriam mantidas até que o desempenho ponta a ponta fosse demonstrado em pagamento normal, mudanças complexas, picos sazonais, acordos coletivos e transferências de funcionários. As economias seriam reconhecidas somente após evidências independentes mostrarem que o sistema e o Centro de Pagamento poderiam absorver o volume. A contingência seria financiada como um requisito de serviço, não tratada como evidência de que a equipe do projeto não tinha confiança.

A accountability em compras públicas seguiu tarefas autorizadas e autoridade retida

A IBM venceu a concorrência pública de 2011 para apoiar o design, personalização, integração e implementação do sistema Phoenix baseado em PeopleSoft. O modelo de contratação usou autorizações de tarefas por meio das quais o governo especificava o trabalho. O relatório de 2018 do Comitê de Contas Públicas sobre construção e implementação do Phoenix capturou as descobertas do Auditor Geral e a resposta institucional. É evidência sobre governança e depoimento, não um julgamento civil alocando danos entre a Coroa e o fornecedor.

A distinção entre integrador e proprietário do projeto é crítica. Um fornecedor é responsável pela entrega competente do trabalho que aceita, aconselhamento preciso, escalonamento de limites conhecidos e conformidade com o contrato. O cliente permanece responsável pelos requisitos de negócio, aprovação de escopo, critérios de aceitação, financiamento, prontidão operacional e lançamento. Um modelo de autorização de tarefas pode tornar esses limites visíveis se cada alteração registrar quem a solicitou, que evidência a apoiou, como o risco mudou e quem aceitou o resultado.

A evidência da reunião 81 do PACP registrou o depoimento do PSPC de que a IBM realizou o trabalho que lhe foi solicitado e que o departamento atuou como gerente do projeto enquanto a IBM era a integradora. Esse depoimento deve ser atribuído, não tratado como uma descoberta independente de que o fornecedor não tinha responsabilidade. No entanto, refuta a alegação simplista de que a IBM controlava unilateralmente os requisitos e o portão de lançamento.

O material de transição de 2022 do departamento continuou a descrever o papel da IBM no suporte e estabilização do Phoenix. Um briefing departamental é útil para contexto contratual e operacional, mas continua sendo o relato do departamento. Custos do fornecedor, produtos de trabalho, defeitos e decisões devem ser testados contra contratos, autorizações de tarefas, registros de aceitação e evidências técnicas independentes.

O reparo de compras públicas requer um registro de decisões. Cada recurso omitido, compromisso de configuração, adiamento de defeito e limitação de teste deve identificar o conselho do fornecedor, a decisão do cliente, o proprietário operacional, a população afetada e o risco residual. A autoridade de lançamento deve ser nomeada e independente o suficiente para interromper a implantação. A pressão comercial de cronograma não pode ser permitida para redefinir um critério de aceitação falhado como um aprimoramento pós-lançamento sem responsabilidade explícita do executivo e do proprietário do serviço.

Os requisitos eram regras de pagamento, dados e procedimentos operacionais

O pagamento federal é moldado por estatutos, acordos coletivos, classificações, abonos, licenças, pensões, impostos e eventos de emprego. A complexidade não desculpa o fracasso, mas muda a obrigação de engenharia. Os requisitos devem traduzir regras legais e políticas em cálculos configurados, validações de entrada, fluxo de trabalho, procedimentos de serviço e tratamento de exceções. A simplificação requer acordo entre empregadores, agentes de negociação, departamentos e proprietários de políticas; uma equipe de tecnologia não pode simplificar silenciosamente uma regra omitindo-a.

A implementação do Phoenix removeu ou adiou funções para permanecer dentro do orçamento e cronograma. Parte do trabalho que o sistema legado ou consultores departamentais apoiavam tornou-se manual ou exigiu novos procedimentos. Quando a funcionalidade é reduzida, o programa deve contabilizar o trabalho transferido para humanos, alocar a função receptora e testar a solução alternativa. Uma lacuna não é fechada apenas porque existe uma instrução manual.

A propriedade dos dados é igualmente importante. Os departamentos permanecem responsáveis por informações de RH oportunas e precisas, enquanto as operações centralizadas de pagamento processam muitas transações resultantes. O sistema precisa de validação na entrada, mensagens de rejeição claras, detecção de duplicatas e uma visão compartilhada do status. Se um departamento vê apenas que um evento foi enviado enquanto o Centro de Pagamento vê um caso incompleto, o funcionário se torna o mecanismo de reconciliação.

A modernização das regras de pagamento deve produzir um catálogo controlado. Cada regra precisa de uma autoridade, interpretação em linguagem simples, lógica legível por máquina, exemplos, casos extremos, casos de teste e datas de vigência. As mudanças precisam de controle de versão e teste de regressão. O catálogo deve distinguir as regras que o Phoenix calcula automaticamente daquelas que exigem intervenção manual. A notificação de erros deve identificar se a causa foi dados de origem, configuração, cálculo, atraso de processamento ou ambiguidade de política.

Essa classificação evita um erro comum de atribuição. A auditoria financeira posterior do Auditor Geral descobriu que muitos erros de pagamento básico e interino amostrados estavam associados a erros de entrada de dados e atrasos de processamento, e não a cálculos errôneos do Phoenix. Isso não torna o sistema bem-sucedido: um serviço de folha de pagamento inclui seus controles de dados e processo. Isso torna o remédio mais preciso. Substituir o motor sozinho não pode corrigir eventos de RH atrasados ou capacidade de processamento insuficiente.

O teste teve que seguir uma pessoa por todo o sistema

Testar uma plataforma de folha de pagamento exige mais do que verificar cálculos isolados. O teste ponta a ponta começa com um evento de RH autorizado, passa pelos sistemas e interfaces departamentais, aplica a regra correta, chega ao Centro de Pagamento quando o trabalho manual é necessário, gera o pagamento e o lançamento contábil, atualiza os registros de imposto e pensão e mostra um status que a equipe de suporte e o funcionário possam entender. Correções e reversões também devem ser testadas.

A auditoria de 2018 constatou que o PSPC não testou completamente o Phoenix antes do lançamento e cancelou um piloto planejado. Os testes foram restringidos à medida que o cronograma se apertava. Os departamentos relataram prontidão em grande parte por autoavaliação, enquanto problemas conhecidos permaneciam. A questão central não era se scripts de teste existiam; era se os resultados representavam volume de produção, casos complexos, interfaces reais, equipe treinada e a migração em duas ondas.

As evidências de prontidão devem ser adversariais. Os testadores precisam de casos com maior probabilidade de falhar: transferências entre departamentos, pagamento interino, acordos coletivos retroativo, licença sem vencimento, rescisões, múltiplos abonos, acomodação por deficiência, penhora e recuperação. O sistema deve ser testado com dados incompletos e conflitantes. Os testes de desempenho devem incluir volumes de pico e trabalho de correção acumulado, não apenas transações novas e limpas.

A prontidão operacional é um cálculo de capacidade. Preveja o trabalho recebido por tipo, parcela automatizada, tempo de manuseio, pessoal, conclusão do treinamento, produtividade durante o aprendizado e retrabalho. Compare a capacidade com a nova demanda mais o inventário migrado. Se o modelo assume que o novo software aumenta imediatamente a produtividade, um revisor independente deve exigir evidências. Se consultores experientes já saíram, a contingência deve contabilizar a perda de especialização.

Um portão de lançamento deve ter critérios de parada binários: funções críticas concluídas ou uma solução alternativa adequadamente alocada testada; nenhum defeito de gravidade um não resolvido; reconciliação dentro da tolerância; interfaces departamentais aprovadas; procedimentos de suporte e pagamento de emergência exercitados; privacidade e segurança aceitas; e resultados paralelos suficientes para mostrar resultados corretos. Os executivos podem aceitar risco residual, mas a aceitação deve declarar a população de funcionários e o remédio se o risco se materializar.

As ondas de 2016 transformaram fraqueza de prontidão em dano ao funcionário

O Phoenix foi implantado em duas ondas em fevereiro e abril de 2016. Mudanças centralizadas de serviço ocorreram por volta do mesmo período. Os funcionários então relataram pagamentos atrasados, ausentes, inferiores e superiores, e o trabalho não resolvido se acumulou. O lançamento é o gatilho porque expôs o sistema combinado em escala. A raiz inclui decisões tomadas anteriormente sobre escopo, teste, pessoal, treinamento, preparação departamental, dados e governança.

A auditoria de 2017 relatou que em junho de 2017 o governo devia cerca de C$ 228 milhões a 51.000 funcionários e 59.000 funcionários deviam cerca de C$ 295 milhões ao governo. Essas eram medidas datadas derivadas sob o método da auditoria. Elas não significam 110.000 pessoas únicas porque as populações podem se sobrepor, e não equivalem a todas as dificuldades, todas as correções posteriores ou todas as transações. O relatório 42 do Comitê de Contas Públicas registrou uma medida separada de 520.000 solicitações de pagamento pendentes em 18 de outubro de 2017.

Essa diferença—funcionários versus solicitações—é fundamental. Uma pessoa pode ter um subpagamento, um sobrepagamento, um problema fiscal e várias alterações pendentes. Uma solicitação pode gerar várias transações. Um caso pode agrupar trabalhos relacionados ou representar uma consulta de suporte. A comunicação nunca deve escrever “520.000 funcionários” quando a fonte diz solicitações. Nem uma redução de transação deve ser descrita como o mesmo número de pessoas integralmente compensadas.

O subpagamento e o sobrepagamento também têm medição assimétrica. Um sobrepagamento cria um recebível identificável para o governo uma vez detectado, embora registros históricos misturassem sobrepagamentos administrativos e reais. O subpagamento nem sempre foi identificado automaticamente como uma população completa; poderia permanecer oculto até que um funcionário, departamento ou consultor de compensação o encontrasse. Um briefing do comitê do PSPC de 2020 sobre o Phoenix reconheceu limites na segregação de tipos de sobrepagamento e no rastreamento preciso de subpagamentos.

O impacto no funcionário não pode ser reduzido a dólares líquidos. Uma correção posterior pode restaurar o pagamento bruto, deixando efeitos de juros, imposto, benefício, crédito, tempo e saúde. Um sobrepagamento pode criar medo de recuperação mesmo quando o funcionário relatou o problema prontamente. A accountability requer a data em que o funcionário perdeu o acesso ao pagamento correto, a data em que o suporte interino chegou, a data em que o registro subjacente foi corrigido e a data em que o dano consequencial foi resolvido.

O inventário atual é trabalho, não uma contagem de vítimas

O painel do Centro de Pagamento relatou 198.000 transações prontas para processar em 17 de junho de 2026. Ele dividiu-as em cerca de 133.000 transações com impacto financeiro, 62.000 sem impacto financeiro ou envolvendo consultas gerais e 3.000 relacionadas a acordos coletivos. Também separou o trabalho dentro dos padrões de serviço, fora dos padrões por menos de um ano e com mais de um ano.

Essas categorias são úteis apenas se suas definições viajarem com o número. “Pronto para processar” é um status de fluxo de trabalho, não todo o trabalho em todos os departamentos. “Impacto financeiro” não especifica subpagamento, sobrepagamento ou valor. “Sem impacto financeiro” ainda pode importar para o registro de um funcionário. Uma consulta pode não ser um erro. O inventário não é, portanto, a contagem de funcionários prejudicados, e sua queda não prova correção ou reparação total.

O mesmo painel relatou transações recebidas e processadas para um período recente, incluindo trabalho manual e automatizado. A produtividade acima da entrada pode reduzir o inventário, mas não mostra qualidade, a menos que correções e reaberturas sejam rastreadas. A automação pode fechar trabalho rotineiro mais rapidamente enquanto casos complexos mais antigos permanecem. Um bom painel combina volume com idade, precisão na primeira vez, contagem de funcionários, retrabalho, efeito financeiro e confirmação de resolução.

A página de operações atuais do PSPC descreve um sistema de folha de pagamento mais amplo que atende mais de 430.000 servidores públicos atuais e antigos em mais de cem organizações, com o Centro de Pagamento servindo diretamente um subconjunto. Relata milhões de contracheques e uma alta taxa de precisão agregada quinzenal. Essa população difere do inventário de transações do painel e da contagem de funcionários afetados do OAG.

A precisão agregada deve ser interpretada como “qual parcela dos pagamentos atendeu à medida de precisão declarada”, não “qual parcela dos funcionários não experimentou problemas”. Uma pessoa pode receber muitos pagamentos corretos após um erro antigo não resolvido. Uma pequena porcentagem de milhões de pagamentos ainda pode representar dano individual grave. A métrica precisa de uma definição, numerador, denominador, período e tratamento de correções.

Amostragem de auditoria, equidade da folha de pagamento e correção individual

O comentário de 2024–25 sobre auditorias financeiras do Auditor Geral relatou que 29 por cento dos funcionários amostrados tiveram um erro no pagamento básico ou interino durante o ano, com 21 por cento ainda necessitando correção em 31 de março de 2025. Esses são resultados de amostra sob um método de auditoria. Eles não podem ser multiplicados por toda a força de trabalho para declarar uma contagem populacional sem design estatístico e análise de confiança.

A auditoria também concluiu que as despesas com folha de pagamento foram apresentadas de forma justa no geral. A justeza das demonstrações financeiras usa materialidade em nível agregado; não certifica o pagamento de cada funcionário. Um governo pode ter despesas de folha de pagamento apresentadas de forma justa enquanto funcionários individuais experimentam erros pessoais materiais. A comunicação institucional deve apresentar ambas as verdades sem usar uma para cancelar a outra.

O OAG atribuiu novamente os erros amostrados a erros de entrada de dados e atrasos de processamento, e não a cálculos incorretos do Phoenix. Essa distinção direciona o reparo para a pontualidade departamental, validação e capacidade, bem como para a substituição do sistema. Não absolve o serviço ponta a ponta. Os funcionários não experimentam fronteiras organizacionais; eles experimentam se o dinheiro certo chegou.

Em 31 de março de 2025, a auditoria descreveu cerca de 349.000 solicitações de ação de pagamento pendentes, com mais da metade com mais de um ano. Também relatou mais de C$ 472 milhões em sobrepagamentos pendentes, uma provisão para contas duvidosas e um recebível líquido menor. O sobrepagamento bruto, a provisão e o valor contábil líquido são medidas contábeis separadas. A idade não prova cobrabilidade ou culpabilidade.

Um painel accountable mostraria evidências de amostra e população separadamente. As métricas operacionais podem cobrir todas as transações registradas, enquanto as auditorias independentes testam amostras e controles. As exceções encontradas por uma auditoria devem alimentar a remediação, e a remediação deve ser retestada. Os leitores públicos devem ser informados quando as definições diferem entre OAG, PSPC, Tesouro do Canadá e sistemas departamentais.

A recuperação de sobrepagamento não deve criar um segundo dano

Um sobrepagamento não é dinheiro gratuito, mas a recuperação não é um simples exercício de cobrança de dívidas quando o sistema do empregador causou ou prolongou o erro. O governo deve estabelecer o valor, período, tratamento fiscal, correções anteriores e janela legal de recuperação. Os funcionários precisam de uma declaração compreensível e uma maneira de contestar o cálculo. Os cronogramas de recuperação devem levar em conta dificuldades e pagamento não resolvido em andamento.

Um briefing do PSPC de 2022 sobre sobrepagamentos do Phoenix usou figuras datadas que combinavam sobrepagamentos administrativos e reais e relatava funcionários identificados, valores criados, valores recuperados e saldos pendentes. Essas medidas não devem ser comparadas diretamente com o recebível das demonstrações financeiras posteriores do OAG sem reconciliar data, população, baixas, ajustes fiscais e definição.

Sobrepagamentos administrativos podem surgir quando um registro é corrigido por meio de transações que criam temporariamente valores de compensação. Um sobrepagamento real é dinheiro que, em última análise, não é devido ao funcionário. Se o sistema não pudesse separá-los de forma confiável em uma data histórica, o relatório deve dizer isso. Rotular o valor combinado como dívida do funcionário exagera a certeza e pode levar a ação de recuperação inadequada.

O subpagamento precisa de um processo igualmente forte, embora não apareça como um recebível do governo. Os funcionários não devem suportar o ônus de reconstruir cada evento faltante. Departamentos e PSPC precisam de detecção proativa: comparar dados de emprego autorizados com pagamento real, identificar mudanças inexplicáveis e contatar as pessoas antes que uma discrepância persista. As consequências de juros, impostos e benefícios devem estar vinculadas à correção subjacente.

O objetivo de controle é uma única declaração de reconciliação visível ao funcionário e à equipe de suporte autorizada. Deve listar eventos de emprego, pagamento esperado, pagamento real, correções, adiantamentos, sobrepagamentos, recuperações e disputas restantes por data. Sistemas separados podem operar por trás da interface, mas a pessoa não deve receber saldos contraditórios de equipes diferentes.

A reparação foi uma família de acordos e reivindicações

O hub de reivindicações e compensação do Tesouro do Canadá organiza vários processos de danos do Phoenix. A própria estrutura mostra por que “reivindicações pagas” é muito vago. Alguma compensação foi creditada automaticamente a funcionários atuais elegíveis; alguns ex-funcionários ou espólios tiveram que se candidatar; alguns remédios cobriram danos gerais; e processos de impacto severo exigiram evidências individualizadas.

O acordo de danos de 2019 cobriu agentes de negociação signatários e forneceu compensação geral incluindo até cinco dias de licença sob seus termos. Também criou rotas para danos financeiros e não financeiros adicionais. Um crédito de licença tem um valor, mas não é o mesmo que dinheiro pago a um ex-funcionário ou danos concedidos após uma reivindicação.

O acordo separado do PSAC de 2020 usou disposições monetárias de danos gerais para funcionários representados elegíveis e abordou a implementação tardia de acordos coletivos. A elegibilidade dependia dos anos fiscais cobertos e do status de emprego. A existência de um acordo não estabelece que toda pessoa afetada pertencia à sua unidade de negociação ou recebeu o valor máximo.

Um memorando de recuperação de 2021 alinhou benefícios especificados para pessoas cobertas pelo acordo anterior. Deve ser relatado como um mecanismo posterior distinto, não mesclado silenciosamente nos termos de 2019. Data do acordo, período de elegibilidade e data de pagamento podem diferir.

O processo de impacto severo aborda categorias como custos financeiros, perda de renda de investimento, licença relacionada a problemas de saúde e dificuldades pessoais ou financeiras severas, sujeito a termos e evidências aplicáveis. Um limite se aplica a muitas categorias, enquanto algumas têm tratamento diferente. Uma reivindicação submetida não é evidência de que o valor reivindicado foi aceito, e um remédio aceito pode incluir restauração de licença em vez de dinheiro.

O relato de reparação deve, portanto, mostrar populações separadamente: creditado automaticamente, elegível para reivindicar, reivindicações recebidas, decididas, aceitas total ou parcialmente, negadas, pagas, reabertas e pendentes. Também deve mostrar o tempo de processamento mediano e da cauda. O propósito não é apenas contábil. O atraso na reparação pode aprofundar o dano original e corroer a confiança mesmo após o pagamento base ser corrigido.

O relato de custos precisa de um mapa de escopo

O relatório de despesas do Phoenix de 2024–25 do Tesouro do Canadá relatou C$ 937,5 milhões em despesas relacionadas ao Phoenix para aquele ano fiscal. A página declara exclusões, incluindo trabalho de RH e pagamento da Próxima Geração, danos e reivindicações da Coroa, e custos de oportunidade. É um total anual com escopo, não o custo cumulativo do Phoenix desde 2009.

Diferentes questões de custo precisam de diferentes livros-razão. O orçamento original de implementação responde o que o projeto foi autorizado a gastar. A despesa anual de estabilização responde o que o governo gastou em um ano sob categorias declaradas. Danos relatam obrigações de compensação. As provisões para sobrepagamentos são estimativas de balanço, não despesas do programa. O tempo de pessoal departamental e o trabalho político atrasado podem ser custo de oportunidade. As estimativas do Dayforce dizem respeito a um programa sucessor.

A estimativa de custo de substituição de 2019 do Escritório do Diretor Parlamentar de Orçamento foi uma estimativa de cenário baseada em suposições disponíveis na época. Não era uma adjudicação de compra, orçamento aprovado do Dayforce ou fatura real. Compará-la com estimativas posteriores pode mostrar como o escopo e as informações mudaram, mas apenas se as suposições e a base de preço forem retidas.

Os controles de custo devem atribuir cada dólar a programa, organização, ano fiscal e propósito: operar, estabilizar, limpar inventário, compensar, recuperar, projetar substituição, departamento de transição ou aposentar legado. Custos compartilhados precisam de regras de alocação. A comunicação pública deve reconciliar totais anuais com valores cumulativos e explicar mudanças. As economias devem ser relatadas líquidas do trabalho departamental deslocado e dos processos manuais em andamento.

Valor pelo dinheiro não é o lançamento mais barato. É o custo de entregar pagamento correto e pontual com controles sustentáveis. Uma execução paralela mais cara pode ser um bom valor se prevenir a migração de erros e danos aos funcionários. Por outro lado, estender sistemas antigos e novos indefinidamente pode criar custos duplicados sem reduzir o risco. Os tomadores de decisão precisam de critérios de saída explícitos, em vez de uma declaração impulsionada pelo cronograma.

A Goss Gilroy foi um estudo de lições, não uma auditoria

O relatório de lições aprendidas da Goss Gilroy revisou a iniciativa de 2008 a abril de 2016 por meio de revisão de documentos e consultas. O relatório afirma expressamente que não é uma auditoria e que suas opiniões e conclusões pertencem à Goss Gilroy, não necessariamente ao governo. Essa isenção de responsabilidade é um limite substantivo de evidência.

O estudo continua valioso. Organizou lições em torno de governança, supervisão, gerenciamento de mudanças, capacidade, teste e cultura de projeto. A consulta pode revelar como os participantes entenderam a pressão e a tomada de decisão, incluindo informações que os documentos formais do projeto subestimam. Mas não usa o mandato estatutário do Auditor Geral ou método de garantia, e suas observações baseadas em entrevistas não devem ser apresentadas como fato julgado.

Os relatórios do OAG, comitês parlamentares, briefings departamentais e o estudo da Goss Gilroy podem ser lidos juntos por meio de uma matriz de mandato. Para cada proposição, a matriz declara se a fonte auditou registros, ouviu depoimentos, descreveu a política departamental, relatou visões dos participantes ou emitiu uma recomendação. A concordância entre fontes com mandatos diferentes pode fortalecer uma conclusão; a discordância deve ser visível, não suavizada.

Essa abordagem protege tanto a accountability quanto a justiça. Impede que uma observação de consultoria se torne uma constatação legal contra um indivíduo. Também impede que uma instituição descarte uma lição operacional recorrente apenas porque não foi produzida por meio de uma auditoria. A resposta correta é testar a observação contra registros e evidências operacionais atuais.

Atividade de estabilização não é o mesmo que resolução

A estratégia integrada de RH e pagamento do PSPC combina estabilização atual do Phoenix, redução de backlog e trabalho futuro do Dayforce. O enquadramento integrado é sensato porque o trabalho não resolvido e o design de substituição interagem. Também cria um risco de relato: o progresso em um fluxo pode ser confundido com sucesso em outro.

Uma atualização de progresso de março de 2026 disse que uma alta parcela de uma população-alvo de casos antigos foi processada e que as transações com mais de um ano caíram. “Casos-alvo” não é o inventário completo, e “processado” não prova por si mesmo que todo funcionário concordou com o resultado ou recebeu reparação consequencial. O denominador e a seleção do alvo devem permanecer visíveis.

A estabilização deve ter resultados em camadas. Primeiro, processar a transação. Segundo, verificar o pagamento resultante e os registros downstream de imposto, pensão e benefícios. Terceiro, confirmar com o funcionário que o problema está resolvido ou registrar uma disputa restante. Quarto, conectar a pessoa à compensação aplicável. Quinto, testar se o controle raiz mudou para que o tipo de caso não se repita.

A redução de inventário pode, de outra forma, recompensar o fechamento em vez da correção. As equipes sob pressão de volume podem dividir ou combinar trabalho de forma diferente, alterar definições de status ou fechar uma consulta enquanto uma transação financeira permanece. Amostragem de qualidade independente, taxas de reabertura e confirmação do funcionário restringem esse risco. O relato de casos mais antigos impede que a melhoria agregada esconda uma cauda persistente.

O sistema estabilizado também precisa de resiliência operacional até a aposentadoria. Patches de segurança, suporte do fornecedor, calendários de folha de pagamento, mudanças de acordo coletivo e funcionários experientes não podem ser negligenciados porque o Dayforce está planejado. O período de transição pode ser a fase de maior risco: as pessoas aprendem uma nova plataforma enquanto mantêm o Phoenix e limpam o trabalho antigo. Os modelos de capacidade devem incluir ambos os sistemas e a preparação departamental.

O planejamento do Dayforce deve ganhar o direito de lançar

O relatório de viabilidade do Dayforce descreve pesquisa, configuração e teste usados para avaliar se a plataforma comercial poderia atender às necessidades federais de RH e pagamento. O trabalho de viabilidade pode reduzir a incerteza, mas dados simulados e cenários selecionados não provam produção precisa de folha de pagamento em todos os departamentos, acordos coletivos e exceções legadas.

O OAG de 2026 relatou que a transformação do Dayforce permaneceu em planejamento até junho de 2027 e citou um total preliminar acima de C$ 4,2 bilhões que excluía custos importantes de transição departamental. Também alertou que erros não resolvidos do Phoenix poderiam ser carregados para o novo sistema e que a simplificação das regras de pagamento permanecia incompleta. Durante e após a auditoria, o programa encurtou seu cronograma. Uma data mais rápida aumenta o ônus da prova; não o reduz.

A página de monitoramento de compromissos do PSPC descreve marcos de configuração e teste. Marcos prospectivos são planos. A comunicação deve usar “espera”, “planeja” ou “visa” até que o evento ocorra e as evidências passem. Um teste paralelo planejado não é uma reconciliação concluída.

O portão de lançamento deve exigir folha de pagamento paralela semelhante à produção para departamentos representativos e casos difíceis por ciclos suficientes para incluir retroatividade, benefícios e efeitos de fim de ano. Cada diferença deve ser classificada, possuída e resolvida. O teste deve comparar pagamento esperado, saída do Phoenix, saída do Dayforce e registro real do funcionário, em vez de assumir que o Phoenix é sempre a referência correta.

Os controles de migração devem separar dados mestre limpos de casos não resolvidos. As transações abertas precisam de uma disposição: resolver antes da migração, migrar com histórico completo e proprietário nomeado, ou reter em um processo legado controlado. Os saldos de sobrepagamentos, adiantamentos, licenças, impostos e pensões precisam de reconciliação. Os funcionários devem poder ver qual sistema é o proprietário de seu problema durante a transição.

A prontidão departamental deve ser evidenciada de forma independente. Cada organização precisa de pessoal treinado, processos de RH mapeados, resultados de qualidade de dados, testes de interface, rotas de suporte e contingência. Um programa central deve amostrar e desafiar as autoavaliações. A autoridade de parada deve ser capaz de atrasar um departamento ou onda sem ser anulada apenas porque um cronograma público foi anunciado.

Um mapa de controle para prontidão e reparação da folha de pagamento

Um sistema de accountability reparado pode ser organizado em oito domínios. Os proprietários de requisitos mantêm o catálogo de regras de pagamento e aprovam a simplificação. Os proprietários de compras registram o trabalho do fornecedor, conselho, aceitação e defeitos. As equipes técnicas configuram e testam. Os departamentos são proprietários de eventos de RH oportunos. O PSPC é proprietário das operações do Centro de Pagamento e do serviço ponta a ponta. O Tesouro do Canadá é proprietário da política do empregador e das estruturas de danos. Os proprietários financeiros reconciliam a folha de pagamento e os sobrepagamentos.

Uma autoridade de lançamento independente decide se as evidências apoiam a transição.

Cada domínio precisa de prova observável. Os requisitos são rastreados até a configuração e os testes. As tarefas do fornecedor têm registros de aceitação. Os eventos departamentais atendem aos limites de pontualidade e validação. A capacidade do Centro de Pagamento excede a demanda prevista com contingência. As métricas de inventário reconciliam transações, casos, solicitações e funcionários afetados. Subpagamentos e sobrepagamentos têm definições datadas. Os livros-razão de reparação conectam erro de pagamento, dano consequencial, decisão e pagamento.

O mapa de controle deve preservar a dignidade do funcionário. Os funcionários não devem precisar repetir a mesma história para várias equipes ou inferir qual organização é a proprietária do problema. Um gerente de caso pode coordenar entre RH departamental, Centro de Pagamento, funções de imposto, pensão e reivindicações, enquanto cada um mantém responsabilidade formal. As comunicações devem declarar o que é conhecido, o que permanece em disputa, a próxima ação e a data esperada.

A automação deve apoiar, não obscurecer, a accountability. Mecanismos de regras podem validar dados; fluxo de trabalho pode encaminhar exceções; análises podem identificar falhas recorrentes; e painéis podem mostrar o envelhecimento. Toda decisão automatizada deve preservar dados de origem, versão da regra, alterações de status e sobreposições humanas. Um código fechado não deve apagar as evidências necessárias para auditoria ou reivindicação.

A garantia independente deve continuar após o lançamento. Os auditores devem amostrar funcionários, não apenas transações, e seguir seus registros entre sistemas. Os representantes dos funcionários devem ver medidas agregadas de erro e reparação. Os departamentos devem ser comparados quanto à pontualidade dos dados sem transferir toda a culpa para o processamento central. Os resultados devem ser publicados com definições estáveis o suficiente para mostrar tendências.

Conclusão

O Phoenix tornou-se um teste de accountability em compras públicas porque o governo comprou e configurou software enquanto redesenhavam o serviço que o cercava. Funções ausentes, testes incompletos, especialização reduzida, propriedade fragmentada de dados e portão de lançamento fraco interagiram. O papel contratado da IBM importa, mas o PSPC reteve a autoridade para definir o trabalho, aceitar o escopo e implantar. A atribuição precisa é essencial para o aprendizado.

O registro de impacto requer igual precisão. Funcionários são pessoas; transações, solicitações e casos são unidades de trabalho. Subpagamento, sobrepagamento, backlog, precisão e amostras de auditoria têm denominadores diferentes. Despesa anual, estabilização cumulativa, danos e estimativas de substituição têm limites de custo diferentes. Um inventário em queda pode ser progresso sem provar que toda pessoa foi paga corretamente e compensada.

A reparação é parte do desempenho do sistema, não um pensamento jurídico externo. Suporte de emergência, danos gerais, licença, pagamentos únicos, pagamentos de recuperação e reivindicações de impacto severo precisam de medidas transparentes de elegibilidade, processamento e resultado. Corrigir o pagamento base meses ou anos depois não repara automaticamente as consequências fiscais, de crédito, saúde ou tempo perdido.

O Dayforce oferece uma chance de construir controles mais fortes, mas a chance não é prova. Configuração, viabilidade e testes paralelos planejados devem culminar em evidências reproduzíveis em eventos reais de RH, regras de pagamento, departamentos e funcionários. Registros não resolvidos do Phoenix devem ter proprietários nomeados e caminhos de migração reconciliados. O portão de lançamento independente deve ser capaz de dizer não.

O padrão durável é simples: o governo não deve declarar um sistema de folha de pagamento pronto até que possa mostrar quem foi testado, o que diferiu, como as exceções foram resolvidas, como os funcionários serão protegidos e quem pode interromper a implantação. Essa evidência transforma a modernização de um cronograma em um serviço público accountable.