Немного расскажу о себе. Я с 2008 года занимаюсь организационным проектированием. Реализовала более сотни проектов в телекоммуникационной и нефтяной областях, в одной из крупнейших GameDev компаний России.
Елена Артюх
Руководитель центра организационного
развития ПАО «Газпромнефть»
Методы гибкого управления численностью
Мне хотелось бы поговорить вообще про ресурсное планирование. Я вижу тренд, что именно организационное развитие всё больше интегрируется в HR-повестку, и не только в чисто классическое организационное проектирование, но и в систему вознаграждения и управления талантами. Конечно, в этом достаточно существенную роль играет ресурсное планирование, потому что без него планирование как таковое сложно себе представить.
Я поделюсь некоторыми своими соображениями о том, куда ресурсное планирование идёт. Некоторое время назад, на мой взгляд, тема ресурсного планирования, оргпроектирования выпала на какой-то период из обсуждения на конференциях и в профессиональном сообществе в принципе. Я это связываю с тем, что мы переходили из Agile-формата, в котором много экспериментировали и искали различные решения, в более стабильный формат.
Компаниям потребовалось время на перестройку, на понимание, что такое гибкие модели, управление через ролевые модели, продуктовый подход. Некогда было думать и планировать, не было достаточной базы для планирования. Все начали быстро нанимать людей, быстро перестраивать организацию, опираясь на некое экспертное представление о том, сколько людей нужно.
Но, тем не менее, последние два-три года многие продвинутые компании уже живут в продуктовой логике в том или ином масштабе. Это позволяет нам уже ретроспективно понять, как эффективнее управлять ресурсами. Ведь всем известно, что качество планирования экономит множество лишних ресурсов.
На ресурсное планирование, или планирование численности, как мы привыкли его называть, всё больше запросов со стороны различных HR-подразделений. Это не только запрос на точность планирования фонда оплаты труда, но и запрос подразделений по управлению талантами на качество прогнозирования компетенций.
Сейчас ощущается дефицит кадров во многих отраслях, соответственно, этот голод нужно утолять. Нужно понимать, как работать со студентами, иногда даже со школьниками. Для этого необходимо создавать модели длительного горизонта планирования.
Также ощущается запрос на рост производительности труда. Если говорить про крупные компании, про государственные холдинги, то это цели, которые транслируются, в том числе, на уровне государства. Есть программы поддержки, которые позволяют развивать крупный бизнес эффективнее. Если говорить про мелкий бизнес, средний бизнес, формирующиеся стартапы, то и здесь мы не просто распределяем задачи, но и начинаем использовать определённые эффективные модели.
Самое важное — появились фактические данные о перепроизводстве кадров, или оверстаффинге в конкретных подразделениях. Мы можем анализировать эту информацию, что создает окно возможностей.
Я не очень завидую тем компаниям, которые только сейчас начинают работать с темой производительности труда, управлением численностью. С одной стороны существует большой тренд на человекоцентричность, на работу с вовлеченностью, на мониторинг усталости, выгорания и прочего. Это говорит о том, что нам нельзя до бесконечности вновь и вновь использовать те человеческие ресурсы, которые у нас есть. Мы ограничены человеческими возможностями и тем, что вкладываем в программы well-being. Это влияет на имидж работодателей, насколько кандидаты готовы работать в той или иной компании. Мы не можем утилизировать персонал на 120-130% и вынуждены ограничивать. Но при этом мы понимаем, что не можем позволить себе до бесконечности быть супергуманитарными организациями.
Лишний персонал всегда несёт дополнительные затраты и на привлечение, и на его содержание, и на создание АУПа, который его обеспечивает. К тому же, людей сложно найти на рынке, и проще и быстрее найти меньшее количество сотрудников.
Есть цифра 0,87 как коэффициент утилизации персонала, и компании пытаются попасть в эту метрику. Почему 0,87? Потому что 13% загрузки — это отпуска, ноль командировок, больничные, один-два дня обучения. Можно сокращать обучение, снижать количество дней больничного, но скорее всего мы будем работать именно с организационными моделями, с разными способами нормирования и перестройки работы этого подразделения, чтобы добиться именно этого показателя.
Том Гартнер проводил исследование, которое говорит о том, что за последние полтора года больше 70% крупных компаний или перезапустили свои проекты по нормированию, планированию и оценке трудозатрат, или переосмыслили этого направление. Если обобщить некоторое количество статей и научных трудов, которые сейчас есть, то ресурсное планирование или управление численностью разделяется на три больших направления. Первое — это классическое: через нормирование, драйверы, оценку производительности труда. Второе — это проектное ресурсное планирование, когда мы говорим о длительных циклах. И третье — это гибкое ресурсное планирование.
Если говорить про классическое ресурсное планирование, то все инструменты нормирования базовой автоматизации механизмов, модели численности живы и сейчас. Точность подобных моделей мы планируем обычно на год, численность можем смотреть на более долгие горизонты с меньшей точностью. При этом те базы нормативов, которые создаются, актуальны в течение двух, трёх, пяти лет. Это даёт нам возможность не так часто пересматривать эти данные и делать некоторые проекты по нормированию, вырабатывать драйверы, нормативы и превращать их в количество FTE, которые нужны в этом или следующем году в том или ином подразделении. Если посмотреть на проектную деятельность, то change планируется на основании некоторых проектных планов. Здесь мы планируем уже не на год или на горизонт бизнес-плана или инвестиционного плана, а на конкретную веху проекта. При таком подходе обычно меньше гибкости, так как мы планируем, что у нас есть определённый слот для производства работ, на который нужны соответствующие компетенции. Соответственно, мы планируем длительность загрузки компетенции на определённый этап проекта. При этом мы учитываем географические и иные ограничения и далее собираем ресурсный план-проект.
Многие компании делают внутриотраслевые профессиональные сообщества, в которых обмениваются бенчами, данными по проектным аналогам. Всегда можно позвонить коллегам и узнать, сколько времени у них это занимало, пересчитать в количество FTE.
Классические инструменты планирования численности по-прежнему актуальны для контура RUN. Change-деятельность планируется на основании проектных планов с целью своевременной поставки компетенций.
Как правило, проектная деятельность про то, что все ресурсы аллокированы в одном проектном подразделении. Если мы запускаем процессы на долгий срок, то мы стараемся собрать все ресурсы в одной точке, сделать проекты достаточно масштабными, чтобы на их протяжении всем нашлась работа. Мы думаем, как правильно фазировать, чтобы люди внутри перемещались. Это задачка со звёздочкой, но вполне себе достижимая.
При этом для проектного ресурсного планирования используется всё тот же софт, что и для планирования внутри подразделений. Если мы планируем логистику, МТО, складские остатки в Primavera или в Project, то ресурсное планирование использует ту же самую систему. Мы просто включаем это в FTE как еще один параметр. Но здесь уже начинает проявляться вопрос про то, что мы используем компетентностный подход, дифференциацию по компетенциям для того, чтобы посчитать, сколько людей нужно.
Мы более или менее умеем и за пределами IT-компаний можем планировать change-деятельность. Мы можем внутри себя оценить, сколько ресурсов нам нужно на реализацию определённого проекта, используя классические проверенные методы.
Но при этом есть очень мощный выход на саму организационную структуру, без которой мы в ближайшее время не обойдемся. Основная ценность ресурсного планирования в гибком формате в том, что оно нужно для того, чтобы быстро поставлять компетенции в команду. Скорость становится ключевой ценностью. Когда у нас короткие поставки ценности, для нас скорость конкуренции на рынке становится намного более важной и ключевой, чем количество людей как таковое.
Суть гибкого ресурсного планирования — это скорость: как быстро сделать так, чтобы ваша команда, которая делает инновационный продукт огромной потенциальной нормой рентабельности, получала даже узкие компетенции тогда, когда ей это нужно.
Для этого мы вынуждены смешивать подходы. С одной стороны, все понимают, что продуктовые или продукто-ориентированные структуры эффективнее в части поставки ценности. Мы собрали всех в одну команду, компетенций достаточно, команда собралась и заработала.
Гибкое ресурсное планирование: внутри команды количество ресурсов зависит от желаемой скорости развития продукта. Структура команды предварительно ограничена определённым набором ролей и разделена на фичетимы или компонентные микро-команды.
Но так бывает не всегда. Достаточно сложно достичь такого результата, как минимум, потому что есть дефицит кадров. Если мы посмотрим на существующую Agile-команду, то, как правило, в неё входят IT-архитекторы, front-end разработчики, финансовые аналитики. Они нужны не на всём жизненном цикле проекта, но мы всё равно вынуждены их подключать на part time.
Соответственно, что же делать с тем, что есть ряд людей на part time и full time. Мы начинаем делить их организационно. Тех, кто нам нужен постоянно, мы сразу включаем в нашу организационную структуру и делаем её продукто-ориентированной. Часто это называют core team. Мы выделяем её в оргструктуре, даём полномочия на управление этой структурой, то есть идём классическим путём.
Есть вторая часть и ряд компетенций, которые излишне отдавать в каждую команду. Мы столько людей не наймём, ёмкость рынка не такая большая, а дефицит значительный. Мы начинаем искать узких специалистов, которые временно привлекаются в команды, и создавать центры компетенций. Или создаём ресурсные пулы, в которых мы комфортно можем перераспределять людей.
Далее начинается самая сложная организационная задача. Во-первых, надо рассортировать людей на тех, кто является core team и находится в продуктово-ориентированной структуре. Во-вторых, надо сделать так, чтобы временно привлекаемые специалисты поставлялись достаточно быстро. Здесь как раз и начинаются все сложности с ресурсным планированием. Ситуация начинает постоянно меняться, доступа к информации о том, сколько времени этот человек нужен в команде, у нас нет.
Сначала мы разберёмся с core team. Есть тренд в создании ролевых моделей, и от них мы сейчас уйти не можем. Поэтому мы берём оргдизайнера и начинаем проектировать роли, которые находятся в core team. Скорее всего, это эксперты по узким направлениям, например, ИТ-специалисты. Как правило, время отсечки — год и более. Плюс 80% времени, а лучше 87%, они могут утилизироваться внутри команды.
Мы собираем эту команду по ролям и отдаём для реализации проекта. Продуктовая команда начинает работать с этими ресурсами. Как перераспределять время, чтобы достичь результата с 80% до 87%, — это становится задачей лидера команды. Часто случается, что HR пытается не на уровне дизайнера команды, а на уровне принятия решений в моменте глубоко залезать в дизайн внутри команды и тратить на это очень много времени. КПД у таких действий очень низкий. Моя рекомендация из опыта работы с различными командами: ближайшие полтора-два года не лезть в процесс, когда у вас оптимальный организационный дизайн команды. Дальше надо отдать возможность работы с этой командой самим участникам, которые будут повышать эффективность самостоятельно.
Ваше привлечение и вовлечение нужно, когда команда хочет двигаться быстрее, когда мы хотим кратно ускорить скорость развития продукта. Если менеджмент решил, что команда двигается слишком медленно, то команда начинает переструктурироваться. Если она делала одну фичу или один организационный объём за период времени, которые в Agile-подходе зафиксированы, а нужно это делать в два раза быстрее, то мы делаем две фиче-команды. То есть поставляем ещё одного Product Owner, ещё одного архитектора, профессиональных экспертов из разных областей продукта и т.д. То есть, как правило, действуем по принципу Х2 в рамках той ролевой архитектуры, которая уже создана. Если команды создают не фичи, а разные компоненты (например, мобильное приложение для IOS или Android), то тогда мы команды просто клонируем.
Что происходит с теми самыми временно привлекаемыми узкими специалистами? Кажется, всё просто. Если мы собрали центр компетенций, то мы отдаём людей в команды. Время одного человека нужно запланировать так, что он поработал с одной командой, дальше перешёл во вторую, третью и так далее. Здесь возникают подводные камни. Первое — это пиковые нагрузки. Нет идеально запланированных pipeline,и нам иногда нужно больше людей. Второе — это то, что все проекты начинают двигаться. Третье — не всё, что запланировано, идеально. Команды могут прийти к тому, что определённый специалист им вообще не нужен.
Ресурсное планирование для центров компетенций строится от проектов. Рекомендация — разделить два элемента. Первое — это сбор потребностей от проектов, когда мы спрашиваем, сколько надо людей и нужны ли они будут вообще. Мы предварительно разбрасываем слоты и начинаем бронировать ресурсы, понимая, кто на какой проект пойдёт.
Дальше, имея предварительный опорный план и понимая, сколько нам будет нужно людей, каких компетенций и какого уровня, уже ждать момента выдачи заказа на ресурс от проектной команды. В результате команда получает эксперта. Если сделать, например, квартальный сбор потребностей, то он будет сопоставим со сроком подбора. Если вы увидите, что вам нужно больше других компетенций, которых у вас нет, то вы сможете просто набрать людей.
Второе — от момента заказа до его закрытия вы сможете выдерживать приличные сроки. Приличными сейчас на рынке считаются сроки от двух-трёх дней до двух недель, когда команда готова ждать. Или промежуток времени, через который им будет необходим определённый специалист.
Временно востребованные компетенции привлекаются из центров компетенций на определённый период времени. Процесс ресурсного планирования — сквозной для проектов и центров компетенций.
Последняя важная вещь — это анализ факта списания трудозатрат центров компетенций, в которых их руководители поправочными коэффициентами с нашей помощью могут иначе сбалансировать свою модель. Например, нужно больше / меньше компетенций или человек на более продолжительный срок. На уровне статистики мы можем калибровать эти данные. Настройка этого цикла калибровки по правилам и становится основной задачей оргразвития в части ресурсного планирования для гибких моделей.
Для этого нужно, первое, — система учёта трудозатрат. Подойдут банальные Tracker, Jira, Битрикс и прочее. Главное, чтобы они учитывали факт так, как это потом потребляется центрами компетенций. Соответственно, нужна культура, в которой люди фиксируют свои трудозатраты в моменте. Второе — это сама методология правил списания трудозатрат, их анализа и того, как данные заносятся в систему, иначе они будут не употребимы. Третье — нужно понять, кто такой ресурсный менеджер. Кто, вообще, для вас человек, который выделяет ресурсы в команду. Иногда это руководитель ресурсного пула или центра компетенций, иногда это специально выделенный человек. Но это точно вопрос ребром.
Когда мы живём в такой enterprise-модели, то упираемся в то, что у нас есть ограничение на численность, и мы не нанимаем людей, когда они критически нужны. Согласование численности и прочих упражнений становится достаточно трудоёмким. Для контура модели, в которой мы живём, а не для иной, зачастую снимаются ограничения на рост численности. Рост происходит согласно заявкам, собранным потребностям. Это очень важный аспект, на который мне хотелось бы обратить внимание.
Вопрос из зала: У нас проектное проектирование предполагает, что руководители проекта должны быть достаточно компетентны в наборе команды. К сожалению, этого у нас с вами нет. Поэтому надо, наверное, начинать с обучения лидеров этих проектных команд, а потом уже всех остальных.
Елена Артюх: Видимо, надо начинать с проекта в HR. Во-первых, HR точно должен поднимать вопрос качества ресурсного планирования. Нам всегда лучше видно: мы можем сравнить данные с проектными аналогами, понять, где есть дефициты в планировании, где есть перерасход ресурсов, а далее — как минимум, эту тему поднимать.
Второе — в функции оргразвития снова появляются отдельно выделенные компетенции по развитию методологии ресурсного планирования или управления численностью. Методологическая основа — сбор данных по драйверам, реализация проектов, в которых без нас анализ факта списания точно не появится, поэтому проектный менеджер в HR точно должен быть. При этом даже без бизнеса здесь никто не справится. Здорово, если есть те самые руководители центров компетенции или лидеры функций, которые могут экспертно соотнести системы метрик и показателей с трудоёмкостью операции. В матричной модели это делать намного быстрее. Если есть лидер функции внутри матричной модели, то это как раз тот человек, который экспертно в процессе управления численностью обязательно должен присутствовать и сравнивать проекты между собой, понимать, какие есть отклонения. В гибкой модели это ещё играет большую роль.
Илья Антонов, «Лукойл»: Для каких видов проектов и в каких сферах вы применяете гибкий подход?
Елена Артюх: Для крупных капитальных проектов мы применяем проектное управление или проектно-ресурсное планирование. Гибкий подход используется для всех проектов развития. Например, это может быть создание новых продуктов, где есть короткий цикл поставки. Гибкого ресурсного планирования требует всё, что делается по Agile, для внутренних или внешних нужд компаний. Большая часть проектов имеет IT-составляющую, но есть и проекты, в которых её нет, но есть, например, технологическая составляющая. Или есть подбор новых технологий, списание запасов, внутренние аудиты запасов. Подобные вещи вполне могут делаться в Agile.
Илья Антонов, «Лукойл»: У нас вертикально-интегрированная компания. Основные виды деятельности — добыча нефти, продажа, сбыт нефтепродуктов, переработка. Мы не выпускаем ни IT-продуктов, ни коробочных решений. У нас понятная отраслевая деятельность. Как Вы думаете, где бы мы могли применить гибкий подход?
Елена Артюх: Первое — это точно сбыт. Везде, где есть точки контакта с клиентом, соответственно, это сбыт В2С, то есть заправки. Второе — это В2В и поиск новых ниш для реализации нефтепродуктов, где речь будет идти не о применении ресурсного планирования, а о том, чтобы с помощью продуктового подхода начать отвечать на потребности клиентов. И, собственно, внутренний change, то есть проект трансформации.
Илья Антонов, «Лукойл»: У вас в центрах компетенции находится пул экспертного персонала. Где находится данный центр компетенций в структуре компании? Это отдельная структура, это производственно-сервисные центры, это IT? Какие у дочерних обществ корпоративные центры? Как направляются люди из данных центров в проекты?
Елена Артюх: Где создавать центры компетенций, я бы здесь не фреймилась. Очень сильная специфика каждой компании. Качественной разницы между тем, чтобы создавать подобные вещи в сервисных центрах или в корпоративном центре, нет. Разница будет в том, что, если в корпоративных центрах быстрее, потому что, как правило, там не требуется сложная схема списания. Значит, вы просто можете отдать человека на проект в дочернем обществе, продолжая оплачивать его работу из прибыли без заключения договоров и так далее. Вы просто сэкономите время на этом, если вы сейчас в начале пути, и вам нужно быстро разогнать этот маховик.
Уже с определённым уровнем зрелости, года через полтора-два, можно говорить о том, чтобы выводить подобные пулы в сервисные центры. При этом надо учитывать, что у коллег будут принципиально другие SLA, и их показатели будут сопряжены с показателями тех самых продуктовых команд. То есть у юристов будут показатели не юридические, а показатели эффекта того продукта, который они делают. Это достаточно сложные схемы в проектировании и разработке, они занимают много времени, не считая проекта централизации как такового.
Но принципиально никакой разницы нет. Важно понимать: чем более централизованный этот пул, чем больше людей в нём собрано, тем быстрее он выдаёт ресурсы.
Второй вопрос был про то, как это выглядит. Действительно, на рынке сейчас есть две схемы. Первая — это через наём-увольнение, вторая — через прикомандирование. Я считаю, что наём-увольнение — менее эффективная схема. Мы мараем трудовые книжки, и на это требуется много вторичных трудозатрат с проверками
Альтернативная схема — через прикомандирование. Это ролевая модель, которая не является штатным расписанием и чем-то застывшим внутри компании. На управляющем комитете или собрании коллегиального органа при выдаче финансирования на реализацию проекта утверждается оргсхема. В ней написано, какой нужен специалист и на какое количество часов рабочего времени. Автоматическое согласование этой схемы значит, что руководитель соответствующего центра компетенции должен выделить этого человека. Он вписывает его трудозатраты во внутренних таймшитах: Jira, Primavera и так далее.Тогда это не трудоёмко с точки зрения обслуживания процесса.
