Отсеките все лишнее! Функциональный анализ — король инструментов первичной обработки задачи

Материал из книги ТРИЗ. Решение бизнес-задач.

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

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

Э. Майлз, сотрудник фирмы «Дженерал электрик», автор инженерно-стоимостного анализа, определил свой метод как «прикладную философию». Он считал, что «анализ стоимости… — это организованный творческий подход, цель которого заключается в эффективном определении непроизводительных затрат или издержек, не обеспечивающих ни качества, ни полезности, ни долговечности, ни внешнего вида, ни других требований заказчика». По сути, автор определяет назначение своего детища точно так же, как мы понимаем назначение LEAN, концепции бережливого производства. Только в отличие от LEAN, ФА ищет потери не в процессе, а в си- стеме. А как известно, любая система представляет собой совокупность взаимосвязанных элементов. Если, применяя философию LEAN, мы боремся с различными видами потерь в производственном процессе, то применяя ФА, — с излишками конструкции, с неоправданно завышенным составом системы.

Основная идея ФА заключается в том, что любая система создается не просто так, а ради определенной цели. Ложка хочет, чтоб ею ели, стул приглашает сесть, CRM-система просит ввести в нее данные и готова поделиться с вами полезными отчетами, бизнес-процессы описаны для того, чтобы сотрудники могли быстро и эффективно выполнять свою работу, а руководители не тратили бы часы на разъяснение однотипных задач.

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

Отсюда становится понятно, что функции могут относиться как к системе в целом (такую функцию в ТРИЗ называют «главная полезная функция» — ГПФ), так и к подсистемам. Функции подсистем, в зависимости от их назначения, могут быть основными (предназначенными непосредственно для выполнения ГПФ; основными функциями обладает рабочий орган системы), вспомогательными (предназначенными для усиления ГПФ, которыми обладают остальные элементы системы), дополнительными (полезными, но отличными от тех, которые заложены проектировщиком при создании системы, то есть полезными функциями), а также вредными. Увы, не все коту масленица. Вредные функции в системе содержатся всегда и в избытке. За все приходится платить.

Если мы имеем дело с искусственными системами (рис. ниже), то по- скольку такие системы всегда создаются с определенной целью, они наполнены функциями. Каждый элемент системы несет в себе определенный функционал, иначе зачем он там? Для красоты? Даже если и так. В этом случае перед нами декоративный элемент, у которого есть определенная функция — радовать глаз…

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

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

Сформированная графическая модель функционирующей системы

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

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

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

Шаг 1. Компонентный анализ. Определяем МФС

Первый шаг начинается с выделения модели функционирующей системы, или на языке ФА — с компонентного анализа.

Схема проведения ФА

Для нашего примера компонентный анализ будет выглядеть примерно так (повторюсь, модель упрощена до предела):

Исследуемая система ПодсистемыБлижайшие надсистемы
* отдел продаж* менеджер
* руководитель по продуктовому направлению в системе продаж
* клиент на В2В-рынке (клиент)

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

Шаг 2. Структурный анализ и анализ связей в системе. Ломаем «вредную машину»

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

Пример структурного анализа

В строках и столбцах таблицы располагаются элементы системы и ближайших надсистем, выявленные на шаге 1. Связи обозначаются Сn = С1, С2, С3, …, С10 — связи между элементами системы. С означает «связь». Каждая получает порядковый номер, что дает возможность с ними работать отдельно.

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

Обратите внимание, что в данной таблице определены  как  прямые, так и обратные связи. Если козырек над подъездом, на котором лежит снег, давит на балки, это прямая связь. Балки не поддаются (иначе козырек бы рухнул) и оказывают сопротивление давлению. Это обратная связь. Если руководитель вышел из себя и орет на подчиненного, это прямая связь. Подчиненный, на которого орет руководитель, думает, что руководитель сегодня в неадекватном состоянии, и выбирает определенную модель поведения. Это проявление обратной связи. Поэтому в таблице связи С1 и С6 или С5 и С9 — не одно и то же.

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

Таблица. Анализ связей в МФС — определяем полезное действие и ломаем «вредную машину»

Посмотрите, сколько информации можно выжать из каких-то пяти взаимодействующих элементов, хотя на самом деле МФС куда сложнее! Ведь правда, где генеральный директор? Где господа конкуренты? А собственник? Его позиция что, не интересна? Почему в схеме отсутствуют элементы, задающие производственные ограничения? Разве они не влияют на процесс продаж? Конечно, влияют, поэтому в начале демонстрации метода я написал, что данный пример — учебный, он упрощен до предела. Хотя полезные действия и НЖЯ взяты вполне реальные, и даже в таком простом примере их набралось немало!

