Понятие «система» в рамках ТРИЗ Часть 3

Понятие «система» в рамках ТРИЗ

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

Часть 1

Часть 2

Часть 3

 

Лен Каплан

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

Решение проблемы

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

Для генерирования идей по изменению компонентов («ресурсов») можно использовать Приемы (см., например, софтвер Guided Brainstorming).  Почему не «оригинальные» 40 Приемов?  Потому что Приемы в вышеуказанном софтвере специально реорганизованы и переписаны для работы с «ресурсами».

Для генерирования идей по изменению свойств и взаимодействий между компонентами можно использовать, например, правила «вепольного анализа» (см., например, книгу Iouri Belski, Improve Your Thinking).

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

Стандартизация процесса решения проблемы

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

Стандартизация модели «системы»

Попытки стандартизации модели «системы» предпринимались неоднократно.

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

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

Попытки построить такой предварительный процесс, предпринятые при разработке софтвера TechOptimizer компании Invention Machine Corp. (современное название софтвера – GoldFire), привели к созданию «функциональной» модели, представляющей собой конгломерат множества вепольных моделей. В Кишиневской школе ТРИЗ подобные модели получили презрительную кличку «вепольная модель трактора» - по причине своей громоздкости, нечитаемости и, с нашей точки зрения, полной бесполезности при решении проблем…

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

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

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

Еще большие сложности встречаются в проблемах, которые вовлекают не только «физические», но и другие взаимодействия.  Попробуйте, например описать, как производимый «технической системой» шум мешает соседям спать, и они жалуются на шум.  Кстати, куда отнести «шум»?  Это не объект, но и не «непосредственное физическое действие».  Создатели софтвера рекомендуют отнести «шум» к... «надсистеме» (???).  Оказывается, в прокрустово ложе системы моделирования с жесткими правилами не умещается все разнообразие проблемных ситуаций – и приходится стыдливо создавать эдакий «отстойник» для того, что «не вписывается» в эти правила... Остается еще невыясненным вопрос, почему этому «отстойнику» дали столь неудачное имя...

Но главная проблема этого предварительного аналитического процесса заключается в том, что совершенно непонятно, что же мы моделируем.  «Функционирование системы»?  А где границы этой системы?  Расширять эту «расплывчатую субстанцию» можно до бесконечности (что и делают многие сторонники «систем», доходя до межгалактических взаимодействий), но анализу проблемы как таковой подобная «безграничность» не помогает – скорее, мешает.  А «насильственно» заузить эти границы – есть риск не учесть именно те взаимодействия («функции»), которые и важны для решения проблемы...

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

Наиболее стандартизированным выглядит процесс решения проблемы, описанный в АРИЗ.  Однако и этот процесс начинается «с середины» - с выявления конфликта, возникшего... ну да, «в системе».  И опять – как и в предыдущем случае – дальнейший успех использования этой стандартной процедуры базируется на шатком фундаменте: «угадал – не угадал».  Попытки компенсировать этот недостаток АРИЗ предпринимались неоднократно: и «нулевая часть» АРИЗ-85-В, разработанная Б.Л. Злотиным, и АВИЗ-2000 (Алгоритм Выявления Изобретательской Задачи), созданный Г.И. Ивановым, и многие другие...  Здесь до стандартизации, увы, пока еще далеко.  И одна из причин этого плачевного состояния – в том, что мы продолжаем заниматься «анализом системы»...

Стандартизация модели «ситуации»

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

В этой модели очень легко выделить стандартные структурные элементы:

  1. Желаемый результат и нежелательное последствие
  2. События, влияющие на получение желаемого результата или нежелательного последствия
  3. События, не влияющие на получение ни желаемого результата, ни нежелательного последствия
  4. События, влияющие на получение и желаемого результата, и нежелательного последствия
  5. Желательные связи между событиями
  6. Нежелательные связи между событиями
  7. Отсутствующие связи между событиями
  8. Восприятие происходящих событий

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

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

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

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

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

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

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

Работая с желательной связью между событиями, мы можем ее усилить; можем ее изменить для улучшения желаемого результата; или заменить на более эффективную.

