Phoenix превратил готовность платёжной системы и компенсации сотрудникам в проверку подотчётности госзакупок

Кратко

• Phoenix совместил замену программного обеспечения с централизацией обслуживания, поэтому готовность должна была охватывать всю цепочку от кадровых событий до выплат.Инициатива заменила десятилетиями работавший платёжный движок и одновременно перенесла расчёт вознаграждений из ведомств в новый Pay Centre. Вотчёте Генерального аудитора о внедрении за 2018 годуказано, что критические функции были исключены, тестирование сокращено, предупреждения о неготовности проигнорированы, а система развёрнута двумя волнами в феврале и апреле 2016 года. Расчётный движок мог выглядеть технически работоспособным, пока ведомства, данные, процедуры и мощности службы оставались неготовыми.

• Роль IBM должна описываться через контракт и санкционированные работы, а не через моральную притчу об одном вендоре.Компанию выбрали интегратором, чтобы она помогала проектировать, дорабатывать, интегрировать и внедрять систему на базе PeopleSoft. Public Services and Procurement Canada контролировало управление проектом, деловые решения, санкционирование задач и запуск. Работа вендора — законный предмет подотчётности, но официальные документы не подтверждают, что все решения по объёму, тестированию, мощностям и запуску можно возложить на одну IBM.

• Первые антикризисные показатели смешивали людей, деньги и единицы работы, которые нельзя сводить к одной статистике.Вотчёте Генерального аудитора за 2017 год о проблемах с выплатамиприведены данные о количестве сотрудников и суммах недоплат и переплат на конкретную дату, тогда как в других документах считали необработанные запросы о выплатах. У одного сотрудника может быть несколько операций или дел. Запрос может быть информационным, нефинансовым или нерешённым — сам по себе он не доказывает такой же ущерб, как неполученная зарплата.

• Совокупная точность может сочетаться с индивидуальными трудностями и старым остатком.Высокий процент корректно обработанных выплат среди миллионов платежей не доказывает, что каждый сотрудник вовремя получил правильную сумму. Выборку аудита с ошибками точно так же нельзя механически распространять на весь штат. Для точности, своевременности, возраста необработанных операций, пострадавших сотрудников, возврата переплат и компенсаций нужны отдельные знаменатели.

• Работа с людьми не была единой программой.Экстренные авансы в счёт зарплаты, возмещение расходов, общие компенсации за ущерб, дополнительные дни отпуска, единовременные выплаты, механизмы выравнивающих выплат и заявки по тяжёлым последствиям подчинялись разным полномочиям, профсоюзным группам, периодам права на выплаты и процессам. Автоматическая компенсация — не поданная заявка; поданная заявка — не принятая; принятая заявка — не обязательно деньги, выплаченные в тот же день. Учёт компенсаций сотрудникам должен вестись с той же дисциплиной, что и платёжный учёт.

• Суммарные затраты требуют явных границ.Первоначальные бюджеты проекта, прогнозы экономии, ежегодные расходы, связанные с Phoenix, совокупные затраты на стабилизацию, компенсации, резервы по переплатам, работа ведомств по переходу и сметы программы Dayforce отвечают на разные вопросы. Простое сложение этих цифр без корректировки по периодам и охвату учитывает одни и те же работы дважды и скрывает исключения. Оценка стоимости замены — не счёт, а годовые расходы — не совокупная стоимость за всё время.

• Goss Gilroy и Генеральный аудитор делали разную работу.В заказанном исследовании извлечённых уроков прямо сказано, что оно не является аудитом и что выводы принадлежат консалтинговой фирме. Это ценный консультативный материал о культуре, управлении и управлении изменениями, но его нельзя цитировать как вывод Генерального аудитора. Обозначение мандата — часть фактической точности.

• Dayforce остаётся программой подготовки, а не доказательством того, что Phoenix исправлен.Оценка осуществимости, настройка, тесты на макетных данных, запланированные параллельные прогоны и сокращённый график внедрения — свидетельства активности и намерений. Вотчёте Генерального аудитора за 2026 год о модернизацииговорилось о возможности устранить риски, пока планирование было неполным. Для успеха нужны сверенные результаты, приближённые к реальной эксплуатации, контролируемый перенос, готовность ведомств, восстановление прав сотрудников и независимо действующий механизм остановки запуска.

Платёжная система и непрерывность государственной службы

Выплату зарплаты часто называют тыловой функцией, но для сотрудников это регулярно повторяющееся публичное обязательство. Пропущенный или ошибочный платёж может сказаться на аренде, ипотеке, продуктах, уходе за детьми, налогах, пособиях, пенсионных взносах и кредитной истории. Для работодателя та же ошибка означает дополнительную работу, бухгалтерские корректировки, обязательства по возврату средств и последствия для трудовых отношений.

Когда работодатель — федеральное правительство, непрерывность выплат влияет и на легитимность институтов: государство должно показать, что способно исполнять самое рутинное обязательство перед людьми, которые оказывают государственные услуги.

