Кадровые процессы без почтовых цепочек: когда компании нужна платформа
У HR в таблице стоит «оформление завершено». Руководитель отдела просит открыть доступ к новой системе. В почте лежит версия дополнительного соглашения с замечанием. Бухгалтерия ждёт, когда получит подтверждённые данные. Это одна история сотрудника, но таблица, почта и учётная система показывают разные статусы.
Сбой начинается не в момент, когда кто-то забыл поставить галочку. Он возникает раньше: таблица, почта, КЭДО и учётная система одновременно считают себя источником правды. Команда тратит время на сверку. Сотрудник ждёт. Руководитель не может понять, какое действие действительно следующее.
Мы смотрим на кадровый контур как на набор решений, которые должны пережить обсуждение. У решения есть объект, текущее состояние, основание, владелец следующего шага и след в истории. Почта остаётся полезной для вопроса и уведомления. Таблица помогает с разовой сверкой и анализом. Когда действие меняет статус сотрудника, документ, доступ или срок, ему нужен управляемый контур.
В опросе HRtech-платформы Jinn участвовали 515 представителей российских компаний: HR-директора, HRBP и HR-специалисты. Это данные опроса, а не измерение всего рынка. Они задают контекст для разговора о кадровой автоматизации, а решение о платформе всё равно начинается с конкретного маршрута внутри компании.
Шесть операций, которым нужен общий статус
Кадровая платформа не обязана сразу заменять все привычные сервисы. Её первая задача — собрать в одном месте переходы, которые запускают следующее действие или меняют права человека.
Таблица в этой схеме не исчезает. В ней удобно сравнить нагрузку по подразделениям или подготовить импорт. Почта нужна, чтобы обсудить нестандартный случай. Система хранит результат обсуждения: какой вариант выбрали, кто его подтвердил, когда он вступает в действие и кому теперь нужно действовать.
Отдельного внимания требуют документы. Файл со статусом «загружен» редко отвечает на вопрос команды. Нужны как минимум тип документа, действующая версия, этап проверки, доступ и событие, которое переводит его дальше. Иначе в день оформления приходится искать «последний финальный» файл среди нескольких цепочек писем.
С доступами работает та же логика. Запрос «откройте сотруднику систему» становится управляемым действием, когда рядом видны основание, роль, срок и владелец отзыва. Это не призыв строить отдельный сервис ради каждой учётной записи. Такая запись нужна в маршрутах, где ошибка в правах останавливает работу следующей команды или оставляет лишний доступ после изменения роли.
Решение живёт дольше переписки
Представим обычное изменение: сотрудника переводят в другую команду. Руководитель подтверждает переход, HR обновляет условия, ИТ выдаёт доступы, а бухгалтерия получает данные для следующего расчётного периода. В переписке все участники могут договориться быстро. Через две недели возникает новый вопрос: когда решение вступило в силу, какой документ действовал, кто подтвердил выдачу доступа и дошла ли информация в учёт.
Для платформы это один маршрут с несколькими событиями. У него есть карточка сотрудника, статус перехода, правила доступов, связанные документы, список владельцев и журнал действий. Важно, чтобы следующий участник видел подтверждённое состояние, а не восстанавливал его по теме письма.
Мы не советуем превращать в сущность каждый комментарий. В продукт попадает решение, которое влияет на другой шаг. Например, «согласовано изменение роли с 1 ноября» запускает документ, набор доступов и уведомление следующему владельцу. «Обсудили варианты с руководителем» остаётся сообщением, пока не изменяет маршрут.
Причину, согласующего, срок и условие закрытия исключения лучше фиксировать рядом с процессом. Тогда временная договорённость не остаётся в закрытом чате после того, как команда сменилась или сотрудник ушёл в отпуск.
Где заканчивается таблица
Таблица справляется, когда маршрут короткий: один владелец видит поток целиком, статусы меняются редко, доступы не требуют отдельного учёта, а ошибку легко заметить в тот же день. В таких условиях разработка платформы будет преждевременной.
Порог появляется, когда для ответа «что происходит со сотрудником сейчас» нужно открыть несколько каналов. Ещё один признак — процесс передаётся между HR, руководителем, ИТ, бухгалтерией или безопасностью. В этот момент проблема уже не в форме анкеты. Она в том, что у перехода нет единственного владельца и подтверждённой записи.
- Где находится текущий статус и какое событие его изменило?
- Кто владеет следующим шагом и как видно просрочку?
- На каком основании выдали доступ, подписали документ или передали данные дальше?
- Как восстановить историю, когда участник процесса недоступен?
Ответ «в переписке» сам по себе не приговор. Он показывает точку, где команда пока зависит от памяти конкретного человека. Если таких ответов несколько, маршрут пора описать как продуктовый процесс.
Первый релиз не должен повторять всю HR-систему
Полный кадровый контур выглядит дорогим и долгим. Поэтому мы начинаем с одного маршрута, где разрыв уже заметен. Подходит, например, последовательность «приём → документы → доступы → изменение условий → выход». Для неё фиксируют роли, состояния, события, интеграции и исключения. Остальные функции остаются в привычных системах до тех пор, пока не становятся частью этого маршрута.
Такой подход можно измерить. До запуска команда выбирает одну наблюдаемую величину: время до выдачи доступа, число возвратов документа на доработку или долю переходов без ручной сверки. В опросе Jinn только 47% участников измеряли эффект от HR-автоматизации. Поэтому метрику полезно определить до выбора интерфейсов и интеграций.
Вернёмся к строке «оформление завершено» из начала статьи. Для процесса этого недостаточно. Команде нужны подтверждённый документ, назначенные доступы, переданные данные и владелец финального перехода. Пока эти события живут в разных каналах, участники видят разные статусы и сверяют их вручную.
Именно такие маршруты мы берём за основу при разработке SaaS-платформ: один источник состояния вместо поиска по нескольким каналам.
