Доклад на VIII юбилейной конференции «ТРИЗ. Практика применения методических инструментов и их развитие».

Доклад на VIII юбилейной конференции «ТРИЗ. Практика применения методических инструментов и их развитие».

Нетехническая ТРИЗ: опыт решения организационно-управленческих задач, ограничения и инструменты.

Цель: наметить область применения ТРИЗ в сфере организационно-управленческого проектирования, показать некоторые особенности применения инструментов ТРИЗ совместно с другими подходами к системному анализу – СМД (Г.П. Щедровицкий) и ТОС (И. Голдратт).

Содержание доклада:

1. Определение задач бизнеса.
2. Применение подходов СМД-методологии Г.П. Щедровицкого для первичной обработки плохо формализованных задач бизнеса.
3. Находки И. Голдратта  — применение подходов ТОС для анализа технических противоречий.
4. Выводы.
5. Литература.

 

1. Определение задач бизнеса.

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

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

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

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

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

Рис. 1. Организационно-управленческие задачи = бизнес-задачи.

 

2. Применение подходов СМД-методологии для предварительной обработки плохо формализованных задач бизнеса.

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

Стоит отметить, что подобная практика взаимодействия с заказчиком давно и успешно опробована в ТРИЗ. Например, Николай Хоменко даже разработал схему подобного взаимодействия [4]. Н. Хоменко предложил рассматривать модель задачи с четырех точек зрения:

— с позиции человека, работающего над решением проблемы;

— с позиции человека, который контролирует формальную правильность анализа проблемы и признание инструментов и методик, тем, кто занят решением проблемы с методологической точки зрения («человек на мачте»);

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

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

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

Рис. 2. Порядок работы над задачей, в том числе над бизнес-задачей, предложенный Н. Хоменко.

Надо сказать, на практике мы не использовали данный подход в виду того, что он требует значительного времени на подготовку и отвлечения дополнительных сотрудников заказчика, но на мой взгляд, подход интересен. При решении подобных задач мы всегда создаем проектную группу из числа сотрудников заказчика, которые как следует погружены в проблему. Работа над задачей обычно проходит циклично, в 4-6 проходов, каждый из которых состоит из анализа задачи в группе (проектно-аналитическая сессия), а затем – «дотяжка» промежуточного результата в дистанционном режиме. Группа работает до получения окончательного решения, то есть до создания программы преобразований, реализуя которые команда добивается снятия целевых НЭ.

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

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

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

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

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

Что происходит дальше? А дальше есть два пути работы с полученной схемой.

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

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

  3.  Выделить противоречия и далее работать с ними. В этом случае в работу вступают решительные  механизмы ТРИЗ или ТОС;

 

Путь 2. Именно по этому пути мы пошли, решая задачу о продажах строительной техники (рис. 3, нижняя часть). Суть данного пути состоит в следующем:

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

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

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

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

 

3. Находки И. Голдратта  — применение подходов ТОС для анализа технических противоречий.

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

Внимание! В приведенном ниже примере последовательное формулирование противоречий проходит в логике ТРИЗ, наработки ТОС используются в последний момент, когда вместо перехода к классическим механизмам разрешения ТП в ТРИЗ мы используем прием ТОС – анализ противоречия по формуле <потребительское свойство 1> → <ядро противоречия> должен → <система в крайнем состоянии> → потому что <новая сущность>. Прием очень продуктивен и прост в применении, рекомендую взять на вооружение.

Разберем метод анализа противоречий (сначала движемся в логике ТРИЗ).

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

Рис. 4. Ядро противоречия в рассматриваемой задаче.

Далее я спросил, какая потребность будет удовлетворена при каждом состоянии системы и какая цель будет удовлетворена, так было сформировано противоречие в окончательном виде (рис. 5):

Рис. 5. Техническое противоречие в рассматриваемой задаче.

