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

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

Привет, я Антон Фокин — CEO Qtim

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

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

В опросе HRtech-платформы Jinn участвовали 515 представителей российских компаний: HR-директора, HRBP и HR-специалисты. Это данные опроса, а не измерение всего рынка. Они задают контекст для разговора о кадровой автоматизации, а решение о платформе всё равно начинается с конкретного маршрута внутри компании.

Возьмём один переход сотрудника: руководитель подтвердил новую роль, HR готовит изменение условий, ИТ выдаёт доступы, а бухгалтерия ждёт дату действия. Участники работают в разных сервисах, но переход у них один. Платформа не заменяет эти сервисы: она удерживает порядок событий и подтверждённый результат каждого из них.

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

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

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

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

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

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

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

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

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

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

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

У такого подхода есть ещё одно преимущество: его можно измерить. До запуска команда выбирает одну наблюдаемую величину — время до выдачи доступа, число возвратов документа на доработку или долю переходов без ручной сверки. В опросе Jinn только 47% участников измеряли эффект от HR-автоматизации. Поэтому метрику полезно определить до выбора интерфейсов и интеграций. Тогда проект отвечает на вопрос о процессе, а не на вопрос о том, насколько красиво выглядит новый кабинет.

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

Именно такие маршруты мы берём за основу при разработке SaaS-платформ: один источник состояния вместо поиска по нескольким каналам.