Идеи совместного применения ТРИЗ, СМД и ТОС для решения задач бизнеса. Часть 2.

Прошло некоторое время с момента выхода моей статьи «Идеи совместного применения ТРИЗ и СМД для решения задач бизнеса». Статья не осталась незамеченной и я получил ряд комментариев от сообщества. Ниже привожу вопросы и комментарии, постараюсь дать на них максимально развернутый ответ.

 

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

1. Вопрос: Хотелось бы большего раскрытия понятий, спрятанных во втором абзаце. Совершенно необходимо ввести понятие «задачи бизнеса», Оно играет роль определенного водораздела и как бы синонимично задачам социальным, что в реальности вызывает много вопросов. С бизнес задачами как задачами повышения прибыльности ТРИЗовцы познакомились в середине восьмидесятых, решая задачи ФСА. Это позволило в поздние восьмидесятые реально решать задачи, которые ставились бизнесменами (например, Герасимов — Литвин, задача о повышении эффективности сбора торфа). И именно они начинали, принесли первый опыт.

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

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

 

2. Вопрос: Будет ли рассмотрена особенность  подхода такого инструмента как теория ограничений? Внесено ли что-то этим подходом по Вашему мнению?

 А.К.: ТОС там есть, хотя и не упоминается. Разверну. ТОС обозначена в схеме 4, пункты 3 и 4.

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

 

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

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

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

 

4. Вопрос. Cамо это понятие (ТС) не сводится к «железкам», чисто инженерным направлениям. Техника — это любой инструмент, которым человек изменяет окружающую среду. В этом смысле задачи менеджмента, принятие политических решений — тоже технические задачи. И к ним применима ТРИЗ. Другое дело, что в этих случаях для точно применения известных инструментов (или создания новых) нужна новая информационная база.

Ответ участника дискуссии (не А.К.): Задачи менеджмента и маркетинга это не технические задачи. Не надо жонглировать понятиями и искажать смыслы. Это задачи административные (организационные).

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

 

Что такое задачи бизнеса?

В предыдущей статье я писал о том, что такое задачи бизнеса. В ходе дискуссии выяснилось, что в 80-хх годах прошлого века в ТРИЗ возникла промежуточная ступенька к задачам бизнеса – функционально-стоимостной анализ, где ТРИЗовцы впервые в своей практике столкнулись с необходимостью держать в фокусе экономическую эффективность. Вообще, в 80-х годах активно  предпринимались попытки оценивать экономическую эффективность в инженерной среде, так, например, вслед за работами Тейлора в США в нашей стране было введено понятие экономической стойкости режущего инструмента, за что, правда, авторы получили хороший разнос по партийной линии. Однако постепенно тема начала приживаться, так как от экономических расчетов, как ни крути – не отвертишься. В конце концов, любая эффективность измеряется экономическими показателями. Жаль, что партийное руководство СССР это слишком поздно осознало. Но что сделано – то сделано. Таким образом, вопрос экономической эффективности на рубеже перехода СССР к рыночным отношениям все чаще всплывал на повестке дня и инженерам пришлось как следует «подружиться» с экономическими показателями. Чистое творчество обходилось все дороже стремительно сжимающейся казне.

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

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

Итак, бизнес-задачи – это задачи из области организационно-управленческого проектирования.

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

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

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

 

Рис. 1. Понятия технических задач и бизнес-задач.

 

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

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

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

 

Инструменты ТРИЗ, ТОС и СМД для применения в бизнес-задачах.

Для удобства я приведу здесь схему, которую использовал в статье «Идеи совместного применения ТРИЗ и СМД для решения задач бизнеса». Это структурная схема работы над задачами бизнеса, от нее мы оттолкнемся и двинемся дальше.

 

 Рис. 2. Алгоритм работы над бизнес-задачей с совместным применением СМД-методологии и ТРИЗ.

 

Как известно, ТРИЗ – это не единственная система работы с многопараметральными и «нежесткими» задачами, такими, как задачи организационно-управленческого проектирования. Интерес представляет теория ограничения систем, разработанная И. Голдраттом и усовершенствованная его последователями.

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

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

В рамках данной статьи мы не можем подробно рассказать о всех нюансах проведения сит. анализа и схематизации,  подробнее его методика описана в работах Г.П. Щедровицкого, содержится в докладах СМД-методологов, например А.Г. Реуса. Коротко: ситуационный анализ является отражением второго определения системы, к которому мы еще с вами вернемся, и оперирует следующими основными категориями: слои, группы, процессы, связи, функции, места, материал, свойства материала.

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

 

