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

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

Что такое BPMN и почему это не язык программистов

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

Расшифровка снимает половину страха. BPMN - это Business Process Model and Notation, дословно «модель и нотация бизнес-процесса». Главное слово тут последнее: notation, обозначения. Не язык программирования, не среда разработки, не то, что запускается кнопкой. Договоренность о том, каким значком что рисовать.

Договоренность не чья-то личная: стандарт ведет международный консорциум OMG, а не отдельный вендор или редактор схем. Действующая версия нотации - BPMN 2.0: принята в 2011 году и стандартизована как ISO/IEC 19510. Заодно сниму вопрос, который задают каждый раз: новой версии BPMN не существует. Версия 2.0 применяется полтора десятка лет, никакой 3.0 в природе нет.

Теперь зачем оно собственнику. Вообще нотации - и BPMN тут не единственная - придумали ради одного: чтобы схему одинаково прочитали собственник, менеджер и подрядчик. Без общих правил каждый рисует свои прямоугольники, и через десять минут обсуждение съезжает с процесса на картинку: «а почему у тебя тут овал?». Стандарты моделирования существуют не ради красоты, а чтобы спор шел о деле. Любое построение отдела продаж рано или поздно упирается в один вопрос: а как у вас продают сейчас, по шагам?

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

И сразу про границы. Нотация BPMN описывает порядок выполнения работ и участников - и только его. Оргструктуру, ИТ-архитектуру, финансовую модель она не описывает. Не пробел, а сила: модель процесса остается читаемой за пять минут. Путаницу с соседями - BPMN и UML, BPMN и IDEF0 - разберу дальше отдельно. Моделирование тут вообще громкое слово для «нарисовать, как есть».

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

Десять значков, которых хватит на весь ваш процесс продаж

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

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

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

Кружок - событие (event). Тонкий контур - начало: «заявка поступила с сайта». Жирный - конец: «сделка закрыта», «клиент отказался». Финалов почти всегда несколько, и это нормально: отказ - такой же законный конец процесса, как оплата.

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

Прямоугольник со скругленными углами - задача (task). Вот тут глагол с объектом: «перезвонить по заявке», «выставить счет», «согласовать скидку». Одна задача - одно действие одного человека. Если внутрь просится союз «и», скорее всего, там спрятались две задачи.

Ромб - шлюз (gateway). Шлюзы в BPMN бывают разных типов, вам хватит двух: исключающий «или» (клиент согласовал - идем к счету, отказался - идем в закрытие) и параллельный «и» (счет выставляем и товар резервируем одновременно). Про шлюзы BPMN дальше будет отдельный разговор, здесь достаточно запомнить форму и то, что ромб задает вопрос, а не думает за менеджера.

Стрелки. Сплошная - поток управления (sequence flow), она задает порядок выполнения внутри вашей компании. Пунктирная - поток сообщений (message flow): письмо клиенту, его ответ, платежка в банк. Официально и то и другое называют соединяющими объектами, а на практике важно одно: путать сплошную с пунктирной нельзя.

Рамка вокруг схемы - пул (pool), полоса внутри нее - дорожка (lane). Пул - участник целиком: ваша компания, клиент, банк. Дорожка - роль внутри участника: менеджер, руководитель отдела, бухгалтер. Подробнее про них - в разделе про пулы и дорожки, там же и главное правило схемы.

Листок с загнутым углом - объект данных (data object). Счет, договор, карточка сделки. То, что задача порождает или берет в работу.

Прямоугольник с плюсиком - подпроцесс (sub-process). Используют подпроцесс ради одного: свернуть кусок, который сейчас не разбираем. «Согласование договора» одним блоком вместо семи шагов, и схема снова помещается на лист.

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

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

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

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

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

Что из полной спецификации можно смело пропустить

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

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

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

Как прочитать чужую схему, если ее принес подрядчик

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

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

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

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

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

Остановитесь на каждом ромбе. Один вопрос: по какому условию идет ветка? Не «что тут решают», а по какому признаку. «Клиент согласовал?» - условие. «Менеджер думает» - не условие, а дыра.

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

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

Разбирать по отдельности каждый BPMN элемент на чужой распечатке не нужно, эти формы вы отличите и так. Гораздо полезнее задать три вопроса.

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

Пул, дорожка и правило, которое нарушают почти все новички

Есть один признак, по которому за пару секунд видно, рисовал человек по правилам или по наитию. Связан он с рамками.

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

Теперь само правило. Сплошная стрелка потока управления работает только внутри одного пула. Между пулами - исключительно пунктир потоков сообщений. Без исключений.

Логика тут не про моделирование, а про жизнь. Внутри своей компании вы командуете: поставили менеджеру задачу - он ее делает. Клиенту задачу поставить нельзя. Вы отправляете счет, он платит или не платит, это обмен, а не управление. Сплошная линия из вашего пула в пул клиента читается буквально: «мы управляем действиями клиента». В нотации BPMN так нельзя, потому что в жизни так не бывает.

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

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

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