Граница контроля начинается до любых расчётов. Ведомство создаёт или меняет кадровое событие: назначение, перевод, временное исполнение обязанностей, отпуск, сверхурочные, надбавку, обновление коллективного договора, увольнение или выход на пенсию. Событие нужно санкционировать, корректно внести и вовремя передать. Затем правила оплаты определяют, что причитается. Pay Centre может запросить документы или ручную обработку. Phoenix рассчитывает и производит выплаты, но последующие процессы — исправление, налоги, пенсии, пособия и учёт — могут зависеть от той же записи.

Эта цепочка объясняет, почему диагноз «ошибка в программном обеспечении» слишком узок. Расчётный движок может работать по настроенным правилам, тогда как исходное событие поступило поздно или с ошибкой. Корректная операция может стоять в очереди за старыми. Ведомственная HR-система может использовать другой процесс или стандарт данных. Коллективный договор может требовать массовых обновлений. Исправление может порождать новую операцию и взаимодействовать с прежней переплатой. У каждой передачи работы должен быть владелец, стандарт обслуживания, статус исключения и маршрут эскалации.

Поэтому модернизация объединила как минимум четыре изменения: технологию, операционную модель, кадровые мощности и организационное поведение. Правительство заменило Regional Pay System, централизовало обслуживание многих ведомств и сократило местные мощности по расчёту вознаграждений, одновременно попросив организации изменить кадровые практики. Решение о готовности должно было ответить, работают ли все четыре изменения вместе в реальном масштабе. Тест, показавший, что программное обеспечение может сформировать платёжный документ, был необходим, но недостаточен.

Непрерывность в государственном секторе требует и запасного варианта. Если новая система или централизованная служба не может обработать правомерное событие, сотрудникам всё равно нужен своевременный доход. Экстренные авансы снижают немедленный ущерб, но создают работу по сверке и возврату средств. Устойчивый план действий на случай сбоя определяет, кто может санкционировать временные выплаты, как они облагаются налогом и учитываются, когда проводится сверка и как не допустить, чтобы сотрудника просили вернуть сумму, возникшую из-за обходного решения, до того как исправлена основная выплата.

Экономическое обоснование: экономия, централизация и внедрение системы

Инициатива Transformation of Pay Administration (преобразование системы администрирования выплат) началась в 2009 году. Предполагалось, что она будет обслуживать около 290 000 сотрудников более чем ста организаций, заменит прежнюю платёжную систему и централизует администрирование вознаграждений. В публичном обосновании фигурировала регулярная экономия за счёт сокращения должностей, связанных с расчётом вознаграждений, и более стандартизированного обслуживания. Сами по себе эти цели не были неразумными, но они создавали давление на сроки и бюджет, которое могло конфликтовать с данными о готовности.

Изначальная проблема управления заключалась в том, что получение выгоды было увязано с преждевременным сокращением мощностей. Если прогнозируемая экономия зависит от ликвидации опытных должностей до того, как новая организация и система продемонстрируют стабильную пропускную способность, программа расходует свой резерв. Сотрудники, которые разбираются в коллективных договорах, нестандартных случаях и ведомственных практиках, не взаимозаменяемы с функциями программного обеспечения. Их знания могут быть наиболее ценны во время переноса, когда появляются дефекты и исключения в данных.

В аудите 2018 года фигурировал утверждённый бюджет проекта около 310 млн канадских долларов и ожидаемая ежегодная экономия в 70 млн. Эти цифры относятся к первоначальной инициативе и её обоснованию. Их нельзя напрямую сравнивать с более поздними годовыми расходами на стабилизацию или многолетней сметой Dayforce без объяснения охвата, инфляции, ведомств и эксплуатационных расходов. Бюджет — это разрешение и рамки планирования; фактическая стоимость требует реальных расходов; обещанная экономия — измеренного базового уровня и достигнутого сокращения.

Управление экономическим обоснованием должно включать нефинансовые пороги качества услуг. Программа не должна объявлять об успехе только потому, что уложилась в капитальный бюджет или закрыла проект внедрения. Требуемые результаты должны включать корректные и своевременные выплаты, возраст необработанных операций, скорость ответа на обращения, трудности сотрудников, нагрузку на ведомства, ручное вмешательство и надёжность контроля. Если экономия достигается за счёт переноса работы или задержек на ведомства и сотрудников, публичный учёт должен показывать этот перенос.

Надёжный процесс утверждения предусматривал бы поэтапное получение выгоды. Опытные должности сохранялись бы до тех пор, пока сквозная работа не была бы продемонстрирована на обычных выплатах, сложных изменениях, сезонных пиках, коллективных договорах и переводах сотрудников. Экономию признавали бы только после того, как независимые доказательства показали бы, что система и Pay Centre способны выдержать объём. Резерв финансировался бы как требование к услуге, а не как свидетельство того, что команда проекта не уверена в себе.

Подотчётность закупок: санкционированные задачи и полномочия заказчика

IBM выиграла открытый конкурс 2011 года на поддержку проектирования, доработки, интеграции и внедрения системы Phoenix на базе PeopleSoft. Контрактная модель использовала санкционирование задач, через которое правительство определяло работы. Вотчёте Комитета по публичным счетам за 2018 год о создании и внедрении Phoenixотражены выводы Генерального аудитора и ответ институтов. Это материал об управлении и показаниях, а не гражданско-правовое решение о распределении ущерба между Короной и вендором.

