Тезисы в защиту противоречий в технических системах (3)

Тезисы в защиту противоречий в технических системах (3)

Б.И.Голдовский

1. Вводные слова

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

 

2. Где в системе находится противоречие (напоминание об известном)

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

Наличие шкалы оценок результатов деятельности человека постоянно проявляется в том, что любое действие по изменению чего-либо имеет как минимум два следствия, одно из которых будет оценено как «хорошее», «полезное», а другое – как «плохое», «вредное». Это подтверждается опытом как отдельных людей, так и всего человеческого общества и объясняется диалектическим характером существующего мира. Для тех, кому ссылка на диалектику не достаточна, можно сослаться на действие обобщенного принципа Ле Шателье. Этот принцип, сформулированный А. Ле Шателье (1884) и термодинамически обоснованный К. Брауном (1887), гласит, что внешнее воздействие, выводящее систему из равновесия, стимулирует в ней процессы, стремящиеся ослабить результаты этого воздействия [6], [7]. К примеру, в механике тела, обладающего массой, данный принцип проявляется в виде силы инерции, направленной противоположно вектору ускорения, возникающего при действии внешней силы, изменяющей положение и/или параметры движения этого тела. Данный принцип применим к системам разной природы, поэтому используется не только в физике и химии, но и в экономике и теории систем [8]. Применим он и к процессам развития общества [9].

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

1) количество провозимого груза увеличилось в 2 раза;

2) водоизмещение судна увеличилось в 1,4 раза;

3) из (2) – скорость судна уменьшилась в 1,25 раза;

4) из (2) – эксплуатационные расходы увеличились в 1,1 раза;

5) из (2) – выбег при торможении увеличился в 1,45 раза;

6) из (2) – диаметр циркуляции при повороте по курсу увеличился в 1,3 раза.

Если перейти к следствиям следующего уровня, то получим:

7) из (1+2) – провозоспособность увеличилась в 1,6 раза;

8) из (7+4) – рентабельность повысилась в 1,45 раза;

9) из (5+6) – маневренность уменьшилась в 1,35 раза.

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

- (1), (7) и (8) – «улучшение» качеств судна;

- остальные последствия – «ухудшение» качеств судна.

Поскольку «ухудшения» (2), (3) и (4) поглощаются «улучшениями» более высокого  иерархического уровня (7) и (8), то эти «ухудшения» можно считать приемлемыми (допустимыми). А «ухудшения» (5) и (6), обусловившее «ухудшение» (9) более высокого иерархического уровня, признаются недопустимыми. Причем эти оценки не зависят от конкретной личности оценивающего. Автору приходилось по самым разнообразным проектам работать с судостроителями из разных стран, имеющих различную базовую подготовку и отличающийся менталитет. Тем не менее, в вопросах оценки качества  технических средств по шкале «улучшение-ухудшение» все демонстрировали полное единодушие. То есть степень объективности оценок «улучшения» и «ухудшения» сторон технической системы не уступает степени объективности определения общественных потребностей. 

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

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

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

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

- появилась качественно новая потребность, для удовлетворения которой не было и нет соответствующего технического средства (задача по созданию «пионерных» изобретений – сравнительно редкая задача);

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

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

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

Поскольку противоречия системы тесно связаны с ее структурой, то любая система может быть охарактеризована совокупностью присущих ей диалектических противоречий. Для технической системы – совокупностью присущих ей ТП. При этом часть противоречий могут быть общими для некоторого класса систем. (Можно также отметить, что в [9] структурой системы называется совокупность противоречий внутри системы и между системой и окружающей средой.)

Изложенное выше не является чем-то новым, но, к сожалению, об этом приходится напоминать.

 

3. Техническое средство – это и объект и система

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

Можно согласиться с предложением, приведенным в [10], чтобы в качестве обобщающего термина использовать название «техническое средство» (сокращенно ТСр). Тем более что этот термин соответствует назначению всех изделий техники – быть средством для удовлетворения потребностей общества. Следует также отметить, что термин «техническое средство» как обобщающий очень часто используется в проектной (технической) документации.

А применение терминов «объект» или «система» зависит от уровня (глубины) рассмотрения данного технического средства. Если ТСр рассматривается как нечто целое, не делимое и обладающее рядом характеристик, имеющих внешнее проявление, то можно использовать термин «технический объект». Например, автомобиль в рекламном проспекте описывается, чаще всего, именно как объект. При этом можно описывать и развитие  объекта по изменению его внешних характеристик. Примером такого подхода может служить [11], где по имеющимся статистическим зависимостям показано отношение противоречия между «массой» и «скоростью» транспортных средств, а также исследуется изменение важных внешних параметров ряда технических объектов во времени.

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

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

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

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

Доводы, приведенные в [2] в пользу замены термина «система» термином «ситуация», базируются на явной «демонизации» влияния недостаточной однозначности (которая никогда не может быть достигнута) определения понятия «система» на весь процесс поиска новых технических решений, использующий методический аппарат ТРИЗ. Те проблемные вопросы ТРИЗ, которые отмечены в начале работы  [2], вполне могут решаться и без кардинального и окончательного уточнения понятия «система».

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

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

 

4. Противоречия обостренные и необостренные

Одной из причин, затрудняющих использование аппарата противоречий, присущих системе, для поиска решений, является отсутствие в понятийном аппарате ТРИЗ представления об «обостренном противоречии». В [3] и [5] предлагалось допустимое ухудшение стороны системы обозначать как «отрицательный эффект» (ОЭ), а недопустимое (неприемлемое) – как «нежелательный эффект» (НЭ). Тогда необостренное противоречие представлялось как единство ПЭ (положительного эффекта, улучшения) и ОЭ, а обостренное противоречие – как единство ПЭ и НЭ. При этом отличие обостренного противоречия от необостренного определяется степенью неприемлемости (существенности) ухудшения, являющегося стороной противоречия.

 В классической ТРИЗ противоречием признается только обостренное противоречие, с явно нежелательным эффектом. Откуда оно берется, не ясно, ибо появляется на сцене как «черт из коробки»: вот вам НЭ, который надо устранить. Именно поэтому возможны такие заявления как «в «система»-центрической ТРИЗ не существует критериев, отличающих «систему с противоречием» от «системы без противоречия» [2]. Между тем в любой системе можно найти множество присущих ей противоречий, что с успехом и делается на качественном уровне с помощью построения причинно-следственных цепочек: одномерных, плоских и даже пространственных [12], [13]. Практический опыт проектирования показывает, что такое выявление всего множества технических противоречий, присущих данной ТС (или данному классу ТС), является не инженерной, а академической задачей. Большинство противоречий, присущих системе, вполне проживает весь её жизненный путь, не будучи затронутыми процессом разрешения, поскольку входящие в эти противоречия отрицательные эффекты не существенны (т.е. противоречия не обострены). При выполнении реальных разработок необходимо выделить действительно важные, существенные противоречия, разрешением которых придется заниматься.

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

Такой подход, позволяющий отслеживать динамику изменения степени обострения противоречий, особенно ценен при рассмотрении процесса развития систем. Но он ценен и при решении практических задач, поскольку позволяет выделять именно существенные задачи: как поставленные, так и возникающие в процессе поиска решения. Впрочем, специалисты ТРИЗ, занятые решением практических задач, не могли пройти мимо необходимости оценки существенности ухудшений сторон системы. Так, в [14] предусмотрена оценка существенности НЭ. Представление о допустимых и недопустимых ухудшениях присутствует и в [2].

В [15] рассмотрены различные виды проблем, которые приходится решать при проведении разработок новой техники. По опыту автора из всего множества видов подобных проблем «ломать голову» приходится только в том случае, если необходимо разрешать обостренное противоречие, присущее системе. Во всех остальных случаях обычно достаточно применить известные (тривиальные) решения.

 

5. О «невидимости» противоречий

В последнее время участились заявления о том, что поиск качественно новых решений не обязательно связан с необходимостью разрешения противоречия. Например,  такие решения получаются при проведении функционально ориентированного поиска (ФОП). Однако анализ подобных случаев показывает, что противоречия либо не умеют искать, либо просто не замечают.

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

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

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

Полезно рассмотреть в качестве еще одного примера такое высказывание: «Одна из авиакомпаний отказалась окрашивать свои самолеты, поскольку краска уже больше не нужна для обеспечения гладкости поверхности самолета. Налицо качественное изменение ТС без какого-либо противоречия». В этом примере сразу две ошибки: техническая и методическая. Окраска поверхности самолетов действительно использовалась для снижения шероховатости, когда поверхность фюзеляжа и крыльев выполнялись из дерева и ткани (перкаля). При переходе к цельнометаллическим конструкциям в 50-е годы 20-го века шероховатость металлического листового проката стала ниже шероховатости самой мелкотертой краски. Тем не менее самолеты продолжали красить. Дело в том, что красочное покрытие самолета выполняет несколько функций: декоративную или маскировочную, опознавательную и, главное, защиту от коррозии. Поскольку самолет основную часть времени находится под открытым небом, на него воздействуют различные по составу осадки и налипают частицы грязи, которые при взаимодействии с металлом конструкции могут породить процессы химической или электрохимической коррозии, что особенно опасно для заклепок, широко применяемых в конструкции самолета. Отрицательным эффектом от применения краски является увеличение массы самолета и, соответственно, расхода топлива. Такое противоречие характерно для любых транспортных средств: обеспечение или улучшение функционирования транспортного средства, приводящее к увеличению его массы сверх полезной нагрузки, приводит к ухудшению транспортной эффективности и, соответственно, к повышенному расходу энергии. Соотношение между приростами массы и расхода топлива зависит от принципа действия. Для водоизмещающего судна, например, относительное увеличение роста расхода топлива составляет 2/3 от относительного увеличения массы. А для транспортных средств с динамическими принципами удержания над поверхностью относительный прирост расхода топлива превышает относительный прирост массы. Учитывая, что реальный расход топлива пропорционален скорости движения, которая в авиации велика, и постоянный рост цен на авиационный керосин, указанное противоречие для самолетов находится в состоянии перманентного обострения. Именно из-за необходимости снимать это обострение постоянно реализуются различные мероприятия по снижению массы конструкций и оборудования самолетов.

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

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

 

6. О диалектическом отрицании

Механизмом разрешения противоречия в системе является диалектическое отрицание. Обычно, говоря о диалектическом отрицании, вспоминают «закон отрицания отрицания». Однако главное отличие диалектического отрицания от жесткого формально-логического состоит в том, что при диалектическом отрицании именно отрицанию подвергается только нежелательная сторона явления с сохранением положительной. В наиболее наглядном и полном виде подобное отрицание может быть реализовано путем последовательного (ступенчатого) отрицания признаков, обеспечивающих существование НЭ, с сохранением признаков, обеспечивающих сохранение ПЭ, содержащихся в причинно-следственной цепочке между ПЭ и НЭ. Впервые такой механизм поиска направлений разрешения ТП был предложен в [3] в виде «оператора отрицания», который был реализован в комплексном методе [18] и затем более подробно описан в [4] и [5]. Следует отметить, что практически такая же процедура отрицания звеньев причинно-следственной цепочки предлагается в [1] и [2]. Причем, если в [1] предписание строить такую цепочку отсутствует, а факт движения по цепочке виден из примеров, то в [2] указание на необходимость построения причинно-следственной цепочки между НЭ и ПЭ уже появилось.

Вообще знакомство с безусловно интересными работами [1] и [2] приводит к мысли, что цены им не было бы, появись они до 1974-го или хотя бы до 1990-го годов. Хотя в появлении этих работ именно в 2010-е годы есть свой резон, о котором будет сказано ниже.

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

Другим достоинством применения процедур «оператора отрицания» является также возможность получения более конкретных подсказок по сравнению с обобщенными эвристиками. Это можно продемонстрировать на примере решения задачи о рисосушильной машине, рассмотренной в [1] и [2]. Суть задачи сводится к устранению сильного шума, который создается выходящей из машины струей горячего воздуха. В [1] физической причиной появления шума названа собственная турбулентность струи, что не верно. В [2] эта причина уже определена более правильно: завихрения, которые образуются при выходе струи в воздух. Действительно: взаимодействие частиц струи, имеющих большую скорость, с частицами неподвижного воздуха на границе струи создает в воздухе вихри, которые и порождают шум. (Можно отметить, что подобная задача применительно к шуму реактивного двигателя в свое время рассматривалась в [4].)

Если применить отрицание признаков существования НЭ, то можно получить следующие формулировки:

- скоростные частицы струи взаимодействуют с частицами не неподвижного (подвижного) воздуха;

- скоростные частицы струи взаимодействуют с частицами не неподвижного (подвижного) не воздуха;

- с неподвижными частицами воздуха взаимодействуют не скоростные частицы струи;

- с неподвижными частицами воздуха взаимодействуют не скоростные частицы не струи.

Если обобщить эти формулировки, то получается следующее направление решения: между горячей струей и неподвижным воздухом помещается струя воздуха или часть горячей  струи, имеющей скорость меньше, чем скорость основной струи. (Оценки показывают, что при скорости промежуточной струи в половину от скорости основной можно ожидать снижение уровня шума на 4-6 дБ, что существенно.) Похожую подсказку дает и применение стандарта 1.2.2: ввести между конфликтующими веществами третье вещество, являющееся видоизменением одного из конфликтующих. Однако в результате отрицания признаков существования НЭ подсказка получается гораздо более детальной, поскольку оперирует с признаками, присущему данному конкретному противоречию.

 Даже в случае использования ФОП отрицание признаков существования НЭ исходной (отбрасываемой) системы с обостренным противоречием позволяет конкретизировать запрос, повышая направленность поиска. Это можно продемонстрировать на примере известной учебной задачи об испытании модели парашюта, которая рассмотрена в [19], причем при разборе задачи в части 2 Алгоритма сначала был выполнен компьютерный поиска аналогов, а затем в части 3 – анализ противоречия в системе.

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

Но модели парашютов в кавитационных трубах не испытывали, поскольку напор потока воды для таких моделей был слишком велик. Для этого использовали малую вертикальную установку визуализации. Подобная установка представляет собой два бака (верхний и нижний), соединенных вертикальной трубой диаметром 0,15-0,20м. В нижней части трубы установлена заслонка, а у нижнего бака - насос, обеспечивающий перекачку воды из нижнего бака в верхний по отдельному трубопроводу. В средней части трубы размещается съемный рабочий участок из оргстекла, внутри которого устанавливается модель. Для обеспечения равномерности потока в трубе вход из верхнего бака в трубу выполняется очень плавным и никакие устройства перед рабочей частью размещать не разрешается. Работает установка следующим образом: вода из нижнего бака закачивается наверх, заполняя верхний бак и трубу при закрытой заслонке. Затем производится отстой продолжительностью не менее 5 минут. После этого открывается заслонка и вода протекает по трубе из верхнего бака в нижний. Во время этого перетекания, которое длится немногим более 1 минуты, производится фотографирование картины обтекания. Задача этой установки заключается в оперативном испытании значительного количества мелких (дешевых) моделей, по результатам которых формировались рекомендации, которые затем воплощались в крупные модели для дальнейших испытаний в аэродинамической трубе или бассейне. Цель испытаний, как правило, заключается в исследовании поведения вихревых шнуров, образующихся, например, на стыке крыла самолета с фюзеляжем, на изломе крыла, на стыке выступающих частей подводного аппарата с корпусом: как они будут взаимодействовать между собой и с моделью. Поскольку обеспечить подачу пузырьков воздуха в поток в такой установке не удается из-за опасения исказить картину обтекания, для визуализации вихрей используется подача жидкой краски в район предполагаемого отрыва вихря. Краска засасывается в зону пониженного давления в центре вихря, делая его заметным. У такого способа визуализации было выявлено несколько недостатков:

- для подвода краски к месту отрыва вихря в теле модели приходилось выполнять соответствующие каналы, что усложняло и удорожало изготовление моделей;

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

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

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

- краска (маркер) подается не в зону отрыва вихрей;

- краска (маркер) не накапливается в воде (подается один раз или выводится из воды);

- краска (маркер) не подается в воду (анти подается, извлекается из воды).

