В IT-компаниях данные о людях часто изолированы: рекрутеры ведут воронку в ATS, кадры оформляют отпуска и ставки в HRIS, а бухгалтерия начисляет выплаты и рассчитывается с подрядчиками в ERP. В результате на совещаниях C-level менеджеры оперируют несовпадающими цифрами: CTO видит нехватку разработчиков, CFO указывает на превышение бюджета ФОТ, а HRD не может сопоставить скорость найма с оттоком.
Сборка сквозного HR-дашборда решает эту проблему за счет объединения метрик численности, подбора и затрат в единую витрину данных. Главная сложность такого проекта — не выбор BI-системы, а выстраивание единого словаря терминов, очистка сырых записей и строгое разграничение прав доступа для соблюдения требований 152-ФЗ и сохранения конфиденциальности компенсаций.
Архитектура данных: связка HRIS, ATS и финансового контура
Для построения достоверного дашборда требуется объединить три независимых источника. Ошибки возникают тогда, когда аналитики пытаются забирать финансовые метрики из кадровой базы или рассчитывать факт выхода специалистов исключительно по данным ATS.
Полноценный пайплайн включает следующие уровни:
- 1. Первичные источники: кадровый учет (HRIS / 1C:ЗУП), рекрутмент (ATS), финансовый контур (ERP / 1С:Бухгалтерия).
- 2. Слой ETL и очистки данных: дедупликация, сопоставление сквозных ID сотрудников, валидация хронологии статусов, приведение к единой оргструктуре.
- 3. Корпоративное хранилище (DWH) и витрины: агрегаты по департаментам, локациям и грейдам, маскирование персональных данных (ПДн) и изоляция индивидуальных окладов.
- 4. BI и визуализация: применение правил Row-Level Security (RLS) и вывод тематических экранов (Численность, Подбор, Бюджет).
Кадровый контур (HRIS / 1C:ЗУП)
Первичная база для учета трудовых отношений. Из нее выгружаются:
- статус сотрудника (штат, декрет, отпуск без сохранения оплаты);
- тип занятости и доля ставки (0.5, 1.0);
- даты приема, перевода, изменения должности/грейда и увольнения;
- причина расторжения договора (по инициативе сотрудника, соглашению сторон, инициативе компании);
- привязка к департаменту, проекту и центру финансовой ответственности (ЦФО).
Рекрутинговый контур (ATS)
Системы управления кандидатами (Huntflow, FriendWork и др.) фиксируют динамику воронки:
- заявка на подбор (дата открытия, плановый грейд, профиль, инициатор);
- этапы прохождения кандидатов (скрининг, техническое интервью, финал, оффер);
- факт принятия или отклонения оффера с фиксацией причин;
- плановая и фактическая дата выхода новичка.
Финансовый контур (ERP / 1С:Бухгалтерия)
Контур фактических расходов, исключающий расхождения между плановым и реальным бюджетом:
- начисленная заработная плата, премии, бонусы и опционные программы;
- страховые взносы и налоговые отчисления;
- компенсационные пакеты (ДМС, спорт, курсы, компенсация коворкингов);
- прямые расходы на привлечение (бюджеты job-бордов, кадровые агентства, реферальные выплаты);
- оплата внешних исполнителей (договоры ГПХ, самозанятые, ИП, IT-аутстаффинг).
Единый словарь метрик для IT-компании
Разночтения в аналитике начинаются с разной трактовки базовых терминов. Ниже представлена матрица метрик, сформированная с учетом методологии кадрового учета и международного стандарта отчетности по человеческому капиталу ISO 30414.
| Блок | Метрика | Методология и формула расчета | Источник | Частота среза |
|---|---|---|---|---|
| Численность | Списочная численность | Количество сотрудников с действующими трудовыми договорами на конкретную дату среза. | HRIS | Ежедневно |
| Численность | Среднесписочная численность | Сумма списочной численности за каждый календарный день месяца / Количество дней месяца. | HRIS | Ежемесячно |
| Численность | FTE (Full-Time Equivalent) | Сумма долей ставок сотрудников (например: 2 разработчика по 0.5 ставки = 1.0 FTE). | HRIS | Ежемесячно |
| Численность | Чистый прирост (Net Headcount) | Количество принятых сотрудников за период минус количество уволенных. | HRIS | Еженедельно / Ежемесячно |
| Численность | Коэффициент текучести (Turnover) | (Уволенные за период / Среднесписочная численность) × 100%. Разделяется на добровольную и недобровольную. | HRIS | Ежемесячно |
| Подбор | Открытые вакансии | Количество активных заявок в статусе «В работе» на дату формирования отчета. | ATS | Ежедневно |
| Подбор | Возраст вакансии (Age of Job) | Текущая дата минус дата открытия заявки на подбор. | ATS | Еженедельно |
| Подбор | Время закрытия (Time to Fill) | Дата принятия оффера или фактического выхода минус дата открытия вакансии. | ATS + HRIS | Ежемесячно |
| Подбор | Конверсия этапов воронки | (Кандидаты на этапе N / Кандидаты на этапе N-1) × 100%. | ATS | Еженедельно |
| Подбор | Acceptance Rate офферов | (Количество принятых офферов / Общее число выставленных офферов) × 100%. | ATS | Ежемесячно |
| Затраты | Стоимость найма (Cost per Hire) | (Внешние затраты на каналы + Внутренний ФОТ рекрутмента) / Общее число нанятых. | ATS + ERP | Ежеквартально |
| Затраты | Общие затраты на персонал (TCoW) | ФОТ (оклады, премии) + Налоги + Бенефиты + Обучение + Рабочие места и софт. | ERP | Ежемесячно |
Регламент и частота синхронизации данных
Попытка перевести все HR-метрики в режим реального времени перегружает контуры интеграции и порождает методические ошибки. Разные пласты данных требуют индивидуального темпа обновления.
1. Ежедневный контур (Оперативный мониторинг)
- Состав данных: списочная численность, статусы открытых и закрытых позиций, кандидаты на финальных этапах, выставленные офферы.
- Цель: отслеживание оперативной загрузки рекрутеров и контроль комплектования критически важных для релизов команд.
2. Еженедельный контур (Тактическое управление)
- Состав данных: поэтапная конверсия воронки найма, динамика возраста вакансий, запланированные выходы, увольнения на испытательном сроке.
- Цель: своевременная переброска сорсинговых ресурсов и синхронизация с нанимающими менеджерами.
3. Ежемесячный контур (Стратегический и финансовый учет)
- Состав данных: среднесписочная численность, расчет FTE, коэффициенты оттока, закрытие фактического ФОТ, налоги, акты подрядчиков, TCoW.
- Методическое правило: финансовые показатели фиксируются только после официального закрытия расчетного периода в бухгалтерии (обычно 5–10 числа следующего месяца). Попытка вывести ФОТ в середине текущего месяца неизбежно выдает некорректную аналитику из-за отсутствия данных по премиям, больничным и перерасчетам.
Data Quality: алгоритмы проверки качества и валидации
Сырые выгрузки из кадровых баз и систем рекрутмента содержат пробелы и технические накладки. Без регулярных правил проверки качества данных (Data Quality Rules) дашборд быстро утратит доверие стейкхолдеров.
Обязательные автоматические проверки перед загрузкой в витрину:
- Проверка непрерывности и логики статусов:
- Кандидат отмечен как «Нанят», но вакансия в ATS продолжает числиться активной.
- Сотрудник уволен в HRIS, но числится ответственным за проведение технических интервью в ATS.
- Контроль хронологии дат:
- Дата направления оффера не может быть позже даты фактического выхода сотрудника.
- Дата увольнения не может предшествовать дате приема на работу.
- Длительность нахождения вакансии в работе не может принимать отрицательные значения.
- Валидация штатного расписания:
- Суммарный FTE по отделу в витрине не должен превышать лимит по штатному расписанию без системного флага превышения (Overbooking).
- Сверка кадровых и финансовых идентификаторов:
- Каждая транзакция начисления в ERP должна содержать валидный табельный номер сотрудника или реквизиты договора подрядчика. Записи без сквозного ID изолируются в отдельный журнал ошибок для ручной обработки.
Безопасность и 152-ФЗ: ролевой доступ и правила агрегации
Сведения о персонале содержат персональные данные (ПДн) и конфиденциальную финансовую информацию (индивидуальные ставки, надбавки, премии). Доступ к этим срезам строго регламентируется.
Модель распределения прав:
- Уровень 1. C-Level, HRD, CFO: Полный доступ к гранулярным финансовым данным, индивидуальным компенсациям, сквозным бенчмаркам и стратегической аналитике по всей компании.
- Уровень 2. Руководители дирекций и департаментов: Доступ строго ограничен своим подразделением через RLS-фильтры. Отображаются суммарный FTE, агрегированный бюджет отдела, текучесть и воронка найма без доступа к данным соседних блоков.
- Уровень 3. Тимлиды и нанимающие менеджеры: Доступ только к операционным метрикам подбора (статусы вакансий, воронка кандидатов, средний срок закрытия). Персональные оклады и общий ФОТ полностью скрыты.
Технические правила защиты информации:
- Исключение ПДн из аналитического слоя: ФИО, паспорта, контакты и адреса сотрудников отсекаются на этапе ETL. Аналитика оперирует суррогатными ключами:
employee_id,job_id,cost_center_id. - Row-Level Security (RLS): Механизм фильтрации строк на уровне базы данных или BI-платформы. Пользователь физически не может отправить запрос к данным, выходящим за пределы его зоны ответственности.
- Правило k-anonymity (защита от деанонимизации окладов): В небольших командах (2–3 человека) вывод показателя «Средний оклад» раскрывает точный заработок каждого инженера. Если размер выборки меньше заданного порога (рекомендуемый минимум: N < 5), система автоматически блокирует вывод финансовых показателей и текучести либо агрегирует их до уровня вышестоящего подразделения.
Проектирование интерфейса: структура аналитических экранов
Эффективный дашборд строится по принципу детализации от верхнеуровневых KPI компании к конкретным проблемным зонам через три ключевых экрана.
Экран 1: Executive Summary (Для генерального директора, HRD, CFO)
- Верхняя панель (KPI): Текущий FTE, процент укомплектованности штата, коэффициент текучести (LTM), отклонение фактического ФОТ от бюджета.
- Динамический блок: Линейный график чистого прироста численности (Headcount Change) в разрезе 12 месяцев.
- Оргструктура: Распределение штата по технологическим стекам (Backend, Frontend, QA, DevOps, Management) и центрам затрат.
Экран 2: Подбор и рекрутмент (Для нанимающих менеджеров и Lead Recruiter)
- Воронка подбора: Конверсия кандидатов по стадиям в разрезе направлений разработки.
- Структура возраста вакансий: Сегментация активных позиций по срокам (до 30 дней, 31–60 дней, свыше 60 дней) для локализации зависшего найма.
- Аналитика отказов: Диаграмма причин отклонения офферов кандидатами (уровень компенсации, несоответствие стека, контроффер текущего работодателя).
- Сроки закрытия: Показатель Time to Fill в разрезе грейдов (Junior, Middle, Senior, Lead).
Экран 3: Затраты и эффективность (Для CFO и HRD)
- Фактическая структура TCoW: Доли базовых окладов, бонусов, налогов, льгот и внешних подрядчиков.
- Юнит-экономика найма: Динамика Cost per Hire в сравнении с эффективностью каналов (реферальная программа, job-борды, агентства).
- Баланс ресурсов: Соотношение штатных специалистов и привлеченных подрядчиков (аутстаффинг/ГПХ) в общих трудозатратах компании.
Часто задаваемые вопросы (FAQ)
1. С чего начать создание дашборда, если в компании нет DWH, а данные хранятся в 1С и таблицах?
Сформируйте MVP на базе 5–7 критичных метрик: списочная численность, открытые заявки, текучесть и Time to Fill. Настройте регулярную автоматизированную выгрузку нормализованных таблиц из 1С и ATS в промежуточную реляционную базу данных (например, PostgreSQL) с валидацией типов данных, после чего подключите к ней выбранный BI-инструмент.
2. Как учитывать внешних IT-специалистов (аутстаффинг, ГПХ, самозанятые) в метриках численности?
Разделяйте показатели на Payroll Headcount (только штатные сотрудники по трудовым договорам) и Total Workforce (совокупный объем всех привлеченных специалистов). Для подрядчиков рассчитывается эквивалент занятости (Contractor FTE) на базе фактически отработанных часов по актам, а выплаты по договорам учитываются в отдельной статье затрат, чтобы не искажать среднюю зарплату штата.
3. Какой порог выборки использовать, чтобы предотвратить деанонимизацию зарплат?
Оптимальным порогом считается выборка от 5 человек. Если в фильтрах дашборда указан срез с меньшим числом сотрудников, дашборд должен программно блокировать отображение абсолютных и средних финансовых метрик, выводя уведомление о недостаточном объеме выборки.
4. Какой BI-инструмент выбрать для реализации HR-дашборда?
Выбор опирается на требования к безопасности и инфраструктуре:
- Apache Superset — open-source инструмент, разворачивается on-premise в закрытом контуре, поддерживает гибкое разграничение RLS на уровне SQL-запросов.
- Yandex DataLens — облачное решение с серверами в РФ, быстро интегрируется с корпоративными СУБД, подходит для оперативного построения отчетности без сложных ETL-пайплайнов.
- 1С:Аналитика — прямое расширение для инфраструктуры 1С, оптимизирующее работу при отсутствии внешнего хранилища данных.
5. В чем разница между Time to Fill и Time to Hire?
Time to Hire фиксирует скорость движения соискателя: от момента его первого контакта с компанией (отклика или сорсинга) до принятия предложения о работе. Time to Fill измеряет период закрытия бизнес-потребности: от даты утверждения заявки на подбор до фактического выхода специалиста на работу. Time to Fill всегда продолжительнее, так как включает предварительную подготовку требований и срок отработки кандидата на предыдущем месте.
Вывод
Построение работающего HR-дашборда в IT-компании опирается на три базовых принципа:
- Единый словарь метрик: формулы расчета FTE, текучести и стоимости найма утверждаются и фиксируются в документации до начала разработки визуализаций.
- Контроль целостности данных: интеграционные пайплайны снабжаются автоматическими проверками хронологии, соответствия штатному расписанию и финансовым кодам.
- Безопасность архитектуры: персональные идентификаторы маскируются на уровне ETL, а разграничение прав на базе RLS и правил агрегации исключает утечки персональных данных и условий оплаты труда.



.svg.webp)



