90-дневный пилотный план EWA для компаний

90-дневный пилот EWA следует разделить на три этапа: 0–30 дней — подготовка; 31–60 дней — контролируемая эксплуатация; 61–90 дней — оценка и решение о масштабировании. Цель — не максимальное число транзакций, а доказательство того, что вся цепочка «подтверждённое рабочее время – лимит – перевод средств – расчёт зарплаты – бухгалтерия» работает корректно, сотрудники понимают свои права, а риски остаются в пределах, приемлемых для компании.

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

> Глоссарий терминов: EWA (получение оплаты за уже отработанные дни) · pilot (пилотное внедрение) · UAT (приёмочное тестирование пользователями) · RACI (матрица ролей: Исполнитель – Ответственный – Консультируемый – Информируемый) · KPI (ключевой показатель эффективности) · ROI (возврат инвестиций) · go-live (официальный запуск в эксплуатацию) · soft launch (мягкий запуск в небольшом масштабе) · project charter (устав проекта) · risk register (реестр рисков) · playbook (руководство по действиям) · dashboard (панель мониторинга) · Go–Adjust–Stop (Продолжить – Скорректировать – Остановить).

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

Документация, демонстрации и UAT позволяют проверить лишь часть системы. Пилот с реальными данными помогает компании убедиться:

• Обновляется ли подтверждённое рабочее время корректно и достаточно быстро (согласно процессу Lương Ngày).

• Не создаёт ли формула расчёта лимита расхождений в конце периода.

• Не дублируются, не зависают ли транзакции и не уходят ли на неверный счёт.

• Могут ли расчёт зарплаты и бухгалтерия провести сверку до уровня каждой транзакции.

• Понимают ли сотрудники комиссии, лимит и остаток заработной платы.

• Способна ли служба поддержки обрабатывать ошибки учёта времени, увольнения и запросы на проверку.

• Насколько общие затраты и выгоды соответствуют бизнес-кейсу.

• Контролируются ли персональные данные и права доступа в реальной эксплуатации.

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

Готова ли компания к пилоту EWA?

Дату старта стоит назначать только тогда, когда базовые условия уже выполнены.

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

Как выбрать масштаб пилота

Выбор подходящего подразделения

Стоит отдавать приоритет заводу, региону или группе, которые обладают:

• относительно стабильными данными учёта рабочего времени;

• чёткими лицами, утверждающими рабочее время, и HR-контактами;

• возможностью расчёта зарплаты формировать отдельные отчёты для пилотной группы;

• готовностью руководства к сотрудничеству;

• достаточной численностью сотрудников для возникновения реальных ситуаций;

• отсутствием одновременных изменений слишком большого числа ключевых политик.

Какой масштаб является подходящим?

Диапазон 300–1000 сотрудников может служить ориентиром для крупных работодателей, но не является обязательным стандартом. Небольшие компании могут проводить пилот с меньшим числом участников; компании с ещё нестабильными данными стоит начинать с более узкого масштаба.

Масштаб должен отвечать двум требованиям:

1. Быть достаточно небольшим, чтобы его можно было остановить и устранить проблему при инциденте.

2. Быть достаточно большим, чтобы протестировать нагрузку, поведение пользователей и исключительные ситуации.

Определение подходящей группы

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

• действующие трудовые отношения;

• корректно сопоставленный табельный номер сотрудника;

• наличие подтверждённого рабочего времени;

• наличие данных о заработной плате как основы расчёта;

• наличие действительного счёта для получения средств;

• отсутствие статуса увольнения/временной блокировки/спора по рабочему времени;

• завершённое подтверждение условий и уведомление о данных.

Не стоит открывать доступ по принципу «все сотрудники», а затем разбираться с недостающими данными постфактум.

Общий обзор 90-дневного графика

Этап 1 — Подготовка, дни 0–30

Неделя 1. Утверждение цели и масштаба

• Разработать устав проекта.

• Выбрать руководителя проекта и проектный комитет.

• Выбрать подразделение, группу сотрудников и сроки пилота.

• Утвердить основную цель и вспомогательные KPI.

• Сформировать базовый уровень по увольнениям, авансам, рабочему времени, расчёту зарплаты и затратам.

• Определить бюджет и источник средств.

• Составить первоначальный реестр рисков.

Результат: утверждены масштаб, KPI, бюджет, ответственный руководитель и график проекта.

Неделя 2. Юридические вопросы, политика и данные

• Определить структуру транзакций и схему движения денежных средств.

• Проверить договор, регламент и условия для сотрудников.

• Утвердить модель комиссии и сторону, которая её несёт.

• Составить карту данных, роли обработки и матрицу разграничения прав доступа.

• Определить сроки хранения/удаления данных и порядок действий при инцидентах.