Получается, что при поиске существующих аналогов или проведении ФОП можно было бы сконцентрироваться на двух направлениях:

- обеспечение визуализации вихрей при наличии в  объеме воды малого количества краски;

- извлечение газовых маркеров из воды (или материала модели).

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

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

 

7. Об изменяющейся ценности направленного поиска

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

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

Обесценивание некоторых направлений деятельности из-за влияния компьютерных технологий наблюдается и в ТРИЗ. В прошлом веке для оперативного поиска задач-аналогов необходимо было заводить соответствующую картотеку, а для поиска нового принципа действия – массив данных по физэффектам с поисковыми таблицами. Сейчас и то и другое гораздо проще найти в Интернете. Этим, в частности, объясняется растущая популярность проведения ФОП: вместо того, чтобы анализировать «плохую» систему, проще её отбросить и поискать «хорошую» с помощью компьютера.

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

 

8. О фактической сложности и необходимой простоте ТРИЗ

Обратиться в очередной раз к теме противоречий в технических системах автора побудил и тот факт, что в реальном инновационном поиске аппарат ТРИЗ используется совместно с большим количеством других методик (которые при ближайшем рассмотрении не выходят за рамки действий нормального инженера, но зато хорошо разрекламированы). В этой ситуации выхолащивание из ТРИЗ факторов её особенности (каковым является, в частности, умение работать с противоречиями в системе) приведет к тому, что ТРИЗ просто затеряется в массе всех прочих методов поиска. (Чем же тогда тризовцы будут отличаться от иных разработчиков?) Между тем в [9] ТРИЗ приводится как пример овладения диалектической формой мышления, использующей понятия «развитие» и «противоречие». При этом указывается, что современные вызовы как раз и требуют применения такой формы мышления высокого уровня. Однако там также отмечается, что даже элиты в основном пользуются обыденной формой мышления, причем в упрощенном варианте типа «здравого смысла», а большинство населения не «дружит» и с этим упрощенным вариантом. Личный опыт автора подтверждает, что даже среди людей с высшим образованием специалисты, которые могут внятно и обоснованно изложить свою мысль – это «штучный товар». То есть ТРИЗ – это «прикладная диалектика», но вряд ли этой диалектике можно научить широкие круги. Следует признать, что ТРИЗ в полном объеме и во всей своей сложности является научным и культурным феноменом, доступным весьма ограниченному кругу людей. А для того, чтобы донести ТРИЗ до более широкого круга лиц, необходимо провести специальную работу по выделению компактного ядра ТРИЗ и изложения этого ядра в гораздо более простом формате обыденного мышления.

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

Эти достаточно банальные умозаключения и примеры приведены здесь для того, чтобы была ясна причина появления работы [2]: весь её текст пронизан мыслью о необходимости упрощении материала и процедур ТРИЗ (что особенно актуально с учетом намерения большинства зарубежных специалистов, обучающихся ТРИЗ, более нескольких часов на это обучение не тратить). Отказ от использования понятия «система», который в [2] обосновывается «высшими» соображениями, на самом деле позволяет избежать необходимости объяснять это достаточно сложное понятие обучаемым лицам и не тратить время на освоение процедуры полного описания системы (которое далеко не всегда нужно при практическом решении задачи). А термин «ситуация»  вследствие большой общности понятен без объяснения, на интуитивном уровне, поскольку человек всегда находится в какой-либо ситуации (даже когда спит). Упрощению восприятия процедур ТРИЗ служит и перевод всего процесса в психологическую и лингвистическую плоскости, поскольку обычный человек не любит возиться со сложными логическими конструкциями. Например, когда в практику обучения ТРИЗ ввели представление о ФП, многие слушатели стали охотно формулировать его (зачастую ошибочно), игнорируя выявление ТП. Это становится понятным, если учесть, что сформулировать антиномию типа «должно быть… и не должно быть…», ухватившись за один из признаков существования НЭ, психологически гораздо проще, чем работать с логической структурой ТП. Соответственно, ничего не зная о правильном построении причинно-следственной цепочки противоречия, можно выявить значительную её часть, ухватившись за описание НЭ и просто отвечая на наводящие вопросы «Почему», «Зачем» и «Для чего». Целям упрощения служит и замена представления об идеальности как об особой эвристике ТРИЗ понятием относительной эффективности, давно известным и применяемым в проектировании. Такая замена не корректна, переклеивание ярлыков «множит сущности сверх необходимого», однако относительную эффективность легче объяснить и представить количественно.

Таким образом, дальнейшее развитие ТРИЗ должно идти по двум направлениям: наряду с разработкой теории и базовых методик необходимо создавать упрощенные (но корректные) версии ТРИЗ, пригодные для широкого круга пользователей. Разумеется, любая упрощенная версия имеет ограниченное применение. Подход, изложенный в  [1] и [2], явно не пригоден для моделирования развития технических средств, однако может быть продуктивен при решении определенного круга практических задач (границы этого круга будут уточняться практикой применения). При создании упрощенных версий главное – это не забывать о наличии границ.

В заключение необходимо заметить, что показанная  в настоящих тезисах (в напоминание) картина противоречий в технических системах, разумеется, значительно сложнее слишком простого, но привычного представления «внутри АП прячется ТП, а внутри ТП – ФП».  Однако специалисты высокого уровня, которым и предстоит развивать ТРИЗ, должны бы представлять себе эту область знания во всей её неизбежной сложности. 

 

Использованные источники

1. Каплан Л.А. Новый подход к анализу и разрешению противоречий. Диссертационная работа. 2011 – http://triz-summit.ru/file.php/id/f5003/name/01-Len%20Kaplan_Диссертация.pdf

2. Каплан Л. Понятие «система» в рамках ТРИЗ. В 6-ти частях. 2014 – http//www.metodolog.ru/node/1795;1796; 1797; 1799; 1800; 1802

3. Голдовский Б.И. О противоречиях в технических системах: материалы к семинару преподавателей методики изобретательства ОЛМИ при ЦС ВОИР / Б.И.Голдовский. – Горький, 1974. -  Деп. в ЧОУНБ 26.09.1989 № 758

4. Голдовский Б.И., Вайнерман М.И. Рациональное творчество – М.: «Речной транспорт», 1990

5. Голдовский Б.И. О противоречиях в технических системах-2 / Б.И.Голдовский. – Нижний Новгород, 1999. – Деп. в ЧОУНБ 28.02.2000 № 2547 - http://www.metodolog.ru/00001/00001.html

6. http://ru.wikipedia.org/wiki

7. http://dic.academic.ru/dic.nsf/ecolog/864

8. http://www.wikiznanie.ru/ru-wz/index.php

9. Переслегин С.Б. Новые карты будущего, или Анти-Рэнд. – М.: АСТ; СПб.: Terra Fantastica, 2009

10. Паренчик Г.И. Терминологический аспект ТРИЗ. Ч. 8. 2006 - http://www.metodolog.ru/00645/00645.html

11. Привень А.И. О количественных критериях идеальности технических систем. В 4-х частях. 2012 -  http//www.metodolog.ru/node/1499; 1505; 1512; 1524

12. Rousselot F., Zanni-Merk C., Cavallucci D. Towards a formal definition of contradiction in inventive design, Computers in Industry, 2012, vol. 63, p.2310242.

13. Cavallucci D., Zanni-Merk C., Rousselot F. On contradiction clouds. Proceedings of the TRIZ Future Conference 2008, Procedia Engineering, 2011, No. 9, p. 368–378.

14. Шпаковский Н., Новицкая Е. Алгоритм работы с изобретательскими проектами. 2008 - http://www.gnrtr.ru/Generator.html?pi=301&cp=3

15. Кудрявцев А.В. Противоречия, их альтернативы и возможности развития. 2008 - http://www.metodolog.ru/01344/01344.html

16. Авиакомпания easyJet покрасит свои самолеты наносмолой - http://lenta.mk.ua/article/555589.html (февраль 2011г.)

17. MOL внедряет новую краску для судов, уменьшающую трение корпуса с водой - http://www.crewing.biz.ua/Article55028.html (июль 2011г.)

18. Комплексный метод поиска новых технических решений. В 3-х частях. – Горький: 1979, 1980 (Голдовский Б.И. и др.,в соавторстве)

19. Рубин М.С. Универсальный алгоритм решения изобретательских задач (АРИЗ – Универсал – 2010) – http://triz-summit.ru/ru/203798/205151/205266/205416/205301/

 

 

Март 2014 года

 

 

 

 

 

 

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

Рубрики: 

Комментарии

Re: Тезисы в защиту противоречий в технических системах (3)

А мне вот даже интересно, кто-нибудь из отметившившихся комментаторов имеет что сказать по комментируемому тексту или только про свое понимание некоего термина, в тексте прозвучавшего?

Re: Тезисы в защиту противоречий в технических системах (3)

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

ИМХО, противоречие находится не в системе, и не в голове решателя; оно появляется при переходе от старой системы КАК ЕСТЬ к новой системе КАК НАДО при особых условиях.

При таких особых условиях возникает ситация, когда известные решателю способы реализации требований в системе КАК НАДО не годятся. Подробнее я об этом написал в статье: http://triz.by/articles/refinement-of-the-notion-of-contradiction-in-triz.html

 

Re: Тезисы в защиту противоречий в технических системах (3)

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

 

Quote:

Submitted by AndrewK on сб, 07/06/2014 - 02:24.

...противоречие находится не в системе, и не в голове решателя; оно появляется при переходе от старой системы КАК ЕСТЬ к новой системе КАК НАДО при особых условиях.

К моменту или к периоду времени появления противоречия вопросов нет: оно появляется при переходе от "плохой" существующей системы (по-вашему, от системы КАК ЕСТЬ) к новой "хорошей" системе (по-вашему, к системе КАК НАДО).

Вопрос вот в чем: ГДЕ появляется противоречие, если НЕ в системе, и НЕ в голове решателя? Оно же не висит в воздухе, правда? 

Успехов,

AlexZ

 

Re: Тезисы в защиту противоречий в технических системах (3)

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

2 AlexZ

Чтобы ответить на вопрос "ГДЕ?", следует определиться, что речь идет о процессе, который является частью процесса проектирования системы КАК НАДО. 

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

Процессным объектом для рассматриваемого процесса является проект системы КАК НАДО. В ИТ проект системы КАК НАДО оформляется в виде спецификаций. Если упрощенно, то спецификации - это описание выбранных для системы КАК НАДО решений, удовлетворяющих требованиям. Ну как-то так...

С уважением,

АК

 

Re: Тезисы в защиту противоречий в технических системах (3)

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

Quote:

Submitted by AndrewK on вс, 08/06/2014 - 15:26.

2 AlexZ

Чтобы ответить на вопрос "ГДЕ?", следует определиться, что речь идет о процессе, который является частью процесса проектирования системы КАК НАДО.

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

Вы хотите сказать, что вне ИТ проектировщики сразу бросаются проектировать решение: «... думать некогда, трясти надо»?

Quote:

Если посмотреть на структуру противоречия, то можно увидеть, что противоречие как раз и представляет собой структуру, состоящую из требований и способа их реализации. Следовательно, упрощенно мы можем сформулировать, что противоречие возникает и должно быть разрешено после сбора и анализа требований, но до окончательного выбора решений для системы КАК НАДО.

Зачем смотреть на структуру противоречия? То, что «... противоречие возникает и должно быть разрешено после сбора и анализа требований, но до окончательного выбора решений для системы КАК НАДО», - это привязка ко времени возникновения противоречия и ко времени его разрешения, но не к месту возникновения противоречия.

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

Quote:

Процессным объектом для рассматриваемого процесса является проект системы КАК НАДО. В ИТ проект системы КАК НАДО оформляется в виде спецификаций. Если упрощенно, то спецификации - это описание выбранных для системы КАК НАДО решений, удовлетворяющих требованиям. Ну, как-то так...

Ответа нет...

Успехов,

AlexZ

Re: Тезисы в защиту противоречий в технических системах (3)

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

2 AlexZ

AlexZ wrote:

Quote:

Submitted by AndrewK on вс, 08/06/2014 - 15:26.

2 AlexZ

Чтобы ответить на вопрос "ГДЕ?", следует определиться, что речь идет о процессе, который является частью процесса проектирования системы КАК НАДО.

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

Вы хотите сказать, что вне ИТ проектировщики сразу бросаются проектировать решение: «... думать некогда, трясти надо»?

Не так. Я просто привел пример отрасли, которую хорошо знаю. 

AlexZ wrote:
Quote:

Если посмотреть на структуру противоречия, то можно увидеть, что противоречие как раз и представляет собой структуру, состоящую из требований и способа их реализации. Следовательно, упрощенно мы можем сформулировать, что противоречие возникает и должно быть разрешено после сбора и анализа требований, но до окончательного выбора решений для системы КАК НАДО.

Зачем смотреть на структуру противоречия? То, что «... противоречие возникает и должно быть разрешено после сбора и анализа требований, но до окончательного выбора решений для системы КАК НАДО», - это привязка ко времени возникновения противоречия и ко времени его разрешения, но не к месту возникновения противоречия.

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

Очевидно, я пропустил важную для понимания часть ответа на вопрос: ГДЕ? Ответ: в процессе проектирования системы КАК НАДО. Далее (см. предыдущий пост) я описал где именно в этом процессе возникает противоречие. 

Своим слушателям на семинаре я бы добавил, что противоречие возникает в знаниях о рассматриваемой системе. С одной стороны, мы знаем, как устроена и работает система КАК ЕСТЬ; также мы знаем, как должна работать система КАК НАДО. С другой стороны, мы знаем, что выявленные противоерчия не позволят сделать систему КАК НАДО. Можно с некоторой долей натяжки сказать, что противоречия находятся в знаниях, а разрешение противоречия - изменение этих знаний. Вот поэтому они (противоречия) и не находятся ни в системе, ни в голове.

 

AlexZ wrote:
Quote:

Процессным объектом для рассматриваемого процесса является проект системы КАК НАДО. В ИТ проект системы КАК НАДО оформляется в виде спецификаций. Если упрощенно, то спецификации - это описание выбранных для системы КАК НАДО решений, удовлетворяющих требованиям. Ну, как-то так...

Ответа нет...

Успехов,

AlexZ

 

С уважением,

АК

 

Re: Тезисы в защиту противоречий в технических системах (3)

AndrewK wrote:

2 AlexZ

AlexZ wrote:

Зачем смотреть на структуру противоречия? То, что «... противоречие возникает и должно быть разрешено после сбора и анализа требований, но до окончательного выбора решений для системы КАК НАДО», - это привязка ко времени возникновения противоречия и ко времени его разрешения, но не к месту возникновения противоречия.

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

Очевидно, я пропустил важную для понимания часть ответа на вопрос: ГДЕ? Ответ: в процессе проектирования системы КАК НАДО. Далее (см. предыдущий пост) я описал где именно в этом процессе возникает противоречие. 

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

Но, как потенциальный "слушатель семинара", все же не могу не поинтересоваться по поводу именно ПРОСТРАНСТВЕННОЙ, А НЕ ВРЕМЕННОЙ локализации противоречия.

"В процессе" - это не ответ. Процесс - это, даже чисто этимологически: лат. processus — «течение», «ход», «продвижение». Здесь нет пространства, а есть только время. На что и указал AlexZ.

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

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

Так в каком- все-таки объекте - НЕ "системе" и НЕ "процессе", а именно "объекте"! - локализовано событие "возникновение противоречия", если этим объектом НЕ является "техническая система" и НЕ является "голова решателя"?

Заранее благодарен за интересные версии.

Re: Тезисы в защиту противоречий в технических системах (3)

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

priven wrote:

Так в каком- все-таки объекте - НЕ "системе" и НЕ "процессе", а именно "объекте"! - локализовано событие "возникновение противоречия", если этим объектом НЕ является "техническая система" и НЕ является "голова решателя"?

Заранее благодарен за интересные версии.

2 priven

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

Если мы хотим определить пространство, то давайте найдем ответ на вопрос: в каком пространстве "живет" процесс проектирования системы КАК НАДО? Очевидно, что ни пространство, занимаемое системой КАК ЕСТЬ, ни пространство, занимаемое головой решателя, не подходят. 

