Для чего нужна bpmn
BPMN простым языком
Данный цикл статей предназначен для всех, кто собирается приступить к созданию моделей с использованием BPMN.
Часть 1. Зачем люди моделируют бизнес-процессы
Моделирование бизнес-процессов обычно рассматривают в контексте их оптимизации с целью повысить эффективность бизнеса в компании в целом. Обычно такая потребность возникает, когда в компании имеются проблемы: например, низкая эффективность ее сотрудников, не оптимальная организационная структура, запутанные коммуникации или неправильное разграничение зон ответственности между ее подразделениями могут ограничивать возможности организации, приводить к снижению ее прибыли, сдерживать ее развитие, делать ее менее конкурентоспособной.
Проблемы, связанные с не оптимальным подходом к построению и управлению бизнес-процессами компании, могут проявляться на всех этапах ее развития. На ранних этапах, когда компания еще только формируется, отсутствие строгого разграничения обязанностей и зон ответственности сотрудников и целых структурных подразделений компании часто приводит к конфликтным ситуациям. Нехватка квалифицированных кадров в различных областях и невозможность достаточно точно спрогнозировать, когда и где понадобится тот или иной специалист, сдерживает развитие компании. Отсутствие культуры передачи знаний вызывает проблемы при увольнении и замене сотрудников, и отрицательно сказывается на работе компании в целом.
Рост размеров компании, увеличение числа ее сотрудников часто приводит к тому, что ее деятельность усложняется, бизнес-процессы становятся запутанными, и управлять ими становится нелегкой задачей.
Как правило, в таких ситуациях принимается решение сформировать новые или кардинально улучшить старые подходы к управлению, сформировав четкую и продуманную систему управления организацией. Осуществить подобную трансформацию практически невозможно без построения бизнес-модели, учитывающей особенности компании и определяющей стратегию ее будущего развития. Бизнес-процесс — один из «кирпичиков» в фундаменте бизнес-модели организации.
Цифровизация, цифровая трансформация компаний, как в государственном, так и в частном секторе, так же невозможна без построения бизнес-модели, как и любая другая трансформация бизнеса. Подобная практика — не просто дань «цифровой» моде, задаваемой высокотехнологичными компаниями; она опирается на мировые стандарты. Наличие документированной бизнес-архитектуры предприятия является требованием международных стандартов ISO 9001:2000 и российских стандартов ГОСТ Р ИСО 9001-2001. Проверенные на практике подходы рекомендуют придерживаться определенного порядка построения бизнес-архитектуры. Без предварительного моделирования изменений в бизнес-процессах и оценки эффектов этих изменений невозможно определить количественные и качественные результаты трансформации, оптимизировать расходы в процессе трансформации.
Построение бизнес-модели затрагивает не только организацию процессов. Современные подходы рассматривают проектирование архитектуры информационных систем не как отдельную задачу, а связывают ее в единое целое с задачами построения бизнес-архитектуры и информационной архитектуры.
Говоря о том, зачем и как моделировать бизнес-процессы, невозможно обойти вопрос о том, что такое бизнес-процессы вообще, и с какой точки зрения их можно рассматривать.
Существует несколько определений бизнес-процессов, каждое из которых отражает определенную точку зрения на бизнес-процесс.
Определение 1. Бизнес-процесс — совокупность взаимосвязанных или взаимодействующих видов деятельности, преобразующих входы в выходы (ISO 9000:2000).
Определение 2. Бизнес-процесс — структурированный набор действий, охватывающий различные сущности предприятия и подчиненный определенной цели (ISO/CD 15531-1).
Определение 3. Бизнес-процесс — совокупность различных видов деятельности, в рамках которой «на входе» используется один или более видов ресурсов, и в результате этой деятельности «на выходе» создается продукт, представляющий ценность для потребителя (М. Хаммер, Д. Чампи, Реинжиниринг бизнес-процессов).
Определение 4. Бизнес-процесс — несколько связанных работ или процедур, в совокупности реализующих конкретную цель текущей деятельности в рамках существующей оргструктуры (Ойхман Е.Г., Попов Э.В, Реинжиниринг бизнеса).
Как мы можем видеть, в определениях 3 и 4 ставится акцент на создании продукта, представляющего ценность для конечного потребителя, или на достижении конкретной цели. Существование цели, которой необходимо достичь, — отличительная черта бизнес процесса. Как правило, сами цели не отражаются в модели процессов; однако, они являются важным элементом бизнес-процессов.
Говоря о том, зачем моделировать бизнес-процессы, невозможно не сказать о том, кто участвует в моделировании бизнес-процессов, и кто является конечным потребителем результатов этого моделирования. В зависимости от целей моделирования, будет определяться состав заинтересованных лиц — руководителей и исполнителей.
Моделирование может охватывать разные аспекты деятельности предприятия, и состав заинтересованных лиц будет определяться направлениями деятельности, выбранными для моделирования.
Как правило, модель бизнес процесса используется достаточно широким кругом лиц на предприятиях, где проводится оптимизация бизнес-процессов и выполняется построение бизнес-архитектуры. Ниже приведен примерный состав пользовательской аудитории моделей бизнес-процессов:
Бизнес-аналитики по различным направлениям деятельности организации;
Разработчики информационных систем;
Системные архитекторы, разрабатывающие архитектуру отдельных информационных систем;
Бизнес-аналитики, выполняющие проектирование организационной структуры предприятия;
Руководители подразделений, заинтересованные в оптимизации бизнес-процессов, выполняемых в этих подразделениях.
Далее мы рассмотрим, как организовано взаимодействие между этими группами в рамках работы над моделью бизнес-процесса.
Что такое BPMN-диаграмма и зачем она нужна в разработке
Схемы по методу моделирования бизнес-процессов (BPMN) используются в разных сферах, например, в продажах и ведении проектов. В разработке этот инструмент важен на этапе бизнес-аналитики: с помощью BPMN описываются все сценарии взаимодействия пользователей и системы.
Эта система условных обозначений создавалась специально для того, чтобы найти общий язык между аналитиками и управленцами без технической подготовки.
В YuSMP Group мы отдаем BPMN-диаграммы продуктов после окончания дискавери-фазы. Эта нотация входит в список обязательных артефактов, которые получает клиент.
Business Process Model and Notation (нотация моделирования бизнес-процессов) — это система условных обозначений, которая отображает бизнес-процессы с помощью блок-схем. BPMN диаграмма показывает в какой последовательности совершаются рабочие действия и перемещаются потоки информации.
При помощи моделирования можно описать любой бизнес-процесс, но в контексте этой статьи мы говорим больше о веб-системах, сайтах и приложениях.
Наглядная схема показывает, где в процессах есть узкие места или вовсе тупики, из-за которых клиенты уходят или не заканчивают целевое действие (заявка, покупка, звонок). BPMN подсвечивает места, которые можно улучшить и моделирует способы адаптации под новые условия.
Главное преимущество BPMN-диаграмм — это то, что они понятны и внутри организации, и за ее пределами. Нотация описывает процессы языком, который доступен всем участникам проекта. Его понимает команда разработки (бизнес-аналитики, программисты, продакт-менеджеры) и сторона заказчика (владелец и сотрудники).
Информация в графическом виде более доступна для восприятия, чем сложный технический текст. Схемы упрощают работу над проектом: заказчику понятно, как будет работать система и он может вносить коррективы еще на этапе обсуждения проекта.
Но если этот язык легок для восприятия, это не значит, что им может пользоваться кто угодно. BPMN-схемы готовят специалисты — бизнес-аналитики. Они подробно и последовательно описывают бизнес-процессы так, чтобы проект потом можно было легко внедрить в разработку.
На примере фрагмента схемы, которую мы создавали для платформы онлайн-обучения, покажем основные объекты языка BPMN и как они взаимодействуют друг с другом.
На иллюстрации: «Вход на сайт».
На иллюстрации: «Есть логин и пароль?».
На иллюстрации: «Да/Нет».
На иллюстрации: «Запросить у владельца курса логин и пароль».
BPMN — это схема из блоков и соединительных элементов, которые отображают все действия, происходящие в системе. Эту диаграмму составляют на дискавери-фазе бизнес-аналитики.
С помощью BPMN-диаграмм работа идет динамичнее: бизнес-аналитики быстрее отдают проект разработчикам, которым не нужно тратить время на то, чтобы вникать в систему и разбираться в процессах.
Команда разработки и заказчик лучше понимают друга, BPMN исключает возможность «двойного прочтения», а значит и недопониманий тоже.
Диаграмма улучшает коммуникацию не только внутри компании, но и создает единое информационное поле в общении с заказчиком.
BPMN наглядно показывает слабые места, где потенциальные клиенты могут уйти. А значит, исправить или вовсе предотвратить “утечку” будет намного проще.
А какое его истинное назначение?
Есть более проще нотации типа EPC. Одно из назначений BPMN это написание однозначных инструкций в графическом виде для последующего выполнения в системах типа BPMS. То есть, это более жесткая нотация, как очень высокоуровневый язык программирования.
Для целей бизнес анализа и обмена информацией с простыми менеджерами он избыточен. Как по набору нотационных артефактов, так по жесткости валидации схем. Но в ввиду разных причин его применяют в основном для визуализации, сократив элементный состав (что в итоге почти приравняла его к нотации EPC).
Как описать бизнес-процесс в формате нотации BPMN. Пошаговая инструкция + видео
О бизнес-процессах я уже писал много раз, в том числе, посвящал свои публикации пояснениям, что это такое, и как в принципе описывать различные бизнес-процессы. Подробно об этом вы можете почитать в статье «Что такое бизнес-процесс и описание бизнес-процесса» и в других публикациях, посвященных этой тематике. Сейчас я хочу поговорить о том, как собранную информацию перенести в формат BPMN, т.е. как правильно описывать бизнес-процессы с использованием этой нотации.
Важно понимать, что пока бизнес-процесс не описан в графическом виде, можно считать, что его нет, так как текстовые описания или рассуждения в устной форме оценить крайне сложно. Но очень часто люди путаются, с чего начинать и как правильно действовать при составлении графической модели. В помощь всем желающим я составил примерную последовательность действий.
Следуйте этим пунктам и составление бизнес-процесса пройдет быстро и без критических ошибок:
Получить список действий.
Перевести действия в задачи.
Назначить действия исполнителям.
Вычислить финалы процесса.
Описать условия (шлюзы).
Описать внешние по отношению к процессу сущности.
Переложить описания в нотации.
В этой статье я не планирую описывать элементы BPMN, для этого есть множество учебников и мануалов, в том числе, среди моих публикаций. Этой нотации посвящены такие материалы: «Краткое описание BPMN с примером», «Спецификация BPMN 2. Перевод официальной документации» и др. По той же причине не ждите, что я покажу наглядно, как использовать все возможные элементы. Кроме того, здесь я не буду говорить об исполняемых бизнес-процессах. При их составлении есть свои правила, особенности, ограничения. Здесь пойдет речь о составлении бизнес-процесса в нотации BPMN, предназначенного для анализа работы.
1. Получить список действий
Первое, что вам нужно после того, как вы провели интервью с людьми, которые участвуют в процессе, это получить список действий.
Важно понимать, что сейчас вам нужны именно действия, а не задачи. Задачи будут на следующем этапе. Обычно люди описывают свою работу текстом, как есть. И описывают свою работу как они делают, и что они делают. И ваша задача на основе интервью составить последовательность действий.
Как из описания сделать список действий
Давайте разберемся подробнее, как это сделать максимально быстро и корректно:
По итогам интервью составьте текстовое описание. Например:
«При необходимости в товаре которого нет в наличии продавец создает документ “Заявка на закупку” и направляет его на согласование закупщику. Закупщик проверяет необходимость в закупке данного товара и если закупщик разрешает закупить товар согласно документу “Заявка на закупку”, то продавец информируется о разрешении закупить товар, и закупщик создает документ “Заказ поставщику”. Иначе заявка аннулируется с комментарием содержащем причину отказа в закупке товара. Продавец информируется об отказе в закупке товара.»
Естественно, это может быть не одно и не два интервью, некоторые вещи вы можете взять из документации (инструкции, формы документов). Но основной источник все таки интервью, так как вы делаете работу для людей и они будут работать с ней.
Уберите лишнее. Посмотрите на текст внимательно, избавьтесь от ненужных слов.
В приведенном примере убрать следует фразу «которого нет на складе». Независимо от того, есть такой товар или нет, если возникает необходимость в товаре от поставщика, потребуется “Заявка на закупку”.
То есть с точки зрения выполнения, не имеет значения почему сотрудник дело то или иное действие. Нам не интересны вопросы “почему” и “зачем”, нам интересен ответ на вопрос “что делает”, чтобы затем получить “что сделать”. Мотивация сотрудников не касается нас в данном случае.
Выделите действия. В том же примере я выделил их подчеркиванием:
«При необходимости в товаре продавец создает документ “Заявка на закупку” и направляет его на согласование закупщику. Закупщик проверяет необходимость в закупке данного товара и, если закупщик разрешает закупить товар согласно документу “Заявка на закупку”, то продавец информируется о разрешении закупить товар, и закупщик создает документ “Заказ поставщику”. Иначе заявка аннулируется с комментарием, содержащем причину отказа в закупке товара. Продавец информируется об отказе в закупке товара.»
Создается список действий.
В приведенном примере он выглядит так:
Продавец создает документ “Заявка на закупку”
Закупщик проверяет необходимость в закупке данного товара
Если закупщик разрешает закупить товар
Продавец информируется о разрешении закупить товар
Закупщик создает документ “Заказ поставщику”
Иначе заявка аннулируется с комментарием
Продавец информируется об отказе в закупке.
Таким образом, вы просто составляете список действий, основываясь на объяснениях человека. Если возникают какие-то сомнения, этот список можно и нужно согласовать с людьми, которые занимаются этой работой.
Все же, почему действия, а не задачи? Все просто. Это самый понятный язык для людей, которые непосредственно выполняют работу. Они так думают, они так сами описывают свою работу. И ваш список с ними согласовывать также будет намного проще в таком виде.
2. Перевести действия в задачи
На этом этапе согласованный список действий нужно уже перевести в задачи. Т.е. вместо действия «распечатывают накладную» у вас должна появиться задача «распечатать накладную». Теперь там, где были описания действий, должны стоять задачи, описанные глаголами неопределенной формы, т.е. ответы на вопрос «что нужно сделать».
В некоторых других нотациях “согласовать сделку” или какие-то другие сложные действия допустимо рассматривать, как задачи. Но это возможно только в тех нотациях, где такие комплексные задачи впоследствии можно декомпозировать.
В BPMN такой возможности нет. Потому здесь задача должна быть самым простым действием. В этой нотации имеются подпроцессы (Sub-Process) или подзадачи (Sub-Task). Эти возможности мы будем рассматривать позже. Здесь и сейчас я говорю именно о задачах.
Если действия могут быть сложными и комплексными, то задачи – максимально простыми и конкретными. Например, вам в качестве описания действия предложен вариант «Проводим инвентаризацию склада». Здесь мало сменить форму глагола на «Проинвентаризировать склад», нужно разделить это сложное действие на части и выстроить последовательность.
3. Назначить действия исполнителям
После того, как вы описали задачи, нужно определиться, кто будет их выполнять. На этом этапе исполнителей стоит назначать предварительно, например, простым карандашом на бумаге. На самом деле, вы еще не можете 100% определить, кто именно будет выполнять то или иное действие. Часть исполнителей очевидны, другие могут измениться по итогам работы над бизнес-процессом.
Например, сейчас заявку на закупку товаров согласовывает закупщик. В будущем мы можем принять решение, что при сумме товара больше определенного порога, финальное согласование выполняет руководитель. В результате для крупных заказов для задачи “согласование” изменится исполнитель.
Эти задачи уже будут тем, что называется task, т.е. задачами в BPMN. Кроме того, обязательно нужно составить список исполнителей, он потребуется при работе в нотации.
4. Вычислить финалы процесса
Процесс может завершаться в нескольких случаях. Это может быть успешный результат, при котором выполняются все этапы и достигается результат. Может быть отказ и прекращение процесса на том или ином этапе. В текстовом описании явно выделяется только успешная реализация. Этапы отказа обычно описываются где-то в середине.
Например, это может быть «Если необходимости в товаре нет, закупщик аннулирует заявку и отправляет уведомление продавцу».
По логике текстового описания, такой вариант развития событий может находиться где-то в середине текста. Но для построения графической диаграммы нужно четко определить, где будут находиться варианты завершения процесса.
5. Описать условия (шлюзы)
У нас уже есть задачи и их исполнители. Пришло время разобраться с условиями. Речь здесь идет не о тех условиях, в которых протекает бизнес-процесс, а о том, что при определенных условиях выполняется один перечень действий, а при других – процесс идет по другому пути.
Например, решение о необходимости закупки товаров принимает закупщик. Если в будущем мы решим, что этот закупщик будет работать только с определенной группой товаров, понадобится проверка условия: в зависимости от группы товаров передавать заявку в работу одному из закупщиков.
Эти условия в BPMN называются шлюзами. Их обязательно нужно предусмотреть и описать.
6. Описать внешние по отношению к процессу сущности
При описании любого бизнес-процесса вы столкнетесь с двумя типами сущностей:
Внутренние сущности вы описываете в рамках задач бизнес-процесса. Внешние нужно перечислить отдельно и указать, где и на каком этапе необходимо обращаться к внешним сущностям. В рамках стандарта BPMN внешние сущности не являются обязательными, но они добавляют больше смысла графической диаграмме.
7. Переложить описания в нотации
Вы собрали необходимую информацию, остается перенести ее в графический вид.
Задачи. Это прямоугольники с закругленными краями, внутри которых вы пишете название задачи.
Шлюзы. Условия выглядят ромбами. Разместите их на диаграмме.
Соедините между собой задачи и шлюзы стрелками.
Укажите список исполнителей, а также исполнителя для каждой задачи.
Сверху разместите «внешний пул», т.е. все внешние сущности, и свяжите их с нужными задачами.
В своем примере я не говорил об артефактах. Их также можно использовать для каких-то нюансов, которые вы не планируете подробно описывать в виде задач, но все же они важны для работы. Кроме того, не забывайте указывать вид задачи. Они могут быть автоматическими, могут выполняться только вручную, а могут исполняться человеком, который работает в информационной системе.
Взаимодействие диаграммы и описания диаграммы
Когда мы на основе текстового описания создаем диаграмму, эта диаграмма взаимодействует с описанием. С одной стороны, графика создается на основе текстового описания. С другой, далее вы передаете эту диаграмму руководителю или заказчику, согласуете с ответственными сотрудниками, которые будут участвовать в процессе и т.д.
Все они могут в процессе обсуждения вносить предложения правок и дополнений. И если вы вносите изменения в графическую диаграмму, необходимо соответствующим образом изменить и текстовое описание.
Например, вы предложили вариант диаграммы, где закупщик самостоятельно принимает решение о закупке товара или отклоняет заявку. Руководитель предложил разделить закупки по типам товаров или добавить согласование на уровне начальника отдела закупок в случае суммы, превышающей определенный порог. Все эти изменения вы вносите в диаграмму, после чего обязательно нужно изменить и/или дополнить текстовое описание.
По сути, текстовое описание и графическая диаграмма должны дополнять друг друга. Картинка намного легче воспринимается, она информативнее, при помощи графики намного проще пояснить основные этапы и последовательность задач в процессе, а также оценить его эффективность. С другой стороны, текстом вы можете дать больше информации, подробнее описать какие-то важные действия и т.д. Потому картинка и текст должны описывать один и тот же процесс и обязательно взаимодействовать, т.е. при изменении картинки меняется текст, при изменении текста меняется картинка.
Советы по описанию
Как видите, если разделить свои действия на описанные выше этапы, составить диаграмму BPMN оказывается не так и сложно. При этом я рекомендую руководствоваться следующими принципами:
Чем меньше задач, тем лучше. Не стоит детализировать работу больше, чем это действительно необходимо. Причина проста: чем больше элементов на диаграмме, тем проще запутаться. К тому же с возрастанием количества элементов на диаграмме увеличивается ее сложность, а соответственно и труднее соблюсти баланс между информативностью и легкостью восприятия.
Не усложняйте. В BPMN есть возможность совмещать события и задачи (task). По возможности лучше избегать подобных решений, разделяйте их, делайте диаграмму максимально простой и читабельной.
Описывайте процессы, которые вы можете представить в реальности. Всегда помните о цели – вы описываете не просто что-то умозрительное, но последовательность работы реальных людей. Потому, если вы не можете представить то, что описываете, лучше вообще не делать такое описание.
Старайтесь быть лаконичными. Избегайте больших текстов.
Никогда не пользуйтесь в описании задач союзом «и». Недопустимо называть задачу «договориться о доставке и подготовить заказ к отгрузке». Это две отдельные задачи.
Я предложил вам последовательность действий, которую считаю правильной и удобной, но она не является обязательной. С опытом вы, скорей всего, как и я, начнете пропускать первые этапы. Я уже давно пропускаю текстовое описание, сразу пишу список действий и список исполнителей, так как моего опыта хватает, чтобы первые этапы провести “в голове” и сразу сформулировать последовательность действий или даже задач. В некоторых случаях, когда процесс с моей точки зрения не является сложным, я сразу приступаю к работе с графикой, так как я уже хорошо знаю все нюансы подобных процессов и все задачи также формулирую “в голове”. А если вы не уверены в результате, пользуйтесь предложенной последовательностью действий. Мой вариант поможет вам прийти к нужному результату, но он не является единственно правильным и обязательным.
Надеюсь, что предложенный выше алгоритм работы поможет вам быстро и безошибочно строить описания BPMN-диаграмм для ваших бизнес-процессов.
Руководство для начинающих по использованию BPMN в повседневной работе
Что такое BPMN?
Не верь чужим речам, а верь своим глазам. Лучше один раз увидеть, чем сто раз услышать. Не рассказывайте сказок. Именно такие поговорки сделали Нотацию моделирования бизнес-процессов (BPMN) чрезвычайно популярной среди многих типов компаний, отраслей и профессий. Но что такое BPMN и как этот метод работает?
В двух словах, BPMN — это стандартизированный метод отображения блок-схем, который позволяет создавать и обмениваться простыми для понимания диаграммами. Эти диаграммы могут визуально моделировать этапы бизнес-процесса от начала до конца.
Пример схемы процесса изменения адреса BPMN (выше)
Хотя существует несколько методов моделирования процессов, BPMN быстро на практике стала стандартом моделирования процессов, и для этого есть веская причина.
Каковы ее возможности?
Одно из наиболее значительных преимуществ BPMN заключается в ее способности создавать блок-схемы, которые могут быть столь просты или сложны, насколько это необходимо. Это позволяет заинтересованным сторонам на всех уровнях (техническом или нет) понять их.
Именно это качество, вероятно, объясняет популярность BPMN. Опрос 2016 года показал, что 64% компаний заинтересованы в использовании BPMN для упрощения своих бизнес-процессов. Цель для большинства компаний проста: сэкономить деньги за счет снижения затрат и повышения производительности.
Почему это необходимо?
Ставки высоки. Рассмотрим статистику из опроса предприятий 2018 года:
Помимо повышения эффективности, другие важные причины для поддержки работы по созданию бизнес-процессов включают в себя:
От ИТ, финансовых услуг, страхования и производства до образования, телекоммуникаций, розничной торговли, компьютеров и программного обеспечения — каждая компания может извлечь выгоду из улучшения бизнес- или организационных процессов.
Использование BPMN
Цель BPMN — дать всем четкое представление о процессе от его начала до конца. Это помогает обеспечить визуализацию, которая ликвидирует пробелы информации, показывая последовательность деловых операций, необходимых для перехода от начала бизнес-процесса к его завершению.
Вот несколько преимуществ, которые бизнес может получить при использовании BPMN:
Примеры моделирования процессов
Бизнес-ориентированные
Многие специалисты и организации хотят моделировать на высоком уровне процесс, ориентированный на людей. В этом случае использование нескольких символов требует меньше глубоких знаний о BPMN, поэтому запись проста. И наоборот, эти модели могут быть скорректированы, чтобы быть чрезвычайно подробными для ИТ и других технических участников.
Вот лишь несколько примеров процессов, которые могут визуально отображены посредством этих блок-схем:
Технически-ориентированные
Как упоминалось ранее, вы можете детализировать диаграммы по мере необходимости, например, для изображения ИТ-ориентированных процессов, кодирования и многих других:
В более развернутых версиях можно моделировать сложные бизнес-события, такие как сообщения, таймеры, бизнес-правила и условия сообщений об ошибках. Давайте рассмотрим больше этих развернутых версий BPMN.
Элементы и символы BPMN 2.0
Нотация BPMN имеет пять основных категорий элементов, которые включают много разных форм и символов. Вот их краткий обзор:
Объекты потока
Они показывают поведение в бизнес-процессе и включают в себя:
Объекты данных
Они содержат информацию о данных в процессе. Данные представлены четырьмя способами:
Соединяющиеся объекты
Они связывают объекты потока друг с другом или другой информацией и показывают поток процесса:
Swimlanes
Этот термин обозначает бассейны и дорожки.
Артефакты
Они дают дополнительную информацию о процессе. Существует два типа артефактов:
Упрощение BPMN с помощью программного обеспечения
Когда необходимо создать блок-схему, вам не нужно изобретать велосипед, особенно если вы только начинаете работать с BPMN.
Использование программы позволит вам быстрее создавать диаграммы и повышать эффективность модели вашего бизнес-процесса. При выборе ПО убедитесь, что оно позволяет вам:
Советы по началу работы
Являетесь ли вы опытным владельцем бизнес-процессов или аналитиком, вы в любом случае сможете упростить свои бизнес-процессы, какими бы простыми или сложными они ни были. Если информация кажется немного ошеломляющей, имейте в виду: вы можете создать простую диаграмму BPMN, а затем основываться на ней в дальнейшей разработке.