Как описывать бизнес процесс

Бизнес-процессы отдела продаж — это все действия, которые осуществляют продавцы на пути к сделке.

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

• Бизнес-процессы отдела продаж: что это такое
• Бизнес-процессы отдела продаж: продажа и обслуживания
• Бизнес-процессы отдела продаж: воронка продаж
• Бизнес-процессы отдела продаж: как описать за 4 шага

БИЗНЕС-ПРОЦЕССЫ ОТДЕЛА ПРОДАЖ: ЧТО ЭТО ТАКОЕ

Бизнес-процессы отдела продаж — это стандартный набор действий, которые выполняют ваши продавцы для того, чтобы получить результат.

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

По сути управление отделом продаж — это управление бизнес-процессами и этапами.

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

Бизнес-процессы отдела продаж делятся на основные и вспомогательные.

Основные бизнес-процессы обеспечивает прямую коммуникацию с клиентом. Основные бизнес-процессы отдела продаж это два процесса:

1. процесс продажи;***
2. процесс сопровождения.

Вспомогательные бизнес-процессы отдела продаж поддерживает выполнение основных процессов.

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

Варианты вспомогательных бизнес-процессов в отделе продаж:

1. Согласование условий Коммерческого предложения (КП);***
2. Составление и согласование договора;***
3. Разработка ценового предложения для клиента;***
4. Согласование условий поставки товара или внедрения услуги.

На вспомогательные бизнес-процессы менеджер отдела продаж может тратить от 30 до 50% своего времени. Это время он отнимает от основной задачи — продаж и коммуникации с клиентом.

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

Ваш продавец может согласовывать условия выставляемого клиенту Коммерческого предложения с экспертом технической службы. И в этом случае процесс продажи становится длиннее на время, в течение которого происходит это согласование. Также и с подготовкой договора.

Задача управления бизнес-процессами отдела продаж — выявлять проблемные места на стыках и устранять их.

Для этого необходимо описать все бизнес-процессы отдела продаж.

Таким образом кроме основного бизнес-процесса вам необходимо будет описать следующие суб-процессы отдела продаж:

1. Процесс подготовки КП;***
2. Процесс согласования КП;***
3. Процесс подготовки договора;***
4. и т.д.

Рассмотрим основные стадии бизнес-процессов отдела продаж: привлечения клиентов и обслуживания.

БИЗНЕС-ПРОЦЕССЫ ОТДЕЛА ПРОДАЖ: ПРОДАЖА И ОБСЛУЖИВАНИЕ

Бизнес-процесс продажи и обслуживания в В2В состоит из 6 (шести) генеральных стадий. На каждой стадии может быть несколько этапов.

СТАДИИ БИЗНЕС-ПРОЦЕССА ПРОДАЖИ И ОБСЛУЖИВАНИЯ

