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

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

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

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

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

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

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

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

Чтобы создать модель, необходимо определить:

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

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

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

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

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

Кейс 1. Идеально отлаженный бизнес-процесс: Википедия

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

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

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

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

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

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

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

3. Хаоса в команде, когда, к примеру, у сотрудников есть должности, но нет полномочий, или когда над одним и тем же процессом параллельно работает несколько человек, в результате работа дублируется, в то время как другие задачи простаивают.

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

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

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

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

Источник: medium.com

Как моделировать процессы — методика для начинающих

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

1. Что такое моделирование процесса и модель процесса

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

Как моделировать процессы

Вот так выглядит модель процесса в BPMN. По ссылке еще примеры

Для создания модели нужно:

Подготовиться.
Получить понимание бизнес-процесса.
Использовать инструкцию по трансляции человеческого понимания в кружочки и квадратики.
Использовать инструмент для рисования кружочков и квадратиков.

2. Подготовительные работы

2.1. Правила успешной коммуникации

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

Из этих книг для себя я вывел такие правила и вам тоже их советую:

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

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

Уважаю собеседников – даю возможность сказать, всё что они считают нужным. Не перебиваю, не делаю выводов за них и не подменяю их слова собственными рассуждениями об их словах.
Задаю открытые вопросы («Как у вас происходит х?»), а не закрытые («Вы, наверное, делаете это так?»).

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

— А еще мы доставляем заказы не только DPD, но DHL.

— А кто принимает решение о варианте доставки?

— Клиент в личном кабинете выбирает.

— А как меняется процесс, если доставка DHL?

— Не мы к ним отвозим заказы, а они у нас забирают.

2.2. Шаблон для заполнения результатов разговоров

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

По картинкой ссылка на шаблон

Каждая строчка должна содержать только один конкретный элемент, нельзя вставлять названия с союзами (И, ИЛИ и т.д.) или обобщающими местоимениями (ВСЕ, КАЖДЫЙ, НЕКОТОРЫЙ).

Товар на складе.

3. Как составить человеческое понимание процесса

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

Результат — то, чем может однозначно завершиться процесс.

Товар получен и оплачен, дело в суде закрыто, банковская гарантия выдана.

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

Сделки с драг.металлами суммой >600 000. надо регистрировать в фин. мониторинге. Бухгалтерскую отчетность надо сдавать до 31 апреля.

Действия — работа, которая нужна для процесса.

Отправка СМСки, звонок клиенту или подготовка акта.

Участники — это те люди или отделы, которые выполняют действия или участвуют в процессе.

Курьеры, бухгалтерия, сотрудники сборки, водители.

Набор – т.е. порядок, в котором действия идут друг за другом.

«Сначала клиент должен оплатить заказ, потом мы звоним клиенту, потом звоним на склад и заказываем отгрузку».

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

«Если я не дозвонился клиенту, то на склад звонить не буду, а буду звонить через 3 дня клиенту снова.»

3.1. Начинаем с результата процесса

Выбираем процесс с понятным, хорошим результатом. Я возьму процесс «Оплата счёта», он заканчивается результатами «Товаруслуга по счёту получены» и «Закрывающие документы получены».

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

Как определить результат

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

Плохо	Хорошо
Смска о дате доставке отправлена клиенту.	Клиент получил заказ. Бухгалтерия получила закрывающие документы.

Как результат звучит в речи

— Ну и в итоге мы оплачиваем товар, курьер его привозит вместе с документами. Мы ставим печати на документах, один документ курьеру отдаем, а один в бухгалтерию. Товар сдаём на склад или сразу в проекте используем.

— А по счету всё, больше ничего не делаем?

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

Запишите результат в ексель-файл.

Записываем результат в шаблон

3.2. Определяем клиента и требования

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

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

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

Бухгалтерия кажется хорошим кандидатом на «клиента», потому что они заинтересованы в сборе документов. Но выгоды от «оплаты счёта» бухгалтерия не получает, поэтому они не клиенты — они предъявляют требования к тому, как процесс должен протекать, если он запустился.

Запишем их требования в таблицу.

3.3. Действия и решения

Чтобы ответить на вопрос «как моделировать процессы» на этот раздел нужно обратить особое внимание.

Читайте также: Открыть бизнес с форекс

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

Плохо	Хорошо
Сотрудник отдела продаж заходит в ЦРМ, находит карточку контакта, находит его телефонный номер, набирает клиента, фиксирует детали разговора в карточке.	Сотрудник отдела продаж договаривается о доставке с клиентом.

Нас интересует не каждое действие в деталях, а факт наличия действия и его участия в процессе.

Искать удобно от результата

-Что нужно сделать, чтобы оплаченный товар оказался на складе?

— Ну, курьер звонит заранее, автор заявки с ним договаривается на конкретную дату доставки.

— А почему курьер звонит?

— Мы вообще-то деньги заплатили его компании, они должны нам доставить товар!

— Так, а почему деньги мы заплатили?

— Иван Иваныч, директор, согласовал мою заявку.

— А как он её увидел?

— Я ему на почту бросил, заполнил её по шаблону.

— А шаблон где взяли?

— Лежит в гугл доках, оттуда все его берут, кто хочет что-то купить»

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

Людям будет сложно разделить действия, события и решения в своей работе, а нам важно их выловить. Будем стараться их вылавливать наводящими вопросами.

— А Иван Иваныч всегда согласует заявки?

— А какие он заявки не согласует?

— Меньше 100 тысяч рублей ему не интересно согласовывать. За него это директор финансовый делает.

(Это решение)

