Почему важно знать о теории ограничения систем.

Проекты как явление существуют почти столько же, сколько человеческая деятельность, как таковая. Конечно, когда египтяне возводили пирамиду Хеопса, они не называли это “проектом”, но суть явления от этого не менялась.  Начало развития управления проектами как науки было положено еще в конце XIX века, и с тех пор эта дисциплина выработала серьёзные теоретические основы и сильную практическую методологию. Однако, эксперименты и поиски более эффективных решений не прекращаются. В одних проектах что-то работает лучше, в других хуже. В попытке найти оптимальную методологию работы появилась теория ограничений. Не смотря на то, что она была разработана доктором Элияху Голдраттом ещё в 1980-х годах, эта концепция не теряет актуальности и в проектах 2017-го. По этой причине предлагаю её рассмотреть и понять, как эта методология применима в IT-проектах.

Теория ограничений. Базовое понимание.

Теория ограничений — это метод управления, в котором мы отталкиваемся от допущения,
что любая система ограничена в развитии определённым количеством факторов. Всегда существует хотя бы один ограничитель, и в рамках данной концепции необходимо его определить и сфокусироваться конкретно на нём. Суть теории ограничений хорошо описывается фразой “цепь прочна настолько, насколько прочно её самое слабое звено”. Это значит, что процессы, организации изначально уязвимы, поскольку самая слабая их часть может повредить или сломать всю систему, или как минимум серьёзно повлиять на результаты деятельности.

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

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

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

Существует три типа ограничителей, то есть сдерживание потенциала системы может произрастать из трёх источников:

1. Оборудование — то, как оборудование используется, ограничивает возможность системы производить новые товары или услуги.
2. Люди — нехватка опытных людей ограничивает систему. Кроме того, иногда препятствием могут стать определённые ментальные модели, генерирующие контрпродуктивное поведение.
3. Политика — часто именно писанные и неписанные правила мешают производительности системы.

Кроме ограничителей, данная теория различает четыре вида производств, или фабрик (plants):

1. I-производство — линейное производство, например сборочный конвейер, когда материалы втекают в производство и обрабатываются по очереди. Основной ограничитель такой системы — самая медленная её операция.
2. А-производство — течение материалов “от многих к одному”, то есть несколько под-процессов происходят одновременно, после чего их результаты обрабатываются вместе. Основная сложность — синхронизация всех под-процессов так, чтобы их результаты подавались на финальную совместную обработку вовремя.
3. V-производство — течение “от одного ко многим”, например производство, использующее одно сырье, и производящее из него большое количество разнообразных финальных продуктов. Основная проблема этого вида — “воровство”, когда одна операция забирает на себя часть материалов, предназначавшихся другой операции, из-за чего последняя не может быть завершена.
4. Т-производство — сначала материалы текут по типу I-производства, однако позже распадаются на несколько процессов. Большинство разнообразных материалов используется в различных процессах, и большинство процессов использует различные материалы. Хороший пример этого — настраиваемые устройства вроде компьютеров. Данный вид производства страдает одновременно и от проблем с синхронизацией А-производства, и от проблемы  “воровства” V-производства.

IT-разработка, чаще всего, построена или по схеме A-производства или повторяет модель Т-производства. Тут нельзя обозначить строгое соответствие одной из указанных схем, так как создание IT-продуктов, в отличие от, например, сбора автомобилей — процесс творческий и требует особого подхода. Однако, не смотря на это базовые принципы теории ограничений работают и тут.

Анализ проблемы и поиск решения

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

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

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

Шаг 2. Определить ограничитель.
Первая и основная задача — правильно определиться с проблемным участком нашей системы, правильно определить “слабое звено”. В начале процесса улучшений такой участок легко обнаружить. Ресурс/отдел/человек, являющийся бутылочным горлышком:

• Всегда занят.
• Работа не доводится до конца и накапливается.
• Ресурсы, связанные с окончанием работы/продукта всегда простаивают.

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

Шаг 3. Оптимизировать ограничитель.
Если производительность системы ограничена производительностью самого слабого звена, первым и наиболее логичным решением будет увеличение производительности последнего. Что можно сделать?

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

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

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

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

