Как с помощью WIP лимитов Kanban повысить эффективность работы отдела рекрутинга
Бытует мнение, что Kanban — это очень сложный метод. Действительно, в нем значительно больше различных нюансов, чем в том же Scrum. Но в этом и заключается его ценность — более обширная сфера применения и возможность влияния на большее количество аспектов управленческой работы, чем у его более популярного “конкурента”.
Тем не менее, пугающая многих сложность, на мой взгляд, сильно преувеличена. Все зависит от языка описания. Этой статьей я начинаю серию публикаций, в которых подробно разберу каждый из инструментов Kanban. По возможности максимально простым языком и на примерах не из мира IT.
Заранее оговорюсь: я — консультант, управленец и специалист в Kanban. Все кейсы для статей буду брать из опыта своих клиентов. Поэтому не готов буду спорить о профильных аспектах обсуждаемых процессов. Что клиент у себя построил, с тем и работаем :)
Сегодня на примере отдела рекрутинга поговорим о необходимости ограничивать объем одновременно выполняемой работы (Work in progress limits). Одном из основных условий внедрения Kanban.
Как чаще всего выглядят стадии найма персонала в компании среднего размера?
От “бизнеса” поступают заявки на закрытие различных вакансий. По мере возникновения они сыпятся в общий Беклог работы отдела рекрутинга. Далее, в зависимости от профиля позиции и правил компании, в различной последовательности могут проходить этапы поиска и отбора резюме, проверки кандидатов службой безопасности, первичного интервью, ряда профильных интервью со специалистами компании и финальное общение с руководителем.
Последовательность этапов для нас сейчас не столь важна. В каждой компании есть свои нюансы. Для нас важно понять как именно организован сам процесс работы над заявкой и что влияет на его эффективность.
Обычно все начинается с того, что наш рекрутер (назовем ее Леной) берет в работу заявки из общего списка отдела. Берет сама или их назначает руководитель, сейчас тоже не принципиально. Вопрос в том, какое количество заявок находится в работе у Лены одновременно?
Допустим, наша Лена — очень ответственный сотрудник. Она знает, что в текущий момент от разных департаментов поступило 10 заявок, каждая из которых является срочной и важной для бизнеса. Чтобы принести максимальную пользу компании, Лена принимает решение работать над всеми ними одновременно (М-многозадачность). Она расставляет приоритеты и начинает поиск резюме.
И тут возникает первый вопрос — совпадают ли расставленные Леной приоритеты с приоритетами компании?
И даже если эти приоритеты расставил ее руководитель, который осведомлен о них значительно лучше, у Лены, как у любого живого человека, могут быть позиции, которые ей нравятся больше остальных, и те, что меньше. Те, в которых она — спец, и те, в которых она “плавает”.
Поэтому, даже если приоритеты расставлены правильно, неосознанно Лена качественнее и быстрее обработает своих “фаворитов”, а остальные имеют большие шансы “зависнуть”.
Особенно такие “зависания” вероятны, если список задач Лены постоянно пополняется новыми “приоритетными” заявками от разного рода руководителей, которые она ответственно обрабатывает. При этом считая, что приносит максимально возможную пользу для компании.
Но так ли это на самом деле?
Есть ли в вашей компании явные правила приоритизации задач отдела рекрутинга? Или же, как обычно принято на постсоветском пространстве, приоритеты устанавливаются громкостью голоса и наличием “звезд на погонах”? Есть ли полная уверенность в том, что месяцами не закрывающиеся позиции уборщицы или грузчика, менее важны для бизнеса, чем найм маркетолога или финансиста? Как часто подобные вопросы обсуждаются в кругу руководителей смежных подразделений?
Устанавливая лимиты на каждую из стадий процесса, Канбан, для начала, помогает сделать текущую ситуацию более прозрачной, а затем начать ею лучше управлять.
Так, допустим, на стадию поиска резюме мы поставим ограничение в 3 заявки. Это означает, что наша Лена не может работать над более чем 3 вакансиями одновременно. Таким образом, приоритеты в ее работе становятся для всех более видимыми. И новую позицию в работу Лена может взять только в случае передачи на следующий этап одной из трех, уже находящихся в работе.
Это приводит к тому, что в отделе начинают накапливаться заявки из разных департаментов. Что порождает споры о том, какую заявку брать следующей? Достаточно ли у нас рекрутеров? Достаточно ли у них квалификации для закрытия всех возможных вакансий? Или нужно ввести разделение по специализациям между рекрутерами? Или, возможно, что-то тормозит работу Лены на последующих стадиях?
Узнать о блокерах на следующих стадиях мы можем, опять же, только в случае установки ограничений на объем выполняемой ими работы. Они не обязательно должны быть равны лимиту предыдущей стадии (хотя можно начать и с этого). Но должны быть обязательно. Иначе заявки будут уходить как в бездонную бочку. Люди будут работать, а с какой скоростью они эту работу выполняют и согласно каким приоритетам снова будет не ясно.
Допустим, следующим этапом после нахождения резюме у нас будет его проверка службой безопасности. Одна из самых длительных стадий процесса найма в большинстве компаний.
Если наша Лена действительно очень быстро находит нужные резюме и заваливает СБ кандидатами на проверку, то с введением WIP лимитов она будет часто простаивать в ожидании результатов. И это породит массу неудобных, но очень полезных для нас вопросов: чем занять Лену? может ли она помочь кому-то на следующих стадиях? не слишком ли длительны наши процессы проверки кандидатов? достаточно ли у нас ресурса СБ? возможно ли провести доп обучение для рекрутеров, чтобы они могли самостоятельно отсеивать часть кандидатов без помощи специалистов службы безопасности? и т.д…
Таким образом, шаг за шагом мы можем выявлять все больше изъянов нашей системы и находить для них соответствующие решения.
Но самое главное, установка WIP лимитов дает возможность начать замерять время прохождения заявки через всю нашу процедуру найма и управлять скоростью ее закрытия за счет уменьшения или увеличения WIP лимитов на разных стадиях.
Также подобные замеры могут дать нам дополнительный инструментарий для косвенного влияния на весь процесс. У нас появляются оцифрованные аргументы, чтобы объяснить руководителям, как задержки на их стадиях влияют на скорость закрытия вакансий по всей компании.
Так, на моей памяти, СЕО одной достаточно крупной организации, одним росчерком пера сократил время закрытия вакансий по всей компании на 30%, после того как узнал, что 40% времени кандидаты ждут собеседований и финальных решений от сотрудников первой линии его подчинения. Без этих цифр руководитель отдела рекрутинга пыталась достучаться с этой проблемой до ТОПов больше года!
Но если все так “ровно и гладко”, то почему, спросите вы, этим инструментарием пользуется так мало компаний?
Из-за страха простоев и тех неудобных разговоров, которые порождают вопросы, приведенные выше.
В нашей культуре не принято “выносить сор из избы”. Нам проще закрыть глаза на неэффективность того или иного процесса, чем вызвать на неприятный разговор коллегу из соседнего отдела. Мы надеемся, что они сами поймут и обязательно исправятся, а это происходит крайне редко.
Я привел в статье множество вопросов. Но не дал ни одного ответа. Я сделал это умышленно, поскольку ответы зависят от реалий каждой конкретной ситуации.
Канбан — это не панацея и не волшебный метод решения проблем. Но при желании с его помощью можно сделать более явными основные изъяны любого процесса и начать планомерно их исправлять.
Об остальных инструментах в следующих статьях. Подписывайтесь на обновления!