Обратите внимание, как прописаны положительные  действия и НЖЯ. Все они начинаются с глагола в неопределенной форме, обозначающего конкретное действие носителя функции (инструмента) по отношению к объекту функции (изделию). Общий порядок записи функций в ТРИЗ принят такой. Он конкретен и содержит всю необходимую для работы информацию.

Итак, мы получили набор положительных действий в формате функций и набор НЖЯ, также сформированных по формуле функций (это — вредные функции системы).

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

Я не стал добавлять в книгу ПСА по данной задаче, ведь построение причинно-следственных цепочек мы подробно разобрали. Если в вашем бизнесе ситуация похожа, можете самостоятельно поработать с 29 НЖЯ из таблицы и определить ключевые. Отправьте полученную причинно-следственную цепочку на адрес info@bmtriz.ru, и мы дадим вам обратную связь по ее построению. Не забудьте отметить ключевые НЖЯ!

После получения списка ключевых НЖЯ по результатам проведения ПСА рекомендую работу по их преодолению пока не проводить. Почему? Потому что после оптимизации положительных действий и, возможно, сокращения элементов системы (вспомните, в результате проведения ФА мы отсекаем все лишнее) часть ключевых НЖЯ из полученного списка уберется автоматически. Нет объекта функции — нет самой полезной функции. Возможно, нет и вредной. Носитель функции удален из системы, вместе с ним ушли и вредные функции.

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

Обратите внимание, что некоторые НЖЯ из таблицы входят в противоречие друг с другом, например, НЖЯ 12 и НЖЯ 13. Такое бывает довольно часто! И если после проведения ПСА остаются ключевые НЖЯ, которые все еще находятся друг с другом в состоянии конфликта (противоречия), тогда в дальнейшем с ними стоит работать, как с конфликтующей парой, и применять к таким «сборкам» инструменты разрешения противоречий из арсенала ТРИЗ.

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

Таблица. Пример структурного анализа

Шаг 3. Ранжирование функций. Работаем с полезными функциями

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

  • основные функции, то есть те, что непосредственно осуществляются для выполнения главной полезной функции (ГПФ), ради которой создана система;
  • вспомогательные функции, нужные для усиления ГПФ;
  • дополнительные, которые система выполняет несмотря на то, что для этого она изначально не предназначалась.

Для лучшего понимания рассмотрим функции бытовой мясорубки. Этот агрегат имеет следующие основные узлы:

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

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

Получилась следующая картина:

Упрощенная функциональная модель мясорубки. Ранжирование функций и функциональное моделирование

С основными функциями все более-менее ясно, их всегда выполняет рабочий орган системы (на рисунке рабочих органа два — нож и решетка). Место выполнения основной функции всегда принимается за нулевой ранг функции — танцевать надо от печки.

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

Чтобы еще более усилить ГПФ, современные мясорубки снабдили электроприводом. Мы получили новые ранги вспомогательных функций, которые еще сильнее удалены от рабочего органа, зато приобрели удобство, усилив ГПФ. Для приготовления фарша физическая сила более не нужна.

Нечто подобное происходит и с компаниями. В погоне за усилением ГПФ мы все шире разворачиваем структуру организации, удаляя орган управления дальше от рабочего органа системы. Но увеличение рангов всегда имеет и «темную» сторону — снижаются возможности контроля, накапливаются ошибки, многократно возрастает инерционность системы, ухудшается обратная связь… Поэтому система нуждается в периодическом сокращении количества элементов с сохранением требуемого функционала.

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

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

Ранжирование функций в отделе продаж

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

Интересно, но в таблице Анализ связей в МФС — определяем полезное действие и ломаем «вредную машину» в связи С6 присутствует НЖЯ 21 «входить в противоречие с коммерческими приоритетами филиала». На рисунке Ранжирование функций в отделе продаж мы видим, что начальник филиала и руководитель по продуктовому направлению с точки зрения поставленной задачи располагаются на одном слое (В1). Похоже, такое «горизонтальное расположение» двух руководителей, ставящих задачи менеджеру, и является причиной данного НЖЯ. В компании, поставившей эту задачу, довольно остро стояла эта проблема — приоритеты двух руководителей, которым подчиняются менеджеры, не совпадали. В результате возникал конфликт интересов. Матричная структура, которую строила данная компания, не была отлажена на момент постановки задачи, отсюда и возникало противоречие. Ранжирование функций объясняет наличие в системе данного НЖЯ.

Шаг 4. Функциональное моделирование. Готовимся к удалению лишнего