Различие между интегратором и владельцем проекта критически важно. Вендор отвечает за качественную поставку принятых работ, точные консультации, эскалацию известных ограничений и соблюдение контракта. Заказчик остаётся ответственным за бизнес-требования, утверждение объёма работ, критерии приёмки, финансирование, операционную готовность и запуск. Модель санкционирования задач может сделать эти границы видимыми, если каждое изменение фиксирует, кто его запросил, какие доказательства его поддерживали, как изменился риск и кто принял результат.

Вматериалах 81-го заседания PACPзафиксированы показания PSPC о том, что IBM выполнила порученную ей работу и что ведомство выступало руководителем проекта, а IBM — интегратором. Эти показания нужно атрибутировать, а не считать независимым выводом об отсутствии ответственности вендора. Однако они опровергают упрощённое утверждение, что IBM в одностороннем порядке контролировала требования и решение о запуске.

Впереходных материалах ведомства за 2022 годпо-прежнему описывалась роль IBM в поддержке и стабилизации Phoenix. Ведомственный брифинг полезен для понимания контрактного и операционного контекста, но остаётся версией самого ведомства. Затраты вендора, результаты работ, дефекты и решения следует проверять по контрактам, санкционированию задач, актам приёмки и независимым техническим данным.

Исправление системы закупок требует реестра решений. По каждому исключённому функционалу, компромиссу в конфигурации, отложенному дефекту и ограничению тестирования нужно указывать рекомендацию вендора, решение заказчика, операционного владельца, затронутый круг людей и остаточный риск. Орган, принимающий решение о запуске, должен быть назван и достаточно независим, чтобы остановить развёртывание. Коммерческое давление сроков не должно позволять переопределять проваленный критерий приёмки как доработку после запуска без явной ответственности руководства и владельца услуги.

Требования: правила оплаты, данные и процедуры работы

Федеральная оплата определяется законами, коллективными договорами, классификациями, надбавками, отпусками, пенсиями, налогами и кадровыми событиями. Сложность не оправдывает провал, но меняет инженерную задачу. Требования должны переводить правовые и политические правила в настроенные расчёты, валидацию ввода, рабочие процессы, сервисные процедуры и обработку исключений. Упрощение требует согласия работодателей, профсоюзных представителей, ведомств и владельцев политик; технологическая команда не может молча упростить правило, просто опустив его.

Внедрение Phoenix удаляло или откладывало функции, чтобы уложиться в бюджет и сроки. Часть работы, которую раньше поддерживали прежняя система или ведомственные консультанты, стала ручной или потребовала новых процедур. Когда функциональность сокращают, программа должна учесть работу, переданную людям, обеспечить кадрами принимающую функцию и протестировать обходное решение. Пробел не закрывается от того, что существует ручная инструкция.

Владение данными не менее важно. Ведомства остаются ответственными за своевременную и точную кадровую информацию, а централизованная платёжная служба обрабатывает множество порождаемых операций. Системе нужны валидация при вводе, понятные сообщения об отклонении, выявление дубликатов и общий обзор статусов. Если ведомство видит только то, что событие отправлено, а Pay Centre видит незавершённое дело, механизмом сверки становится сам сотрудник.

Модернизация правил оплаты должна дать контролируемый каталог. У каждого правила должны быть основание, объяснение простым языком, машиночитаемая логика, примеры, крайние случаи, тест-кейсы и даты вступления в силу. Изменения требуют контроля версий и регрессионного тестирования. Каталог должен разделять правила, которые Phoenix рассчитывает автоматически, и те, что требуют ручного вмешательства. Отчётность об ошибках должна указывать, была ли причина в исходных данных, конфигурации, расчёте, задержке обработки или неоднозначности политики.

Такая классификация предотвращает типичную ошибку атрибуции. В более позднем финансовом аудите Генерального аудитора многие ошибки в выборке — в основной оплате и оплате за исполнение обязанностей — были связаны с вводом данных и задержками обработки, а не с ошибочным расчётом Phoenix. Это не делает систему успешной: платёжная служба включает контроль данных и процессов. Но это делает средство исправления более точным. Замена одного движка не может исправить запоздалые кадровые события или нехватку мощностей обработки.

Тестирование должно было проследить путь человека через всю систему

Тестирование платёжной платформы требует большего, чем проверка изолированных расчётов. Сквозное тестирование начинается с санкционированного кадрового события, проходит через ведомственные системы и интерфейсы, применяет нужное правило, попадает в Pay Centre, когда требуется ручная работа, формирует платёж и бухгалтерскую проводку, обновляет налоговые и пенсионные записи и показывает статус, понятный и службе поддержки, и сотруднику. Исправления и сторнирования тоже нужно тестировать.

Аудит 2018 года установил, что PSPC не протестировало Phoenix полностью перед запуском и отменило запланированную пилотную фазу. По мере сжатия сроков тестирование ограничивали. Ведомства сообщали о готовности в основном через самооценку, при том что известные проблемы оставались. Главный вопрос был не в том, существовали ли тест-сценарии, а отражали ли результаты реальный объём работы, сложные случаи, настоящие интерфейсы, обученный персонал и миграцию двумя волнами.

