Глава 11. Логические инструменты ТОС в управлении проектами

We use cookies. Read the Privacy and Cookie Policy

Глава 11. Логические инструменты ТОС в управлении проектами

Эта глава подводит итог всему сказанному ранее. Я опишу, каким образом убедился в необходимости использовать метод критической цепи в управлении проектом. Также перечислю ряд идей, над которыми еще стоит подумать. Деминг видел одно из препятствий успешным преобразованиям в склонности менеджеров ориентироваться на примеры. Он говорил: «На просьбы привести пример аналогичной ситуации я всегда отвечаю, что никакие примеры успешных или неудачных попыток повышения качества и производительности не покажут, чего стоит ожидать именно в вашем случае» [1]. Далее Деминг пишет: «Вопрос не в том, успешно ли предприятие, а в том, почему оно именно такое, какое есть. И почему оно не добилось более значимых результатов? Необходимо в теории представлять, чего мы хотим достичь». Вы уже познакомились с принципами ССРМ вкупе с некоторыми сопутствующими положениями теории ограничения систем, TQM, шести сигм, бережливого производства, гибких методологий Agile и РМВОК. Описываемый в данной главе процесс логических рассуждений ТОС, разработанный Голдраттом, — это инструмент для наглядной передачи хода мыслей, изложенных ранее.

11.1. Синтез принципов

Матрица на рис. 11.1 показывает, где и как можно использовать инструменты ТОС в управлении проектами. Из нее видно, что положения ТОС и принципы управления проектами дополняют друг друга. По непонятной мне причине кое-кто противопоставляет ТОС (и концепцию критической цепи) традиционному управлению проектами. Как уже говорилось в самом начале, я считаю, что теория ограничений — один из приемов непрерывного совершенствования управленческого мышления и что она способна принести огромную пользу в управлении проектами. В этой главе мы рассмотрим каждый из инструментов ТОС, перечисленных в таблице, и узнаем, как их можно использовать в дополнение к ССРМ.

Рис. 11.2 демонстрирует соотношение ССРМ и ключевых управленческих концепций, описанных в главе 2. Верхние строки еще раз показывают, что ССРМ — это комбинация традиционного управления проектами и концепции критической цепи ТОС. Ключевые принципы бережливого производства взяты у авторов Дж. Вумек и Д. Джонс [2]; шести сигм — у П. Панде, Р. Ньюмена и Р. Каванаг [3]; принципы TQM — это пункты теории глубинных знаний Деминга, а теория ограничений представлена пятью направляющими шагами. (Другие инструменты ТОС, о которых пойдет далее речь, отражены на рис. 11.1.) Цель рис. 11.2 — передать, насколько многогранен результат синтеза перечисленных концепций. Конечно, существуют взаимосвязи и между пунктами, перечисленными в столбце (и, соответственно, между теми, которые приведены в верхней строке матрицы тоже). Если вдруг между ними возникает конфликт, можете устранить его при помощи инструментов ТОС, описанных далее.

Разработанный PMI стандарт ОРМ3 [4] является продолжением РМВОК в приложении к программам и портфелям проектов. До сих пор мы с вами не говорили об этом уровне управления проектами, однако и к нему можно применить метод ССРМ. Можно использовать описанные далее инструменты или просто подумать, а как бы изменился состав портфеля проектов, если при выборе руководствоваться правилами ТОС. Дискуссия в интернет-сообществе ТОС (ТОС Internet group) продемонстрировала, что некоторые простые приемы могут быть использованы и на этом уровне управления, однако в детали никто пока не вдавался и эффективной методики не сформулировал. В заключение прозвучала рекомендация учитывать влияние неопределенности применительно к любому проекту (причем неопределенность в окупаемости проекта чаще всего намного выше неопределенности содержания, сроков и стоимости), а также заранее просчитывать различные варианты развития событий и их влияние на производительность по денежному потоку и операционные расходы компании. Участники дискуссии справедливо подчеркивают, что выбор проектов для портфеля осуществляется на основании ранее принятых решений (то есть уже идущих проектов) и что все новые инициативы должны оцениваться с учетом этих уже запущенных проектов или, если хотите, вместе с ними.

