«Вечная проблема»: а нужно ли ее решать?

Часть 2

смотри Часть 1

Лен Каплан

Южная Корея, декабрь 2011 – январь 2014

Определения «трудноопределимых» понятий (Продолжение)

Теперь можно обсудить и такое «скользкое» в «система»-центрической ТРИЗ понятие как «критерии решения проблемы».

Критериями решения проблемы являются:

• Степень улучшения желательного результата; эта степень может быть ограничена как «снизу» (улучшить показатель не менее чем на Х%), так и «сверху» (улучшить показатель, но не более чем на Ы%)
• Степень подавления нежелательных результатов (они не должны превышать «порога допустимости»). В частности, такими «нежелательными результатами» являются затраты как на осуществление решения, т.е. на изменение ситуации, так и на его использование, т.е. на использование измененной ситуации.  Под «затратами» подразумеваются затраты ресурсов, усилий, времени. При этом имеются в виду не только «прямые затраты». Скорее, это весь комплекс затрат, включая решение новых проблем, вызванных реализацией предложенного решения – весьма близко к понятию «Total Cost of Ownership»
• Недопустимость некоторых нежелательных результатов (они не должны возникать ни в коем случае). Примером является, например, потенциальный вред здоровью и жизни людей, пользующихся новым товаром.

Критерии решения проблемы, в основном, должны быть заданы до начала решения проблемы.  Иначе процесс решения превращается в «движущуюся мишень» из-за естественного стремления заказчика получить как можно больше «за те же деньги».  Однако некоторые критерии задаются с точки зрения «известного, но неправильного» решения, и потому после нахождения решения проблемы должны быть изменены.

Из приведенного определения трех типов критериев становится ясно, что несоответствие предложенного решения проблемы какому-либо из этих критериев является постановкой новой («вторичной») задачи для решения, а не поводом для отбрасывания решения как неудачного.

А теперь, похоже, пришло время посмотреть на еще более трудноопределимое и труднопонимаемое в ТРИЗ понятие: «надсистема».  Может, с точки зрения «ситуации» как центрального понятия с ним тоже будет легче разобраться?

Я впервые всерьез столкнулся с тем, насколько трудно назвать надсистему для конкретной системы, в 1989 году, при выполнении проекта «Прогноз развития подъемного крана».  Методика прогнозирования предполагала на одном из шагов определить надсистему прогнозируемой системы.  И тут – да еще и в присутствии моих учителей, А. Зусман и Б. Злотина – я впал в ступор.  Оказалось, что я не могу назвать надсистему для подъемного крана. Казалось бы – чего проще, назови «систему более высокого порядка», и все.  А что такое – «система более высокого порядка»?

Выход, в конце концов, был найден – как всегда, «методом гениальной догадки» (А как еще искать выход из безвыходного положения?).  Я нарисовал картинку, на которой подъемный кран «выполняет свою Главную Полезную Функцию», т.е. перемещает грузы на строительной площадке.  А затем дал название этой картинке: «строительная площадка».  Вот это и было имя надсистемы.  С тех пор пользуюсь этим эмпирическим правилом.

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

Коварный ложный след ожидает неопытного аналитика уже на первом этапе - этапе определения надсистемы. Слишком часто вместо надсистемы хочется назвать всего лишь обобщенное определение исходного объекта, а эта ошибка заводит в тупик, который ощущается неопытным аналитиком только на следующих шагах системного анализа. [Титов В.В., Системно-морфологический подход в технике, науке, социальной сфере. Методолог, http://www.metodolog.ru/00046/00046.html]

Замечу, что при всем при этом автор статьи рекомендует следующую последовательность работы:

Первый шаг системного анализа - представление изучаемого объекта в виде системы. Для искусственной системы этот шаг сводится к выявлению и словесному определению следующих понятий:

1. надсистема, в которую входит объект,
2. главная полезная функция объекта,
3. перечень подсистем объекта,
4. структура системы.

Но затем дает рекомендацию, как проверить, правильно ли выбрана надсистема:

2) Проверьте, корректно ли звучит вопрос: "Какую функцию выполняет <исходный объект> в <надсистеме>?"

И вот тут начинается непонятное: так что же нужно определить раньше, надсистему или главную полезную функцию объекта?  Казалось бы, с «система»-центрической точки зрения, начинать нужно с надсистемы.  Но проверить правильность выбора надсистемы можно только после того, как определена ГПФ.  А ГПФ определяется с точки зрения надсистемы – потому что в другой надсистеме у системы другая ГПФ.  Каково?  Ну как тут не стать «философом»?  Так что же было раньше, курица или яйцо (точнее, надсистема или ГПФ)?

А теперь попробуем взглянуть на эту «проблему» с «ситуация»-центрической точки зрения.  Для этого введем грамматически некорректный термин: «надситуация».