• Утвердить условия допуска, лимит, резерв и предельный лимит программы.

Результат: утверждён пакет юридических, политических и связанных с данными документов.

Неделя 3. Интеграция и функциональное тестирование

• Сопоставить табельные номера сотрудников между HR, учётом времени, расчётом зарплаты и EWA.

• Протестировать различные статусы рабочего времени.

• Протестировать формулу расчёта лимита.

• Протестировать изменение счёта для получения средств.

• Протестировать защиту от дублирования транзакций.

• Протестировать успешные, неудачные транзакции, транзакции в ожидании проверки и возвраты.

• Протестировать случаи увольнения, ошибок учёта времени и закрытия периода.

• Провести тестовую сверку — от транзакции до расчётного листка/бухгалтерской проводки.

Результат: протокол UAT, список ошибок, ответственные за исправление и результаты повторного тестирования.

Неделя 4. Обучение и утверждение запуска

• Обучить руководителей, утверждающих рабочее время.

• Обучить HR, расчёт зарплаты, бухгалтерию, IT и службу поддержки.

• Провести коммуникацию для пилотной группы простым и понятным языком.

• Провести опрос на понимание условий перед активацией.

• Утвердить график дежурств и каналы поддержки.

• Провести учения по инцидентам и механизму приостановки.

• Провести совещание Go/No-Go.

Результат: окончательный список подходящих сотрудников, чек-лист запуска и протокол утверждения.

Этап 2 — Контролируемая эксплуатация, дни 31–60

Дни 31–37. Мягкий запуск (soft launch)

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

• долю успешной регистрации/аутентификации;

• корректность отображения подтверждённого рабочего времени и лимита;

• корректность отображения комиссии и остатка заработной платы;

• поступление транзакций на правильный счёт;

• корректное уменьшение лимита после транзакции;

• работу журналов, уведомлений и тикетов поддержки.

Ежедневная сверка и короткие итоговые совещания в конце дня в течение первой недели.

Дни 38–45. Стабилизация процессов

• Постепенно расширять доступ в рамках утверждённого масштаба.

• Отслеживать рабочее время, ожидающее подтверждения, и время обновления лимита.

• Классифицировать все тикеты по причинам.

• Закрывать критические ошибки до увеличения масштаба.

• Проверять поведение при повторных выводах средств и остаток заработной платы.

• Проверять возможности источника средств в пиковые дни.

Дни 46–60. Проверка нагрузки и исключений

• Прогнать заранее предусмотренные сценарии в реальных условиях эксплуатации.

• Отслеживать пиковые дни, выходные и периоды, близкие к закрытию периода.

• Проверить случаи увольнения, смены смены, отпуска без сохранения зарплаты и корректировок рабочего времени.

• Оценить эффективность поддержки и эскалации обработки.

• Подготовиться к первой сверке расчёта зарплаты.

Осторожный лимит во время пилота

Единого универсального коэффициента безопасности не существует. Во время пилота компании следует:

• рассчитывать лимит только на основе подтверждённого рабочего времени;

• при необходимости использовать более низкий коэффициент доступа, чем планируется после масштабирования;

• сохранять резерв на случай корректировок рабочего времени и обоснованных обязательств;

• устанавливать лимиты на человека, день, подразделение и всю программу;

• приостанавливать сервис при падении источника средств или качества данных ниже порога;

• не смягчать лимит только ради увеличения числа транзакций.

Этап 3 — Оценка, дни 61–90

Дни 61–75. Завершение одного периода расчёта зарплаты

Это обязательный этап для проверки полного жизненного цикла:

1. Закрыть данные по рабочему времени.

2. Определить итоговый статус каждой транзакции.

3. Включить досрочно полученные суммы в расчёт зарплаты.

4. Сверить каждого сотрудника и каждую транзакцию.

5. Сверить выписки и бухгалтерские проводки.

6. Обработать расхождения.

7. Выпустить понятные расчётные листки.

8. Закрыть период и сохранить документацию.

Пилот не следует считать успешным лишь потому, что средства были переведены корректно, если не подтверждена итоговая сверка периода.

Дни 76–85. Оценка опыта, эффективности и рисков

• Опрос пользователей и не пользующихся сервисом сотрудников.

• Интервью с руководителями, HR, расчётом зарплаты, бухгалтерией и поддержкой.

• Сравнение KPI с базовым уровнем и контрольной группой.

• Расчёт общих затрат, предварительных выгод и ROI.

• Анализ комиссий, жалоб, остатка заработной платы и поведения при использовании.

• Обновление реестра рисков и оценка контроля.

Дни 86–90. Принятие решения

Проектный комитет готовит итоговый отчёт и предлагает одно из трёх решений:

• Go: масштабировать согласно дорожной карте.

• Adjust: продлить или скорректировать пилот.