11.2. Используем логические рассуждения по ТОС в управлении проектом

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

В главе 2 я заявлял, что для успешного применения ССРМ нет необходимости четко понимать теорию ограничений и ее методы. Казалось бы, это противоречит приводимому ранее высказыванию Деминга. Противоречие «рассеивается», если вы поймете легшие в основу ССРМ исходные установки, упоминавшиеся на протяжении всей книги. Для применения метода достаточно понимать, в чем залог его успеха. Если сравнить описание исходных условий, на которые мы опирались в данной книге, с особенностями вашей организации, можно будет соответствующим образом адаптировать под себя весь процесс. Некоторые составляющие процесса настолько полезны (например, устранение негативной многозадачности), что положительные результаты от применения ССРМ проявятся, даже если внедрение в вашей компании будет отличаться от того, что рекомендовано в книге. Ряд довольно гибких организаций, так сказать, первопроходцев, успешно перешли на работу по ССРМ, даже не зная о существовании процесса логических рассуждений и обладая лишь поверхностными сведениями об остальных инструментах ТОС. В других компаниях элементы ССРМ были внедрены в рамках иных управленческих концепций, таких как бережливое производство или шесть сигм.

Мне посчастливилось еще в августе 1994 года познакомиться с ранней версией процесса логических рассуждений ТОС в приложении к управлению проектами. Этот вариант использования инструментов ТОС был разработан Ди Джейкобом совместно с Голдраттом и другими специалистами института Голдратта AGI. В сущности, он уже обладал всеми признаками, присущими методу критической цепи в управлении отдельными проектами, и показался мне заслуживающим особого внимания. Изменения, произошедшие с 1994 года, по большей части касаются способов представления результатов и не затронули самой сути построения системы управления отдельными проектами.

В исходном виде управление проектами по ТОС не распространялось на системы одновременных проектов. В появившейся в 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 в том, чтобы показать причинные связи всех НЯ и их происхождение из единого ключевого конфликта.

Дерево текущей реальности, посвященное управлению проектами в целом, не может отразить всех особенностей вашей ситуации. Мне приходилось консультировать компании как с очень развитой, так и с весьма упрощенной системами проджект-менеджмента. Как это ни странно, организациям с минимальным управлением проектами проще перестроиться на работу по методу ССРМ. Некоторые утверждают, что в этих случаях успех вызван не самим ССРМ, а просто тем, что вообще вводится некая упорядоченная система ведения дел. Я с этим не согласен, потому что в компаниях, где принято решать много задач одновременно, традиционный подход к управлению проектом только усугубил бы ситуацию. Не так уж редко доводится встречать людей, считающих планом проекта диаграмму Гантта, в которой нет никакой логики между операциями и указана лишь дата окончания работ, и то заданная кем-то извне. За несколько месяцев таких менеджеров спокойно можно научить строить эффективные планы по методу критической цепи, управлять при помощи буферов и вести проекты все успешнее и успешнее.

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

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

11.3.1. ПОЛИТИКИ, ОЦЕНКИ, МОДЕЛИ ПОВЕДЕНИЯ

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

11.3.2. ЦИКЛЫ ОБРАТНОЙ СВЯЗИ

ДТР в полном виде, как правило, содержит также особые структуры — замкнутые циклы, элементы которых поддерживают и усиливают друг друга. Пример — на рис. 11.3, где блоки 1, 2, 3 «питают» блок 9, а тот,

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

Замкнутые циклы, как правило, содержат в себе ту оптимальную точку, к которой следует приложить усилия, чтобы изменить систему. Поэтому к ним всегда стоит относиться с особым вниманием. Один из циклов обратной связи обязательно связан с системой оценок (если не так, зачем она вообще нужна?). Двумя важными для успеха ССРМ сигналами являются реакции руководства на использование среднеоценочных показателей при планировании, а также на отчеты о состоянии буферов.

11.3.3. КРИТИЧЕСКИЙ АНАЛИЗ