Вводить, по аналогии с «система – надсистема – подсистема», термин «подситуация» мы не будем.  Для системы подсистема – это один из компонентов системы.  А компоненты ситуации мы уже определили – это события.

Теперь же попробуем определить «надситуацию»:

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

Вот и все.  Теперь можно определить и понятие «надсистема» - по аналогии с определением понятия «система»:

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

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

1. Ситуацию, в которой необходимо переместить тяжелый груз в пространстве
2. Ситуацию, в которой опрокидывание подъемного крана может привести к дальнейшим нежелательным последствиям
3. Ситуацию, являющуюся «пересечением» вышеуказанных двух ситуаций.

Все просто и понятно, не так ли?  И не нужно ни «большого опыта аналитической работы», ни «гениального озарения», чтобы выявить «надсистему»…

Какие инструменты нужны нам для работы?

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

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

1. Для решения проблемы необходимо в ходе анализа проблемной ситуации выявить события, компоненты и связи между ними, которые можно изменить для получения «беспроблемной» ситуации.  Для этого нам нужно построить модель (или, при необходимости, комплект моделей ситуации), содержащую все эти элементы и с достаточной степенью точности отражающую существенные реалии ситуации.
2. Для того, чтобы найти хотя бы одно решение проблемы, нам нужно найти возможные способы изменения изменяемых событий, компонентов и связей между ними, а затем объединить некоторые из них в решения.  Следовательно, нам нужен достаточно полный набор «подсказок»: как можно изменить событие, компонент или связь.
3. Найденное решение нужно привести в соответствие с заранее заданными критериями.  Для этого нужно не только уметь изменять события, компоненты и связи, но также уметь вводить новые события, компоненты и связи в условиях, когда вводить их по каким-то причинам нельзя.
4. После того, как найдено решение, нужно провести анализ новой, измененной ситуации.  В ходе этого анализа нужно выявить события, компоненты и связи между ними, которые изменятся вследствие проведения изменений в ситуации.  Далее нужно разобраться, какие из этих изменений являются желательными и нежелательными, и оценить степень этих изменений.  Здесь нам понадобится модель ситуации (или, при необходимости, комплект моделей), содержащая события, компоненты и связи между ними, позволяющая проследить «последующие» (производные) изменения в ситуации.
5. Следующий цикл решения проблемы должен выявить способы использования желательных изменений, а также способы предотвращения нежелательных изменений.  Для этого нам нужны подсказки двух типов: (а) как использовать новые возможности, и (б) как предотвратить нежелательные изменения.

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

С другой стороны, эти 5 шагов работы над проблемой позволяют, если удастся представить хотя бы 80% решаемых проблем в виде «типичной проблемной ситуации», создать простой и прозрачный процесс решения проблемы, обеспечивающий полноту охвата всех существенных факторов и полноту нахождения всех возможных решений.

Анализ проблемной ситуации

Процедура анализа проблемной ситуации

Итак, вернемся к вопросу, с которого мы начали: как анализировать проблемную ситуацию?

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

Следовательно, анализ проблемной ситуации следует начинать с анализа событий, их последовательности и их восприятия.  Для этого нужно построить «блок-схему» (flowchart) ситуации.  Желательно, чтобы на этой «блок-схеме» были приведены все существенные события, (а) приводящие к желательному результату, ради которого эта ситуация осуществляется, (б) приводящие к нежелательному недопустимому последствию, которое делает эту ситуацию проблемной, а также (в) обеспечивающие их восприятие.

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

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

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

Лирическое отступление: Почему «событие», а не «функция»?

Вопрос резонный – нечем крыть...

А. Галич, Легенда о табаке

Именно здесь возникает серьезный вопрос: а почему это автор предлагает использовать блок-схему, а не функциональную модель?  Ведь недаром Майлз утверждал, что функциональная модель – как раз по сравнению с блок-схемой – обладает очень высоким «креативным» потенциалом.  Не откатывается ли автор к более слабой модели, не «отбрасывает ли он ТРИЗ на 50 лет назад»?  Вопрос резонный, и на него придется отвечать.

Ответ будет состоять из трех частей:

1. Функциональная модель и блок-схема используют разные «языки описания».
   1. Блок-схема использует описания наблюдаемых и измеримых явлений, т.е. изменений состояний различных компонентов
   2. В то же время функциональная модель использует описания гипотез, объясняющих, почему эти явления происходят
2. Блок-схема и функциональная модель являются двумя комплементарными (взаимодополнительными) половинками одного и того же описания ситуации. Это описание использует события как результаты выполнения функций, а функции – как «объяснения», почему эти события произошли.  Поэтому эти два описания взаимозаменяемы и равноценны с точки зрения анализа ситуации.
3. Блок-схема и функциональная модель противоположны по своим достоинствам и недостаткам:
   1. Функциональная модель трудна в составлении, но затем существенно упрощает интеллектуальные действия по изменению мыслеобраза ситуации.
   2. Блок-схема проста в составлении, но затем существенно усложняет интеллектуальные действия по изменению мыслеобраза ситуации.

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