• Stop: приостановить, пересмотреть модель или не продолжать.

RACI для проекта пилота EWA

Обозначения: R — непосредственный исполнитель; A — окончательно ответственный/утверждающий; C — консультируемый; I — информируемый.

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

KPI-дашборд 90-дневного пилота

Группа «Данные и допуск»

• Число/доля сотрудников, соответствующих условиям.

• Доля дел, корректно сопоставленных с табельным номером сотрудника.

• Доля счетов для получения средств, успешно прошедших аутентификацию.

• Доля рабочего времени, подтверждённого в срок согласно SLA.

• Число сотрудников без лимита из-за нехватки данных.

Группа «Использование»

• Доля активации.

• Доля пользователей.

• Число транзакций на человека за период.

• Средняя сумма получаемых средств.

• Доля полученной суммы относительно уже начисленной заработной платы.

• Прогнозный остаток заработной платы после транзакции.

Группа «Эксплуатация»

• Доля успешных транзакций.

• Время обработки транзакции.

• Транзакции с ошибкой/в ожидании проверки/возвраты.

• Дублирующиеся или заблокированные из-за подозрения на дублирование транзакции.

• Число и сумма расхождений сверки.

• Время закрытия тикета.

Группа «Опыт»

• Доля правильного понимания EWA, комиссий и остатка заработной платы.

• Уровень удовлетворённости.

• Число жалоб на 1000 подходящих сотрудников.

• Причины отказа от активации/использования.

• Доля сотрудников, желающих продолжать пользоваться сервисом.

Группа «Персонал и финансы»

• Ручные авансы до и после.

• Время, сэкономленное HR/расчётом зарплаты.

• Увольнения через 7/30/60/90 дней.

• Отсутствие на рабочем месте/прогулы смен.

• Затраты на пилот и затраты на одного подходящего сотрудника/пользователя.

• Пересчитанные выгоды, чистая выгода и предварительный ROI.

Группа «Риски»

• Переплата сверх реальной заработной платы.

• Потери из-за ошибок в данных/мошенничества.

• Инцидент безопасности/утечка персональных данных.

• Нарушение критически важного SLA.

• Число сотрудников с остатком заработной платы ниже внутреннего порога предупреждения.

Критерии Go–Adjust–Stop

Go — условия для масштабирования выполнены

• Завершён как минимум один период расчёта зарплаты со сверкой до уровня каждой транзакции.

• Нет необработанных существенных расхождений.

• Подтверждённое рабочее время и данные соответствуют SLA.

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

• Сотрудники правильно понимают комиссии, лимит и остаток заработной платы.

• Затраты укладываются в бюджет, есть разумные признаки выгоды.

• Юридические вопросы, данные, источник средств и безопасность не создают препятствий для масштабирования.

Adjust — продолжение с корректировками

• KPI не достигнуты, но причины ясны и есть план действий.

• Медленное подтверждение рабочего времени или низкая доля активации из-за коммуникации.

• В интеграции ещё сохраняются ручные операции, но они находятся под контролем.

• Модель комиссии, лимит или SLA требуют корректировки.

• ROI ещё не положительный из-за разовых затрат или слишком малого масштаба пилота.

Stop — остановка или пересмотр модели

• Невозможно провести сверку с расчётом зарплаты/бухгалтерией.

• Есть ошибочные/дублирующиеся выплаты или неконтролируемые потери.

• Источник средств не гарантирован.

• Юридическая природа или ответственность сторон остаются неясными.

• Произошёл серьёзный инцидент с данными.

• Сотрудники были введены в заблуждение или столкнулись со значительным негативным воздействием без эффективных мер.

Чек-лист запуска в эксплуатацию

Юридические вопросы и политика

• [ ] Модель и денежные потоки описаны и утверждены.

• [ ] Договор, регламент и условия для сотрудников согласованы.

• [ ] Комиссии и сторона, которая их несёт, чётко объявлены.

• [ ] Разработан механизм на случай увольнения, недостатка зарплаты и спора по рабочему времени.

• [ ] Проверены сообщения о займе, кредитной истории, процентах/комиссиях.

Данные и технологии

• [ ] Лимит рассчитывается только на основе подтверждённого рабочего времени.

• [ ] Табельный номер сотрудника и номер транзакции уникальны.

• [ ] Протестированы защита от дублирования, повторные попытки и транзакции в ожидании.

• [ ] Настроены разграничение доступа, шифрование, журналы и оповещения.

• [ ] Есть механизм блокировки уволенных сотрудников.

• [ ] Предусмотрен план отката/приостановки.

Финансы, расчёт зарплаты и бухгалтерия

• [ ] Формула расчёта лимита и резерв утверждены.

• [ ] Источник средств и предельный лимит программы готовы.

