Узкое место решает всё: как теория ограничений помогает улучшать сложные системы

от автора

Привет, Хабр! Меня зовут Лера, я технический писатель в Авито. Сегодня в статье хочу рассказать о книге, которая около 40 лет остаётся настольной для руководителей, предпринимателей и менеджеров по всему миру. Речь пойдет о книге «Цель» Элияху Голдратта

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

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

Элияху Голдратт — израильский физик, бизнес-консультант и один из самых влиятельных теоретиков менеджмента XX века. Он разработал теорию ограничений — подход к управлению сложными системами, основанный на поиске и последовательном устранении их главных ограничений. Сегодня принципы теории ограничений применяют не только в производстве, но и в логистике, управлении проектами, разработке программного обеспечения и продуктовых командах.

Сюжет 

Крупный производственный завод постоянно срывает сроки поставок. Заказы задерживаются неделями. Склады переполнены незавершённой продукцией. Руководство недовольно результатами, клиенты уходят к конкурентам, а сотрудники работают всё больше и больше, но ситуация становится только хуже.

В какой-то момент Алекс Рого, директор завода, получает ультиматум от руководства: за три месяца ему предстоит сделать предприятие эффективным. 

Пытаясь разобраться в происходящем, Алекс обращается к своему бывшему преподавателю физики Йоне. Именно через диалоги с Йоной Голдратт постепенно раскрывает, что же такое «настоящая» эффективность. 

В статье вместе с героями разберёмся:

Коллеги, а какая у нас цель?

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

Парадокс (или реальность бизнеса?): локальные показатели могут выглядеть нормально, но бизнес в целом всё равно не достигает результата.

Переломный момент наступает, преподаватель Йона задает Алексу простой вопрос, который точно звучит у вас на дейликах: в чём цель завода?

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

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

Голдратт предлагает смотреть на бизнес через три ключевых показателя:

  • проход / throughput — сколько денег система зарабатывает через продажи;

  • запасы / inventory — сколько денег заморожено в материалах, незавершённой работе и готовой продукции;

  • операционные расходы / operational expense — сколько денег система тратит, чтобы превращать запасы в продажи.

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

Эффективность имеет смысл только тогда, когда она помогает всей системе двигаться к цели.

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

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

Тут еще больше контента

Оптимизировать нельзя устоять

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

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

Роботы-автоматизаторы

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

Но был нюанс. 

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

Йона объясняет это на простом примере: представьте колонну туристов, идущих по лесу. Скорость всей группы определяется не самым быстрым участником, а самым медленным. Если подгонять самых быстрых, это не ускорит группу. Наоборот, расстояние между людьми станет только больше.

Именно это происходило на заводе.

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

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

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

Жми сюда!

Что такое ограничение системы и как его находить

Было ли у вас такое, что кажется, что проблем в бэклоге — сотни, и каждая из них важна? С этим же и столкнулся Алекс, и Йона задал ему простой вопрос:

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

В вопросе кроется главный принцип теории ограничений:

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

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

С заводом происходит то же самое.

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

Мальчик Херби и поиск узкого места

К пониманию ограничений Алекс приходит во время похода со скаутами (американские пионеры). Он замечает, что колонна постоянно растягивается: быстрые ребята уходят вперёд, а остальные отстают. Причиной оказывается скаут Херби — самый медленный мальчик из группы. Как бы ни ускорялись остальные, вся колонна всё равно движется с его скоростью.

Тогда Алекс ставит Херби впереди и распределяет часть содержимого его тяжёлого рюкзака между другими ребятами. После этого группа начинает двигаться быстрее и держаться вместе. Так Херби становится метафорой ограничения — самого медленного звена, которое определяет скорость всей системы.

