Хорошая постановка задачи

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

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

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

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

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

Всего доброго,

 

Форумы: 

Re: Хорошая постановка задачи

Приветствую, Александр Владимирович!

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

Предпроектные стадии работ по обследованию объекта модернизации и выработке концепции позволяют сформулировать задание в виде ТЗ или обоснованно отказаться от решения задачи. ТЗ, конечно, более строгий документ, чем формулировка ИЗ, однако, только в нём реально увидеть накладываемые количественные ограничения и разносторонние требования к результату.

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

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

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

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

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

Re: Хорошая постановка задачи

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

Где та мера исходной неопределенности, которую еще можно допустить?

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

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

Re: Хорошая постановка задачи

Сагадеев Александр wrote:
Приветствую, Александр Владимирович!

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

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

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

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

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

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

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


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

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

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

Re: Хорошая постановка задачи

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

Re: Хорошая постановка задачи

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

Александр Марсович, прошу, поправьте, этот текст.

Чуть позже, с Вашего позволения.

Сагадеев Александр wrote:
Предпроектные стадии работ по обследованию объекта модернизации и выработке концепции позволяют сформулировать задание в виде ТЗ ...

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

Эту работу, как я понимаю, должен делать заказчик?

Нет, подрядчик.

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

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

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

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

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

Мне не странно. Просто, объём работ будет тоже невелик. На относительно простых задачах, зачастую, решение приходит на этапе выработки концепции.

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

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

Получается, что это была работа по выработке концепции и составлению части ТЗ. От концепции (в терминах ГСА -- «найденной идеи») до её воплощения ещё далеко. Часто, изобретатели считают, что это и не их дело вовсе. Идея передаётся далее инженерам, научным сотрудникам, конструкторам для её практической реализации.

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

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

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

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

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

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

Re: Хорошая постановка задачи

Александр Кудрявцев wrote:
Но нам ведь никто не мешает формулировать задачи? Во всяком случае, Альтшуллеровское "как быть?" это допускает.

Оно так, конечно, только меня всегда смущает два "но":
1. Проблема в ситуации так как оно заявляется и так как оно есть на самом деле - две большие разницы (говоря медицинским языком, заявляется симптом, но не причина).
2. Есть "решение для заказчика" и "наилучшее возможное решение", которые не только не совпадают, но и даже "наилучшее" заказчику категорически нежелательно...

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

Re: Хорошая постановка задачи

Касательно подготовки к формулированию задачи.

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

Первый предпроектный этап.

  1. характеристика объекта и результатов его функционирования;
  2. описание существующей технической системы;
  3. описание недостатков существующей технической системы;
  4. обоснование необходимости совершенствования технической системы;
  5. цели, критерии и ограничения создания ТС;
  6. функции и задачи создаваемой (модернизируемой) ТС;
  7. выводы и предложения.

Следует обратить внимание на пункт из состава работ: «Формирование требований пользователя к ТС». Это не требования заказчика. Для трейлера, это будут требования водителя или требования автопредприятия, которое будет использовать трейлер.

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

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

Второй предпроектный этап.

  1. описание результатов изучения объекта модернизации;
  2. описание и оценка преимуществ и недостатков разработанных альтернативных вариантов концепции создания (модернизации) ТС;
  3. сопоставительный анализ требований пользователя к ТС и вариантов концепции ТС на предмет удовлетворения требованиям пользователя;
  4. обоснование выбора оптимального варианта концепции и описание предлагаемой ТС;
  5. ожидаемые результаты и эффективность реализации выбранного варианта концепции ТС;
  6. ориентировочный план реализации выбранного варианта концепции ТС;
  7. необходимые затраты ресурсов на разработку, ввод в действие и обеспечение функционирования;
  8. требования, гарантирующие качество ТС;
  9. условия приёмки системы.

Обратите внимание, речь опять идёт о требованиях пользователя, а не заказчика.

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

Результатом является генеральная идея (концепция) модернизации. Она так же согласуется с заказчиком. Так же на этом этапе и заказчик и подрядчик определяют ограничения по материально-техническим ресурсам, затратам времени. На основании всего этого формируется ТЗ.

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

Для разного уровня задач, естественно, такая система проведения работ должна быть отмасштабирована. Ни чего страшно (хотя и непривычно), если отчёт о НИР содержит всего одну страничку и является всего лишь патентным обзором.

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

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

Re: Хорошая постановка задачи

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

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

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

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

Во-вторых, зачем он мне для решения тех опосредованных практических проблемных ситуаций, которые рассматриваются на форуме? Заказчика, который оплатит мне существенные временные затраты, нет. Соответственно, и нет фактора обязательности участия в поиске решения.

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

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

