Обычно разговор об аналитике в HR начинается с благих пожеланий: «Давайте оцифруем компетенции», «Построим дашборд удовлетворенности». Заканчивается это часто стандартно: выгрузкой Excel-таблиц из ЗУПа, ручным копированием резюме из Outlook в папку «Кандидаты – зима – 2025(финальная версия)2» и бесконечными правками.
В этой статье мы посмотрим на HR-данные как на продукт: со своей архитектурой, контрактами и ответственными за результат. Поговорим о том, как построить пайплайн, который в реальном времени показывает не абстрактную статистику, а реальную динамику бизнес-процессов.
Анатомия хаоса: что обычно течет в HR-пайплайне
В большинстве компаний HR-ландшафт состоит из множества разнородных систем. Обычно там:
-
АИС «Кадры» (она же 1С:ЗУП или что-то легаси). Тут живут штатное расписание, оклады, приказы. Данные статичны, обновляются постфактум.
-
ATS (системы отбора). Talekh, WebiTour, просто гугл-формы или самописный портал. Здесь кипит жизнь: воронки, этапы, отказы, офферы. Это про будущее компании.
-
LMS (системы обучения). Разрозненные курсы, тесты, SCORM-пакеты, разбросанные по разным порталам.
-
Трекеры задач (например, Jira или Digital Q.Tasks&Teams) фиксируют цифровую активность сотрудников: коммиты, изменения статусов задач, запуск сборок и другие действия в рамках работы над проектом.
-
Культура и обратная связь. Смесь eNPS-опросов, лайков в корпоративном портале и данных с «Виртуального ассистента».
Соединить это вручную в устойчивом и масштабируемом виде – задача нетривиальная. Строить очередной табель учета в Excel – бессмысленно. Идеальная ситуация для IT-специалиста – когда ключевые HR-процессы унифицированы или имеют предсказуемую структуру данных и единый API для интеграции.
Для этого мы в «Диасофт» используем платформу Digital Q.HCM, где собраны процессы подбора, адаптации, обучения, оценки, развития кадров.
В реальности чаще приходится строить слой абстракции поверх разнородных систем. Поэтому дальше будем рассматривать общий случай – построение пайплайна поверх действующих сервисов.
Обеспечение SLA для HR-данных через real-time пайплайн
После того как мы зафиксировали текущий ландшафт, следующий шаг – обеспечить качество, предсказуемость и непрерывность данных. То есть выполнить требования SLA: информация должна быть точной, своевременной, измеримой и доступной для аналитики и оперативных процессов.
Чтобы этого добиться, нужно отказаться от пакетной загрузки раз в сутки. Real-time в HR дает возможность запускать процессы и фиксировать события практически моментально.
Допустим, кандидат перешел на этап «Оффер» – это событие. Сотрудник написал заявление на увольнение – событие. Менеджеру назначено обучение – событие. Каждое такое изменение должно попадать в пайплайн сразу.
Технически мы это реализуем через Change Data Capture (CDC) и потоковую обработку событий: изменения снимаются из источников и доставляются дальше в реальном времени.
Однако в большинстве HR-ландшафтов, особенно с легаси вроде 1С, CDC редко доступен «из коробки». Почти всегда это набор компромиссов: использование штатного механизма регистрации изменений 1С, опрос через OData/API или репликация на уровне БД. При этом real-time не отменяет необходимости контроля качества: в пайплайн стоит встроить валидацию схемы и бизнес-правил, чтобы «быстро» не означало «быстро и с ошибками».
Поэтому real-time – не результат первого спринта, а целевая архитектура, к которой система постепенно приходит по мере устранения ограничений легаси.
Архитектура «правильного» пайплайна
1. Слой сбора (Source Layer)
Здесь мы не трогаем продуктивные базы прямыми запросами, чтобы не нарушить работу ЗУПа и других операционных систем.
Ставим легковесные коннекторы (Debezium для PostgreSQL/MS SQL и других БД, поддерживающих CDC) или парсеры логов/шедулеры для систем без real-time API, с перспективой перехода на Webhook, когда системы «дорастут». Для современных систем с REST API используем Kafka Connect с соответствующим коннектором.
Если повезло, и у вас все HR-процессы живут в одной HCM-платформе, слой сбора упрощается: данные уже имеют согласованную структуру и доступны через единый API. Но в реальности чаще приходится поддерживать множество коннекторов.
2. Слой брокера (Message Bus)
Все события отправляем в брокер сообщений. В российских реалиях это чаще всего Apache Kafka или совместимые брокеры (RabbitMQ с плагинами), используемые в крупных enterprise-ландшафтах.
Брокер выполняет роль «памяти» и буфера. При этом критически важно, чтобы схема данных была формализована и версионировалась – через Schema Registry, Avro/Protobuf или строго описанные JSON-контракты. Иначе через месяц никто не вспомнит, что означало поле emp_status = A.
3. Слой потоковой обработки (Stream Processing)
Здесь происходят операции обогащения событий. Например, событие «Кандидат нанят» из ATS объединяется с данными о распределении по команде и информацией об обучении из LMS.
Выбор инструмента для потоковой обработки зависит от сложности задач: для простых агрегатов можно использовать KSQL (ksqlDB). Сложные оконные операции лучше реализовывать на Apache Spark Structured Streaming или Flink. Для создания материализованных представлений, которые отражают текущее состояние сотрудников почти в реальном времени, обычно используют ksqlDB, State Tables во Flink или Materialized Views в ClickHouse.
4. Слой санитарной зоны (Serving Layer).
Данные очищены, обогащены и готовы к использованию. Далее есть два направления.
Для аналитических задач – таких как расчет воронок найма, удержания или стоимости подбора – данные подгружаем в OLAP-систему, где аналитики строят отчеты, не нагружая операционные системы.
Параллельно формируем OLTP-витрину (PostgreSQL, Redis) для оперативных HR-задач: например, чтобы в реальном времени проверять, активна ли учетная запись сотрудника или какие задачи назначены конкретному специалисту. Также эта витрина питает дашборды внутри HCM-системы.
Особенности enterprise: с чем придется побороться
Теперь об остром. Почему большинство HR-пайплайнов разваливаются?
Проблема первая: мастер-данные (MDM) сотрудника
У вас Иван Петров в ATS – это ivan.p@email, в Active Directory – Ivan.Petrov, в расчетном листке – «Петров Иван Иванович», а в Jira – Neo. Без мастер-ключа данные либо не свяжутся, либо свяжутся с ошибками – и аналитика станет недостоверной.
Единственный рабочий вариант – внедрить единый идентификатор сотрудника (табельный номер, Employee ID из HCM или унифицированный уникальный email) и требовать его от всех поставщиков данных как обязательный стандарт. В этой модели HCM-система (или отдельный MDM-сервис) становится естественным источником мастер-данных.
Проблема вторая: темные данные
Что такое «причина увольнения» в базе? Это небольшая анкета из трех пунктов, которую менеджер заполняет «на автомате». Реальная причина почти всегда остается за пределами системы.
Рабочий подход здесь – не пытаться вытянуть правду из одного поля, а моделировать вероятности. Косвенные признаки часто говорят больше прямых формулировок:
— резкое падение продуктивности в Jira за пару недель до увольнения;
— прекращение участия в митингах;
— отсутствие прогресса по ИПР;
— аномальный рост переработок.
Когда эти сигналы собираются в едином пайплайне, можно предупредить HR еще до заполнения формальных полей. В реальном времени это позволяет строить модели удержания и оперативно реагировать. Важно отметить, что такие модели должны использоваться этично – с информированием сотрудников и для поддержки, а не для превентивных санкций.
Проблема третья: скорость против точности
Отчеты по эффективности часто нужны «еще вчера», а данные обычно «доезжают» с задержкой. В итоге аналитика формально верная, но к моменту, когда цифры сходятся, управлять по ним уже бессмысленно.
Нам помогает простой прием – не смешивать ожидания и факт. В пайплайн сразу закладывается модель двух версий данных. Сначала приходят быстрые, предварительные данные (estimated): плановая загрузка команд, ожидаемые показатели, гипотезы. Позже, когда период закрыт, они обновляются фактическими значениями (actual). Это позволяет видеть динамику и отклонения в моменте, не дожидаясь финальной сверки.
Технически это реализуется через через SCD Type 2 (хранение версий записей) или отдельные колонки plan_value / fact_value в одной таблице. Главное – чтобы аналитики и дашборды умели с этим работать и не вводили пользователей в заблуждение.
Метрики на конвейере: что считаем в реальном времени
Когда пайплайн построен как поток событий, метрики перестают быть постфактум-отчетами и превращаются в триггеры действий.
Time-to-Hire в моменте. Не средняя температура по больнице, а конкретное время прохождения каждого этапа сейчас. Если на этапе «Техническое интервью» кандидат висит 5 дней – это не проблема рекрутера, это проблема занятости тимлида. Пайплайн генерирует событие, которое триггерит алерт тимлиду через систему уведомлений.
Реактивация кандидатов (Talent Rediscovery). Уволился разработчик. Система видит: ставка открыта. Событие ухода запускает поиск в базе кандидатов, которые уже были на рассмотрении 2 месяца назад, но им не позвонили. Пайплайн поднимает их в топ, а рекрутер получает задачу возобновить контакт.
Риски увольнения. Модель на основе косвенных признаков (падение активности, пропуски митингов) генерирует событие «высокий риск» и отправляет уведомление HR.
В идеале метрики должны быть рабочим инструментом, а не отчетом по запросу. То есть руководитель не просит аналитика собрать сводную информацию, а заходит в дашборд и видит актуальные показатели, которые обновляются автоматически.
Заключение: вместо HR-аналитики – HR-инжиниринг
HR дата-пайплайн, который действительно работает, превращает кадровую службу из регистратора фактов в регулятор бизнес-процессов. Это система, которая не просто отвечает на вопрос «сколько людей уволилось?», а позволяет заранее увидеть, где упадет производительность, и перебросить ресурсы.
Строить такой пайплайн – задача не для HR-отдела. Это задача для системных архитекторов, которые не боятся залезть в легаси, подружить его с Kafka и выдать на-гора чистый поток данных.
Если у вас уже есть HCM-платформа, которая предоставляет единый API и согласованную модель данных, – это сильно упрощает жизнь. Но даже если вы имеете дело с классическим «зоопарком сервисов», описанные архитектурные принципы (CDC, брокер, потоковая обработка, разделение promised/actual) остаются универсальными и реализуемыми на любом стеке.
P.S. В комментариях предлагаем поделиться, используете ли вы пакетную загрузку или graph-based MDM или в целом считаете, что HR-аналитика не так уж и важна?
ссылка на оригинал статьи https://habr.com/ru/articles/1027616/