Частично функциональное моделирование мы рассмотрели на рисунке Упрощенная функциональная модель мясорубки. Ранжирование функций и функциональное моделирование.

Упрощенная функциональная модель мясорубки. Ранжирование функций и функциональное моделирование

Это графическая форма функционального моделирования. Обычно, когда мы решаем реальные задачи, всегда начинаем с графической формы. В результате получается нечто, изображенное на рисунке Ранжирование функций и функциональное моделирование. Пример грубого прототипирования (пример взят из другой задачи).

Ранжирование функций и функциональное моделирование.
Пример грубого прототипирования

Вначале, вооружившись доской и маркерами или бумагой и карандашом, делаем набросок — располагаем элементы системы в порядке их рангов и стрелочками обозначаем функции. Рисование на доске обычно сопровождается активной коммуникацией команды. Это приветствуется! Главное — понимать разницу между коммуникацией и балаганом. Затем, когда команда изрядно почеркалась на доске, переходим к табличной форме функционального моделирования. Теперь мы неспешны и вдумчивы…

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

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

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

Вернемся к нашему примеру с отделом продаж. При составлении функциональной модели в табличной форме воспользуемся данными из таблицы и результатами ранжирования функций (рис. Ранжирование функций в отделе продаж).

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

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

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

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

При функциональном моделировании полезные функции маркируются литерой А, если степень их выполнения адекватна ситуации; И — если полезная функция избыточна и Н — если недостаточна. Вредные функции, естественно, так не маркируются. Само по себе наличие вредной функции — уже задача. Хотя при необходимости вы можете разбить вредные функции на классы по степени их проявления.

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

Итак, настает кульминация ФА — функциональное моделирование. Кстати, элементы надсистемы в функциональную модель уже не входят (к ним направлена основная функция).

Таблица. Функциональное моделирование.

Дальше есть два пути.

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

Приведем логику постановки задач по результатам ФА совместно с комментариями по нашему примеру.

  • Проверить, нет ли в системе дублирования функций. Если есть, оправданно ли оно? Если нет, провести свертывание дублирующих функций. Дублирование функций есть в виде дополнительных функций «страховки» на вышестоящих эшелонах. Существует дублирование и по горизонтали (продажи — маркетинг, продажи — back-office и т. д.).
  • Сломать  «вредную машину» — то есть поставить задачи по удалению вредных функций. Эту операцию мы частично делали, когда проводили ПСА по таблице Анализ связей в МФС — определяем полезное действие и ломаем «вредную машину». Однако мы договорились не ставить задачи по полученным ключевым НЖЯ, пока ФА не будет проведен до конца.
  • Не усложняя систему, усилить недостаточные функции. В нашем случае недостаточное выполнение функций компенсируется наличием дополнительных функций у других элементов системы, но не всегда, например, F2.1 и F2.2, несмотря на попытки компенсации, все равно выполняются на недостаточном уровне.
  • Убрать избыточные функции, упростив системуИзбыточность связана в основном со страховкой других руководителей и подразделений, за исключением функции F1.5 — маловероятно, что маркетинг самостоятельно с ней справится.
  • Удалить лишние элементы системы, проведя свертывание. Необходимо определить его  правила.  Возможно,  что-то  удастся сделать на ранге 1, удалив одно из параллельных звеньев (рис. Ранжирование функций в отделе продаж). Часть НЖЯ в этом случае будут автоматически удалены. Внимание: при проведении свертывания требуется тщательно прописать его правила, чтобы не получилось как с тем заводом, где уволили рабочих с молотками.
  • Убрать дополнительные функции системы, если есть системы, в которых эти функции основные. Устранить дублирование. В нашем примере к этому классу задач сводится очень многое — см. задачи выше.

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

Схема проведения ФА

Но настоящие герои всегда идут в обход. Так что покажу вам еще один путь постановки задач при проведении ФА. Он хоть и выглядит сложнее и длиннее, зато способен привести к отличному результату! Есть еще силы в изучении ТРИЗ? Тогда вперед!

Шаг 4.1. Разбираем цепочки функций. Этот шаг — для целеустремленных и очень дотошных.

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

Шаг этот требует глубокой мыслительной работы и неспешного делания. Главное — ничего не придумывать! Процесс описывается именно таким, какой он есть, а не таким, каким должен быть. Иногда, по меткому выражению Д. Хэнны, нужно уметь быть «мухой на стене». Муха лишена всяких эмоций, не умеет предсказывать будущее и не помнит прошлое. Все, что ей доступно, — отстраненно наблюдать за происходящим здесь и сейчас. Именно так следует вести себя при составлении цепочки функций — аккуратно фиксировать картину как она есть, ничего не придумывая. Не знаете, что происходит? Спросите того, кто знает. Никто не может внятно ответить? Исследуйте, если нужно, потратьте несколько дней на наблюдение.

