Сколько сотрудников нужно компании для управления доступом к заработанной зарплате?

Сколько сотрудников нужно компании для управления доступом к заработанной зарплате? Модель персонала и RACI

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

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

> Предупреждение: Ngô Nhã Kỳ — Biên tập viên ban biên tập, а не штатное расписание Nhân Kiệt. Необходимо измерить реальную рабочую нагрузку в пилоте перед принятием решения о штате или обязательствах по поддержке 24/7.

1. Почему количество пользователей недостаточно для определения штата?

Две компании с 5,000 работников могут нуждаться в очень разных ресурсах:

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

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

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

2. Десять переменных, определяющих ресурсы

1. Количество работников, имеющих право.

2. Количество активных пользователей и транзакций в день.

3. Количество клиентов/локаций/смен.

4. Количество шаблонов рабочего времени.

5. Доля неутвержденного/непроверенного рабочего времени.

6. Доля неподтвержденных ID/аккаунтов.

7. Доля зависших/неудачных транзакций.

8. Количество и сложность периодов выплаты зарплаты.

9. Часы поддержки запросов.

10. Уровень автоматизации, SLA и приемлемый риск.

3. 11 ключевых ролей

(Подробнее: Управление доступом к заработанной зарплате после запуска: RACI, контроль и инциденты.)

1. Исполнительный спонсор

Утверждает цели, бюджет, объем, риск и решения о расширении/остановке.

2. Владелец услуги

Отвечает за качество услуги от начала до конца, а не только за одну систему. Это роль, которую не следует оставлять пустой.

3. Владелец продукта/процесса

Управляет требованиями, формулами, лимитами, процессами и приоритетами улучшений.

4. HR Master Data

Управляет записями, ID, статусами работы, переводами, увольнениями и отношениями с клиентами.

5. Операции с посещаемостью

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

6. Операции с платежами

Отслеживает платежные поручения, специализированные счета, зависшие транзакции, сверку и аварийное отключение.

7. Сверка/Финансы

Сверяет записи доступа к заработанной зарплате, выписки и задолженности; обрабатывает расхождения и невозвратные суммы.

8. Зарплата

Обеспечивает правильные транзакции для правильных людей/периодов, составляет отчеты и расчетные листки.

9. Поддержка клиентов

Принимает запросы, проверяет, классифицирует, обновляет и закрывает тикеты.

10. Инженерия/SRE/Информационная безопасность

Интеграция, мониторинг, релизы, инциденты, безопасность, резервное копирование и восстановление.

11. Юридические вопросы/Данные/Соответствие

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

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

4. Модель A — Маленький пилот

Иллюстративный охват

• 100–1,000 работников, имеющих право;

• один–два клиента;

• мало шаблонов рабочего времени;

• поддержка в определенные часы;

• ограниченные транзакции/низкие суммы;

• ежедневная сверка.

Рекомендуемая основная группа

Общее количество фактических людей может составлять 5–8 человек, совмещающих роли, а не 5–8 FTE на полный рабочий день.

5. Модель B — Средний масштаб

Иллюстративный охват

• 1,000–10,000 работников;

• много локаций/клиентов;

• стабильные ежедневные транзакции;

• несколько шаблонов рабочего времени;

• расширенные SLA и смены поддержки.

Рекомендуемая структура

• один специализированный Владелец услуги;

• один Владелец продукта/процесса;

• 1–3 человека HR/рабочее время;

• 1–2 человека платежи/сверка;

• 1–2 человека поддержка клиентов по сменам;

• зарплата по периодам, с резервом;

• техника/SRE по вызову;

• информационная безопасность, юридические вопросы и данные по расписанию.

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

6. Модель C — Большой масштаб, много клиентов

Характеристики

• десятки тысяч работников;

• сотни клиентов/локаций;

• много источников и шаблонов рабочего времени;

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

• большие транзакции и денежные потоки;

• высокие требования к контролю/разделению обязанностей.

Рекомендуется организовать по подгруппам

1. Управление услугами: владелец, KPI, риски, поставщики.

2. Данные о рабочей силе: записи, рабочее время, маппинг, утверждение.

3. Операции с деньгами: источники средств, платежные поручения, сверка.

4. Сверка и зарплата: выписки, задолженности, расчетные листки.

5. Опыт работников: адаптация, поддержка клиентов, личные финансы.

6. Технологии и доверие: инженерия, SRE, информационная безопасность, данные.

Каждая подгруппа имеет руководителя и расписание резервирования; P1 имеет независимого Командира инцидентов.

7. Формула определения штата по рабочей нагрузке

Можно оценить:

FTE = общее количество минут обработки работы за период ÷ количество полезных минут работы каждого FTE

Пример для поддержки клиентов:

Тикеты/день × среднее количество минут/тикет × коэффициент постпроверки ÷ полезные минуты/смена

Пример для сверки:

Исключения/день × минуты/исключение + время на общую проверку + отчет

Не используйте 480 минут/день как абсолютную полезную производительность; необходимо вычесть время на собрания, обучение, перерывы и колебания нагрузки.

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

(Подробнее: Результаты пилота доступа к заработанной зарплате: KPI и уроки и План пилота доступа к заработанной зарплате на 90 дней.)

• количество новых/измененных/уволенных записей;

• количество строк рабочего времени и доля ошибок;

• ожидающее утверждение рабочее время и его возраст;

• несоответствующие аккаунты/OCR;

• транзакции по часам/сменам;

• доля успешных/ожидающих/неудачных транзакций;

• количество исключений сверки;

• тикеты по типу;

