Диагностика проблемной ситуации

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

Здравствуйте, уважаемые методологи.

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

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

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

В алгоритме МОИТТ-82 формулирование технического противоречия происходит на втором шаге. На первом же шаге производится описание задачи:

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

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

В книге Орлова М.А. Основы классической ТРИЗ. – 2-ое издание. – М.: СОЛОН-ПРЕСС, 2006. также есть раздел, посвященный анализу проблемной ситуации. Автор называет его алгоритмом диагностики проблемной ситуации. Данный алгоритм включает в себя 7 шагов (далее идут цитаты из книги):

  1. Общая диагностика системы с целью определения компонентов системы, подлежащих усовершенствованию или устранению – на основании функционально-стоимостного анализа, либо на основании сопоставления уровня развития технической системы и ее компонентов с законами и линиями развития систем, либо на основании иных способов оценки эффективности компонентов.
  2. Строится системно-функциональная модель конфликта.
  3. Предварительное определение множества технических или физических противоречий и множества соответствующих оперативных зон.
  4. Предварительное определение ресурсов в выбранных оперативных зонах, в системе и в системном окружении.
  5. Выбор Мета-стратегии решения проблемы для каждой оперативной зоны.
  6. Ранжирование оперативных зон по сложности содержащихся в них проблем и установлении порядка решения задачи.
  7. Краткая формулировка по одной конкретной задаче для каждой оперативной зоны и переход к этапу редукции.

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

В итоге мои вопросы следующие:

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

Заранее спасибо.

Форумы: 

Re: Диагностика проблемной ситуации

С другой ветки http://www.metodolog.ru/node/18

Александр Кудрявцев wrote:
Коллеги, я уже много раз говорил на сайте и здесь, на форуме. И повторю это сейчас: в классической ТРИЗ нет средств для первоначального толчка, для проявления вектора, по которому пойдет движение. Клиент должен задать систему, рассказать, что в ней плохо и спросить: "как быть".
.
Могу немного рассказать, как поступаю в подобной ситуации.
Для меня клиент - это мой начальник, который и ставит задачу. Но поскольку он большой начальник, то в технические тонкости не вникает. У него проблемы совсем другого уровня. Он говорит так: "Ты специалист, ты и решай, где там противоречия в нашей продукции. Мне надо, чтобы налаженное дело работало, и продукция бы защищалась патентом". Начальнику не нужны никакие сильные или слабые решения, ему патент нужен, защищающий, по возможности, минимальные изменения продукции относительно существующей, а лучше, и вовсе без них.
Поэтому ориентируюсь на конечный результат - получение патента для защиты продукции. Делаю патентный поиск аналогов - сам, конечно (никогда не заказываю со стороны), по нашим патентам и иностранным, относящимся к нашей продукции. А в патентах и смотрю, с какими проблемами, недостатками сталкиваются другие изобретатели, и как они их разрешают. Выбираю прототип, наиболее похожий на нашу продукцию. А он уж описан по патентным правилам, и картинка есть. Прямо бери первый шаг АРИЗа и описывай, из чего состоит система. А какой там главный недостаток - так это есть в описаниях аналогов. Причем недостатки всегда одни и те же: низкая производительность и надежность, плохая точность, дорогая стоимость. Ну, а дальше понеслось по АРИЗу и другим средствам ТРИЗ, вплоть до написания заявки на изобретение или полезную модель. За такую работу уже платят деньги.
Можете попробовать. Желаю успеха.
ABB

Re: Диагностика проблемной ситуации

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

Это хороший, нормальный путь, в ситуации, когда можно определить, работает описанная в патенет система, или нет.
Более того, именно на основе этого подхода и создавались первые приемы устранения пртиворечий.
Раньше, до 73 года, в патентном описании было все очень четко - известна система, состоящая из ..., у нее есть следующий недостаок. Известна другая система, состоящая из..., у нее этого недостатка нет, но есть другой. Иногда практически полная формулировка ТП получалась.
Эта коллизия хорошо описана у Геннадия Паренчика в работе http://www.metodolog.ru/00119/00119.html и http://www.metodolog.ru/00216/00216.html

Re: Диагностика проблемной ситуации

AlexeyF, приветствую!
Прежде чем обсуждать поставленные вопросы, хотелось бы уточнить, где Вы увидели в приведенном тексте М. Орлова выход на одно противоречие из множества?

Quote:
7. Краткая формулировка по одной конкретной задаче для каждой оперативной зоны и переход к этапу редукции.

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

Re: Диагностика проблемной ситуации

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

Александр Кудрявцев wrote:

Прежде чем обсуждать поставленные вопросы, хотелось бы уточнить, где Вы увидели в приведенном тексте М. Орлова выход на одно противоречие из множества?

