Схематическое изображение бизнес процесса

Иллюстрация: Оля Ежак для SKillbox Media

Рассказывает просто о сложных вещах из мира бизнеса и управления. До редактуры — пять лет в банке и три — в оценке имущества. Разбирается в Excel, финансах и корпоративной жизни.

Бизнес-аналитик с опытом работы более четырёх лет, магистр в области информационной бизнес-аналитики. Сейчас участвует в проектах, связанных с нефтедобычей, геологоразведкой, логистикой. Принимала участие во внедрении «1С:ERP» как основной бизнес-аналитик. Проверяющий куратор курсов Skillbox «Профессия Бизнес-аналитик», «Профессия Операционный менеджер».

Перед тем как улучшать процессы любого бизнеса, важно описать, как они работают сейчас, — смоделировать их. Нотация BPMN (Business Process Model and Notation) — один из способов такого моделирования.

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

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

В статье для Skillbox Media расскажем:

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

---

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

К ним можно причислить, например, обработку заказов в интернет-магазине, доставку товаров клиенту, подготовку договоров.

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

• анализ бизнес-процессов;
• выявление проблем;
• оптимизация бизнес-процессов.

В Skillbox Media есть статья, где подробно рассказано об управлении бизнес-процессами.

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

Три самых распространённых способа описания бизнес-процессов:

• Текстовый — подготовка письменных инструкций, регламентов, стандартов и других нормативных документов.
• Табличный — описание процессов в формате таблиц.
• Схематичный — графическое изображение процессов.

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

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

Нотации описывают:

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

Есть несколько вариантов нотаций — их выбирают в зависимости от типов бизнес-процессов и потребностей бизнеса. Вот некоторые примеры нотаций:

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

В следующих разделах подробно говорим о нотации BPMN.

BPMN — аббревиатура от Business Process Model and Notation. Это система условных обозначений и их описания для моделирования бизнес-процессов.

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

Первая версия BPMN создана в 2004 году рабочей группой IBM. В 2010 году — дополнена и выпущена под названием BPMN 2.0. В неё добавили новые типы событий и диаграмм, устранили ошибки первой версии.

Вот главные преимущества нотации BPMN перед другими нотациями:

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

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

Ниже на иллюстрации приведён пример процесса — поиска и приёма на работу нового сотрудника.

Разберём основные элементы нотации. Их будет достаточно для большинства схем.

Процесс (задача, подпроцесс). Задача — действие или операция, у которых нет дальнейшей декомпозиции в рамках процесса. Подпроцесс — декомпозированный процесс, в который включено несколько задач. На диаграмме он обозначается блоком со знаком +.

Примеры задач в иллюстрации выше — «Заявка на подбор нового сотрудника», «Проведение собеседования». Часто задачи формулируют через глагол: «Провести собеседование», «Подобрать сотрудника».

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

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

В нашем примере стартовые события — «Потребность в расширении штата» и «Текущий сотрудник написал заявление на увольнение».

Шлюзы. Показывают слияния потоков управления в рамках процесса. Среди них выделяют:

• Параллельный шлюз — означает, что два процесса исполняются одновременно. Читается как «И».

  В нашем примере параллельный шлюз — «Проведение собеседования» и «Проведение собеседования, заполнение листа оценки кандидата».

• Эксклюзивный шлюз — используют, чтобы обозначить ветвление потока управления на несколько альтернативных потоков, когда процесс зависит от выполнения условия. Читается как «ИЛИ».

  В этом случае процесс идёт чётко по одному из потоков.

• Неэксклюзивный шлюз — применяют, чтобы показать ветвление потока управления на несколько других, когда процесс зависит от выполнения условий. Читается как «И/ИЛИ».

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

Объект данных. Показывает, какие объекты сопровождают выполнение процесса. Например, бумажный документ, электронный документ, информацию и так далее.

В нашем примере объекты данных — «Заявка на подбор», «Лист оценки кандидата», «Предложение о работе».

Потоки. Это стрелки, которые показывают движение по процессам и порядок их выполнения. Есть несколько видов потоков:

• Поток управления — показывает, в каком порядке выполняется процесс. Эти стрелки связывают между собой задачи, события и шлюзы.

  Пример — связь между задачами «Поиск подходящих кандидатов» и «Отправка релевантных резюме». Это две задачи, которые последовательно идут друг за другом.

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

• Ассоциация — показывает связи объектов данных и баз данных с процессами.

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

Пулы (дорожки). Показывают участников бизнес-процессов. Например, должности, подразделения, роли, внешние субъекты. Дорожка не может соответствовать системе или другим объектам — только людям.

Например, в нашей иллюстрации дорожки соответствуют кандидату, HR-менеджеру, руководителю отдела.

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

Существует много инструментов для разработки процессов в BPMN. Мы рекомендуем бесплатный онлайн-сервис Diagrams.net. В нём можно создавать схемы, модели, диаграммы и обмениваться ими в браузере.

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

Вот пошаговый план того, как построить бизнес-процессы в нотации BPMN:

1. Изучите процесс: для чего он нужен и какие задачи решает.

