Структура применения ТРИЗ для решения задач менеджмента

Доклад на IX конференции ТРИЗ сообщества в Москве, 11 ноября 2017 г.

Общий подход к решению задач организационно-управленческого проектирования изображен на схеме (рис. 1):

Рис. 1. Порядок работы с бизнес-задачей с помощью ТРИЗ. Сборочная схема.

На схеме мы видим, что сначала следует провести анализ условия задачи и применить схематизацию для прояснения условия задачи. Управленческие задачи, как правило, на входе плохо формализованы. Схематизация помогает привести условие к модели функционирующей системы (по Н. Шпаковскому). Мы называем эти операции «первым циклом обработки задачи». Результат прохода по задаче инструментами первого цикла: выделение траектории решения и окончательное определение НЖЯ. На этом этапе могут быть сформированы первые противоречия, но это скорее исключение, чем правило.

Поэтому, для дальнейшей работе с оставшимися НЖЯ обычно применяют методы, которые в ТРИЗ называются «инструментами первичной обработки задачи». Этих инструментов разработано много и они широко известны. Некоторые инструменты первичной обработки задачи приведены на схеме применительно ко 2-му циклу обработки задачи.

После  применения этого класса инструментов снова возникает набор противоречий и НЖЯ, но более глубоком уровне ее понимания. Далее, если удовлетворяющее вас решение все еще не найдено, то на огневые позиции выкатываем бронебойное орудие ТРИЗ – алгоритм решения изобретательской задачи – АРИЗ. Это мощнейший инструмент ТРИЗ, отработанный десятилетиями практики. К стати, мой любимый инструмент. Правда, применяем мы не полную версию АРИЗ-85В, состоящую из 40 шагов, а укороченную, в которой присутствует 6-7 шагов. И если команда, решающая задачу, обладает достаточными предметными знаниями, то решение будет найдено в любом случае. Этот, глубинный уровень, мы называем «третьим циклом обработки задачи».

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

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

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

Поэтому, на схеме мы видим, что решения появляются на разных стадиях обработки задачи и пополняют «копилку» справа, где мы должны впоследствии их собрать в программу преобразований, после чего область ТРИЗ заканчивается и начинается проектное управление. Примерно так работает ТРИЗ в задачах бизнеса – работаем с системой НЖЯ, с системой технических противоречий и на выходе получаем систему решений. Доведение решений до программы преобразований – это конечный результат применения ТРИЗ для управленческих задач. Программа преобразований обычно фиксируется на доске задач в логике гибкой технологии управления проектами SCRUM, например, на электронной доске в www.trello.com.

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

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

Рис. 2. Взаимодействие в команде решателей во время сессии решения задачи и за ее пределами. * на схеме означает рефлексивную позицию.

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

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

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

Для организации работы команд очень рекомендуем метод гибкого планирования SCRUM, в качестве рабочей среды – гугл-документы и электронные доски задач, вроде trello.com. Облачные сервисы очень удобны, они обеспечивают гибкий доступ участников процесса к документам и доске задач в любом времени и месте, позволяют обрабатывать один документ несколькими участниками процесса. Помимо среды обработки документов и доски задач, рекомендуем организовать чат команды, где можно решать оперативные вопросы. Обычно мы рекомендуем hangouts.com, можно использовать любые другие ресурсы или внутренние чаты в ERP-системе компании. Такие возможности в компании как правило есть, если культура создания проектных команд – привычная практика организации.

Доклад_на_IX_конф._-_Кожемяко_АП

 

© Антон Кожемяко, специалист ТРИЗ 4-го уровня, Челябинск.

 

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


Комментарии

Читайте также

Показать больше записей