Рассмотрим эти положения подробнее.

Языки описания

Согласно определениям, сформулированным выше,

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

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

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

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

Комплементарность моделей

Теперь посмотрим на разные модели ситуации.  Начнем с так называемой «полной» модели.  Фрагмент «полной» модели ситуации может выглядеть так:

->[функция 1]->[событие 1]->[функция 2]->[событие 2]->

Для понимания ситуации, однако, достаточно только одного представителя каждой пары «функция-событие».  Следовательно, следующие фрагменты моделей ситуации воспринимаются точно так же, как и фрагмент приведенной выше «полной» модели:

->[функция 1]-> [функция 2]->

-> [событие 1]-> [событие 2]->

->[функция 1]-> [событие 2]->

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

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

Гибридизация моделей

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

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

Для разрешения этого противоречия, используем разделение противоречивых свойств во времени, и объединим эти две модели в один гибрид:

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

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

Итак, третий вывод из обсуждения вопроса «Какую модель нужно использовать для решения творческих проблем?»:

На стадии сбора информации и анализа нам нужно строить блок-схему ситуации, выбрать в ходе анализа «изменяемое событие», а на стадии генерирования идей нужно пользоваться функциями, которые, по нашему предположению, создают это «изменяемое событие».

Процедура анализа проблемной ситуации (Продолжение)

Теперь можно продолжить рассмотрение процедуры анализа проблемной ситуации.

Мы уже установили, что анализ проблемной ситуации следует начинать с анализа событий и их последовательности.  Для этого нужно построить «блок-схему» (flowchart) ситуации.  Для проверки блок-схемы на полноту, можно составить «компонентную модель» ситуации.

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

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

Соответственно, формулирование задачи и дальнейший анализ, в зависимости от того, связано или не связано выбираемое событие с интересующим нас результатом или последствием, осуществляем  следующим образом:

1. Устанавливаем способ достижения требуемого изменения результата или последствия:
   1. Устанавливаем, насколько нужно изменить это событие, чтобы только за счет этого изменения получить требуемое изменение результата или последствия.
   2. Устанавливаем, какой должна быть связь между этим событием и результатом или последствием, чтобы только за счет этой связи, без изменений события, можно было бы получить требуемое изменение результата или последствия.
2. Формулируем задачу:
   1. Формулируем задачу на поиск способов добиться такого изменения события.
   2. Если «изменяемое событие» связано цепочкой связей с интересующим нас результатом или последствием ситуации, формулируем задачу на поиск способов либо преобразовать существующую связь в нужную, либо установить нужную связь взамен существующей.
   3. Если же «изменяемое событие» не связано с интересующим нас результатом или последствием ситуации, формулируем задачу на поиск способов установить нужную связь.
3. Строим гипотезу:
   1. О причинах, по которым это событие осуществляется.
   2. О том, каким образом это событие должно повлиять на интересующий нас результат или последствие.
4. Строим функциональную модель:
   1. Осуществления этого события.
   2. Осуществления нужного влияния.
5. Строим модель свойства:
   1. Для объекта «изменяемого события» строим модель свойства, обеспечивающего нужное изменение.
   2. Для объекта интересующего нас результата или последствия строим модель свойства, обеспечивающего нужное изменение.

Если шаги 1-4 вполне понятны любому ТРИЗ специалисту, использующему функциональный анализ, то шаг 5 – построение модели свойства – нуждается в дополнительных пояснениях.

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

Свойство компонента – это гипотеза о причинах способности данного компонента изменяться (или не изменяться) в ходе определенных событий, а также устанавливать (или не устанавливать) связи с другими компонентами.

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

[Начальное состояние]->[Свойство]->[Конечное состояние]

Эта модель по своей структуре напоминает вепольную модель (точно так же как и модели функций как связь между условием и результатом / последствием).

Итак, в результате анализа мы получаем 4 модели:

1. Блок-схема ситуации (событийная модель)
2. Функциональная модель «изменяемого события»
3. Функциональная модель связи между «изменяемым событием» и интересующим нас результатом или последствием ситуации
4. Модель свойства компонента

Этот комплект моделей позволяет нам

1. Выяснить механизм осуществления ситуации и механизм возникновения проблемы
2. Выделить те элементы ситуации (события и связи между ними), изменение которых может привести к желаемому изменению результатов и последствий ситуации
3. Выявить компоненты, их свойства и взаимодействия между ними, изменение которых позволит осуществить намеченные изменения ситуации.

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

(Продолжение ).