Мне на ум приходит сравнение слабых звеньев в бизнесе с неправильно сросшейся после перелома костью, пусть в качестве примера будет лучевая кость (она в предплечье). Так происходит, если травма осталась без должного внимания, иногда из-за ошибок врачей. Если кость срослась неправильно, её нужно повторно сломать, собрать так, как должно быть и дождаться выздоровления.
Иллюстрация с выделенной лучевой костью, чтобы избавить мозг от раздумий по этому поводу и сфокусировать внимание на важном.
Точно также обстоят дела и бизнесе. Если в бизнес-процессе где-то нарушения, на выходе результат будет хуже, чем мог бы быть. Как та же кость: вроде, она срослась, и рука функционирует, но привычных нагрузок не выдерживает, на погоду ноет, да и анатомическая форма как-то изменилась и смотрится теперь не гармонично.
Различие между примером с переломом и бизнесом лишь в том, что кость нужно сначала сломать, чтобы увидеть последствия неправильного сращивания, а бизнес можно с самого начала выстраивать косо, оттого может казаться, что все идет так, как должно. Почему так? Потому, что сравнивать не с чем. Сравнить все же можно с конкурентами, но это внешнее сравнение, и оно не способно дать глубокое внутреннее понимание собственных промахов. А, если учесть, что два одинаковых бизнеса могут иметь очень разные процессы внутри, то такое сравнение не даст ничего, кроме понимания, что как-то можно лучше.
Процессы: декомпозиция
Тогда как понять, что нужно улучшать внутри своего бизнеса? Среди всего многообразия на рынке сервисов для контроля процессов в бизнесе, я хочу выделить простой, бесплатный и абсолютно индивидуальный инструмент для решения этой задачи. Я всегда начинаю именно с него, т.к. системы сквозной аналитики, коллтрекинги и CRM — это уже инструменты более тонкого контроля. Зачастую они платные.
Для начала стоит посмотреть на общую картину, как бы в максимальном её удалении, чтобы охватить целиком. Так находятся уязвимости, с которыми можно поработать в приближении.
Суть декомпозиции
Декомпозиция — это разделение целого на части. Суть проста — нужно учесть основные процессы, влияющие на бизнес и посмотреть, как они взаимодействуют. Чем больше факторов будет учтено, тем точнее получится модель, но таблица станет сложнее в исполнении, а вероятность допустить ошибку увеличится. Поэтому я рекомендую начать с самого простого учета и постепенно дополнять её, чтобы «туман» рассеивался.
Дальше и я покажу, как всё сделать в Гугл Таблицах. Примеры приведу средней сложности, т.е. не совсем простые, но и не особенно сложные, чтобы любой человек с минимальным пониманием, что вообще такое Гугл Таблица, смог адаптировать инструмент под себя и сразу применить.
Я разберу 3 примера и дам ссылки на шаблоны, чтобы можно было посмотреть всю структуру целиком, поиграться с показателями и подглядеть формулы. Каждая подобная таблица получается разной, поэтому примеры покажут несколько взглядов на «расщепление».
На звание лучшего программиста, оптимизатора или математика я не претендую. Вероятно, какие-то данные можно было эффективнее отразить в таблицах, а что-то можно и убрать, но мой мозг работает своим уникальным образом, и эти таблицы — отражение индивидуального мышления. В этом, кстати, прелесть таблиц — хи можно затачивать под себя как угодно, нет нужды привыкать к какому-то стандартному дашборду (так называется рабочая область с выведенными на неё показателями, термин универсальный) . Здесь всё как конструктор.
ДЕКОМПОЗИЦИЯ. Как решать большие задачи эффективно.
Пример 1. Организация обучающего мероприятия GisCamp
Это реальное мероприятие, и я изменил или скрыл некоторые цифры и данные для того, чтобы соблюсти финансовую тайну клиента. Цифры не важны, важен только принцип и его реализация.
Источник: dzen.ru
Декомпозиция в бизнесе или как управлять воронкой продаж
В любом бизнесе можно выделить массу бизнес-процессов, так же, как и продажи можно представить воронкой продаж. Эти понятия, скорее всего, знакомы уже большинству читателей. Для тех, кто подзабыл или не выучил домашнее задание небольшая вводная:
Бизнес-процессы — сегменты функционирования конкретного бизнеса, описывающие своей совокупностью все этапы его работы. Их можно представить цепочкой, начинающейся, например, от заказа клиента и обработки, до изготовления заказанного продукта и отгрузки.
Схема бизнес-процессов позволяет четко представлять руководителю все звенья бизнеса, взаимосвязи и зависимости, которыми живет компания. Также можно отследить, в каких процессах возникают проблемы и устранить их. Данные процессы можно сегментировать еще и еще, разделять их на несколько подпроцессов и отдельных действий для удобства рассмотрения и управления. Это и называют декомпозицией, но об этом чуть позже.
Воронка продаж — это также схема, но показывающая количество клиентов с первых холодных касаний и на выходе — в покупке или повторной покупке. Сверху находится самая широкая ее часть, а снизу — узкая. Воронка может состоять из множества этапов или из нескольких, все зависит от конкретного маркетингового отдела. Воронка позволяет отслеживать провисания в бизнесе, видеть сильные стороны и принимать на основе информации решения.
Итак, теперь мы все на одной волне и можем двигаться далее по теме. Переходим к уже названной декомпозиции бизнеса. Если вы уже расписали ваши бизнес-процессы, самое время пересмотреть их, где возникают задержки, неточности, на каком этапе.
Представим, что у вас магазин бытовой техники с собственным интернет-магазином. Обозначим основные бизнес-процессы:
- Клиент находит нужную технику и оставляет заявку на обратный звонок с целью уточнения деталей по комплектации и свойствам продукта.
- Заявка поступает в CRM вашего отдела продаж.
- Менеджер звонит клиенту и дает консультацию, закрывает на покупку.
- Клиент узнает нужную информацию и в идеальном случае — оформляет заказ прямо по телефону с оператором. Оплата по карточке.
- Заказ поступает в CRM.
- Заказ обрабатывается и передается на склад.
- Складские сотрудники комплектуют заказ.
- Готовый к отгрузке продукт отправляется к заказчику.
- Заказчик получает свою покупку.
Даже из такой простейшей цепочки можно узнать многое о эффективности работы ваших подразделений. Например, вовремя ли отгружаются заказы, все ли заказы обрабатываются оператором и администратором. Какое количество заявок оператор превращает в сделку.
Один из часто всплывающих подводных камней — заказ не доезжает до заказчика. Почему? Может быть возникла путаница в адресах, которую никто не потрудился потом поправить, возможно курьерская компания сработала недобросовестно.
Конечно, в случае с магазином техники, продаваемые продукты стоят дорого, и клиент не будет долго ждать после просрочки доставки, он быстро призовет компанию к ответу. Но в случае с небольшими покупками задержки могут всплыть уже в разгневанные отзывы покупателей. Вы как руководитель, можете об этом и не узнать или узнаете уже тогда, когда волна недовольства наберет угрожающую мощность.
Также нелишним будет узнавать, как курьер общается с покупателем (подпроцесс), ведь это зачастую больной вопрос. Вежливость и предупредительность курьера не менее важна, нежели вежливость оператора колл-центра. Способность курьера расположить к себе, дать консультацию по товару и вообще оставить о себе, а значит и о компании, хорошее впечатление — увеличивает вероятность новых заказов в будущем.
Прослеживая все звенья цепочки, вы вскоре сможете сделать выводы о том, что не так и что нужно менять. Заявок 140, а прозвонов 70, заказов после них 3. Оператор не справляется. Сервисы, вроде AmoCRM помогут вам узнать, какое время оператор затратил на каждый разговор, скольких обзвонил, как разговаривал. Возможно вам нужно расширить штат, а может быть оператор ленив и не хочет работать.
Воронка продаж и декомпозиция
Построим простую воронку продаж для интернет-магазина:
- 1000 человек увидело вашу контекстную рекламу.
- 100 человек перешли по контекстной рекламе на ваш сайт.
- 70 человек из 100 поюзали сайт.
- 10 человек оставили заявку на обратный звонок.
- 5 человек были закрыты на сделку менеджером.
Здесь мы можем выделить несколько конверсий
- Конверсия из показов рекламы в посетители сайта.
- Из посетителей в лиды (заявки).
- Из лидов в покупатели.
Детализируем воронку на 5 уровне
Менеджер получает заявку в CRM-системе и звонит клиенту. Что он говорит ему и что предлагает? Яркий пример декомпозиции не только бизнес-процессов, но и тактики продажи — предложение не самого товара, а услуги для него. Бесплатные замеры, бесплатные консультации.
Человек может не согласиться купить сразу по телефону, но, если к нему отправится замерщик (монтажник), проведет необходимые мероприятия, даст пару рекомендаций и при этом может рассказать о компании и продукте — вероятность того что сделка состоится увеличивается в разы. Таким образом, мы выделяем подпроцесс — предложение предварительной услуги в которую упаковываем презентацию и строим предложение оператора не на продаже, а на предложении бесплатной услуги.
В вашем бизнесе также найдется множество бизнес-процессов для преобразования по модели декомпозиции. В вашей воронке продаж также можно насчитать множество ступеней, главное — грамотно декомпозировать (делить процессы на подпроцессы).
Что будет, если не пользоваться данным подходом?
Без построения воронки продаж и отладки бизнес-процессов, ваше дело всегда будет во многом работать неопределенно и непредсказуемо. Также вы не будете знать о том, как можно работать с потенциальным клиентом наиболее эффективно. Декомпозиция бизнеса нужна для выявления тех областей вашей деятельности, которые требуют внимания и на которые вы можете положительно повлиять.
Это сегментирование работы с целью лучшего понимания ее деталей и получения возможности их отладки. И это только первое приближение. В дальнейшем вы сможете достаточно точно представлять себе, сколько нужно затратить бюджета для получения определенной посещаемости сайта, какие именно предложения в вашем случае особенно хорошо влияют на покупателей.
Вы можете пользоваться такими сервисами как Roistat – в нем уже заложены многие функции для настройки собственной вороник продаж, аналитики рекламных каналов, коллтрекинг, интеграция с CRM и многие другие важные механизмы современного ведения бизнеса.
Если хотите быстро разобраться и проработать бизнес-процессы вашей компании, обращайтесь за консультацией по номеру 8-800-700-33-89 или оставляйте заявку.
До встречи в следующих статьях!
Источник: kelevro.ru
Декомпозиция процессов в нотации BPMN в Business Studio
По ходу моделирования бизнес-процессов в нотации BPMN в Business Studio схемы часто становятся слишком сложными, что снижает их визуальную наглядность, повышает трудоемкость анализа и принятия решений, затрудняет регламентацию. На громоздкой, запутанной схеме сложно выявить и устранить логические ошибки. Часто бывает так, что схема включает действия, которые являются фрагментами других процессов. Возможные причины — недостаточно продуманная архитектура бизнес-процессов организации, отсутствие навыка определения границ процессов, использования декомпозиции, применения типовых (повторно выполняемых) процессов.
Для того, чтобы сделать модель достаточно простой и наглядной можно:
- создать несколько подпроцессов;
- исключить со схемы действия, которые выполняются в рамках других процессов, и смоделировать взаимодействие с этими процессами (межпроцессное взаимодействие);
- использовать типовые (повторно выполняемые) процессы.
В любом случае, возникает практическая необходимость грамотно использовать методы декомпозиции и межпроцессного взаимодействия. Давайте их рассмотрим.
Создание подпроцессов
На рис. 1 показана схема процесса, включающая несколько задач (действий, операций). Документооборот и подписи шлюзов не показаны для упрощения восприятия схемы. Модель может рассматриваться в качестве учебного примера.
На рис. 1 выделены оранжевым цветом и обведены красными овалами группы задач, которые усложняют схему. По размеру они сделаны специально меньше (на практике я не рекомендую изменять размеры значков).
Рис. 1. Исходная схема бизнес-процесса
Начнем с группы задач, выполняемых Исполнителем Б. Они обведены красным овалом № 1. Вместо этой группы задач оставим одну — «Выполнить расчет и подготовить презентацию».
Далее декомпозируем эту задачу на нижний уровень, используя так же нотацию BPMN.
На рис. 2 видно, что у этой задачи появился маркер «+» внутри квадрата, а схема в целом стала выглядеть значительно проще.
Рис. 2. Создание подпроцесса
Что означает «Подпроцесс» в нотации BPMN? В отличие от полноценного процесса, для которого определяется так называемая «Процессная сущность» (уникальная структура данных) и могут запускаться отдельные экземпляры, подпроцесс в BPMN не имеет своей процессной сущности и является обособленной частью процесса в целом. Это удобно для моделирования (упрощения схемы процесса) и автоматизации.
Однако такой подпроцесс, поскольку он не имеет процессной сущности, невозможно «запустить» на исполнение другим процессом или использовать как типовой при проектировании других процессов в архитектуре.
В BPMN используется два понятия: Collapsed Sub Process («Свернутый») и Extended Sub Process («Раскрытый»). Первый показывается в виде задачи с маркером «+» внутри квадрата, второй — в виде схемы процесса. На рис. 3 показан пример: схема без Sub Process (вверху), Collapsed Sub Process (в середине) и Extended Sub Process (внизу).
В Business Studio в силу архитектуры этой системы невозможно показать на схеме процесса Extended Sub Process, только Collapsed Sub Process.
Рис. 3. Collapsed Sub Process и Extended Sub Process
При моделировании процессов в нотации BPMN в Business Studio довольно часто возникает ситуация, когда на схеме процесса указан один исполнитель, а на схеме подпроцесса возникает несколько дорожек с разными исполнителями.
Если на уровне процесса исполнитель — подразделение, а на уровне подпроцесса — сотрудники, то с этим еще можно мириться, принимая во внимание насущные задачи регламентации процесса. Но если подпроцесс на верхнем уровне выполняет конкретный исполнитель, а на нижем — куча других исполнителей, то это методическая ошибка.
Дело в том, что в Business Studio дорожки используются для назначения исполнителей задач. Это означает, что если мы помещаем какую-то задачу на дорожку исполнителя, то для этой задачи автоматически назначается этот же исполнитель с типом связи «Выполняет». Поэтому очень странно выглядит ситуация, когда на одном уровне задачу «выполняет» конкретный сотрудник, а ниже уровнем задачи «выполняют» уже совершенно другие сотрудники.
С точки зрения регламентации процессов и формирования должностных инструкций такое решение, на мой взгляд, недопустимо. Если бы мы использовали на верхнем уровне тип связи «Является владельцем» или «Отвечает» (такого типа связи по умолчанию нет в Business Studio, но его можно создать), а на нижнем «Выполняет», то такое решение можно было бы считать рациональным.
Обратите внимание, что в нотации BPMN (в отличие от решения, реализованного в Business Studio) дорожки вообще носят вспомогательный (иллюстративный) характер. Назначение исполнителей осуществляется для каждой задачи. Даже если мы назовем как-то дорожку, мы можем в BPMN назначить любых исполнителей.
На рис. 4 показана схема подпроцесса «Выполнить расчет и подготовить презентацию». В данном случае исполнитель тот же самый, что и на верхнем уровне, так что все корректно (с точки зрения регламентации в Business Studio).
Обратите внимание, что подпроцесс начинается с неопределенного события. Как правильно его называть в Business Studio? Часто я просто указываю «Нужно сделать что-то. » и т. п. в зависимости от сути выполняемых действий. Завершающее событие так же именовано по смыслу.
Рис. 4. Схема подпроцесса «Выполнить расчет и подготовить презентацию»
Рассмотрим далее группу задач 2 (см. рис. 1) и обсудим, как можно поступить в этом случае.
Запуск других процессов путем отправки сообщений
Обратите внимание на группу задач на рис. 1, обведенных овалом под номером 2. Его выполняют «Другие исполнители». Можно было бы создать несколько дорожек, но я специально не стал усложнять схему.
Создадим отдельный процесс под названием «Подготовить данные». Теперь этот процесс можно запустить на исполнение из Процесса А, организовав межпроцессное взаимодействие.
Измененная модель показана на рис. 5. Исполнитель А выполняет задачу «Запросить данные». После нее показано промежуточное событие «Запрос на предоставление данных», которое инициирует на выполнение процесс «Подготовить данные». Он показан в виде свернутого пула над схемой. От события к нему проведена стрелка типа Message Flow.
После отправки сообщения поток процесса идет далее и останавливается на событии ожидания сообщения «Предоставлены данные». Когда оно приходит из процесса «Подготовить данные», Процесс А продолжается. Выполняется проверка данных. Если данные некорректные, то происходит возврат и повторный запуск процесса «Подготовить данные». Видно, что схема процесса (рис.
5) стала значительно проще.
Рис. 5. Межпроцессное взаимодействие
Схема процесса «Подготовить данные» показана на рис. 6. Обратите внимание, что процесс запускается путем получения сообщения из Процесса А и завершается отправкой сообщения в Процесс А.
Рис. 6. Схема процесса сбора данных
На рис. 7 показаны возможные варианты моделирования межпроцессного взаимодействия путем отправки и получения сообщений. Поскольку в Business Studio такие примеры технически сделать нельзя, я использовал моделер Camunda.
Пример 1. Первый процесс запускается событием неопределенного типа, например человеком. После выполнения первой задачи отправляется сообщение, которое инициирует выполнение второго процесса. Стартовое событие второго процесса — сообщение. После выполнения двух задач второй процесс отправляет в первый ответное сообщение.
Первый процесс, в свою очередь, находится в режиме ожидания получения сообщения после выполнения третьей задачи.
Пример 2. Первый процесс отправляет во второй сообщение. Но проблема в том, что сообщение нельзя отправить в процесс, который еще не стартовал. Поэтому межпроцессное взаимодействие в Примере 2 возможно только в том случае, если второй процесс стартует раньше, чем первый отправит в него соответствующее сообщение. Эту особенность нужно учитывать, используя метод организации межпроцессного взаимодействия при моделировании в нотации BPMN.
Рис. 7. Возможные варианты межпроцессного взаимодействия путем отправки и получения сообщений
Представим себе ситуацию когда необходим сбор массива данных по одному и тому же алгоритму, но одновременно в разных подразделениях и разными исполнителями. В предыдущем примере мы запускали на исполнение только один экземпляр процесса «Подготовить данные». Как быть, если нужно запустить сразу несколько экземпляров этого процесса, получить и проверить данные? На рис. 8 показано, как это можно сделать.
Создан подпроцесс «Получить данные». Для него показан маркер параллельного многоэкземплярного цикла. Это означает, что этот подпроцесс будет запушен столько раз, сколько необходимо для сбора всех данных.
Рис. 8. Подпроцесс, созданный для отправки/получения сообщений
Схема подпроцесса «Получить данные» показана на рис. 9. Она достаточно проста и не требует комментариев.
Рис. 9. Схема процесса «Получить данные»
Использование типовых процессов
Еще одним достаточно интересным архитектурным решением является использование так называемых типовых или, другими словами, повторно выполняемых процессов. В нотации BPMN это называется Call Activity — вызов другого процесса в рамках уже выполняемого.
Обратите внимание на красный овал № 3 на рис. 1. На нем показаны задачи по согласованию документа. В данном, учебном примере использован параллельный метод согласования. Если у кого-то из согласующих лиц есть замечания, то после выполнения всех задач согласования, необходимо получить и проверить результаты (задача «Получить результаты согласования») и, при наличии замечаний, повторно выполнить подготовку документа. Возможны другие модели цикла согласования.
На практике часто бывает так, что процесс согласования является стандартным — определена последовательность задач и список участвующих в процессе руководителей. В этом случае совершенно нецелесообразно описывать такой цикл в каждом конкретном процессе, где необходимо что-то согласовать. Гораздо проще и практичнее описать цикл согласования как отдельный типовой процесс, а потом использовать его в виде готового решения в моделях других процессов.
В Business Studio создадим новую модель процесса в нотации BPNM под названием «Согласовать документ». Она показана на рис. 10.
Рис. 10. Процесс «Согласовать документ». Упрощенный учебный пример
На схеме Процесса А удалим группу задач согласования (овал № 3) и соответствующие дорожки, закроем схему, скопируем в навигаторе процесс «Согласовать документ» и вставим его как задачу в Процесс А, обязательно используя опцию «Вставить как ссылку», откроем схему Процесса А на редактирование и внесем необходимые изменения. На рис. 11 показана готовая схема Процесса А.
Задача «Согласовать документ» на дорожке Руководителя — это типовой (повторно выполняемый) процесс. В терминах Business Studio — это процесс-ссылка.
Содержательно, представленная конструкция означает следующее. После выполнения операции «Проверить документ» запускается типовой процесс «Согласовать документ» с параметрами (данными), определенными при выполнении Процесса А. При запуске создается отдельный экземпляр процесса «Согласовать документ». После его завершения продолжается Процесс А, в который передаются соответствующие данные по результатам согласования.
Кстати, если нам нужно запустить несколько экземпляров типового процесса, то можно использовать маркер многоэкземплярного параллельного (или последовательного — в зависимости от потребности) цикла. В данном примере для процесса согласования договора это лишено физического смысла, но в других ситуациях может понадобиться.
Рис. 11. Использование типового процесса
Как вы видите на рис. 11, схема процесса стала существенно проще и понятнее.
Кейс. Взаимодействие с типовым процессом путем отправки-получения сообщений
В одном из проектов при использовании типовых процессов возникла интересная практическая задача. Нужно было в рамках выполнения некоторого процесса:
- запустить на выполнение типовой процесс;
- продолжить выполнение процесса и:
- дождаться, когда внутри типового процесса будет выполнена определенная задача (сам типовой процесс еще не закончен), получить сообщение из типового процесса, обработать его и продолжить выполнение.
На рис. 12 показан фрагмент модели, которая решает поставленные задачи. После выполнения шага «Задача N» одновременно запускается типовой процесс и еще два потока работ.
Внизу схемы показано, что типовой процесс выполняется и затем данный поток работ завершается.
Средний поток («Задача N+1» и далее) продолжается своим чередом.
Верхний поток работ сразу останавливается и ждет получения сообщения из процесса «Подготовить данные» (свернутый пул).
Как работает такая модель? По ходу выполнения запущенный из нашего процесса экземпляр типового процесса отправляет сообщение, которое обрабатывается. Это кажется немного странным (и для многих спорным), но может использоваться.
Рис. 12. Фрагмент типового процесса
На рис. 13 показан фрагмент типового процесса, который отправляет нужное сообщение в рассматриваемый нами процесс.
Рис. 13. Фрагмент типового процесса
Сравнение трех методов «декомпозиции» процессов
Сравнение трех рассмотренных нами методов представлено в таблице 1.
- Визуальное упрощение схемы;
- Не возникает отдельный экземпляр для подпроцесса;
- Невозможно использовать в других процессах в качестве типового.
- Визуальное упрощение схемы;
- Необходимо внимательно отслеживать корректность синхронизации экземпляров процессов во времени;
- Для запуска нескольких экземпляров нужно создавать подпроцесс, отправляющий/принимающий сообщения.
- Визуальное упрощение схемы;
- Возможность использовать типовые процессы (Call Activity в BPMN, процесс-ссылка в Business Studio) в моделях разных процессов;
- Возможность запуска нескольких экземпляров типового процесса.
Итак, мы рассмотрели три метода, позволяющие сделать модель процесса проще и визуально нагляднее за счет декомпозиции и применения архитектурных решений.
Вы можете осознанно применять представленные методы при моделировании бизнес-процессов вашей организации с использованием Business Studio. Не стоит чрезмерно увлекаться каким-то одним методом. Нужно умело их комбинировать и использовать там, где это практически целесообразно.
Источник: www.businessstudio.ru