Если же мы хотим определить "объект", в котором возникает противоречие, то можно пойти другим путем. Нужно определить объект, который обрабатывается в рамках процесса проектирования системы КАК НАДО. В ИТ такой объект состоит из 2-х частей: 1) требования; 2) спецификации.  Давайте для простоты назовем этот объект "требования и спецификации". Вот как раз в этом объекте и "возникают" противоречия. К слову, в нем же они и разрешаются.

Опять же к слову, если не философствовать, то можно определить, что противоречия живут в пространстве требований и спецификаций ;) 

 

Re: Тезисы в защиту противоречий в технических системах (3)

если не философствовать, то можно определить, что противоречия живут в пространстве требований и спецификаций 

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

Re: Тезисы в защиту противоречий в технических системах (3)

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

priven wrote:

если не философствовать, то можно определить, что противоречия живут в пространстве требований и спецификаций 

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

 

Александр, в принципе да. С одной оговоркой, что информационное пространство, в котором "живет" знаковая система, тоже является частью реального мира.

 

С уважением,

АК

 

 

Re: Тезисы в защиту противоречий в технических системах (3)

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

Quote:

Submitted by priven on ср, 11/06/2014 - 02:22.

Андрей, правильно ли я Вас понял, что противоречия возникают в некоторой знаковой системе (описании), содержащей требования и спецификации к улучшаемой системе?

Quote:

Submitted by AndrewK on ср, 11/06/2014 - 09:48.

Александр, в принципе - да.

Ага, ага...

«По Привеню» в некоторой знаковой системе (описании) сначала возникают  противоречия, а потом, «по Курьяну», живут в этом описании.

Представляю картину: Решатель описал систему, которую потребовалось усовершенствовать. То ли эта система ему самому не нравилась, либо начальник приказал. Короче, описал систему КАК ЕСТЬ.

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

После чего с сознанием хорошо сделанной работы закрыл рабочий журнал (или файл) с красивым названием «Требования и спецификации». Никаких описаний возможных противоречий перехода от системы КАК ЕСТЬ к системе КАК НАДО в «Требованиях и спецификациях» не было...

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

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

Успехов,

AlexZ

Re: Тезисы в защиту противоречий в технических системах (3)

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

Уважаемый AlexZ,

на авторство способа выявления и разрешения противоречий через записи в рабочий журнал со вставленной туда таблицей Альтшуллера не претендую; это исключительно ваш интеллектуальный продукт. 

Свой способ я описал в статье, ссылка на которую приведена выше. 

С уважением,

АК

Re: Тезисы в защиту противоречий в технических системах (3)

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

На мой взгляд, противоречий в технических СИСТЕМАХ нет вообще, т.к. они могут быть только в конкретно поименованных технических СРЕДСТВАХ..

Это следует из того, что параметры  как численно измеряемые величины можно количественнно определить только в конкретных технических средствах (или их частях). Тогда как техническую систему измерить техническими средствами вряд ли получится.

Re: Тезисы в защиту противоречий в технических системах (3)

AlexZ wrote:

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

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

Тем не менее, в данном случае защищу Вашего оппонента. А именно - сошлюсь на всемирно известные работы некоего Алексея Захарова, посвященные описанию некоей Универсальной Системы Эволюции, аббревиатура которой (УСЭ) переводится с украинского простым и невинным русским словом "всё" ("ни на что не намекаю" (с), и даже песенку не пою...).

Позволю себе процитировать слова автора этой системы:

После чего с сознанием хорошо сделанной работы закрыл рабочий журнал (или файл) с красивым названием «Требования и спецификации». Никаких описаний возможных противоречий перехода от системы КАК ЕСТЬ к системе КАК НАДО в «Требованиях и спецификациях» не было...

А теперь, внимание, вопрос к Вам как этому самому автору: эти слова относятся к описанию Вашей собственной системы - или иной? Если иной - то чем Ваша от оной отличается? 

Re: Тезисы в защиту противоречий в технических системах (3)

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

GIP wrote:

На мой взгляд, противоречий в технических СИСТЕМАХ нет вообще, т.к. они могут быть только в конкретно поименованных технических СРЕДСТВАХ..

Это следует из того, что параметры  как численно измеряемые величины можно количественнно определить только в конкретных технических средствах (или их частях). Тогда как техническую систему измерить техническими средствами вряд ли получится.

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

Противоречия появляются в процессе перехода от старой системы (средства) к новой. Другими словами, противоречия относятся к процессу мышления. 

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

Re: Тезисы в защиту противоречий в технических системах (3)

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

В качестве:

(1) комментария к чеканной фразе Курьяна:

Quote:

Submitted by AndrewK on пн, 09/06/2014 - 20:01.

«...противоречия живут в пространстве требований и спецификаций»

и

(2) ответа на вопрос Привеня к Курьяну:

Quote:

Submitted by priven on ср, 11/06/2014 - 13:22.

«Правильно ли я Вас понял, что противоречия возникают в некоторой знаковой системе (описании), содержащей требования и спецификации к улучшаемой системе?»

1. Когда возникает противоречие 

Противоречие возникает при попытке изменить систему КАК ЕСТЬ в систему КАК НАДО.

Два примера из картотеки:

Карт. 459 (1991 г.). Строительство ветроэлектростанции (ВЭС) в море, где ветер сильнее, чем на суше - можно сэкономить на высоте мачты. Но электроэнергия будет на 70% дороже и обслуживание сложнее.

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

Надо заметить, что эта дисциплина - социальная этика науки - еще очень молода. Вплоть до конца XIX в. считалось, что любое научное открытие безусловно полезно для человечества, и поэтому все, что открыли, надо немедленно вводить в практику, тем самым улучшая и без того неплохие условия жизни homo sapiens.  Однако XX в. показал, что все далеко не так безоблачно...

2. Где возникает противоречие 

Противоречие возникает:

2.1. В реальной системе, т.е. в системе, существующей в физическом мире, если производится её изменение с помощью МПиО: попробовали - не получилось; попробовали - опять не получилось; ...; и т.д. Яркий литературный, но вполне жизненный пример приведен Д.Дефо в романе «Робинзон Крузо», http://lib.ru/PRIKL/DEFO/cruzo.txt_with-big-pictures.html

Гл. 14. Робинзон строит лодку...

... мне пришло в голову: не попробовать ли мне самому сделать лодку или, еще лучше, пирогу? Сделать пирогу казалось мне не только возможным, но самым легким делом...

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

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

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

2.2. В воображаемой системе, т.е. в системе, образ которой построен в голове решателя (проектировщика), и этот образ решатель меняет. К.Маркс: «Самый плохой архитектор отличается от самой хорошей пчелы, строящей соты, тем, что он, в отличие от пчелы, уже построил эти соты в голове», - здесь речь как раз о том самом образе системы, с которым решатель работает.

Замечание. Не хочу возобновлять бесплодную и бесконечную дискуссию про модель(и), поэтому использую термин «образ». Естественно, образ имеет все свойства, существенные для реальной системы, и поэтому результаты изменений образа могут быть перенесены на реальную систему.

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

Заключение: при изменении системы КАК ЕСТЬ в систему КАК НАДО противоречие возникает: 

  • либо в системе реальной - пирога Робинзона была одновременно и хороша (годилась для плавания по морю ), и плоха (в море её было не спустить);
  • либо в идеальной, т.е. в воображаемой системе, построенной и изменяемой в голове решателя.    

Успехов,

AlexZ 

Re: Тезисы в защиту противоречий в технических системах (3)

AlexZ wrote:

Заключение: при изменении системы КАК ЕСТЬ в систему КАК НАДО противоречие возникает: 

  • либо в системе реальной - пирога Робинзона была одновременно и хороша (годилась для плавания по морю ), и плоха (в море её было не спустить);
  • либо в идеальной, т.е. в воображаемой системе, построенной и изменяемой в голове решателя.    

Со вторым пунктом я согласен полностью. А вот с первым...

Можно ли в первом случае считать, что противоречие было локализовано в самой пироге? А что, если бы рядышком нашлись, к примеру, несколько бревен, с помощью которых (используя их в качестве катков) ее можно было спустить к морю? Противоречие в пироге бы исчезло? Интересно, однако же, получается: противоречие локализовано в пространстве, занимаемом пирогой, но оно исчезает от того, что где-то в другой точке пространства имеется некое средство, которое, будучи использовано должным образом (видимо, без участия головы? ведь противоречие-то не в ней?), дает возможность совершить (опять же, я так понимаю, без участия головы) некие "сакральные" действия...

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

P.S. Если Вам угодно употреблять слово "образ" как нечто антонимичное слову "модель", Ваше право. Я же сошлюсь на Википедию:

Моде́ль (фр. modèle, от лат. modulus — «мера, аналог, образец») — это система, исследование которой служит средством для получения информации о другой системе[1], это упрощённое представление реального устройства и/или протекающих в нём процессов, явлений.

Re: Тезисы в защиту противоречий в технических системах (3)

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

AlexZ написал

AlexZ wrote:

Заключение: при изменении системы КАК ЕСТЬ в систему КАК НАДО противоречие возникает: 

  • либо в системе реальной - пирога Робинзона была одновременно и хороша (годилась для плавания по морю ), и плоха (в море её было не спустить);
  • либо в идеальной, т.е. в воображаемой системе, построенной и изменяемой в голове решателя.    

Давайте разбермся, есть ли противоречие в реальной пироге Робинзона в примере AlexZ? 

Общая схема ЖЦ пироги выглядит следующим образом:

Пироги нет -> Пирога сделана и находится в лесу -> Пирога находится в море (у причала) -> Пирога плывет по морю

Робинзон определел требование к 4-ой стадии ЖЦ пироги: пирога должна быть пригодной для плавания по морю. Другие требования Робинзону "не то, чтобы не приходили в голову", но определены не были. Соответственно, он не определил требований к 3-й стадии: пирогу легко переместить из леса в море. 

Не определив требования ко 3-й стадии, Робинзон не обнаружил и противоречия. Для реализации своего единственного требования он применил известный способ: выбрал в лесу подходящее дерево (побольше), срубил и выдолбил его. Пирога получилась? Да. Противоречие в ней есть? Нет. 

Лишь после того, как Робинзон попытался перейти к 3-й стадии, он обнаружил новое требование: пирогу легко перемещать из леса к морю. В этот момент Робинзон столкнулся с административным противоречием: пирогу нужно переместить к морю; но неизвестно, как это сделать. 

Если бы Робинзон знал современный ТРИЗ, то он бы еще до начала изготовления определил требования ко всем стадиям ЖЦ пироги. Это помогло бы ему найти противоречие:

способ, включающий выбор подходящего дерева в лесу и изготовление из него пироги, позволяет (+) сделать пирогу, пригодную для моря, но (-) не позволяет легко перетаскивать такую пирогу из леса к морю.

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

Данный разбор показывает, что в пироге Робинзона (на 2-й стадии ее ЖЦ; а до следующих стадий она не дожила) никаких противоречий нет. Сотвественно, AlexZ чего-то не додумал в своем примере с противоречием в реальной пироге Робинзона. 

Re: Тезисы в защиту противоречий в технических системах (3)

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

priven wrote:

AlexZ wrote:

Заключение: при изменении системы КАК ЕСТЬ в систему КАК НАДО противоречие возникает: 

  • либо в системе реальной - пирога Робинзона была одновременно и хороша (годилась для плавания по морю ), и плоха (в море её было не спустить);
  • либо в идеальной, т.е. в воображаемой системе, построенной и изменяемой в голове решателя.    

Со вторым пунктом я согласен полностью. А вот с первым...

Александр,

представим на секунду, что Пятница, перед тем, как попасть на остров к Робинзону, закончил курсы по управлению требованиями. Уже на острове Пятница бы выяснил, что для создания пироги нужно учитывать требования разных стадий ЖЦ пироги. Выслушав анализ Пятницы, Робинзон сформулировал бы противоречие и не стал бы использовать способ, который это противоречие не устраняет. Получается, что части противоречия могут существовать в разных головах: у Пятницы и Робинзона. Как в этом случае мы будем называь место, где "живет" противоречие?

С уважением,

АК

Re: Тезисы в защиту противоречий в технических системах (3)

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

AlexZ:

Заключение: при изменении системы КАК ЕСТЬ в систему КАК НАДО противоречие возникает: 

  • либо в системе реальной - пирога Робинзона была одновременно и хороша (годилась для плавания по морю ), и плоха (в море её было не спустить);
  • либо в идеальной, т.е. в воображаемой системе, построенной и изменяемой в голове решателя.    

Quote:

Submitted by priven on пт, 13/06/2014 - 03:30.

Со вторым пунктом я согласен полностью. 

Зафиксировали: При изменении системы КАК ЕСТЬ в систему КАК НАДО противоречие возникает в воображаемой системе, построенной и изменяемой в голове решателя.

Quote:
 

Submitted by priven on пт, 13/06/2014 - 03:30.   

А вот с первым...  

(1) Можно ли в первом случае считать, что противоречие было локализовано в самой пироге?

(2) А что, если бы рядышком нашлись, к примеру, несколько бревен, с помощью которых (используя их в качестве катков) ее можно было спустить к морю? Противоречие в пироге бы исчезло? 

Для удобства ответа пронумеровал вопросы как (1) и (2). 

(1) Да, можно. Именно так я это противоречие и сформулировал.

(2) Условие "А что, если бы рядышком нашлись..." использовать нельзя. В ТРИЗ есть т.н. "Правило № 1" - при анализе ситуации использовать только то, что написано в условии. К ресурсам над-, под- и т.д. систем обратимся позднее.  

Пояснение к условию исчезновения противоречия:

Пирога - это система КАК ЕСТЬ, и плохая часть описывающего эту систему противоречия - пирогу в море не спустить.

Пирога + бревна-катки - это уже изменение системы КАК ЕСТЬ к системе КАК НАДО, т.е. это переход к новой системе. При таком переходе плохая часть противоречия "пирогу в море не спустить" исчезает. Даже лучше так: для новой системы "пирога + бревна-катки" такого противоречия просто нет.

Спасибо за вопросы! Успехов,

AlexZ 

Re: Тезисы в защиту противоречий в технических системах (3)

AlexZ wrote:

В ТРИЗ есть т.н. "Правило № 1" - при анализе ситуации использовать только то, что написано в условии. К ресурсам над-, под- и т.д. систем обратимся позднее.  

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

Пирога + бревна-катки - это уже изменение системы КАК ЕСТЬ к системе КАК НАДО, т.е. это переход к новой системе. При таком переходе плохая часть противоречия "пирогу в море не спустить" исчезает. Даже лучше так: для новой системы "пирога + бревна-катки" такого противоречия просто нет.

То есть, простое добавление к системе внешнего элемента устраняет противоречие, локализованное внутри системы? Интересно, каким образом это противоречие устраняется? в результате какого именно взаимодействия? где именно это взаимодействие протекает? если в материальном мире - то как ФИЗИЧЕСКИ взаимодействуют бревна в лесу (в принципе подходящие для того, чтобы сделать из них катки, но пока еще даже не спиленные) с пирогой? или... у пироги, выдолбленной из дерева, тоже есть интеллект, в котором и локализовано противоречие?.. Буратино отдыхает...

 

Re: Тезисы в защиту противоречий в технических системах (3)

AndrewK wrote:

Получается, что части противоречия могут существовать в разных головах: у Пятницы и Робинзона. Как в этом случае мы будем называь место, где "живет" противоречие?

Андрей, отвечать на вопросы - в данном случае Ваша работа, а не моя :). Я, в лучшем случае, могу что-то подсказать.

Если Вам интересен мой ответ, то обратитесь к моей статье, в которой я дал свое определение ТС: вот там они, в моем представлении, и возникают. Но просьба мое определение ТС на этой ветке не обсуждать! Эта ветка - про противоречия.

Re: Тезисы в защиту противоречий в технических системах (3)

AlexZ wrote:
В ТРИЗ есть т.н. "Правило № 1" - при анализе ситуации использовать только то, что написано в условии. К ресурсам над-, под- и т.д. систем обратимся позднее. 

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

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

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

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

