Шаг 6. Анализ процессов
Материал из книги ТРИЗ: практическое руководство для бизнеса в схемах.
Как дальше работать с траекториями? Для этого стоит определить, что анализировать дальше: процесс или структуру.
При анализе структуры мы словно фотографируем элементы их взаимосвязи в статике. Анализ процесса показывает изменения элементов и их взаимосвязей во времени.
Для анализа структуры существует ряд методов, два из которых рассмотрим чуть позже.
Если считаете, что траекторию следует рассматривать как процесс, тогда вам потребуется воспользоваться одним из двух подходов. Вы анализируете процесс как последовательность операций либо рассматриваете его в логике движения вещества, энергии или информации (анализ потоков).
Итак, у нас появилось три сущности, с двумя из которых продолжаем работать в логике ТРИЗ: это траектории и нежелательные эффекты. Нежелательные эффекты пока придержим, благо они будут еще прибывать в результате последующих шагов, а вот с траекториями начнем работать уже сейчас.
Третья сущность отправляется на «парковку», чему мы несказанно рады – у нас появились первые продукты нашей мыслительной работы, которые мы можем внедрить в наш бизнес!
Теперь поговорим о траекториях (шаг 5 Общей схемы).
И тут вдруг мы оказываемся на распутье, которое можно схематично представить примерно так: см. схему 1.1.
Из схемы 1.1 видно, что сначала стоит определить, каким способом будем дальше обрабатывать траектории. А для этого нужно решить, что важнее: проанализировать процесс или структуру системы?
Мы уже частично описали пространство, в котором находится наша система, когда на шаге 3 Общей схемы анализировали МФС с помощью схемы.
Поэтому если с точки зрения решаемой задачи нам выгоднее залезть в структуру, то мы продолжим ее анализировать. Это можно сделать с помощью инструментов функционального анализа (здесь метод не описан ввиду его высокой трудоемкости) либо с помощью более детального рассмотрения ключевых стейкхолдеров в схеме МФС (тогда применим MPV-анализ, это шаг 7 Общей схемы).
Если же более информативен и менее затратен анализ процесса в области выбранной траектории, тогда стоит для начала попробовать пройти по этому пути.
В общем суть понятна: решатель все равно что электрический ток, всегда должен стараться пройти по пути наименьшего сопротивления, если результат неочевиден. Если неясно, что за горизонтом, разве не логично отправиться сначала по легкому пути и посмотреть, куда мы придем? Попробуйте сначала свернуть, обрыв обогнуть. Если не получилось, выбираем трудную дорогу.
Дальнейший ваш шаг мне сейчас неизвестен. Это может быть либо анализ процесса, либо анализ структуры. Вам следует разобраться, как преодолеть первую развилку на схеме 1.1 и двинуться дальше.
Например, если рассмотреть несколько траекторий, полученных на шаге 3 при анализе схемы 3.5, мы увидим следующее.
*Структура/процесс и процесс/структура отличаются тем, что хотя скорее всего в обоих случаях придется анализировать и процесс, и структуру, но в первом случае выгоднее начинать с анализа структуры, а во втором – наоборот.
** Часть 1 задачи 3.3 несложно разбить на задачи на исполнение и отправить на парковку, поэтому часть 1 в траектории не попала.
Давайте разберемся на примере, в каком случае выгодно анализировать процесс, а в каком –
структуру. Не сомневаюсь, что у вас будет свое мнение на этот счет (так и должно быть, вы же решатель!). Изложу для примера свои выкладки по нескольким траекториям.
- Траектория 1.1. Сделать так, чтобы CRM-система соответствовала требованиям и поддерживала новую систему продаж.
Почему мы говорим о структуре? Вроде бы менеджеры вносят данные в CRM-систему постепенно, следуя логике развития сделки, а это процесс… Так-то оно так, да только у нас стоит задача не оптимизировать внесение данных менеджерами в CRM-систему, а сделать так, чтобы CRM-система соответствовала требованиям новой системы продаж и поддерживала ее. Когда речь идет о требованиях одних элементов системы к другим, в первую очередь речь идет о структуре. Анализируя структуру, мы учитываем связи-функции-процессы, слои и группы элементов, и лишь поняв их взаимоотношения, можно решить поставленную задачу. Так что структура первична.
Тогда почему в ячейке написано структура/процесс? А потому, что на разных стадиях развития сделки требования новой системы продаж могут отличаться, то есть требуется рассматривать структуру в динамике, а это уже процесс. Наилучшее решение здесь – проанализировать структуру в нескольких ключевых точках. - Траектория 1.2. Настроить сквозные процессы. Тут и так все понятно. Возможно, понадобится анализировать и структуру, но это точно не то, с чего следует начинать. Начинать нужно с анализа процесса.
- Траектория 2.1. Как сделать так, чтобы требования системы продаж выполнялись, но менеджеры тратили как можно меньше усилий? Эта траектория может быть рассмотрена уже после того, как найдены решения траектории 1.1, после чего требования системы продаж фиксируются в качестве ограничений. Теперь, если требования системы известны и зафиксированы (= const), осталось рассмотреть процесс работы менеджеров в новой системе продаж. Так что данную траекторию выгоднее подвергнуть дальнейшему анализу с помощью методов анализ процесса.
- Траектория 3.1, часть 1. Провести сравнение требований существующей и новой систем, определить области сходства и кардинального расхождения. Все, что касается сравнения требований, – это прежде всего структура. Время – ключевая характеристика процесса. Поэтому если мы упремся в требования, связанные со временем, то не исключено, что придется внимательно рассмотреть не только структуру, но и процесс.
Отлично, с первой развилкой на схеме 1.1 разобрались. Переходим ко второй. Возникает вопрос, что лучше: проанализировать последовательность операций или выбрать для анализа потоки? Для начала разберемся, в чем разница между этими двумя видами анализа процессов.
Сначала нужно делать то, что нужно делать сначала, учит мудрый С. Кови. Известно также высказывание «Хороший процесс не может не родить результат». Примерно так следует рассуждать решателю, если перед ним стоит задача разобраться, насколько оптимально ответственные сотрудники проводят тот или иной бизнес-процесс. В этом случае проанализируйте последовательность операций.
Если же требуется разобраться, насколько эффективно из точки А в точку В попадает вещество, энергия или информация (поток), тогда анализируем поток.
Например, перед нами стоит задача повысить конверсию лида в клиента при покупке страхового полиса. Первое, что приходит в голову, – это анализ процесса. Но что анализировать: потоки или последовательность операций? Пытаясь ответить на этот вопрос, команда страховой компании изобразила следующую схему (схема 1.2).
Если внимательно присмотреться к схеме, то мы увидим, что на одной схеме изображены оба подхода. Сначала потенциального клиента настигает контент, приходящий из разных источников: рекомендации от знакомых, СМИ, SMS, информация из буклетов и т. д. Потом, если информация его заинтересует, он становится лидом и перемещается на сайт (Потенциальный клиент – еще не клиент, но если он положительно отреагировал на информационное сообщение, то стал лидом, то есть каким-то образом обозначил свой интерес). Предполагается, что лид совершит ряд действий, прежде чем превратится в клиента (приобретет страховой полис).
Если мы хотим сделать так, чтобы контент достигал целевой аудитории по максимуму, то потребуется проанализировать движение потоков информации к потребителю (то есть к фокусу внимания потенциального клиента). Это, по замыслу задачедателя, должно привести к превращению потенциального клиента в лид. Если же мы хотим, чтобы лид превратился в клиента (совершил покупку), то нужно проанализировать последовательность его шагов к вожделенному продукту. В первом случае следует анализировать потоки, а во втором – последовательность операций!
В чем основное отличие? Поток – это перенос вещества, энергии или информации (в организационно-управленческих задачах чаще всего анализируются информационные потоки). Поток всегда имеет источник, потребителя и канал (тракт), в котором он перемещается. Например, Волга начинается с маленького ручейка (источника), впадает в Каспийское море (потребитель), имеет русло (тракт), в котором течет вода (поток вещества).
Пример: требуется снизить отток клиентов из небольшой компании, поставляющей компьютерные комплектующие (повысить конверсию). Руководители компании понимают, что первый шаг, который они должны сделать, – это ускорить реакцию на заявки клиента. Логично рассмотреть процесс движения заявок клиента по компании как поток, имеющий свои источники, потребителя и канал (схема 1.3).
Кстати, при анализе процессов в организационных системах редко встретишь чистую схему потока, аналогичную описанию движения реки Волги или схеме движения наполеоновских войск по России в 1812–1813 годах, составленную французским инженером Шарлем Минаром в 1869 г. (схема 1.4).
Еще пример: анализ процесса обработки банком кредитной заявки клиента.
На схеме 1.5 просматривается чистая схема процесса, в фокусе – сами операции, а не канал прохождения информации. Более того, ширина канала и потери потока на схеме 1.5 анализу не подвергаются. В данном случае перед задачедателем не стоит цель сократить потери потока, как в предыдущем случае. Необходимо оптимизировать процесс обработки заявок. Это в конечном итоге должно привести к сокращению времени и количества операций на проверку контрагента при требуемой достоверности результата. Иначе говоря, требуется отсеять как можно больше ненадежных плательщиков, с одной стороны, а с другой – как можно реже отказывать надежным заемщикам.
Второй вариант постановки задачи по схеме 1.5 – повысить качество отбора заемщиков, не усложняя процесс. В таком случае анализ потерь потока не имеет смысла, так как конкретные информационные потоки не анализируются.
Кстати, задача оптимизации бизнес-процессов неплохо решается при применении нотаций описания бизнес-процессов с последующим переходом к возможностям функционального анализа, в этом случае функциональное моделирование можно проводить прямо на схеме процесса. Но подобные изыскания лучше вынести за пределы данной книги, наша с вами задача – разобраться в несложных инструментах анализа…
При необходимости можно поглубже залезть в задачу, изображенную на схеме 1.5: разбить процесс на информационные потоки. Для этого потребуется потоки конкретизировать и анализировать, рассматривая потери, бутылочные горлышки и застойные зоны. А дальше, как вы понимаете, потоки можно не только рассматривать по отдельности, но и накладывать друг на друга, имея перед глазами схему бизнес-процесса. Наложение потоков даст ряд интересных задач.
Очень важно не путать понятия «потери потока» и «потери времени». Потери времени прекрасно видны и в схеме, изображающей поток, и на схеме бизнес-процесса, а вот с анализом потерь потока нормально справляется только анализ потоков, так как он позволяет схематично изобразить тракт потока и сам поток.
В общем, основная мысль следующая: если вам нужно анализировать поток (его скорость, потери, преобразования, искажения, изменение направления и т. д.), применяйте анализ потоков, для чего как минимум нужно понимать, что течет в потоке и каков тракт потока. Если же вам важно оценить временные затраты на операцию и потери времени между операциями, целесообразность той или иной операции, выявить неоправданное дублирование операций, определить перегруженные или недогруженные операции и т. д., не вникая в структуру потока между этими операциями, то используйте анализ последовательности операций. В этом случае проще всего применять стандартные нотации бизнес-процессов, в первую очередь BPMN.
Анализировать процесс следует, если после разбора схемы, полученной на шаге 3, вы обнаружили дефекты процессов между элементами системы. В этом случае следует провести анализ потоков в указанном месте схемы или описать процесс с помощью нотаций, например, BPMN, с целью поиска недостатков процесса.
В ходе анализа потока (схема 1.3) выявляются следующие дефекты.
1. Потери. На каком участке потока и сколько потока вещества, энергии или информации теряется?
2. Бутылочные горлышки (сужение канала потока). Есть ли такие в системе? Если есть, нужно устранить.
3. Застойные зоны (торможение скорости потока). Это тоже типовой дефект в потоке, требующий устранения.
4. Серые зоны – места, где решателю непонятно, что происходит с потоком. При наличии в потоке серых зон ставятся задачи по их прояснению.
Необходимо отметить, что потоки бывают не только полезные, но и вредные (например, потоки фоновой информации, искажающие основные информационные потоки, потоки вредных веществ и нежелательной энергии и т. д.). При решении задач на вредные потоки, напротив, в поток добавляют застойные зоны, бутылочные горлышки, управляемые потери. При моделировании таких потоков ставятся обратные задачи. Подробнее об анализе потоков читайте в моей книге ТРИЗ. Решение бизнес-задач. Так, на схеме 1.4 изображен вредный для России поток – вторжение наполеоновских орд в 1812 году, которые нужно было как можно быстрее и ценой наименьших потерь разбить и выдворить вон. Как вы знаете из истории, логика работы с вредным потоком была блестяще реализована.
Вернемся к полезным потокам. Если внимательно посмотреть на схему 1.3, мы увидим дефекты, по которым можно поставить следующие задачи:
1. Застойная зона по заявкам с сайта и почты. Специалист, работающий с заявками, быстрее всего реагирует на заявки, приходящие с мессенджеров, так как получает мгновенные уведомления. Заявки с сайта и почты (заявки с сайта автоматически приходят на почту) обрабатываются дольше, иногда клиенты ждут ответа 2–3 часа, так как специалист забывает контролировать почту. Задача: как сделать так, чтобы уведомления о заявках, приходящих на почту, поступали мгновенно?
2. Потери. Мы видим следующие потери:
a) потенциальные покупатели ушли, не дождавшись ответа: задача поставлена в п. 1;
b) нашли дешевле у конкурентов. Как сделать так, чтобы идентифицировать покупателей,
готовых купить дороже взамен на другие ценности (сервис, гарантии, скорость, надежность поставки и т. д.?) и показать им эту ценность? Сомневаюсь, что стоит ставить задачу о том, чтобы потенциальные покупатели не уходили к конкурентам за информацией;
c) не смогли согласовать цену с клиентом. Как сделать процесс согласования цены простым и понятным для клиента и для сотрудника;
d) не устроили условия доставки. Какими путями можно улучшить условия доставки/
самовывоза?
3. Бутылочное горлышко – консультирование. В момент консультирования клиента ответы на
заявки приостанавливаются. С точки зрения потока скорость продвижения заявок притормаживается – наше сознание способно держать в фокусе только одну задачу. Значит, ставим задачу: как сделать так, чтобы в процессе консультирования клиента текущая работа с заявками не приостанавливалась (прием запроса, согласование, фиксация оплаты, постановка позиции в лист заказа, команда на отгрузку)? Данная задача поставлена представителем малого бизнеса, поэтому все эти задачи были решены в жестких ограничениях – найм дополнительных сотрудников не допускается.
4. Серых зон не обнаружено.
В результате будут найдены новые траектории и нежелательные эффекты, с которыми будем работать в дальнейшем. Возникшие идеи отправляем на парковку.
В ходе анализа последовательности операций (схема 1.5) выявляются следующие дефекты.
1. Излишние операции. Операции бывают создающие, контрольные и исправляющие. В ходе анализа выявляются операции, которые можно удалить из процесса, передав их функции другим операциям (в ТРИЗ удаление операции называется свертыванием). Подробнее о проведении свертывания читайте в книге ТРИЗ. Решение бизнес-задач.
2. Дублирующие операции. Устранение дублирующих операций происходит аналогично.
3. Неоправданно длительные по времени операции. В ходе анализа бизнес-процесса оценивается время на проведение операций, при необходимости ставятся задачи на сокращение времени операций.
4. Потери времени между операциями. В ходе анализа ставятся задачи по сокращению потерь времени между операциями.
5. Неиспользованные возможности распараллеливания. Если есть возможность сократить длину главного пути бизнес-процесса, увеличив количество параллельных операций без потери качества, такие задачи должны быть поставлены.
6. Бутылочные горлышки. Если в процессе выявлены операции, представляющие собой бутылочные горлышки, нужно поставить задачи по их удалению (не путайте удаление бутылочных горлышек со свертыванием операций).
7. Если удалить бутылочное горлышко невозможно, его нужно рассмотреть как ключевое системное ограничение. Тогда ставится задача по созданию буфера перед такой операцией с целью бесперебойного функционирования ограничения (подробнее смотрите концепцию «барабан-буфер-канат» в теории ограничения систем). Задачи по системным ограничениям – отдельный пласт. Ключевые системные ограничения должны быть выявлены и по ним поставлены задачи.
В отличие от задач на вредные потоки, задачи на вредные бизнес-процессы встречаются нечасто. Но если вы столкнулись с подобной задачей, то прежде чем приступить к ее анализу, ознакомьтесь с методом диверсионного анализа. Сильно поможет.
© Антон Кожемяко.
Подробнее ознакомиться с бизнес-ТРИЗ вы можете, пройдя онлайн-курс Бизнес-ТРИЗ с возможностью прохождения международной сертификации по стандартам IBTA (international business TRIZ association).