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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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