Описание бизнес процессов bpmn инструмент

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

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

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

BPMN для бизнес-аналитиков

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

BPMN: ОСНОВНЫЕ ПОНЯТИЯ

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

Можно сказать, что BPMN является частью двух основных компонентов:

• BPM (моделирование бизнес-процессов) — это среда, в которой вы непосредственно участвуете в моделировании. В одиночку или в команде.
• BPMS (система моделирования бизнес-процессов) — это инструменты для выполнения создаваемых вами моделей. Это может быть Bizagi, Comundo, ELMA и т.д.

ЯЗЫК ОПИСАНИЯ БИЗНЕС-ПРОЦЕССОВ

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

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

BPMN.Studio — бесплатный инструмент для моделирования бизнес-процессов

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

Например, для моделирования бизнес-процессов вам потребуются знания таких понятий, как «условия», «цикл», «декомпозиция» и др.

Важно понимать, что 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 не стоит — нотация очень проста в освоении, а вашим коллегам и клиентам не нужны даже минимальные знания, чтобы читать такие схемы, моделирование очень понятен, а готовые диаграммы интуитивно понятны. понятно. Попробуйте, у вас тоже обязательно все получится.

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

Глава 4. BPMN. I’m lovin it

Business Process Modeling Notation (BPMN) была разработана в 2002 году организацией под названием Business Process Management Initiative (BPMI), которая в 2005 году слилась с некоммерческой Object Management Group, которая, в свою очередь, сейчас поддерживает нотацию и уже готовится к выпуску версии 2.0 (на сайте bmpn.org выложена спецификация уже второй бета-версии). На сей же момент текущая версия — 1.2, на которую пока и ориентируемся.

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

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

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

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

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

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

В-пятых, можно привязать к определённым действиям также и объекты системы, которые используются или создаются в ходе выполнения того или иного действия, т. е. можно описать не только workflow, но и documentflow. Смотрим на объекты под общим названием «артефакты», в частности с типом «Документ».

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

В общем, достоинств нотации очень много, однако, что греха таить, есть у нотации BPMN и ограничения.

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

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

В-третьих, нотация не позволяет указать стоимость выполнения того или иного действия в денежном выражении (как, например, IDEF0).

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

Источник: ecm-journal.ru

BPMN 2.0 – легкое понимание бизнес процессов

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

Современная история теории управления бизнес-процессами начинается на рубеже XXI века, когда была сформулирована концепция процессного управления организацией – BPM ( Business Process Management ). BPM рассматривает бизнес-процесс как ресурс предприятия, для которого применимы такие методы как анализ и мониторинг, симуляция, описание, моделирование и управление. В целях унификации методов описания и моделирования бизнес-процессов были разработаны формальные системы условных обозначений (нотации), которые также иногда называют языками.

Одним из таких языков является BPMN (Business Process Management and Notation). Стандарт BPMN версии 1.0 первоначально был разработан рабочей группой Business Process Management Initiative Notation в 2004 году . Текущая версия 2.0.2, вышедшая в 2013 году, поддерживается консорциумом Object Management Group ( OMG ), в который в результате слияния BPMI и OMG вошли специалисты, стоявшие у истоков создания нотации.

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

Описание

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

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

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

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

Задачи (операции) – действия, выполняемые в рамках бизнес-процесса его участниками.

Существует несколько подвидов Задач, а также другие объекты, которые некоторые относят к частным случаям задач:

1. Задачи:

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

1. Подпроцессы – это действия, которые могут включать в себя: другие действия, шлюзы, события и потоки операций. Существует 4 вариации:

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

1. Задачи-вызовы – это задачи, которые вызывают глобальный процесс BPMN или глобальную задачу. Также делятся на 5 подвидов:

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

Шлюзы (развилки) – операторы, определяющие ход протекания процесса.

Существует несколько разновидностей шлюзов:

• Исключающий – логический оператор “строгое ИЛИ (XOR)”.
• Включающий – логический оператор “ИЛИ (OR)”
• Параллельный – логический оператор “И (AND)“
• Комплексный – аналогичен включающему шлюзу “ИЛИ (OR)”.
• Событийный – логический оператор “строгое ИЛИ (XOR)”, управляемый событиями.

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

События можно отнести к 3 категориям с подвидами:

1. Стартовые события (дающие начало бизнес-процессу);
2. Промежуточные события (происходящие в ходе выполнения бизнес-процесса):

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

1. Конечные события (события, с наступлением которых бизнес-процесс завершается).

Категории, в свою очередь, включают в себя типы событий:

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

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

Включают в себя:

• Данные:

• Входящие;
• Исходящие.

• Входящие;
• Исходящие.

Артефакты – графические и текстовые элементы, с помощью которых можно внести дополнительную информацию на модель или визуально выделить некоторые элементы (группа, сноска и этап).

Связи (потоки) – способ отображения взаимосвязей между объектами на диаграммах. Существует 5 типов связей в BPMN:

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

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

К преимуществам нотации BPMN можно отнести то, что она:

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

Из недостатков можно выделить следующее:

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

В некоторых организациях персонал от бизнеса плохо воспринимает нотацию из-за ее IT -корней.

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

Растущая популярность BPMN в качестве стандарта привела к тому, что его стали поддерживать наиболее распространенные средства моделирования, в том числе и SILA Union .

Модели BPMN 2.0 в SILA Union

Вручение Нобелевской премии

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

• Эффективный инструмент менеджмента
• Описывает все необходимые бизнесу процессы, объекты и взаимосвязи
• Учитывает возникновение различных событий и объясняет необходимость определенных операций
• Обширные графические возможности
• Может использоваться для любых процессов
• Выраженная гибкость нотации
• Возможность использования различными аудиториями

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