• Позволить другим элементам системы помогать слабому звену или отрядить на них небольшую часть работы.
• Построить работу таким образом, чтобы вся система работала со скоростью слабого звена, дабы избежать перегрузки слабого звена текущей работой.
• Создать для слабого звена буфер — прослойку задач, которые позволят избежать простоев в случае задержки из-за слабого звена. Обычно в цепи системы существует два типа буферов — перед слабым звеном (чтобы убедиться, что не будет простоев у слабого звена в силу нехватки задач для него) и позади слабого звена (чтобы убедиться, что в случае невыполнения слабым звеном части задач у звеньев системы, зависящих от него, не будет простоев).
• Убедиться, что у остальных элементов системы есть свободное время или возможность овертаймов, чтобы, в случае необходимости, их можно было привлечь в помощь.
• Убедиться, что перед слабым звеном ставятся только самые важные и срочные задачи.

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

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

Шаг 5. Развивать ограничитель.
Это шаг, к которому большинство людей интуитивно хотят прибегнуть первым — добавить больше людей, больше оборудования, больше тренировки, больше инструментов, больше всего. Однако это стоит делать только после того как все “бесплатные” улучшения были проведены. Напоминаю, наша цель, максимально увеличить эффективность системы, а не просто закидать проблему шапками. Развивать ограничитель можно так:

• Увеличить размер ресурса (больше людей).
• Обучить ресурс.
• Повысить качество инструментов.
• Перейти на другую технологию.

Улучшения “развития” намного сложнее прочих, поскольку требуют дополнительного финансирования. Кроме того, они опаснее, так как  для внедрения большинства вариантов понадобится время. Более того, продуктивность может даже упасть, прежде чем улучшения начнут давать положительный результат. Например, добавляя в команду людей, нужно понизить нагрузку на неё на время, пока участники команды помогают новичкам войти в процесс. Именно поэтому не рекомендуется спешить переходить к этому этапу, в большинстве случаев в системе имеются незадействованные возможности оптимизации и делегирования.

Шаг 6. Повторить!
После внедрения каждого шага и появления положительных результатов, нужно вернуться к началу и задать себе несколько вопросов:

Наши задачи и измерения производительности всё ещё верны?

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

Пример практического применения теории ограничений.

Данный пример не имеет прямого отношения к IT отрасли, зато прекрасно иллюстрирует, как теория ограничений позволяет решать проблемы методом “out of the box”.

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

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

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

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

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

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

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

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

1. Загружать подразделение проектами ровно на столько, чтобы самый загруженный ресурс мог справляться с выделенным объёмом работы.
2. Урезать срок выполнения задач на 50%, переместив это время в буфер позади проекта на случай срыва сроков. Таким образом, время доставки было урезано до семи недель, вместо предыдущих десяти.
3. Изменять приоритеты разных процессов проекта по мере того, как этот буфер начинал истощаться. Иными словами, более активная работа начиналась на той задаче, буфер которой подходил к концу.

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

Результаты проявились сразу после внедрения изменений. За месяц количество своевременных поставок повысилось с нуля до 50%, а за три месяца — до 100%. Время доставки, как уже упоминалось, уменьшилось с десяти до семи недель. После первой волны изменений команда поняла, что существует возможность дальнейшего понижения сроков выполнения задач, в результате чего время доставки уменьшилось до шести, а потом и до трёх недель, всего лишь через четыре месяца после начала работы по методу теории ограничений. Шесть месяцев спустя количество выполняемых задач удвоилось по сравнению со старыми показателями.

Неудивительно, что с таким увеличением продуктивности ограничителя, скорость проведений клинических испытаний ощутимо увеличилась, а производство лекарства значительно продвинулось. Финальным результатом внедрения инноваций явился запуск продукта не “на пару недель раньше конкурентов”, как изначально ожидалось, а на четыре месяца раньше. Благодаря этому только за первый год продаж Big Pharma заработала на 1 миллион долларов больше, чем её конкурент, при том что само производство стоило для неё на 200 тысяч долларов дешевле.

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