• (PDF) Элияху М. Голдратт - Критическая цепь (2006)
• TOGAF и Теория Ограничений - Деревья (Александр Кварцхава, 2018). О дереве текущей реальности, дереве разрешения конфликтов, дереве будущей реальности.
• Курс лекций о совместном применении Теории Ограничений и TOGAF (Александр Кварцхава, 2018).
• Управление - PERT/GERT
• Стейкхолдеры

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

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

Основные проблемы, присущие большинству проектов, можно определить как высокую вероятность:

• превышения бюджета
• опоздания по срокам
• урезания содержания

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

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

Делая оценку по времени, руководство закладывает подстраховку от неопределённости.
В большинстве случаев, управленцы удобно себя чувствуют при 80-90% вероятности выполнения задания в срок.
Однако, распределение вероятности успеха таково, что с определённой точки каждый добавочный процент вероятности успеха будет "стоить" всё больше и больше времени.
Пример:

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

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

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

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

Поздний старт. Ранний старт.

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

скачать схему в формате diagrams.net (бывший draw.io)

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

Предположим, что один из ваших менеджеров говорит вам, что он провёл отличную работу по сокращению затрат: ему удалось сократить затраты на 20%. Правда, это привело к тому, что 50% ваших клиентов крайне недовольны уровнем обслуживания. Вы назовёте такого менеджера хорошим?
Другой менеджер обеспечил проход - выполнил все поставки в срок, но для этого набрал дополнительных людей и перевёл всех на бесконечную сверхурочную работу. Хороший ли он менеджер?
Контролировать затраты и обеспечить проход. Два абсолютно необходимых условия. Мы не достигнем нашей цели, если удовлетворим только одно из этих двух условий. И эти подходы настолько противоположны, что приемлемого компромисса между ними не существует.

Прочность цепи определяет самое слабое звено.
А теперь давайте посмотрим, что это предполагает. Вы всё так же президент, отвечающий за всю цепь. Я всё так же отвечаю за один отдел. Поскольку существует только одно самое слабое звено, давайте возьмём более распространенный случай: отдел, за который я отвечаю, НЕ является самым слабым звеном. И... вы опять говорите мне, что я должен добиться улучшений. На этот раз улучшить прочность звена. И опять через какое-то время я прихожу к вам и говорю, что в результате моей гениальности и денег и времени я добился улучшения. Я усилил прочность моего звена. Я сделал его в три раза прочнее.
Но ведь вас на самом деле интересует не моё звено, а вся цепь.
Моё звено не было самым слабым. Если я сделал его прочнее, насколько я увеличил прочность цепи? Ни на сколько. Абсолютно ни на сколько.

Теперь вы видите что на самом деле происходит? Большинство локальных улучшений не помогают глобальному! А мы хотим глобального улучшения, мы хотим, чтобы организация как целое добилась улучшения. Теперь мы знаем, что поскольку любое улучшение требует внимания, времени и денег, обеспечение многих локальных улучшений по принципу "чем больше -- тем лучше" определённо не является тем путём, который приведет к улучшению всей организации. Это неверный путь.

Вам знакомо выражение "синдром конца месяца"?
В начале месяца мы контролируем затраты. Жёстко следим, что не было сверхурочной работы, чтобы размер производимых партий был оптимальным.
Но в конце месяца кто об этом помнит? Делается всё, только чтобы выпихнуть заказ с производства: партия из трёх недостающих единиц, сверхурочная работа на все выходные. Только отгрузите этот чёртов заказ!

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

• Шаг 1: НАЙТИ ограничение(я) системы. Найти её самое слабое звено.
  Отлично, мы нашли ограничение. Если мы посмотрим на организации, мы с легкостью увидим, что существует два различных случая. Первый -- когда мы определили, что ограничением является физический ресурс -- бутылочное горлышко, то есть ресурс, у которого недостаточно мощности для того, чтобы удовлетворить спрос. В этом случае усилить самое слабое звено будет означать, что мы должны помочь бутылочному горлышку делать больше. Но мы не должны забывать про другой случай: тот, когда мы выяснили, что ограничением является ошибочная политика (правило) организации. В этом случае усиление слабого звена не должно пониматься как то, что мы хотим помочь ошибочной политике "делать" больше. Мы должны заменить ошибочную политику.
• Шаг 2: Решить, каким образом МАКСИМАЛЬНО ИСПОЛЬЗОВАТЬ ограничение(я) системы.
• Шаг 3: ПОДЧИНИТЬ всё остальное принятому решению.
  Если мы не можем выжать из бутылочного горлышка больше 10 единиц, нет никакого смысла производить больше в не-бутылочных горлышках.
