Спасибо, что вы с нами!
В крупных холдингах система подбора почти никогда не живет сама по себе. Она постоянно соприкасается с кадровым контуром, сервисом заявок, согласованиями, проверками, документооборотом, корпоративными коммуникациями и аналитикой.
Проблема обычно не в том, что нет интеграций, а в том, как именно они устроены. Статусы кандидата начинают расходиться между системами, документы появляются то в одном месте, то в другом, проверка службы безопасности живет отдельным процессом, рекрутеры ведут массовые коммуникации в сторонних каналах, а отчетность собирается сшиванием выгрузок. Вопрос, который в итоге задают и HR, и ИТ, звучит одинаково: как связать подбор с остальным ландшафтом так, чтобы процесс стал единым, а решение выдержало десятки юрлиц без ручного администрирования?
Расскажем, как договориться о данных, правах и источниках, как выстроить устойчивый обмен через программные интерфейсы и события.
Единая модель данных и источник истины для статусов
Если не зафиксировать, что такое вакансия, заявка, кандидат, этап воронки, оффер, выход, где у каждой сущности границы и владельцы, то любая связка превратится в бесконечные уточнения и расхождения. Внутри одной компании это еще терпимо, но когда подключаются десятки юридических лиц, каждая локальная трактовка начинает множиться, и вылезает типичный эффект: один и тот же человек в ATS уже «согласован», а в кадровой системе он всё ещё «на проверке», потому что где-то статус считается по факту действия, а где-то по факту документа.
Для такой задачи нужен общий словарь и понятные переходы между системами. В них фиксируются поля, правила заполнения, идентификаторы, допустимые переходы статусов, а также источник истины по каждому элементу. Например, документы сначала попадают в ATS (допустим, из анкеты кандидата), а оттуда уже в систему электронного документооборота. При этом ATS фиксирует факт и дату отправки в КЭДО.
Технически это часто решается через связку мастер-данных и событийной модели. Кандидат получает стабильный идентификатор, который не меняется при переводах между вакансиями и юрлицами. Справочники должностей, подразделений, локаций и юрлиц синхронизируются по оговоренным правилам, а ключевые изменения фиксируются как события, чтобы их можно было воспроизводить и проверять.
На практике после принятия решения по кандидату система подбора отдает в кадровый контур согласованный набор полей и событие, далее кадровая система отвечает подтверждением приема, а дальше обе стороны живут по одному сценарию без ручных перекидываний статусов. Единый процесс начинается не с интерфейсов, а с того, что HR и ИТ одинаково понимают, что именно считается фактом и где этот факт хранится. Например, в «Потоке» для этого есть двусторонняя интеграция с КЭДО: задается строго определенный этап, с которого передаются данные кандидата. При достижении этого этапа кандидат считается «принятым», а КЭДО может передавать в Поток данные по дальнейшему оформлению, трудоустройству и даже по увольнению, что важно для сценария повторного найма.
Интеграционный контур: API, события и устойчивость
Даже когда модель данных оговорена, следующий риск появляется на границах ответственности. Интеграция чаще всего ломается, когда меняется владелец процесса, обновляется внешняя система, появляются новые юрлица или начинается пик найма. Поэтому важно проектировать контур так, будто сбои неизбежны, но пользователи всё равно будут ожидать, что история кандидата останется цельной.
Содержательно хорошая интеграция для холдинга — это управляемая цепочка действий. Рационально все-таки разделять обмен на две части: быстрые запросы по программному интерфейсу для того, что нужно прямо в момент действия пользователя, и асинхронные события для того, что может обрабатываться фоном, но обязано быть доставлено и отражено в карточке кандидата. Поверх этого добавляется дисциплина промышленной эксплуатации: повторные отправки без дублей, версионирование контрактов, мониторинг очередей, журнал интеграционных ошибок с понятным маршрутом эскалации, тестовый контур, где можно прогонять изменения до выхода в прод.
Практически помогает подход, когда один и тот же сценарий много раз повторяется и его не приходится каждый раз изобретать заново. В холдингах часто встречается конструкция «система забрала данные, обработала, вернула результат», это может быть проверка службы безопасности, верификация документов, скоринг или тестирование. Если заранее задать стандартный формат запроса и ответа, привязку результата к статусам воронки и правила уведомлений, то запуск становится более предсказуемым и дешевле, а сопровождение проще, потому что интеграция ведет себя одинаково в разных юрлицах.
Безопасность и доступы: сегментация по юрлицам и оргструктуре
Система подбора для крупной компании со множеством юрлиц почти всегда попадает в зону повышенного внимания к персональным данным. Это и анкеты, и резюме, и результаты проверок, и переписка, и записи звонков, и документы. При этом реальность крупной компании отличается тем, что доступ редко ограничивается одной командой по вакансии. Есть юрлица, уровни оргструктуры, роли и исключения, и если не заложить этот слой сразу, то дальше он превращается в нескончаемую ручную настройку и постоянные риски утечек.
Здесь важны три вещи: ролевой доступ, ограничение видимости по оргструктуре и юридическим лицам, а также аудит действий. Ролевой доступ отвечает за то, что человек может делать и видеть: каких кандидатов, какие вакансии, какую информацию по кандидатам; может ли создавать вакансии или отклонять кандидатов, может ли видеть зарплату и т.д.
Сегментация по оргструктуре позволяет настроить вариант ролевой модели с опорой на оргструктуру компании. Например, чтобы руководитель вертикали автоматически мог видеть все свои вакансии, а также вакансии всех своих подчиненных, даже если в команду по вакансии его не включили. Это же позволяет быстро настроить видимость в привязке к юрлицам. Система сохраняет историю всех действий с кандидатами. А дальше уже по этим данным можно проверить, кто, что и когда делал.
Для холдинга особенно полезен подход, когда видимость вакансий и кандидатов ограничивается по оргструктуре, потому что это снимает типичную административную боль: не приходится постоянно пересобирать команды на каждую вакансию, а правила доступа остаются стабильными при масштабировании и ротациях.
Техническая реализация обычно опирается на корпоративные механизмы аутентификации и централизованное управление учетными записями, а для данных добавляются меры, которые помогают пройти комплаенс-проверки. Хороший пример из практики подбора — это деперсонализация кандидатов, когда можно массово деперсонализирововать из интерфейса или по API. Например, в «Потоке» безопасность или видимость вакансий по организационно-штатной структуре — это часть архитектуры, которая позволяет спокойно подключать новые юрлица без риска и нагрузки на администрирование.
Масштабирование без разрывов данных: массовый наём, коммуникации и ИИ
Когда интеграционный контур собран, на первый план выходит вопрос производительности процесса. Крупные компании почти всегда живут в двух режимах одновременно: точечный наём, где важна глубина и точность согласований, и массовый наём, где важны скорость, непрерывность коммуникации и отсутствие потерь воронки. И именно массовый наём быстрее всего показывает, где у системы слабые места: рекрутеры выгружают кандидатов в таблицы, звонят из отдельных сервисов, результаты остаются в сторонних журналах, а в ATS возвращается максимум комментарий без фактов, времени и ссылок.
Любые массовые действия должны происходить без переключения между системами и без потери истории кандидата. Поэтому интеграции с коммуникационными сервисами и телефонией лучше проектировать как продолжение карточки кандидата. Например, рекрутер выделяет группу откликов, отправляет их в очередь обзвона прямо из интерфейса ATS, дальше корпоративная телефония дозванивается по заданному сценарию, а по итогам разговора в карточке автоматически появляются факт звонка, статус, длительность, ссылка на запись, при этом подробная статистика прозвона хранится в телефонии, а в ATS остается ровно то, что нужно для воронки и контроля. В таком виде компания получает главное: история звонков и записи живут там же, где остальная история кандидата, а не разъезжаются по разным системам и файлам.
Удобно, если в ATS есть функционал, чтобы организовать проектный найм. Например, функция «Поток Рекрутмента» «Супервакансия и подвакансии» помогает нанять всех сотрудников на стройку или к открытию нового завода. В рамках одного проекта будут разные вакансии и можно по всему проекту смотреть закрываемость. При этом подвакансии остаются полноценными, по ним можно вести кандидатов и делать офферы, но сверху появляется единая группа найма, по которой удобно смотреть общую картину и собирать аналитику.
В дополнение к ATS в крупных компаниях также обсуждают внедрение ИИ-инструментов, так как они помогают ускорить работу HR-специалистов. Но ценность не в том, что есть отдельные умные функции, а в том, что они встроены в саму ATS и в процесс найма. Генерация текстов вакансий и сообщений уменьшает время на старт, автоматизированный поиск по крупным площадкам добавляет поток кандидатов без ручной рутины, оценка релевантности помогает быстрее разбирать входящий объем, боты для первичного скрининга снимают нагрузку на рекрутеров в пиковые недели. В таком виде ИИ перестает быть набором опций и становится способом держать скорость без потери качества, особенно когда масштабируется количество юрлиц и одновременно растет число вакансий. Тогда массовый наём выигрывает за счет связки ATS и ИИ-функций, которые ускоряют первый контакт с кандидатом. ИИ может сразу находить подходящих соискателей в холодном поиске, автоматически проверять их по требованиям и инициировать сообщение или звонок через бота. В итоге время до первого контакта сокращается до 5–15 минут с момента публикации резюме, что помогает выдерживать SLA (например, в ритейле) и повышает конверсию.
Первый шаг для холдинга
Если тема новая или только стартует в компании, то рекомендуем:
- зафиксировать базовый путь кандидата от отклика до выхода,
- отметить места, где теряются статусы, время и ответственность,
- определить источники истины для статусов, документов и проверок.
Эффективнее начать подготовку к внедрению с минимального набора интеграций, которые дают быстрый эффект и не ломают существующие процессы. Выбрать приоритетные сценарии, согласовать требования по безопасности и доступам.
Интеграция ATS в ИТ-ландшафт холдинга действительно требует экспертизы — и это как раз то, что команда «Потока» берет на себя. Мы уже внедряли HR-платформу в крупных компаниях уровня билайна, Велесстроя и Самоката и хорошо понимаем, как сделать так, чтобы ATS быстро и безопасно встала в контур.
Всё сводится к понятной последовательности шагов: договориться о ключевых данных и владельцах, собрать устойчивый интеграционный контур (с наблюдаемостью, прозрачной ответственностью и корректными доступами), а затем масштабировать рабочие сценарии, которые убирают разрывы в массовом найме. В результате ATS начинает работать как часть кадрового контура, а не как отдельный рекрутинговый инструмент. И жизнь становится проще и для HR, и ИТ, и службы безопасности.
Текст подготовила Елена Можелис, продуктовый редактор «Потока»
Статья выпущена в феврале 2026 года