Re: Тезисы в защиту противоречий в технических системах (3)

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

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

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

Александр Владимирович,

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

изменение системы из КАК ЕСТЬ в КАК НАДО сопровождается не только появлением новизны в системе, но и появлением новизны в системе знаний. Более того, новизна - это свойство системы знаний, а не системы, которую решатель менял.

Здесь возникают следующие интересные вопросы:

1) а что из себя представляла исходная система знаний (до возникновения противоречия)?

2) а что нового появляется в системе знаний после устранения противоречия? 

Давайте посмотрим, что происходит в системе знаний.

До решения изобретательской задачи мы имели систему знаний, которая описывала систему КАК ЕСТЬ. В ней, в частности, пристуствовало знание о том, каким способом система КАК ЕСТЬ реализет некоторое требование: т.е. отношение способ -> требование. 

В какой-то момент времени в систему знаний добавляется новое требование, относящееся уже к системе КАК НАДО.

Очевидно, что если отношение "способ -> новое требование" может быть реализовано в реале, то система знаний меняется незначительно: мы всего лишь узнали, что наш способ могёт еще и новое требование. 

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

Соответственно, разрешение противоречия - это переход к ситуации "измененный способ -> новое требование и отсутствие НЭ". По сравнению с предыдущим случаем система знаний изменяется значительно сильнее: в ней появляется 1) новое требование (как и в первом случае), 2) новое отношение "старый способ -> НЭ" 3) новый способ, как правило, это мутация старого способа; 4) новое отношение "новый способ -> новое требование"; 5) новое отношение "новый способ -> нет НЭ". Новизна, однако!

Теперь несколько слов про голову решателя и систему знаний. Можно было бы согласиться с тезисом, что система знаний "живет" и изменяется в голове условно объединенного человека. Только вот этот тезис не очень операционален, так как подталкиваен нас к метафоре, что голова объединенного решателя - это место хранения системы знаний. ИМХО, более операциональной метафорой будет "голова объединенного решателя - это процессор, т.е. место обработки системы знаний". В этом случае мы можем рассматривать процесс: исходная система знаний -> голова решателя -> новая система знаний. А эта схема "легким дивжением руки" превращается в другую схему: исходная система знаний -> изобретательская задача (противоречие) -> новая система знаний. Получется весьма технологичненько, не находите? 

Re: Тезисы в защиту противоречий в технических системах (3)

AndrewK wrote:
Очевидно, что если отношение "способ -> новое требование" может быть реализовано в реале, то система знаний меняется незначительно: мы всего лишь узнали, что наш способ могёт еще и новое требование. 

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

Соответственно, разрешение противоречия - это переход к ситуации "измененный способ -> новое требование и отсутствие НЭ". По сравнению с предыдущим случаем система знаний изменяется значительно сильнее: в ней появляется 1) новое требование (как и в первом случае), 2) новое отношение "старый способ -> НЭ" 3) новый способ, как правило, это мутация старого способа; 4) новое отношение "новый способ -> новое требование"; 5) новое отношение "новый способ -> нет НЭ". Новизна, однако!

  Конечно, здесь может быть значительно больше разных ситуаций, но если обобщить, то согласен.

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

Re: Тезисы в защиту противоречий в технических системах (3)

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

Quote:

Submitted by priven on вс, 15/06/2014 - 02:22.

Quote:

AlexZ пишет:

В ТРИЗ есть т.н. "Правило № 1" - при анализе ситуации использовать только то, что написано в условии. К ресурсам над-, под- и т.д. систем обратимся позднее. 

Полагаю, что это правило едва ли подходит для решения таких задач, таких, как локализация места возникновения противоречия в системе.

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

Проблема как она дана, http://constructorus.ru/uspex/metod-sinektiki.html

... никто из участников синектической сессии не посвящается в конкретные условия задачи и необходимый результат. Считается, что раннее определение задачи не позволит уйти от привычного хода мыслей и затруднит абстрагирование. Здесь просто представляется проблема, явление или объект.      

Quote:

Submitted by priven on вс, 15/06/2014 - 02:22.

Давайте не будем путать изобретательские задачи с исследовательскими!

Давайте! Но при этом договоримся не путать начало анализа изобретательской ситуации с учетом рекомендаций «Правила № 1», с требованием использовать только те ресурсы, которыми располагает система, и на основе которых требуется объяснить (исследовательская задача) явление, происходящее в системе.

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

Quote:

Submitted by priven on вс, 15/06/2014 - 02:22.

Quote:

AlexZ пишет:

Пирога + бревна-катки - это уже изменение системы КАК ЕСТЬ к системе КАК НАДО, т.е. это переход к новой системе. При таком переходе плохая часть противоречия "пирогу в море не спустить" исчезает. Даже лучше так: для новой системы "пирога + бревна-катки" такого противоречия просто нет.

То есть, простое добавление к системе внешнего элемента устраняет противоречие, локализованное внутри системы?

Тут два момента...

Первый: что такое «локализованное внутри системы противоречие»?

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

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

Т.е. речь идет опять-таки о системе в целом.

В АРИЗ, например, это происходит в 3-й части, http://www.altshuller.ru/triz/ariz85v-3.asp:

Три первые части АРИЗ существенно перестраивают исходную задачу. ... мы одновременно получаем новую задачу - физическую. В дальнейшем надо решать именно эту задачу.

Второй: да, именно простое добавление к системе внешнего элемента устраняет противоречие. Только приемов разрешения ТП, где упоминается добавление чего-то, около десятка. А уж веполей с добавками не счесть. Даже удивительно, что для Вас это новость...

Quote:

Submitted by priven on вс, 15/06/2014 - 02:22.

Интересно, каким образом это противоречие устраняется? В результате какого именно взаимодействия? Где именно это взаимодействие протекает?

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

http://www.heuristic.su/effects/catalog/est/byId/description/274/index.html

Quote:

Submitted by priven on вс, 15/06/2014 - 02:22.

Если в материальном мире - то как ФИЗИЧЕСКИ взаимодействуют бревна в лесу (в принципе подходящие для того, чтобы сделать из них катки, но пока еще даже не спиленные) с пирогой?

От Рис. 1 по ссылке,

http://www.heuristic.su/effects/catalog/est/byId/description/274/index.html, Применение эффекта

переходим к конкретике: пирога на катках.

Сделать катки из деревьев (так, кстати, называются неспиленные бревна в лесу) для Робинзона было бы отдыхом! Ведь Робинзон для изготовления пироги «... срубил кедр, который имел пять футов десять дюймов в поперечнике внизу, у начала ствола, а вверху, на высоте двадцати двух футов, четыре фута одиннадцать дюймов». Т.е. размеры бревна (заготовки для пироги) такие: диаметр у основания примерно 175 см, у вершины - 150 см, а длина - 660 см.

Quote:

Или... у пироги, выдолбленной из дерева, тоже есть интеллект, в котором и локализовано противоречие?.. Буратино отдыхает...

А вот это показывает нарушение Вами «Правила № 1» - про интеллект пироги у Дефо ничего не сказано... И про Буратино тоже ничего...  

Интеллект есть у Робинзона, но почему-то в ситуации с изготовлением пироги Робинзон им не воспользовался. Т.е. не создал в голове образы - система КАК ЕСТЬ (бревно, образ № 1) и система КАК НАДО (пирога в море, образ № 2) - и не попытался перевести, опять-таки в голове,  образ № 1 в образ № 2. А если бы попытался, то увидел бы непреодолимые трудности, или, по-нашему, противоречия.

Робинзон энергично гнал от себя мысли о трудностях, у Дефо это очень ярко описано:

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

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

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

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

Ну, и закономерный результат «недолгодуманья» - возникла система с противоречием: хорошая пирога, но далеко от моря...

Успехов,

AlexZ

Re: Тезисы в защиту противоречий в технических системах (3)

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

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

Александр Владимирович,

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

1) сборка знаний 

2) обнаружение и решение проблем

Если 1-ая стадия уже достаточно технологизирована (причем, уже в разных сферах), то 2-ая стадия осуществляется специальным человеком (ген. конструктором, изобретателем, продакт менеджером и т.п.), по сути, ремесленником. Можно ли 2-ую стадию технологизировать и, соответственно, разделить на более мелкие операции? Ну, так ТРИЗ (точнее, АРИЗ) именно это и позволяет сделать. 

Другой вопрос, нужно ли создавать "большие инструменты" ТРИЗ (и ТРТС), которые будут заменять 1-ю стадию? ИМХО, лучше сделать качественный интефейс между уже существующими для 1-ой стадии технологиями и ТРИЗ. И фокусироваться на дальнейшем развитии самого ТРИЗ. 

Re: Тезисы в защиту противоречий в технических системах (3)

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

Александр Владимирович,

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

1) сборка знаний 

2) обнаружение и решение проблем

Если 1-ая стадия уже достаточно технологизирована (причем, уже в разных сферах), то 2-ая стадия осуществляется специальным человеком (ген. конструктором, изобретателем, продакт менеджером и т.п.), по сути, ремесленником. Можно ли 2-ую стадию технологизировать и, соответственно, разделить на более мелкие операции? Ну, так ТРИЗ (точнее, АРИЗ) именно это и позволяет сделать. 

Другой вопрос, нужно ли создавать "большие инструменты" ТРИЗ (и ТРТС), которые будут заменять 1-ю стадию? ИМХО, лучше сделать качественный интефейс между уже существующими для 1-ой стадии технологиями и ТРИЗ. И фокусироваться на дальнейшем развитии самого ТРИЗ. 

Re: Тезисы в защиту противоречий в технических системах (3)

AndrewK wrote:
Александр Владимирович, я не понял, в чем Вы видите расхождение позиций. Вы рассматриваете технологию, в которой выделяете несколько важных стадий: 1) сборка знаний   2) обнаружение и решение проблем

Если 1-ая стадия уже достаточно технологизирована (причем, уже в разных сферах), то 2-ая стадия осуществляется специальным человеком (ген. конструктором, изобретателем, продакт менеджером и т.п.), по сути, ремесленником. Можно ли 2-ую стадию технологизировать и, соответственно, разделить на более мелкие операции? Ну, так ТРИЗ (точнее, АРИЗ) именно это и позволяет сделать. 

Другой вопрос, нужно ли создавать "большие инструменты" ТРИЗ (и ТРТС), которые будут заменять 1-ю стадию? ИМХО, лучше сделать качественный интефейс между уже существующими для 1-ой стадии технологиями и ТРИЗ. И фокусироваться на дальнейшем развитии самого ТРИЗ. 

В такой версии действительно особых расхождений и нет. Спасибо, Андрей Георгиевич.  По поводу создания "больших" инструментов. Все же здесь придется немного потрудиться, поскольку не очень адаптированы существующие инструменты записи больших масивов для прочтения с нашими целями. Да и не всегда входят разные плечи противоречия в то, что мы привыкли понимать как единый массив. Особенно, если система совсем велика. Но в целом конечно же надо будет пользоваться тем, что уже наработано. возможно чутка модифицируя при необходимости. Или строить специальные адаптеры для обеспечения удобной работы.

Re: Тезисы в защиту противоречий в технических системах (3)

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

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

Согласен. На данный момент существует три направления:
1. Введение инструментов, наработанных в других областях (с модификацией, конечно) в ТРИЗ. Этим успешно занимается GEN3. Фактически они пытаются превратить ТРИЗ в инновационную среду.  Их много и, поэтому, они могут себе позволить такую попытку.
2. Встраивание ТРИЗ в уже существующие инновационные среды, как Lean, 6 Sigma и TOC. С моей точки зрения это менее трудоёмко и... более перспективно. Поэтому этим занимаются все, кому не лень.:)
3. Создание этаких "buffers" между инструментами, наработанными в других областях и инструментами ТРИЗ по принципы вход-выход. Выходы и входы из "buffers" представляют собой входы и входы инструментов из других областей или ТРИЗ инструментов. Это направление я считаю самым перспективным, поскольку это не требует переделки существующих и уже устоявшихся инструментов.

Re: Тезисы в защиту противоречий в технических системах (3)

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

Григорий,

я согласен, что 3 направление является самым перспективным. ИМХО,  2 и 1 вообще мало перспективны. 

В ТРИЗ сильной стороной всегда была и остается технология выявления и решения изобретательских задач (АРИЗ и связанные с ним инструменты). Многие современные технологии проектирования и инноваций как раз слабы именно в этом компоненте. Интеграция будет давать большой плюс обеим интегрируемым технологиям.

Re: Тезисы в защиту противоречий в технических системах (3)

Gregory Frenklach wrote:
На данный момент существует три направления:
1. Введение инструментов, наработанных в других областях (с модификацией, конечно) в ТРИЗ. Этим успешно занимается GEN3. Фактически они пытаются превратить ТРИЗ в инновационную среду.  Их много и, поэтому, они могут себе позволить такую попытку.
2. Встраивание ТРИЗ в уже существующие инновационные среды, как Lean, 6 Sigma и TOC. С моей точки зрения это менее трудоёмко и... более перспективно. Поэтому этим занимаются все, кому не лень.:)
3. Создание этаких "buffers" между инструментами, наработанными в других областях и инструментами ТРИЗ по принципы вход-выход. Выходы и входы из "buffers" представляют собой входы и входы инструментов из других областей или ТРИЗ инструментов. Это направление я считаю самым перспективным, поскольку это не требует переделки существующих и уже устоявшихся инструментов.

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

4. Разработка новых моделей и инструментов решения задач.

Re: Тезисы в защиту противоречий в технических системах (3)

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

Quote:

Submitted by AndrewK on вс, 15/06/2014 - 14:04.

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

Альтшуллер, конечно, был голова, но он не писал так сложно: система знаний, отношение «способ --> требование», подстановка нового требования и т.п. Вот, к примеру, простое описание из статьи «О психологии изобретательского творчества», http://www.altshuller.ru/triz/triz0.asp: «Наличие взаимосвязи между главными составными частями машины приводит к тому, что развитие той или иной части оказывается возможным только до определенного предела - пока не возникнут противоречия между измененной частью машины и оставшимися без изменений другими ее частями».

Quote:

Submitted by AndrewK on вс, 15/06/2014 - 14:04.

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

1) новое требование (как и в первом случае),

2) новое отношение "старый способ --> НЭ"

3) новый способ, как правило, это мутация старого способа;

4) новое отношение "новый способ --> новое требование";

5) новое отношение "новый способ --> нет НЭ".

Новизна, однако!

Куцая новизна... Поскольку для характеристики нового способа разрешения противоречия Вы использовали биологический термин «мутация» (см. п. 3), то чисто формально для другого способа разрешения противоречия можно было бы использовать еще один биологический термин - «кросс(инг)овер» или «гибридизация». То, что «кроссовер» или «гибридизация» - это способы разрешения противоречия прямо говорит их применение для разрешения альтернативных противоречий (см. «Перенос ресурсов», http://www.trizminsk.org/e/212012.htm; «Алгоритм последовательной гибридизации продуктов...», http://www.triz-summit.ru/203864/204997/205066).     

И еще одно направление пропущено: создание принципиально нового способа, в котором выявленный НЭ изначально отсутствует. Мы же так постоянно поступаем, когда у старого способа нет ресурсов изменения.

Итого имеем 2 направления разрешения полученного противоречия и одно направление непоявления (если можно так выразиться) полученного ранее противоречия:

1. Старый способ --> Мутация старого способа --> Новый способ.

2. Старый способ № 1 и Старый способ № 2 --> Объединение плюсов Старых способов №№ 1 и 2 --> Новый способ.

3. Старый способ --> Новый принцип действия --> Новый способ.

А теперь появилась задача: соединить все 3 указанные линии в одну структуру. Ведь смотрИте: на входе везде один объект - Старый способ; на выходе везде один объект - Новый способ. Ну, вот так: Старый способ --> СТРУКТУРА --> Новый способ. Вот это была бы новизна... 

Успехов,

AlexZ

Re: Тезисы в защиту противоречий в технических системах (3)

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

AlexZ wrote:

Quote:

Submitted by AndrewK on вс, 15/06/2014 - 14:04.

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

Альтшуллер, конечно, был голова, но он не писал так сложно: система знаний, отношение «способ --> требование», подстановка нового требования и т.п. Вот, к примеру, простое описание из статьи «О психологии изобретательского творчества», http://www.altshuller.ru/triz/triz0.asp: «Наличие взаимосвязи между главными составными частями машины приводит к тому, что развитие той или иной части оказывается возможным только до определенного предела - пока не возникнут противоречия между измененной частью машины и оставшимися без изменений другими ее частями».

Уважаемый AlexZ (к сожалению, не знаю Вашего имени),

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

 

AlexZ wrote:
Quote:

 

Submitted by AndrewK on вс, 15/06/2014 - 14:04.

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

1) новое требование (как и в первом случае),

