HR-дашборд в Power BI: как собрать витрину по найму и текучести
HR-дашборд по найму и текучести полезен тогда, когда он отвечает не на абстрактный вопрос «что происходит в HR», а на два конкретных: где замедляется комплектование и где компания теряет людей. Для такой задачи не нужен огромный кадровый портал. Нужна одна понятная витрина с согласованными определениями показателей, аккуратной моделью данных и визуализациями, по которым руководитель видит не только цифры, но и возможное действие.
В терминологии Power BI важно разделять отчет и панель мониторинга. По документации Microsoft, отчет создают на базе семантической модели и он может состоять из нескольких страниц. Панель мониторинга в службе Power BI — это одностраничное полотно с плитками, закрепленными из отчетов. Поэтому для HR-задачи логика обычно такая: сначала собрать модель и отчет в Power BI Desktop, затем при необходимости вынести ключевые визуализации на одностраничную панель в службе Power BI.
Какие вопросы должен закрывать дашборд
Перед загрузкой данных полезно зафиксировать, какие управленческие вопросы вы хотите закрыть. Для витрины по найму и текучести это обычно такие вопросы:
- как меняется скорость закрытия вакансий по периодам;
- на каком этапе найма теряется больше всего кандидатов;
- в каких подразделениях вакансии закрываются медленнее других;
- сколько людей вышло и сколько выбыло за период;
- в каких командах увольнения концентрируются сильнее;
- меняется ли картина по локации, менеджеру, типу занятости или должностной группе.
Если дашборд не помогает ответить именно на эти вопросы, он быстро превращается в набор карточек без управленческого смысла.
Минимальный набор источников
Технически Power BI позволяет подключаться к разным типам данных, а Power Query — повторяемо очищать и преобразовывать их. Для первого рабочего варианта HR-витрины достаточно минимального набора источников:
| Источник | Что взять | Для чего в отчете |
|---|---|---|
| ATS | Вакансия, дата открытия, этапы, кандидат, оффер, дата выхода | Воронка найма, скорость закрытия, статусы офферов |
| HRIS | Сотрудник, дата приема, дата увольнения, подразделение, должность, менеджер, локация | Приемы, увольнения, разрезы по оргструктуре |
| Excel-выгрузки | Справочник подразделений, причины увольнения, соответствия кодов и названий | Нормализация справочников и ручные сопоставления |
Такой набор не делает модель идеальной, но его достаточно, чтобы собрать узкий отчет для руководителя. Важно не загружать все поля подряд: лишние столбцы усложняют модель, но не улучшают ответы.
Как заранее договориться о метриках
По предоставленным источникам нельзя вывести единый обязательный стандарт HR-метрик. Поэтому для дашборда их нужно оформить как внутренние рабочие определения и закрепить до построения визуализаций. Ниже — не «единственно правильные» формулы, а шаблон для согласования.
| Показатель | Рабочее определение, которое можно согласовать | Что важно уточнить |
|---|---|---|
| Time-to-hire | В принятом здесь разделении — дни от попадания кандидата в воронку до принятия им оффера | Не смешивать с time-to-fill от открытия вакансии; дату фактического выхода учитывать как отдельную конечную точку и явно называть показатель |
| Offer acceptance rate | Доля принятых офферов среди офферов с финальным исходом | Нужно решить, входят ли в знаменатель офферы, которые еще в процессе |
| Turnover | Доля уволившихся за период относительно согласованной базы численности | Нужно определить, какую численность вы используете: среднюю за период, на начало или на конец периода |
| Voluntary turnover | Отдельный turnover только по добровольным увольнениям | Нужен справочник причин увольнения и единая группировка причин |
| Hires / Leavers | Количество выходов и количество увольнений за период | Нужно договориться, по какой дате считать событие |
Для самой витрины полезно завести отдельный короткий словарь показателей и показать его команде до первой публикации. Иначе Power BI будет считать корректно, но бизнес все равно начнет спорить с формулировками.
Для разграничения временных метрик используем объяснение Workable: time-to-hire рассматривает путь конкретного кандидата, а time-to-fill — заполнение вакансии. Учебный пример: вакансию открыли в день 1, кандидат вошёл в воронку в день 10 и принял оффер в день 25. Его time-to-hire — 15 дней. Если ваша ATS использует другую конечную точку, опишите её в словаре данных и не сравнивайте показатели по одному названию.
Какой должна быть модель данных
Таблицы фактов
Для этой темы удобно разделить модель на несколько фактов, а не пытаться хранить все в одной широкой таблице.
- Vacancies — вакансия, подразделение, рекрутер, дата открытия, дата закрытия, статус.
- Candidates — кандидат, вакансия, источник, этап, даты переходов, оффер, итоговый исход.
- Employees — сотрудник, дата приема, дата увольнения, подразделение, должность, менеджер, локация, тип занятости, причина увольнения.
Такое разделение уменьшает риск смешать уровни анализа. Например, офферы живут на уровне кандидата, а открытые позиции — на уровне вакансии.
Справочники и связи
- Calendar — предусмотренная в нашей модели таблица дат для помесячной динамики и сравнения периодов.
- Departments — нормализованные названия подразделений и, если нужно, иерархия бизнеса.
- TerminationReasons — группировка причин увольнения.
- Stages — этапы найма и их порядок.
Отдельное внимание нужно уделить датам. В одной сущности может быть несколько дат: отклик, оффер, выход, увольнение. Если все связать без плана, фильтрация начнет работать непредсказуемо. Поэтому заранее решите, какая дата активна для каждой таблицы и какие срезы должны управлять какими визуализациями.
Учебная схема ключей и направлений фильтрации
Далее — авторская модель небольшой HR-витрины на принципах звезды Microsoft. Предположим, строка Candidates соответствует одной заявке кандидата на конкретную вакансию и имеет уникальный ApplicationID; повторное обращение человека — другая заявка. В Employees для этого упрощённого примера одна строка на сотрудника, а увольнение и приём рассматриваются как события этой записи. Если возможны повторные наймы, сначала нужна модель эпизодов трудоустройства с отдельным ключом, иначе показатели будут смешаны.
| Сторона 1 | Сторона * | Условие примера |
|---|---|---|
| Departments[DepartmentID] | Vacancies[DepartmentID], Candidates[DepartmentID], Employees[DepartmentID] | Три отдельные активные связи; в справочнике один код на подразделение |
| TerminationReasons[ReasonID] | Employees[ReasonID] | Активная связь для разреза причин увольнения |
| Stages[StageID] | Candidates[CurrentStageID] | Текущий этап заявки; это не история всех переходов |
| Calendar[Date] | Candidates[ApplicationDate] | Активная связь для отбора заявок по дате отклика |
| Calendar[Date] | Candidates[OfferDate] | Неактивная связь для отдельного расчёта по дате оффера |
У сторон 1 ключи должны быть уникальными, типы ключей на обоих концах — согласованными. Для перечисленных связей выбираем одностороннее направление от справочника к факту. Не соединяем все факты друг с другом только ради общего фильтра: один и тот же срез подразделения может управлять ими через Departments. DepartmentID в событии должен отражать выбранное бизнес-правило, например подразделение на дату события; таблица связей сама не восстанавливает историю переводов.
В представлении модели создайте и проверьте каждую связь: столбцы, кардинальность 1:* и направление фильтра. После этого выберите одно подразделение и сверяйте одну конкретную заявку и одного сотрудника с источником. Если на стороне 1 оказались дубли, не переключайте связь на many-to-many лишь для исчезновения ошибки: сначала выясните, какой объект действительно уникален.
Несколько дат без неоднозначного среза
В нашем примере Calendar фильтрует заявки по ApplicationDate по умолчанию. Для меры количества офферов по OfferDate используем явно выбранную неактивную связь:
Offers by offer date =
CALCULATE(
COUNTROWS(Candidates),
USERELATIONSHIP(Calendar[Date], Candidates[OfferDate]),
Candidates[OfferDate] <> BLANK()
)Здесь одна заявка содержит не более одного учитываемого оффера; при нескольких версиях оффера нужен отдельный факт. USERELATIONSHIP использует соответствующую связь только для вычисления меры. Если руководителю нужны независимые одновременные срезы «дата отклика» и «дата оффера», создайте отдельные ролевые таблицы дат с активными связями вместо ожидания, что один календарь выполнит обе роли сразу.
Для Employees так же заранее выберите роль календаря: например, HireDate активна, TerminationDate неактивна для отдельной меры увольнений. Подсчёт численности на дату — другая логика по интервалу занятости, его нельзя получить простым количеством приёмов за месяц. Если используются ограничения RLS, отдельно учтите: по документации Microsoft фильтры RLS распространяются через активные связи, а USERELATIONSHIP не переносит их через неактивную.
Что делать в Power Query
Power Query, по документации Microsoft, сохраняет шаги преобразования как повторяемый запрос и не изменяет исходные данные. Для HR-витрины это удобно: один раз настраиваете очистку, затем просто обновляете.
- Подключите выгрузки из ATS, HRIS и Excel.
- Приведите типы данных: даты, текстовые поля, числовые признаки.
- Уберите дубли по сотрудникам, вакансиям и кандидатам.
- Нормализуйте названия подразделений, должностей и локаций.
- Разделите «склеенные» поля, если источник выгружает несколько значений в один столбец.
- Добавьте справочники причин увольнения и этапов подбора.
- Проверьте пустые идентификаторы и некорректные даты.
- Сформируйте календарную таблицу для анализа по периодам.
Частая практическая проблема — разные обозначения одной и той же сущности в разных системах. Например, в ATS подразделение хранится текстом, а в HRIS — кодом. В этом случае полезен отдельный справочник соответствий, а не ручные исправления в каждой новой версии отчета.
Какие визуализации подходят для этой витрины
Блок ключевых показателей
В верхней части страницы удобно разместить компактный набор карточек: открытые вакансии, согласованный показатель скорости найма, долю принятых офферов, hires, leavers и turnover. Если нужно, рядом можно показать изменение к прошлому периоду.
Воронка найма
Для ATS-части дашборда хорошо подходит воронка или столбчатая диаграмма по этапам. Она отвечает на практический вопрос: где именно теряется конверсия. Если просадка видна между оффером и выходом, проблема одна; если между откликом и первичным отбором — совсем другая.
Динамика увольнений
Для текучести полезна линейная диаграмма по месяцам. Рядом можно вывести разложение по типам увольнений, если в компании согласована такая классификация. Тогда видно не только общий объем выбытия, но и структуру.
Срезы по бизнес-разрезам
Минимально полезные фильтры — период, подразделение, локация, менеджер, должностная группа. Но здесь нужно помнить ограничение платформы: полноценная фильтрация и срезы работают в отчете; сама панель мониторинга Power BI как отдельный объект более ограничена. Поэтому для аналитической работы удобнее сам отчет, а панель использовать как короткий обзор.
Матрица для детализации
Нижним блоком полезно поставить матрицу по подразделениям: headcount, hires, leavers, turnover, открытые вакансии, статусы найма. Это помогает быстро перейти от общего сигнала к конкретной команде.
Где чаще ошибаются при интерпретации
- Смешивают уровни данных. Метрики по вакансиям, кандидатам и сотрудникам считают в одной таблице без понимания, что знаменатели у них разные.
- Используют текущую оргструктуру для прошлых событий. Тогда увольнение, случившееся в одной команде, в отчете внезапно оказывается в другой после перевода или реорганизации.
- Считают офферы “в процессе” как финальные. Это искажает картину по принятию офферов.
- Сравнивают периоды с разной структурой данных. Например, в одном месяце причина увольнения была обязательным полем, а в другом нет.
- Пытаются анализировать все на панели мониторинга. По документации Microsoft, dashboard в сервисе — это обзорная одностраничная сущность. Для поиска причин нужен отчет с детализацией.
Учебный пример: если на сводной панели видно рост увольнений в одном блоке, это еще не доказывает ухудшение удержания. Причина может быть в переносе сотрудников между подразделениями, изменении справочника причин увольнения или в том, что часть увольнений была занесена в систему пакетно в конце месяца. Поэтому сигнал с панели нужно проверять на уровне отчета и исходных таблиц.
Как настроить обновление и не сломать доверие к цифрам
Power BI поддерживает публикацию отчетов и плановое обновление в службе. Для HR-витрины это полезно только при одном условии: структура входных файлов должна быть стабильной. Если каждый месяц меняются названия столбцов, отчет станет хрупким независимо от качества визуализаций.
Минимальные правила обновления такие:
- зафиксируйте шаблон выгрузок из ATS и HRIS;
- проверяйте ключевые поля до обновления: employee_id, vacancy_id, даты приема и увольнения;
- показывайте на странице дату последнего обновления;
- после публикации сверяйте итоговые числа с операционными системами хотя бы по нескольким контрольным точкам.
Что показать бизнесу вместе с дашбордом
Даже хороший экран с графиками лучше сопровождать короткой интерпретацией. Руководителю обычно полезны три тезиса:
- Что изменилось. Например, замедлилось прохождение воронки на поздних этапах или выросло выбытие в конкретном блоке.
- Где риск. Например, под угрозой срок закрытия массовых вакансий или стабилизация команды в филиале.
- Что смотреть дальше. Не обязательно сразу давать готовое решение; иногда достаточно указать, какой этап, подразделение или справочник требует проверки.
Итоговая логика простая: HR-дашборд в Power BI по найму и текучести строится вокруг узкого круга вопросов, минимального набора источников, прозрачной модели и заранее согласованных определений. Тогда Power BI выполняет свою сильную роль — соединяет подготовку данных, модель, визуализацию и публикацию в одну управляемую витрину, а не в коллекцию несогласованных графиков.
