ТРИЗ в бизнес-анализе

Теория решения изобретательских задач как инструмент для бизнес-анализа

Об уточнении понятия противоречия в ТРИЗ

4.06.2014
New_preview_12-1_new

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

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

Сегодня уже предпринимаются попытки, например, в [1], провести такую ревизию понятий. Однако пока не решены некоторые проблемы, в том числе,

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

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

Требования и ограничения

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

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

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

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

Особый вид требований в системной инженерии – это ограничения, которым должна удовлетворять система. Широко применяемое в ТРИЗ понятие «нежелательный эффект» полностью соответствует понятию «ограничение».

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

В приведенном выше примере можно выделить следующие требования стейкхолдеров:

  1. Руководство компании «К» хочет, чтобы в системе документооборота устанавливались сроки и маршруты обработки каждого документа.
  2. Руководство контрагента «А» хочет, чтобы документы компании «К» обрабатывались без нормативов.

Системные требования:
(СТ1) Для каждого вида документа и каждого вида обработки в подразделениях компании «К» должны быть установлены сроки выполнения.

Системное ограничение:
(СО1) Для документов, обрабатываемы контрагентами «А», сроки выполнения обработки документов у контрагента неизвестны.

Общая схема противоречий

Административное противоречие

Известно следующее определение административного противоречия (АП): «нужно что-то сделать, а как сделать – неизвестно…» [4].

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

Схема административного противоречия

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

Например, в приведенном выше примере требование СТ1 (для каждого вида документа и каждого вида обработки в подразделениях компании «К» должны быть установлены сроки выполнения) не может быть реализовано, для случая, когда документ обрабатывается контрагентом. В этом случае имеет место ограничение СО1 (для документов, обрабатываемы контрагентами «А», сроки выполнения обработки документов у контрагента неизвестны).

В рассматриваемом примере административное противоречие может быть определено следующим образом:

Как реализовать требование СТ2 (в системе документооборота нужно установить в нормативный срок обработки документа у контрагента «А»)?

Техническое противоречие

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

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

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

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

Например, в системе документооборота ТП1 может быть сформулировано так, как указано выше, а ТП2 – следующим образом:
Если
Не согласовать нормативные сроки обработки документов с контрагентом «А»,
То
em>(+) мы обеспечиваем реализацию требования стейкхолдера (руководство контрагента «А» хочет, чтобы документы компании «К» обрабатывались без нормативов).
Но
(-) мы не сможем реализовать требование СТ1 (в системе документооборота нужно установить в нормативный срок обработки документа у контрагента «А»).

Противоречие альтернативных систем

Понятие альтернативного технического противоречия (АТП) или противоречия альтернативных систем предложено В. Герасимовым и С. Литвиным в методе объединения альтернативных систем в надсистему, описанном в [7]. В соответствии с этим методом пара технических противоречий формулируется в соответствии со следующим шаблоном [7]:

АТП1: Если система реализована в виде базовой системы, то ее достоинством является (указать), но при этом имеется недостаток (указать).
АТП2: Если система реализована в виде (указать название альтернативной системы), то ее достоинством является (указать устраненный недостаток базовой системы), но при этом имеется недостаток (указать).

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

Альтернативное техническое противоречие

Физическое противоречие

В ТРИЗ физическое противоречие (ФП) определено следующим образом:
… часть рассматриваемой системы должна находиться в таком-то физическом состоянии, чтобы удовлетворять одному требованию задачи, и должна находиться в противоположном состоянии, чтобы удовлетворять другому требованию задачи [8].

М. Рубин и В. Кияев в [1] предложили новое наименование для ФП – противоречие свойств (ПС). Их определение выглядит так:
формулировка противоположного состояния того или иного свойства одного элемента системы, необходимое для реализации противоположенных требований к системе.

Другими словами, для определения ФП (ПС) необходимо выделить элемент, который должен обладать противоположными свойствами, чтобы удовлетворить противоречивым требованиям. Очевидно, что объект с противоположными свойствами – это элемент, который входит в состав способа, который был выбран в АП и рассматривался в ТП.

В рамках предлагаемой схемы ФП (ПС) может быть представлено следующим образом:

Физическое противоречие

Например, в противоречии, сформулированном для системы документооборота, мы рассматриваем способ (согласовать нормативные сроки обработки документов с контрагентом «А»). Объект, который лежит в основе противоречия – это срок обработки документа у контрагента «А».

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

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

В случае АТП элемент является частью способа, реализованного в базовой системе.

Заключение

Предлагаемая общая схема противоречия отличается от существующих в ТРИЗ определений тем, что для описания противоречия используются понятия «требование» и «способ реализации требований».

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

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

Литература

  1. Рубин М.С., Кияев В.И. Основы ТРИЗ и инновации. Применение ТРИЗ в программных и информационных системах: Учебное пособие. 2013.
  2. ISO/IEC 15288:2002. System Engineering. System Life-Cycle Processes.
  3. Software Engineering Body of Knowledge, IEEE, 2004
  4. Альтшуллер Г.С. Найти идею, Введение в теорию решения изобретательских задач, Петрозаводск, Скандинавия, 2003
  5. Альтшуллер Г.С. АРИЗ – значит победа. В сб. Правила игры без правил / Сост.: А.Б. Селюцкий, Петрозаводск, Карелия, 1989.
  6. Альтшуллер Г.С. Алгоритм решения изобретательских задач АРИЗ-85В. 1985.
  7. Герасимов В.М., Литвин С.С. Зачем технике плюрализм? Развитие альтернативных технических систем путем их объединения в надсистему. Ленинград. Журнал ТРИЗ, №1, 1990.
  8. Альтшуллер Г.С., Селюцкий А.Б. Крылья для Икара. Как решать изобретательские задачи. Петрозаводск, Карелия, 1980.