2) новое отношение "старый способ --> НЭ"

3) новый способ, как правило, это мутация старого способа;

4) новое отношение "новый способ --> новое требование";

5) новое отношение "новый способ --> нет НЭ".

Новизна, однако!

Куцая новизна... Поскольку для характеристики нового способа разрешения противоречия Вы использовали биологический термин «мутация» (см. п. 3), то чисто формально для другого способа разрешения противоречия можно было бы использовать еще один биологический термин - «кросс(инг)овер» или «гибридизация». То, что «кроссовер» или «гибридизация» - это способы разрешения противоречия прямо говорит их применение для разрешения альтернативных противоречий (см. «Перенос ресурсов», http://www.trizminsk.org/e/212012.htm; «Алгоритм последовательной гибридизации продуктов...», http://www.triz-summit.ru/203864/204997/205066).

Уточнение: речь идет не о способе разрешения противоречия, а об известном решателю способе удовлетворения требования. Именно вокруг него решаель строит проиворечие. Подробнее см. здесь: http://triz.by/articles/refinement-of-the-notion-of-contradiction-in-triz.html

Там же (по ссылке) есть и про противоречие альтернативных систем.

   

AlexZ wrote:

И еще одно направление пропущено: создание принципиально нового способа, в котором выявленный НЭ изначально отсутствует. Мы же так постоянно поступаем, когда у старого способа нет ресурсов изменения.

Итого имеем 2 направления разрешения полученного противоречия и одно направление непоявления (если можно так выразиться) полученного ранее противоречия:

1. Старый способ --> Мутация старого способа --> Новый способ.

2. Старый способ № 1 и Старый способ № 2 --> Объединение плюсов Старых способов №№ 1 и 2 --> Новый способ.

3. Старый способ --> Новый принцип действия --> Новый способ.

А теперь появилась задача: соединить все 3 указанные линии в одну структуру. Ведь смотрИте: на входе везде один объект - Старый способ; на выходе везде один объект - Новый способ. Ну, вот так: Старый способ --> СТРУКТУРА --> Новый способ. Вот это была бы новизна... 

Успехов,

AlexZ

Создание нового способа может происходить в 2-х случаях:

1) Уже на стадии административного противоречия (требование есть, а способ неизвестен, даже гугл не помогает). Этот случай я пока не рассматриваю. 

2) В процессе решения ТП и ФП, когда изменение исходного способа, по сути, приводит к появлению принципиально нового способа (задача о ледоколе, например). У нас здесь появляется единая шкала изменения способа и метрика - степень изменения способа. С одной стороны, эта метрика задается ИКРом (минимальность изменения способа); с другой стороны - этим самым неуловимым переходом количественного изменения в качественное, т.е. старый способ превращаетя в качественно новый способ. 

Тогда 1) и 3) направления - это одно направление, которое распадается на два уже на стадии решения противоречия: либо мутация старого способа, либо качественно новый способ. В общем, как получится. Ну, в природе ведь происходит очень похоже: мутировал очередной ген и "Опа! Новый вид!".

Направление 2) я бы тоже не выделял как-то особенно. Просто не вижу принципиальной разницы между мутацией способа путем скрещивания (альтернативных систем) и мутацией путем точечного воздействия на исходный способ. 

С уважением,

АК

P.S. Хочу обратить Ваше внимание, что, обсуждая противоречия, мы вообще пока обходимся без технических (или еще каких) систем. А? 

Re: Тезисы в защиту противоречий в технических системах (3)

AndrewK wrote:

P.S. Хочу обратить Ваше внимание, что, обсуждая противоречия, мы вообще пока обходимся без технических (или еще каких) систем. А? 

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

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

Re: Тезисы в защиту противоречий в технических системах (3)

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

priven wrote:

AndrewK wrote:

P.S. Хочу обратить Ваше внимание, что, обсуждая противоречия, мы вообще пока обходимся без технических (или еще каких) систем. А? 

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

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

Александр,

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

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

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

Re: Тезисы в защиту противоречий в технических системах (3)

AndrewK wrote:

Решение изобретательской задачи - это определенное изменение способа. А способ, как правило, применяется не только в рассматриваемой системе, но и в других системах. <...> 

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

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

Всё это верно, но вопрос стоял несколько более узко: где именно (в пространстве) возникают противоречия? Согласитесь, что если эти противоречия относятся к нашему знанию, то возникать они могут только там, где возникает знание. Не "информация" (под которой в обиходе чаще всего понимается некий набор данных - они могут в принципе возникать где угодно), а именно "знание". Которое, если верить Википедии, есть "форма существования и систематизации результатов познавательной деятельности человека".

Другими словами, если Вы согласны с тем, что противоречия (в тризовском понимании) возникают в нашем знании, то ответ на вопрос о месте их физического возникновения получается автоматически: они возникают в человеческой голове и нигде более. Версию с буратинами (типа, противоречия возникают в выдолбленной пироге и исчезают от знания [ею самой] того, что есть за ее пределами), надеюсь, всерьез рассматривать мы с Вами не будем.

Однако вопрос, тем не менее, остается, а именно: является ли (всегда ли является) этот человек, в голове которого возникают противоречия, именно решателем изобретательской задачи?

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

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

P.S. Сошлюсь на текст самой статьи:

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

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

Как видим, тот человек, в голове которого может возникнуть понимание противоречия, в принципе не обязан даже пытаться это противоречие решить: от аналитика, устанавливающего некую эмпирическую взаимосвязь (с попыткой объяснить ее причины или без таковой), этого явно не требуется. А... что требуется от человека, который [профессионально] занимается выявлением противоречий в системе?

Re: Тезисы в защиту противоречий в технических системах (3)

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

Quote:

Submitted by AndrewK on вт, 17/06/2014 - 11:29.

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

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

Вот поэтому я и не хотел использовать термин "система". Головоломные обороты речи уводят от сути.

Ну, и в продолжение обсуждения места появления противоречия при изменении "плохая, с проблемами" система --> "хорошая, без проблем" система.

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

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

Т.е. противоречие всегда в системе: (1) в реальной, если бездумно с ней работать, или (2) в образе системы, если работать с этим образом, а результат работы переносить на систему реальную.            

Успехов,

AlexZ   

Re: Тезисы в защиту противоречий в технических системах (3)

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

AlexZ wrote:

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

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

Противоречие, которое вы помещаете в пирогу, на самом деле возникает между разными частями (стадиями ЖЦ) системы. При этом второй части (стадии) пироги физически не существует: пирога ведь так и не попала в море. 

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

AlexZ wrote:

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

Т.е. противоречие всегда в системе: (1) в реальной, если бездумно с ней работать, или (2) в образе системы, если работать с этим образом, а результат работы переносить на систему реальную.            

Для начала давайте разберемся, что такое "плохая" и "хорошая" система (или образ системы)?

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

Если с этой точки зрения посмотреть на пирогу Робинзона, то он сделал прототип для проверки возможности выдолбить "пирогу, пригодную для моря". Чтобы сделать законченную систему, он должен еще разработать способ спуска пироги в море. Например, поэксперементировать со спуском тяжелых бревен. Я как бы опять призываю посмотреть на весь ЖЦ системы, а не только на отдельную стадию. 

С уважением,
АК

Re: Тезисы в защиту противоречий в технических системах (3)

AndrewK wrote:

Александр, 

а почему Вы сделали вывод, что знания возникают и живут именно в голове? 

Андрей, про "живут" я пока что не говорил ни слова :). Жизнь знания - это отдельная тема и, думаю, не для этой ветки.

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

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

Re: Тезисы в защиту противоречий в технических системах (3)

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

priven wrote:

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

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

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

Даже в указанном Вами определении "Зна́ние — форма существования и систематизации результатов познавательной деятельности человека." нет указания на то, что знания возникают в голове.

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

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

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

ИМХО, знания возникают и существуют в знаковой системе, которая не сводится к какой-то конкретной голове. 

С уважением,

АК

Re: Тезисы в защиту противоречий в технических системах (3)

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

Quote:

Submitted by AndrewK on ср, 18/06/2014 - 17:19.

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

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

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

Всё! Дальше Робинзон не заглядывал! Дефо прямо об этом и говорит!

Quote:

Submitted by AndrewK on ср, 18/06/2014 - 17:19.

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

А это Вы домысливаете за Робинзона, это объяснение действий Робинзона с высоты знаний сегодняшнего дня! И этим нарушаете Правило № 1: в начале анализа использовать только то, что дано в условии задачи. А в условии сказано (и не один раз!), что для Робинзона существовала только одна единственная стадия, которая и составляла ВЕСЬ жизненный цикл - сделать пирогу.

Quote:

Submitted by AndrewK on ср, 18/06/2014 - 17:19.

Противоречие, которое вы помещаете в пирогу, на самом деле возникает между разными частями (стадиями ЖЦ) системы.

Вот еще такое соображение по поводу места возникновения противоречия: в Таблице приемов разрешения ТП (http://www.altshuller.ru/triz/technique2.asp) практически все параметры в списке - с № 1 по № 39 - относятся к объекту, и вступают в противоречие с другим параметром объекта: вес подвижного объекта - форма (объекта) и т.д. И далее термин «объект» (http://www.altshuller.ru/triz/technique1.asp) входит в описание самих приемов разрешения ТП, либо в подприемы. Например,

ПРИЕМ 1. ПРИНЦИП ДРОБЛЕНИЯ

а) Разделить объект на независимые части.

б) Выполнить объект разборным.

в) Увеличить степень дробления объекта.

Ну, никуда от объекта (читай - системы), нет деться. И таким объектом в нашем случае является пирога.

Успехов,

AlexZ  

Re: Тезисы в защиту противоречий в технических системах (3)

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

AlexZ wrote:

Quote:

Submitted by AndrewK on ср, 18/06/2014 - 17:19.

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

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

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

Всё! Дальше Робинзон не заглядывал! Дефо прямо об этом и говорит!

В Вашей парадигме противоречия понятие "когнитовное искажение" не имеет смысла. Я же рассматриваю противоречие в парадигме системы знаний. Здесь когнитивное искажение представляет собой ошибку, баг, неправильность в системе знаний. Так что Дефо описал как раз когнитивное искажение в системе знаний Робинзона!

AlexZ wrote:

Quote:

Submitted by AndrewK on ср, 18/06/2014 - 17:19.

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

А это Вы домысливаете за Робинзона, это объяснение действий Робинзона с высоты знаний сегодняшнего дня! И этим нарушаете Правило № 1: в начале анализа использовать только то, что дано в условии задачи. А в условии сказано (и не один раз!), что для Робинзона существовала только одна единственная стадия, которая и составляла ВЕСЬ жизненный цикл - сделать пирогу.

Как интересно переворачивается картинка! Вы отстативаете позицию о наличии противоречия в пироге и при этом оперируете представлениями Робинзона. Я же рассматриваю противоречие в рамках системы знаний  и при этом незнание Робинзона о наличии следующих стадий ЖЦ пироги рассматриваю не как объективную реальность, а как проблел в знаниях Робинзона. Ведь в объективной реальности стадия спуска пироги в море неизбежна! То, что Робинзон об этом не думал, как раз и есть пробел в его знаниях, т.е., когнитивное искажение.  

AlexZ wrote:

Quote:

Submitted by AndrewK on ср, 18/06/2014 - 17:19.

Противоречие, которое вы помещаете в пирогу, на самом деле возникает между разными частями (стадиями ЖЦ) системы.

Вот еще такое соображение по поводу места возникновения противоречия: в Таблице приемов разрешения ТП (http://www.altshuller.ru/triz/technique2.asp) практически все параметры в списке - с № 1 по № 39 - относятся к объекту, и вступают в противоречие с другим параметром объекта: вес подвижного объекта - форма (объекта) и т.д. И далее термин «объект» (http://www.altshuller.ru/triz/technique1.asp) входит в описание самих приемов разрешения ТП, либо в подприемы. Например,

ПРИЕМ 1. ПРИНЦИП ДРОБЛЕНИЯ

а) Разделить объект на независимые части.

б) Выполнить объект разборным.

в) Увеличить степень дробления объекта.

Ну, никуда от объекта (читай - системы), нет деться. И таким объектом в нашем случае является пирога.

Успехов,

AlexZ  

А здесь мы сталкиваемся с наследием ТРИЗ. Таблица приемов, а также сами приемы создавались в то время, когда рассмотрение ЖЦ систем еще не нашло широкого применения в инженерной практике и патентном фонде. Пу сути, ЖЦ начал широко применяться в последней четверти XX века при создании сложных систем.  Это обстоятельство объясняет отсутствие в таблице приемов параметров, связанных с ЖЦ систем. 

С другой стороны, есть приемы, которые прямо "заточены" на процессы ЖЦ системы, например, 5, 10, 11, 12, 15, 19, 21, 23, 25, 27, 34, 36.

 

С уважением,

АК

 

Re: Тезисы в защиту противоречий в технических системах (3)

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

Quote:

Submitted by AndrewK on пт, 20/06/2014 - 01:02.

В Вашей парадигме противоречия понятие "когнитовное искажение" не имеет смысла. Я же рассматриваю противоречие в парадигме системы знаний.

Ну, всё… Мне приписали парадигму. Продолжать дискуссию не имеет смысла: участники, придерживающиеся разных парадигм, никогда не договорятся (Т.Кун о несоизмеримости, несравнимости различных парадигм).

Quote:

Submitted by AndrewK on пт, 20/06/2014 - 01:02.

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

... незнание Робинзона о наличии следующих стадий ЖЦ пироги рассматриваю ... как проблел в знаниях Робинзона. Ведь в объективной реальности стадия спуска пироги в море неизбежна! То, что Робинзон об этом не думал, как раз и есть пробел в его знаниях, т.е., когнитивное искажение

Придираюсь чисто формально...

Ошибка (баг, неправильность) в системе знаний И пробел в знаниях - это ОДНО И ТО ЖЕ?

Если - ДА, то как можно исказить то, чего нет? Т.е. как можно исказить пробел в знаниях?

Если - НЕТ, то тогда пробел в знаниях - это не когнитивное искажение. 

Quote:

Submitted by AndrewK on пт, 20/06/2014 - 01:02.

ЖЦ начал широко применяться в последней четверти XX века при создании сложных систем. Это обстоятельство объясняет отсутствие в таблице приемов параметров, связанных с ЖЦ систем. С другой стороны, есть приемы, которые прямо "заточены" на процессы ЖЦ системы, например, 5, 10, 11, 12, 15, 19, 21, 23, 25, 27, 34, 36.

Ах, тяжелое наследие… Родимые пятна...

А почему тогда в Matrix 2003 (авторы - Mann, Dewulf, Zlotin, Zusman) в списке 48 (!) параметров в названии параметра и/или в пояснении к каждому параметру (сам специально проверил) всё так же упоминаются object or system, несмотря на «... широкое применение подхода к ЖЦ с последней четверти XX века»? Есть еще и Matrix 2010, в которой нет кардинального изменения в виде отказа от термина object or system или изменения в виде включения в рассмотрение термина life (object or system) circle.  

«Приемы, прямо заточненные на ЖЦ...» - это ужЕ решения, как преобразовать исходный объект и/или систему. Т.е. в начале всегда объект (или система), а о пути его (её) преобразования мы узнаём позднее.

Успехов,

AlexZ

Re: Тезисы в защиту противоречий в технических системах (3)

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

AlexZ wrote:

Quote:

Submitted by AndrewK on пт, 20/06/2014 - 01:02.

