Работы стало больше, а нанимать пока не хочется. Где искать резерв производительности?

Когда команда перестаёт справляться с объёмом, первое решение кажется очевидным: нужен ещё один человек.

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

Перед наймом полезно проверить: сколько рабочего времени существующей команды вообще превращается в результат. Потому что высокая загрузка и высокая производительность - не одно и то же.

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

И если проблема находится именно там, новый сотрудник её не уберёт, он просто встроится в тот же процесс.

Представим отдел из шести человек. Команда закрывает около 120 заявок в неделю. Объём вырос, нужно делать 150, и руководитель просит седьмого сотрудника.

До согласования вакансии можно посмотреть, как проходит одна заявка от входа до результата. По моему опыту довольно часто обнаруживается примерно следующая картина.

Сотрудник обработал свою часть за двадцать минут, но потом заявка два часа ждала согласования руководителя. После согласования ещё час ждала данных от другого отдела.

Формально команда загружена, но фактически скорость всего процесса определяется не количеством исполнителей, а этими ожиданиями.

Добавление ещё одного человека в начало цепочки здесь способно даже ухудшить ситуацию.

У каждого по десять задач и все срочные, по каждой кто-нибудь периодически спрашивает статус. Сотрудники постоянно переключаются между клиентами, проектами, чатами и внутренними вопросами.

В результате работа идёт, но заканчивается медленно.

Иногда производительность растёт не после добавления новых задач, а после ограничения количества одновременно открытых: не начинать пятнадцатую, пока не закончена пятая, звучит слишком просто. Но для многих процессов именно это сокращает сроки сильнее, чем дополнительный человек.

Сначала сотрудник внёс данные в CRM, потом перенёс их в таблицу, в конце недели руководитель собрал из нескольких таблиц отчёт. После этого кто-то ещё проверил цифры, потому что данные в системах расходятся.

Каждая операция сама по себе занимает немного времени, поэтому такие потери редко выглядят критичными. Но если команда повторяет их десятки раз в неделю, они превращаются в отдельную ставку, которой как будто «не хватает».

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

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

Сотрудник делает работу, получает комментарии и делает её ещё раз. В отчёте это может выглядеть как одна выполненная задача, а по факту компания оплатила её выполнение дважды.

Перед наймом нового человека полезно посмотреть, какую долю работы команда делает повторно. Иногда убрать причины возвратов дешевле и быстрее, чем расширять штат.

Возможно также стоит ставить вопрос компетентности исполнителей.

Это ещё одна частая проблема. Когда сроки начинают расти, кажется, что перегружены все, но процесс почти всегда ограничивает конкретное место.

Например, пять менеджеров могут спокойно обрабатывать входящий поток, а все нестандартные решения должен подтвердить один руководитель.

Или производство способно выпускать больше, но закупки не успевают обеспечивать материалы.

Или специалисты выполняют работу вовремя, но результат неделями лежит на проверке.

В такой ситуации общий найм не обязательно даст дополнительный выпуск. Сначала нужно понять: где именно появляется очередь.

Допустим, шесть сотрудников закрывают 120 заявок в неделю. Компания хочет выйти на 150. Кажется, что нужен седьмой человек.

Но после разбора процесса может выясниться, что часть заявок регулярно возвращается на доработку, распределение задач выполняется вручную, а несколько операций сотрудники дублируют в двух системах.

Компания убирает один ручной этап, меняет порядок согласования и автоматизирует часть переноса данных. Те же шесть человек начинают стабильно закрывать 145–150 заявок.

Это не значит, что найм может быть ошибкой вообще. Руководителю важно понять, что сначала нужно найти мощность, за которую уже он заплатил.

Когда процесс действительно упирается в людей.

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

Проблема возникает, когда человек становится универсальным способом лечить любой перегруз. Появилась очередь - нанять. Упали сроки - нанять. Руководитель не успевает согласовывать - нанять ещё одного исполнителя. Так штат растёт быстрее, чем производительность.

Я бы начала с четырёх вопросов.

1. Где именно возникла очередь?

Не «отдел перегружен», а на каком конкретном этапе работа перестала проходить с нужной скоростью.

2. Сколько времени задача обрабатывается, а сколько ждёт?

Эти цифры часто сильно отличаются.

3. Что команда делает повторно или вручную?

Переделки, перенос данных, отчёты, одинаковые запросы, ручные проверки.

4. Что конкретно должно измениться после найма?

Например: количество закрытых заявок должно вырасти со 120 до 150 в неделю или срок выполнения сократиться с пяти дней до трёх.

Если ответа на эти вопросы нет, возможно, пока не до конца понятно, какую проблему должен решить новый сотрудник.

Найм - хороший способ купить дополнительную мощность. Но сначала стоит убедиться, что компания действительно покупает мощность, а не ещё одного человека для обслуживания потерь, которые уже существуют внутри процесса.