Комментарии:  16

Добавить комментарий

Подписаться без комментирования

  1. Игорь Девойно says:

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

    • Андрей Курьян says:

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

      P.S. Противоположные состояния объекта, противоположные значения свойства очень часто встречаются у разных авторов материалов ТРИЗ. Психологическая инерция, однако. 😉

  2. Алла Нестеренко says:

    Здравствуйте, про противоречия – всегда интересно :-)
    1) вот хотелось бы понять, чем по сути отличается утверждение “согласование сроков с контрагентом” от утверждения “срок установлен”. Просто мне кажется, что по сути оно ничем не отличается, а это означает, что в данной конкретной задаче Вы переназвали одно и то же разными именами. Возможно, я просто не поняла суть проблемы, тогда уточните, пожалуйста, в чем разница.
    2) Если углубиться в историю, в старой книжке Г.И. Иванова “Формулы творчества…” есть формулировки АП-ТП-ФП, которым я учила своих школьников. АП: “Знаю, что, но не знаю как” (т.е., по моему разумению, это как раз означает “не имею способа”), ТП – “Знаю как, но от этого еще хуже” (т.е. у меня есть способ, но он вместе с положительным дает отрицательный эффект) и ФП – “Знаю, что и как, но не знаю, каким образом” (в последнем случае могу ошибаться, но не о нем сейчас речь). Действительно, довольно много задач (и нетехнических, в том числе) берется в такой раскладке. То есть модель вполне рабочая. Вопрос только в том, не сужает ли она исходную модель АРИЗ. Мне кажется, что сужает. И АП не всегда – отсутствие способа, иногда это, как раз, плохой способ, а иногда удобнее сразу описывать его через признаки. И с ТП, мне кажется, та же история. Лично я даже в “детской” ТРИЗ все равно, когда требуется глубокий анализ упираюсь в модель Хоменко, описанную через имена и значения признаков. На мой взгляд, она не сужает область применения классики и дает более глубокий инструмент для работы. Очень может быть, что есть большие классы задач, для которых Ваш способ – самое то. Но тогда, мне кажется, надо описать эти классы. Я пока не увидела тут модели, которая позволила бы это сделать.
    3) Относительно формулировки ФП согласна с Игорем, опять же – в ОТСМ эта формулировка именно так и выглядит. К сожалению, я еще не читала учебник Рубина, но для программистов, возможно, более естественный язык – свойство и значение свойства и посчитать другое за противоположное в определенных условиях тоже вполне естественно, так что, возможно, Рубин это и имел в виду :-).

    • Андрей Курьян says:

      Алла, здравствуйте!

      1) “согласование сроков с контрагентом” предполагает выполнение определенного процесса. Это может быть звонок, переписка и т.д. “Срок установлен” – это уже имеющийся результат. Этот результат м.б. получен либо в следствие выполнения процесса, либо каким-то другим способом.
      Собственно, упомянутое противоречие разрешается через “установку срока” другим способом, например, сбором и обработкой статистики о сроках обработки документов данным контрагентом. Решение – это инфоробот, который с заданной периодичностью вычисляет срок обработки документа контрагентом. Если контрагент новый, то для него устанавливает “среднестатистический” для данного типа контрагентов срок, а затем, по мере накопления истории, инфоробот корректирует установленный срок.

      По остальным пунктам отвечу в следующих постах.

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

    • Продолжение: п.2.2)

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

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

    • По п.3 согласен. Я об этом уже написал в ответе Игорю.

      Посмотрите также Открытое письмо (предыдущая статья) http://triz.by/articles/open-letter-about-the-development-triz-3.html. Там я немного затронул тему различия способа и системы.

  3. Роман says:

    >> (СО1) Для документов, обрабатываемы контрагентами «А», сроки выполнения обработки документов у контрагента неизвестны.

    Почему это системное ограничение? Возможно, это бизнес-ограничение?

    • Роман,
      “срок обработки документа” является элементом системы. Соответственно, речь идет о системном требовании. Смотри, как мы его получаем.
      У нас есть требование стейкхолдера “А” “обрабатывать документы без норматива”. Когда мы отображаем это требование в нашу систему, то получим системное ограничение СО1.

  4. Антон Иванов says:

    Имхо, Н. Хоменко, Э. Курги, Б. Голдовский многое прояснили в противоречиях.

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

  5. Андрей И. says:

    отличный пример стоящего материала. благо, автор просто гений.

  6. С.Н. Семенов says:

    Уважаемый автор! Понятие “противоречие свойств” в связи с системой противоречий ТРИЗ не является “новым” в 2013 (!?) году . Оно , а еще и “противоречие функций”(после “технического” понятого как ” противоречие требований” было впервые (?) представлено на известной в ТРИЗовском сообществе конференции в Новосибирске с участием Г.С. Альтшуллера, а затем использовалось
    В преподавании и публикациях
    в Уфе. А первая: Семенов С.Н. Основы философской культуры в курсе обучения методам научно-технического творчества // Методология и методы технического творчества: Тезисы докладов и сообщений к научно-практической конференции 30 июня – 2 июля 1984г. – Новосибирск:СО АН СССР, 1984, С.11.

    ,

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

  7. Ludozhka says:

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

  8. Валерий Гальетов says:

    “Внутри технической системы” нет никаких конфликтов и “технических противоречий”. Еще Волюслав Владимирович Митрофанов вопрошал: “Вот стул! Какое в нем противоречие?”
    И если ТП “конфликт внутри технической системы”, то как может ЭТОТ конфликт “заменяться физическим”?
    Противоречие – это понятие, позволяющее построить определенный интеллектуальный процесс по выработке решения. Если проще – это средство для выработки решения определенным способом.
    И не более того.
    Всего разумного!