В Вашей парадигме противоречия понятие "когнитовное искажение" не имеет смысла. Я же рассматриваю противоречие в парадигме системы знаний.

Ну, всё… Мне приписали парадигму. Продолжать дискуссию не имеет смысла: участники, придерживающиеся разных парадигм, никогда не договорятся (Т.Кун о несоизмеримости, несравнимости различных парадигм).

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

AlexZ wrote:

Quote:

Submitted by AndrewK on пт, 20/06/2014 - 01:02.

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

... незнание Робинзона о наличии следующих стадий ЖЦ пироги рассматриваю ... как проблел в знаниях Робинзона. Ведь в объективной реальности стадия спуска пироги в море неизбежна! То, что Робинзон об этом не думал, как раз и есть пробел в его знаниях, т.е., когнитивное искажение

Придираюсь чисто формально...

Ошибка (баг, неправильность) в системе знаний И пробел в знаниях - это ОДНО И ТО ЖЕ?

Если - ДА, то как можно исказить то, чего нет? Т.е. как можно исказить пробел в знаниях?

Если - НЕТ, то тогда пробел в знаниях - это не когнитивное искажение.

Вот когда смените парадигму ;), то тогда мы с Вами и подискутируем на эту интересную тему. А до тех пор нам будет трудно понять друг друга. :)

AlexZ wrote:
 

Quote:

Submitted by AndrewK on пт, 20/06/2014 - 01:02.

ЖЦ начал широко применяться в последней четверти XX века при создании сложных систем. Это обстоятельство объясняет отсутствие в таблице приемов параметров, связанных с ЖЦ систем. С другой стороны, есть приемы, которые прямо "заточены" на процессы ЖЦ системы, например, 5, 10, 11, 12, 15, 19, 21, 23, 25, 27, 34, 36.

Ах, тяжелое наследие… Родимые пятна...

А почему тогда в Matrix 2003 (авторы - Mann, Dewulf, Zlotin, Zusman) в списке 48 (!) параметров в названии параметра и/или в пояснении к каждому параметру (сам специально проверил) всё так же упоминаются object or system, несмотря на «... широкое применение подхода к ЖЦ с последней четверти XX века»? Есть еще и Matrix 2010, в которой нет кардинального изменения в виде отказа от термина object or system или изменения в виде включения в рассмотрение термина life (object or system) circle.  

Этот вопрос Вы лучше адресуйте авторам Matrix 2003. 

AlexZ wrote:

«Приемы, прямо заточненные на ЖЦ...» - это ужЕ решения, как преобразовать исходный объект и/или систему. Т.е. в начале всегда объект (или система), а о пути его (её) преобразования мы узнаём позднее.

Успехов,

AlexZ

Честно говоря, не понял эту мысль. Какое начало Вы имеете ввиду? 

Прием представляет собой не решение, а типовое преобразование способа, порождающего противоречие требований (т.е., ТП). Такое преобразование может затрагивать изменение структуры какого-то объекта, стадий (состояний) ЖЦ объекта, взаимодействий между разными объектами и не только. Позволит ли прием получить решение или нет, зависит от конкретного противоречия. 

С уважением,

АК

Re: Тезисы в защиту противоречий в технических системах (3)

AndrewK wrote:

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

AndrewK wrote:
Позволит ли прием получить решение или нет, зависит от конкретного противоречия.
И от решателя, конечно.

Куда же без него? :)

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

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

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

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

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

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

Re: Тезисы в защиту противоречий в технических системах (3)

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

Пример в общем-то нормальный. Непонятно, что там за неразрешаемое противоречие получается. Что в нем принципиально неустраняемо?

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

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

Не надо путать постановку задачи заказчиком и формулирование противоречия как элемент работы специалиста. Поэтому безразлично, знает ли бизнесмен про скорость вращения Земли на разных широтах. Заказчик просто потребует сделать "здесь" как у них "там".

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

Re: Тезисы в защиту противоречий в технических системах (3)

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

Александр,

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

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

Что касаея вашего пример, то в системной инженерии применяется технология, в которой УЖЕ разделены такие операции, как работа с требованиями стейкхолдеров и работа с системными требованиями. В сложных проектах ее делают разные люди: бизнес-аналитики и системные аналитики. Любой из них может выявлять противоречия. Мой опыт показывает, что они (аналитики) постоянно сталкиваются с противоречиями. Другое дело, что без знания ТРИЗ они не знают, что с противоречиями нужно делать.

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

Re: Тезисы в защиту противоречий в технических системах (3)

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

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

Непонятно, что там за неразрешаемое противоречие получается. Что в нем принципиально неустраняемо?

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

Re: Тезисы в защиту противоречий в технических системах (3)

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

Здесь всего-навсего видно, что строительство космодрома в тундре имеет как достоинства, так и недостатки. А противоречия пока нет.

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

Re: Тезисы в защиту противоречий в технических системах (3)

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

Здесь всего-навсего видно, что строительство космодрома в тундре имеет как достоинства, так и недостатки. А противоречия пока нет.

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

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

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

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

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

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

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

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

Можно это сделать? Можно! Например, погрузить космический корабль вместе с топливом на дирижабль, долететь на нем до экватора и оттуда уже разгоняться. Вполне себе "тризовское" решение, не находите?

Но... будет ли правильным в данной ситуации пытаться устранять именно это противоречие?

Re: Тезисы в защиту противоречий в технических системах (3)

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

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

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

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

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

Александр Кудрявцев wrote:
... при устранении противоречия ... разрывают казавшуюся незыблемой некую рамку или совмещают условия, казавшиеся несовместимыми.

priven wrote:
Вот такую рамку я и предлагал (условно) разорвать: построить космодром в тундре, но чтобы топлива на старте на каждый килограмм полезной нагрузки тратилось столько же, сколько и на экваторе.
Ну и где тут ТП? Андрей Георгиевич выше в обсуждении уже намекал, что максимум, о чем можно говорить в такой конструкции, это административное противоречие - почти не формализованная структура, выражающая какую-то хотелку. "Хочу, чтобы в тундре, но чтобы дешево". Все, на этом социальная миссия заказчика  должна быть закончена. Лучше бы, конечно, чтобы он и про тундру понял, что это след его личной (и неудачной ) попытки решить проблему, которую он тащит с собой в ТЗ, и которая нужна скорее как пример границы рамки - ему нужно не в тундре, а чтобы было легко договариваться об отчуждении земель, еще что-то на уровне требований к проекту. Вот пусть про это и пишет, а не про тундру. А то разворачивание в ходе выполненеия проекта подобным образом свернутых условий отнимает много времени и сил, причем не всегда завершается успешно.

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

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

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

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

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

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

Можно это сделать? Можно! Например, погрузить космический корабль вместе с топливом на дирижабль, долететь на нем до экватора и оттуда уже разгоняться. Вполне себе "тризовское" решение, не находите?

Но... будет ли правильным в данной ситуации пытаться устранять именно это противоречие?

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

Re: Тезисы в защиту противоречий в технических системах (3)

Александр Владимирович, спасибо за подробные ответы на провокационные вопросы. Ибо выясняются детали, которые, быть может, были как бы "между строк", как бы "самоочевидны для профессионалов", но не были вербализованы, очерчены, что ведет к некоторым накладкам и спорам порой ни о чем.

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

Заранее прошу прощения за многословие. Слишком много вопросов возникло при чтении Вашего комментария, простите великодушно, что решил их задать и слегка прокомментировать. 

1. Не вполне пока что согласен с тем, что сформулированное мною противоречие - административное, а не техническое. Как отличить? 

Вот несколько определений:

Техническое противоречие - ситуация, когда улучшение одного эксплуатационного параметра системы приводит к недопустимому ухудшению другого.

(Николай Шпаковский, http://www.trizland.ru/trizba/articles/183/)

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

(Леонид Каплан, http://www.triz-summit.ru/203864/204997/204998/)

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

(автор неизвестен, http://www.inventech.ru/lib/glossary/contradtech/)

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

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

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

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

От этого, собственно говоря, зависит, должен ли тот, кто формулирует противоречие, уметь его решать, - то самое, о чем я спросил с самого начала.

3. Пока еще не очень понятно, можно ли пользоваться понятием противоречия на ранних стадиях проекта.

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

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

4. Не очень понятно, что должен и чего не должен делать заказчик.

А ведь это тоже важно! Ибо, с одной стороны:

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

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

Но не будем о грустном. Вернемся к противоречиям: разве не полезно было бы заказчику сформулировать задачу в виде противоречия именно для того, чтобы разделить понятия, которые в его сознании неразрывно связаны? Более общо: помогает ли формулирование задачи в виде противоречия такую (мнимую) связь увидеть и разорвать в своем вИдении? Если нет - то что этому мешает и как это преодолеть?

5. Продолжая тему про заказчика: как избежать его "бескорыстной помощи" в формулировании задачи?

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

А можно ли помочь задачедателю превратить задачу ("надо переставить винду") в проблему ("хочу, чтобы друг на том конце провода меня увидел, но не получается")? Другими словами, как бедному задачедателю хотя бы до административного противоречия дойти? Какие инструменты использовать?

 

Re: Тезисы в защиту противоречий в технических системах (3)

P.S.  Вопрос № 6. 

Существуют ли какие-либо способы (методы, инструменты), позволяющие избежать вот этой ситуации?

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

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

Re: Тезисы в защиту противоречий в технических системах (3)

priven 1.. Не вполне пока что согласен с тем, что сформулированное мною противоречие - административное, а не техническое. Как отличить? 

Вот несколько определений:   ...

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

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

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

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

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

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

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

От этого, собственно говоря, зависит, должен ли тот, кто формулирует противоречие, уметь его решать, - то самое, о чем я спросил с самого начала.

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

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

3. Пока еще не очень понятно, можно ли пользоваться понятием противоречия на ранних стадиях проекта.

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

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

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

4. Не очень понятно, что должен и чего не должен делать заказчик.

А ведь это тоже важно! Ибо, с одной стороны:

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

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

Но не будем о грустном. Вернемся к противоречиям: разве не полезно было бы заказчику сформулировать задачу в виде противоречия именно для того, чтобы разделить понятия, которые в его сознании неразрывно связаны? Более общо: помогает ли формулирование задачи в виде противоречия такую (мнимую) связь увидеть и разорвать в своем вИдении? Если нет - то что этому мешает и как это преодолеть? 

Скорее всего заказчику тоже нужен для чего-то какой-нибудь инструментарий. Я рассказал, что мне нужно от заказчика, не более.

5. Продолжая тему про заказчика: как избежать его "бескорыстной помощи" в формулировании задачи?

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

А можно ли помочь задачедателю превратить задачу ("надо переставить винду") в проблему ("хочу, чтобы друг на том конце провода меня увидел, но не получается")? Другими словами, как бедному задачедателю хотя бы до административного противоречия дойти? Какие инструменты использовать?

Видимо разговаривать с людями надо. Для этого в проектах есть специальная стадия обсуждения ТЗ перед его подписанием.

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

Re: Тезисы в защиту противоречий в технических системах (3)

P.S.  Вопрос № 6. 

Существуют ли какие-либо способы (методы, инструменты), позволяющие избежать вот этой ситуации?

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

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

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

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

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

Re: Тезисы в защиту противоречий в технических системах (3)

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

2 Александр Привень

Существуют ли какие-либо способы (методы, инструменты), позволяющие избежать вот этой ситуации?

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

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

ИМХО, Вы смешиваете разные уровни задач. Морской старт ракеты относится к задаче 5-го уровня сложности (по классификации Альтшуллера). Для этого типа задач по определению не существует известного способа. В терминах системы знаний это означает, что у разработчиков нет знаний по поводу того, "что пойдет не так". Соответственно, для такой задачи невозможно по определению формулировать противоречие. Решение такого рода задач осуществляется методом проб и ошибок. 

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

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

Re: Тезисы в защиту противоречий в технических системах (3)

AndrewK wrote:
Морской старт ракеты относится к задаче 5-го уровня сложности (по классификации Альтшуллера). Для этого типа задач по определению не существует известного способа. В терминах системы знаний это означает, что у разработчиков нет знаний по поводу того, "что пойдет не так". Соответственно, для такой задачи невозможно по определению формулировать противоречие. Решение такого рода задач осуществляется методом проб и ошибок.
Андрей Георгиевич, здесь я вынужден несколько возразить. Морской старт у нас возник не как задача, а как способ ее решения. Решали-то задачу об удешевлении вывода на орбиту. И в качестве совсем уж пятого уровня я бы даже ее не определил, поскольку к моменту выдачи этой идеи в 92 году, в мире уже был значительный опыт запусков с морских платформ, даже не фиксированных (подводные лодки). Так что внешняя неожиданность задач отсутствовала. (Это к вопросу об оценке уровня, необычности, заарнее понимаемой решабельности  и пр). Хотя признаюсь, путаюсь я в этих уровнях. Там ведь критерии как правило ориентированы на характеристики решения - сколько потребовалось проб, из какой области взяты идеи, насколько сильно в итоге изменилась надсистема...

Re: Тезисы в защиту противоречий в технических системах (3)

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

Александр Владимирович,

я не готов дискутировать по поводу уровня задачи в системе морского старта, так как плохо знаю эту область. В качестве показательного примера задачи 5-го уровня сложности можно считать задачу создания сверхсветового двигателя  (см. http://vpk.name/news/93955_nasa_gotovitsya_k_stroitelstvu_sverhsvetovogo_dvigatelya.html), которая сейчас решется в НАСА. 

 

С уважением,
АК

Re: Тезисы в защиту противоречий в технических системах (3)

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

Итак:

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

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

Теперь приведу мою исходную формулировку:

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

Ваш комментарий:

Здесь всего-навсего видно, что строительство космодрома в тундре имеет как достоинства, так и недостатки. А противоречия пока нет.

Увы - так пока что и не понял, чего в моем "супе" не хватает, с учетом того, что южная альтернатива ("как у американцев в Майами") была сформулирована с самого начала, и именно по отношению к этой альтернативе были сказаны слова "удешевляет" и "удорожает". То есть, два крайних варианта были названы (строительство в тундре и Майами, с понятной и, как мне кажется, самоочевидной экстраполяцией к полюсу и экватору), два взаимозаисимых эффекта - тоже (изменение стоимости проекта и изменение стоимости запусков), и про перемещение места строительства вроде как тоже сказано. А что было не сказано, если противоречия (даже не технического, а вообще - но это мелочь в данном случае) там нет? Что, какое уточнение, превратит отсутствие противоречия в его присутствие? По-моему, Ваша формулировка вполне эквивалентна моей... Какое (конкретно!) отличие в этих формулировках, на Ваш взгляд, делает Ваш вариант правильным, а мой - ошибочным?

Re: Тезисы в защиту противоречий в технических системах (3)

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

2 Александр Привень

вмешаюсь в вашу дискуссию по-поводу конкретного противоречия.

ИМХО, Ваша формулировка противоречия

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

вполне корректна методологически:  

известный способ - сооружение космодрома в тундре - позволяет реализовать требование - удешевить проект - но порождает нежелательный эффект - удорожание запусков.  

Однако уже в 1-ой части АРИЗ появляется и ТП2:

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

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

Re: Тезисы в защиту противоречий в технических системах (3)

Повторюсь. Вот эта формулировка

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

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

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

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

 

Re: Тезисы в защиту противоречий в технических системах (3)

Александр Владимирович, спасибо за методическое разъяснение (и четкий, конкретный ответ на поставленный мной вопрос). Теперь Ваша позиция понятна.

Но я снова сошлюсь на Ваши слова:

Формулировки надо не предполагать, не размазывать их по объему текста, а писать четко и полно.

И, согласившись с ними, вернусь к самому что ни на есть классическо-каноническому описанию процедуры формулирования ТП - к АРИЗу-85В:

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

 

Обратите внимание - даже здесь (не говоря о многих других описаниях ТП) ЧЕТКО НЕ не говорится о том, что именно то самое, что было хорошо, должно обязательно стать плохо, и наоборот. Написано только, что в обоих противоположных состояниях что-то должно быть хорошо и что-то другое - плохо. А также - что "плохое" должно быть следствием полезного действия. Согласитесь, с позиций "формулировки надо... писать четко и полно" это не совсем одно и то же!

Я, естественно, не первый, кто обратил на это внимание. По этому поводу, в частности, В.А.Леняшин с корейскими коллегами написали:

...по нашему мнению в определение ТП, приведенного в тексте АРИЗ-85В [1,2,6] вкралась досадная ошибка, которая существенным образом изменила смысл понятия ТП <далее идет первый из двух абзацев вышецитированного текста АРИЗа>... Стоящее в середине предложения "или" позволяет трактовать Административное противоречие, как техническое, что, к сожалению, достаточно часто и делается при описании решения проблем в статьях последних лет.

Авторы статьи предложили следующее определение ТП:

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

При этом они специально оговорили:

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

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

А можно ли дать все-таки такое определение ТП, чтобы уже из этого определения было понятно, что моя формулировка не содержит в себе ТП? Такое определение, которое бы соответствовало Вашим словам, под которыми, повторюсь, я готов подписаться обеими руками:

Формулировки надо не предполагать, не размазывать их по объему текста, а писать четко и полно.

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

Re: Тезисы в защиту противоречий в технических системах (3)

Александр Ильич, действительно уже поднадоело. Вам достаточно такой точности  - и в добрый путь. Формулировку ТП, которой пользуюсь, уже давал в тексте этой вот переписки. Ставлю точку.

Re: Тезисы в защиту противоречий в технических системах (3)

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

Осталось несколько вопросов...

Quote:

Submitted by AndrewK on вс, 15/06/2014 - 03:04.

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

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

1. Создать приницпиально новую систему знаний (теорию), или

2. Усовершенствовать исходную систему знаний (теорию) или

3. Создать принципиально новую систему знаний (теорию) объединением плюсов исходных систем знаний (теорий).

И совсем не обязательно возникают противоречия на этих 3-х направлениях...

Quote:

Submitted by AndrewK on ср, 18/06/2014 - 06:19.

... давайте разберемся, что такое "плохая" и "хорошая" система (или образ системы)?

В инженерии существует понятие протитип (макет). Он создается при разработке новой системы, чтобы проверить работоспособность использованных решений (способов удовлетворения требований). Можно ли назвать прототип, удовлетворяющий какой-то части требований, "плохой" системой?

Такой прототип нужно назвать «плохой» системой! Если прототип удовлетворяет лишь какой-то части требований, то почему же он хороший? Хороший прототип должен удовлетворять всем требованиям. Так что такое «хорошо», и что такое «плохо»? Где та печка, от которой танцевать?

Quote:

Submitted by Александр Кудрявцев on вс, 22/06/2014 - 07:04.

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

Quote:

Submitted by Александр Кудрявцев on пн, 23/06/2014 - 12:53.

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

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

Конкретное ТП1: Необходимый рост напряжения (плюс) в поперечном сечении колонны  обеспечивается за счет недопустимого роста количества материала (минус).

Типовое ТП1: Улучшение параметра № 11 (напряжение или давление) приводит к ухудшению параметра № 25 (количество вещества).  

Приемы разрешения ТП1:

10. Принцип предварительного исполнения

а) Заранее выполнить требуемое изменение объекта (полностью или хотя бы частично).

б) Заранее расставить объекты так, чтобы они могли вступить в действие с наиболее удобного места и без затрат времени на доставку.

Идея - использовать предварительно напряженные конструкции

14. Принцип сфероидальности

а) Перейти от прямолинейных частей объекта к криволинейным, от плоских поверхностей к сферическим, от частей, выполненных в виде куба или параллелепипеда, к шаровым конструкциям.

б) Использовать ролики, шарики, спирали.

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

