1. Найдите все истинные причины (утверждения, к которым не ведет ни одна стрелка).
2. Найдите истинную причину, связанную с 70 и более процентами НЯ. Для этого посчитайте, сколько НЯ влечет за собой каждая истинная причина, и сопоставьте это число с общим количеством элементов, установленным на этапе 7. Пометьте найденную ключевую проблему и подтвердите правильность своей находки, озвучив все ее логические связи с НЯ следующим образом:
Если устранить (ключевую проблему), то исчезнет и (следствие).
А если исчезнет это следствие, то не будет и следующего результата.
А когда исчезнет это явление… исчезнет и НЯ.
Примечание: в ходе проверки не забывайте, что эллипс обозначает логическое «И». Если ваша диаграмма построена верно, с соблюдением всех КПЛП, то достаточно снять одну причину из нескольких, объединенных эллипсом, чтобы исчезло результирующее событие и, следовательно, разрушилась связь, ведущая к НЯ. Поэтому ТОС и проповедует минималистический подход к решению проблем, ведь, имея полную картину недостатков системы, можно преодолеть трудности при минимальных затратах времени и сил. Выстраивая цепочки причин и следствий от НЯ к ключевой проблеме, мы на самом деле ищем ограничение системы – проблему, решение которой максимально положительно скажется на всей системе.
3. Если среди истинных причин никак не удается установить ключевую проблему, переходите к этапу 9. Если же ключевая проблема найдена, сразу приступайте к этапу 10.
9. Ищите V-образные структуры или пропущенные связи
Если ключевая проблема до сих пор не установлена, придется достраивать диаграмму дальше вниз, к основанию, даже если уже не осталось необъединенных НЯ. На данном этапе, скорее всего, вы обнаружите несколько ветвей, которые оканчиваются истинными причинами (рис. 3.38).
1. Изучите все истинные причины и сопоставьте их друг с другом.
2. Попытайтесь найти две причины, каким-либо образом связанные между собой (подобно тому, как мы делали на этапе 4). Обнаружив их, продолжайте построение от каждой ветви вниз, как на этапе 6, пока не дойдете до причины, от которой по законам логики (т. е. следуя КПЛП) начинаются обе цепочки. Это будет недостающая V-образная структура. Если в основании этой структуры лежит причина, вызывающая 70 % НЯ, значит, обнаружена ключевая проблема (ограничение).
3. Можно пойти другим путем: сопоставлять утверждения всех ветвей на одном уровне (уровне истинных причин), чтобы выявить пропущенные горизонтальные связи. При этом могут быть найдены пропущенные промежуточные утверждения. Нанесите на диаграмму найденные связи, проверьте их по КПЛП и пересмотрите истинные причины: может, теперь одна из них связана с 70 % НЯ и, таким образом, является ключевой проблемой. В конце концов вы обязательно доберетесь до ключевой проблемы, действуя согласно пунктам 2 и 3.
10. Выберите проблемы для дальнейшей работы
Казалось бы, трудностей с выбором быть не должно: занимаемся ключевой проблемой. Но давайте-ка вернемся на первый этап нашей процедуры. Где границы зоны вашего контроля и сферы влияния? Только с учетом ответов на эти вопросы можно выбирать, на решение какой проблемы направить усилия (рис. 3.39).
1. На готовом дереве текущей реальности очертите границы зоны вашего контроля, включая в нее те элементы, которые вы сами можете преобразовать. По возможности замкните линию, при этом вовсе не обязательно должен получиться круг. При необходимости обозначьте несколько отдельных зон контроля. Используйте определенный цвет, рисуя границы зон контроля.
2. Повторите все то же для сферы влияния, используя другой цвет. Ориентируйтесь не только на существующую ситуацию, но и на предположение о том, как далеко могла бы простираться сфера вашего влияния. Влияние может быть и опосредованным, например, сами вы не можете повлиять на законодательство, но можете убедить законодателей изменить его. Итак, чем шире охват, тем лучше, даже если вы пока и не представляете, как именно могли бы повлиять на то или иное событие.
3. Определите, где находится ключевая проблема по отношению к зоне контроля и сфере влияния. Если она располагается в рамках сферы вашего влияния, можете приступать к ее решению. Если же проблема – за границами контроля и влияния, выберите из истинных причин две или более, которые, по вашему мнению, связаны с большинством негативных явлений, и сосредоточьте все усилия на их преодолении.
Примечание: предположим, нам удалось отыскать одну ключевую проблему, связанную с 70 % нежелательных явлений, но как же быть с оставшимися 30 %? Вспомним о пяти направляющих шагах ТОС: наша цель – обнаружить самое слабое звено цепи, ограничение, т. е. ключевую проблему, даже если она и не вызывает абсолютно все негативные события в нашей ситуации. В процессе непрерывного совершенствования системы вы доберетесь и до остальных 30 %. Но начинать лучше с одной ключевой проблемы. В ходе ее решения система может значительно измениться, перестроиться, и в результате те 30 % могут просто перестать быть НЯ. А если не перестанут, имеет смысл построить еще одно ДТР для нового состояния системы из этих оставшихся 30 % НЯ. Однако в этот раз вы можете выявить иные истинные причины. Таким образом мы реализуем пятый из направляющих шагов: когда ограничение устранено, начинайте все сначала и ищите следующее слабое звено.
Радуйтесь, что проблемы существуют. Ведь если бы их не было, кто угодно мог бы работать на вашем месте.
Неизвестный источник
Ключевые проблемы и крайне нежелательные явления
Как быть, если вы прошли всю процедуру, нашли ключевую проблему, но она никак не связана с нежелательным явлением, которое очень вас беспокоит? НЯ не равнозначны по важности: одни менее нежелательны, другие крайне нежелательны – весь вопрос в том, кто оценивает. Модель построения ДТР дает количественный критерий поиска проблемы (связь с 70 % НЯ), но не качественный. Здравый же смысл подсказывает, что нельзя оставить без внимания серьезное НЯ, даже если оно в эти 70 % не входит. В этом случае задаем себе следующие вопросы.
● Повлечет ли решение ключевой проблемы максимизацию производительности по денежному потоку?
● Если НЯ, которое волнует нас больше всего, не входит в 70 % явлений, вызванных ключевой проблемой, а мы все равно будем над ним работать, не будет ли это субоптимизацией, не пожертвуем ли мы интересами всей системы, только чтобы улучшить какую-то одну ее часть?