1. Стадия Leads Generation***Стадия генерации лидов. Трафик может создаваться вашими маркетологами за счет форм захвата на сайте или лендинге, рекламы в соцсетях и в директ. Если отдел продаж делает исходящие холодные звонки, то на этой стадии вам необходимо подготовить базу для прозвона. Это подготовительная стадия. Поиск лидов может осуществляться вашими продавцами-хантерами на выставках и конференциях или с помощью холодных звонков.***Особенность этой стадии: если генерация лидов осуществляется с помощью исходящего холодного звонка, то эту функцию выполняет менеджер-хантер. А если привлечение корпоративного клиента осуществляете на профильных мероприятиях, эта задача может решаться менеджерами-клоузерами. При этом их распорядок дня и KPI должны в дальнейшем корректироваться c учетом необходимости выделения времени на исходящий обзвон новых лидов.///
2. Стадия Leads Development***Стадия утепления и развития лидов. На этой стадии бизнес-процесса продажи менеджер-хантер обрабатывает входящий звонок потенциального клиента или делает исходящий первичный холодный звонок. На этой стадии осуществляется квалификация лида с определением его категории, потенциала и вероятности сделки. С помощью квалификации менеджер определяет дальнейшую стратегию продажи клиенту для данной категории.***Хантер должен утеплить лид до стадии признания потребности и получить от него согласие на выставление Коммерческого предложения (КП).///
3. Стадия Leads Conversion***Стадия закрытия лида в сделку. Самая сложная стадия бизнес-процесса продажи. На ней продавец-клоузер должен согласовать заказ, провести переговоры по цене и закрыть лид в сделку. Часто на этой стадии лид «зависает», происходит несварение в трубопроводе продажи, бизнес-процесс замедляется.***Задача РОПа внедрить такие техники продаж, которые научат менеджеров завершать эту стадию как можно быстрее и завершить ее подписанием договора и получением денег.///
4. Стадия Сlient Fulfillment***Стадия исполнения условий договора. Считается, что эта стадия бизнес-процесса продажи является самой простой. Однако задача этой стадии на выходе получить лояльного клиента готового к повторному заказу. Поэтому несмотря на то, что на предыдущей стадии бизнес-процесса продажи вы «зкрыли» клиента, на этой стадии вы его «открываете» для долгосрочного и качественного сотрудничества.///
5. Стадия Account Management***Стадия возврата, удержания и развития клиента. На этой стадии менеджер по сопровождению клиентов осуществляет не только сбыт продукции по предварительным заказами или плану продаж, но и увеличивает свою долю в клиенте.***Задача компании повысить показатели LTV и NPS. Эти показатели полностью зависят от качества работы клиентских менеджеров.///
6. Стадия Key Account Management***Стадия обслуживания ключевых и ВИП клиентов выделена в отдельный блок бизнес-процесса продажи для того, чтобы указать на исключительную важность работы с важными клиентами. Эти клиенты требуют особых техник продаж и этапы работы с ними в бизнес-процессе могут отличаться от этапов работы на предыдущей стадии.

Все стадии бизнес-процессов продажи и обслуживания описываются в деталях.

Помните, что каждая стадия может быть описана как отдельный процесс. Например стадия Leads Generation — это отдельный процесс по лидогенерации. В нем несколько этапов, каждый должен быть описан и понятен исполнителям.

БИЗНЕС-ПРОЦЕССЫ ОТДЕЛА ПРОДАЖ: ВОРОНКА ПРОДАЖ

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

Типовые этапы бизнес-процесса продажи для рынков В2В:

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

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

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

БИЗНЕС-ПРОЦЕССЫ ОТДЕЛА ПРОДАЖ: КАК ОПИСАТЬ ЗА 4 ШАГА

ШАГ 1. РАЗБЕЙТЕ БИЗНЕС-ПРОЦЕСС ПРОДАЖИ НА ШАГИ — ЭТАПЫ

Разбейте бизнес-процессы отдела продаж на шаги. Желательно не превышать 7-12 шагов. Это то количество, которое ваши менеджеры смогут запомнить. Если шагов больше, то следует их объединить.

Назовите шаги бизнес-процесса продажи отглагольными существительными. Т.е. не «Согласовать КП», а «Согласование КП».

ШАГ 2. ОПИШИТЕ ЭТАПЫ БИЗНЕС-ПРОЦЕССА ПРОДАЖИ

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

1. Назовите каждый шаг этапа бизнес-процесса: дайте ему определение, используйте в названии действия специалиста, которые осуществляет этап;***
2. Определите исполнителя этапа: назначьте менеджера, который должен осуществить данный этап бизнес-процесса продажи;***
3. Определите «вход» в этап, т.е. то, что начинает этап: например входящий звонок. Вход этапа будет выходом предыдущего этапа;***
4. Определите поставщика этапа, т.е. сотрудника, который обеспечивает вход этапа: выясните, кто осуществляет предыдущий этап, им может быть иной сотрудник чем исполнитель;***
5. Определите «выход» этапа, т.е. результат, который должен быть достигнут в результате данного этапа;***
6. Определите клиента этапа, т.е. сотрудника, который должен использовать выход этапа: определите, кто будет использовать результат этого этапа — это может быть исполнитель, а может быть иной сотрудник;***
7. Определите задачи, которые должны быть решены на каждом этапе: перечислите подробно цели и задачи, которые решает менеджер на этом этапе;***
8. Определите действия, которые должен осуществить исполнитель на этапе: опишите подробно все действия, которые должен совершить сотрудник на этом этапе;***
9. Определите КФУ (ключевой фактор успеха) для этапа: определите, какое действие менеджера предопределит получение нужного результата на этом этапе; это может быть компетенция и навык менеджера;***
10. Определите требования для CRM для дальнейшей наладки в системе (факультативно): опишите, какие функции в CRM должны быть доработаны для того, чтобы можно было автоматизировать этот бизнес-процесс.