Вы совершенно правы, у Орлова ничего не говорится о выходе на одно противоречие из множества. Но в то же время там говорится о ранжировании задач. А ранжирование задач подразумевает выявление приоритетной (если можно так выразиться) задачи. Именно выделение одной приоритетной задачи и заинтересовало меня.

Re: Диагностика проблемной ситуации

Александр Кудрявцев wrote:
Предлагаю обсудить механизмы обеспечения ранжирования задач, по М. Орлову.

Александр Владимирович, а Вы действительно считаете, что у Орлова есть что обсуждать? Даже при переводе на "нормальный русский тризовский"? А почему бы АВИЗ 2000 не рассмотреть, уж все лучше, чем Орловские заумствования и мозговихляния...

Бороться и искать,
Найти и перепрятать!

Re: Диагностика проблемной ситуации

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

Re: Диагностика проблемной ситуации

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

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

Почти всегда это получается при выходе на качественно новый уровень по линиям развития ТС. Например. Клубок противоречий:

Моторов должно быть мало чтобы было дешево
Моторов должно быть много чтобы повысить силу и надежность
Моторы должны быть быстрыми для производительности станка
Моторы должны быть медленными чтобы повысить силу
Моторы должны потреблять много тока чтобы повысить мощность
Моторы должны потреблять мало тока чтобы не сгореть
Моторы должны быть другие потому что эти полны недостатков
Моторы должны быть эти же потому что они уже закуплены
Моторы должны делать много шагов на 1 мм для силы и точности
Моторы должны делать мало шагов на 1 мм для скорости
Моторы должны управляться 25 р. микросхемами для экономии
Моторы должны управляться 150 р. микросхемами для мощности

Решен свертыванием надсистемы:

Вместо 4 моторов и 4 микросхем по 25 р. использовать два мотора, соединенных последовательно и управляемых 1-й микросхемой за 150 р. Получается экономия почти в три раза, мощность (т.е. сила*скорость) возрастает примерно в два раза, моторы не горят благодаря автоматической регулировке в дорогой микросхеме, точность не ухудшается.

И таких примеров много, даже за пределами техники.
Типа: заколебали пещерные львы, саблезубые тигры, волки, гиены, комары, холод, темнота => разожгли костер => и все эти проблемы стали менее беспокоить.

Re: Диагностика проблемной ситуации

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

Здравствуйте, MNTC, спасибо, что присоединились к нашей дискуссии.

MNTC wrote:

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

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

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

Если честно, в примере, который Вы привели, я не увидел ни одного решения указанных противоречий.

Далее

MNTC wrote:

Решен свертыванием надсистемы:

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

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

Начнем с первого ТП. Здесь может быть два ИКР.
ИКР1.1: Моторов мало и они дешевые, и при этом мы имеем большую силу и надежность.
ИКР1.2: Моторов много и они очень дешевые.

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

Также при достижении ИКР1.1 теряет смысл третье ТП, т.к. в этом случае у нас уже есть большая сила и повышать мощность не надо.

Четвертое ТП – это вообще не ТП, а административное противоречие. Поэтому здесь его пока исключим из рассмотрения (в конце я к этому противоречию еще вернусь).

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

Таким образом, достижение ИКР1.1 позволяет «одним махом» решить остальные ТП.

А теперь давайте возьмем второе ТП. ИКР здесь будет следующий:
ИКР2: Моторы быстрые и при этом имеют большую силу.

Согласитесь, при достижении ИКР2 мы уже не разрешим первое ТП. Быстрые моторы с большой силой естественно будут дорогими. Следовательно, в первую очередь необходимо решать первое ТП, а не второе.

Еще отмечу, что решение уменьшать количество моторов совпадает с вашим решением:

MNTC wrote:

Вместо 4 моторов и 4 микросхем по 25 р. использовать два мотора

И, наконец

MNTC wrote:

Моторы должны быть другие потому что эти полны недостатков
Моторы должны быть эти же потому что они уже закуплены

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

С уважением, Алексей.

Re: Диагностика проблемной ситуации

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

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

  1. выявить в задаче несколько ТП;
  2. для каждого ТП сформулировать ИКР;
  3. по очереди для каждого ИКР посмотреть, устранятся ли остальные ТП, если достичь этот ИКР;
  4. ИКР, который «одним махом» устраняет наибольшее количество ТП, получает наибольший приоритет.

Re: Диагностика проблемной ситуации