Доказательства готовности должны быть состязательными. Тестировщикам нужны случаи, которые скорее всего провалятся: переводы между ведомствами, оплата временного исполнения обязанностей, ретроактивные коллективные договоры, отпуск без сохранения содержания, увольнения, несколько надбавок, создание условий для сотрудников с инвалидностью, удержания по исполнительным листам и возврат переплат. Систему нужно тестировать на неполных и противоречивых данных. Нагрузочные тесты должны включать пиковые объёмы и накопленную работу по исправлениям, а не только чистые новые операции.

Операционная готовность — это расчёт мощности. Спрогнозируйте входящую работу по типам, долю автоматизации, время обработки, штат, завершение обучения, производительность в период освоения и переделки. Сравните мощность с новым спросом плюс перенесённым остатком. Если модель предполагает, что новое программное обеспечение немедленно повышает производительность, независимый рецензент должен потребовать доказательств. Если опытные консультанты уже ушли, план на случай сбоя должен учитывать утраченную экспертизу.

Контрольная точка запуска должна иметь бинарные критерии остановки: критические функции завершены или протестировано должным образом укомплектованное обходное решение; нет нерешённых дефектов первого уровня серьёзности; сверка в пределах допуска; ведомственные интерфейсы пройдены; процедуры поддержки и экстренных выплат отработаны; приватность и безопасность приняты; достаточно параллельных результатов, показывающих корректные исходы. Руководство может принять остаточный риск, но в акте приёмки должны быть указаны круг сотрудников и средство исправления, если риск реализуется.

Волны 2016 года превратили слабую готовность в ущерб для сотрудников

Phoenix развернули двумя волнами в феврале и апреле 2016 года. Примерно тогда же произошли изменения в централизованном обслуживании. Сотрудники стали сообщать о задержках, невыплатах, недоплатах и переплатах, накапливалась необработанная работа. Запуск стал спусковым крючком, потому что вывел объединённую систему в реальный масштаб. Корень — в более ранних решениях об объёме работ, тестировании, штате, обучении, готовности ведомств, данных и управлении.

В аудите 2017 года сообщалось, что в июне 2017 года правительство задолжало около 228 млн канадских долларов 51 000 сотрудников, а 59 000 сотрудников задолжали правительству около 295 млн. Это показатели на конкретную дату, полученные по методике аудита. Они не означают 110 000 уникальных людей, потому что группы могут пересекаться, и не равны всему ущербу, всем позднейшим исправлениям или всем операциям. Вдокладе № 42 Комитета по публичным счетамзафиксирован отдельный показатель — 520 000 необработанных запросов о выплатах по состоянию на 18 октября 2017 года.

Это различие — сотрудники против запросов — фундаментально. Один человек может иметь недоплату, переплату, налоговую проблему и несколько ожидающих изменений. Один запрос может породить несколько операций. Дело может объединять связанную работу или представлять собой обращение в службу поддержки. В отчётности никогда не следует писать «520 000 сотрудников», если в источнике сказано «запросы». И сокращение числа операций нельзя описывать как восстановление прав такого же количества людей.

Недоплаты и переплаты измеряются асимметрично. Переплата после обнаружения создаёт для правительства идентифицируемую дебиторскую задолженность, хотя исторические записи смешивали административные и фактические переплаты. Недоплата не всегда автоматически выявлялась по всей совокупности; она могла оставаться скрытой, пока её не находил сотрудник, ведомство или консультант по вознаграждениям. Вбрифинге PSPC для комитета в 2020 году о Phoenixпризнавались ограничения в разделении типов переплат и точном отслеживании недоплат.

Воздействие на сотрудника нельзя свести к чистым деньгам. Позднейшее исправление может восстановить валовую выплату, но оставить последствия для процентов, налогов, пособий, кредитной истории, времени и здоровья. Переплата может вызывать страх возврата денег, даже если сотрудник сразу сообщил о проблеме. Подотчётность требует фиксировать дату, когда сотрудник впервые потерял доступ к корректной выплате, дату получения временной поддержки, дату исправления основной записи и дату урегулирования сопутствующего ущерба.

Текущий остаток — это работа, а не число пострадавших

Напанели показателей Pay Centreсообщалось о 198 000 операций, готовых к обработке, по состоянию на 17 июня 2026 года. Они делились примерно на 133 000 операций с финансовым эффектом, 62 000 без финансового эффекта или связанных с общими запросами и 3 000, связанных с коллективными договорами. Отдельно разделялась работа в пределах стандартов обслуживания, за их пределами менее года и старше года.

Эти категории полезны только вместе со своими определениями. «Готово к обработке» — это статус в рабочем процессе, а не вся работа во всех ведомствах. «Финансовый эффект» не уточняет, недоплата это, переплата или сумма. «Без финансового эффекта» всё равно может иметь значение для записи сотрудника. Обращение может не быть ошибкой. Поэтому остаток — это не число пострадавших сотрудников, и его снижение не доказывает полного исправления или компенсаций.

На той же панели приводились поступившие и обработанные операции за недавний период, включая ручную и автоматизированную работу. Пропускная способность выше поступления может сокращать остаток, но не показывает качество, если не отслеживаются исправления и повторные открытия. Автоматизация может быстрее закрывать рутинную работу, тогда как старые сложные дела остаются. Хорошая панель сочетает объём с возрастом, точностью с первого раза, числом сотрудников, переделками, финансовым эффектом и подтверждением урегулирования.