Опишите этапы бизнес-процессов отдела продаж as is, то есть таким, какой он есть сейчас.

Затем опишите бизнес-процессы отдела продаж as to be, т.е. такими, какими они должны стать после исправления «узких» мест.

ШАГ 3. ОПРЕДЕЛИТЕ ЗОНЫ РАЗВИТИЯ В БИЗНЕС-ПРОЦЕССАХ ОТДЕЛА ПРОДАЖ

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

ШАГ 4. ОПРЕДЕЛИТЕ ПОКАЗАТЕЛИ БИЗНЕС-ПРОЦЕССОВ ОТДЕЛА ПРОДАЖ

Сформулируйте показатели бизнес-процесса. Они могут быть сформулированы для каждой стадии. Показатели бизнес-процесса продажи измеряют результативность или эффективность этапов.

Показатели могут быть итоговыми (догоняющими) и промежуточными (обгоняющими).

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

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

После того, как вы описали бизнес-процесс продажи, составьте план действий (Action plan) по улучшению этапов. Разработайте дополнительные технологии продаж, материалы для менеджеров, скрипты и примеры писем.

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

Источник: activesalesgroup.ru

Как описать бизнес-процесс в нотации BPMN

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

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

Следуйте этим пунктам и составление бизнес-процесса пройдет быстро и без критических ошибок:

1. Получить список действий.
2. Определить исполнителей
3. Перевести действия в задачи.
4. Вычислить финалы процесса.
5. Назначить действия исполнителям.
6. Описать условия (шлюзы).
7. Описать внешние по отношению к процессу сущности.
8. Переложить описания в нотации.

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

Кроме того, здесь я не буду говорить об исполняемых бизнес-процессах. При их составлении есть свои правила, особенности, ограничения. Здесь пойдет речь о составлении бизнес-процесса в нотации BPMN, предназначенного для анализа работы.

Получить список действий

Первое, что вам нужно после того, как вы провели интервью с людьми, которые участвуют в процессе, это получить список действий.

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

Как из описания сделать список действий

Давайте разберемся подробнее, как это сделать максимально быстро и корректно:

1. По итогам интервью составьте текстовое описание. Например:«При необходимости в товаре которого нет в наличии продавец создает документ “Заявка на закупку” и направляет его на согласование закупщику. Закупщик проверяет необходимость в закупке данного товара и если закупщик разрешает закупить товар согласно документу “Заявка на закупку”, то продавец информируется о разрешении закупить товар, и закупщик создает документ “Заказ поставщику”. Иначе заявка аннулируется с комментарием содержащем причину отказа в закупке товара. Продавец информируется об отказе в закупке товара.» Естественно, это может быть не одно и не два интервью, некоторые вещи вы можете взять из документации (инструкции, формы документов). Но основной источник все таки интервью, так как вы делаете работу для людей и они будут работать с ней.
2. Уберите лишнее. Посмотрите на текст внимательно, избавьтесь от ненужных слов. В приведенном примере убрать следует фразу «которого нет на складе». Независимо от того, есть такой товар или нет, если возникает необходимость в товаре от поставщика, потребуется “Заявка на закупку” . То есть с точки зрения выполнения, не имеет значения почему сотрудник дело то или иное действие. Нам не интересны вопросы “почему” и “зачем”, нам интересен ответ на вопрос “что делает”, чтобы затем получить “что сделать”. Мотивация сотрудников не касается нас в данном случае.
3. Выделите действия. В том же примере я выделил их подчеркиванием:«При необходимости в товаре продавец создает документ “Заявка на закупку” и направляет его на согласование закупщику. Закупщик проверяет необходимость в закупке данного товара и, если закупщик разрешает закупить товар согласно документу “Заявка на закупку”, то продавец информируется о разрешении закупить товар, и закупщик создает документ “Заказ поставщику”. Иначе заявка аннулируется с комментарием, содержащем причину отказа в закупке товара. Продавец информируется об отказе в закупке товара.» А как же вычислить действия? Обыкновенно — это глаголы. Все просто.