Шлюзы: где процесс расходится и почему это самое ценное место схемы

Если бы в чужой диаграмме мне разрешили смотреть только на один значок, я бы выбрал ромб. Прямоугольники показывают, что люди делают. Ромбы показывают, чего в компании нет. Шлюзы в BPMN рисуют именно ромбом, и по ним видно больше, чем по всей остальной картинке.

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

Шлюзов в BPMN описано больше, чем нужно живому отделу продаж. Рабочих шлюзов вам хватит двух.

Исключающий шлюз, в быту «или». Поток уходит в одну ветку. Клиент согласовал - идем к счету, отказался - идем в закрытие. Третьего маршрута нет. Тонкость: ветки обязаны покрывать все ответы, а не только «да» и «нет».

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

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

Теперь про ошибку, которую делают чаще всего. Ромб с подписью «менеджер решает» я вижу на каждой второй самодельной диаграмме. Шлюзы в BPMN ничего не решают сами: решение принимает человек внутри задачи, а ромб фиксирует, куда пойдет процесс дальше. Подписывайте вопросом с проверяемым ответом: «Клиент согласовал?», «Счет оплачен?», «Прошло три дня?».

А дальше - то, ради чего раздел вообще написан. Шлюзы в BPMN не создают правил. Они их обнажают. Спросите на планерке: что мы делаем, если клиент не ответил три дня? Если повисает тишина, а трое дают три разных ответа - ветки нет не в модели, ее нет в жизни. Сделки не проваливаются в CRM. Они висят, потому что никто не договорился, что с ними делать.

Шлюзы в BPMN стоят там, где вы когда-то приняли решение молча и никому не сказали. Моделирование просто выносит его наружу.

Рисуем процесс продаж за один вечер: семь шагов

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

Приготовьте лист А3 или свободный кусок стены, пачку стикеров и два маркера. Инструменты моделирования подождут: начинать с создания диаграммы в редакторе - верный способ убить вечер на выравнивание стрелок. Стикер переклеивается за две секунды, а блок в программе тянет за собой привязки и разъехавшиеся дорожки, и к третьей правке вы начнете беречь нарисованное вместо того, чтобы менять. Первый черновик BPMN схемы живет на стене, а в редактор диаграмма переезжает, когда перестает меняться каждые десять минут. BPMN элементы, которые понадобятся, вы уже знаете - те самые десять форм, и половина из них уйдет в дело.

Шаг 1. Один процесс, самый денежный. Не «опишем компанию», а продажи. Назовите его глаголом с объектом: «продать оптовому клиенту», «обработать заявку с сайта». Нет глагола в названии - вы описываете отдел, а не работу.

Шаг 2. Границы. С какого события начинается и каким результатом заканчивается. «Заявка упала в CRM» - «деньги пришли на счет». Границы важнее середины: пока их нет, описания бизнес-процессов расползаются на склад, на бухгалтерию и на «а еще у нас иногда бывает».

Шаг 3. Дорожки по ролям. Тем, которые есть сегодня, а не по штатке мечты. Правила использования дорожек мы разобрали выше: роль, а не человек. Обычно хватает трех полос - менеджер, руководитель, бухгалтер - плюс отдельный пул клиента.

Шаг 4. Действия в ряд, без развилок. Один маршрут - тот, по которому идут восемь сделок из десяти. Порядок выполнения слева направо, одно действие - один стикер. Тут почти все спотыкаются, потому что сразу вспоминают исключения. Не вспоминайте. Любой пример бизнес-процесса из интернета выглядит гладким потому, что нарисован задним числом.

Шаг 5. Развилки. Пройдите цепочку заново и на каждом шаге спросите: а бывает иначе? Клиент не ответил, попросил отсрочку, товара нет на складе. Каждое «бывает иначе» - ромб с вопросом и вторая ветка. Шаг самый долгий и самый полезный: обычно к нему вопросов больше, чем ко всем остальным вместе.

Шаг 6. Документы и данные. Счет, договор, карточка сделки, акт - стикером другого цвета рядом с задачей, которая их порождает. Полминуты работы, а подрядчику сразу видно, какие поля нужны в карточке сделки.

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

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

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

Зрелище неприятное, но полезное.

Три часа работы - и разговор с подрядчиком идет иначе. Вы приходите не с «настройте нам CRM», а с моделью на руках и списком развилок, у которых пока нет правил.

«Как есть» и «как надо»: две схемы, а не одна

Схемы BPMN бывают двух жанров, и путать их дороже всего.

«Как есть» (as-is) фиксирует реальность: с костылями, с двойным вводом в Excel, с менеджером, который ведет своих клиентов в блокноте. Некрасиво, зато честно - разрывы видны только на такой картинке.

«Как надо» (to-be) - целевая модель, по ней настраивают систему.

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

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