К слову, а такое "хорошая" постановка задачи? И чем она отличается от "нехорошей" постановки?

Если это процесс поиска задачи, то какой ее вид у нас должен получиться после его окончания: техническая задача, из которой получается задача изобретательская, или сразу задача изобретательская?

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

ДВОЕНИЕ --

путь к единению

Re: Хорошая постановка задачи

GIP wrote:

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

Геннадий Иванович, не придирайтесь.

GIP wrote:

Следует ли на его основе, перестраивать индивидуальный стиль мышления?
Лично мне этого делать не хочется.

Конечно, это личное дело каждого. Можно, вообще без всякого стиля и методов.

GIP wrote:

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

Не понял в чём сложность и при чём тут теория автоматов.
Не понял, о каких программах Вы говорите.

GIP wrote:

Во-вторых, зачем он мне для решения тех опосредованных практических проблемных ситуаций, которые рассматриваются на форуме? Заказчика, который оплатит мне существенные временные затраты, нет. Соответственно, и нет фактора обязательности участия в поиске решения.

А это не Вам он нужен, он нужен постановщику задачи.

GIP wrote:

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

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

GIP wrote:

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

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

GIP wrote:

К слову, а такое "хорошая" постановка задачи? И чем она отличается от "нехорошей" постановки?

Собственно, это и обсуждаем.

GIP wrote:

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

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

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

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

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

Re: Хорошая постановка задачи

Изображение пользователя Сергей Малкин.

Мы используем следующую модель:
Этап 1: Анализ Ситуации
Цель первого этапа перейти от расплывчатой ситуации к четким целям.
Situation
Проблемосодержащая система
Система (назовите систему)
для (укажите назначение и потребителя)
включающая (назовите подсистемы)
производит (опишите выход)
используя (укажите вход)
путем (опишите процесс)

Шаг 1. Выявление Проблемы
Проблема в том, что (опишите проблему)
при условии (укажите причины)
приводит к тому, что (опишите последствия)

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

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

Фаза 2: Поиск Идей
Цель этого этапа найти максимальное количество идей за счет использования изобретательских приемов
Шаг 3. Определение направлений
Цель этого шага выяснить изменение каких функций позволит решить задачу.

Что нужно увеличить? (составьте список полезных функций)

Что нужно уменьшить? (составьте список вредных функций)

Какие противоречия возникают при использовании известных способов? (составьте список)
«противоречивая функция» обеспечивает «полезную функцию» но взывает «вредную функцию».

Шаг 4. Генерация идей
Цель этого шага применить Изобретательские Приемы для генерации идей.

Сергей Малкин
www.pretiumllc.com

Re: Хорошая постановка задачи

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

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

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

А чем плоха концепция постановки-решения проблем Иванова Г.И., изложенная в статье "Какой алгоритм нужен инженеру?" и в частности Алгоритм решения инженерных проблем 2009?

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

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

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

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

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

С уважением.

Re: Хорошая постановка задачи

Изображение пользователя Сергей Малкин.

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

В зависимости от того, какой сервис оказывается, такие задачи и формулируются. Хотя алгоритм и шаблоны остаются неизменными, меняется характер дополнительных вопросов к экспертам. Цель этого опроса - свести уникальную ситуацию к типовым формулировкам, для которых у нас организована Система Изобретательских Приемов, подталкивающая самих экспертов увидеть скрытые ресурсы изменения/воздействия на ситуацию.
Если клиернт заказал Увеличение Интеллектуальной Собственности, то необходимо сделать расширение его патентеой базы (как за счет создания своих патентов, так и за счет покупки ключевых перспективных патентов).
Если речь идет об Улучшении Бизнес-процессов, то скорее всего мы попытаемся поменьше трогать производство и патенты (справедливости ради отмечу, что бизнес-процес в Америке сейчас тоже объект патентования, но это такой геморой, что предпочитают не связываться)
Как сказал президент одной фирмы, выслушав презентацию по ТРИЗ: Всё это прекрасно, но меня интересуют только 2 вещи ROI и ROE (кто не знает - это возврат на инвест и возврат на капиталл) за которые меня или награждают, или наказывают. Все остальное - ваши проблемы.
Если говорить проще, бизнес - это процесс делания денег. В хорошей постановке задачи нужно правильно связать деньги с задачей. В этом контексте я всегда задаю клиенту вопрос: "Что случиться если проблему не решать? Объясните в денежном выражении."

Сергей Малкин
www.pretiumllc.com

Subscribe to Comments for "Хорошая постановка задачи"