1. Продавец создает документ “Заявка на закупку”
2. Закупщик проверяет необходимость в закупке данного товара
3. Если закупщик разрешает закупить товар
4. Продавец информируется о разрешении закупить товар
5. Закупщик создает документ “Заказ поставщику”
6. Иначе заявка аннулируется с комментарием
7. Продавец информируется об отказе в закупке.

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

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

Перевести действия в задачи

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

Как определить, какое действие является задачей, а какое — нет? Задача — это то действие, которое выполняет непосредственно исполнитель, т.е. он один и более никто. Например, “согласовать сделку” не может быть задачей, так как здесь выполняется несколько действий. в которых принимают участие разные люди. Это уже не задача, а процесс.

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

В BPMN такой возможности нет. Потому здесь задача должна быть самым простым действием. В этой нотации имеются подпроцессы (Sub-Process) или подзадачи (Sub-Task). Эти возможности мы будем рассматривать позже. Здесь и сейчас я говорю именно о задачах.

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

Назначить действия исполнителям

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

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

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

Вычислить финалы процесса

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

Например, это может быть «Если необходимости в товаре нет, закупщик аннулирует заявку и отправляет уведомление продавцу».

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

Описать условия (шлюзы)

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

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

Эти условия в BPMN называются шлюзами. Их обязательно нужно предусмотреть и описать.

Описать внешние по отношению к процессу сущности

При описании любого бизнес-процесса вы столкнетесь с двумя типами сущностей:

1. Внутренние — те, которыми мы управляем внутри процесса. Это взаимоотношения внутри компании или подразделения, если бизнес-процесс описывает только какую-то часть работы компании. Ими вы можете управлять, т.е. изменить в случае необходимости последовательность задач, ответственных за выполнение и т.д.
2. Внешние — такие, которыми мы не можем управлять. Это сущности, которые необходимы для достижения результата, но сами они находятся за рамками вашего бизнес-процесса. Самый простой пример – поставщики, сотрудники транспортных компаний, клиенты. В некоторых случаях в число внешних сущностей также входят другие подразделения компании, например, бухгалтерия или производство. Например, вы описываете работу отдела продаж, а другие подразделения работают хорошо, и руководитель компании не желает там ничего менять. В любом случае от их действий зависит получение результата, но управлять ими вы не можете.

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

Переложить описания в нотации

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

1. Задачи. Это прямоугольники с закругленными краями, внутри которых вы пишете название задачи.
2. Шлюзы. Условия выглядят ромбами. Разместите их на диаграмме.
3. Соедините между собой задачи и шлюзы стрелками.
4. Укажите список исполнителей, а также исполнителя для каждой задачи.
5. Сверху разместите «внешний пул», т.е. все внешние сущности, и свяжите их с нужными задачами.

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

Взаимодействие диаграммы и описания диаграммы

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

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

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

С одной стороны, текстовое описание — это отправная точка для создания диаграммы. С другой — это не какой-то незыблемый и неизменяемый документ. При изменении графики текст также должен изменяться.

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

Советы по описанию

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

1. Чем меньше задач, тем лучше. Не стоит детализировать работу больше, чем это действительно необходимо. Причина проста: чем больше элементов на диаграмме, тем проще запутаться. К тому же с возрастанием количества элементов на диаграмме увеличивается ее сложность, а соответственно и труднее соблюсти баланс между информативностью и легкостью восприятия.
2. Не усложняйте. В BPMN есть возможность совмещать события и задачи (task). По возможности лучше избегать подобных решений, разделяйте их, делайте диаграмму максимально простой и читабельной.
3. Описывайте процессы, которые вы можете представить в реальности. Всегда помните о цели – вы описываете не просто что-то умозрительное, но последовательность работы реальных людей. Потому, если вы не можете представить то, что описываете, лучше вообще не делать такое описание.
4. Старайтесь быть лаконичными. Избегайте больших текстов.
5. Никогда не пользуйтесь в описании задач союзом «и». Недопустимо называть задачу «договориться о доставке и подготовить заказ к отгрузке». Это две отдельные задачи.

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

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

Надеюсь, что предложенный выше алгоритм работы поможет вам быстро и безошибочно строить описания BPMN-диаграмм для ваших бизнес-процессов.