Настранице PSPC о текущей работеописана более широкая платёжная система, обслуживающая более 430 000 нынешних и бывших госслужащих более чем ста организаций, при этом Pay Centre напрямую обслуживает часть из них. Сообщается о миллионах платёжных документов и высоком совокупном показателе точности за двухнедельные периоды. Эта совокупность отличается от остатка операций на панели и от показателя OAG по пострадавшим сотрудникам.

Совокупную точность следует понимать как «какая доля выплат соответствует заявленному критерию точности», а не «какая доля сотрудников не столкнулась с проблемами». Человек может получать много корректных выплат после нерешённой старой ошибки. Небольшой процент от миллионов выплат всё равно может означать серьёзный ущерб для конкретного человека. У показателя должны быть определение, числитель, знаменатель, период и порядок учёта исправлений.

Выборка аудита, достоверность отчётности и корректность индивидуальных выплат

Вкомментарии Генерального аудитора о финансовых аудитах за 2024–25 годысообщалось, что у 29 % попавших в выборку сотрудников в течение года была ошибка в основной оплате или оплате за исполнение обязанностей, а 21 % всё ещё требовалось исправление на 31 марта 2025 года. Это результаты выборки по методике аудита. Их нельзя механически умножать на весь штат, чтобы объявить число пострадавших, без статистического дизайна и анализа достоверности.

Аудит также заключил, что расходы на оплату труда в целом представлены достоверно. Достоверность финансовой отчётности использует существенность на агрегированном уровне; она не подтверждает выплату каждому сотруднику. Правительство может достоверно отражать расходы на оплату труда, тогда как отдельные сотрудники сталкиваются с существенными личными ошибками. Институциональная отчётность должна показывать обе истины, не позволяя одной отменять другую.

OAG снова объяснил ошибки в выборке ошибками ввода данных и задержками обработки, а не неверными расчётами Phoenix. Это различие направляет исправление на своевременность, валидацию и мощности ведомств, а также на замену системы. Оно не снимает ответственность со сквозной услуги. Сотрудники не видят организационных границ; они видят, пришли ли правильные деньги.

По состоянию на 31 марта 2025 года аудит описывал около 349 000 необработанных запросов на действия по выплатам, более половины из которых старше года. Также сообщалось о более чем 472 млн канадских долларов непогашенных переплат, резерве по сомнительным долгам и меньшей чистой дебиторской задолженности. Валовая сумма переплат, резерв и чистая балансовая стоимость — это отдельные учётные показатели. Возраст не доказывает ни взыскиваемость, ни вину.

Подотчётная панель показывала бы данные выборки и совокупности отдельно. Операционные показатели могут охватывать все зарегистрированные операции, а независимые аудиты проверяют выборки и контроли. Исключения, найденные аудитом, должны направляться на исправление, а исправление — проверяться повторно. Читатели должны знать, когда определения различаются в системах OAG, PSPC, Treasury Board и ведомств.

Возврат переплат не должен создавать второй ущерб

Переплата — это не бесплатные деньги, но возврат — не простая процедура взыскания долга, когда ошибку вызвала или затянула система работодателя. Правительство должно установить сумму, период, налоговый режим, прежние исправления и законный срок взыскания. Сотрудникам нужна понятная выписка и возможность оспорить расчёт. Графики возврата должны учитывать материальное положение и сохраняющиеся нерешённые выплаты.

Вбрифинге PSPC 2022 года о переплатах Phoenixиспользовались показатели на конкретную дату, объединявшие административные и фактические переплаты; сообщалось о выявленных сотрудниках, возникших суммах, возвращённых суммах и остатках задолженности. Эти показатели нельзя напрямую сравнивать с более поздней дебиторской задолженностью в финансовой отчётности OAG без сверки даты, совокупности, списаний, налоговых корректировок и определений.

Административные переплаты могут возникать, когда запись исправляется через операции, временно создающие встречные суммы. Фактическая переплата — это деньги, которые сотруднику в итоге не причитались. Если система не могла надёжно разделить их на некоторую историческую дату, в отчёте об этом нужно сказать прямо. Называя объединённую сумму долгом сотрудника, вы преувеличиваете определённость и можете спровоцировать неправомерное взыскание.

Недоплаты требуют не менее сильного процесса, хотя они не отражаются как дебиторская задолженность правительства. Сотрудники не должны нести бремя реконструкции каждого пропущенного события. Ведомствам и PSPC нужен проактивный контроль: сравнивать санкционированные кадровые данные с фактическими выплатами, выявлять необъяснимые изменения и связываться с людьми, пока расхождение не закрепилось. Последствия для процентов, налогов и пособий должны быть связаны с основным исправлением.

Цель контроля — единая сверка, видимая сотруднику и уполномоченным сотрудникам поддержки. В ней должны быть перечислены кадровые события, ожидаемая выплата, фактическая выплата, исправления, авансы, переплаты, возвраты и оставшиеся споры с датами. За интерфейсом могут работать разные системы, но человек не должен получать противоречивые остатки от разных команд.