Идея - использовать арочные конструкции, купольные конструкции Б.Фуллера, http://ru-domes.livejournal.com, гиперболоид вращения (конструкция башен Шухова)   

36. Применение фазовых переходов

Использовать явления, возникающие при фазовых переходах, например изменение объема, выделение или поглощение тепла и т. д.

Не удается проинтерпретировать... :(

А вот что такое симметричность параметров для исходного ТП1?

Конкретное ТП2 с симметричными параметрами: Необходимое снижение стоимости (это плюс) колонны достигается за счет недопустимого снижения её несущей способности (это минус).

Типовое ТП2: Улучшение параметра № 31 (вредный фактор, генерируемый самим объектом) приводит к ухудшению параметра № 27 (надежность).

Но ведь для решения задачи «Построить колонну для растущей со временем нагрузки, но без резкого роста затрат на материал колонны» совсем нет необходимости рассматривать симметричное ТП2.

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

Успехов,

AlexZ

Re: Тезисы в защиту противоречий в технических системах (3)

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

AlexZ wrote:

Осталось несколько вопросов...

Quote:

Submitted by AndrewK on вс, 15/06/2014 - 03:04.

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

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

1. Создать приницпиально новую систему знаний (теорию), или

2. Усовершенствовать исходную систему знаний (теорию) или

3. Создать принципиально новую систему знаний (теорию) объединением плюсов исходных систем знаний (теорий).

И совсем не обязательно возникают противоречия на этих 3-х направлениях...

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

К слову, еще П.К. Энгельмейер в "Теории творчества" (1910) сформулировал тезис о том, что наука (читай, теории) развивается через изобретения. Он посвятил этому тезису целую главу своей книги.

 

Re: Тезисы в защиту противоречий в технических системах (3)

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

AlexZ wrote:

Quote:

Submitted by AndrewK on ср, 18/06/2014 - 06:19.

... давайте разберемся, что такое "плохая" и "хорошая" система (или образ системы)?

В инженерии существует понятие протитип (макет). Он создается при разработке новой системы, чтобы проверить работоспособность использованных решений (способов удовлетворения требований). Можно ли назвать прототип, удовлетворяющий какой-то части требований, "плохой" системой?

Такой прототип нужно назвать «плохой» системой! Если прототип удовлетворяет лишь какой-то части требований, то почему же он хороший? Хороший прототип должен удовлетворять всем требованиям. Так что такое «хорошо», и что такое «плохо»? Где та печка, от которой танцевать?

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

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

Re: Тезисы в защиту противоречий в технических системах (3)

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

Submitted by AlexZ

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

Конкретное ТП1: Необходимый рост напряжения (плюс) в поперечном сечении колонны  обеспечивается за счет недопустимого роста количества материала (минус).

Типовое ТП1: Улучшение параметра № 11 (напряжение или давление) приводит к ухудшению параметра № 25 (количество вещества).  

 

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

если увеличить диаметр колонны, то (+) увеличивается рабочее напряжение в поперечном сечении колонны, но (-) увеличивается количество материала. 

Для полной формы ТП как раз и действует симметрия, о которой написал Александр Владимирович Кудрявцев. Именно эта же симметрия используется в 1-ой части  АРИЗ-85В для проверки правильности построения противоречия, когда строится ТП1 и ТП2. Противоречие альтернативных систем также обладает этой симметрией. Поэтому-то оно и является противоречием. Если еще точнее, то противоречие должно быть симметричным. 

Смысл симметрии в том, что противоречие - это причинно-следственная связь между изменением способа и порождаемыми при этом изменнении ПЭ и НЭ. В Вашем примере изменение способа = увеличение диаметра колонны; ПЭ = увеличение рабочего напряжения; НЭ = рост расхода материала. Симметрия в данном случае позволяет нам убедиться, что мы имеем дело именно с противоречием. Другими словами, противоположное изменение способа должно поменять ПЭ и НЭ местами. (В случае противоречия альтертаивных систем мы заменяем один способ на другой.) В Вашем примере симметрия будет выглядеть так: если уменьшить диаметр колонны, то (+) уменьшится количество материала, но (-) уменьшится рабочее напряжение. 

Для работы с таблицей приемов используется урезанная форма ТП: способ в явном виде не рассматривается; выбираются параметры, характеризующие ПЭ и НЭ. Кстати, прием должен применяться к способу, упомянутому в полном ТП, так что к нему на стадии решения все равно надо возвращаться.

Submitted by AlexZ

36. Применение фазовых переходов

Использовать явления, возникающие при фазовых переходах, например изменение объема, выделение или поглощение тепла и т. д.

Не удается проинтерпретировать... :(

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

Re: Тезисы в защиту противоречий в технических системах (3)

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

Quote:

Submitted by AndrewK on сб, 28/06/2014 - 07:51.

Submitted by AlexZ

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

Конкретное ТП1: Необходимый рост напряжения (плюс) в поперечном сечении колонны  обеспечивается за счет недопустимого роста количества материала (минус).

Типовое ТП1: Улучшение параметра № 11 (напряжение или давление) приводит к ухудшению параметра № 25 (количество вещества). 

То, что Вы написали в качестве конкретного ТП - это урезанная форма ТП. Если восстановить полную форму ТП, то будет приблизительно так: если увеличить диаметр колонны, то (+) увеличивается рабочее напряжение в поперечном сечении колонны, но (-) увеличивается количество материала.

Э-э-э-э, нет! Вы написали то же самое, что и у меня в ТП1...

Симметричное ТП2 для исходного ТП1 будет вот таким:

Конкретное ТП2: Необходимое снижение стоимости (плюс) колонны достигается за счет недопустимого снижения её несущей способности (минус).

Это видно из схемы ТП1 и ТП2:

Типовое ТП2: Улучшение параметра № 26 (количество вещества) приводит к ухудшению параметра № 11 (напряжение или давление).

Замечание: В моём исходном посте опечатка - для параметра № 26 "Количество вещества" ошибочно напечатал № 25. Но выбор приемов разрешения правильный, именно для параметра № 26.     

Рекомендуемые приемы разрешения ТП2:

10. Принцип предварительного исполнения

36. Применение фазовых переходов

14. Принцип сфероидальности

3. Принцип местного качества

а) Перейти от однородной структуры объекта (или внешней среды, внешнего воздействия) к неоднородной.

Идея - использовать композиты.

б) Разные части объекта должны иметь (выполнять) различные функции.

в) Каждая часть объекта должна находиться в условиях, наиболее благоприятных для ее работы.

Видно, что исходный список приемов разрешения ТП1 (№№ 10, 14 и 36) поменял порядок (№№ 10, 36 и 14) и дополнился приемом № 3, т.е. списки практически совпали. Это означает, что моя формулировка ТП2 правильная.   

Quote:

Submitted by AndrewK on сб, 28/06/2014 - 07:51.

1. Для полной формы ТП как раз и действует симметрия... Именно эта же симметрия используется в 1-й части  АРИЗ-85В для проверки правильности построения противоречий ТП1 и ТП2.

2. Противоречие альтернативных систем также обладает этой симметрией. Поэтому-то оно и является противоречием. Если еще точнее, то противоречие должно быть симметричным.

1. Где в ТРИЗовских материалах говорится о полной форме ТП и об обязательности симметрии ТП1 и ТП2, сформулированных для одной рассматриваемой системы? Где в ТРИЗовских материалах это специально подчеркнуто и эта обязательность доказывается, а не вытекает из интуитивных соображений или не предлагается в виде аксиомы?

Пока ссылки на такой авторитетный материал нет, справедлива гипотеза, что симметричность ТП1 и ТП2 - это частный случай. Ведь из того, что «то, что русскому - здорОво, то немцу - смерть», совсем не следует обратное. Или из того, что «одно (№ 1) лечим, другое (№2) калечим» совсем не следует, что если лечить другое (№ 2), то покалечим одно (№1).    

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

Успехов,

AlexZ

Re: Тезисы в защиту противоречий в технических системах (3)

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

 

Submitted by AlexZ

Э-э-э-э, нет! Вы написали то же самое, что и у меня в ТП1...

Симметричное ТП2 для исходного ТП1 будет вот таким:

Конкретное ТП2: Необходимое снижение стоимости (плюс) колонны достигается за счет недопустимого снижения её несущей способности (минус).

Я написал то, да не совсем то. Точнее, свосем не то. 

Я написал следующую пару:

ТП1: если увеличить диаметр колонны, то (+) увеличивается рабочее напряжение в поперечном сечении колонны, но (-) увеличивается количество материала

ТП2: если уменьшить диаметр колонны, то (-) уменьшается рабочее напряжение в поперечном сечении колонны, но (+) уменьшается количество материала

В моей формулировке в явном виде пристутствует способ, которой я (решатель) хочу изменить: способ = изменение диаметра колонны. 

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

О том, почему важна формулировка ТП в полной форме, я писал в статье (см. http://triz.by/articles/refinement-of-the-notion-of-contradiction-in-triz.html). 

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

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

 

Submitted by AlexZ

1. Где в ТРИЗовских материалах говорится о полной форме ТП и об обязательности симметрии ТП1 и ТП2, сформулированных для одной рассматриваемой системы? Где в ТРИЗовских материалах это специально подчеркнуто и эта обязательность доказывается, а не вытекает из интуитивных соображений или не предлагается в виде аксиомы?

Ну, со строгими формулировками в ТРИЗ беда, да Вы и сами в курсе. При желании у Альтшуллера можно много чего найти, например вот:

Каждое ТП можно изложить двояко: "при улучшении А ухудшается Б" или "при ухудшении А улучшается Б"...

Альтшуллер Г.С., Селюцкий А.Б. Крылья для Икара. Как решать изобретательские задачи. Петрозаводск, Карелия, 1980, с.50. 

 Чем Вам не симметрия? 

 

Submitted by AlexZ

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

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

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

С уважением,

АК

 

Re: Тезисы в защиту противоречий в технических системах (3)

Согласен с Андреем Георгиевичем - формулировка противоречия "про колонну" выполнена пардон, неопрятно. Отсутствие указание на то, что меняют в системе, не дает возможности понять возникающую причинно-следственную связь улучшений и ухудшений. И ФП не из чего строить. Если бы было указание на средство, то можно было бы поставить нормальное ФП. Если: уменьшая толщину колонны, выигрываем в себестоимости (или, например, в обзорности), но проигрываем в надежности, стойкости конструкции, а увеличивая толщину колонны выигрываем в надежности, но проигрываем...

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

Предложенная же конструкция ТП не дает возможности построить ФП логически точно. О нем можно только догадаться. Количество материала стоит рядом с себестоимостью и потому непонятно, то ли его изменение является потребностью клиента, то ли это нечаянно перемешано. Может быть меняем толщину, а может быть материал, или внутреннюю структуру, или вообще нагрузку.

Re: Тезисы в защиту противоречий в технических системах (3)

Уважаемые господа участники спора,

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

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

Позиция исследователя: мне нужно ПОНЯТЬ природу взаимосвязи между наблюдаемыми явлениями, установить некую объективную истину, независимую от меня и моих желаний. А здесь всё несколько сложнее. Ибо выясняется, что выбор конкретного изменяемого параметра - тольщины колонны - весьма мало что меняет по сути. Могу вместо толщины взять высоту - и СНОВА получу ТО ЖЕ САМОЕ противоречие между выходными параметрами, хотя толщина будет оставаться при этом постоянной. Могу попробовать менять материал колонны - и снова получу на выходе ТО ЖЕ САМОЕ соотношение между стоимостью и несущей нагрузкой, хотя и толщина, и высота при этом меняться не будут. То есть, для исследователя в этом случае изменение толщины, высоты, материала - это всего лишь чьи-то личные, субъективные "хотелки", а суть противоречия скрывается в том, что изменение ЛЮБЫМ ИЗВЕСТНЫМ ПУТЕМ (а не какое-то конкретное изменение чего-то одного), ведущее к повышению рабочей нагрузки (+), ведет к удорожанию (-). Какой именно способ изменения выберет при этом решпатель - это его личное дело, не меняющее сути явления. Которое (явление) лежит вовсе не в голове решателя, а "зарыто" где-то в самой системе.

Кто здесь "прав" - инженер или исследователь - вопрос, на мой взгляд, мало осмысленный. Но если человек привык смотреть на мир всегда только с какой-то одной позиции (скажем, инженера), то другая позиция ЕМУ КАЖЕТСЯ какой-то "неправильной", и тогда возникает спор, принципиально не имеющий никакого позитивного решения. Если, конечно, не выйти в новое измерение и понять, что выбор "правильного" ответа определяется позицией и точкой зрения спорящих.

Re: Тезисы в защиту противоречий в технических системах (3)

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

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

 

Re: Тезисы в защиту противоречий в технических системах (3)

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

Quote:

Submitted by Александр Кудрявцев on вс, 29/06/2014 - 02:35.

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

???

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

Quote:

Submitted by Александр Кудрявцев on вс, 29/06/2014 - 02:35.

... формулировка противоречия "про колонну" выполнена, пардон, неопрятно.

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

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

Откуда ТП1: увеличение диаметра колонны приводит к требуемому увеличению несущей способности колонны, но одновременно растет и её стоимость.

Откуда взялось многоточие в конце фразы: «увеличивая толщину колонны выигрываем в надежности, но проигрываем...»? Что тут непонятного? В тексте примера и в ТП1, вытекающем из текста, все параметры указаны.  

Quote:

Submitted by Александр Кудрявцев on вс, 29/06/2014 - 02:35.

ФП не из чего строить. Если бы было указание на средство, то можно было бы поставить нормальное ФП.

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

Даже приемы, по крайней мере, №10 (предварительное исполнение) и №14 (сфероидальность) разрешения типового ТП1 «Улучшение параметра № 11 (напряжение или давление) приводит к ухудшению параметра № 26 (количество вещества)» дают возможность нарисовать портрет ответа: использовать предварительно напряженные конструкции + использовать арочные конструкции, купольные конструкции Б.Фуллера, однополостный гиперболоид вращения (конструкция башен Шухова).

Quote:

Submitted by Александр Кудрявцев on вс, 29/06/2014 - 02:35.

Предложенная конструкция ТП не дает возможности построить ФП логически точно.

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

Или краткая форма ФП: Колонна должна быть толстой (для большой несущей способности) И колонна должна быть тонкой (для малых затрат на материал). Найденные по приемам (№№ 10 и 14) предварительно напряженные конструкции, арочные конструкции, купольные конструкции Б.Фуллера, однополостный гиперболоид вращения (конструкция башен Шухова) точно удовлетворяют обеим половинкам ФП.

Успехов,

AlexZ   

Re: Тезисы в защиту противоречий в технических системах (3)

AlexZ wrote:

???

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

Алексей Николаевич, формулировка замечательная! Но я ориентировался на графическую форму, которую Вы изобразили вот здесь. Продублирую ее.

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

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

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

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

Re: Тезисы в защиту противоречий в технических системах (3)

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

priven wrote:

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

Позиция инженера: мне нужно ИЗМЕНИТЬ объект (колонну), добившись нужного мне результата неким понятным мне путем. ....

Позиция исследователя: мне нужно ПОНЯТЬ природу взаимосвязи между наблюдаемыми явлениями, установить некую объективную истину, независимую от меня и моих желаний.

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

Это вызвано тем, что у решателя может отсутствовать ясное понимание, для чего именно ему надо формулировать ТП-ФП.

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

Другими словами, надо (возможно, и всегда) сначала разделять известное целое  на сумму составляющих, а потом на такой основе строить систему. А не стартовать к ТП на основе того, что дано. Ибо последнее очень напоминает самонадувательство :)

 