Кинзябулатов Рамиль

Бизнес консультант

Бизнес-консультант с большим практическим опытом работы в России и ближайшем зарубежье. Автор многочисленных публикаций и нескольких книг по оптимизации и автоматизации бизнеса. Живу и работаю в Москве, руководитель компании Trinion. Делюсь опытом посредством блога на сайте trinion.org

Вам также может понравиться

Организация работы склада. Описание. BPMN схемы прилагаются

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

Краткое описание BPMN с примером

Что такое BPMN – определение и подробное описание нотации. Из чего состоит BPMN, основные элементы бизнес-моделирования: как их правильно использовать. Различия между исполняемыми и неисполняемыми бизнес-процессами. Как работать с BPMN на практике.

Что такое бизнес-процесс и описание бизнес-процесса

Определение бизнес-процесса простыми словами и важные особенности процессного подхода. Когда необходим бизнес-процесс, методы моделирования бизнес-процессов и правила их описания. Примеры, ответы на частые вопросы.

Что такое бизнес: разговор по понятиям

Что означает термин «бизнес» — уточняем понятия и терминологию. История появления слова «бизнес» — на Западе и в России. Отличие бизнеса от трудовой деятельности. Бизнес в отношении к субъекту и объекту. Что такое бизнес-процессы и как с ними работать.

Разбираемся с понятием BPM. Что такое управление бизнес процессами

Что такое управление бизнес-процессами (BPM) и зачем процессный подход нужен в бизнесе. История появления управления бизнес-процессами. Основные подходы и терминология – описание простыми словами. Процессный и функциональный подходы.

Описание нотации IDEF3

Что из себя представляет нотация IDEF3. Из каких элементов состоит? Как используют эту нотацию и как она связана с IDEF0. О этом и многом другом вы узнаете из данной статьи.

Описание бизнес-процессов Как есть (AS IS) и Как должно быть (TO BE)

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

Что такое DFD (диаграммы потоков данных)

Подробное описание DFD (диаграмм потоков данных). Определение и методы использования. Зачем нужны DFD-нотации, где они применяются на практике, и как их быстро создавать. Вопросы и ответы по DFD-нотациям. Простые методы работы с DFD.

Как описать бизнес-процесс в нотации BPMN

Как показывает практика описания процесса, для многих людей непонятно в какой последовательности описывать процесс. Прочитав данную статью вы поймете как описывать и какой минимальный набор действий необходимо сделать для получения описания процесса в нотации BPMN. Вы также можете использовать последовательность описанную в статье и для описания процесса в нотации IDEF3.

Источник: trinion.org

Что такое нотация BPMN: как описать бизнес в виде схемы из квадратов и стрелочек

BPM-эксперт Георгий Ржавин — о том, как понятно описывать бизнес-процессы.

Если вам интересна эта статья, то точно пригодится наша шпаргалка «33 ошибки начинающего руководителя. Как не развалить команду в первый месяц»

Картина прозрачных бизнес-процессов помогает компании быть «живой». Если менеджер не видит вклад своего отдела в успех всего бизнеса или сотрудник не знает, как дальше будут использовать результат его работы, — у компании проблемы.

Чтобы этого не допустить, можно пользоваться нотацией BPMN — удобным инструментом описания бизнес-процессов. Когда они визуализированы, их проще автоматизировать, масштабировать — и вести бизнес вперед.

Георгий Ржавин — руководитель BPM-направления в GlowByte Consulting и вице-президент Ассоциации профессионалов управления бизнес-процессами. Уже более 10 лет он работает в сфере BPM — внедряет эту нотацию в процессы банков, строительных организаций, юридических и торговых компаний.

В этом интервью Георгий объяснил, что такое BPMN, из-за чего бизнес становится непрозрачным для собственника, почему команды бывают против описания процессов и как это решить.

Что такое нотация BPMN простыми словами

Объясняя ребенку, я бы сказал: «Нотация BPMN — способ описать бизнес в виде схемы из квадратиков и стрелочек». Стрелочки показывают логику работы бизнеса, а квадратики — людей и сервисы.

Если более формально, то нотация BPMN — это способ описать процессы в компании языком, одинаково понятным бизнесу, IT-специалистам и даже машинному интеллекту.