Компенсации: семейство соглашений и заявок

Вцентре Treasury Board по заявкам и компенсациямсобраны несколько процессов возмещения ущерба от Phoenix. Сама структура показывает, почему «выплаченные заявки» — слишком расплывчатая формулировка. Часть компенсаций зачислялась автоматически подходящим под условия нынешним сотрудникам; часть бывших сотрудников или наследников должна была подавать заявления; некоторые меры покрывали общую компенсацию ущерба; процедуры по тяжёлым последствиям требовали индивидуальных доказательств.

Всоглашении 2019 года о возмещении ущербаучаствовали подписавшие его профсоюзные организации; оно предусматривало общую компенсацию, включая до пяти дней отпуска на его условиях. Оно также создало маршруты для дополнительного финансового и нефинансового ущерба. Дни отпуска имеют ценность, но это не то же самое, что деньги, выплаченные бывшему сотруднику, или компенсация, присуждённая по заявке.

Отдельноесоглашение 2020 года с PSACпредусматривало денежную общую компенсацию для подпадающих под условия сотрудников, представленных профсоюзом, и касалось запоздалого применения коллективных договоров. Право на выплаты зависело от охваченных финансовых годов и статуса занятости. Само существование соглашения не означает, что каждый пострадавший входил в его профсоюзную группу или получил максимальную сумму.

Меморандум 2021 года о выравнивающих выплатахпривёл к единообразию определённые льготы для людей, охваченных более ранним соглашением. О нём нужно сообщать как об отдельном более позднем механизме, а не молча сливать с условиями 2019 года. Дата соглашения, период права на выплаты и дата платежа могут различаться.

Процедура по тяжёлым последствиямохватывает такие категории, как финансовые расходы, упущенный инвестиционный доход, отпуск, связанный с проблемами со здоровьем, и тяжёлые личные или финансовые обстоятельства, с учётом применимых условий и доказательств. Для многих категорий действует порог, для некоторых — иной порядок. Подача заявки не является доказательством того, что заявленная сумма принята, а принятая мера может включать восстановление отпуска, а не деньги.

Отчётность о компенсациях должна поэтому показывать группы раздельно: получившие автоматическое зачисление, имеющие право подать заявку, поданные заявки, рассмотренные, принятые полностью или частично, отклонённые, оплаченные, повторно открытые и ожидающие рассмотрения. Также нужно показывать медианное время обработки и хвост распределения. Смысл не только в учёте: задержка компенсации может усугубить исходный ущерб и подорвать доверие, даже когда основная выплата исправлена.

Отчётность о расходах требует карты охвата

Вотчёте Treasury Board о расходах на Phoenix за 2024–25 годыуказаны расходы, связанные с Phoenix, в размере 937,5 млн канадских долларов за этот финансовый год. На странице перечислены исключения, включая работы по программе Next Generation HR and Pay, компенсации и требования, связанные с Короной, а также альтернативные издержки. Это годовой итог в заданных границах, а не совокупная стоимость Phoenix с 2009 года.

На разные вопросы о расходах нужны разные учётные книги. Первоначальный бюджет внедрения отвечает на вопрос, сколько проекту было разрешено потратить. Годовые расходы на стабилизацию — сколько правительство потратило за год по указанным категориям. Компенсации отражают обязательства по возмещению. Резервы по переплатам — это балансовые оценки, а не программные расходы. Время сотрудников ведомств и отложенная работа по политикам могут быть альтернативными издержками. Оценки Dayforce касаются программы-преемника.

Оценка стоимости замены отParliamentary Budget Officer (PBO) за 2019 годбыла сценарной оценкой на основе тогдашних допущений. Это не результат закупки, не утверждённый бюджет Dayforce и не фактический счёт. Сравнение с более поздними оценками может показать, как менялись охват и информация, но только если сохранить допущения и ценовую базу.

Контроль расходов должен относить каждый доллар к программе, организации, финансовому году и цели: эксплуатация, стабилизация, расчистка остатка, компенсации, возврат средств, проектирование замены, переход ведомства или вывод из эксплуатации прежней системы. Общие расходы требуют правил распределения. Публичная отчётность должна сводить годовые итоги с совокупными цифрами и объяснять изменения. Экономию следует показывать за вычетом вытесненной работы ведомств и продолжающихся ручных процессов.

Соотношение цены и качества — это не самый дешёвый запуск. Это стоимость корректных и своевременных выплат при устойчивых контролях. Более дорогой параллельный прогон может быть выгоден, если он предотвращает перенос ошибок и ущерб сотрудникам. И наоборот, бесконечная параллельная эксплуатация старой и новой систем может создавать двойные расходы без снижения риска. Лицам, принимающим решения, нужны явные критерии выхода, а не объявление, продиктованное графиком.

Goss Gilroy — исследование уроков, а не аудит

Вотчёте Goss Gilroy об извлечённых уроках, заказанном правительством, инициатива рассмотрена с 2008 года по апрель 2016 года на основе изучения документов и консультаций. В отчёте прямо сказано, что это не аудит и что мнения и выводы принадлежат Goss Gilroy, а не обязательно правительству. Эта оговорка — содержательная граница доказательств.