2. Определите, является он основным, вспомогательным или процессом управления.

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

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

Процесс управления — процесс, влияющий на существование и развитие компании. Например, управление командами компании.

3. Запросите у ответственных за процесс инструкции, регламенты и другие нормативные документы, которые описывают процесс или работу участвующих в нём отделов. По этим документам можно составить первичное представление о процессе.

4. Выявите всех участников процесса: должности, роли, отделы, в некоторых случаях — Ф. И. О. ответственных сотрудников. Но в схемах процесса лучше избегать построения дорожек, завязанных на Ф. И. О., — иначе нужно будет постоянно следить за актуальностью данных.

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

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

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

Задачи бизнес-аналитика, для которых требуется BPMN, делят на два этапа:

• Построение схем «как есть» (as is) — описание текущей последовательности работ бизнес-процесса.
• Построение схем «как будет» (to be) — описание целевого процесса с фиксацией требуемых изменений: этапов модернизации, автоматизации.

Разберём на примере. Допустим, в компании N было 70 сотрудников, которые работали в одном офисе. Всю необходимую документацию они распечатывали, подписывали от руки и самостоятельно относили получателю — например, бухгалтеру, отделу кадров или секретарю.

Потом компания выросла в 2,5 раза, появились удалённые сотрудники. Руководство приняло решение внедрить систему электронного документооборота (СЭД). Перед внедрением такой системы бизнес-аналитику потребуется выполнить три основные задачи:

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

Что даёт описание текущего процесса и моделирование целевого процесса документооборота? Снизится риск упустить ключевые функции СЭД и получить на выходе систему, которая не будет решать задачи компании.

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

• Бизнес-процессы — все операции, которые помогают решать задачи бизнеса и получать доход. Чтобы всё работало по плану, процессами нужно управлять: описывать их, анализировать и оптимизировать.
• Эффективнее всего описывать бизнес-процессы графически — в виде интуитивно понятных схем. Для этого используют различные нотации — системы условных обозначений. Они нужны для того, чтобы любой человек понимал, что изображено на схеме.
• Одна из универсальных и самых наглядных нотаций — нотация BPMN (Business Process Model and Notation). Она в графическом виде отражает последовательность работ бизнес-процессов и логику их выполнения.

• Если вы только начали разбираться в управлении бизнес-процессами — прочитайте статью Skillbox Media «Большой гайд по управлению бизнес-процессами: главное, что должен знать каждый менеджер».
• В этой статье отдельно разбирали вопрос моделирования бизнес-процессов, в этой — процесс их автоматизации.
• Также в Skillbox есть курс «Профессия Бизнес-аналитик». На нём учат собирать данные о финансах компании и бизнес-процессах, проводить продуктовые интервью и определять стратегии развития, оптимизировать процессы.

Другие материалы Skillbox Media для менеджеров

Научитесь: Профессия Бизнес-аналитик
Узнать больше

Содержание:

1.      Простая блок-схема бизнес-процесса

2.      Моделирование IDEF0

3.      Моделирование BPMN

4.      Моделирование BPMN

5.      Графические нотации бизнес-процессов. Выводы.

Добрый день, коллеги.

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

·         Простая блок-схема;

·         IDEF0;

·         BPMN;

·         EPC.

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

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

1. Простая блок-схема бизнес-процесса

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

 

Упрощенная схема заваривания чая в нотации простой блок-схемы приведена Рисунке 1.

Преимущества данной схемы:

·         Простота элементов, наглядность;

Недостатки данной схемы:

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

·         Сложность в описании временных задержек, ожиданий.

 

Рисунок 1. Схема заваривания чая в формате простой блок-схемы

2. Моделирование IDEF0

Нотация является федеральным стандартом обработки информации в США с 1993 года. К особенностям данного формата можно отнести следующие особенности:

·         Использование контекстной диаграммы:

Бизнес-процессы idef0 обязательно подразумевают использование диаграммы верхнего уровня, так называемой «диаграммы А-0», которая устанавливает область моделирования, ее границу и связи объекта моделирования с окружающей средой.

·         Поддержку декомпозиции:

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

·         Доминирование:

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

·         Выделение 4 типов стрелок:

В нотации выделяются такие типы стрелок: «Вход», «Выход», «Механизм», «Управление». Тип стрелки определяется стороной функционального блока, к которой она присоединена. «Входы» преобразуются или потребляются процессом. «Выходы» — данные или материальные объекты, производимые процессом. «Механизмы» описывают средства поддержания процесса. «Управления» показывают условия, необходимые процессу для производства правильного выхода.

Описание основных графических элементов:

 

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

Упрощенная схема заваривания чая в нотации IDEF0 приведена на Рисунке 2 (Контекстная диаграмма) и Рисунке 3 (Диаграмма первого уровня декомпозиции).

Преимущества данной схемы:

·         Неограниченная глубина детализации;

·         Жесткое регламентирование описания ресурсов процесса.

Недостатки данной схемы:

·         Сложность при глубоком уровне детализации;

