В исходном виде управление проектами по ТОС не распространялось на системы одновременных проектов. В появившейся в 1997 году книге Голдратта «Критическая цепь» (Critical Chain) [5] проблеме конфликта ресурсов на подобных проектах посвящена всего пара страниц. На мой взгляд, важность системного подхода к управлению одновременными проектами открыл Тони Риццо из компании Lucent Technologies, однако пока у него не вышло никаких публикаций на сей счет. В этом отношении тон процессу достижения результата задавал сам результат, то есть сначала появилось решение для системы проектов и потом лишь были построены деревья текущей и будущей реальности (ДТР и ДБР), подводящие к этому решению.
К сожалению, находится не так уж много желающих досконально следовать правилам построения и критического анализа логических диаграмм ТОС. Данные, приводимые Эриком Норином, Деброй Смит и Джеймсом Маккеем [6], показывают, что информация, даваемая на так называемых курсах Ионы, очень мало используется в дальнейшем. (Иона — герой первой книги Голдратта [7], в честь которого в AGI назвали тренинг по процессу логических рассуждений ТОС.) Мои собственные (ненаучные) исследования в этой сфере, а также обсуждения в интернет-сообществе ТОС свидетельствуют о том, что ситуация не очень-то изменилась за последние несколько лет. То есть мало кто на практике использует знания, получаемые на курсах Ионы, и еще меньше тех, кто с помощью этой методики находит революционные решения своих проблем. Есть основания полагать, что индуктивным путем ТОС никогда не прийти к по-настоящему творческому решению вопроса [8, 9]. Думаю, Карл Поппер и Е. Де Боно согласились бы, что у таких людей, как Голдратт, гипотезы рождаются сами, а потом уже проходят проверку процессом рассуждений ТОС. Многие пользуются данной методикой, чтобы подвести логическое обоснование под решения, предлагаемые ТОС, например, для производственных систем или в управлении проектами. Логические деревья дают лучшее представление о системе и помогают совершенствовать ее. Однако они же могут и сдерживать дальнейшие улучшения, поскольку определенным образом ограничивают круг видимых проблем.
Понимая принцип работы метода критической цепи, вы сможете определить, соответствует ли ваша система тем предположениям о текущей реальности, на которых основан ССРМ. Если расхождения значительны, вам придется изменить модель желаемой действительности и те прорывные методы, которые позволят воплотить ее в жизнь.
Диаграммы, полученные в результате процесса логических рассуждений ТОС, весьма объемны и не могут быть полностью включены в книгу. Полную версию смотрите на сайте компании Advanced Projects по адресу: http://www.advanced-projects.com.
11.3. Дерево текущей реальностиДерево текущей реальности ДТР описывает систему в том виде, в каком она существует сейчас. Такое представление необходимо, чтобы найти ключевой конфликт. Ключевой конфликт — это истинная причина множества нежелательных явлений (НЯ). Создание ДТР начинается с выявления НЯ — то есть тех явлений, которые беспокоят вас на данный момент. Например: «Меня по-настоящему беспокоит, что проекты идут с нарушением сроков». Нежелательные явления в управлении проектами перечислены в главе 3.
Затем выбираются три НЯ и формулируется ключевой конфликт. Сначала конфликт выявляется по каждому из трех НЯ, затем все три конфликта комбинируются и из них выводится один, обусловивший их появление, — ключевой. Диаграмма разрешения конфликтов «грозовая туча» для проблем управления проектами также представлена в главе 3. ДТР устанавливает причину появления ключевого конфликта, ведущего к большинству (если не ко всем) НЯ. Этот конфликт, играющий важную роль в системе, и будет той оптимальной точкой, к которой следует приложить усилия, чтобы добиться перемен.
На рис. 11.3 показано ДТР по текущему состоянию управления проектами. В нем нашел отражение и ключевой конфликт, расписанный в главе 3
(рис. 3.13). Получилась ДРК, где элементы, включая и вызвавшие конфликт исходные установки, связаны логикой достаточности. Читаем диаграмму снизу вверх и получаем: «Если все хотят, чтобы проекты выполнялись успешно, и если в условиях возросшей конкуренции руководство и заказчики требуют многого в кратчайшие сроки и за минимальные деньги, то успешным признается проект, в ходе которого добились большего за меньший срок и с меньшим бюджетом». Далее: «Если успешным признается проект, в ходе которого добились большего за меньший срок и с меньшим бюджетом, и если единственным способом уменьшить длительность критического пути является уменьшение длительности работ на критическом пути, а единственным способом сократить расходы является снижение расходов по каждой проектной операции, то возникает насущная необходимость пересматривать оценочные значения операций в меньшую сторону».
Аналогичным образом читается правая цепочка, которая подводит нас к блоку 9: «Возникает насущная необходимость закладывать в оценочные значения операций запас на непредвиденные обстоятельства. Это противоречит необходимости уменьшать оценочные значения операций. Так при планировании проекта возникает конфликт».
Заметьте, что я опустил слова «все больше и больше», которые включены в схему. Они обретают смысл, если вы повторно несколько раз обсуждаете диаграмму в вашей организации. Также обратите внимание, что некоторые НЯ, являющиеся следствием на верхних уровнях диаграммы, служат в то же время причиной НЯ нижних уровней, и наоборот.
На рис. 3.14 представлены ориентировочные связи НЯ, логика появления которых в таком обобщающем представлении не очевидна. Полное дерево содержит множество промежуточных связей, которые показывают появление тех или иных НЯ под влиянием принятого в организации образа мыслей и действий. Главная идея рис. 3.14 в том, чтобы показать причинные связи всех НЯ и их происхождение из единого ключевого конфликта.
Дерево текущей реальности, посвященное управлению проектами в целом, не может отразить всех особенностей вашей ситуации. Мне приходилось консультировать компании как с очень развитой, так и с весьма упрощенной системами проджект-менеджмента. Как это ни странно, организациям с минимальным управлением проектами проще перестроиться на работу по методу ССРМ. Некоторые утверждают, что в этих случаях успех вызван не самим ССРМ, а просто тем, что вообще вводится некая упорядоченная система ведения дел. Я с этим не согласен, потому что в компаниях, где принято решать много задач одновременно, традиционный подход к управлению проектом только усугубил бы ситуацию. Не так уж редко доводится встречать людей, считающих планом проекта диаграмму Гантта, в которой нет никакой логики между операциями и указана лишь дата окончания работ, и то заданная кем-то извне. За несколько месяцев таких менеджеров спокойно можно научить строить эффективные планы по методу критической цепи, управлять при помощи буферов и вести проекты все успешнее и успешнее.