А нежелательную связь между событиями мы можем ослабить, «отключить», изменить для ослабления нежелательного последствия, либо заменить на менее эффективную.

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

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

Такая стандартизация позволяет организовать стандартный процесс решения проблем.  Такой стандартный процесс поддерживается, например, софтверами Innovation WorkBench (компании Ideation International Inc.) и GIToolkit (компании Pretium Consulting LLC).

Возможна ли дальнейшая стандартизация процесса?  Оказывается, да.  Ситуацию можно представить в упрощенном виде:

[Условие] -> [Ключевое событие] -> [Результат] -> [Цель]                                   .

                                                      -> [Последствие] -> [Дальнее последствие]

В этой упрощенной стандартной модели ситуации участвуют только 6 событий. Здесь не учитываются события, не связанные с желаемым результатом и нежелательным последствием.   Но зато участвуют три «новых» события: Условие, Цель и Дальнее последствие, обычно выходящие за пределы рассматриваемой ситуации.  Для этих трех «новых» компонент ситуации можно сформулировать следующие задачи:

  1. Условие:
    1. Изменить условие так, чтобы нежелательное последствие не могло бы произойти
    2. Заменить условие на другое, при котором нежелательное последствие не может произойти
    3. Заменить условие на другое, при котором нежелательное последствие станет незначительным
    4. Заменить условие на другое, при котором нежелательное последствие принесет пользу
  2. Цель
    1. Найти другие способы достижения той же цели, не приводящие к нежелательному последствию
    2. Найти другие цели, которые можно достичь заодно с этой целью
    3. Найти другие цели, достижение которых может компенсировать недостижение или неполное достижение этой цели
  3. Дальнее последствие
    1. Устранить дальнее последствие, даже если не удастся устранить или ослабить нежелательное последствие
    2. Ослабить дальнее последствие до допустимого уровня
    3. Обратить дальнее последствие в пользу
    4. Изменить ситуацию так, чтобы это дальнее последствие не возникало

Пошаговое решение проблемы

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

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

Звучит весьма заманчиво, не так ли?  Однако легче это сказать, чем сделать.  С первого взгляда непонятно, где границы между такими «уровнями», какой объем анализа нужен на каждом уровне и т.д.  Попытки разделить процесс решения на такие уровни по шагам привычных ТРИЗовских алгоритмов (например, АРИЗ-85-В – см. работы Н. Шпаковского) выглядят привлекательно, но недостаточно обоснованно.

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

  1. Вначале решаем  «проблему как она дана», безо всякого предварительного анализа: устраняем нежелательное последствие или улучшаем желаемый результат
  2. Если не удастся решить «проблему как она дана», рассматриваем другие задачи, связанные с этой проблемой; при этом нужно проанализировать разнообразные аспекты «проблемы как она дана»
  3. Если решить эти задачи не удастся, нужно пересмотреть условия, при которых ситуация происходит; для этого нужно проанализировать условия, при которых осуществляется ситуация
  4. Если не удастся решить задачу об изменении условий, нужно решить «противоположную» задачу:
    1. Если решалась задача об устранении нежелательного последствия, нужно решить задачу о лучшем достижении желаемого результата; для этого нужно проанализировать желаемый результат
    2. Если решалась задача об улучшении желаемого результата, нужно решить задачу об устранении нежелательного последствия, которое мешает реализовать известный способ улучшения желаемого результата; для этого нужно проанализировать нежелательное последствие применения известного способа
  5. Если не удастся решить «противоположную» задачу, нужно решить задачу «сделать проблемную ситуацию допустимой»:
    1. Если решалась задача об устранении нежелательного последствия, нужно решить задачу о том, как сделать допустимыми дальние последствия; для этого нужно проанализировать дальние последствия
    2. Если решалась задача об улучшении желаемого результата, нужно решить задачу, как сделать допустимым имеющийся, неулучшенный результат; для этого нужно проанализировать цели, ради достижения которых предпринимается попытка улучшить желаемый результат
  6. Если не удастся решить задачу «допустимой» ситуации, нужно решить противоречие, связанное с тем, что некоторое событие приводит и к желательному результату, и к нежелательному последствию; для этого нужно проанализировать ситуацию и выявить это противоречие
  7. Если не удастся разрешить противоречие, нужно решить задачу на изменение нежелательных связей между событиями; для этого нужно более подробно проанализировать связи между событиями, составляющими проблемную ситуацию.  Решать придется следующие задачи:
    1. Ослабление или разрушение нежелательных связей
    2. Повышение эффективности желаемых связей
    3. Установление отсутствующих связей
  8. Если не удастся решить задачу на изменение связей между событиями, нужно решить задачу поиска альтернативных способов достижения цели; для этого нужно более подробно проанализировать цель, ради которой решается проблема
  9. Если не удастся найти альтернативные способы достижения цели, ради которой решается проблема, нужно решить задачу поиска альтернативных способов достижения дальних целей; для этого нужно проанализировать цепочку целей, от цели, ради которой решается проблема, до максимально возможных дальних целей
  10. Если не удастся найти альтернативные способы достижения дальних целей, нужно решить задачу изменения восприятия ситуации; для этого нужно проанализировать каналы восприятия событий, причины возможного искажения и неадекватности восприятия и т.п.
  11. Если не удастся решить и эту задачу, значит, поставленная проблема в данной ситуации, при данных условиях и критериях отбора объективно неразрешима.

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