·         В связи со сложностью хорошо подходит для верхнеуровневого и малоприменима для детального описания бизнес-процессов

 

Рисунок 2. Контекстная диаграмма 

 

Рисунок 3 Диаграмма первого уровня декомпозиции

3. Моделирование BPMN

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

В нотации BPMN выделяют пять основных категорий элементов:

·         элементы потока (события, процессы и шлюзы);

·         данные (объекты данных и базы данных);

·         соединяющие элементы (потоки управления, потоки сообщений и ассоциации);

·         зоны ответственности (пулы и дорожки);

·         артефакты (сноски).

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

Описание основных графических элементов:

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

 Упрощенное BPMN описание заваривания чая приведено на Рисунке 4. 

Рисунок 4. Упрощенный процесс в нотации BPMN

Преимущества данной нотации:

·         Неограниченная глубина детализации;

·         Жесткое регламентирование использования элементов;

·         Автоматизация процессов моделирования и исполнения;

·         Гибкость и наглядность отображения сложных процессов.

Недостатки данной схемы:

·         Сложные регламенты моделирования.

4. Нотация EPC

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

Описание основных графических элементов:

Преимущества нотации EPC

·         При формировании схемы выдерживается строгая, формальная логика процесса.

·         Четко определены все события, возникающие по ходу процесса.

Недостатки нотации EPC

·         Сложность восприятия.

·         Значительная трудоемкость формирования схемы.

·         Информационная избыточность.

·         Занимает слишком много места, что неудобно для документирования.

Упрощенная схема заваривания чая в нотации EPC приведена на Рисунке 5.

 

Рисунок 5. Упрощенная схема заваривания чая в нотации EPC

5. Графические нотации бизнес-процессов. Выводы.

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

При работе в любой графической нотации необходимо придерживаться определенных общих правил:

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

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

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

Эксперт-консультант по производственному учету

Виктор Малиновский.

Введение

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

Главное назначение и практическое применение

Нотация BPMN (Business Process Modeling Notation) нужна для подробного описания логики выполнения бизнес-процесса, в том числе для отражения деталей процессов, таких как: события, исполнители каждого из действий, используемые и создаваемые документы и другие объекты, использующиеся в качестве входных данных для тех или иных действий или создающиеся в результате их выполнения.

BPMN позволяет описать бизнес-логику выполнения действий в виде наглядной диаграммы, а также запустить отрисованный бизнес-процесс на исполнение. Для этого используются специализированные системы BPMS (Business Process Management System), поддерживающие эту нотацию.

BPMS-системы могут автоматически перевести схему бизнес-процесса в исполняемый код и создать веб-приложение, которое будет обрабатывать данные, введённые пользователями и сторонними сервисами. Это соответствует концепции Low Code/No Code (создание программного обеспечения без разработки кода) и отлично подходит для автоматизации офисных процессов.

Технически такая возможность реализуется за счёт перевода BPMN-диаграмм в документы формата BPEL (Business Process Execution Language). BPEL-документы представляют собой инструкции исполнения бизнес-процессов для веб-сервисов.

Таким образом, BPMN используется в следующих случаях:

1. Когда нужно детально и наглядно показать последовательность и логику взаимосвязи действий, событий, исполнителей и объектов бизнес-процесса

2. Когда требуется запустить схему бизнес-процесса на исполнение в BPMS-системах

Краткая история появления нотации

BPMN считается довольно молодой нотацией: её 1-я версия вышла в 2009 году под эгидой профессионального консорциума OMG. Сегодня эта нотация является стандартом де-факто в ИТ-сфере и используется для описания бизнес-процессов. Текущая версия BPMN 2.0 вышла в 2011 году и используется до сих пор. В 2014 году в дополнение к BPMN группа OMG выпустила нотацию описания бизнес-правил и принятия решений (Decision Model and Notation, DMN).

DMN упрощает построение BPMN-диаграмм в случаях сложной бизнес-логики и многоуровневых её ветвлениях.

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

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

Уровни моделирования

В зависимости от целей построения BPMN-диаграмм, различают 3 уровня моделирования:

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

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

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

Алфавит нотации

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

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

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

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

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

События

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

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

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

Поток управления

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

Эфемерной сущностью BPMN, которая показывает смысл концепции потока, называют токен. Подобно потоку воды токен «бежит» от стартового события диаграммы к финишному, разделяясь на несколько экземпляров с помощью логических операторов. Последовательность и вариативность выполнения действий называется бизнес-логикой и показывается с помощью логических операторов или развилок, шлюзов. Например, на диаграмме ниже представлено 2 логических оператора: исключающее ИЛИ (XOR) и включающее ИЛИ (OR).

Процесс утреннего пробуждения

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

После выполнения действия оператор включающего ИЛИ (OR) пропускает поток на действие «Выпить кофе» или на действие «Узнать новости» или по обоим веткам. Исключения здесь нет, ручеёк потока управления распараллеливается на две ветки, чтобы потом объединиться снова в одну и один раз выполнить действие «приготовиться к делам». После выполнения этого действия процесс заканчивается конечным событием.

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

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