Рис. 3. Пример схемы, полученной в результате проведения ситуационного анализа.

 

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

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

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

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

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

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

 

Рис. 4. Концепция ТОС, представленная в виде диаграммы U-shape. Рисунок из книги О. Коуэна и Е. Федурко «Основы теории ограничений».

 

Левая, нисходящая часть диаграммы, говорит о применении инструментов анализа, предназначенных для первичной обработки задачи. Пивот – это поворотная точка, формулирование и разрешение противоречия. Далее вступает в силу правая, восходящая, часть диаграммы, представленная инструментами синтеза решения бизнес-задачи. Для того, чтобы продемонстрировать основной арсенал инструментов ТОС, лежащих на «аналитической» и «синтетической» ветвях, приведу полную версию диаграммы  U-shape:

 

Рис. 5. Концепция ТОС, представленная в виде диаграммы U-shape с нанесенными на диаграмму инструментами анализа и синтеза. Рисунок из книги О. Коуэна и Е. Федурко «Основы теории ограничений».

 

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

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

Хорошо, а что говорит опыт применения методологии синтеза в консалтинговых проектах? Лично я склоняюсь в сторону «Системной сборки», разработанной Г. П. Щедровицким и его последователями. Она наглядна, позволяет активно использовать групповую динамику при поиске решения и менее утомительна для применения в группе специалистов, не обученных тонкостям методологии, нежели «Дерево текущей реальности». Об этом говорит мой опыт, но я никому не навязываю своего мнения.

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

Как известно, модель ТП в ТРИЗ выглядит следующим образом:

 

Рис. 6. Графическая модель технического противоречия, принятая в ТРИЗ.

 

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

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

 

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

 

В ТОС модель противоречия (Туча) похожа на модель ТП, но имеет свои отличительные особенности:

 

 

Рис. 8. Графическая модель Тучи – противоречия в версии ТОС.

 

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

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

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

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

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

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

 

 

Рис. 9. Основа тучи – конфликт двух состояний системы.

 

Далее я спросил, какая потребность будет удовлетворена при каждом состоянии системы и какая цель будет удовлетворена, так были заполнены квадраты А, В и С в модели противоречия, изображенного на рис. 8:

 

Рис. 10. Сформированная графическая модель противоречия (Туча) по поставленной задаче.

 

Противоречие сформировано, теперь нужно решать. Путей решения несколько, однако в данном случае я предпочел проверить возможность решения «здесь и сейчас», прибегнув к анализу связей противоречия, изображенных стрелками на рис. 10.  Основа логики работы со связями такая: мы читаем фрагмент противоречия, например, от D к В: для того, чтобы  компетенции управления продажами сложного оборудования быстро развивались за счет четкой фокусировки на задаче продаж сложного оборудования, отдел продаж сложного оборудования должен быть представлен самостоятельной структурной единицей, потому что … и здесь должна появиться новая сущность, которой нет ни в состоянии системы D, ни в ее потребностях (свойствах) В. Расспросив руководителя проекта об этом, я выяснил, что этой сущностью является «четкость структуры подчиненности и сфокусированная ответственность». Как видите, понятий «четкость структуры» и «фокус ответственности» ранее в противоречии не фигурировало, мы говорили лишь о фокусировке на задаче, так что «четкость» и «ответственность» мы зафиксировали. Далее похожую операцию мы проделали со связью D’ – С и получили еще одно новое знание: во втором случае мы имеем «принцип единоначалия», с руководителя подразделения проектных продаж можно спрашивать за поставки в проект целиком, причем руководителю видна вся картина в проекте. То есть, возникает сущность «видение всего проекта целиком» и «единоначалие». В результате противоречие принимает вид:

 

 

Рис. 11. Туча и анализ связей B-D и C-D’.

 

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

Этот пример наглядно демонстрирует, что сама по себе структура противоречия в ТОС (рис. 8) не имеет кардинальных отличий от модели противоречия, принятого в ТРИЗ (рис. 6), однако следует принять на вооружение механизм анализа связей в противоречии – этот механизм позволяет гораздо быстрее продвигаться к решению задач бизнеса. В ТРИЗ столь четкого и простого анализа противоречия, к сожалению, пока не используется.

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

 

© Антон Кожемяко.