При работе с дашбордом по подобру персонала дошло дело до расчета загруженности рекрутеров. На одной заявке много вакансий, на одной вакансии много рекрутеров. Один рекрутер, разумеется, работает по нескольким заявкам. Как посчитать реальную работу каждого сотрудника?

Как было раньше: руководители выгружали отчет из СРМ в виде эксель файла, в котором была детализация на уровне заявки. В ней же информация о том, сколько вакансий в рамках этой заявки, сколько уже наняли, сколько еще нужно нанять (потребность). В ней же одна ячейка, в которой перечислены все участвующие рекрутеры и сам руководитель. Принято решение всю загрузку считать просто пропорционально между всеми рекрутерами, работающими по заявке/вакансии.

Это значит, что если в строке указано, что по данной заявке работают три рекрутера, и уже наняли 9/15 человек, то каждый из них работает по 0,33 заявки и нанял по 3 человека, и каждый должен нанять ещё по 2 человека. И неважно, кто и сколько действительно работал.

Мой долг на этом этапе убедиться, что этот расчёт всех устраивает и предложить альтернативу. Мне казался такой подход не справедливым, но хозяин - барин.

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

Условно у каждого кандидата было 10 статусов, и передвинуть его мог только кто-то из рекрутеров, например, если у кандидата два этапа: «Отбор» и «Звонок» то рекрутер совершил два действия: разобрал отклик и позвонил. Посмотрев на общее количество таких действий в рамках каждой вакансии и заявки можно было рассчитать долю реального вклада рекрутера.

Схему предварительно одобрили все руководители. Казалось, что мы нашли более честный способ. Но когда мы передали результат в тестирование, оказалось, что это всё ещё не совсем то, что нужно.

Во-первых, статусы неравнозначны. Довести кандидата до двух офферов гораздо ценнее, чем сделать десять отказов при разборе отклика (да и времени занимает больше). Во-вторых, при разных обстоятельствах во время отбора кандидат мог многократно двигаться между статусами (в том числе возвращаться назад, и несколько раз проходить один и тот же этап). Формально это увеличивало эффективность рекрутера, хотя причина могла быть совсем не в нём. Например, проблемы с документами. В-третьих, сама модель требовала ещё доработки. Но, как часто это бывает, у заказчика уже не было времени. В итоге всё осталось по старому.

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

А вы сталкивались с тем, что метрика кажется справедливой, но бизнес её не принимает?