Обычно разговор об аналитике в 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‑аналитика не так уж и важна?