А как вы вообще понимаете, что пора начинать оплату счёта?
У нас есть календарный план-график, в нём +- расписано, когда нужны материалы. Каждый менеджер просматривает график раз в неделю и делает заказы.

(Это событие)

3.4. Сотрудники

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

3.5. Последовательность

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

4. Превращаем слова в схему

Вот таблица, которая помогает слова превратить в значки BPMN. В шаблоны идём сверху вниз, а в BPMN отрисовываем справа налево (от конца к началу).

№	Словами	В BPMN	Картинка	Комментарий
1	Результат	Завещающее событие
2	Клиент	Дорожка		Если внутренний участник
3	Клиент	Внешний пул		Если внешний участник
4	Требования	Задача		Чтобы удовлетворить требованиям обычно кто-то должен сделать работу, а тот, кто представляет требования — подтвердить, что они выполнены.
5	Действие	Задача
6	Решение	Шлюз + Задача бизнес-правила		Бизнес-правило используют тогда, когда хотят отобразить сложное решение
7	Участник внешний	Внешний пул
8	Событие	Событие		События должны быть специфицированы по стартовым, промежуточным и завещающим.

5. Пример

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

6. Инструмент для моделирования процесса

Для первой модели воспользуемся сервисом bpmn.io — он бесплатный и не требует регистрации. А еще поддерживает нотацию BPMN 2.0.

7. Теперь вы знаете как моделировать процессы

Теперь вы знаете как моделировать процессы. Расскажите в комментариями, с какими сложностями при моделировании процессов приходилось вам сталкиваться? Что непонятно из статьи?

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

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

Что такое нотация моделирования бизнес-процессов

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

Читается за 8 мин.

Хотите создать BPMN-схему? Попробуйте Lucidchart! Быстро, легко и бесплатно.

Что такое BPMN?

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

Цель применения метода BPMN — смоделировать способы адаптации под новые условия, а также пути повышения эффективности и конкурентоспособности. За последние несколько лет данный метод подвергся стандартизации и получил несколько исправленное название — «модель и нотация бизнес-процессов», — однако аббревиатура BPMN осталась без изменений. Стоит отметить, что этот метод отличается от унифицированного языка моделирования (UML), применяемого в разработке программ.

Экскурс в недавнюю историю

Метод нотации моделирования бизнес-процессов был разработан организацией Business Process Management Initiative (BPMI) и с тех пор претерпел ряд доработок. В 2005 году произошло слияние BPMI с группой компаний Object Management Group (OMG), и последняя взяла инициативу в свои руки. В 2011 году OMG выпустила BPMN 2.0 и изменила название метода на «модель и нотацию бизнес-процессов». Перемена ознаменовала внедрение более подробного стандарта моделирования бизнес-процессов с использованием расширенного набора символов и способов нотации для схем бизнес-процессов. С 2014 года в дополнение к BPMN также появился новый метод создания блок-схем — стандарт «модель и нотация принятия решений», так как BPMN обычно не подходит для схематизации потоков решений.

Цели и преимущества

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

Информация, представленная в виде схемы, как правило, удобнее для понимания, чем описание в виде текста. Схематизация упрощает как обмен информацией, так и совместную работу по созданию эффективного процесса с целью достижения качественного результата. Схемы также способствуют ведению дискуссии при составление XML-документов, необходимых для выполнения различных процессов (XML — Extensible Markup Language — «расширяемый язык разметки»). Основной стандарт XML носит название BPEL (или BEPEL4WS), что расшифровывается как Business Process Execution Language for Web Services («язык исполнения бизнес-процессов для веб-служб»).

Элементы и символы схем в BPMN 2.0

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

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

Рассмотрим отдельные элементы и то, как они применяются для характеристики бизнес-процессов.

События

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

Действие

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

Развилка

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

Последовательность

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

Поток сообщений

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

Связь

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

Бассейн и плавательная дорожка

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

Артефакт

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

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

Кто занимается моделированием бизнес-процессов?

Бизнес-процессы можно моделировать с помощью незамысловатых схем, нарисованных от руки, а можно — углубиться в детали и добавить расширяемые элементы, которые затем пригодятся при реализации. Составление наиболее сложных BPMN-схем, как правило, доверяют сертифицированным аналитикам. Консорциум Object Management Group (OMG) проводит пять типов экзаменов по BPMN 2.0, а сама сертификация носит название OCEB 2 (что расшифровывается как OMG-Certified Expert in BPM 2.0 — «эксперт по BPM 2.0, сертифицированный OMG»). Экзаменация проводится по двум направлениям — бизнес и техническая составляющая. Задача OMG — стандартизировать моделирование бизнес-процессов с помощью BPMN 2.0 примерно таким же образом, как унифицированный язык моделирования (UML) стандартизировал разработку программного обеспечения.

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

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

Субмодели в составе BPMN-схем

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

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

Другие виды схем

В BPMN также выделяют другие виды схем: обмен сообщениями, хореография и совместная работа.

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

Главные советы по моделированию процессов

Четко обозначьте охват процесса, то есть с чего он начинается и чем заканчивается.
Прежде чем моделировать нововведения в BPMN, не помешает сначала схематизировать текущий бизнес-процесс и выделить его недостатки.
BPMN-схема, желательно, должна уместиться на одной странице, даже если это целый плакат (бывает и так).
Потоки последовательностей изображаются горизонтально, а связи и потоки данных — вертикально.
Для разных участников проекта можно создать разные версии схемы с необходимой степенью детализации.
BPMN не подходит для моделирования структур организаций, потоков данных и функционального разбиения. Хотя в BPMN-схемах действительно отражаются некоторые информационные потоки в составе бизнес-процессов, всё же не стоит путать их с диаграммами DFD.