Когда HR приходит к ИТ-директору с запросом на автоматизацию найма, за этим, как правило, стоит не техническая задача, а управленческая. Рассмотрим, где такие проекты проваливаются, сколько реально стоят и как организовано внедрение, которое приносит измеримый результат.
Главное, что нужно проверить до старта
Большинство проектов по автоматизации найма не дают ожидаемого эффекта по одной причине: процесс, который пытаются автоматизировать, не описан. Нет чёткой последовательности шагов, непонятно, кто за что отвечает, информация между участниками передаётся устно и теряется по дороге.
Здесь важно понимать: автоматизация не исправляет процесс — она его закрепляет. Если внутри беспорядок, система просто зафиксирует этот беспорядок в цифровом виде, и он никуда не денется. Именно поэтому до выбора любого инструмента стоит честно ответить на простой вопрос: может ли HR-блок описать процесс найма пошагово, назвать ответственного на каждом этапе и объяснить, как принимается решение по кандидату? Если ответ неуверенный — сначала нужно выстроить сам процесс, и только потом искать под него инструмент автоматизации.
Роль HR: от исполнителя к владельцу продукта
HR-система сегодня — это не отдельное приложение, которое работает само по себе. Она встраивается в существующую инфраструктуру компании: интегрируется с кадровыми системами, корпоративным порталом, внутренними коммуникациями и почтой. Вместе с этой интеграцией сразу возникает вопрос, который раньше HR-проектов не касался: где и как хранятся данные. По требованиям
Всё это изменило не только технические требования к проекту, но и состав команды, которая принимает решение о внедрении. Раньше HR-директор выбирал систему самостоятельно — в лучшем случае согласовывал бюджет с финансами. Сейчас в проект входят юристы, безопасники, системные администраторы и аналитики. Сам HR-руководитель в этой команде занимает принципиально иную позицию. Всё чаще он выступает в роли product owner: формулирует требования, управляет внедрением как проектом и отвечает за результат перед бизнесом. Это принципиально другой уровень ответственности и другой уровень компетенций, который от него теперь требуется.
Где реально экономятся деньги
Многие компании ожидают, что после внедрения системы автоматизации стоимость подбора снизится. Через год обнаруживают, что цифра в бюджете осталась прежней — просто деньги переложились из одной строки в другую. Раньше уходили на джоб-борды, теперь уходят на лицензии, поддержку, интеграцию и обучение.
Реальная экономия достигается иначе — через скорость закрытия вакансий. Чем быстрее закрыта позиция, тем меньше часов рекрутер тратит на каждого кандидата и тем раньше новый сотрудник начинает приносить компании результат. На линейных позициях это особенно ощутимо: каждая незакрытая ставка напрямую влияет на операционные показатели, и потери от простоя легко посчитать в деньгах.
Проверить, происходит ли эта экономия на самом деле, можно одним вопросом: изменилось ли количество рекрутеров, которые нужны компании для обработки того же объёма вакансий? Если число осталось прежним, автоматизации не произошло. Система сделала работу рекрутеров чуть удобнее, но реальной эффективности компания не получила.
Именно поэтому метрики успеха нужно определять до старта, а не после. Для ИТ-директора важно ещё на этапе подготовки проекта определить метрики успеха: сколько компании стоит закрытие вакансии, сколько времени занимает найм, какой объём ручной работы выполняют рекрутеры, сколько систем участвует в процессе и во сколько обходится их поддержка. Без этих исходных данных оценить результат внедрения после запуска сложно.
Децентрализованная структура: как не утонуть в зоопарке систем
Компании с филиальной структурой сталкиваются с типичной картиной: у каждого подразделения своя система, свои данные, свои процессы найма. Один филиал работает в одной CRM, другой ведёт всё в Excel, третий вообще не знает, что у соседей что-то автоматизировано. Такое встречается уже в компаниях от 800 человек — это не история про корпорации-гиганты.
Попытка решить эту проблему одним махом — привести всё к единому стандарту одновременно — почти всегда заканчивается провалом. Подразделениям навязывают чужие процессы, и в ответ получают саботаж. Гораздо эффективнее начать с одного-двух департаментов, отладить там процесс, получить измеримый результат — и дать этим людям самим рассказать об опыте коллегам. Каждое следующее внедрение идёт быстрее: уже есть внутренние сторонники с живыми цифрами, и сопротивления значительно меньше.
При этом успех масштабирования во многом определяется архитектурой самой платформы. Важно выбирать систему, которая изначально рассчитана на такую гибкость: позволяет настраивать разные процессы для разных подразделений, не заставляя всех работать по единому шаблону. Но гибкость процессов не должна означать раздробленность данных. Для ИТ-директора принципиально, чтобы при различии процессов данные оставались централизованными. В противном случае компания получает не единую систему подбора, а ещё один набор несвязанных между собой баз данных и интеграций.
Внутренняя база кандидатов — недооценённый ресурс
У большинства крупных компаний накоплены базы кандидатов, которые не используются повторно. Люди подавали заявки год, два, три назад — их данные хранятся в системе, но в подборе не участвуют. Это одновременно юридический риск — избыточные персональные данные сверх минимума, установленного законом, — и упущенная возможность сократить затраты на привлечение новых кандидатов.
Между тем работа с внутренней базой даёт вполне конкретный эффект. В ритейле, например, при открытии новой точки географическая близость кандидата к месту работы — один из ключевых факторов успешного найма. Если данные о местоположении собраны, можно точечно реактивировать тех, кто живёт рядом, вместо того чтобы тратить бюджет на широкий таргет на внешних площадках.
В вахтовом найме работает другая логика, но результат тот же. Люди, которые уже работали в компании, возвращаются значительно охотнее новых кандидатов — просто потому что знают, чего ожидать. На практике работа с такой базой добавляет около 15% к воронке найма без дополнительных затрат на привлечение.
Для ИТ-директора это в первую очередь вопрос к архитектуре системы: умеет ли платформа работать с накопленными данными, строить по ним выборки и запускать автоматические сценарии повторного вовлечения кандидатов. Если нет — данные так и будут копиться мёртвым грузом, создавая юридические риски, но не принося никакой пользы.
Где сейчас граница между ИИ и человеком в найме
Во многих компаниях ИИ уже не просто помогает отбирать резюме — он ведёт первичный контакт с кандидатом: переписку, первые вопросы, проверку базовых критериев. Следующий уровень — уже не переписка, а полноценный анализ поведения кандидата в реальном времени. Системы анализируют видеоинтервью: отслеживают реакции кандидата, тембр голоса, эмоциональные маркеры и на основе этого формируют рекомендацию. Такие решения уже есть на рынке и активно внедряются.
При всём этом финальное решение о найме остаётся за человеком — и, судя по всему, останется там ещё долго. Задача ИИ в этой цепочке — собрать полную картину по кандидату, структурировать данные и подсветить ключевые факты. Задача рекрутера и нанимающего менеджера — принять взвешенное решение на их основе. Рутинная фильтрация уходит на сторону системы, а за рекрутером остаётся то, что алгоритм пока не умеет: оценивать человека в контексте команды и культуры компании.
Для ИТ-директора это означает, что запрос на интеграцию ИИ-инструментов в HR-контур — уже не вопрос будущего. Компании, которые сегодня внедряют автоматизацию найма, завтра придут с запросом на диалоговых агентов, видеоанализ и предиктивную аналитику по кандидатам. Инфраструктура должна быть к этому готова.
А значит, проекты автоматизации подбора давно вышли за рамки HR-функции. Они становятся частью общей цифровой архитектуры компании, а их эффективность зависит не только от возможностей системы, но и от того, насколько органично она встроена в существующие процессы, данные и корпоративные сервисы.