Результаты процесса логических рассуждений необходимо подвергать критическому анализу. Это основной способ проверить, что гипотезы, выработанные в рамках этого процесса, в большей степени соответствуют действительности, чем какие-то альтернативные идеи. Есть, конечно, испытанный метод научного эксперимента, однако его очень трудно применять для таких сложных систем, как проекты. В главе 3 мы говорили о том, что при помощи научного метода теории познания (пример — ТОС) вы никогда не сможете доказать справедливость той или иной гипотезы. Максимум, на что можно рассчитывать, — это путем критического анализа удостовериться, что одно предположение более точно описывает действительность, чем другое.

Критический анализ результатов процесса логических рассуждений проводится следующим образом. Каждая диаграмма исследуется по Критериям проверки логических построений (КПЛП). Я впервые услышал об этой методике от членов AGI, однако подозреваю, что и они, в свою очередь, заимствовали ее логику у кого-то еще. К сожалению, ни Голдратт, ни кто-либо из AGI не раскрывают источников своих материалов. КПЛП описаны у Детмера [10] и других авторов, однако ссылки при этом даются только на AGI.

Критерии проверки логических построений:

• Ясность: все ли понимают значения используемых в диаграмме слов?

• Наличие утверждения: можно ли доказать или опровергнуть справедливость высказанной мысли?

• Наличие причинно-следственных отношений: можно ли доказать правильность указанной причины? (Обычно доказательством служит тот факт, что данное следствие всегда проявляется, если есть указанная причина, и никогда не обнаруживается, когда этой причины нет.)

• Достаточность приведенной причины: помимо указанной причины, не требуются ли еще другие условия, чтобы проявилось данное следствие?

• Проверка наличия альтернативной причины: может ли данное следствие проявляться без указанной причины или под действием каких-то других причин? (Принцип «достаточной приемлемости» в ТОС говорит, что необходимо останавливаться лишь на тех причинах, которые приводят к данному следствию хотя бы в трети случаев.)

• Отсутствие подмены причины следствием, или «пожар»: «Если виден дым, значит, случился пожар» — яркий пример подмены; создается ложное впечатление, будто бы это формулировка причинноследственных отношений, тем более что используется конструкция «если... то». Правильно говорить: «Если я вижу дым, то я понимаю, что в доме случился пожар». Конечно, наличие дыма не является причиной пожара.

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

• Тавтология: знаменитое «Этого не может быть, потому что этого не может быть никогда». Или еще пример:

Джо: «Если каждый день дудеть в трубу, у меня в гостиной слонов не будет».

Дэн: «Почему ты так считаешь?»

Джо: «Ну разве ты видишь в моей гостиной хоть одного слона?»

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

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

11.3.4. ПОДДЕРЖКА УЧАСТНИКОВ

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

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

Я заметил, что большинство людей интуитивно понимают и принимают правильность использования диаграммы разрешения конфликтов. Три «грозовые тучи», которые подводят нас к мысли о ССРМ, способно воспринять даже высшее руководство. Это будет проще и быстрее, чем пытаться получить их согласие на выработанные вами прорывные решения найденного ключевого конфликта.

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

11.4. Дерево будущей реальности

Если ДТР показывает, «что именно менять», то дерево будущей реальности описывает, «на что менять». Это ваше представление об идеальном состоянии системы, ваше видение. Когда вы беретесь за преобразования, призванные искоренить все НЯ текущей реальности, этой идеальной системы еще не существует. Результатом построения дерева будущей реальности является набор неких революционных решений, которые необходимо реализовать, чтобы перевести систему в желаемый вид. Революционное решение, или прорыв, — это то, что вызовет к жизни будущую реальность. Прорыв — это не действие. Чтобы осуществить преобразования, необходимо выработать план соответствующих мероприятий.

11.4.1. ЖЕЛАЕМЫЙ РЕЗУЛЬТАТ

Создание ДБР начинается с того, что все нежелательные явления мы переформулируем в желаемые результаты (ЖР). На рис. 11.4 приведены ЖР, характерные для эффективной системы управления проектами. Также показано, где в схеме находится прорыв — революционное изменение в системе.

11.4.2. ПРОРЫВНЫЕ РЕШЕНИЯ

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