• время обработки и повторного открытия;

• количество изменений конфигурации;

• объем зарплаты по cut-off;

• инциденты и часы по вызову.

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

9. Пример RACI

10. Роли, которые не следует полностью совмещать

• человек, исправляющий рабочее время, и человек, утверждающий ту же запись;

• человек, изменяющий лимиты, и человек, утверждающий их;

• человек, осуществляющий/корректирующий транзакции, и человек, завершающий сверку;

• разработчик, внедряющий изменения в production, и сам их подтверждающий;

• человек, держащий банковские ключи, и человек, принимающий все решения по платежам;

• человек, обрабатывающий инциденты, и человек, утверждающий удаление логов;

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

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

11. Дежурства и on-call

Если система позволяет транзакции 24/7, но команда поддержки работает только в рабочие часы, необходимо четко указать:

• какие функции автоматизированы 24/7;

• какие P1 имеют on-call;

• когда будут обработаны обычные тикеты;

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

• эскалация до VPBank;

• право использовать аварийное отключение;

• передача между сменами.

Не обещайте 24/7 только потому, что приложение доступно в любое время.

12. Минимальный runbook для каждой роли

(Подробнее: Как компании справляются с инцидентами доступа к заработанной зарплате и Playbook по обработке жалоб на доступ к заработанной зарплате.)

HR/рабочее время

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

Операции с платежами

Несоответствующие аккаунты, зависшие транзакции, таймауты, сверка, нехватка средств, аварийное отключение.

Сверка

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

Зарплата

Cut-off, транзакции вблизи периода, двойные вычеты, возвраты после закрытия, расхождения в расчетных листках.

Поддержка клиентов

Проверка запрашивающего, коды причин, минимальные данные, SLA/эскалация, содержание ответа.

Техника/Информационная безопасность

Уведомления, откаты, сохранение логов, P1, нарушения данных, восстановление.

13. KPI для команды управления

Следует измерять

• количество записей, имеющих право;

• утвержденное рабочее время в срок;

• доля объединенных записей;

• успешные транзакции;

• возраст зависших транзакций;

• своевременная сверка;

• соответствие зарплаты;

• время ответа/решения;

• доля повторно открытых тикетов;

• ошибки в деньгах/данных;

• своевременные действия RCA.

Не следует использовать отдельно

• количество снятий;

• общая сумма выплат;

• количество аккаунтов с установленным приложением;

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

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

14. Персонал у клиентов/на местах

Каждому клиенту необходимо как минимум определить:

• спонсора или контактное лицо для управления;

• администратора списка;

• утверждающего рабочего времени и его замену;

• помощника по адаптации на смене;

• контактное лицо по зарплате/бухгалтерии;

• контактное лицо по инцидентам/эскалации.

При наличии нескольких смен, модель "посла на смене" помогает с инструктажем, но не должна хранить OTP, пароли или совершать транзакции вместо работников.

15. Обучение по ролям

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

16. План персонала при расширении

(Подробнее: Шаблон плана пилота доступа к заработанной зарплате и критерии расширения.)

Этап 1 — Увеличение числа пользователей

Проверка поддержки клиентов, сверки, баланса и ожидающего рабочего времени.

Этап 2 — Добавление клиентов

Оценка шаблонов рабочего времени, утверждающих и контактных лиц на месте.

Этап 3 — Увеличение автоматизации

Проверка мониторинга, on-call, аварийного отключения и распределения полномочий.

Этап 4 — Поддержка вне рабочего времени

Дизайн смен, надбавки, передача, эскалация и здоровье команды дежурных.

Не расширяйте охват, прежде чем нанять/назначить людей для обработки исключений.

17. Контрольный список для организации управления

• Назначен Владелец услуги.

• В RACI нет деятельности без "A".

• У утверждающего рабочего времени есть резерв.

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

• Есть человек, отслеживающий зависшие транзакции.

• Зарплата участвует с пилота.

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

• Техника/SRE имеет соответствующий on-call.

• Назначен Командир инцидентов.

• Юридические вопросы/Информационная безопасность имеют расписание обзоров.

• Рабочая нагрузка измеряется по типу исключений.

• Штат учитывает часы пик/конец периода.

• Каждая роль имеет runbook.

• Обучение и тренировки завершены.

• Расширение должно проходить через ресурсные ворота.

18. Часто задаваемые вопросы

Нужен ли специализированный персонал для пилота на 500 человек?

Можно использовать совмещенную команду, но все же необходимы Владелец услуги, утверждающий рабочего времени, платежи/сверка, зарплата, поддержка клиентов и назначенный on-call для техники.

Если система автоматизирована, зачем нужны Операции с платежами?

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

Нужна ли поддержка клиентов 24/7?

Зависит от окна транзакций и SLA. Если поддержка не 24/7, необходимо четко указать время ответа и иметь on-call для серьезных денежных инцидентов.

Кто должен быть Владелец услуги?

Человек, имеющий полномочия координировать HR, рабочее время, деньги, зарплату, технику и клиентов; не обязательно начальник IT-отдела.

Когда нужно увеличивать штат?

Когда превышены лимиты по бэклогу, возрасту исключений, SLA, переработкам или рискам разделения обязанностей — не только при увеличении числа пользователей.

---

Автор: Ngô Nhã Kỳ — Biên tập viên ban biên tập, Nhan Kiet Manpower Supply Co., Ltd.

Консультации по решениям доступа к заработанной зарплате для бизнеса: Горячая линия 0937.022.655 · Email info@nhankiet.vn · Доступ к заработанной зарплате для бизнеса