Совет: если уж вы решили какое-то время побыть мухой на стене, то распечатайте таблицу функциональной модели (рис. Определение MPV в зависимости от нахождения пользователя) и держите ее под рукой. При необходимости допишете туда новые функции или внесете исправления.

Определение MPV в зависимости от нахождения пользователя

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

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

Цепочки функций в графическом виде

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

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

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

Вот так выглядят цепочки функций:

Первые три цепочки уже говорят о том, что они должны быть преобразованы в вид:

Становится очевидно, что функции F1.2, F1.3 и F1.4 должны быть заданы CRM-системой. Отчеты также должны содержать эти сущности, тогда не будет разрозненной информации об изменениях потребностей клиентов, системы принятия решения у клиентов кат. А. Инициация новой сделки — также понятная сущность, которая в деятельности менеджеров регламентируется особо.

Идем дальше:

Кстати, первые три цепочки функций также имеют альтернативную ветку к F2.2. Это функция основная, связанная с выводом на рынок новых продуктов. F2.1 — тоже основная, связана с инициированием изменений существующих продуктов. Интересно, может ли этот процесс быть как-то систематизирован, например, через анализ по S-кривой? Как мы обычно поступаем — на стадии II развития продукта по S-кривой его модернизируем, а к III этапу начинаем искать ему замену? Этот вопрос можно ставить на повестку дня.

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

Рассматривая цепочки более внимательно, мы обнаруживаем в них вспомогательную функцию F4.6, реализуемую коммерческим директором. Если вывод новых продуктов  (цепочка: F1(O) — (F1.2(O) + F1.3(O) + F1.4(O)) — F1.8/F1.9 — F2.5 — F4.6 — F2.2(O)) не связан с моральным старением предыдущего, то такая консолидирующая функция очень важна. А если связан? Не вопрос ли это скорее руководителя по продуктовому направлению, чем коммерческого директора? Кто должен защищать проект вывода нового продукта на рынок — коммерческий директор или руководитель по продуктовому направлению? Похоже, в каждом случае по-разному. Оказывается, F2.2 должна по-разному осуществляться в разных случаях!

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

F1.1(O) — F1.10(Д). По ходу реализации основной функции менеджер получает обратную связь от клиента о продуктах компании — это правильно. Но от менеджера эта функция никуда не идет, она тупиковая! Отчеты, которые ведут  менеджеры в CRM-системе, не предполагают занесения данной информации, что имеет  под собой основания — менеджеров не стоит перегружать бумажной работой. Но информация-то теряется! Получается, менеджерам говорят о важности обратной связи от клиента, но большая часть информации в таком функциональном распределении будет потеряна. Получаем противоречие: менеджеры должны фиксировать всю собранную от клиента обратную связь по продуктам компании и качеству обслуживания, так как именно они находятся в наиболее тесном контакте с клиентом, и менеджеры не должны этого делать, чтобы не погрязнуть в рутине, которую в скором времени они предпочтут «полевой» работе.

А вот у руководителя продуктового направления эта цепочка полновесная, но несколько странная:

Из цепочки видно, что информация о продуктах, полученная от клиента (поэтому F1.10 и является избыточной. У руководителя по продуктовому направлению она В1, у менеджеров — Д), кладется в основу изменений в продуктах (F2.1). В итоге эти изменения должны быть заложены в бюджет, а затем, когда будут воплощены «в железе», переданы в план продаж филиала. Затем информация о продажах через цепочку отчетов проходит всю вертикаль власти, и только так принимается решение о полноценном выводе продуктов на рынок.

Стоит поставить вопрос о свертывании F4.1 и F3.8. Это можно сделать, если коммерческий директор и директор (объект функции F4.1) смогут получать необходимые данные в режиме реального времени. Эти критерии выявляются, и ставится задача об их автоматическом вычислении.

В общем, систему вы поняли. Больше цепочек вытягивать из рисунка Цепочки функций в графическом виде не буду, но если вы разрабатываете реальный проект, нужно аккуратно рассмотреть все функциональные цепочки. Абсолютно все! Тогда вы сможете поставить значительное количество задач по оптимизации существующей системы. Вы можете удалять как «лишние» функции, сокращая цепочку, так и целые элементы, предварительно прописав правила, которые необходимо выполнить, чтобы убрать функцию и тем более элемент. Эти правила, называемые в ТРИЗ «правила свертывания», образуют задачи, которые постепенно собираются в программу преобразования. А далее, как мы уже говорили, часть рекомендаций внедряется, а часть образует противоречия, как в цепочке F1.1(O) — F1.10(Д).