Вот перечень прорывов для внедрения ССРМ:

• Снизить оценочную длительность операций на 50%. Руководители проектов составляют сетевую диаграмму проекта без закладывания резерва по ресурсам или времени. При этом учитывается максимально вероятная длительность операций. Мы же используем оценку с вероятностью 50%, то есть вдвое уменьшаем оценочную длительность работ.

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

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

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

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

• Планировать начало операций по правилу «как можно позднее», соблюдение сроков защищается буфером. Это тоже подчинение операций нуждам ограничения, ведь в данном случае, как правило, в первую очередь запускается критическая цепь и не более одной-двух других цепочек работ.

• Работать в стиле «эстафеты». Не допускать многозадачности и проявления студенческого синдрома. Исполнитель принимается за операцию при первой же возможности, выполняет ее максимально быстро и сразу же передает готовый результат на следующий этап. Так мы начинаем устранять ограничение.

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

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

На рис. 11.5 показаны прорывные события в том порядке, в каком они появляются в ДБР.

11.4.3. ДБР КАК РУКОВОДСТВО

ПО ПРОВЕДЕНИЮ ПРЕОБРАЗОВАНИЙ

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

ДБР — своего рода проверка правильности ДТР. При создании ДБР часто обнаруживаются связи, не учтенные при разработке ДТР. Однако, поскольку ДБР сосредоточено на будущем, нет смысла прерываться на корректирование ДТР.

В основе ДБР лежат перечисленные ранее прорывные события. Каждое из них сопровождается объяснением, почему именно оно видится нам необходимым и как оно может помочь.

11.4.4. ЦИКЛЫ ОБРАТНОЙ СВЯЗИ

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

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

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

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

11.4.5. НЕЖЕЛАТЕЛЬНЫЕ ПОСЛЕДСТВИЯ И НЕГАТИВНЫЕ ВЕТВИ

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

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

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

На рис. 11.6 представлена НВ для ССРМ, отражающая распространенное опасение, что явное отображение запаса времени в плане неизбежно побуждает руководство и клиентов этот запас урезать. В литературе по традиционному управлению проектами в данном случае советуется планировать запасное время в скрытой форме. Однако это трудно назвать профессиональным подходом к делу!

Первым делом вы рисуете диаграмму, в которой прорыв связывается с неким НЯ. НВ основана на логике достаточности, как ДТР и ДБР, и читается при помощи формулировок «если... то». Думаю, вы уже поняли, как следует читать логические диаграммы. Построение необходимо проанализировать по КПЛП.

Построив НВ, мы должны подумать, как предотвратить появление нежелательного эффекта. Для этого мы тщательно изучаем диаграмму и выявляем ту точку, в которой ход событий меняет свой оттенок на негативный. В нашем случае этой поворотной точкой оказывается блок 602 — «Клиенты хотят сократить длительность проекта и урезать буфер». Затем мы выявляем исходные установки, легшие в основу появления стрелок, ведущих к этому блоку. На нашем рисунке таких стрелок две. Обратите внимание, эти стрелки исходят из элементов 600 и 601, которые связаны строгим логическим «и» (это передается символом «эллипс», или, как его еще называют практики ТОС, «банан»). Поэтому мы избавимся от блока 602, если сумеем устранить хотя бы один из ведущих к нему блоков, потому что для появления события 602 должны одновременно соблюдаться условия 600 и 601. Вот что значит «строгое и».

В нашем примере блок 601 — неопровержимый факт. Так что нет смысла тратить время, ища опровержения его достоверности или необходимости для появления 602. Связь между блоками 600 и 602 установлена исходя из следующего допущения (приводим наиболее очевидное): «Клиенты уверены, что самый лучший и прямой способ уменьшить сроки выполнения проекта — это сократить время, заложенное в качестве резерва в буфере проекта». Это допущение, скорее всего, сделано правильно, если речь идет о заказчике (а иногда в роли внутреннего заказчика выступает руководство компании), который не понимает принципов ССРМ.

