Нотация по моделированию бизнес-процессов BPMN (The Business Process Modeling Notation) — это новый стандарт для моделирования бизнес процессов и сетевых услуг, который впервые был выпущен BPMI Notation Working Group в мае 2004 года. Последняя версия нотации BPMN 2.0 вышла в 2010 году. Оригинальная спецификация (на английском языке) изготовлена группой компаний «Object Management Group».
Нотация BPMN описывает условные обозначения для отображения бизнес-процессов в виде диаграмм бизнес-процессов. BPMN ориентирована как на технических специалистов (разработчиков, ответственных за реализацию процессов), так и на бизнес-пользователей (бизнес-аналитиков, создающих и улучшающих процессы) и менеджеров, следящих за процессами и управляющих ими. Следовательно, BPMN призвана служить связующим звеном между фазой дизайна бизнес-процесса и фазой его реализации. Для этого язык использует базовый набор интуитивно понятных элементов, которые позволяют определять сложные семантические конструкции.
Business Process Model and Notation (BPMN) 2.0 Tutorial
Людям, занимающимся бизнесом, крайне удобно работать с бизнес-процессами, отображаемыми в виде блок-схем. Множество бизнес-аналитиков проектируют и описывают бизнес-процессы компаний с помощью простых диаграмм в нотации BPMN, т.к. язык нотации понятен даже на уровне пользователя. При этом модели процессов, описанных в нотации BPMN, являются ИСПОЛНЯЕМЫМИ (т.е. реализуются в любой BPM-системе), а не только документируются. Для детального описания процессов существуют программные решения, которые способны преобразовать диаграммы в исполняемые процессы, эти процессы затем могут быть запущенны и работать в реальном времени.
Предлагаемый практический курс по описанию и чтению бизнес-процессов в нотации BPMN представляет собой серию Уроков, которые в доступном виде с многообразием практических примеров (реализованных в системе управления бизнес-процессов ELMA) познакомят всех интересующихся с популярной нотацией BPMN.
Компанией ELMA был проделан колоссальный труд по переводу оригинальной спецификации BPMN на русский язык, но её чтение для простых бизнес-пользователей является непростой задачей. Упрощенных материалов сейчас не найти в открытом доступе. Поэтому разработанный Курс – уникальный труд, описывающий основные нюансы работы с процессами, описанными в нотации BPMN.
Собственно перед вами первый такой труд, мы очень постарались сделать его простым, понятным, а главное полезным!
Одной из причин создания BPMN явилась необходимость построения простого механизма для проектирования и чтения как простых, так и сложных моделей бизнес-процессов. Для удовлетворения двух этих противоречащих требований был применен подход систематизации графических элементов нотации по категориям. Результатом явился небольшой перечень категорий нотаций, позволивший людям, работающим с диаграммами BPMN, без труда распознавать основные типы элементов и осуществлять корректное чтение схем.
С точки зрения легкости чтения и понимания процессов нотация BPMN 2.0 вне конкуренции. Моделирование в BPMN осуществляется посредством диаграмм с небольшим числом графических элементов. Это помогает пользователям быстро понимать логику процесса.
Любой процесс, описанный в нотации BPMN, представляет собой последовательное или параллельное выполнение различных действий (операций) с указанием определённых бизнес-правил. Рассмотрим простой пример процесса «Обработка заказа», который может реализовываться в рамках продажи и аренды велосипедов через интернет-магазин.
Рис.1. Процесс «Обработка заказа»
Чтение процесса всегда начинается со Стартового события (зеленого кружка).
Рис.1.1. Стартовое событие
Как видно из названия, Стартовое событие указывает на то, в какой точке берет начало тот или иной процесс. В контексте потока операций Стартовое событие является начальной точкой в процессе; это означает, что никакой входящий поток операций не может быть соединен со стартовым событием. Стартовое событие в нотации BPMN изображается в виде круга со свободным центром.
Примечание: стартовым событием процесса-примера является звонок или письмо от клиента на сайт компании (интернет-магазина).
Далее от Стартового события выполнение процесса идет по линиям (Поток операций) до Конечного события (красный кружок), их может быть несколько.
Рис.1.2. Конечное событие
Конечное событие указывает на то, в какой точке завершается тот или иной процесс. В контексте Потока операций Конечное событие завершает ход Процесса; это означает, что никакой Исходящий поток операций не может быть соединен с Конечным событием.
Конечное событие представляет собой круг, выполненный одиночной, жирной линией. Толщина линии должна быть жирной настолько, чтобы без труда можно было отличить Конечное событие от Стартового.
Примечание: в приведённом примере Стартовое и Конечное события для большего удобства различаются так же по цвету (дизайнер системы ELMA). Конечное событие процесса «Обработка заказа» отображает завершение процесса – выдачей заказанного товара.
Примените знания нотации BPMN 2.0 на практике
в Low-code BPM-системе ELMA365
Вся логика работы (ход) процесса выражается во всевозможных элементах, расположенных между Стартовым и Конечным событием. Основным элементом, отражающим деятельность, выполняемую внутри процесса, являются Действия. Действия – это точки выполнения работ в ходе Процесса. Они относятся к выполняемым элементам Процесса BPMN. Действие может быть как элементарным, так и неэлементарным (составным).
Элементарное Действие выражается в выполнении одной единственной Задачи. Графически Задача изображается в виде прямоугольника с закругленными углами. Самой распространённой Задачей является типичная для технологического процесса задача, где человек участвует в качестве исполнителя. Такие Задачи называются Пользовательскими.
Примечание: в рамках процесса «Обработка заказа» основными действиями являются задачи «Зарегистрировать и обработать заявку», «Оформить заявку на покупку» и «Оформить заявку на аренду».
Рис.1.3. Пользовательская задача
Другой элемент нотации, часто используемый в описании процессов – Шлюзы (Условия). Графический элемент Шлюза представляет собой небольшой ромб, используемый во многих нотациях схем бизнес-процессов для изображения ветвления и знакомый большинству инструментов моделирования. Фактически Шлюз — есть совокупность входов и выходов.
Рис.1.4. Шлюз
Шлюзы используются для контроля расхождений и схождений потока операций в рамках процесса. Термин шлюз подразумевает пропускное устройство, которое либо позволяет осуществлять переход через шлюз, либо нет.
Примечание: в приведённом примере, в зависимости от желания клиента (купить или арендовать велосипед), заявка оформляется в формате покупки либо аренды соответственно. В данном процессе Шлюз указывает, что процесс может пойти только в одном из описанных направлений, т.е. либо покупка либо аренда.
Даже самый сложный процесс, описанный в нотации BPMN, легко читается любым бизнес-пользователем, владеющим знанием основных элементов Процесса BPMN.
В рамках следующих практических Уроков по применению нотации в описании бизнес-процессов будут рассмотрены более подробно все виды графических элементов и условия их применения.
Каждый Урок даст вам практические знания о правилах использования основных элементов BPMN 2.0.
Дополнительно выполненные самостоятельные работы (с возможностью «подсмотреть ответ» и сверить его со своим решением) помогут в умении самостоятельно анализировать и моделировать простые бизнес-процессы с помощью BPMN.
Источник: www.elma-bpm.ru
Нотация BPMN 2.0: ключевые элементы и описание
BPMN (Business Process Management Notation) – это язык моделирования бизнес-процессов, который является промежуточным звеном между формализацией/визуализацией и воплощением бизнес-процесса.
Говоря проще, такая нотация представляет собой описание графических элементов, используемых для построения схемы протекания бизнес-процесса.
Как минимум, такая схема нужна, чтобы выстроить в соответствии с ней бизнес процесс и понятно регламентировать его для всех участников. Немаловажным является то, что моделирование BPMN позволяет впоследствии провести автоматизацию бизнес-процессов в соответствии с имеющейся схемой.
Является ли нотация BPMN лучшей для поставленных перед ней задач? Хороший ответ, актуальный до сих пор, дал еще в семидесятых годах XX века Чарльз Бокс «Все модели неверны, некоторые полезны». BPMN точно полезна, а некоторые ограничения, которые нотация имеет, по мнению экспертов не столь важны на практике:
Моделируя что-либо, мы удаляем некоторые аспекты реального мира, чтобы их визуализировать. И все же ИТ-профессионалы продолжают искать одну истинную нотацию моделирования и набор семантики, чтобы управлять сразу всем. Они предполагают, что должно быть возможно перевести все аспекты и их взаимосвязи на визуальный язык. Я думаю, что большинству людей бизнеса это не нужно.
Они используют модели для общения друг с другом … и да, в ходу круги и стрелки, прямоугольники и облака, и … лишь очень немногие заинтересованы в том, чтобы отразить взаимосвязь всех аспектов друг с другом. Дерек Миерс (Derek Miers) – Отраслевой аналитик и консультант. Более 25 лет специализируется в сферах управления бизнес-процессами, цифровой трансформации, бизнес-архитектуры и технологических инноваций. В настоящее время работает в Gartner время на позиции директора по исследованиям в сфере Enterprise Architecture (EA)
Первая версия нотации BPMN вышла в мае 2004 года (BPMN 1.0). Следующая версия появилась в январе 2011 года (BPMN 2.0). Наконец, в январе 2013 года компания OMG выпустила ту версию, которая в основном используется и сегодня – BPMN 2.0.2.
Основные графические элементы BPMN
BPMN-процесс – это любой бизнес-процесс, отражённый с помощью нотации. Процессы состоят из элементов, каждый из которых обозначается на схеме специальным значком.
Элементы нотации BPMN – это элементы графической схемы, но также и элементы самого бизнес-процесса.
Нотация опирается на следующие базовые графические элементы:
- Пул и Дорожки
- Действия
- Шлюзы или Развилки
- События
- Потоки
- Артефакты
BPMN элементы “Пул” и “Дорожка”
Весь бизнес-процесс состоит из пулов: совокупности операций + лиц, которые эти операции выполняют.
Например, пулом окажется весь набор действий по погрузке товара и отправке его клиенту.
При этом выделяют так называемые “дорожки”, из которых состоит любой пул. Для нашего примера одной из дорожек станет оформление документов, касающихся погрузки и отправки товара, второй дорожкой – физическая погрузка нужной партии на автомобиль и поездка автомобиля к клиенту. Обе эти дорожки дополняют одна другую, проходят параллельно, но в целом служат выполнению одного и того же этапа бизнес-процесса.
![]() |
Пул | Используется для обозначения границ бизнес-процесса |
![]() |
Дорожка | Используется для отражения ответственных исполнителей и их ролей в процессе |
BPMN элемент “Действие”
Под “действием” понимается единица работы, выполняемой в ходе исполнения бизнес-процесса. Действия могут быть как элементарными (задача/task), так и составными (подпроцесс/sub-process).
Есть несколько типов элементарных действий, которые отличаются условиями выполнения:
- Многократное выполнение действия в рамках одного процесса. Например, одно и то же действие может выполняться параллельно для каждого товара в заказе клиента.
- Циклическое действие выполняется многократно, пока заданное условие верно.
BPMN предполагает следующие графические отображения для основных типов действий:
Абстрактная задача | Используется для обозначения простого действия или операции, не имеющей дальнейшей декомпозиции в рамках текущего бизнес-процесса. | |
![]() |
Подпроцесс | Используется для отображения декомпозированного процесса, включенного в состав рассматриваемого процесса. Подпроцесс описан более подробно на своей диаграмме. |
![]() |
Процесс-ссылка | Используется для обозначения ссылки на один из наиболее часто повторяющихся процессов. |
Здесь стоит отметить, что современные BPM-системы зачастую предлагают более широкий набор типов действий, чем предлагает BPMN. Например, в инструменте для моделирования бизнес-процессов в Comindware Business Application Platform вы найдёте графические элементы для нескольких типов элементарных действий, а также встроенных кейсов:
![]() |
Пользовательская задача | Используется для отображения задачи, которую выполняет человек. |
![]() |
Задача на выполнение сценария | Используется для отображения шага процесса, по достижении которого автоматически выполняется скрипт. |
![]() |
Задача на вызов сервиса | Используется для иллюстрации шага процесса, на котором вызывается веб-служба или скрипт С#. |
![]() |
Встроенный кейс | Используется для представления нестандартной задачи, курируемой ответственным лицом или группой лиц. Кейсы используются, когда нужно быстро организовать в рамках процесса неструктурированную или слабоструктурированную активность. |
BPMN элементы “Развилка” или “Шлюз”
Под шлюзами понимаются элементы, определяющие ветвление и слияние потоков работ.
BPMN описывает 7 типов развилок. В качестве основных выделяют 2 типа:
Шлюз исключающего «или» | Используется для создания альтернативных потоков процесса или сходящихся потоков управления. | |
Параллельный шлюз | Используется для создания параллельных путей без оценки какого бы то ни было условия или для сходящихся потоков и синхронизации параллельных веток выполнения процесса. |
Двух развилок, описанных выше достаточно для построения бизнес-процессов любой сложности. Остальные типы развилок, описанных в BPMN, позволяют строить более компактные схемы процессов, но это преимущество многие эксперты ставят под сомнение, т.к., маловероятно, что люди без специальной подготовки поймут такие схемы.
Пример использования шлюза исключающего «или» для создания альтернативных потоков процесса:
- Этап 7. Звонок клиенту с целью оценить качество обслуживания.
- 1. Если клиент доволен, фиксация положительной оценки, закрытие бизнес-процесса.
- 2. Если клиент недоволен, выяснение причины.
Дальнейшая схема может сильно ветвиться: если клиент недоволен доставкой, то требуется связаться с начальником этой службы; а если качеством продукции, то следующим этапом будет передача претензии в отдел производства, либо эскалация (поднятие иерархического уровня) с целью донести сведения о такой претензии до более высокого руководства.
Фактически, шлюзы являются одними из самых ответственных и сложных этапов бизнес-процессов. От того, насколько грамотно будут прописаны все условия и следствия по принципу “Если… то”, во многом зависит эффективность работы всей системы.
BPMN элемент “Событие”
“Событие” является одним из главных элементов BPMN и служит для описания того, что должно случиться (в отличие от задачи, когда что-то должно быть сделано). Событием может быть, например, подписание договора, или разговор с клиентом.
Графические элементы событий в BPMN классифицируют двумя способами:
- В зависимости от положения события на схеме процесса:
Начальное событие (инициирующее бизнес-процесс) | |
Промежуточное событие | |
Конечное событие (заканчивающее бизнес-процесс). |
В случае с доставкой товара начальным событием будет, очевидно, заявка клиента. Либо же – звонок менеджера клиенту с предложением совершить покупку. Конечным событием в такой цепочке станет факт доставки, подтверждённый подписью клиента.
- По типу события классификация следующая:
Простое событие | Представляет не типизированное событие. | |
Событие-сообщение | Показывает отправку или получение сообщения. | |
Событие-таймер | Используется для моделирования регулярных событий. Также таймер может использоваться для моделирования моментов времени, временных промежутков и превышения лимита времени. |
Очень часто начальные и конечные события являются событиями-сообщениями.
BPMN элементы “Потоки”
Поток – это последовательность действий, которая обозначается стрелкой. Элемент “поток” показывает какое действие после какого необходимо совершить.
![]() |
Поток управления | На стандартный поток управления не воздействуют условия и он не проходит через шлюзы, т.е. является неконтролируемым. |
Условный поток управления | Используется для того, чтобы показать, что дальнейшее выполнение процесса будет происходить по определённому потоку только в том случае, если выполнятся заданное условие. Ромбик у основания стрелки добавляется, если условный поток управления является исходящим от процесса. Ромбик не добавляется, если условный поток управления является исходящим от шлюза. | |
Поток управления по умолчанию | Используется тогда, когда необходимо показать, что дальнейшее выполнение процесса будет происходить по определённому потоку только если не выполняется ни одно из заданных условий. | |
![]() |
Поток сообщений | Используется для отображения межпроцессного взаимодействия – отображает передачу сообщений или объектов из одного процесса в другой процесс или внешнюю ссылку. |
![]() |
Ассоциация | Применяется для визуализации связи между элементами потока и объектами, не являющимися элементами потока (артефактами). |
BPMN элементы “Артефакт”
Под артефактами в BPMN понимают объекты, которые не влияют на исполнение бизнес-процесса напрямую. Это могут быть документы, данные, информация.
Основные виды артефактов:
![]() |
Группа объектов | Используется для группировки графических элементов, принадлежащих одной и той же категории и позволяет повысить простоту восприятия диаграммы. |
Текстовая аннотация | Применяется для уточнений к диаграмме – комментариев и пояснений, которые увеличат читабельность диаграммы. | |
Объект данных | Используется для отображения информации о данных, которые обрабатывается в ходе процесса. |
Преимущества BPMN
BPMN-описание бизнес процесса имеет несколько преимуществ.
Первое – простота трансляции диаграмм в исполняемые модели с помощью языка формального описания бизнес-процессов.
Описание элементов BPMN является понятным для большинства участников бизнес-процессов и часто не требует никаких дополнительных разъяснений. С помощью простого графического выражения можно составить конкретные регламенты, которые будут исполняться сотрудниками.
Наряду с тем, что описание нотации BPMN 2.0 позволяет добиться понимания сотрудниками того, как происходят бизнес-процессы, данную нотацию поддерживают большинство современных инструментов бизнес-моделирования, что позволяет импорт готовых схем бизнес-процессов в BPM-системы.
Comindware Business Application Platform – современная платформа для автоматизации бизнес-процессов с поддержкой нотации BPMN 2.0, включая как возможность моделирования BPMN-процессов прямо в платформе, так и импорт схем бизнес-процессов из сторонних инструментов моделирования для их дальнейшего исполнения в системе Comindware.
Хотите узнать больше о платформе Comindware и оценить насколько она подойдёт для вашей компании? Закажите бесплатную демо-презентацию.
Заказать демо
Елена Гайдукова, маркетолог-аналитик. Работает в сфере BPM и автоматизации процессов с 2014 года. В настоящее время является бренд-менеджером решений на базе Comindware Business Application Platform.
Источник: www.comindware.ru
Краткое описание нотации BPMN
На сегодняшний день BPMN является одним из самых распространенных методов описания бизнес-процессов, которые сегодня уже «понятны» как бизнес-пользователям, так и программным продуктам, предназначенным для работы с бизнес-моделями. Т.е. этот язык описания также является стандартом для создания исполняемых алгоритмов в управлении бизнесом.
О том, что такое BPMN, написано много. Но практически вся информация, которую можно найти в Интернете, ориентирована на специалистов, которые ранее сталкивались с BPMN или другим стандартом моделирования бизнес-процессов. Предлагаю разобраться «с нуля» — что такое BPMN? В чем особенности и преимущества этой технологии и почему она все чаще используется для описания бизнес-процессов организации.
Методология моделирования бизнес-процессов — очень широкое понятие, по сути, это та самая база знаний, которую необходимо для практического применения языков моделирования бизнес-процессов. Я расскажу об этом в следующих статьях и не раз. Почему я акцентирую на этом внимание? Многие (и я в том числе) считают, что достаточно выучить язык бизнес-моделирования, и вы сможете строить бизнес-процессы.
Практика показывает, что базовые знания методологии моделирования бизнес-процессов здесь незаменимы. Перед тем как изучать моделирование, для начала необходимо ознакомиться с методологией бизнес-моделирования, понять общие принципы, приобрести определенные навыки бизнес-анализа и только потом приступать к изучению нотации BPMN.
BPMN: основные понятия
BPMN (Business Process Model and Notation) — это язык моделирования бизнес-процессов, который является промежуточным звеном между формализацией/визуализацией и воплощением бизнес-процесса. С помощью моделирования мы можем описать любые бизнес-процессы, и они могут выполняться в самых разных системах управления.
Можно сказать, что BPMN является частью двух основных компонентов:
- BPM (моделирование бизнес-процессов) — это среда, в которой вы непосредственно участвуете в моделировании. В одиночку или в команде.
- BPMS (система моделирования бизнес-процессов) — это инструменты для выполнения создаваемых вами моделей. Это может быть Bizagi, Comundo, ELMA и т.д.
Язык описания бизнес-процессов
И основой моделирования здесь является наличие языка описания бизнес-процессов. И важно понимать, что это действительно язык, точно так же как языки программирования или даже языки, на которых говорят люди, он тоже простой на базовом уровне и сложный, когда начинаешь изучать нюансы. В этом языке есть свои правила, семантика, правописание, свои законы, которые надо изучать и неукоснительно соблюдать. С другой стороны, как и всякий искусственный язык, предназначенный не для живого общения, а для строгого и однозначного описания каких-то действий и процессов, он принципиально проще «живых» языков, и его правила строго логичны.
Кроме того, из-за ограниченного круга задач, которые стоят перед этим языком, он гораздо более определен в терминологии. Но все же тут много нюансов, каких-то сочетаний «слов», несущих свою смысловую нагрузку. И очень важно строго соблюдать правила сочетания разных элементов языка и знать ограничения (что с чем сочетать недопустимо, как начинать описание, как заканчивать и т. д.).
И как любой технологический язык, описание бизнес-процессов имеет свои специфические конструкции, разобраться в которых без определенного уровня технологических знаний будет крайне сложно. Поэтому для изучения языка описания бизнес-процессов также важно, в первую очередь, понимать сами технологии, для описания которых он предназначен.
Например, для моделирования бизнес-процессов вам потребуются знания таких понятий, как «условия», «цикл», «декомпозиция» и др.
Важно понимать, что BPMN не является языком описания ИТ-систем. Эта нотация предназначена для описания предметной области реального бизнеса. И здесь могут быть задействованы как программные комплексы, так и люди (сотрудники компании, заказчики, поставщики). Это самое важное отличие данной нотации от графических средств описания программ.
Элементы нотации BPMN
Язык описания бизнес-процессов основан на следующих базовых объектах:
- Event – Событие;
- Activity – Действия;
- Gateway – Шлюзы или Развилки;
- Flow – Поток;
- Date – Данные;
- Artefact – Артефакты;
- Swimline – «плавательные дорожки»;
- Pool (Пул) — набор.
EVENT (СОБЫТИЕ)
Event — это событие, которое произошло в описании процесса. Эти события могут быть начальными, конечными или промежуточными.
ACTIVITY (ДЕЙСТВИЯ)
Activity – это те действия (задачи), которые необходимо выполнить на определенном этапе бизнес-процесса. При моделировании их обычно обозначают прямоугольниками, что соответствует сути действия.
Действия могут быть элементарными, т. е. неделимыми на некоторые более простые действия, и неэлементарными, т. е. такими, которые при детализации распадаются на последовательность определенных более простых действий.
Обычно действия делятся следующим образом:
Задача – единица работы. Если задача помечена символом +, то задача является подпроцессом и может быть детализирована.
Транзакция – набор логически связанных действий. Для транзакции может быть определен протокол выполнения.
Событийный подпроцесс помещается внутри другого процесса. Он начинает выполняться, если инициируется его начальное событие. Событийный подпроцесс может прерывать родительский подпроцесс или выполняться параллельно с ним.
Вызывающее действие является точкой входа для глобально определенного подпроцесса, который повторно используется в данном процессе.
GATEWAY (ШЛЮЗ, РАЗВИЛКА)
GATEWAY — это управляющий узел, который появляется при условном разветвлении бизнес-процесса. Графически изображается в виде ромба.
Шлюзы нужны и в тех случаях, когда процедура зависит от определенных факторов. Например, при работе с покупателями шлюз появляется на этапе, когда клиент принимает решение о покупке — «да или нет». При положительном решении необходимо совершить покупку, при отрицательном — выяснить возможные причины отказа, работать с «отказом» и т.д.
Наиболее используемые развилки
Оператор исключающего ИЛИ, управляемый данными. При ветвлении направляет поток лишь по одной из исходящих ветвей. При синхронизации потоков оператор ожидает завершения одной входящей ветви и активирует исходящий поток управления.
Оператор И. При разделении на параллельные потоки все ветви активируются одновременно. При синхронизации параллельных ветвей оператор ждет завершения всех входящих ветвей и затем активирует исходящий поток.
Оператор ИЛИ. При ветвлении активируется одна или более ветвей. При слиянии все выполняющиеся входящие ветви должны быть завершены.
POOL (ПУЛ)
Пул — это объект, описывающий один процесс на диаграмме. Его может не быть на карте, но он всегда есть. На одной диаграмме может быть несколько Пулов. Пул может быть расширен для просмотра деталей.
Пул также может содержать так называемые «дорожки». Они нужны для того, чтобы указать участников процессов, которые скрыты в пуле. Например, в процессе работы с клиентами участвует менеджер по продажам, начальник отдела продаж, возможно, бухгалтер или кассир.
Пулы (участники) и дорожки отражают распределение обязанностей. Пул или дорожка обозначает организацию, роль или систему. Дорожки позволяют иерархически делить пулы и другие дорожки.
Порядок обмена сообщениями может быть задан при помощи потока сообщений и потока управления.
DATE OBJECT (ДАННЫЕ, ОБЪЕКТЫ ДАННЫХ)
Объекты данных — это элемент, указывающий, какие данные и документы необходимы для начала действия или каковы результаты завершенного действия.
Объект данных может быть сгенерированным заказом. Для менеджера это будет результат действий, а для склада, принимающего заказ, начало действия (сбор товара и отгрузка).
MESSAGE (СООБЩЕНИЕ)MESSAGE (СООБЩЕНИЕ)
Этот элемент необходим для отображения отношений между двумя участниками процесса.
Это может быть Email, сообщения внутри системы совместной работы, переписка в любом из мессенджеров, которыми пользуются участники процесса, общение на сайте компании, СМС-сообщения и т.д.
ARTEFACT (АРТЕФАКТЫ)
Под артефактами в BPMN понимаются объекты, не являющиеся действиями и не имеющие прямого отношения к действиям. Это могут быть любые документы, данные, информация, не влияющие непосредственно на выполнение процесса.
Существует два типа артефактов:
- Группа объектов;
- Текстовая аннотация.
Группа объектов — это еще один способ объединить несколько элементов под общим символом, чтобы сэкономить место на диаграмме и упростить ее чтение. Здесь различные виды деятельности собраны под одним общим названием. Группа объектов также всегда может быть подробно рассмотрена. Группа выглядит как прямоугольник со скругленными углами, выполненный пунктирной линией с точками.
Текстовые аннотации используются для различных уточнений к диаграмме. Это могут быть комментарии, пояснения, другая информация, которая повысит читабельность схемы. Аннотации представляют собой незамкнутый прямоугольник, выполненный сплошной линией, от которого к объекту аннотации ведет линия, состоящая из точек.
Исполняемые и неисполняемые бизнес-процессы
В бизнес-моделировании процессы можно разделить на два типа — исполняемые, которые реально будут работать с помощью специального программного обеспечения типа Bizagi, и неисполняемые, т.е. бизнес-модели, которые нужны только для изучения и демонстрации вариантов того, как предприятие работает.
В принципе, особой разницы между их построением нет, здесь важен лишь желаемый результат. Либо бизнес-модель будет применяться только для облегчения взаимопонимания между заказчиком (менеджером) и консультантом (исполнителем). Либо эта нотация в дальнейшем будет использоваться в какой-то программной среде для организации работы компании. В нормальных руководствах вы не найдете такого деления на две части. Но я лично считаю, что есть смысл условно разделить бизнес-процессы таким образом, так как при разном желаемом результате потребуется разная глубина проработки деталей и выбор возможных инструментов для работы.
Исполняемые бизнес-процессы должны быть построены в строгом соответствии со всеми правилами нотации BPMN, иначе программное обеспечение не сможет корректно работать с составленной бизнес-моделью. Исполняемые процессы нужны, например, на предприятиях, где принят процессный подход к деятельности. Программное обеспечение позволяет отслеживать все процессы в режиме реального времени, а на основании данных, полученных на каждом этапе, руководитель компании и отделов всегда сможет понять, на каком этапе находится работа над тем или иным процессом. Этот метод позволяет значительно повысить эффективность управления.
Неисполняемые бизнес-процессы нужны исключительно для демонстрации бизнес-модели. Это может быть диаграмма, показывающая реальное положение дел на предприятии, это может быть наглядная иллюстрация предполагаемых изменений в реинжиниринге. При этом, конечно, можно использовать любые удобные инструменты, в том числе и традиционный для многих IDEF0. А соблюдение правил языка моделирования необходимо только для достижения взаимопонимания.
Приступая к работе с BPMN, первоначально рекомендуется создавать неисполняемые бизнес-процессы. Это действительно очень удобные нотации для иллюстрации предложений, демонстрации «узких мест» в бизнесе, даже просто для себя понять структуру работы организации очень удобно с помощью нотаций. В этом очень помогает визуальная графика и строгие правила.
Исполняемая версия требует глубоких знаний BPMN, а также внимательного отношения к каждой детали, также как создаете программа (алгоритм) для компьютера, просто используя графическую нотацию, а не текстовый язык. Это работа для опытных специалистов.
Подходит ли BPMN для малого и среднего бизнеса?
Нотации BPMN можно и даже нужно использовать при работе с малым и средним бизнесом. Вполне возможно, что вы не будете реализовывать бизнес-модель на программном уровне, так как это всегда дополнительные затраты, а в среде малого бизнеса нет необходимости в таких инструментах для контроля и анализа работы.
Но, тем не менее, на уровне неисполняемых бизнес-процессов я очень активно использую BPMN. Дело в том, что несмотря на сложность записи (т.е. обучение и умение работать с нотациями), уровень понимания BPMN невысок, т.е. чтение нотаций не требует каких-то специальных знаний и навыков. Графические обозначения понятны интуитивно. И я еще не встречал ни одного человека, которому было бы трудно читать нотации. Эта нотация создана специально для нахождения общего языка между аналитиком и обычными бизнесменами (менеджерами).
В итоге, как я писал выше, с помощью BPMN вы экономите свое время и время заказчика (менеджера) и достигаете наивысшего уровня взаимопонимания. Нотации не допускают «двойного чтения», поэтому очень помогают в работе.
Минусы и важные особенности BPMN
Для выбора любого средства также важно понимать возможные недостатки:
- В нотации BPMN имеется значительное количество понятий и терминов, их необходимо знать и правильно применять.
- Высокий начальный уровень. Как и в случае с любым многофункциональным инструментом, для изучения требуется больше времени по сравнению с другими нотациями (IDEF0, IDEF3).
- Требуется знание бизнес-анализа. В BPMN модели — это не просто картинки или диаграммы, которые можно нарисовать в любом графическом редакторе. Здесь очень важна хорошая структура и четкая последовательность.
Пример практического применения BPMN
Конечно же, без примера описание моделирования бизнес-процессов было бы неполным и не до конца понятным. В качестве иллюстрации моделирования в нотации BPMN можно взять процесс регистрации пассажира на рейс самолета.
Применение диаграмм BPMN на практике
- Делайте диаграммы как можно разветвленными. Чем больше элементов на вашей диаграмме, тем труднее ее будет читать вам и вашим клиентам.
- Используйте максимально простую и понятную терминологию. Очень важно, чтобы ваши клиенты, а также техники, которые будут работать с диаграммами, понимали все (или почти все) термины без дополнительных пояснений.
- Все имена процессов должны быть максимально информативными и понятными. В противном случае читабельность диаграммы также будет крайне низкой. Имена процессов лучше всего подходят либо к терминам, используемым в конкретной организации для описания работы, либо просто к интуитивно понятным фразам.
- Также важно четко указать обязанности сотрудников компании, бизнес-модель которой вы описываете. Самое простое решение — выбрать имена среди существующих подразделений. А если желаемой должности или отдела в компании еще нет, не бойтесь придумать ее самостоятельно. Но постарайтесь сделать название еще и «говорящим», понятным широкому кругу бизнес-аудитории.
- Должно быть достаточно подпроцессов, чтобы избежать ненужных деталей, но не более того. Помните о чувстве меры. Если подпроцессов слишком мало, то действия, которые должны быть спрятаны в них, будут в общем процессе, создавая дополнительные объекты, стрелки, ответвления и, как следствие, путаницу. Если переборщить со стремлением убрать все в подпроцессы, то диаграмма потеряет свою информативность, а некоторые изменения в подпроцессе начнут косвенно влиять на результаты всего процесса.
- Не бойтесь ошибаться! Если вы сделаете ошибку в исполняемой методологии, это очень быстро обнаружится при запуске (отладке) процесса. Если вы создаете просто наглядную схему, то мелкие ошибки не так важны, главное, чтобы эта схема помогла вам и людям, для которых вы ее делаете (заказчикам, техническим специалистам), понять все нюансы вашей идеи. И в любом случае они учатся на ошибках, а корректировки бизнес-модели можно вносить быстро и легко.
Какой бы вариант бизнес-моделирования вам не понадобился, бояться BPMN не стоит — нотация очень проста в освоении, а вашим коллегам и клиентам не нужны даже минимальные знания, чтобы читать такие схемы, моделирование очень понятен, а готовые диаграммы интуитивно понятны. понятно. Попробуйте, у вас тоже обязательно все получится.
- Блог компании Auriga
- Анализ и проектирование систем
- Бизнес-модели
Источник: habr.com