Диаграмма BPMN может содержать один или несколько пулов, каждый из которых может содержать одну или несколько дорожек.

Процесс утоления голода

В следующем примере процесс «утоления голода» состоит из двух дорожек («Ребёнок» и «Мама»), общение между которыми выполняется через поток управления.

Стартовым событием является простое событие «Возникло чувство голода» на дорожке Ребёнок, а конечным — простое событие «Чувство голода удовлетворено» на этой же самой дорожке.

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

Кафе показано отдельным свёрнутым пулом, общение с которым происходит через поток сообщений в рамках свёрнутой задачи «Собраться в кафе». Предполагается, что детали выполнения задачи «Собраться в кафе» отражены на отдельной диаграмме.

Типы событий

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

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

Также некоторые события могут быть прерывающими и не прерывающими.

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

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

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

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

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

Типы действий

Подобно событиям, действия в BPMN также могут быть разных типов:

• Выполняемые вручную без использования какого-либо ПО, например, съесть пиццу.

• Выполняемые пользователем с помощью ПО, к примеру, заказать пиццу.

• Выполняемые скриптом или сервисом, например, изменить статус заказа пиццы.

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

Более подробно про типы действий, их смысл и графические обозначения рассказано в Приложении Б.

Логические операторы

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

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

В отличие от исключающего или, простое ИЛИ (OR) допускает возможность активации как нескольких веток, так и одной из них. В математическом смысле этот оператор реализует дизъюнкцию или логическое сложение переменных, что показано в таблице истинности на слайде.

Наконец, логическое И (AND) означает активацию всех входящих или исходящих в этот оператор потоков управления, реализуя логическое умножение переменных, т. е. операцию конъюнкции.

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

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

Следующий рисунок показывает использование эксклюзивного шлюза по событиям, который запускает движение потока только по той ветке, где событие произойдёт раньше. Например, получено согласие от клиента ИЛИ прошло 5 дней (без новостей от клиента).

Все остальные шлюзы, которые есть в BPMN, приведены в Приложении В.

Артефакты

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

Вы можете найти полный перечень артефактов в Приложении Г.

Правила построения диаграмм

Рассмотрим пример бизнес-процесса обработки заявки:

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

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

После действия «Направить клиенту коммерческое предложение (КП)» на диаграмме используется логический оператор ИЛИ (событийный XOR), после которого возможен один из двух вариантов:

1. Если прошло 5 дней, что показано событием с триггером таймер, и ответа от клиента нет, заявке присваивается статус «Отказ» в CRM-системе и наступает финишное событие «Заявка закрыта».

2. Если же ответ от клиента получен и 5 дней ещё не прошло, процесс движется дальше в зависимости от данных в этом ответе.

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

В результате этой задачи создаётся документ «Проект договора» и наступает финишное событие «Заявка успешно обработана».

Поток по умолчанию

Если в диаграмме используются операторы обычного XOR, проверяющего условия по данным, и OR (неисключающего ИЛИ) рекомендуется помечать поток по умолчанию, который активируется, если другие условия не сработали. Поток по умолчанию допустимо не подписывать, если подписаны остальные потоки и диаграмма остаётся понятной. В примере ниже «‎Нецелевой» — поток по умолчанию.

Альтернативный способ показать условия

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

Задачи и события

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

Ниже показан пример диаграммы с задачами по отправке и получению сообщения:

Пример этой же диаграммы с событиями получения и отправки сообщений:

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

Рекомендации по использованию BPMN

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

Принимая во внимание три уровня моделирования BPMN и избыточный алфавит этой нотации, можно сделать вывод, что при проектировании диаграмм «‎для людей» (без запуска на выполнение в BPMS-системах) следует намеренно ограничить количество используемых элементов:

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

• Использовать только свернутые подпроцессы, раскрывая их детали на отдельной диаграмме.

• Использовать только XOR и AND, без событийных шлюзов и OR, так как разница между исключающим и не исключающим ИЛИ понятна не всем пользователям.

• Использовать события с типом простое, таймер, сообщение и останов.

Для упрощения восприятия диаграммы стоит придерживаться правил наименования:

• Внешних контрагентов показывать как закрытые, они же — свёрнутые пулы (пулы, в которых нет действий).

• Называть закрытые пулы ролями или бизнес-единицами, а открытые — процессами.

• Называть дорожки также, как роль, должность или структурное подразделение.

• Называть действия (задачи) в стиле Глагол-Существительное, например, «‎Проверить счёт», «Подтвердить заявку», «Оформить договор».

• Называть события как свершившийся факт в прошедшем времени, к примеру, «Поступила заявка», «Прошло 3 дня».

• Подписывать исходящие из XOR стрелки, например, «Да» и «Нет», а также отмечать поток по умолчанию.

Также рекомендуется:

• Показывать успешное и неуспешное завершение процесса разными финишными событиями.

• Не выводить поток управления за пределы подпроцесса.

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

Наконец, при разработке любой диаграммы нужно помнить о главном правиле аналитика: независимо от нотации, ваша схема должна быть МАКСИМАЛЬНО простой и понятной читателю БЕЗ знания тонкостей процессного моделирования!

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

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