Вернувшись на завод, Алекс начинает искать своих «Херби». Вместе с командой он анализирует производственный поток и обнаруживает два участка, перед которыми постоянно скапливаются детали: станок NCX-10 и термообработку. Именно они определяют пропускную способность всего завода. Пока эти ресурсы не могут обрабатывать больше деталей, ускорение остальных участков лишь увеличивает объём незавершённого производства.

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

Пять шагов теории ограничений

Найти ограничение — только половина дела. Когда Алекс и его команда обнаруживают два узких места — станок NCX-10 (далее буду упоминать его как NCX-10) и участок термообработки. Первое решение кажется очевидным: купить новое оборудование. Но согласования и поставка займут месяцы, а завод нужно спасать прямо сейчас. Поэтому Йона предлагает сначала научиться правильно работать с уже существующими ограничениями.

Так Алекс постепенно приходит к пяти фокусирующим шагам теории ограничений.

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

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

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

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

Команда Алекса обнаруживает, что самые ценные ресурсы завода используются хаотично. NCX-10 иногда простаивает без материалов, а иногда обрабатывает детали, которые не нужны для срочных заказов.

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

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

Если NCX-10 способен обработать 100 деталей в день, нет смысла производить перед ним 200. Лишние детали не ускорят выпуск заказов, а лишь пополнят запасы незавершённого производства.

Поэтому остальные участки начинают работать в ритме ограничения. Часть станков простаивает, локальные показатели снижаются, зато готовые заказы быстрее доходят до клиентов. Так Алекс понимает: эффективность отдельного участка не всегда означает эффективность всей системы.

Шаг 4. Расширьте возможности ограничения

Только после того, как команда использовала узкие места по максимуму, можно увеличивать их мощность. Часть операций с NCX-10 переносят на другие станки, сокращают количество переналадок и пересматривают маршруты деталей.

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

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

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

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

Высокая загрузка сотрудников не равна высокой эффективности

Одна из основных идей Голдратта заключается в том, что люди и оборудование не должны быть постоянно загружены на 100%. На заводе Алекса всё было устроено ровно наоборот: простой станка считался потерей денег, а свободный сотрудник — признаком плохого управления. Поэтому каждый участок стремились загрузить по максимуму. Однако постепенно Алекс понимает, что именно такой подход во многом и привёл предприятие к кризису.

Объяснение он снова находит во время похода со скаутами: скорость каждого зависит от того, кто находится перед ним, замедляется один человек — замедляется процесс. 

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

При этом ни один этап не работает совершенно предсказуемо. Задача может оказаться сложнее, оборудование — сломаться, поставщик — задержать материалы. Голдратт называет такие отклонения статистическими колебаниями. В походе Алекс замечает, что небольшие задержки отдельных мальчиков постепенно накапливаются, из-за чего колонна растягивается всё сильнее. То же происходило и на заводе: маленькие отклонения на каждом участке превращались в большие очереди незавершённой продукции.

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

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

Кликни здесь и узнаешь

Как применить идеи Голдратта в команде

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

Принцип

Что делать

Не оптимизируйте всё подряд

Сначала определите, что действительно замедляет весь процесс

Найдите своего Херби

Ищите главное ограничение: человека, команду, процесс или инфраструктуру

Смотрите на поток, а не на загрузку

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

Ограничивайте незавершённую работу

Заканчивайте начатое до запуска новых задач и используйте WIP-лимиты

Оставляйте запас мощности

Не стремитесь занять каждого сотрудника на каждую минуту

Главный вопрос руководителя в этой логике звучит так: что сейчас больше всего ограничивает скорость всей системы?

Выводы

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

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

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

А что вы пойдёте менять в своих рабочих процессах прямо сейчас?

Кстати, если вам интересна работа в бигтехе —  Хабр совместно с ЭКОПСИ проводит большое исследование IT-брендов работодателей. В прошлом году в нём поучаствовали 34 000 специалистов. Если у вас есть опыт — он точно будет учтён.

ссылка на оригинал статьи https://habr.com/ru/articles/1055388/