Что важнее: загрузка людей или поток работы
Представим организацию, в которой каждый сотрудник занят на 100%.
У аналитиков очередь задач.
У разработчиков расписана каждая неделя.
Руководители проводят встречи одну за другой.
Финансы постоянно обрабатывают запросы.
Юристы перегружены согласованиями.
У HR десятки параллельных проектов.
Никто не сидит без дела.
На первый взгляд такая компания должна быть чрезвычайно эффективной.
Но именно в ней проект может несколько недель ждать свободного аналитика.
Потом ещё неделю — согласования.
Затем попасть в очередь ИТ.
После разработки ждать тестирования.
Потом снова вернуться на доработку.
Каждый участник всё это время был очень занят.
А результат двигался медленно.
В этом и заключается один из главных парадоксов управления производительностью:
максимальная загрузка людей и максимальная скорость создания результата — не одно и то же.
Иногда это вообще противоположные цели.
Мы привыкли считать незанятого человека потерей
Логика загрузки кажется абсолютно рациональной.
Компания платит сотруднику за рабочее время.
Следовательно, желательно использовать это время максимально эффективно.
Если специалист занят только на 70%, возникает вопрос:
почему компания оплачивает оставшиеся 30%?
Поэтому руководители начинают заполнять свободную мощность.
Есть окно — добавим проект.
Освободился сотрудник — дадим дополнительную задачу.
Команда способна взять ещё одну инициативу — запускаем.
Постепенно организация приходит к состоянию, когда свободного ресурса практически не остаётся.
На уровне отдельного сотрудника это действительно выглядит эффективно.
Но компания получает результат не от загрузки отдельных людей.
Она получает результат от прохождения работы через цепочку взаимозависимых участников.
И здесь начинает работать совершенно другая логика.
Клиенту безразлично, насколько заняты сотрудники
Представим процесс создания нового продукта.
Сначала требуется исследование.
Потом бизнес-анализ.
Затем согласование экономики.
Разработка.
Юридическая проверка.
Запуск.
Если весь путь занимает шесть месяцев, для бизнеса именно эти шесть месяцев определяют скорость получения результата.
Не имеет большого значения, что каждый участник процесса был занят на 97%.
Компания всё равно ждала шесть месяцев.
То же самое происходит практически везде.
Кандидату неважно, насколько загружен рекрутер. Для него существует время от первого контакта до решения.
Клиенту неважно, сколько задач у менеджера. Для него существует время от обращения до результата.
Руководству неважно, насколько занята проектная команда. Для бизнеса существует время от решения запустить изменение до появления эффекта.
Поэтому существует принципиально другой способ смотреть на производительность:
не сколько работы выполняет каждый элемент системы,
а как быстро ценность проходит через систему целиком.
Поток меняет единицу измерения
При управлении загрузкой объектом внимания становится человек или подразделение.
Сколько часов занято?
Сколько задач выполняется?
Какова утилизация ресурса?
При управлении потоком объектом становится работа.
Когда она вошла в систему?
Где находится сейчас?
Сколько времени ждёт?
Что мешает ей двигаться?
Сколько работы одновременно находится внутри системы?
Как быстро законченные результаты выходят наружу?
Это принципиальная смена управленческой оптики.
Вместо:
«Все ли заняты?»
появляется вопрос:
«Почему результат так долго идёт от начала до конца?»
И ответы часто оказываются неожиданными.
Большую часть времени работа может вообще не выполняться
Представим проект, который существует 100 рабочих дней.
Интуитивно кажется, что примерно столько времени над ним и работали.
Но если разложить путь подробнее, картина может выглядеть иначе.
Пять дней — анализ.
Десять дней — ожидание решения.
Три дня — подготовка.
Две недели — очередь на согласование.
Семь дней — разработка.
Ещё несколько дней — ожидание тестирования.
Затем возврат.
Новая очередь.
Повторное согласование.
Фактической работы может оказаться относительно немного.
Большая часть календарного времени находится между операциями.
Проект не выполняется.
Он ждёт.
Именно поэтому попытка ускорить отдельных сотрудников часто почти не влияет на общий срок.
Если разработчик вместо пяти дней выполнит работу за четыре, компания выиграет один день.
Если проект до этого три недели ждал разработчика, проблема находится совсем не в скорости его работы.
Максимальная загрузка создаёт очереди
Представим специалиста, способного выполнять примерно десять задач в неделю.
Если ему поступает пять или шесть, очередь практически не возникает.
Есть резерв.
Появилась срочная задача — её можно взять.
Что-то оказалось сложнее — система выдерживает отклонение.
Теперь загрузим специалиста практически полностью.
Каждый свободный час заранее распределён.
На бумаге эффективность выросла.
Но достаточно одной задаче занять больше времени, чем планировалось, чтобы следующая начала ждать.
Появляется срочный запрос — его приходится вставлять в очередь.
Остальные сроки сдвигаются.
Кто-то просит ускорить свою задачу.
Начинаются переключения.
И чем ближе система находится к предельной загрузке, тем чувствительнее она становится к любому отклонению.
Это особенно важно в интеллектуальном труде, где продолжительность задач невозможно идеально предсказать.
Поэтому свободная мощность не всегда является потерей.
Иногда это резерв устойчивости системы.
Организации часто создают очереди сами
Очередь не обязательно выглядит как группа людей перед кабинетом.
В современной компании она скрыта в цифровых системах.
Непроверенные документы.
Задачи в бэклоге.
Запросы на согласование.
Непринятые решения.
Проекты, ожидающие ресурса.
Письма.
Тикеты.
Кандидаты между этапами.
Инициативы, ожидающие бюджета.
Каждая такая очередь увеличивает время прохождения работы.
Но поскольку очередь распределена между системами и подразделениями, организация может её почти не замечать.
Она видит только:
«У юридического отдела много работы».
«ИТ перегружено».
«Финансы не успевают».
Хотя более полезный вопрос звучит иначе:
почему мы отправляем в этот элемент системы больше работы, чем он способен обработать?
Системное мышление требует анализировать именно такие взаимосвязи, ограничения и повторяющиеся механизмы, а не только локальную производительность отдельного элемента.
Локальная эффективность способна ухудшать общий результат
Это один из самых неприятных управленческих парадоксов.
Допустим, подразделение А способно подготовить 100 заявок.
Следующее подразделение B способно обработать только 60.
Что произойдёт, если руководитель А добьётся повышения производительности до 120?
Локальный показатель улучшится на 20%.
Для всей системы почти ничего не изменится.
На выходе по-прежнему будет около 60.
Зато перед B станет накапливаться ещё большая очередь.
Компания создаст больше незавершённой работы.
Именно поэтому оптимизация каждой функции отдельно не гарантирует оптимизации бизнеса.
Иногда она делает систему хуже.
Подразделение прекрасно выполняет свой KPI.
Но совокупный результат не растёт.
Это фундаментальное различие между управлением функциями и управлением потоком.
Узкое место определяет скорость всей системы
Если в процессе существует ограничение, производительность системы начинает определяться именно им.
Можно ускорять всё вокруг.
Но общий поток практически не изменится.
Представим найм.
Рекрутеры способны выводить на интервью 100 кандидатов в месяц.
Но руководители бизнеса могут качественно проводить только 40 интервью.
Можно увеличить штат рекрутеров.
Усилить рекламу вакансий.
Внедрить новые инструменты поиска.
Количество кандидатов станет больше.
Скорость закрытия вакансий может почти не измениться.
Потому что ограничение находится в другом месте.
Более того, дополнительные кандидаты увеличат нагрузку на уже перегруженный этап.
Поэтому сильное управление начинается не с вопроса:
«Как повысить производительность каждого?»
А с вопроса:
«Что сейчас ограничивает производительность всей системы?»
Перегруженное ограничение нельзя лечить дополнительным входящим потоком
Организации регулярно делают именно это.
Продажи не выполняют план — маркетинг увеличивает количество лидов.
ИТ не успевает — запускается ещё больше проектов цифровизации.
Рекрутинг перегружен — открывается ещё больше вакансий одновременно.
Проектный офис не успевает координировать портфель — добавляется новая отчётность.
Каждое решение само по себе может выглядеть разумным.
Но если система уже перегружена, дополнительный входящий поток только увеличивает очередь.
Поэтому иногда лучший способ ускорить работу — не добавить ресурс и не потребовать большей производительности.
А перестать запускать новую работу.
Незавершённая работа имеет стоимость
Запущенный, но не законченный проект часто воспринимается почти как актив.
«Мы уже начали».
«Команда работает».
«Проект реализуется».
Но незавершённая работа потребляет ресурсы.
Её нужно координировать.
Обсуждать.
Отслеживать.
Обновлять статус.
Перепланировать.
Хранить контекст.
Управлять зависимостями.
Каждый дополнительный параллельный проект увеличивает сложность всей системы.
Если один специалист участвует в пяти инициативах, ему приходится постоянно переключать контекст.
Если десять подразделений ведут десятки пересекающихся проектов, количество зависимостей растёт ещё быстрее.
Поэтому количество одновременно запущенной работы становится самостоятельным управленческим параметром.
Не всё, что можно начать, нужно начинать сейчас.
Иногда 80% загрузки эффективнее 100%
Для традиционной управленческой логики это звучит почти неправильно.
Как можно сознательно оставлять свободный ресурс?
Но представим критически важного специалиста.
При 100% плановой загрузке любое отклонение создаёт задержку.
При 80% существует резерв.
Возникла проблема — есть возможность отреагировать.
Появилась действительно срочная задача — не нужно разрушать весь план.
Одна работа оказалась сложнее — очередь не начинает мгновенно расти.
Этот резерв похож на свободное место на дороге.
Если каждая полоса полностью заполнена автомобилями, теоретически дорожное пространство используется максимально эффективно.
Практически движение замедляется.
Небольшое нарушение сразу создаёт пробку.
То же происходит с организационными системами.
Свободная мощность может выглядеть как неэффективность локально и одновременно быть условием высокой скорости системы в целом.
Особенно опасна стопроцентная загрузка руководителей
Обычно загрузку обсуждают применительно к сотрудникам.
Но один из самых дорогих дефицитов организации — управленческое внимание.
Если календарь руководителя заполнен с утра до вечера, внешне это может выглядеть как высокая востребованность.
Но что происходит, когда появляется сложная проблема?
Когда нужно подумать?
Провести анализ?
Поговорить с ключевым сотрудником?
Принять нестандартное решение?
Разобраться в причине системного сбоя?
Свободного пространства нет.
Поэтому решения откладываются.
А за одним управленческим решением иногда ждут десятки людей.
Парадокс:
руководитель чрезвычайно занят, но его максимальная загрузка создаёт простой всей системы.
На высоких уровнях управления способность сохранять ресурс для решений может быть значительно важнее количества встреч в календаре.
Управление потоком требует ограничивать вход
Большинство организаций хорошо умеют запускать работу.
Значительно хуже — ограничивать её.
Новая идея кажется перспективной.
Проект получает одобрение.
Команда начинает работать.
Но редко задаётся вопрос:
«Есть ли у системы реальная мощность принять ещё одну инициативу?»
Поэтому сильный контур управления должен контролировать не только выполнение.
Он должен контролировать входящий поток.
Сколько проектов может одновременно находиться в работе?
Какой ресурс является дефицитным?
Какие инициативы должны ждать?
Что нужно закончить прежде, чем запускать следующее?
В портфельном управлении именно прозрачность загрузки, приоритизация, управление ресурсами и зависимостями позволяют связать стратегические намерения компании с её реальной способностью исполнять изменения.
Без этого стратегия легко превращается в постоянно растущий список проектов.
Начинать меньше — значит заканчивать больше
Допустим, организация ведёт двадцать проектов одновременно.
Каждый движется медленно.
Руководство хочет ускориться.
Интуитивное решение:
усилить контроль.
Добавить людей.
Поставить более жёсткие сроки.
Но существует другой вариант.
Остановить десять проектов.
Перераспределить ресурс на оставшиеся.
Быстрее завершить их.
Освободившиеся команды направить на следующие.
В каждый отдельный момент организация будет делать меньше.
Но за год может закончить больше.
Именно здесь особенно хорошо видно различие между активностью и потоком результата.
Первая система оптимизирует количество начатой работы.
Вторая — количество законченной.
Для бизнеса второй показатель почти всегда важнее.
Это меняет и роль руководителя
Если руководитель оптимизирует загрузку, его внимание направлено на людей.
Кто свободен?
Кому ещё дать задачу?
Почему у сотрудника нет полной загрузки?
Можно ли добавить проект?
Если руководитель оптимизирует поток, вопросы становятся другими.
Где работа ждёт?
Где образуется очередь?
Какое ограничение сейчас определяет скорость?
Сколько задач находится в работе одновременно?
Где происходят лишние передачи между подразделениями?
Какие решения задерживают поток?
Что можно убрать?
Что нужно закончить раньше, чем начинать новое?
Руководитель перестаёт быть диспетчером занятости.
Он становится архитектором системы исполнения.
Метрики тоже должны измениться
Если компания измеряет только загрузку, система довольно быстро научится демонстрировать загрузку.
У всех появятся задачи.
Время будет распределено.
Количество активности вырастет.
Но это ничего не говорит о скорости получения ценности.
Поэтому рядом с показателями ресурсов необходимо видеть показатели потока.
Сколько времени проходит от начала до результата?
Сколько работы одновременно находится внутри системы?
Сколько задач завершается за период?
Где возникает ожидание?
Как часто работа возвращается на предыдущие этапы?
Насколько предсказуем срок прохождения?
Это не означает, что загрузку вообще не нужно измерять.
Она важна для понимания мощности и распределения ресурсов.
Ошибка начинается тогда, когда загрузка превращается в конечную цель.
Главная единица эффективности — законченный результат
Компания не зарабатывает на количестве открытых задач.
Клиент не получает ценность от количества часов, проведённых сотрудниками на совещаниях.
Стратегия не реализуется от количества запущенных проектов.
Результат появляется тогда, когда работа прошла через систему и что-то изменилось.
Продукт запущен.
Клиент получил решение.
Вакансия закрыта.
Процесс изменён.
Система внедрена и используется.
Проект дал ожидаемый эффект.
Именно поэтому зрелая организация постепенно перестаёт задавать вопрос:
«Как сделать так, чтобы каждый был максимально занят?»
И начинает задавать значительно более важный:
«Как сделать так, чтобы важная работа проходила через нашу систему максимально быстро и предсказуемо?»
Это требует другой управленческой логики.
Ограничивать количество одновременно запущенной работы.
Защищать узкие места.
Создавать резерв мощности.
Уменьшать очереди.
Сокращать переключения.
Управлять зависимостями.
Быстрее принимать решения.
И иногда сознательно оставлять людей не полностью загруженными.
Потому что бизнесу в конечном счёте не нужна стопроцентная занятость каждого сотрудника.
Ему нужен результат.
Можно построить организацию, где все заняты и ничего не успевает.
И можно построить систему, где у людей существует резерв, работа быстро проходит между этапами, а результат появляется раньше.
На уровне отдельного сотрудника первая система может выглядеть эффективнее.
На уровне бизнеса выигрывает вторая.
Поэтому главный вопрос управления производительностью — не:
«Насколько заняты наши люди?»
А:
«Насколько быстро через наших людей проходит ценность?»
