для чего нужен bpmn
Что такое 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.
Часть 1. Зачем люди моделируют бизнес-процессы
Моделирование бизнес-процессов обычно рассматривают в контексте их оптимизации с целью повысить эффективность бизнеса в компании в целом. Обычно такая потребность возникает, когда в компании имеются проблемы: например, низкая эффективность ее сотрудников, не оптимальная организационная структура, запутанные коммуникации или неправильное разграничение зон ответственности между ее подразделениями могут ограничивать возможности организации, приводить к снижению ее прибыли, сдерживать ее развитие, делать ее менее конкурентоспособной.
Проблемы, связанные с не оптимальным подходом к построению и управлению бизнес-процессами компании, могут проявляться на всех этапах ее развития. На ранних этапах, когда компания еще только формируется, отсутствие строгого разграничения обязанностей и зон ответственности сотрудников и целых структурных подразделений компании часто приводит к конфликтным ситуациям. Нехватка квалифицированных кадров в различных областях и невозможность достаточно точно спрогнозировать, когда и где понадобится тот или иной специалист, сдерживает развитие компании. Отсутствие культуры передачи знаний вызывает проблемы при увольнении и замене сотрудников, и отрицательно сказывается на работе компании в целом.
Рост размеров компании, увеличение числа ее сотрудников часто приводит к тому, что ее деятельность усложняется, бизнес-процессы становятся запутанными, и управлять ими становится нелегкой задачей.
Как правило, в таких ситуациях принимается решение сформировать новые или кардинально улучшить старые подходы к управлению, сформировав четкую и продуманную систему управления организацией. Осуществить подобную трансформацию практически невозможно без построения бизнес-модели, учитывающей особенности компании и определяющей стратегию ее будущего развития. Бизнес-процесс — один из «кирпичиков» в фундаменте бизнес-модели организации.
Цифровизация, цифровая трансформация компаний, как в государственном, так и в частном секторе, так же невозможна без построения бизнес-модели, как и любая другая трансформация бизнеса. Подобная практика — не просто дань «цифровой» моде, задаваемой высокотехнологичными компаниями; она опирается на мировые стандарты. Наличие документированной бизнес-архитектуры предприятия является требованием международных стандартов ISO 9001:2000 и российских стандартов ГОСТ Р ИСО 9001-2001. Проверенные на практике подходы рекомендуют придерживаться определенного порядка построения бизнес-архитектуры. Без предварительного моделирования изменений в бизнес-процессах и оценки эффектов этих изменений невозможно определить количественные и качественные результаты трансформации, оптимизировать расходы в процессе трансформации.
Построение бизнес-модели затрагивает не только организацию процессов. Современные подходы рассматривают проектирование архитектуры информационных систем не как отдельную задачу, а связывают ее в единое целое с задачами построения бизнес-архитектуры и информационной архитектуры.
Говоря о том, зачем и как моделировать бизнес-процессы, невозможно обойти вопрос о том, что такое бизнес-процессы вообще, и с какой точки зрения их можно рассматривать.
Существует несколько определений бизнес-процессов, каждое из которых отражает определенную точку зрения на бизнес-процесс.
Определение 1. Бизнес-процесс — совокупность взаимосвязанных или взаимодействующих видов деятельности, преобразующих входы в выходы (ISO 9000:2000).
Определение 2. Бизнес-процесс — структурированный набор действий, охватывающий различные сущности предприятия и подчиненный определенной цели (ISO/CD 15531-1).
Определение 3. Бизнес-процесс — совокупность различных видов деятельности, в рамках которой «на входе» используется один или более видов ресурсов, и в результате этой деятельности «на выходе» создается продукт, представляющий ценность для потребителя (М. Хаммер, Д. Чампи, Реинжиниринг бизнес-процессов).
Определение 4. Бизнес-процесс — несколько связанных работ или процедур, в совокупности реализующих конкретную цель текущей деятельности в рамках существующей оргструктуры (Ойхман Е.Г., Попов Э.В, Реинжиниринг бизнеса).
Как мы можем видеть, в определениях 3 и 4 ставится акцент на создании продукта, представляющего ценность для конечного потребителя, или на достижении конкретной цели. Существование цели, которой необходимо достичь, — отличительная черта бизнес процесса. Как правило, сами цели не отражаются в модели процессов; однако, они являются важным элементом бизнес-процессов.
Говоря о том, зачем моделировать бизнес-процессы, невозможно не сказать о том, кто участвует в моделировании бизнес-процессов, и кто является конечным потребителем результатов этого моделирования. В зависимости от целей моделирования, будет определяться состав заинтересованных лиц — руководителей и исполнителей.
Моделирование может охватывать разные аспекты деятельности предприятия, и состав заинтересованных лиц будет определяться направлениями деятельности, выбранными для моделирования.
Как правило, модель бизнес процесса используется достаточно широким кругом лиц на предприятиях, где проводится оптимизация бизнес-процессов и выполняется построение бизнес-архитектуры. Ниже приведен примерный состав пользовательской аудитории моделей бизнес-процессов:
Бизнес-аналитики по различным направлениям деятельности организации;
Разработчики информационных систем;
Системные архитекторы, разрабатывающие архитектуру отдельных информационных систем;
Бизнес-аналитики, выполняющие проектирование организационной структуры предприятия;
Руководители подразделений, заинтересованные в оптимизации бизнес-процессов, выполняемых в этих подразделениях.
Далее мы рассмотрим, как организовано взаимодействие между этими группами в рамках работы над моделью бизнес-процесса.
Что такое нотация BPMN. Основные понятия с примером
О бизнес-процессах, что такое BPM
Разговаривать о процессном подходе, методологии BPM и нотации BPMN невозможно без понятия бизнес-процесса.
Управление процессом – вот что предполагает методология BPM. Существует множество определений, что такое бизнес-процесс, и выбрать какой-то один сложно. Но можно выделить ключевые свойства бизнес-процесса:
Методология BPM позволяет выстроить работу компании с помощью бизнес-процессов. Содержит в себе набор основных принципов и подходов к построению нотации BPMN, что решает поставленную задачу.
Нужно уметь реагировать на изменчивую сущность бизнес-процессов. Прежде всего, это связано с давлением внешней среды (изменение законодательства, стандартов и норм, растущие требования клиентов, недремлющие конкуренты, слияния и поглощения компаний), прогрессом в информационных технологиях, стремлением к совершенствованию внутри компании (сокращение издержек, увеличение продаж за счет повышения качества для потребителя, улучшение финансовых показателей). Поэтому говорить о внедрении как о разовом процессе – сделали и забыли как это позиционирует классический реинжиниринг, не приходится.
В методологии BPM рассматриваются следующие понятия:
В век цифровой трансформации методология BPM как никогда становится востребованной. Те компании, кто способен гибко и во время перестраивать свои бизнес-процессы повышают эффективность своего бизнеса.
Каким компаниям подходит использование BPM
Не все компании готовы к BPM. Трудно представить необходимость внедрение такой технологии для компании в 5 человек, так как все процессы понятны сотрудникам, а главное легко поддаются управлению. Поэтому на разных этапах зрелости компании должны применяться разные технологии:
Получите консультацию эксперта для вашей компании
Нотация BPMN
BPMN – система условных обозначений (нотация) и их описания для моделирования бизнес-процессов. Для исполнения смоделированных бизнес-процессов с помощью BPMN существует инструмент BPMS. Ярким представителем является BizAgi.
Сегодня использования BPMN как одного из методов для описания бизнес-процессов очень распространено. Нотация BPMN понятна как представителям бизнеса, так и программам, работающим с бизнес-моделями, это стандартный язык, позволяющий связать управление бизнесом и создание исполняемых алгоритмов.
BPMN это не единственная нотация, которая сейчас используется, и некоторые из нотаций заметно упрощают понимание, чем BPMN. Но на моменте автоматизации, когда задача стоит не просто нарисовать удобную схему бизнес-модели, а еще и возможность экспортировать ее в исполняемые алгоритмы программных продуктов без BPMN сложно обойтись.
Но важно понимать следующее, BPMN – это не язык, который описывает IT системы. Предназначение BPMN нотации в другом – это возможность понятным языком описать для бизнес-заказчика предметную область.
В BPMN наравне задействованы и программные системы, и люди (клиенты, поставщики, сотрудники организации). Это основное отличие нотации BPMN от графических инструментов для описания программ.
К преимуществам BPMN следует также отнести открытый стандарт Object Management Group (omg.ru) и признания ее всеми ведущими поставщиками ПО.
К недостаткам нотации BPMN можно отнести коллективное авторство в рамках «не привязки» к методологии, не хватает стройности, что ведет к сложности освоения и реализации в BPMS. Решается данный недостаток соглашением о моделировании – своде правил, чем пользуемся в организации, в рамках проекта.
В нотации BPMN можно выделить базовые значки, которые используются во всех бизнес-моделях. Именно их я рассмотрю дальше. Этого будет достаточно, чтобы познакомиться с нотацией BPMN и понять основные принципы для работы с ней. Палитру значков при необходимости можно расширить, прочитав более подробно об этом в документации BPMN.
При описании бизнес-процесса в нотации BPMN необходимо получить ответы на следующие вопросы: что сделать; кто должен сделать; последовательность действий; по какой информации, объекту данных.
Ниже описаны базовые объекты для описания бизнес-процессов, которые используются нотацией BPMN.
— Event
Событие, которое произошло в описании процесса. События делятся на начальные, промежуточные или конечные.
Старт необязателен при описании бизнес-процесса, не запрещено также использовать несколько стартов. Завершение также необязательно, т.к процесс может, например, заканчиваться ошибкой. Также как стартов, завершений может быть больше одного. Хорошим стилем считается использование одного старта, несколько завершений.
— Task
Это задачи, выполняющиеся в бизнес-процессе на определенном этапе. Со стороны модели – это шаг процесса. Глазами пользователя – это выглядит как задание в рамках определенного бизнес-процесса. Для текстового описания задачи используется глагол, а не существительное. Например, «Заполнить заявку», а не «Заполнение заявки». Задачи могут быть не делимыми на более элементарные действия или требующие подробной детализации последовательности более простых действий. Если задачу можно детализировать, но на общей схеме это не требуется, ее можно оформить как подпроцесс.
— Gateway
Развилки появляются в случае условного ветвления бизнес-процесса. Например, если заявка на расход проходит согласование, то она включается в реестр платежей на день, если отклоняется, то она корректируется Инициатором или отклоняется совсем и т. д. Развилки могут быть «или/или» – идем только по одному из исходящих потоков; могут быть параллельными, тогда движение продолжается по ВСЕМ потокам, в случае параллельной развилки используют сходящуюся развилку, то есть ожидание выполнения последнего входящего потока.
— Flow
Поток обозначается стрелками, показывает последовательность выполнения действий.
— Date
Объекты данных – показывает либо результат выполненного действия, либо какие данные, объекты требуются для запуска действия.
— Pool
Пул описывает один бизнес-процесс на диаграмме. Пул есть всегда, но в явном виде может не изображаться. Допускается несколько пулов на одной диаграмме. Пул бывает белый – изображает поток работ, которым можно управлять и черный – внешняя сущность, например, Заказчик.
Для пула характерно выделение дорожек для определения лиц, кто участвует в бизнес-процессе. Семантика произвольная — подразделение, роль, группа, пользователь.
Пример применения BPMN
Для примера возьмем бизнес-процесс обеспечения заявки на потребность. Финишем (результатом) будет считаться получение сотрудником заказанных товаров.
Бизнес-процесс в компании выстроен так:
После получения товаров от поставщика, Кладовщик приходует и выдает Сотруднику со склада заказанные наименования.
Не все процессы нужно детализировать при описании с помощью нотации BPMN. Что-то можно опустить. Например, я не рассматриваю в примере описание процесса оплаты товары, согласование цены и количества в заказе поставщика. Первоначально, нужно показать процесс «крупными мазками», не углубляясь и не закапываясь в детализирование. Если есть потребность любой подпроцесс можно показать детальнее.
Нотация BPMN при моделировании бизнес-процессов позволяет самому Аналитику регулировать глубину детализации в описание бизнес-процесса, что-то выносить за пределы описания.
Начало процесса, точкой входа является получение заявки на потребность от Сотрудника на портале. Точка выхода – получение заказанных товаров Сотрудником. В схеме я использовала как развилки, так и подпроцессы. Например, использование подпроцесса «Зарезервировать товар» после развилки «Есть на складе» позволяет, отдельно детализировать последовательность действий, которые выполняет менеджер в этом процессе.
Какие преимущества дает такое описание бизнес-процесса? Можно наглядно продемонстрировать бизнес-клиентам функциональную связь между подразделениями в части максимального покрытия внутренних потребностей компании. На схеме видны бизнес-процесс, последовательность выполнения, источники информации, показывается доступом к каким процессам или документам должен обладать пользователь.
Лично мне описание бизнес-процессов в BPMN позволяет лучше структурировать описание и понять узкие места в процессах клиента. В заключение хочется сказать, что ключ к успеху овладения нотацией BPMN – это конечно же практика, но те преимущества, которые дает описание BPMN, безусловно, стоят этого времени.
Краткое описание BPMN с примером
О том, что такое BPMN, написано очень много. Но проблема в том, что почти вся информация, которую можно найти в Интернет, ориентирована на людей, которые уже ранее сталкивались с BPMN или с другим стандартом моделирования бизнес-процессов. Я же предлагаю разобраться «с нуля» — что такое BPMN? В чем особенности и преимущества этой технологии и почему она появилась и оказалась столь востребованной, по крайней мере, за рубежом. Да и у нас в стране ей все больше и больше интересуются.
Также я хочу сразу обратить ваше внимание на то, что здесь я буду говорить именно о нотации BPMN, т.е. о языке моделирования бизнес-процессов. Я, конечно, постараюсь максимально просто описать основы BPMN так, чтобы они были понятны даже новичкам. Но также важно понимать, что здесь я буду говорить именно о языке, а не о методологии.
Методология моделирования бизнес-процессов — это понятие очень обширное, по сути, это та самая база, знания которой нужны для практического применения языков моделирования бизнес-процессов. О ней я буду говорить в будущих статьях и не раз. Почему я делаю на этом акцент? Многие люди (и я в свое время также) считают, что достаточно выучить язык бизнес-моделирования, и вы сумеете выстраивать бизнес-процессы. 
Практика показывает, что без базовых знаний здесь не обойтись. И всем, кто только планирует изучение моделирования, я настоятельно советую сначала ознакомиться с методологией, понять общие принципы бизнес-моделирования, получить определенные навыки бизнес-анализа. И только потом приступать к изучению BPMN или любого другого языка.
А для понимания причин появления BPMN и всех нюансов моделирования при помощи этой системы нотаций, понадобится также знание основных проблем, которые решает BPMN, что для работы использовали до появления BPMN, и с какими сложностями сталкивались. Ведь появление новых систем и нотаций невозможно без понимания определенной проблематики. И я считаю, что этот аспект очень важен для понимания сути вопроса, что же такое на самом деле BPMN.
Лично я познакомился впервые с BPMN около восьми лет назад, когда начал изучать систему Bizagi Modeler. Заинтересовался я этой системой по причине того, что давно уже понимал всю важность моделирования. До этого я лично пользовался IDEF0 и IDEF3, но там я сталкивался с определенными ограничениями. Дело в том, что IDEF0 несколько ограничен по числу возможностей. А IDEF3 мне лично показался излишне строгим и «сухим», в нем было сложно моделировать многие виды бизнес-процессов с участием программных продуктов.
В то время Bizagi был относительно простым модулем, в котором присутствовал удобный редактор для моделирования (рисования) бизнес процессов, но еще не было никаких инструментов для исполнения бизнес-процессов. Но даже тогда строгие правила BPMN, принятые в системе Bizagi, помогали избегать значительного числа ошибок, столь частых при обычном «рисовании» бизнес-процессов в графических редакторах или на бумаге.
В поисках оптимального решения для себя я изучал ARIS, инструменты 1С для бизнес-моделирования, различные системы моделирования бизнес-процессов, которые были придуманы различными бизнес-консультантами, как российскими, так и зарубежными. И, конечно же, познакомился с нотацией BPMN.
При первом знакомстве BPMN мне во многом понравился, идея была очень хорошей, а вот исполнение на тот момент с моей точки зрения еще было «сырым». И полноценно пользоваться BPMN я начал около 3 лет назад, после того, как задачи, которые я стал решать, усложнились настолько, что IDEF0 применять полноценно никак не получалось. И оказалось, что нотация развивалась, и теперь я активно пользуюсь BPMN в своей работе.
BPM: ОСНОВНЫЕ ПОНЯТИЯ
Для того чтобы разобраться, что такое BPMN, нужно понимать, что часть этой аббревиатуры «BPM» имеет две расшифровки — Business Process Modeling и Business Process Management. В первом случае – это непосредственно моделирование бизнес процесса, а во втором – управление бизнес-процессами, т.е. общая система, частью которой и является Business Process Modeling.
При этом моделирование бизнес-процессов – является основой и основной целью. При помощи моделирования мы можем описать любой бизнес процесс, а исполняться они могут в самых разных системах управления.
Есть и еще одно понятие, о котором стоит сразу упомянуть – это «BPMS», т.е. Business Process Modeling System. Этот термин описывает те самые системы управления, в которых производится моделирование, а также исполнение бизнес-процессов.
Можно сказать, что BPMN является частью двух важнейших составляющих:
ЯЗЫК ОПИСАНИЯ БИЗНЕС-ПРОЦЕССОВ
Когда впервые сталкиваешься с моделированием бизнес-процессов, очень тяжело понять, с чего же тут начать, где искать основу для понимания того, как строятся бизнес-модели. И я также с этим в свое время столкнулся.
А основой здесь является наличие языка описания бизнес-процессов. И важно понимать, что это действительно язык, как и языки программирования или даже языки, на которых говорят люди, он также прост на базовом уровне и сложен, если начинать изучать нюансы. У этого языка есть свои правила, семантика, орфография, свои законы, которые нужно изучить и строго им следовать. С другой стороны, как и любой искусственный язык, предназначенный не для живого общения, а для строгого и однозначного описания каких-то действий и процессов, он в своей основе проще “живых” языков, а его правила — строго логичны.
Кроме того, в силу ограниченности задач, которые стоят перед этим языком, он гораздо более определен в терминологии. Но все же и здесь имеется очень много нюансов, каких-то сочетаний «слов», которые несут собственную смысловую нагрузку. И очень важно строго следовать правилам сочетания разных элементов языка и знать ограничения (что с чем сочетать недопустимо, как начинать описание, чем заканчивать и пр.).
И как любой технологический язык, описание бизнес-процессов имеет собственные специфические конструкции, понять которые без определенного уровня технологических знаний будет крайне затруднительно. А потому для изучения языка описания бизнес-процессов также важно, в первую очередь, понимать сами технологии, для описания которых он предназначен.
Например, для моделирования бизнес-процессов вам понадобится знание таких понятий, как «условия», «цикл», «декомпозиция» и т.д.
Важно понимать: BPMN не является языком описания IT-систем. Эта нотация предназначена для описания предметной области реального бизнеса. И здесь могут быть задействованы как программные системы, так и люди (сотрудники компании, заказчики, поставщики). Это самое главное отличие этой нотации от графических инструментов для описания программ.
НЕМНОГО ИСТОРИИ BPMN
Для большего понимания особенностей моделирования бизнес-процессов и структуры языка моделирования, я хочу немного рассказать об истории появления нотации BPMN. Разработка системы моделирования бизнес-процессов и спецификаций для нее (языка моделирования) ведется относительно давно.
Первая версия BPMN 1.0 была выпущена в мае 2004 года компанией Business Process Management Initiative. Эта версия обладала ограниченными возможностями и была, так сказать, «пробным вариантом», который нуждался в многочисленных доработках.
Следующая версия BPMN 1.1 выходит в январе 2008, и здесь разработкой и поддержкой занималась уже Object Management Group, организация, появившаяся в результате слияния BPMI с другой компанией-разработчиком программного обеспечения.
Еще один релиз появляется всего через год, версия BPMN 1.2 выходит в свет в январе 2009. Разработчик OMG остается прежним. Команда, которая занимается продуктом, после слияния практически не меняется.
В январе 2011 года компания OMG выпускает версию BPMN 2.0, а в декабре 2013 выходит последний на данный момент релиз – BPMN 2.0.2. Именно эта версия предлагается всем пользователям и сегодня, так как система получилась стабильной, возможности моделирования в ней очень широкие, а язык моделирования (набор обозначений) по большей части понятен всем бизнес-пользователям – как бизнесменам, бизнес-консультантам, так и техническим специалистам.
Из истории можно сделать вывод что период изменений в этом языке миновал, и можно спокойно изучать и использовать его на практике.
Сегодня BPMN – это один из наиболее распространенных методов описания бизнес-процессов, которые сегодня уже «понимают» как бизнес-пользователи, так и программные продукты, предназначенные для работы с бизнес-моделями. Т.е. этот язык описания является стандартным также и для создания исполняемых алгоритмов в сфере управления бизнесом.
Я особенно хочу подчеркнуть этот момент, так как и сам столкнулся поначалу с непониманием, зачем те или иные вещи усложнять? Ведь для описания бизнес-процессов, например, при GAP-анализе (анализ разрывов) или для представления заказчику бизнес-модели в какой-то упрощенной форме, всего многообразия элементов BPMN вам не нужно. Но когда начинается автоматизация, когда бизнес-модель становится не просто удобной схемой, а может экспортироваться в другие программные продукты в качестве исполняемых данных, все становится на свои места. Последняя версия BPMN действительно стабильна и все требования к языку обоснованы.
ИЗ ЧЕГО СОСТОИТ НОТАЦИЯ BPMN?
И здесь я хочу сделать небольшое отступление. Дело в том, что перевод терминов и понятий с английского языка на русский – занятие сложное. Найти наиболее точное слово обычно может специалист, но переводом занимается совсем другой человек, часто вообще не имеющий понятия о сути тех понятий, которые он переводит. В результате появляется множество неточностей, понятия усложняются, возникает путаница. Об особенностях перевода и сложностях применения терминов в сравнении с графикой я уже писал, например, в статье Знакомство с нотацией IDEF0 и пример использования (см. раздел “Несколько слов о преимуществах графики”).
Я в этой статье буду оперировать теми понятиями и терминами, которые использую сам на практике. И они не всегда будут совпадать с теми словами, которые вы встречали в Википедии или каких-то переведенных руководствах. Причина заключается именно в том, что я, как специалист, в некоторых случаях нашел для себя более точный перевод английского термина. И применение слова, которое выбрал для себя я, помогает понять суть процесса намного быстрее.
Конечно, я буду пояснять всю терминологию по мере необходимости. А потому думаю, что проблем с пониманием и терминами не возникнет. Но все же обратить внимание на этот момент, я считаю правильным.
Язык описания бизнес-процессов опирается на следующие базовые объекты:
Я же остановлюсь только на базовых элементах, без которых не обходится ни одна бизнес-модель. Для первого знакомства с BPMN и понимания основных принципов работы нотаций этого достаточно.
EVENT (СОБЫТИЕ)
Event – это то событие, которое произошло в описании процесса или хореографии (о ней я расскажу отдельно). Эти события могут быть начальными, конечными или промежуточными.
Например, опишем процесс получения заказа от клиента по телефону:
ACTIVITY (ДЕЙСТВИЯ)
Activity – это те действия (задачи), которые должны быть выполнены на определенном этапе бизнес-процесса. Их при моделировании обычно обозначают в виде прямоугольников, в которые вписывают суть действия.
Действия могут быть элементарными, т.е. неделимыми на какие-то более простые действия, так и не элементарными, т.е. такими, которые при детализации делятся на последовательность определенных более простых действий.
Обычно действия делят следующим образом:
GATEWAY (ШЛЮЗ, РАЗВИЛКА)
Gateway – это контрольный узел, который появляется в случае условного ветвления бизнес-процесса. Графически изображается в виде ромба.
Также шлюзы необходимы в случаях, когда порядок действий зависит от тех или иных факторов. Например, при работе с заказчиками шлюз появляется на этапе принятия клиентом решения о покупке – «да или нет». При положительном решении необходимо оформить покупку, при отрицательном – выяснить возможные причины отказа, провести работу с «отказом» и т.д.
FLOW (ПОТОК) И MESSAGE FLOWS (ПОТОК СООБЩЕНИЙ)
Поток Flow – это последовательность действий, обозначается как стрелка, и показывает, какое действие после какого необходимо совершить.
Message Flows – это пунктирные стрелки в бизнес-модели, которые показывают сообщения, которыми обмениваются участники бизнес-процесса. Например, если заказ переходит от клиента в обработку в отдел продаж, он сопровождается сообщением, которое содержит информацию об этом заказе. Также Message Flows могут связывать два отдельных пула в диаграмме.
Message Flows Association – еще один вид линий, в отличие от сообщений, которые являются пунктирными линиями, этот вариант отображается в виде последовательности не отрезков, а точек. Необходима для того, чтобы показывать артефакты (о них – ниже).
POOL (ПУЛ)
Пул – это объект описывающий какой-то один процесс на диаграмме. Он может быть не изображен на диаграмме, но он всегда есть. На одной диаграмме может быть несколько Пулов. Пул можно развернуть для просмотра деталей.
Пул может также содержать, так называемые, «дорожки». Они нужны для того, чтобы указать участников процессов, которые скрыты в пуле. Например, в процессе работы с клиентами участвует менеджер по продажам, руководитель отдела продаж, возможно, бухгалтер или кассир.
DATE OBJECT (ДАННЫЕ, ОБЪЕКТЫ ДАННЫХ)
Объекты данных – это элемент, который показывает, какие данные и документы нужны для того, чтобы какое-то действие запустилось, либо которые являются результатом выполненного действия. Объектом данных может быть сформированный заказ. Для менеджера это будет результат действий, а для склада, который получает заказ – началом действия (сбор товаров и отгрузка).
MESSAGE (СООБЩЕНИЕ)
Этот элемент необходим, чтобы показать коммуникацию между двумя участниками процесса. Это может быть Email, сообщения внутри системы совместной работы, переписка в каком-либо из мессенджеров, которыми пользуются участники процесса, коммуникации на сайте компании, sms-сообщения и т.д.
ARTEFACT (АРТЕФАКТЫ)
Под артефактами в BPMN понимают объекты, не являющиеся действиями и не связанные с действиями напрямую. Это могут быть любые документы, данные, информация, которая не влияет напрямую на исполнение процесса.
Выделяют два вида артефактов:
Text Annotation (текстовые аннотации) применяют для различных уточнений к диаграмме. Это могут быть комментарии, пояснения, другая информация, которая повысит читабельность диаграммы. Аннотации – это незакрытый прямоугольник, выполненный сплошной линией, от которого к объекту аннотации ведет линия, состоящая из точек.
ИСПОЛНЯЕМЫЕ И НЕИСПОЛНЯЕМЫЕ БИЗНЕС-ПРОЦЕССЫ
В бизнес-моделировании процессы можно условно разделить на два вида — исполняемые, которые действительно будут работать при помощи специального обеспечения, например, Bizagi, и неисполняемые, т.е.бизнес-модели, необходимые только для изучения и демонстрации вариантов работы предприятия.
В принципе, между их построением нет особой разницы, здесь важен исключительно желаемый результат. Либо бизнес-модель будет применяться только для облегчения взаимопонимания между заказчиком (руководителем) и консультантом (исполнителем). Либо эта нотация будет впоследствии использоваться в какой-либо программной среде для организации работы компании. В обычных руководствах вы этого разделения на две части не найдете. Но я лично считаю, что имеет смысл условно так делить бизнес-процессы, так как при различном желаемом результате потребуется различная глубина проработки деталей и выбор возможных инструментов для работы.
Исполняемые бизнес-процессы обязательно должны быть выстроены в строгом соответствие всем правилам нотации BPMN, так как в противном случае программное обеспечение не сможет работать корректно с составленной бизнес-моделью. Исполняемые процессы нужны, например, на предприятиях, где принят процессный подход к деятельности. Программное обеспечение позволяет вести контроль всех процессов в режиме реального времени, и на основе получаемых на каждом из этапов данных, руководитель компании и подразделений всегда смогут понимать, на каком этапе находится работа по тому или иному процессу. Подобный метод позволяет значительно повысить эффективность управления.
Неисполняемые бизнес-процессы нужны исключительно для демонстрации какой-либо бизнес-модели. Это может быть диаграмма, отображающая реальное положение дел на предприятии, может быть наглядной иллюстрацией к предложенным изменениям при реинжиниринге. В этом случае, конечно, можно использовать любые удобные инструменты, в том числе, традиционный для многих IDEF0. А соблюдение правил языка моделирование необходимо исключительно для достижения взаимопонимания.
Я рекомендую на начальном этапе работы с BPMN создавать неисполняемые бизнес-процессы. Это действительно очень удобная нотация для того, чтобы иллюстрировать свои идеи и предложения, демонстрировать «узкие места» в бизнесе, даже просто для себя разбираться в структуре работы той или иной компании очень удобно с использованием нотаций. Наглядная графика и строгие правила в этом очень помогают.
Исполняемый вариант требует глубоких знаний BPMN, а также внимательного отношения к каждой детали, так как вы, по сути, создаете программу (алгоритм) для компьютера, просто используете для этого не текстовый язык, а графические нотации. Это дело – для опытных специалистов.
ПОДХОДИТ ЛИ BPMN ДЛЯ МАЛОГО И СРЕДНЕГО БИЗНЕСА?
Нотации BPMN можно и даже нужно использовать при работе с малым и средним бизнесом. Возможно, что вы не будете реализовать бизнес-модель на уровне программного обеспечения, так как это всегда — дополнительные затраты, и в условиях малого бизнеса нет необходимости в подобных инструментах контроля и анализа работы.
Но, тем не менее, на уровне неисполняемых бизнес-процессов я очень активно используют именно BPMN. Дело в том, что при всей сложности вхождения (т.е изучения и умения работать с нотациями), уровень понимания BPMN — низкий, т.е. для чтения нотаций не требуется вообще никаких особых знаний и навыков. Графические нотации понимаются интуитивно. И я еще не встретил ни одного человека, для которого бы прочесть нотацию было бы сложно. Эта нотация создавалась специально для того, чтобы найти общий язык между аналитиком и обычными бизнесменами (управленцами).
В результате, как я и писал выше, при помощи BPMN вы экономите свое время и время заказчика (руководителя) и добиваетесь максимально высокого уровня взаимопонимания. Нотации не позволяют “двойного прочтения”, а потому очень помогают в работе.
МИНУСЫ И ВАЖНЫЕ ОСОБЕННОСТИ BPMN
О том, насколько удобна BPMN, я сказал уже много. Но для выбора любого инструмента важно также понимать и возможные минусы. О них я сейчас и расскажу:
ПРИМЕР ПРАКТИЧЕСКОГО ПРИМЕНЕНИЯ BPMN
Конечно же, без примера описание моделирования бизнес-процессов было бы неполным и не до конца понятным. Я решил в качестве примера взять процесс обеспечения заказов покупателей, так как этот этап работы присутствует практически в любом направлении бизнеса, а потому реализация этого процесса на практике будет понятна без дополнительных пояснений широкому кругу читателей.
Результатом этого процесса должно быть обеспечение покупателя необходимыми ему наименованиями товара.
Данный бизнес-процесс выполняется следующим образом:
BPMN позволяет при моделировании бизнес-процессов опускать на определенном уровне те или иные реальные процессы. Так, в нашем случае мы оставляем «за скобками» получение заказа и согласование перечня товаров и их стоимости с клиентом. Это можно будет детализировать в случае необходимости отдельно. Также в этом примере мы оставили «за скобками» процессы оплаты товары, отгрузки, оформления расходных документов и т.д. А сейчас у нас другая задача – описать сам процесс обеспечения покупателя необходимыми товарами.
Точкой входа служит получение заказа от покупателя. Точкой выхода – «резервирование товара».
Обратите внимание, что после получения заказа стрелка ведет к этапу-ромбу, т.е. условию:
При необходимости этот бизнес-процесс может быть детализирован, что также помогает увидеть, что и как работает (должно работать) для получения результата.
КАК РАЗРАБАТЫВАТЬ ДИАГРАММЫ BPMN НА ПРАКТИКЕ?
Здесь я хочу поделиться некоторыми советами о том, с чего начать и как производить разработку моделей бизнес-процессов. Мои советы основаны на знаниях особенностей бизнес-моделирования и личном практическом опыте.
Что еще хотелось бы посоветовать:
Еще статьи по данной теме:
Также в настоящее время я готовлю к публикации книгу и онлайн курс, в которой подробно опишу собственное видение процессного подхода к бизнесу, а также мой собственный практический опыт работы в сфере функционального и процессного моделирования. Все желающие могут подписаться на уведомление о выходе новой книги по и другие новости ссылке.