Исследование остаётся ценным. Оно сгруппировало уроки вокруг управления, надзора, управления изменениями, мощностей, тестирования и культуры проекта. Консультации могут показать, как участники понимали давление и принятие решений, включая то, что официальные документы проекта приуменьшают. Но оно не использует установленный законом мандат и метод подтверждения Генерального аудитора, и его наблюдения, основанные на интервью, нельзя представлять как установленные факты.

Отчёты OAG, парламентские комитеты, ведомственные брифинги и исследование Goss Gilroy можно читать вместе через матрицу мандатов. Для каждого утверждения матрица указывает, проверял ли источник записи, заслушивал ли показания, описывал ли ведомственную политику, сообщал ли мнения участников или выдавал ли рекомендацию. Согласие источников с разными мандатами может усилить вывод; разногласия должны быть видны, а не усреднены.

Такой подход защищает и подотчётность, и справедливость. Он не позволяет консультационному наблюдению превратиться в юридический вывод против конкретного человека. Он также не позволяет институту отмахнуться от повторяющегося операционного урока только потому, что он получен не через аудит. Правильная реакция — проверить наблюдение по документам и текущим операционным данным.

Стабилизационная работа — это не то же самое, что урегулирование

Интегрированнаястратегия PSPC по кадрам и выплатамобъединяет текущую стабилизацию Phoenix, сокращение необработанных операций и будущую работу по Dayforce. Интегрированная рамка разумна, потому что нерешённая работа и проектирование замены взаимодействуют. Но она создаёт и риск для отчётности: прогресс в одном направлении можно принять за успех в другом.

Вобновлении о ходе работ за март 2026 годаговорилось, что обработана высокая доля целевой группы старых дел и что число операций старше года снизилось. «Целевые дела» — это не весь остаток, а «обработано» само по себе не доказывает, что каждый сотрудник согласен с результатом или получил связанную компенсацию. Знаменатель и отбор целевой группы должны оставаться видимыми.

У стабилизации должны быть многоуровневые результаты. Первое — обработать операцию. Второе — проверить итоговую выплату и последующие налоговые, пенсионные записи и записи о пособиях. Третье — подтвердить с сотрудником, что вопрос решён, или зафиксировать оставшийся спор. Четвёртое — связать человека с применимой компенсацией. Пятое — проверить, изменился ли корневой контроль, чтобы такой тип дел не повторялся.

Иначе сокращение остатка может вознаграждать закрытие, а не корректность. Команды под давлением объёмов могут иначе разделять или объединять работу, менять определения статусов или закрывать обращение, пока остаётся финансовая операция. Независимая выборочная проверка качества, доля повторных открытий и подтверждения сотрудников ограничивают этот риск. Отчётность о самых старых делах не даёт совокупному улучшению спрятать устойчивый «хвост».

Стабилизированной системе нужна операционная устойчивость вплоть до вывода из эксплуатации. Патчи безопасности, поддержка вендора, платёжные календари, изменения коллективных договоров и опытный персонал нельзя игнорировать только потому, что запланирован Dayforce. Период перехода может быть самой рискованной фазой: люди осваивают новую платформу, одновременно поддерживая Phoenix и расчищая старую работу. Модели мощностей должны включать обе системы и подготовку ведомств.

Планирование Dayforce должно заслужить право на запуск

Вправительственном отчёте об оценке осуществимости Dayforceописаны исследования, настройка и тестирование, использованные, чтобы оценить, может ли коммерческая платформа удовлетворять федеральные потребности в кадрах и выплатах. Работа по оценке осуществимости может снизить неопределённость, но макетные данные и отобранные сценарии не доказывают точную работу в реальной эксплуатации по всем ведомствам, коллективным договорам и исключениям прежней системы.

OAG в 2026 году сообщил, что преобразование на Dayforce останется на этапе планирования до июня 2027 года, и привёл предварительную сумму свыше 4,2 млрд канадских долларов, которая исключала значительные расходы ведомств на переход. Он также предупредил, что нерешённые ошибки Phoenix могут перейти в новую систему, а упрощение правил оплаты остаётся незавершённым. Во время аудита и после него программа сократила график. Более ранняя дата увеличивает бремя доказывания, а не уменьшает его.

Настранице PSPC об отслеживании обязательствописаны этапы настройки и тестирования. Будущие этапы — это планы. В отчётности следует использовать «ожидается», «планируется» или «целевые значения», пока событие не произошло и не прошло проверку доказательствами. Запланированный параллельный тест — это не завершённая сверка.

Контрольная точка запуска должна требовать параллельного расчёта зарплаты, приближённого к реальной эксплуатации, для представительных ведомств и сложных дел, на протяжении достаточного числа циклов, чтобы охватить ретроактивные выплаты, пособия и эффекты конца года. Каждое расхождение должно быть классифицировано, за ним должен быть закреплён владелец, и оно должно быть устранено. Тест должен сравнивать ожидаемую выплату, результат Phoenix, результат Dayforce и фактическую запись сотрудника, а не исходить из того, что Phoenix всегда является правильным эталоном.