• [ ] UAT проведён до этапа расчётного листка и бухгалтерской проводки.

• [ ] Есть файл и процесс трёхуровневой сверки.

• [ ] Есть процесс возврата средств, исправления ошибок и закрытия периода.

Сотрудники и поддержка

• [ ] Список подходящих сотрудников проверен.

• [ ] Интерфейс отображает комиссии, фактически полученную сумму и остаток заработной платы.

• [ ] FAQ и инструкции по ошибкам учёта времени/транзакций готовы.

• [ ] Канал поддержки, график дежурств и SLA опубликованы.

• [ ] Проведён опрос на понимание условий перед запуском.

Десять распространённых ошибок при внедрении пилота EWA

1. Отсутствие базового уровня: после пилота непонятно, стали ли результаты лучше или хуже и по сравнению с чем.

2. Выбор подразделения со слишком слабыми данными: всё время уходит на исправление рабочего времени вместо проверки EWA.

3. Слишком широкое открытие доступа в первый же день: небольшая ошибка затрагивает слишком много людей.

4. Тестирование только основного сценария: непонятно, как обрабатывать увольнения, ошибки учёта времени, зависшие транзакции или возвраты.

5. Отсутствие единого ответственного руководителя проекта: подразделения ждут решений друг от друга.

6. Установка числа транзакций как основной цели: это может стимулировать чрезмерное использование.

7. Незавершение полного периода расчёта зарплаты: полный жизненный цикл не проверен.

8. Избыточная коммуникация: обещания «получить деньги в любой момент» или «без каких-либо комиссий», не соответствующие реальным условиям.

9. Неучёт внутренних затрат: ROI оказывается завышенным.

10. Масштабирование при неустранённых ошибках: технический долг и расхождения растут вместе с масштабом.

План коммуникации для сотрудников

Сообщение должно давать ответ на шесть вопросов:

1. Что такое Lương Ngày/EWA?

2. Кто имеет право на участие?

3. Какое рабочее время используется для расчёта лимита?

4. Каковы комиссии и фактически получаемая сумма?

5. Как изменяется зарплата в конце периода?

6. К кому обращаться при возникновении ошибки?

Рекомендуется использовать разные форматы: короткие видео, постеры, FAQ, инструкции внутри приложения и обучение для непосредственных руководителей. Содержание должно быть единым на всех каналах.

Шаблон отчёта по пилоту для генерального руководства

1. Резюме для руководства

• Цель, масштаб, сроки.

• Основные результаты.

• Риски и инциденты.

• Предложение Go–Adjust–Stop.

2. Операционные результаты

• Допуск, подтверждённое рабочее время, транзакции, SLA, сверка.

3. Опыт сотрудников

• Понимание, удовлетворённость, жалобы, качественная обратная связь.

4. Влияние на персонал

• Найм, увольнения, отсутствие на рабочем месте и контрольная группа.

5. Финансы

• Затраты, выгоды, ROI и три сценария масштабирования.

6. Риски и контроль

• Реестр рисков, расхождения, инциденты, ещё открытые действия.

7. Дальнейший план

• Масштаб расширения или список корректировок.

• Бюджет и ресурсы.

• Следующая контрольная точка принятия решения.

Заключение

90-дневный пилот EWA — это процесс проверки межфункциональной операционной системы. Успех измеряется не только скоростью перевода средств, но и тем, что обеспечено:

Нужный человек → нужное подтверждённое рабочее время → нужный лимит → нужный счёт → только один раз → нужный расчёт зарплаты → нужная бухгалтерия → нужный опыт.

Компании стоит тщательно подготовиться в первые 30 дней, контролируемо открыть доступ в следующие 30 дней и посвятить последние 30 дней завершению расчёта зарплаты, измерению KPI, расчёту ROI и принятию решения на основе фактических данных.

Компании могут получить пилотный план Lương Ngày, адаптированный под их масштаб, данные учёта рабочего времени, расчёт зарплаты и HR-цели, на странице Lương Ngày для компаний.

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

Источники

• Трудовой кодекс № 45/2019/QH14

• Закон об электронных транзакциях № 20/2023/QH15

• Закон о защите персональных данных № 91/2025/QH15

• Постановление 356/2025/NĐ-CP, детализирующее отдельные положения и меры по реализации Закона о защите персональных данных

• Постановление 52/2024/NĐ-CP о безналичных платежах

• МОТ: Earned Wage Access – A Global Study on Benefits and Risks

---

Автор: Nguyễn Tấn Lộc — специалист отдела стратегии, компания Công ty TNHH Cung Ứng Nhân Lực Nhân Kiệt.

Консультация по решению Lương Ngày для компаний: горячая линия 0937.022.655 · e-mail info@nhankiet.vn · Lương Ngày для компаний