BPMN, IDEF0, UML и блок-схема: чем они отличаются и что брать для продаж

Стоит начать гуглить, как описать процесс, и на вас вываливается алфавитный суп: BPMN, UML, IDEF0, EPC, ArchiMate. Дальше включается логика отличника: сначала выберу правильную букву, потом нарисую. Логика вредная. Какие нотации, кроме BPMN, понадобятся для описания продаж? Ни одной.

Раз путаница живая, разложу четверку по назначению, а не по принципу «что лучше»: языки моделирования спорят между собой примерно как отвертка с молотком.

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

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

Пара BPMN/UML путается чаще остальных. UML - Unified Modeling Language, язык описания программного обеспечения: классы, компоненты, модель системы. Отличия BPMN и UML начинаются с адресата: язык писали для того, кто будет кодить. А путаницу создает activity diagram - внешне почти то же самое, стрелки и ромбы. Отсюда живучая формулировка «BPMN - тот же UML, только для бизнеса». Неточная: BPMN и UML не родственники и не диалекты друг друга. Работать рядом BPMN и UML могут спокойно - разработчику своя картинка, вам своя.

Свободная блок-схема из Word - вообще не язык моделирования, а рисунок по вкусу автора. Отличие не в красоте: диаграмма любого стандарта выглядит как прямоугольники со стрелками. У блок-схемы стандарта нет: овал у одного значит «начало», у второго - «решение». Свобода приятная до первого использования рисунка кем-то, кроме автора.

Коротко: BPMN и UML разводит адресат, BPMN и IDEF0 - этап работы. EPC упомяну строкой: немецкая школа, живет вокруг SAP, малому бизнесу не нужна.

Что брать для моделирования продаж? BPMN. По модели процесса будут работать менеджер, бухгалтер и подрядчик, а не только автор рисунка. И если мучает страх ошибиться с выбором - выдохните: вопрос «какую именно нотацию брать» у вас закрыт. В моделировании бизнес-процессов малого бизнеса IDEF0 мне пригодился дважды, UML - ни разу.

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

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

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

Существительные вместо глаголов. «Договор», «оплата», «клиент». По такой подписи не понять, кто и что делает: договор составили, согласовали или подписали? В прямоугольнике всегда глагол с объектом - «выставить счет», «согласовать скидку». Существительное уместно у объекта данных, пула и дорожки. У события - сказуемое: «счет оплачен», а не «оплата».

Ромб «менеджер решает». Говорил выше, повторю - ошибка живучая. Развилка не думает, она разводит поток по условию из данных. Подпись - вопрос с проверяемым ответом.

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

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

Когда мы в 1PI.PRO садимся разбирать продажи перед настройкой Битрикс24, специально искать ошибки не приходится. Собственник ведет маркером по цепочке, доходит до звонка клиенту и останавливается. А если не ответил? Пауза. «Ну, менеджер сам смотрит». Ветки нет. Дальше открываем CRM - и зависшие сделки лежат в той точке, где ветки нет на бумаге. Элементы BPMN тут ни при чем, они просто подсветили место, где в компании не договорились. Повторяется из проекта в проект: кейсы внедрения разные, а точка одна.

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

Где рисовать: чем открыть схему и не потратить на это неделю

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

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

Бесплатный онлайн-редактор. Чистовик - переносите схему сюда, когда правки стали редкими. Единственная техническая придирка на весь раздел: смотрите не на красоту интерфейса, а на то, выгружает ли редактор файл в формате BPMN, а не только картинку. Разница вылезет у подрядчика: файл он откроет и допишет, а присланную картинку перерисует с нуля и возьмет за работу деньги. Заодно гляньте, есть ли шаблоны BPMN - стартовать с готового примера быстрее, чем с пустого листа.

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

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

Схема готова. Что с ней делать дальше

Самая обидная судьба нарисованного процесса - лечь в папку «Документы» и не открыться больше никогда. А на руках у вас, между прочим, не картинка, а техническое задание на настройку CRM. Переводится оно почти построчно.

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

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

Отсюда порядок, которого мы в 1PI.PRO держимся: сначала описанный процесс, потом настройка. Автоматизация бизнес-процессов в Битрикс24 поверх неописанного процесса дает оцифрованный хаос: те же потери, только теперь с красивыми дашбордами. Любому бизнесу до тридцати человек на старте хватает базового уровня автоматизации, но собран он должен быть по вашей логике, а не по представлению настройщика о том, как «обычно продают». Как именно устроены роботы и воронки внутри портала - тема отдельная, другие разборы по процессам и Битрикс24 лежат в блоге.

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

И совсем практическое. На встречу с интегратором берите четыре вещи: две модели - «как есть» и «как надо», список развилок, у которых пока нет правила, и один вопрос: что делаем с исключениями, которые не влезли ни в одну ветку. По ответу на последний обычно все и понятно.

Заключение

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

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

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