Контроль переноса должен отделять чистые основные данные от нерешённых дел. Для открытых операций нужно определить их судьбу: решить до переноса, перенести с полной историей и назначенным владельцем или оставить в контролируемом процессе прежней системы. Остатки по переплатам, авансам, отпускам, налогам и пенсиям требуют сверки. Сотрудники должны видеть, какая система ведёт их вопрос во время перехода.

Готовность ведомств должна подтверждаться независимо. Каждой организации нужны обученный персонал, описанные кадровые процессы, результаты проверки качества данных, тесты интерфейсов, маршруты поддержки и план на случай сбоя. Центральная программа должна выборочно проверять и оспаривать самооценки. Орган, обладающий правом остановки, должен иметь возможность отложить ведомство или волну, и его не должны отменять только потому, что объявлен публичный график.

Карта контроля готовности выплат и компенсаций

Исправленная система подотчётности может быть организована вокруг восьми доменов. Владельцы требований ведут каталог правил оплаты и утверждают упрощения. Владельцы закупок фиксируют работу вендора, консультации, приёмку и дефекты. Технические команды настраивают и тестируют. Ведомства отвечают за своевременные кадровые события. PSPC отвечает за операции Pay Centre и сквозную услугу. Treasury Board отвечает за политику работодателя и рамки возмещения ущерба. Финансовые владельцы сводят зарплату и переплаты. Независимый орган запуска решает, поддерживают ли доказательства переход.

Каждому домену нужны наблюдаемые доказательства. Требования прослеживаются до конфигурации и тестов. Задачи вендора имеют акты приёмки. Ведомственные события соответствуют порогам своевременности и валидации. Мощность Pay Centre превышает прогнозируемый спрос с учётом резерва. Показатели остатка сводят операции, дела, запросы и пострадавших сотрудников. Недоплаты и переплаты имеют определения с датами. Учётные книги компенсаций связывают ошибку выплаты, сопутствующий ущерб, решение и платёж.

Карта контроля должна сохранять достоинство сотрудников. Им не должно приходиться повторять одну и ту же историю разным командам или догадываться, какая организация отвечает за проблему. Менеджер дела может координировать работу ведомственных кадровых служб, Pay Centre, налоговых и пенсионных функций и функций по заявкам, при этом каждая сохраняет формальную ответственность. В коммуникации должно быть сказано, что известно, что остаётся спорным, какое следующее действие и ожидаемая дата.

Автоматизация должна поддерживать подотчётность, а не скрывать её. Движки правил могут валидировать данные; рабочие процессы — направлять исключения; аналитика — выявлять повторяющиеся сбои; панели — показывать старение. Каждое автоматизированное решение должно сохранять исходные данные, версию правила, изменения статуса и ручные переопределения. Закрытый код не должен стирать доказательства, нужные для аудита или заявки.

Независимое подтверждение должно продолжаться после запуска. Аудиторы должны выбирать сотрудников, а не только операции, и прослеживать их записи между системами. Представители сотрудников должны видеть совокупные показатели ошибок и компенсаций. Ведомства следует сравнивать по своевременности данных, не перекладывая всю вину с централизованной обработки. Результаты должны публиковаться с определениями, достаточно стабильными, чтобы показывать тенденции.

Заключение

Phoenix стал проверкой подотчётности госзакупок, потому что правительство купило и настроило программное обеспечение, одновременно перестраивая услугу вокруг него. Отсутствующие функции, неполное тестирование, сокращённая экспертиза, раздробленное владение данными и слабый контроль запуска взаимодействовали друг с другом. Контрактная роль IBM важна, но PSPC сохранило полномочия определять работы, принимать объём и развёртывать систему. Точная атрибуция — ключ к извлечению уроков.

Запись о последствиях требует такой же точности. Сотрудники — это люди; операции, запросы и дела — единицы работы. Недоплаты, переплаты, необработанные операции, точность и аудиторские выборки имеют разные знаменатели. Годовые расходы, совокупные затраты на стабилизацию, компенсации и оценки замены имеют разные границы затрат. Снижение остатка может быть прогрессом, не доказывая, что каждый человек получил корректную выплату и компенсацию.

Компенсации — часть производительности системы, а не внешняя юридическая надстройка. Экстренная поддержка, общие компенсации, отпуска, единовременные выплаты, выравнивающие выплаты и заявки по тяжёлым последствиям требуют прозрачных критериев права на выплаты, показателей обработки и результатов. Исправление основной выплаты спустя месяцы или годы не восстанавливает автоматически налоговые, кредитные, медицинские последствия или последствия потерянного времени.

Dayforce даёт шанс выстроить более сильные контроли, но шанс — это не доказательство. Настройка, оценка осуществимости и запланированные параллельные тесты должны привести к воспроизводимым доказательствам на реальных кадровых событиях, правилах оплаты, ведомствах и сотрудниках. У нерешённых записей Phoenix должны быть назначенные владельцы и сверенные маршруты переноса. Независимая контрольная точка запуска должна уметь сказать «нет».

Устойчивый стандарт прост: правительство не должно объявлять платёжную систему готовой, пока не покажет, кто был протестирован, что отличалось, как устранены исключения, как будут защищены сотрудники и кто может остановить развёртывание. Эти доказательства превращают модернизацию из графика в подотчётную государственную услугу.