Как HRD выбрать архитектуру HR-Tech:

Что должно быть в центре HR-Tech

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

При таком выборе ядро системы лучше определять по данным и ответственности. В нем должны оставаться:

• заявка на подбор и согласованные требования к роли;
• карточка кандидата или сотрудника;
• текущий статус и история изменений;
• владелец процесса и права доступа;
• показатели, по которым руководитель оценивает результат.

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

Российское исследование hh.ru, результаты которого опубликовал CNews, хорошо показывает разницу между отдельным инструментом и системой. В опросе участвовали 1314 представителей компаний. 57% работодателей сообщили, что используют ИИ для HR-задач, но только 4% применяют его повсеместно. Еще 27% подключают такие инструменты время от времени, без четкой стратегии.

Для HRD это сигнал о зрелости процессов: команда может пользоваться несколькими сервисами, но при этом не иметь единого порядка работы с данными. Поэтому выбор HR-Tech начинается с вопроса о центре управления, а не с длинного списка функций.

Когда одной платформы достаточно, а когда нужна связка инструментов

В статье Josh Bersin о multi-agent AI для подбора описан показательный сценарий. Один агент отвечает на вопросы кандидатов, другой проводит интервью, а собранные данные сохраняются в ATS и используются на следующих этапах.

Такой сценарий показывает принцип выбора архитектуры: HR-Tech оценивают по тому, как решения соединяются вокруг процесса. Отдельный инструмент приносит пользу, когда возвращает результат в основную систему и не создает параллельную базу.

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

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

Перед подключением такого решения полезно проверить три вещи:

1. какой результат оно возвращает в основную систему;
2. какие данные ему нужны для работы;
3. кто отвечает за ошибку, пропуск или изменение этого результата.

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

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

Интеграция начинается с правил данных

CNews Analytics в анонсе обзора «Рынок HR Tech 2026» объединяет в одной повестке защиту персональных данных, КЭДО, аналитику, рекрутинг, ИИ и интегрированные HR-коммуникации. Для HRD это важное сочетание: архитектура связывает программы, требования к данным, доступам и ответственности.

До обсуждения API и технических настроек нужно договориться о пяти правилах.

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

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

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

Минимальный обязательный набор данных. Сервису передаются только те сведения, которые нужны для конкретной задачи. Это снижает количество дублей и упрощает контроль доступа.

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

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

Такая схема связывает подбор с последующими этапами. Материал «Как довести найм до результата: оффер и первые 90 дней» показывает, почему сведения о роли, договоренностях и первых месяцах работы должны возвращаться в найм. Это уже вопрос архитектуры данных: информация о сотруднике продолжает жить после закрытия вакансии.

Экономику решения тоже нужно считать на уровне всей связки. В статье «Стоимость найма: как измерить эффект автоматизации» разобраны затраты и показатели пилота. При выборе HR-Tech к ним добавляется стоимость ручного переноса, поддержки интеграций, дублирования данных и изменений процесса.

Если свести решение к четырем сценариям, получится такая матрица:

Архитектура HR-Tech становится понятной, когда у каждого решения есть свое место. Платформа хранит основу процесса, точечный инструмент усиливает отдельную функцию, а интеграция связывает результат с общей системой. Так HRD получает управляемую цифровую среду и может объяснить бизнесу, как каждый элемент влияет на работу HR.