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

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

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

Объяснить этот парадокс помогает теория ограничений.

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

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

В каждой компании есть своё узкое место

Представим небольшую IT-команду из пяти специалистов и одного опытного архитектора. Этот архитектор обладает редкими знаниями: он принимает ключевые технические решения, проверяет архитектуру и участвует в завершении сложных задач.

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

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

Команда производит два вида услуг.

Первая услуга требует:

• двух часов обычных специалистов;
• одного часа архитектора;
• и продаётся за три доллара.

Вторая услуга требует:

• восьми часов обычных специалистов;
• двух часов архитектора;
• и продаётся за восемь долларов.

На первый взгляд первая услуга выглядит привлекательнее. Для её выполнения требуется всего три человеко-часа, после чего компания получает три доллара. Получается один доллар выручки на человеко-час.

Вторая услуга требует десяти человеко-часов и приносит восемь долларов. Это только восемьдесят центов на человеко-час.

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

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

Причина заключается в неправильном выборе показателя.

Не все человеко-часы имеют одинаковую ценность

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

Час аналитика, час разработчика, час дизайнера, час тестировщика и час архитектора обозначаются одинаковой единицей — человеко-часом. Поэтому кажется, что их можно свободно суммировать и сравнивать.

Но с точки зрения производственной системы эти часы неравноценны.

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

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

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

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

Для первой услуги один час архитектора приносит три доллара.

Для второй услуги два часа архитектора приносят восемь долларов. Следовательно, один час ограничения приносит четыре доллара.

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

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

Компания продаёт время своего ограничения

Это один из главных выводов теории ограничений.

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

Если ограничением является архитектор, компания фактически продаёт его часы.

Если ограничением является тестирование, компания продаёт доступную мощность тестировщиков.

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

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

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

В каждый конкретный момент существует фактор, который сильнее других сдерживает общий результат.

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

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

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

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

Почему загрузка сотрудников на сто процентов разрушает поток

Руководителям психологически трудно видеть незанятых сотрудников.

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

Логика выглядит разумно:

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

Однако в системе с ограничением такая политика приводит к перегрузке.

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

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

Остальные пятьдесят превратятся в незавершённую работу.

Они будут лежать в очереди, требовать уточнений, устаревать, конфликтовать друг с другом и создавать иллюзию огромного объёма деятельности. Сотрудникам придётся переключаться между задачами, а руководителям — постоянно менять приоритеты.

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

Как появляется бесконечная приоритизация

Когда в систему запущено больше задач, чем она способна завершить, начинается борьба за дефицитный ресурс.

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

Тогда компания начинает заниматься приоритизацией.

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

Но от изменения порядка задач производственная мощность не увеличивается.

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

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

Даже из двадцати задач можно составить множество возможных комбинаций и последовательностей. Чем больше список, тем больше вариантов приходится сравнивать. Руководители могут бесконечно обсуждать, что убрать, что добавить и что передвинуть, но производство всё равно остаётся ограниченным.

Поэтому главный вопрос должен звучать не так:

В каком порядке выполнить все эти задачи?

А так:

Какой объём работы система действительно способна довести до конца?

Не начинайте больше, чем можете закончить

Перед запуском каждой новой задачи полезно провести своеобразный тест производственной пропускной способности.

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

Например, новая функция требует:

• восьми часов аналитика;
• двадцати часов разработчика;
• четырёх часов дизайнера;
• двенадцати часов тестировщика;
• двух часов архитектора.

Следующая функция имеет совершенно другой профиль:

• два часа аналитика;
• сорок часов разработки;
• два часа тестирования;
• десять часов архитектора.

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

Первая сильнее нагружает тестирование, вторая — архитектора.

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

Она может быть начата, но не будет завершена.

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

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

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

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

Свободный сотрудник способен:

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

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

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

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

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

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

Ограничение не должно простаивать

Если свободное время обычного сотрудника иногда допустимо, простой ограничения обходится компании особенно дорого.

Когда ограничение не работает, вся система теряет потенциальный выпуск.

Если тестировщик является узким местом, а у него закончились подготовленные задачи, компания теряет не только один час тестировщика. Она теряет результат всей команды, который мог бы быть завершён за этот час.

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

Важно именно слово «разумный».

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

Если запас слишком большой, появляется длинная очередь, растёт время выполнения задач и увеличивается объём незавершённой работы.

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

Пример с тестированием

Во многих IT-командах узким местом становится тестирование.

Разработчиков несколько, а тестировщик один. Планирование при этом часто ведётся по возможностям разработчиков.

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

К середине периода программисты заканчивают разработку и одновременно передают большой объём на тестирование.

Тестировщик физически не успевает проверить всё до конца спринта. Часть задач переносится. Руководство делает вывод, что отдел тестирования работает медленно.

