Системные круги. Системная сборка задач и проектов

1. Точка Б: что может дать сам объект

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

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

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

Именно из желаемого результата мы получаем первые требования к точке Б.

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

Так нежелательный фактор становится подсказкой для поиска ресурса.

2. Точка А: что уже есть у нас

Следующий шаг — посмотреть на собственную систему.

Люди, знания, опыт, документы, оборудование, данные, процессы, время, связи, уже выполненная работа — всё это потенциальные ресурсы.

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

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

Поэтому здесь полезный вопрос звучит очень просто:

Что у нас уже есть и что из этого пока используется не полностью?

3. Надсистема и среда точки Б

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

Смотрим на более крупную систему, частью которой является точка Б: её правила, процессы, участников, инфраструктуру и уже принятые решения.

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

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

4. Надсистема и среда точки А

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

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

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

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

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

Профессиональная ресурсная работа в ТРИЗ значительно шире этой деловой сетки [3].

Противоречие: сохранить обе важные стороны

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

ТРИЗ предлагает искать решение, в котором сохранятся обе стороны. На время поиска полезно удержать сильные требования, вместо того чтобы сразу выбирать среднее значение. Например, вывод должен быть индивидуальным, а время эксперта — расходоваться прежде всего на содержательно сложные решения.

Чтобы увидеть возможный ход, мысленно усилим конфликт до предела: каждому участнику нужна подробная обратная связь, а эксперт физически способен рассмотреть только ограниченный объём. Такое обострение используется в АРИЗ как приём построения модели задачи [2]. Оно помогает увидеть, какую функцию следует передать другому носителю, перенести во времени или разделить по условиям.

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

В приложении 1 раскрыты способы разделения требований и приёмы с деловыми примерами. Здесь важна связка: нужный результат, нежелательный эффект, механизм, ресурс и изменение. Она помогает перейти от усиления привычного способа к другой конструкции решения.

Ключевые мысли главы. Точка Б задаёт направление: сначала мы определяем, какой результат должен стать возможным и по каким критериям он будет полезен. Точка А показывает сегодняшние факты, ресурсы и ограничения. Сопоставление Б и А по одинаковым параметрам помогает увидеть нежелательные эффекты и выделить ближайшую область роста. Инструменты ТРИЗ расширяют поиск: помогают находить ресурсы, формулировать противоречия и искать способы сохранить одновременно несколько важных требований.

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

Глава 5. Практика: девять шагов системной сборки

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

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

В качестве примера возьмём тренинговое агентство.

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

По мере движения по трём кругам постановка будет меняться.

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

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

В третьем круге переведём найденный вариант в действие: выберем приоритет, распределим функции и подготовим первый тест.

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

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

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

Начнём с первого круга — требуемого будущего.

Шаг 1. Назначение, результат и след

Круг 1. Требуемое будущее — Б

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

Именно поэтому первый шаг начинается с назначения.

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

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

На этом же шаге полезно различать ближайший результат и след.

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

Именно поэтому первые вопросы системной сборки звучат так:

Что должно стать возможным благодаря результату?

Что должно стать возможным благодаря результату?

Как будет выглядеть ближайший полезный выход вашей работы?

Что благодаря этому должно продолжить работать дальше?

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

На примере агентства

Мы начали с назначения обучения.

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

Ключевые мысли главы. Назначение направляет выбор средства. Ближайший результат можно предъявить, а след проявляется в дальнейшей работе.

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

Шаг 2. Получатели и параметры

Круг 1. Требуемое будущее — Б

Один результат часто нужен сразу нескольким людям. Презентацию читает партнёр, коммерческие условия проверяет команда исполнения, окончательное решение принимает руководитель. У каждого своя задача и свои требования к результату.

Поэтому сначала важно ответить на простой вопрос:

Каким должен быть результат, чтобы им действительно можно было пользоваться?

Для этого мы называем несколько конкретных признаков.

Если речь идёт о коммерческом предложении, клиенту должно быть понятно:

— что именно ему предлагают;

— какой результат он получит;

— сколько это стоит;

— в какие сроки будет сделано;

— что потребуется от него для начала работы.

Если мы готовим отчёт для руководителя, ему может быть важно быстро увидеть:

— что произошло;

— где есть отклонения;

— почему они возникли;

— какое решение требуется;

— кто отвечает за следующий шаг.

Такие признаки становятся параметрами требуемого результата.

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

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

Так вместо общего пожелания «сделать хорошо» появляется понятная картина точки Б: что именно должно получиться и каким требованиям должен соответствовать результат.

Вопросы

Для кого создаётся результат и по каким признакам он будет пригоден?

Какие полезные качества уже есть и должны сохраниться при изменении?

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

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

Например, клиенту нужен быстрый ответ, а команда исполнения должна убедиться, что обещанное действительно можно выполнить. Оба требования важны. Задача системной сборки — увидеть их одновременно и найти способ согласовать.

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

Коммерческое предложение должно помогать компании двигаться к сделке. Отчёт — помогать руководителю принимать решение. Программа обучения — поддерживать изменение в работе участников и цели организации.

Здесь полезно использовать простой образ: «стать бензином для машины».

Бензин ценен не сам по себе. Он должен подходить конкретной машине и помогать ей двигаться. Так же и наш результат должен подходить той большей работе, в которую он встраивается.

Поэтому стоит спросить:

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

По каким параметрам мой «бензин» должен подходить этой «машине»?

Ответы помогают увидеть дополнительные требования точки Б.

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

Найденные возможности позже войдут в ресурсную часть системной сборки.

На примере агентства

В проекте корпоративного обучения у каждого участника системы были свои требования.

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

Для заказчика — понимание, какие компетенции развиваются и по каким признакам можно оценить результат.

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

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

Так постепенно общая формулировка «провести хорошее обучение» превратилась в набор конкретных параметров будущего результата.

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

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

Шаг 3. Нежелательные эффекты

Круг 1. Требуемое будущее — Б

К этому шагу у нас уже есть два состояния.

Мы понимаем, каким должен быть результат в точке Б: что хочет получить пользователь, какие параметры для него важны и какие требования задаёт более крупная система.

И мы начинаем видеть, что происходит сейчас в точке А.

Теперь главное — сопоставить их.

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

Например, в точке Б клиент после чтения коммерческого предложения должен понимать, что именно он получит. В точке А после чтения он задаёт вопрос: «Что конкретно входит в результат?»

Получается простой разрыв:

Б: клиент понимает состав результата.

А: клиент вынужден его уточнять.

Вот это уже конкретная задача для дальнейшего поиска решения.

Важно сравнивать А и Б по одному и тому же параметру.

Фраза «хотим увеличить продажи, а сайт устарел» соединяет разные вещи. Пока непонятно, действительно ли внешний вид сайта мешает продажам.

Гораздо точнее:

Б: клиент понимает ценность предложения и готов сделать следующий шаг.

А: после знакомства с предложением клиент по-прежнему не понимает, чем оно отличается от других вариантов.

Здесь уже видно конкретное расхождение.

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

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

Например:

Б: руководителю достаточно пяти минут, чтобы понять состояние проекта.

А: пока не знаем, сколько времени он тратит на отчёт.

Тогда следующим действием становится сбор факта, а не поиск причины.

Вопросы шага

Что в текущем состоянии А не совпадает с требуемым состоянием Б?

По какому конкретному параметру виден этот разрыв?

Как он проявляется на практике?

К какому последствию приводит и насколько это последствие существенно?