Re: Тезисы в защиту противоречий в технических системах (3)

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

Здесь показана т.н. графическая схема конфликта, п. 3 "Сопряженное действие". Не стал делить Инструмент на 2 квадратика, а указал 2 состояния Инструмента:

Теперь о колонне... Придется более подробно рассмотреть несколько циклов увеличения нагрузки и, как следствие, несколько циклов увеличения площади сечения S колонны с целью сохранения ею гарантированной несущей способности. Естественно, что при одной и той же высоте колонны увеличение площади сечения S колонны сопровождается ростом её объема V, т.е. ростом затрат С на материал. 

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

Для определенности примем, что по условиям устойчивости конструкции «Нагрузка - Колонна» рост Sigma возможен до половины величины Sigmaпрочн  предела прочности. Стоимость колонны (один и тот же материал, одна высота) с площадью S1 поперечного сечения - С1.

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

Поскольку потребности растут быстрее, чем возможности (ресурсы), то, в конце концов, стоимость СN+1 колонны с площадью поперечного сечения SN+1 > SN для потребителя становится чрезмерной. Это и есть противоречие ТП1, которое возникает после N-ного цикла изменения колонны:

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

В следующий раз возьму пример "вес неподвижного объекта (№ 2) - "объем неподвижного объекта (№ 7)", чтобы без непонятностей :)

Успехов,

AlexZ

Re: Тезисы в защиту противоречий в технических системах (3)

Андрей,

Не хочу вмешиваться в Вашу дискуссию с Алексом, но замечу, что формулирование конкретного противоречия не всегда имеет целью узнать что-то новое о задаче. См. например: Cavallucci D., Zanni-Merk C., Rousselot F. On contradiction clouds. Proceedings of the TRIZ Future Conference 2008, Procedia Engineering, 2011, No. 9, p. 368–378, http://www.sciencedirect.com/science/article/pii/S1877705811001433. Цитирую:

Our proposal, through this article, addresses the issue of obtaining, representing and selecting the appropriate subset of contradictions among a complete set of contradictions resulting from an initial situation framing within a specific domain.

Другими словами (это НЕ перевод! надеюсь, по-английски читать участники дискуссии умеют) - иногда бывает полезно просто составить "карту" противоречий в системе, безотносительно к тому, являются ли они чем-то новым для решателя или нет.

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

P.S. Можно сколько угодно смотреть свысока на попытки сформулировать противоречие формально, исходя только из определения и, как бы, игнорируя самую суть, типа требования получения нового знания о задаче (чего ни в одном известном мне определении ТП нет). Но если мы так и будем плевать на определения и отталкиваться только от своего личного опыта, то - увы! - навсегда законсервируем ситуацию, при которой ТРИЗ будет person-specific (у каждого тризовца - своя собственная версия ТРИЗ, основанная на своем личном опыте). Что мы сегодня и наблюдаем.

Re: Тезисы в защиту противоречий в технических системах (3)

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

Уважаемые коллеги!

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

Quote:

Submitted by AndrewK on чт, 03/07/2014 - 02:38.

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

"Я плАчу не тебе, а тете Симе" (С) К.Чуковский, От двух до пяти, М., Терра - Книжный клуб, 2001, http://www.chukfamily.ru/Kornei/Prosa/Ot2do5/glava1.htm

Теперь без шуток...

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

Отсюда конкретное противоречие, возникшее после некоторого цикла изменений колонны: как обычно, увеличение диаметра колонны приводит к требуемому увеличению несущей способности колонны (это плюс), но одновременно недопустимо растет её стоимость (это минус). Типовое противоречие, вытекающее из конкретного: необходимое увеличение напряжения (параметр № 11) приводит к недопустимому расходу вещества (параметр № 26). 

Последнее противоречие рекомендуется разрешать приемами №№ 10 (предварительное действие), 14 (сфероидальность) и 36 (фазовые переходы). Приемы 10-й и 14-й удалось проинтерпретировать сразу (см. пост ранее), а вот для 36-го только сейчас появилась такая аналогия из металлургии: сталь Гадфильда, которая при приложении нагрузки упрочняется именно за счет фазового перехода (т.н. дисперсионное твердение). Есть ли подобное свойство у какого-либо бетона? 

Ну, и заодно про противоречие, формулирование которого "не всегда имеет целью узнать что-то новое о задаче". 

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

Успехов,

AlexZ

Re: Тезисы в защиту противоречий в технических системах (3)

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

AlexZ wrote:

Ну, и заодно про противоречие, формулирование которого "не всегда имеет целью узнать что-то новое о задаче". 

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

В такой постановке вполне закономерным выглядят два вопроса:

1. Любое ли ТП развивает (некоторую) систему)?

2. И вообще ли развивает?  В смысле, что именно в существенных признаках (понятия) системы изменяется так, что можно быть в достаточной степени увереннымв  именно (прогрессивном)  развитии?

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

Отсюда конкретное противоречие, возникшее после некоторого цикла изменений колонны: как обычно, увеличение диаметра колонны приводит к требуемому увеличению несущей способности колонны (это плюс), но одновременно недопустимо растет её стоимость (это минус).

Например, что входит в состав системы в примере с колонной? Потребитель и колонна, я так понимаю, это элементы системы. А что является ее связями?

если не новизна, то для чего?

priven wrote:
... замечу, что формулирование конкретного противоречия не всегда имеет целью узнать что-то новое о задаче. См. например: Cavallucci D., Zanni-Merk C., Rousselot F. On contradiction clouds. Proceedings of the TRIZ Future Conference 2008, Procedia Engineering, 2011, No. 9, p. 368–378, http://www.sciencedirect.com/science/article/pii/S1877705811001433. Цитирую:

Our proposal, through this article, addresses the issue of obtaining, representing and selecting the appropriate subset of contradictions among a complete set of contradictions resulting from an initial situation framing within a specific domain.

Другими словами (это НЕ перевод! надеюсь, по-английски читать участники дискуссии умеют) - иногда бывает полезно просто составить "карту" противоречий в системе, безотносительно к тому, являются ли они чем-то новым для решателя или нет.

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

С уважением, Александр 

Re: Тезисы в защиту противоречий в технических системах (3)

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

GIP wrote:

AlexZ wrote:

Ну, и заодно про противоречие, формулирование которого "не всегда имеет целью узнать что-то новое о задаче". 

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

В такой постановке вполне закономерным выглядят два вопроса:

1. Любое ли ТП развивает (некоторую) систему)?

2. И вообще ли развивает?  В смысле, что именно в существенных признаках (понятия) системы изменяется так, что можно быть в достаточной степени увереннымв  именно (прогрессивном)  развитии?

Отличные вопросы! Я бы уточнил что развивает не противоречие, а устранение противоречия. 

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

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

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

Re: Тезисы в защиту противоречий в технических системах (3)

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

Александр Ильич, 

насколько я знаю, Д. Кавалуччи работал с Н. Хоменко и Д. Кучерявым. Они занимались исследованиями по построению карт противоречий в рамках ОТСМ-ТРИЗ. 

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

А без требований задача из изобретательской превращается в исследовательскую: как ведут себя значения параметров объекта. 

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

Re: если не новизна, то для чего?

Ромащук Александр wrote:
Так все же для чего можно формулировать ТП, если речь не идет о получении какой-то новой информации о задаче? Предполагается, что это скорее чисто регулятивный инструмент упорядочивания уже наличной у решателя информации или что-то иное?

Хороший вопрос, Александр Николаевич!

Не буду развивать (или раздувать?) здесь тривиальные мысли, только замечу, что если мы действительно хотим применить системный подход, то, наверное, неплохо бы посмотреть на проблему с разных сторон, не так ли?

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

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

Re: если не новизна, то для чего?

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

priven wrote:

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

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

Александр Ильич, Ваш тезис сводится к метафоре: ХОТЕТЬ надо тоже УМЕТЬ 

Ну, дык никто ж и не спорит :)

Re: если не новизна, то для чего?

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

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

У Вас получается, что прояснение (постановка?) противоречий в рассматриваемой системе приводит к новой информации, но не обязательно в рамках уже поставленной задачи, сколько в рамках самой постановки задачи. Думаю, что с этим навряд ли будут так сильно спорить - тут скорее терминологические недопонимания (терминов "задача", "проблема", "уточнение задачи" и т.п.) Правда, тут возникает содержательный вопрос использования именно цикла ТП-ФП, поскольку для них как подчеркивал Александр Владимирович нужно выбрать - ограничиться! -  параметр изменения системы. Выявление основных противоречий системы скорее через ФА или "причинно-следственной цепочки", или нет? 

С уважением, Александр 

Re: если не новизна, то для чего?

Александр Николаевич,

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

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

Re: если не новизна, то для чего?

Александр Ильич, спасибо, понял!

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

С уважением, Александр

Re: Тезисы в защиту противоречий в технических системах (3)

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

Quote:

Submitted by AndrewK on пт, 04/07/2014 - 13:48.

Если противоречие рассматривать в контексте системы знаний, то развитие системы является побочным эффектом.

Остается только прислушаться к вечному: «Не используй имя системы всуе...».

Уже не в первый раз встречаются слова «система знаний»... Что же такое «система знаний»? Вы не видите явную недосказаность в этих словах?

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

Во-вторых, в какую систему эти знания объединены?

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

Согласны с такими пояснениями? Подожду Ваш ответ...

Quote:

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

Поток слов продолжается...

1.  8 существительных в предложении из 14 слов - это надо постараться.  

2. Известный способ применяется (прикладывается) к чему?

Если ответом будет: известный способ изменения применяется (прикладывается) к системе, то это будет основным эффектом устранения противоречия! Система меняется - вот что главное...  

Quote:

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

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

Это потому, что до сих пор нет ясности о взаимосвязи путей эволюции системы. Создание принципиально новой системы почему-то стоит особняком от пути развития существующей системы. А о создании новой системы объединением двух существующих вообще ни слова...

«Куда ж нам плыть?» (С) А.С.Пушкин

Успехов,

AlexZ

Re: Тезисы в защиту противоречий в технических системах (3)

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

AlexZ wrote:

Quote:

Submitted by AndrewK on пт, 04/07/2014 - 13:48.

Если противоречие рассматривать в контексте системы знаний, то развитие системы является побочным эффектом.

Остается только прислушаться к вечному: «Не используй имя системы всуе...».

Уже не в первый раз встречаются слова «система знаний»... Что же такое «система знаний»? Вы не видите явную недосказаность в этих словах?

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

Во-вторых, в какую систему эти знания объединены?

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

Согласны с такими пояснениями? Подожду Ваш ответ...

Попробую пояснить. 

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

2. Кубики в приведенной выше аналогии имеют разные размеры и цвета. Одни кубики могут легко соединяться друг с другом; другие - нет. 

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

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

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

6. Решение изобретательской задачи - это когда изобретатель нашел, как можно соединить кубики (из п.5). В тот самый момент, когда он нашел способ соединения кубиков, произошли 2 вещи: 1) изобретатель решил задачу, возникшую в технической системе; 2) изобретатель изменил кубики, т.е. систему знаний. Психологи называют такой момент инсайтом (ну, это когда изобретатель бъет себя по лбу и кричит "Эврика!" или что-то в этом роде). 

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

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

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

Re: Тезисы в защиту противоречий в технических системах (3)

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

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

Re: Тезисы в защиту противоречий в технических системах (3)

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

Quote:

Submitted by AndrewK on пн, 07/07/2014 - 13:48.

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

...

6. Решение изобретательской задачи - это когда изобретатель нашел, как можно соединить кубики (из п.5). В тот самый момент, когда он нашел способ соединения кубиков, произошли 2 вещи: 1) изобретатель решил задачу, возникшую в технической системе; 2) изобретатель изменил кубики, т.е. систему знаний. Психологи называют такой момент инсайтом (ну, это когда изобретатель бъет себя по лбу и кричит "Эврика!" или что-то в этом роде). 

На кубиках, говорите... Вы и инженерам так на семинаре объясняете процесс создания и/или совершенствования системы? А блок-схему (диаграмму, граф и т.п.) изобразить, прямо по пунктам №№ 1-6?

Успехов,

AlexZ

Re: Тезисы в защиту противоречий в технических системах (3)

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

AlexZ wrote:

Quote:

Submitted by AndrewK on пн, 07/07/2014 - 13:48.

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

...

6. Решение изобретательской задачи - это когда изобретатель нашел, как можно соединить кубики (из п.5). В тот самый момент, когда он нашел способ соединения кубиков, произошли 2 вещи: 1) изобретатель решил задачу, возникшую в технической системе; 2) изобретатель изменил кубики, т.е. систему знаний. Психологи называют такой момент инсайтом (ну, это когда изобретатель бъет себя по лбу и кричит "Эврика!" или что-то в этом роде). 

На кубиках, говорите... Вы и инженерам так на семинаре объясняете процесс создания и/или совершенствования системы? А блок-схему (диаграмму, граф и т.п.) изобразить, прямо по пунктам №№ 1-6?

Успехов,

AlexZ

Спасибо, AlexZ.

Subscribe to Comments for "Тезисы в защиту противоречий в технических системах (3)"