Но проблема возникла не в тестировании. Она возникла на этапе планирования.

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

Диаграмму выполнения работ в таком случае полезно строить по нагрузке ограничения. Если она показывает, что в начале спринта тестировщику нечего делать, это не повод изменить способ подсчёта, чтобы график выглядел красивее. Это сигнал, что поток организован неправильно.

Бутылочное горлышко и настоящая причина проблемы

Большая очередь перед определённым сотрудником или отделом может указывать на ограничение, но не всегда очередь показывает истинную причину.

Представим, что перед тестированием накапливается огромное количество задач. Можно решить, что тестировщиков недостаточно.

Однако часть их времени уходит на действия, которые должны были выполнить разработчики:

• проект не собирается;
• отсутствует необходимая конфигурация;
• требования противоречат друг другу;
• не проведена базовая самопроверка;
• нет тестовых данных;
• результат невозможно развернуть.

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

Тестировщики вынуждены одновременно выполнять свою работу и компенсировать ошибки предыдущих этапов.

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

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

Эффективность отдельной команды и эффективность бизнеса

Одно подразделение может показывать отличные локальные результаты и одновременно ухудшать общий результат компании.

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

С точки зрения разработчиков это рационально:

• меньше потерь на переключение контекста;
• выше личная производительность;
• проще планировать;
• быстрее завершается программная часть проекта.

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

Иногда следующему подразделению не нужен полностью завершённый проект. Оно может начать работать после готовности первого небольшого фрагмента.

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

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

Поэтому любой показатель нужно рассматривать в контексте общей цели.

Нельзя автоматически считать полезными:

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

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

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

Автоматизацию часто обосновывают экономией человеко-часов.

Допустим, три сотрудницы каждый месяц тратят по сорок часов на подготовку отчёта. Всего получается 120 часов в месяц и 1440 часов в год.

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

Но исчезновение ручной операции ещё не означает появления экономического результата.

После автоматизации возможны разные сценарии.

В первом случае проект не будет завершён. Компания потратит бюджет и ничего не получит.

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

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

Формально часы сэкономлены. Финансового результата нет.

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

Поэтому перед автоматизацией нужно задавать вопрос не только:

Сколько часов мы сэкономим?

Но и:

Что конкретно произойдёт с высвободившимся временем и как это повлияет на прибыль?

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

Как применять теорию ограничений на практике

Работу с ограничением можно организовать в несколько последовательных шагов.

1. Найдите главное ограничение

Определите человека, отдел, процесс, оборудование, правило или внешний фактор, который сильнее всего ограничивает выпуск.

Посмотрите:

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

2. Максимально эффективно используйте ограничение

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

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

Тестировщик не должен тратить время на сборку проекта, если это могут заранее проверить разработчики.

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

3. Подчините остальные процессы ограничению

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

Это самый психологически сложный шаг.

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

4. Создайте запас перед ограничением

У ограничения всегда должна быть подготовленная работа.

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

Если запас начинает сокращаться, предыдущие этапы должны временно сосредоточиться на подготовке задач для ограничения.

5. Увеличьте мощность ограничения

Только после того как текущая мощность используется правильно, имеет смысл расширять её.

Для этого можно:

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

Наращивать мощность ограничения полезно. Ускорять неограничивающие процессы часто бессмысленно.

6. Найдите новое ограничение

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

Например, после расширения тестирования узким местом может стать разработка. После ускорения производства — продажи. После увеличения продаж — внедрение или поддержка клиентов.

Поэтому управление ограничениями — не одноразовый проект, а постоянный процесс.

Главный управленческий парадокс

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

В ней может существовать сотрудник, у которого сейчас нет собственной задачи.

Какое-то подразделение может работать не на полной мощности.

Часть доступного времени может быть оставлена под неопределённость.

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

Это кажется неэффективным, если смотреть на отдельного человека.

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

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

Компания — это не набор независимых сотрудников. Это система взаимосвязанных этапов.

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

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

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

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

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

Поэтому руководителю важно постоянно задавать три вопроса:

1. Что сейчас ограничивает результат всей компании?
2. Как максимально полезно использовать это ограничение?
3. Что должны делать остальные сотрудники, чтобы не перегружать его и не оставлять без работы?

Ответы на эти вопросы часто важнее, чем десятки локальных показателей, сложные системы KPI и бесконечные совещания по приоритетам.

Заключение

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

Если узкое место найдено и защищено, система начинает работать предсказуемее:

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

Главное ограничение нужно знать, беречь и использовать осознанно.

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

Потому что цель бизнеса — не сделать так, чтобы каждый постоянно был занят.

Цель — стабильно превращать работу компании в законченный результат и прибыль.