Что имеет смысл автоматизировать в HR и когда нужна собственная HRM-система

Автоматизация HR не равна покупке ещё одного сервиса

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

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

Поэтому первый вопрос для HR-автоматизации я бы формулировал не как «какую HRM-систему выбрать», а как «где один и тот же факт вводится или проверяется больше одного раза». Это намного быстрее показывает настоящую стоимость процесса.

У HRM должен быть понятный центр: кандидат и сотрудник

У CRM естественным центром обычно становится клиент, сделка или операционная заявка. У HRM логика другая: кандидат проходит подбор, становится сотрудником, получает роль и доступы, проходит адаптацию, меняет состояние внутри компании. Вокруг этого жизненного цикла уже появляются документы, обучение, показатели, события и интеграции.

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

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

Подбор часто ломается не в интерфейсе, а на интеграциях

Один из моих HR-проектов вообще не был «большой HRM». Это отдельный шлюз интеграций для HeadHunter и Avito. Задача звучала прозаично: управлять OAuth и токенами, создавать и переключать подписки, принимать webhooks, валидировать события и обогащать их данными внешних API.

На бумаге это несколько API-вызовов. В production быстро появляются другие вопросы: что делать с истёкшим токеном, как не потерять webhook, как повторить тяжёлую обработку после временной ошибки, как не превратить каждый HR-сценарий в отдельный скрипт.

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

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

Автоматизация начинает работать только тогда, когда система понимает состояния процесса. «Кандидат вроде согласован», «сотрудник почти оформлен», «документ уже отправляли» - нормальные человеческие фразы, но плохие состояния для программного контура.

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

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

Роли в HRM - это не только запрет на открытие страницы

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

В CRM управления наёмным персоналом роли и области видимости ограничивают сами рабочие сценарии. Система связывает исполнителей, контрагентов и объекты с заказами, заданиями, ставками и часами, начислениями, заявками на оплату, платёжными реестрами и документами сверки.

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

Нужна ли одна HRM на всё

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

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

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

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

Онбординг хорош как проверка связности системы

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

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

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

Что автоматизировать первым

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

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

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

• Выбрать один сквозной процесс, а не модуль из списка функций.
• Зафиксировать источник истины для кандидата или сотрудника.
• Описать состояния и ответственных за переходы.
• Отделить доменную логику от интеграций с внешними сервисами.
• Сделать ошибки и повторную обработку видимыми.
• Только после этого расширять контур на следующие HR-процессы.

Когда собственная HRM действительно имеет смысл

Я бы не начинал свою HRM только потому, что существующая система неудобная. Неудобный интерфейс часто дешевле исправить настройкой, интеграцией или сменой продукта.

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

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

Вопросы

Продолжить по теме

• Разработка HRM-систем
• Шлюз интеграций для HR-сервисов
• CRM управления наёмным персоналом

Другие статьи

• Когда бизнесу достаточно готовой CRM, а когда нужна собственная система
• Автоматизация бизнес-процессов: когда нужна своя система
• ИИ-агенты для бизнеса: от чат-бота к системе, которая выполняет действия