Как только выявлена исходная установка, можно подумать над тем, как разрушить ее. Два возможных способа — два прорывных решения — указаны на рис. 11.6. Любой из них сделает обнаруженное предположение неактуальным, тем самым искоренив возможность появления НЯ данной негативной ветви. Какой из способов предпочесть — выбирать вам.

Порядок действий при создании НВ следующий:

1. Определите потенциальное НЯ, появления которого вы опасаетесь.

2. Определите, какое из планируемых вами мероприятий-прорывов вызывает это НЯ.

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

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

5. Найдите точку, в которой цепь событий приобретает негативный характер.

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

7. Выработайте прорывные решения, которые нейтрализуют эти установки и предотвратят возникновение НЯ.

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

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

11.5. Дерево перехода

ДП — это последовательность событий, которые должны произойти, чтобы реализовалась идеальная модель системы из ДБР. Мы анализируем каждое прорывное решение из ДБР и проверяем, какие же препятствия нам предстоит преодолеть на пути к воплощению каждого решения. Затем прописываем все промежуточные цели по преодолению выявленных препятствий и соединяем их во временную последовательность с прорывными решениями. На рис. 11.7 представлено ДП первого прорыва для ССРМ. Препятствия показаны в шестиугольниках.

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

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

Дерево перехода, сетевой график проекта и иерархическая структура работ

Многие приспособились использовать ДП для построения графика работ методом «обратного прохождения». Просто вместо перечисления препятствий берем список ожидаемых результатов и продумываем, что требуется для получения каждого из них. При необходимости можно в диаграмму добавлять соответствующие операции. И снова задаем себе вопрос «А что еще нужно?» — и так до тех пор, пока не получим полный перечень всего необходимого для достижения результата. Затем анализируем препятствия, которые могут возникнуть, а меры по их преодолению включаем в список проектных работ. Верхние уровни диаграммы можно превратить в иерархическую структуру работ ИСР, главное, чтобы в ДП развертка шла именно от ожидаемых результатов. В названии операций в сетевой диаграмме проекта необходимо использовать как существительные, так и глаголы, поскольку операция — это некое действие по преобразованию материалов на входе в результат на выходе.

использования описан у Голдратта в романе «Дело не в везенье» [11]. Это очень сильный механизм, который можно использовать при запуске проекта для идентификации возможных препятствий и планирования действий по их преодолению.

11.6. План преобразований

ППР — это последовательный план мероприятий по достижению результатов, обозначенных в ДП. В ППР представлена логика и четкие инструкции действий. Эту диаграмму можно использовать для оценки степени достижения запланированных результатов, но не качества работ. У плана преобразований очень широкий спектр применения в любых ситуациях, требующих достижения какого-то желаемого результата. Например, ППР можно использовать, чтобы заручиться согласием руководства с выводами, полученными в процессе логических рассуждений ТОС.

Рис. 11.8 — пример ППР для одного из прорывных решений по улучшению системы управления проектами. В данном ППР приводится план достижения промежуточной цели 1-1 из ДП на рис. 11.7. Одновременно можно строить ППР лишь для двух нижних уровней ДП. Описав, как добиться промежуточной цели одного уровня, необходимо строить отдельный ППР для целей следующего уровня ДП.

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

11.7. Системное управление несколькими проектами

11.7.1. ДОПОЛНИТЕЛЬНЫЕ ЭЛЕМЕНТЫ ДТР ДЛЯ СИСТЕМЫ ПРОЕКТОВ

В ДТР по системному управлению несколькими одновременными проектами необходимо добавить еще несколько НЯ:

• Руководство соглашается на нереальные сроки.

• Менеджеры проектов борются за ресурсы.

• Исполнителям приходится одновременно выполнять несколько работ из нескольких проектов.

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

• Исполнителей вынуждают работать сверхурочно без дополнительной оплаты.

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

11.7.2. ДОПОЛНЕНИЯ К ДБР

ПО СИСТЕМЕ ОДНОВРЕМЕННЫХ ПРОЕКТОВ

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

1. Определить ресурс-ограничение — «барабан» организации.

2. Определить приоритетность каждого проекта для создания графика «барабана».

3. Рассчитать даты начала и окончания проектов с использованием планов проектов и графика «барабана».

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