2. Описать «счастливый» путь (happy path), который ведёт к созданию полезного результата (продукта).

3. Добавить условия и альтернативные потоки.

4. Добавить неуспешные завершения.

5. Добавить артефакты (объекты и хранилища данных).

6. Раскрыть на новых связанных диаграммах свёрнутые подпроцессы.

7. Добавить промежуточные событийные потоки к внешним пулам.

Пример построения диаграммы по текстовому описанию

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

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

Процесс начинается с момента, когда клиент оставил заявку на сайте (то есть поступление заявки является триггером процесса, его стартовым событием). На основании заявки, в которой указаны подробности заказа, менеджер формирует коммерческое предложение (КП). Далее менеджер озвучивает КП по телефону или направляет на email, или же делает и то, и другое — в зависимости от пожеланий клиента и указанных в заявке контактных данных.

Узнав подробности коммерческого предложения, клиент принимает решение о продолжении сотрудничества или отказе от него. Если клиент не согласился на условия КП, на этом процесс работы с ним заканчивается, а заявке присваивается статус «Отказ».

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

При наличии возражений к проекту договора клиент вносит в него изменения и снова направляет менеджеру. Менеджер формирует новый проект договора и снова отправляет клиенту на согласование, то есть идёт возврат к ранее выполняемой задаче.

Инструменты для разработки бизнес-процессов в нотации BPMN

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

• ШТОРМ — веб-редактор от команды Дениса Котова, пожалуй, главного евангелиста BPMN в России, с автопроверкой диаграмм и возможностями командной работы в одном пространстве;

• Online BPMN — простой и удобный веб-редактор, поддерживает интеграцию с BPMS-системой;

• Cavemo — веб-редактор, аналогичный предыдущему, имеет офлайн-версию

• простые веб-«рисовалки‎» Lucidchart, Draw.io, Visual Paradigm

Также алфавит нотации BPMN поддерживается и в MS Visio, ARIS Express и других редакторах диаграмм общего назначения.

Заключение

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

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

---

• Кандидат технических наук (Системный анализ, управление и обработка информации, 2013)

• Сертифицированный бизнес-аналитик (IIBA CBAP, 2020)

• Сертифицированный специалист Business Studio и СЭД Directum

Профессиональные интересы: системный анализ, бизнес-анализ, разработка и поддержка СМК, ССП (KPI), анализ и формализация бизнес-процессов (UML, IDEF, BPMN), Data Science, технологии Big Data, разработка технической документации (ТЗ по ГОСТам серии 19, 34, руководства пользователя и администратора, описание программных продуктов), управление продуктами и проектами.

BPMN (Business Process Model and Notation — нотация и модель бизнес процессов) разработана компанией Business Process Management Initiative и поддерживается Object Management Group после слияния организаций в 2005 г. Последняя версия 2.0 вышла в 2012 г. В 2013 году BPMN утверждена в качестве международного стандарта ISO/IEC 19510.

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

Бизнес-процессы

Существует множество определений бизнес-процессов. Например Википедия дает такое определение:

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

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

Еще одним определением процесса (бизнес-процесса) будет:

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

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

Запомните принцип:

процесс может:

• получать входы от других процессов;
• передавать выходы другим процессам

Процесс НЕ может:

• получать входы от отделов, сотрудников, физических лиц и прочих сущностей, кроме процессов;
• передавать выходы другим отделам, сотрудникам, физическим лицам и прочим сущностям, кроме процессов

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

Бизнес-процесс состоит из операций и действий. Дадим определение этим понятиям.

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

Операция состоит из действий или набора действий, производимых над обрабатываемым объектом. Действие есть акт взаимодействия оператора с обрабатываемым изделием, в котором достигается определенная, заранее определенная, цель.

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

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

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

И давайте рассмотрим следующую схему:

Зеленый круг — стартовое событие, которое указывает на начало того или иного процесса;

Красный круг — конечное событие, которое указывает на точку завершения процесса;

Ромб — графический элемент шлюза, используется для изображения ветвления;

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

Детальней об всех этих элементах будет рассказано подробней чуть ниже.

Область применения нотации BPMN

Нотация BPMN предназначена для описания:

• Порядка исполнения работ образующих бизнес-процесс,
• Потоков данных между операциями процесса;
• Потоков сообщений между процессами;
• Ассоциации обрабатываемых объектов данных с операциями процесса.

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

• Функциональную (структурную) декомпозицию работ;
• Организационную структуру предприятия;
• Модель данных;
• Бизнес правила,
• Бизнес стратегию компании

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

Основные элементы нотации

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

1.Элементы управления;
2. Соединительные элементы;
3. Артефакты;
4. Данные.
5. Зоны ответственности

Зоны ответственности

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

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

Если пул показывает детали процесса: операции, логические операторы, события и потоки управления, его называют «белый» ящик. Напротив, пул, который не показывает деталей процесса, называют «черный» ящик.