Проверка предложенного алгоритма приведена в Приложении 1 (будет опубликовано в 6-й части предлагаемого материала).

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

 

Алфавитный указатель: 

Рубрики: 

Комментарии

Re: Понятие «система» в рамках ТРИЗ Часть 3

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

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

- Сколько исходных ситуаций было проанализировано для выработки предлагаемого алгоритма? 

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

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

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

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

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

Re: Понятие «система» в рамках ТРИЗ Часть 3

Изображение пользователя Леонид Каплан.

Александр, 

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

Главная идея этого подхода заключается в том, что на каждом этапе мы осуществляем МИНИМАЛЬНО НЕОБХОДИМЫЙ анализ проблемной ситуации - достаточный только для того, чтобы использовать соответствующие решательные инструменты. Если на этом этапе проблему решить не удалось, переходим на следующий этап, начинающийся с МИНИМАЛЬНО НЕОБХОДИМОГО анализа ("углубление" нашего понимания проблемной ситуации), опять достаточного только для применения соответствующих решательных инструментов.

Эта технология работы отличается от принятой в ТРИЗ "однозаходного" подхода, когда мы ОДИН раз осуществляем анализ проблемной ситуации на максимальную глубину, а потом решаем проблему. При таком однозаходном подходе мы тратим уйму сил и времени на анализ проблемной ситуации, а потом не используем от 50 до 90% его результатов при решении. Предлагаемая технология позволяет решить проблему, выполняя только ту аналитическую работу, которая реально необходима.

Если это "нестыковка", то только с общепринятой однозаходной технологией. Логика здесь, действительно, ДРУГАЯ...

Обращу внимание на то, что в моей практике примерно 70% проблем были решены именно в той постановке, "как она дана задачедателем".

Насчет "безо всякого предварительного анализа" я, конечно, погорячился... Предварительный анализ присутствует в виде "составления flowchart'а проблемной ситуации, как она рассказана задачедателем". Действительно, для меня это действие стало давно настолько естественным, что я предпочитаю именно такую запись рассказа о проблеме - вместо привычной текстовой записи. Можно, конечно, и это назвать "анализом"... так что здесь Вы правы.

Объем статьи (который я и так умудрился превысить многократно - потому она и публикуется в несколько заходов) не позволил мне подробно остановиться на этой технологии. Возможно, в другой раз я опишу "многозаходный" подход подробнее. Хотя... до меня это неплохо сделал Николай Шпаковский - например, здесь: http://www.gnrtr.ru/Generator.html?pi=301&cp=3 . Я не совсем согласен с тем общим алгоритмом многозаходной технологии, который использует Николай - но с предложенным им принципом многозаходности, с принципом "необходимого минимума аналитической работы" вполне согласен.  

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

Subscribe to Comments for "Понятие «система» в рамках ТРИЗ Часть 3"