Приветствую всех!
Вопрос поставлен очень интересный.
Но в приведенном примере с мотором, были приведены не ТП, а скорее ФП
Начинать нужно с анализа набора требований. Конечно же, при изменении ТС в сторону удовлетворения одному из требований, может появиться ТП. И при этом, пытаясь удовлетворить каждому требованию у нас появиться несколько ТП. Но каждое из них будет иметь свой узловой компонент. И резонно начать, как правильно было замечено, с выяснения вопроса: а какой элемент в конструкции ТС (автомобиля, мотора) можно изменять.
То, о чем говорил Алексей, касается анализа требований к ТС. Конечно же, в описании исходной ситуации через перечисления требований, содержаться вложенные требования. И здесь два варианта: либо попытаться работать с более общими требованиями (в которые вложены все остальные требования), либо выбрать требования ниже по уровню общности. Но если говорить о методах диагностики проблемной ситуации, то на этой стадии ее анализа, я пока не вижу возможности, хоть как-то обоснованно выбрать какой тип задачи (в зависимости от выбора требований) лучше решать.
Таким образом, я бы разбил задачу диагностики проблемной ситуации на несколько этапов:
1)Анализ набора требований
Целю данного анализа, должно являться формулировка более общих требований к системе, и разложения этих общих требований на требования – составляющие.
Например: Выделим за такое общее требование высокую мощность. Зададимся вопрос, а за счет чего можно повысить мощность. И так можно построить дерево требований.
Построение и анализ таких деревьев – это отдельная очень интересная задача и тема для исследования и дискуссий.
2) Анализ ТС
Целью данного анализа, является выяснение, какие элементы можно изменять, а какие нет. Имеет смысл здесь провести функциональный и функционально стоймостнный анализ ТС.
На данном этапе можно провести анализ ТС по S-кривой, выявив различные пределы (физические, общественные и т.д.) по каждому из требований. Как правило, не имеет смысла совершенствовать ТС по какому-либо требованию, если она находится вблизи физического предела. И наоборот, стоит взяться за подтягивание ТС по требованию, по которому она находится далеко от пределов.
3)Выявление ключевых недостатков в ТС при попытке удовлетворить каждому из требований или совокупности их известными способами.
Целью данной части анализа, является выявление узловых элементов в ТС, вокруг которых выявлены ТП. Анализ недостатков ТС, возникающих при использовании известных способов по совершенствованию ТС. Имеет смысл провести здесь информационный поиск. А как сейчас и до меня пытались усовершенствовать ТС, путем удовлетворения тому или иному требованию. Построить причинно- следственные цепочки для каждого нежелательного эффекта.
4) Обобщенный анализ и выбор ТП (о ранжиривонии ТП по тем или иным признаком говорить можно, но вообще о ранжировании – не корректно).
По каким критериям выбирать ТП зависит как видно из предыдущих этапов анализа от огромного числа объективных (навязанных) и субъективных (психологических) условий.
И без конкретного примера трудно здесь что-либо рекомендовать. Вернее рекомендовать можно: не брать в качестве узлового компонента элемент ТС, который нельзя изменять, например.

Re: Диагностика проблемной ситуации

AlexeyF wrote:
Если обобщить ход решения, который описан выше, то получим алгоритм диагностики задачи:

  1. выявить в задаче несколько ТП;
  2. для каждого ТП сформулировать ИКР;
  3. по очереди для каждого ИКР посмотреть, устранятся ли остальные ТП, если достичь этот ИКР;
  4. ИКР, который «одним махом» устраняет наибольшее количество ТП, получает наибольший приоритет.

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

Re: Диагностика проблемной ситуации

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

Александр Кудрявцев wrote:

не получается ли у Вас, что для диагностики, для определения того, какое ТП сильнее и должно быть решено в первую очередь, надо предварительно много раз решить задачу ("посмотреть", как достичь этот ИКР, устранить множество ТП).

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

На выходе ТП мы получает проранжированные ТП. А как решать мы их будем – это другой вопрос.

Re: Диагностика проблемной ситуации

AlexeyF wrote:
Александр Кудрявцев wrote:

не получается ли у Вас, что для диагностики, для определения того, какое ТП сильнее и должно быть решено в первую очередь, надо предварительно много раз решить задачу ("посмотреть", как достичь этот ИКР, устранить множество ТП).

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

На выходе ТП мы получаем проранжированные ТП. А как решать мы их будем – это другой вопрос.


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

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


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

Re: Диагностика проблемной ситуации

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

AlexeyF wrote:
Пример был ранее приведен в этой ветке сообщений:
http://www.metodolog.ru/node/21#comment-424

Вы имеете в виду пример с моторами, рассказанный чт, 05/08/2008 - 00:25 участником MNTC ?

Перечень показанных MNTC противоречий - он что, единственно правильный и окончательный? А если он сформулирован с ошибками? Или же - просто субъективен?

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

Re: Диагностика проблемной ситуации

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

Quote:
Что значит, решен с помощью свертывания надсистемы? Может быть, у Вас в этом месте опечатка?
Надсистему, как правило, никто трогать не дает, а Вы предлагаете ее свертывать?
.

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