Противоречие сформировано, теперь нужно решать. Путей решения несколько, однако в данном случае я предпочел проверить возможность решения «здесь и сейчас», прибегнув к анализу связей противоречия с помощью формулы: для того, чтобы <потребительское свойство 1> → <ядро противоречия> должен → <система в крайнем состоянии> → потому что <новая сущность> [5] (рис. 6):

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

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

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

Рис. 6. Анализ технического противоречия согласно рекомендациям, позаимствованным из ТОС.

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

 

4. Выводы.

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

В организационно-управленческих системах все очень похоже (это тоже искусственные системы!), с той лишь разницей, что закономерности не являются жесткими и могут варьироваться в зависимости от материала, из которого «собрана» система и от условий, в которых находится «материал» (кадры решают все). Это накладывает дополнительные требования при решении бизнес-задач, с одной стороны, а с другой – дает большое пространство для маневра. Поэтому при решении орагнизационно-управленческих задач следует пользоваться вторым определением системы и работать последовательно: сначала очертить рамку целого (область решения задачи – не путать с оперативной зоной), затем рассмотреть элементы системы в категории мест и их взаимосвязи и функции, исключив «мерцающий» материал. Решение задачи сначала должно быть найдено на уровне мест, а затем обязательно вырабатывается требования к персоналу, то есть оговариваются условия добавления материала. Переход от требований мест к свойствам материала применяется, например, в концепции Ицхака Адизеса [6] – рис. 7 (приведенная на рисунке схема разработана А.П. Кожемяко): 

Рис. 7. Разработка требований к материалу согласно концепции И. Адизеса с последующей оценкой материала.

Как понятно из рис. 7, область ТРИЗ для решения подобных задач находится между анализом плохо формализованной задачи и до момента перехода к оценке материала (см. рис. 8):

 

Рис. 8. Общие подходы к решению задач бизнеса от начала работы над задачей до момента оценки материала (оценка материала в схему не включена и приведена на рис. 7).

 

Итак, опыт работы над проектами в сфере задач бизнеса показывает:

1. Задачи бизнеса следует понимать как задачи организационно-управленческого проектирования;
2. При работе с бизнес-задачами следует руководствоваться вторым определением системы, понимая мерцающие свойства материала;
3. Применять инструменты ТРИЗ, включая инструменты первичной обработки задачи, следует после предварительного анализа плохо формализованной задачи, для чего рекомендую использовать приемы схематизации, взятые из СМД-подхода Г.П. Щедровицкого;
4. После выхода наформулировку ТП по поставленной задаче рекомендую перед переходам к решению по АРИЗ выполнить анализ полученных противоречий по методу, применяемому в ТОС для анализа «тучи»;

Решения с применением системного анализа стоит производить на уровне «мест» до их наполнения «материалом». При этом требования к материалу рассматриваются как элемент решения задачи.

 

Смотреть видео-долад:

 

Презентацию к докладу можете скачать здесь в формате pdf.

 

5. Литература.

1. А.П. Кожемяко. Идеи совместного применения ТРИЗ и СМД для решения задач бизнеса. Статья. Опубликовано: www.bmtriz.ru

2. А.П. Кожемяко. Идеи совместного применения ТРИЗ, СМД и ТОС для решения задач бизнеса. Часть 2. Статья. Опубликовано: www.bmtriz.ru

3. Путеводитель по методологии Организации, руководства и Управления / Хрестоматия по работам Г.П. Щедровицкого. – М.: Альпина Паблишер, 2012. – 197 с.

4. Работы Н. Хоменко в области ТРИЗ-ОТСМ;

5. Библиотека Стратегические решения ТОС. Основы Теории Ограничений. Одед Коуэн и Елена Федурко, 2012. www.toc-strategicsolutions.com

6. Адизес И.К. Как преодолеть кризисы менеджмента. Диагностика и решение управленческих проблем. — М.: Манн, Иванов и Фербер, 2014.

 

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