BPM, BPMN, BPMS — в чем отличия?

BPM (Business Process Management) — это управленческая дисциплина, свод знаний о том, как руководить компанией. Объединяющий термин.

BPMN (Business Process Model and Notation) — это способ, которым можно описать бизнес-процессы в рамках управленческой дисциплины BPM.

BPMS (Business Process Management Suite) — это класс программного обеспечения, IT-систем для управления и оптимизации бизнес-процессов.

Зачем нужна регламентация бизнес-процессов?

Руководителям подразделений регламентация позволяет увидеть цельную картину, а не только функционал, с которым они работают непосредственно.

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

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

Сравним компанию с автомобилем. Водитель понимает: «Поверну руль вправо — поеду вправо». Но если не знаешь, как ведет себя автомобиль, сложно предугадать, куда он направится при повороте руля. Так и в бизнесе. Если процессы не описаны — компания может «поехать» не туда, куда планировали.

Топ проблем бизнеса, если процессы не регламентированы

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

Вытаптывается «коровья тропа» — по ней привыкли ходить, не задумываясь. Когда-то она была эффективной, но потом заросла и перестала быть удобной.

Если в компании ходят по «коровьим тропам», этот бизнес:

#1. Не готов отвечать на вызовы рынка — в компании их не слышат, не успевают перестраиваться.

#2. Теряет управляемость. Руководители отрываются от операционной реальности и начинают принимать управленческие решения в «своем мире» — переставая видеть бизнес таким, какой он есть. Но если понимать, как все «бегает по процессам», решения будут более взвешенными и грамотными.

#3. Не может масштабироваться. Допустим, ваша услуга популярна, и вы хотите предоставлять ее в новом городе — открыть филиал. Как сделать все быстро и с таким же качеством?

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

Яркий пример — McDonald’s. В России, США и ЮАР у гамбургера Big Mac один и тот же вкус, а туалеты в ресторанах сети — одинаково чистые. Все потому, что у компании хорошо описанные и управляемые бизнес-процессы. McDonald’s их легко масштабирует — и делает цифровой двойник собственного бизнеса.

Что такое «модель бизнес-процесса»?

Есть хороший советский анекдот, который описывает проблему с результатом из-за процессов:

• Есть претензии к рукавам?
• Нет.
• А к пуговицам?
• Тоже нет. Но костюмчик вышел не очень.

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

Модель бизнес-процесса — это набор сквозных процессов, которые делятся на:

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

Выбирая уровень детализации, исходим от цели — для кого/чего описываем процесс. Если нужно:

• Описать бизнес для CEO — модель не будет перегружена нюансами.
• Дать сотрудникам регламент — прописать бизнес-процесс детальнее, с системами, объектами и ответственными в виде ролей (BPM рекомендует управлять компанией через роли).
• Сразу оживить процесс — логику прописать так подробно, чтобы не было двойного чтения и схема понималась однозначно.

Чему будете учить на курсе «Нотация BPMN»?

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

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

Проблемы, которые возникают при описании бизнес-процессов

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

В первом случае я часто вижу:

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

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

Да, есть «эксперты предметной области» — и у них нужно уточнять нюансы сферы, в которой настраивается процесс.

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

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

Если говорить о владельцах бизнеса, частая проблема там:

Непонимание, что BPM — про общую трансформацию. Нужно ориентироваться не на то, чтобы «просто внедрить CRM и работать дальше». Целью должно быть повышение эффективности через изменения. Если в каком-то подразделении запускается BPM-проект, но весь бизнес меняться не хочет, результативность стремится к нулю.

Как решить. Объяснять пользу BPM на практике. У меня есть нестандартный кейс — о том, как развивать процессный подход в атмосфере, где все сопротивляются.

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

Многие BPM-системы легко справятся с задачами электронного архива. Но это не их основная функция. Когда руководство получило то, что хотело, я начал постепенно автоматизировать все процессы компании— и показывать результаты.

Изменения очень понравились руководству — топ-менеджеры даже сказали, что всегда хотели внедрить такой подход. Изначально BPMS появилась как решение другой задачи, а сейчас все в компании — ее фанаты.

Источник: l-a-b-a.com