• Шаг 4: РАЗВИТЬ (расширить) ограничение(я) системы.
• Шаг 5: ВЕРНУТЬСЯ к первому шагу.
  Я усиливаю слабое звено. Вся цепь становится прочнее. Я ещё усиливаю его. Вся цепь становится ещё прочнее. Я ещё усиливаю его. И ничего не происходит. Почему? Это звено перестало быть ограничением. Поэтому я должен не допустить инерции и вернуться к первому шагу. Мы нашли процесс для сфокусированности. Это процесс сфокусированности для мира прохода. И в то же время это также процесс непрерывного улучшения.

Диаграмма разрешения конфликтов (ДРК)

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

Задача менеджеров -- хорошо управлять. Для того чтобы хорошо управлять, одним необходимым условием является контролировать затраты, а другим -- обеспечить проход. Но для того чтобы контролировать затраты, менеджеры должны управлять в соответствии с миром затрат. А для того чтобы обеспечить проход, менеджеры должны управлять в соответствии с миром прохода. И как мы видим, эти два условия находятся в конфликте. И что мы делаем? Мы пытаемся найти компромисс. А если его нет? Полный тупик.
Одно из основных положений ТОС заключается в том, что каждый раз, когда мы видим конфликт, это чёткое проявление того, что кто-то сделал неверную исходную посылку, которую можно исправить и таким образом устранить конфликт.

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

А почему мы утверждаем, что для того чтобы обеспечить проход, менеджеры должны стараться управлять в соответствии с миром прохода? Потому что мы полагаем, что достижение хороших результатов с точки зрения прохода невозможно за счёт повсеместного достижения хороших локальных результатов

Теперь у нас есть три альтернативы:

• мы можем подвергнуть сомнению верхнюю исходную посылку
• ИЛИ мы можем подвергнуть сомнению нижнюю исходную посылку
• ИЛИ мы можем продолжать искать компромисс

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

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

Дерево текущей реальности (ДТР)

Дерево текущей реальности (ДТР) -- это инструмент для анализа проблем. С его помощью можно изучить причинно-следственные связи, определяющие текущую ситуацию. ДТР начинается с имеющихся нежелательных явлений в системе (симптомов) и помогает добраться до ряда истинных причин или же до одной ключевой проблемы, вызвавшей все нежелательные явления, с которыми мы столкнулись. Ключевая проблема обычно и является тем ограничением, которое мы стараемся найти, используя тактику пяти направляющих шагов. ДТР подсказывает нам, что именно реорганизовать, -- выявляет наименьшее, простейшее изменение в системе, которое даст наибольший положительный эффект.
Дерево строится "сверху вниз", идём от симптомов, каждый раз задавая себе вопрос "А почему?", к корням.
В общем виде это выглядит так:

Пример: Пример из жизни:

Подстраховка и её разбазаривание.

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

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

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

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

Предположим, что работник должен сделать три элемента: А, В и С. Эти элементы могут входить в разные проекты или в один, это значения не имеет. Выполнение каждого элемента требует ровно 10 рабочих дней. Если он будет работать с элементами последовательно, то на исполнение каждого элемента уйдёт 10 дней. Так, через 10 дней после того, как он начнет работу над В, В будет готов и его передадут другому человеку для дальнейшей работы. Но наш работник находится под давлением и старается удовлетворить требования всех. В результате он работает с одним элементом 5 дней и переходит к другому элементу. Предположим, что он работает с элементами в такой очередности А, В, С, А, В, С. Каким будет время исполнения каждого элемента?

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

Есть три механизма разбазаривания подстраховки:

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

Буферы времени

• Мы не должны защищать подстраховкой каждый отдельный элемент проекта.
• Каждый элемент содержит в себе минимум 200% подстраховки
• Но мы должны заложить подстраховку.

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

Что можно сделать - время, запланированное для каждого элемента, будет сокращено наполовину.
С другой стороны, буфер проекта не будет равен тому времени, которое мы забрали из всех элементов. Он будет сокращен наполовину:

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

Итак, мы:

1. Убедили различные ресурсы урезать оценки по времени
2. Мы отказались от контрольных точек, или, другими словами, устранили даты завершения отдельных элементов
3. Мы ввели отчёт об ожидаемом времени завершения

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

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

Критическая цепь. Конкуренция за ресурсы.

Во многих проектах может случиться следующее - ресурс Х требуется в нескольких местах одновременно. На протяжении определенного времени Х перегружен и начинает отставать. Это ызывает опоздания, которые тянутся от одного некритического пути в другой. Питающие буферы недостаточно велики, чтобы поглотить эти опоздания. Неудивительно, что его критический путь прыгает с одного пути на другой.

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

Если существует конкуренция за ресурсы -- критическая цепь может значительно отличаться от критического пути.
В этих случаях в чем действительная опасность следования критическому пути, а не критической цепи?
Это может привести к катастрофам. Критический путь начинает прыгать. Ты теряешь контроль.
Необходимо добавить в PERT названия ресурсов.
Необходимо добиться максимального устранения конкуренции за ресурс.

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

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