5. Добавить буфер ограничивающего ресурса перед каждой операцией, в которой задействован ресурс-ограничение.

11.7.3. ДОПОЛНЕНИЯ К ДП

ПО СИСТЕМЕ ОДНОВРЕМЕННЫХ ПРОЕКТОВ

В соответствии с обозначенными выше дополнительными прорывами из ДБР необходимо добавить следующие промежуточные цели в ДП:

1. Определен ресурс-«барабан».

2. Определен менеджер ресурса-«барабана».

3. Обозначен исходный приоритет каждого проекта.

4. Руководство утверждает сроки нового проекта только после того, как определен его приоритет по отношению к уже идущим проектам, разработан план и определена дата запуска, зависящая от доступности ресурса-«барабана» (то есть проект вписан в «конвейер»).

11.8. Перспективные направления применения ТОС

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

В главе 2 мы рассматривали теории, которые предлагают методы непрерывного совершенствования вашей системы управления проектами и всей организации. Пять направляющих шагов ТОС — одна из стратегий непрерывного совершенствования системы. Можно довольно широко трактовать понятие «система», следовательно, обширной будет и сфера применения этой стратегии. Предлагаю следующие области для дальнейшего улучшения:

• Применить принципы ТОС ко всем остальным положениям РМВОК. В этой главе мы изложили ряд идей, однако возможно более глубокое изучение вопроса. Исходно при выработке метода ССРМ подход РМВОК не учитывался. Можно заняться такими разделами, как управление человеческими ресурсами или качеством проекта. К ним в полной мере применим метод ТОС: выявить ключевой конфликт и создать план эффективного внедрения решения, снимающего данный конфликт.

• Расширить ТОС на сферы, с которыми она поверхностно пересекается: теория поведения, психология, групповая динамика, творческое мышление. Так, можно приложить ТОС к идеям Де Боно [12] и ТРИЗ (теории решения изобретательских задач), а также распространить на основы мышления — архетипы, разрушить сами образы ограничений, лежащие на пути развития, согласно ТОС.

• Повысить эффективность использования практик РМВОК. Многие сталкиваются сейчас с трудностями в создании ИСР или сетевой диаграммы проекта.

• Более глубоко изучить процессы, связанные с психологией и поведением человека. На данном этапе ТОС, РМВОК, ОРМ3 не особенно сфокусированы на этих вопросах, хотя теория ограничений и предлагает мощное средство решения конфликтов — диаграмму «грозовая туча». В шести сигмах, похоже, этот аспект глубинных знаний, обозначенный Демингом, тоже обойден стороной.

• Продолжить движение в направлении использования в управлении проектами положений бережливого производства и гибких методологий. В ССРМ в некоторой степени использованы идеи из этих подходов, но можно копнуть гораздо глубже. Особенный интерес представляет положение об устранении потерь в бережливом производстве. А упор гибких методологий на создание полноценного продукта за короткий промежуток времени можно применить не только к проектам по разработке программного обеспечения.

Каждый день на свет появляются новые теории. Может, и у вас в голове зреют какие-нибудь свежие идеи. Часть новых теорий окажутся развитием старых (как шесть сигм продолжили начатое в TQM), часть отразят абсолютно инновационные подходы.

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

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

11.9. Итоги

Метод логических рассуждений помогает вам совершенствовать систему. Как было показано ранее, инструменты ТОС можно использовать и в качестве самостоятельных средств для решения отдельных вопросов. Диаграмма разрешения конфликтов работает на широком спектре проблем — от принятия личных решений до снятия напряженности в международных отношениях. Вот ключевые аспекты применения инструментов ТОС в управлении проектами:

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

• Ключевой конфликт связан с тем, решается ли в системе (и как именно) проблема неопределенности путем добавления запаса в буфер.

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

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

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

• Ограничением системы проектов является ресурс, общий для всех проектов системы (ресурс-«барабан»).

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

• Оценка эффективности системы проектов должна быть подстроена под ограничение системы. Не забывайте: запасы мощности должны быть не только у «барабана», но и у всех ресурсов.

Данный текст является ознакомительным фрагментом.