Пул разделен на дорожки, которые служат для группировки операций диаграммы. Дорожки имеют имя. Дорожки принято называть в терминах исполнителей процесса. Ими могут быть:
• должности;
• роли.

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

События

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

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

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

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

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

В BPMN разные события изображаются по разному.

Операции и логические операторы

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

Логический оператор изображают работу, которая не изменяет объект, но маршрутизирует его в соответствии с некоторым правилом. Например, если величина запрошенного кредита превышает 50000 гривен, то его согласует старший менеджер.

Соединительные элементы

C помощью событий, операций и логистических операторов можно составить схему процесса

Операции процесса на схеме соединены стрелками. Эти стрелки имеют тип «Sequence flow» — они показывают последовательность выполнения операций во времени. Можно сказать, что они управляют «потоком операций» — Work Flow.

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

Поток операций (управления) (Sequence Flow)	Поток операций служит для отображения того порядка, в котором организованы действия Процесса или условия Хореографии.
Поток сообщений (Message Flow)	Поток сообщений служит для отображения обмена сообщениями между двумя участниками, готовыми эти сообщения отсылать и принимать. На диаграмме взаимодействия BPMN два отдельно взятых Пула представляют собой двух участников Процесса (бизнес-сущности или бизнес-роли).
Ассоциация (Association)	Ассоциация служит для установления связи между информацией или Артефактами (объектами, не относящимися к Элементам потока) и элементами потока. Текстовые объекты, а также графические объекты, не относящиеся к элементам потока, могут соотноситься с элементами потока. При необходимости Ассоциация может указывать направление потока (например, потока данных).

Данные

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

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

Хранилища данных изображают внешние по отношению к процессу системы хранения, например, СУБД.

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

Артефакты

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

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

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

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

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

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

Субклассы нотации BPMN

Полный набор графических элементов в нотации BPMN 2.0 содержит 116 графических элементов, для упрощения работы с ними их можно разделить на несколько групп (взято из книги Федорова И.Г. «Моделирование бизнес-процессов в нотации BPMN 2.0»)

Основной набор включает 7 элементов, достаточен для разработки концептуальной (не исполняемой) модели процесса.

• Подмножество описательных элементов (+17) достаточно для построения исполняемой модели;
• Подмножество аналитических элементов (+29) • Наконец, полный набор (+50) позволяет создавать любые типы диаграмм.

Логика процесса

Логика процесса описывается с помощью шлюзов (условий), которые могут быть нескольких типов (в BPMN выделяют 7 типов) .

Эксклюзивный шлюз (XOR, «Исключающее ИЛИ») используется для ветвления потока управления на несколько альтернативных потоков, когда выполнение процесса зависит от выполнения некоторого условия.

Исключающие Шлюзы включаются в состав бизнес-процесса для разделения Потока операций на несколько альтернативных маршрутов. Для процесса с исключающим  типом Шлюза может быть выбран лишь один из предложенных маршрутов (поэтому определяется как Шлюз «ИЛИ»).

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

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

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

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

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

Пример построения процесса с помощью BPMN

Ниже представлена схема процесса «Подача заявления на отпуск сотрудником». Это наверное  вариант самой встречаемой схемы, которой будет достаточно для построения 90% схем и она досточно понятна даже стороннему наблюдателю.

BPMN 2.0 Метамодель и нотация бизнес-процессов (сводная информация)

В статье рассмотрены вопросы выбора нотации для описания процессов с целью последующей регламентации. Сравниваются между собой часто используемые нотации Work Flow, такие как: «Простая блок-схема» в MS Visio, «Процедура» Business Studio, нотация ARIS eEPC и другие. При сравнении нотаций основное внимание уделяется вопросам создания простых и понятных сотрудникам организации схем процессов.

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

Введение

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

Сравнение нотаций

Для сравнения были выбраны следующие нотации описания процессов:

1. «Простая блок-схема» (с отображением движения документов, с использованием блока «Решение»);
2. «Простая блока-схема» (без отображения движения документов, без использования блоков «Решение»);
3. «Процедура» системы Business Studio (один из возможных вариантов представления);
4. ARIS eEPC.

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

Рис. 1. Схема процесса в нотации «Простая блок-схема» в MS Visio (с движением документов, с использованием блока «Решение»)

На схеме, представленной на Рис. 1, последовательность выполнения операций процесса во времени показана при помощи жирных стрелок, а движение документов — при помощи тонких пунктирных стрелок. Блоки «Решение» использованы классическим образом. Они отображают информацию (вопросы), от которых «зависит» последующий ход процесса. Такой подход к использованию «ромбиков» является весьма распространенным. Но фактически, вся логика принятия решений и формирования тех или иных выходов (документов) должна заключаться внутри операций процесса. Если задуматься, то ценность (смысл) рисования этих «ромбиков» не является очевидным. Что это за объекты: операции процесса, события? Вроде бы, ни то, и ни другое. Это скорее операторы принятия решения по какому-либо условию. Но ведь мы разрабатываем схему процесса для людей, а не пишем компьютерную программу на специальном языке. В компьютерной программе «ромбик» был бы полноценной операцией сравнения условий и т. п. Но на схеме процесса нужно показывать реальные объекты — процессы, выполняемые людьми, документы, информационные системы и т. п. Задумайтесь, корректно ли показывать «ромбики» отдельно от операции процесса на схеме? Вместо этого можно:

• Описать логику принятия решения в виде последовательность операций на схеме рассматриваемого процесса;
• Описать логику в виде схемы шагов соответствующего подпроцесса, переходя на уровень ниже;
• Описать логику текстом (в текстовых атрибутах операции) и в последующем вывести в регламент выполнения процесса.

Сформулируем «плюсы» и «минусы» рассмотренного выше (Рис. 1) способа использования «ромбиков».

«Простая блок-схема» в MS Visio (с движением документов, с использованием блока «Решение»)

«Плюсы»	«Минусы»
Наглядное отображение «логики» выбора тех или иных выходов процесса; Акцентирование внимания исполнителя на точку принятия решения/ветвление процесса в зависимости от условий.	Вынос логики принятия решения «наружу» операции процесса (некорректно с точки зрения формальной декомпозиции процессов); Неудобно документировать процесс (приходится дублировать «ромбики» текстом при формировании текстового описания операции); Схема процесса становится информационной перегруженной; «Ромбики» часто используются слишком формально, без реальной необходимости.

По мнению автора статьи, рассмотренный на Рис. 1 способ применения блоков «Решение» («ромбиков») является некорректным с точки зрения бизнес-моделирования.

На Рис. 2 показан пример того же самого процесса, только описанного без использования блоков «Решение» и документов. Легко проверить, что на этой схеме на 24 графических элемента меньше, чем на схеме Рис. 1. Схема Рис. 2 выглядит гораздо проще. От графических элементов не рябит в глазах, а с точки зрения информативности эта схема вполне понятна и доступна конечному пользователю. Если для каждой операции процесса описать требования к ее выполнению текстом, то комбинируя табличную и графическую формы представления, можно вполне адекватно описать порядок исполнения процесса для сотрудников компании.

Рис. 2. Схема процесса в нотации «Простая блок-схема» в MS Visio (без движения документов, без использования блока «Решение»)

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

«Простая блок-схема» в MS Visio (без движения документов, без использования блока «Решение»)

«Плюсы»	«Минусы»
Простота и наглядность для исполнителя; На лист можно поместить больше информации, чем в случае формата, использованного на Рис. 1.	«Логика» принятия решений скрыта внутри операций процесса; Графическую схему целесообразно сопровождать таблицей с текстовым описанием операций процесса.

В целом, применение схем в формате, подобном представленному на Рис. 2, является удобным как для разработчиков, так и для сотрудников, работающих по этим схемам.

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

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

Такой подход дает возможность:

• Существенно сократить количество графических элементов на схеме процесса, и при этом;
• Вывести в регламент процесса необходимую информацию о входящих и исходящих документах.

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

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

Рис. 3. «Процедура» системы Business Studio (вариант с нетрадиционным использованием блоков «Решение»)

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

«Процедура» системы Business Studio (вариант с нетрадиционным использованием блоков «Решение»)

«Плюсы»	«Минусы»
Простота представления; Акцентирование внимания исполнителя на операцию, связанную с принятием решения/ветвлением процесса; На листе А4 может быть представлено большое количество информации.	Блок «Решение» не декомпозируется; Неоднозначность в именовании стрелок (возможны разночтения).

В случае применения Business Studio, нотация «Процедура» может быть использована несколько по-разному. Автор статьи склоняется к подходу, представленному на Рис. 3.

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

Заметим, что схема процесса в нотации ARIS eEPC занимает существенно больше места, чем схемы, представленные на Рис. 1–3. Трудоемкость формирования такой схемы также существенно выше.

Рис. 4. Схема процесса в нотации ARIS eEPC (построена в Business Studio)

Схема процесса в нотации ARIS eEPC (построена в Business Studio)

«Плюсы»	«Минусы»
При формировании схемы выдерживается строгая, формальная логика процесса; Четко определены все события, возникающие по ходу процесса.	Сложность восприятия; Значительная трудоемкость формирования схемы; У сотрудников должны быть специальные навыки и опыт интерпретации подобных схем; Информационная избыточность; Занимает слишком много места, что неудобно для документирования.

В целом, если Вы не собираетесь покупать SAP R/3, то выбор и использование нотации ARIS eEPC не является, с точки зрения автора статьи, оптимальным решением. Стоит обратить внимание на более наглядные и интуитивно понятные исполнителям нотации описания процессов. Впрочем, кому-то нотация ARIS eEPC может показаться более наглядной и понятной. До определенной степени, это вопрос вкуса.

Описание процесса для целей последующей автоматизации

Интересно рассмотреть приведенный выше пример описания бизнес-процесса в случае, если он представлен в нотации BPMN 2.0. Это нотация предназначена для описания «исполняемых» процессов, т. е. процессов которые поддерживает система BPM.

Своим мнением об использовании BPMN 2.0. делится А. А. Белайчук — Генеральный директор компании «Бизнес-консоль»:

«На Рис. 5 изображен тот же процесс в нотации BPMN. Как мы видим, этот рисунок похож на Рис. 1: в нотации BPMN задачи изображаются прямоугольниками, развилки — ромбами, данные — пиктограммой, похожей на документ. Потоки управления — сплошные линии, потоки данных — пунктирные.

Надо учитывать, что на этой диаграмме задействована только малая часть нотации BPMN: только один вид развилок из 5 имеющихся в палитре, один вид задач из 8. Помимо более широкой палитры, эту нотацию отличает возможность моделировать не только изолированный поток работ, но также несколько процессов, взаимодействующих друг с другом через сообщения или данные. Кроме того, эта нотация более строгая: в ней определены не только значки, но и правила, по которым они могут сочетаться друг с другом. Необходимость таких правил диктуется тем, что нотация BPMN ориентирована не только на то, что ее будут читать люди, но и на непосредственное исполнение специальным программным обеспечением — „движком“ BPM-системы.

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

Рис. 5. Схема процесса в нотации BPMN 2.0

Практика жизни

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

Рис. 6. Примеры схемы процесса одной из компаний

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

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

Выводы

Итак, очевидно, что при описании процессов нужно стремиться к простоте и понятности для сотрудников.

Использование сложных, формализованных нотаций при описании процессов приводит к:

• Трудностям при использовании (интерпретации) схем рядовыми сотрудниками;
• Невозможности (сложности) организации работ по описанию процессов силами сотрудников подразделений, не прошедших специальное обучение;
• Значительному увеличению трудозатрат бизнес-аналитиков на формирование схем;
• Дополнительным сложностям при документировании схем (большой объем и т. п.).

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

http://finexpert.ru/ — среда общения профессионалов http://bpm3.ru/ — процессы, проекты, эффективность

Октябрь 2010 г.

Рекомендуемые материалы по тематике

Сквозные бизнес-процессы в компании

От процессного управления к цифровой трансформации и роботизации. Версия 4.0

Превращение в гиганта: практика организационного развития ГК «Гулливер»

Определение ролевых функций управления процессом

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

Общий подход к построению схемы бизнес-процесса

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

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

Какими качествами должна обладать готовая схема?

Качественная и эффективная схема должна отвечать следующим требованиям:

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

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

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

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

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

Чтобы модель работала эффективно, недостаточно ее построить. Необходимо выявить все связи между процессами. Такая работа требует прохождения следующих этапов:

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

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

Как построить схему самостоятельно?

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

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

Первый этап. Установление границ бизнес-процесса

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

Соответственно, необходимо понимать все тонкости работы организации и всех его процессов.

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

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

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

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

Второй этап. Точки начала, окончания, ключевые блоки

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

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

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

Третий этап. Дополнение недостающими операциями

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пятый этап. Проверка полученной модели

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

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

Обзор программ для создания схемы бизнес-процесса

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

ELMA BPM

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

Business Studio

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

Visual Paradigm

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

Bizagi Process Modeler

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

Intalio BPMS

Бесплатное программное обеспечение, позволяющее строить и анализировать бизнес-процессы.

ARIS Express

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

Camunda

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

• программа имеет открытый код, что дает возможность специалисту однозначно понимать принципы работы, представленная документация дает возможность легко провести интеграцию движка со своей инфраструктурой;
• поддержка всех языков JVM, в том числе и последних версий Java;
• хорошо организованная инфраструктура без излишних абстракций, требующих дополнительного изучения;
• удобство работы и встраивания движка за счет возможности использования в качестве библиотеки в Java-приложении. Нет ограничений в условиях для разработчиков. Имеется возможность использования любых удобных инструментов;
• дополнительный набор полезных приложений, среди которых – приложения для формирования моделей процессов; выполнения задач, поставленных перед исполнителями; сохранения и интерпретации моделей; анализа состояния процессов; управления правами пользователей и другие. Часть из дополнительных приложений доступны только в платной версии, часть – в бесплатной имеют ограниченный функционал. Тем не менее, возможности движка даже в бесплатной версии впечатляют.

AllFusion Process Modeler

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

IBM WebShpere Business Modeler

Программное средство для моделирования, имитации и анализа бизнес-процессов.

Основными характеристиками являются:

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

Fox Manager Бизнес Процессы

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

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

Comindware Business Application Platform

Российская платформа, в которой реализовано моделирование бизнес-процессов и цифровая трансформация предприятия.

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

Практический пример с графической схемой

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

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

На основе обработки информации составим проект процессов компании.

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

Основные производственные процессы предприятия представлены на рисунке.

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

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

Материалы поступают на склад по накладным от различных поставщиков.

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

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

Таким образом, проведенное исследование позволило сделать следующие выводы:

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

Улучшить работу предприятия можно при учете следующих моментов.

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

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

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

Для улучшения качества хорошо проводить постоянное отслеживание и вести статистический учет по прочности швов для швов различных типов и различных материалов.

Можно чаще документировать толщину шва, чтобы быть уверенными в том, что контроль осуществляется часто.

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

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

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