Можете поработать с цепочками функций самостоятельно. Выделите их и проанализируйте. Присылайте ваш разбор функциональных цепочек на почту info@bmtriz.ru. Обратная связь гарантирована. Если вы провели качественный анализ, то вдумчивая работа не останется незамеченной — мы вышлем вам промокод, дающий право на обучение ТРИЗ по программе нашего онлайн-практикума со скидкой 50 %. Количество промокодов ограничено.

Цепочки функций в графическом виде

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

Функциональный анализ дает такое количество траекторий решений и противоречий, что это приводит к кардинальной переработке изучаемой системы. Поэтому он — настоящий король инструментов первичной обработки задачи. Действительно мощный метод! У него есть лишь один недостаток — требует много времени на анализ и скрупулезную обработку результатов. Этот ключевой недостаток порождает второе НЖЯ, свойственное ФА, — много элементов туда никак не загрузишь, анализ получается чрезмерно сложным и муторным. Так что берите МФС только по ближайшим подсистемам и самым необходимым элементам надсистемы.

Шаг 4.2. Ценностно-затратный анализ

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

где Э — эффективность, ΣФп — сумма полезностей функции (полезная значимость), а ΣФз — сумма затрат на обслуживание этой функции (или затратная значимость).

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

Основные функции не подвергаются такому анализу. Ведь если свернуть основную функцию, становится ненужным рабочий орган, а раз так, то не нужна и вся усиливающая его система. Радикальное свертывание получается. А вот вспомогательные и дополнительные функции можно «подрезать», увеличив эффективность системы.

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

Таблица. Оценка функциональной и затратной значимости функций

Оценка функциональной и затратной значимости функций

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

Теперь строим диаграмму, наглядно показывающую эффективность функций (ценностно-затратный анализ).

Ценностно-затратный анализ удобно проводить с помощью столбчатых диаграмм в XLS, для чего значениям из столбца ΣФз (на диаграмме — нижние столбцы) приписывается знак «минус».

Ценностно-затратный анализ

Рисунок выше сходу выдает аутсайдеров:

  • F3.8 «Передавать отчеты по установленной форме в CRM-системе коммерческому директору»;
  • F3.4 «Устанавливать границы ответственности филиалов в крупных проектах, участники которых присутствуют на территории нескольких филиалов»;
  • F4.4 «Утверждать кадровые решения в отделе продаж».

Проанализируйте цепочки функций, построенные ранее. Могут они обойтись без этих функций? Напишите правила свертывания этих функций. Правило всегда начинается со слов:

  • функцию (объект) можно удалить из системы, если: отсутствует объект функции;
  • объект функции обрабатывает сам себя;
  • другие элементы системы обрабатывают объект функции.

Например, F3.8  «Передавать  отчеты  по  установленной  форме в CRM-системе коммерческому директору» можно свернуть, если:

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

Последний пункт требует отдельного пояснения. Раз уж вы добрались до него, то разворачивайте подробнее. Если сегодня руководитель филиала создает отчеты для коммерческого директора, а вы хотите, чтобы это делал иной элемент системы (например, менеджер или информационная среда), то придется волшебным образом наделить этот объект свойствами руководителя филиала. Ответьте на вопрос: какие характеристики (свойства, информация), имеющиеся у руководителя филиала, заставляют его генерировать данный отчет? Эти сущности должны быть переписаны, все до единой.

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

Теперь проверим цепочки функций, содержащие аутсайдеров (рис. Ценностно-затратный анализ). Например, цепочка: F1.1(O) — F1.10 — F2.1(O) — F2.6 — F3.1– F3.8 — F4.1 — F2.2.

Посмотрите на материал выше — мы уже ставили задачи по свертыванию F3.8 в этой цепочке! Что ж, семь бед — один ответ. Ставим задачи и убираем этот анахронизм. Но устраняя лишнее, работаем, как хирург, через правила свертывания, а не как мясник, используя излюбленный прием «рубануть шашкой» или топором…

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

Вот такой он плодовитый, король методов первичной обработки задач! Советую крепко с ним подружиться. Если будете серьезно применять ТРИЗ, без ФА точно не обойдетесь.

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

Подробнее ознакомиться с бизнес-ТРИЗ вы можете, пройдя онлайн-курс курс Бизнес-ТРИЗ с возможностью прохождения международной сертификации по стандартам IBTA (international business TRIZ association).