Quote:
.Если мы будем стремиться к ИКР1.1, то автоматически устранится второе ТП, т.к. при большой силе быстроту мы всегда можем повысить за счет повышающей передачи.
.

Вот почему хорошо бы ввести в обучение ТРИЗ практическое решение задач в металле. Это в теории хорошо. А как посмотришь на деле - в нынешней России пока заставишь заводы освоить что-то новое да еще и точное за разумные деньги - поседеешь. И передача (как и любой другой нестандартный узел) получится раз в 20 дороже мотора!

Quote:
Перечень показанных MNTC противоречий - он что, единственно правильный и окончательный? А если он сформулирован с ошибками? Или же - просто субъективен?
.

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

Re: Диагностика проблемной ситуации

MNTC wrote:

У нас надсистему можно и нужно трогать. Может конечно это редкий случай. Кстати обычно о надсистеме говорят как о чем-то незыблемом, а ведь на деле почти любая надсистема конечно далека то идеала. и над-над-система - произвдственные возможности предприятия тоже, и наднаднаднадсистема - российская проомышленность... а ведь порою самые лучшие решения не помогут если надсистема хромает. Так что надо ее тормошить не стесняясь :)?

Не "надо", а "надо бы". Что же в наших условиях означает пожелание - надо тормошить российскую промышленность "не стесняясь"?
MNTC wrote:

Вот почему хорошо бы ввести в обучение ТРИЗ практическое решение задач в металле. Это в теории хорошо. А как посмотришь на деле - в нынешней России пока заставишь заводы освоить что-то новое да еще и точное за разумные деньги - поседеешь. И передача (как и любой другой нестандартный узел) получится раз в 20 дороже мотора!?

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

MNTC wrote:

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

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

Re: Диагностика проблемной ситуации

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

Александр Кудрявцев wrote:

не получается ли у Вас, что для диагностики, для определения того, какое ТП сильнее и должно быть решено в первую очередь, надо предварительно много раз решить задачу ("посмотреть", как достичь этот ИКР, устранить множество ТП).

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

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

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

GIP wrote:

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

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

MNTC wrote:

У нас надсистему можно и нужно трогать. <…> Так что надо ее тормошить не стесняясь :)

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

Re: Диагностика проблемной ситуации

AlexeyF wrote:

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

Такой метод называется АРИЗ.
AlexeyF wrote:
Здесь даже возникает такое противоречие. Можно для экономии времени подробно не анализировать проблему, а остановиться на первом попавшемся техническом противоречии и решать его, но при этом возрастает вероятность, что это не приведет к сильному решению, тогда придется решать задачу заново.

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

Re: Диагностика проблемной ситуации

Уважаемый AlexeyF!
Позвольте два слова добавить к А.В. Кудрявцеву.
Почему ситуация называется проблемной? В ней чего-то не хватает, или что-то лишнее. Поэтому и решения изобретательских задач у разных решателей получаются разными. Даже независимо от их решательной силы.
По моему мнению, Ваша задача - научиться пропускать эту исходную неопределенность через решение (например, по АРИЗу) и получить ответ, из которого видно, во что выливается эта исходная неопределенность постановки задачи. Ответ не должен быть сильным обязательно, он должен соответствовать постановке. Когда Вы это сделаете, Вы можете предъявить заказчику Ваше решение и указать, что, из-за того, что он не дал такой-то информации, получается такой-то ответ. А если он даст эту информацию, то сразу видно из Вашего решения, что получится какой-то другой ответ.
Вообще говоря, это работа настоящего инженера. Он должен принимать решения сам по недостающей и лишней информации, и знать, во что это превратится в ответе. Условно это можно назвать так: "перекачка" неопределенности входа через задачу в "неопределенность" выхода, или выявление функциональной связи между входом и выходом.
С уважением.
ABB

Re: Диагностика проблемной ситуации

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

Александр Кудрявцев wrote:

Не "надо", а "надо бы". Что же в наших условиях означает пожелание - надо тормошить российскую промышленность "не стесняясь"?

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

Александр Кудрявцев wrote:

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

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

Александр Кудрявцев wrote:

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

Вот оно как. То есть не всегда и не везде есть противоречия. Идеальное устранение НЭ - это вот так просто без противоречий - раз и устранить? Это уже будет какой-то СверхТРИЗ!

Re: Диагностика проблемной ситуации

MNTC wrote:
Александр Кудрявцев wrote:

Не "надо", а "надо бы". Что же в наших условиях означает пожелание - надо тормошить российскую промышленность "не стесняясь"?

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


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

Вот оно как. То есть не всегда и не везде есть противоречия. Идеальное устранение НЭ - это вот так просто без противоречий - раз и устранить? Это уже будет какой-то СверхТРИЗ!

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

Subscribe to Comments for "Диагностика проблемной ситуации"