Для чего используется 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, а затем основываться на ней в дальнейшей разработке.
Сведения об авторе
BPMN простым языком
Данный цикл статей предназначен для всех, кто собирается приступить к созданию моделей с использованием BPMN.
Часть 1. Зачем люди моделируют бизнес-процессы
Моделирование бизнес-процессов обычно рассматривают в контексте их оптимизации с целью повысить эффективность бизнеса в компании в целом. Обычно такая потребность возникает, когда в компании имеются проблемы: например, низкая эффективность ее сотрудников, не оптимальная организационная структура, запутанные коммуникации или неправильное разграничение зон ответственности между ее подразделениями могут ограничивать возможности организации, приводить к снижению ее прибыли, сдерживать ее развитие, делать ее менее конкурентоспособной.
Проблемы, связанные с не оптимальным подходом к построению и управлению бизнес-процессами компании, могут проявляться на всех этапах ее развития. На ранних этапах, когда компания еще только формируется, отсутствие строгого разграничения обязанностей и зон ответственности сотрудников и целых структурных подразделений компании часто приводит к конфликтным ситуациям. Нехватка квалифицированных кадров в различных областях и невозможность достаточно точно спрогнозировать, когда и где понадобится тот или иной специалист, сдерживает развитие компании. Отсутствие культуры передачи знаний вызывает проблемы при увольнении и замене сотрудников, и отрицательно сказывается на работе компании в целом.
Рост размеров компании, увеличение числа ее сотрудников часто приводит к тому, что ее деятельность усложняется, бизнес-процессы становятся запутанными, и управлять ими становится нелегкой задачей.
Как правило, в таких ситуациях принимается решение сформировать новые или кардинально улучшить старые подходы к управлению, сформировав четкую и продуманную систему управления организацией. Осуществить подобную трансформацию практически невозможно без построения бизнес-модели, учитывающей особенности компании и определяющей стратегию ее будущего развития. Бизнес-процесс — один из «кирпичиков» в фундаменте бизнес-модели организации.
Цифровизация, цифровая трансформация компаний, как в государственном, так и в частном секторе, так же невозможна без построения бизнес-модели, как и любая другая трансформация бизнеса. Подобная практика — не просто дань «цифровой» моде, задаваемой высокотехнологичными компаниями; она опирается на мировые стандарты. Наличие документированной бизнес-архитектуры предприятия является требованием международных стандартов ISO 9001:2000 и российских стандартов ГОСТ Р ИСО 9001-2001. Проверенные на практике подходы рекомендуют придерживаться определенного порядка построения бизнес-архитектуры. Без предварительного моделирования изменений в бизнес-процессах и оценки эффектов этих изменений невозможно определить количественные и качественные результаты трансформации, оптимизировать расходы в процессе трансформации.
Построение бизнес-модели затрагивает не только организацию процессов. Современные подходы рассматривают проектирование архитектуры информационных систем не как отдельную задачу, а связывают ее в единое целое с задачами построения бизнес-архитектуры и информационной архитектуры.
Говоря о том, зачем и как моделировать бизнес-процессы, невозможно обойти вопрос о том, что такое бизнес-процессы вообще, и с какой точки зрения их можно рассматривать.
Существует несколько определений бизнес-процессов, каждое из которых отражает определенную точку зрения на бизнес-процесс.
Определение 1. Бизнес-процесс — совокупность взаимосвязанных или взаимодействующих видов деятельности, преобразующих входы в выходы (ISO 9000:2000).
Определение 2. Бизнес-процесс — структурированный набор действий, охватывающий различные сущности предприятия и подчиненный определенной цели (ISO/CD 15531-1).
Определение 3. Бизнес-процесс — совокупность различных видов деятельности, в рамках которой «на входе» используется один или более видов ресурсов, и в результате этой деятельности «на выходе» создается продукт, представляющий ценность для потребителя (М. Хаммер, Д. Чампи, Реинжиниринг бизнес-процессов).
Определение 4. Бизнес-процесс — несколько связанных работ или процедур, в совокупности реализующих конкретную цель текущей деятельности в рамках существующей оргструктуры (Ойхман Е.Г., Попов Э.В, Реинжиниринг бизнеса).
Как мы можем видеть, в определениях 3 и 4 ставится акцент на создании продукта, представляющего ценность для конечного потребителя, или на достижении конкретной цели. Существование цели, которой необходимо достичь, — отличительная черта бизнес процесса. Как правило, сами цели не отражаются в модели процессов; однако, они являются важным элементом бизнес-процессов.
Говоря о том, зачем моделировать бизнес-процессы, невозможно не сказать о том, кто участвует в моделировании бизнес-процессов, и кто является конечным потребителем результатов этого моделирования. В зависимости от целей моделирования, будет определяться состав заинтересованных лиц — руководителей и исполнителей.
Моделирование может охватывать разные аспекты деятельности предприятия, и состав заинтересованных лиц будет определяться направлениями деятельности, выбранными для моделирования.
Как правило, модель бизнес процесса используется достаточно широким кругом лиц на предприятиях, где проводится оптимизация бизнес-процессов и выполняется построение бизнес-архитектуры. Ниже приведен примерный состав пользовательской аудитории моделей бизнес-процессов:
Бизнес-аналитики по различным направлениям деятельности организации;
Разработчики информационных систем;
Системные архитекторы, разрабатывающие архитектуру отдельных информационных систем;
Бизнес-аналитики, выполняющие проектирование организационной структуры предприятия;
Руководители подразделений, заинтересованные в оптимизации бизнес-процессов, выполняемых в этих подразделениях.
Далее мы рассмотрим, как организовано взаимодействие между этими группами в рамках работы над моделью бизнес-процесса.
Описание нотации BPMN
Нотация BPMN наиболее удобна для декомпозиции, для описания нижних уровней бизнес-процессов, особенно там, где требуется показывать действия участников процессов. Это объясняется самой сутью, методологией, лежащей в основе нотации – это методология workflow – поток работ.
То есть BPMN – это не просто структура процесса, функции, это алгоритм! Это уже не просто некое «до-аналитическое» предположение, что процесс состоит из «вот таких» блоков/функций, это уже четкая последовательность выполняемых действий ее конкретными участниками.
Система обозначений нотации BPMN
BPMN использует в качестве обозначений такие графические элементы, как:
Процесс / задача
Процесс, задача – это определенное действие или набор действий, совершаемых для получения какого-то результата. Блок процесса или задачи представляет собой прямоугольник. Внутри блока указывается наименование процесса или задачи.
Подпроцесс – это процесс который описан более подробно, то есть декомпозирован, на отдельной своей диаграмме (модели).
В системе обозначений нотации BPMN есть еще разновидности процессов, такие как «цикл», «компенсация» и т.д. Мы не будем на них останавливаться, так как при более глубоком знакомстве с нотацией BPMN изучение этих блоков не представляет сложности, они интуитивно понятны.
Выделим, пожалуй, наиболее интересный блок – это блок ad-hoc процессов, потому что четкая, безальтернативная регламентация деятельности – это вопрос выбора модели компании, бизнеса. Смотря на шаг вперед, мы понимаем, что выбор будущего – это «бирюзовая модель» по классификации, введенной Фредериком Лалу, предполагающая если не отсутствие регламентов как таковых, то иной принцип их выработки и исполнения.
Ad-Hoc процесс – такой подпроцесс, действия которого не поддаются четко регламентированным правилам или алгоритмам, эти правила определяются исполнителем. Возможны варианты, когда есть заранее определенный набор действий для каких-либо случаев, но их последовательность, реальное исполнение – это выбор исполнителя.
События
Событие – это состояние, которое влияет или контролирует дальнейшее выполнение бизнес-процесса. Блок события в BPMN обозначается кругом. Внутри блока указывается наименование события.
Относительно точки выполнения процесса события делятся на:
Любое событие может возникать из-за какой-то причины, а может инициировать само какой-то результат. Первые события называются – «обработчики», вторые – «инициаторами». Причина возникновения событий-обработчиков и результат процессов-инициаторов называется триггер.
События-инициаторы – это некоторые промежуточные события (включая промежуточное событие с типом «Неопределенное») и все конечные события. Если встречается событие-инициатор, то процесс просто выполняется дальше и ничего не ожидает. На диаграмме триггер внутри события, являющегося инициатором, показывается закрашенным.
Пример различных типов событий:
Шлюзы
Параллельный шлюз (AND, «И») используется для обозначения слияния/ветвления потоков управления в рамках процесса.
Пример использования параллельного шлюза при ветвлении/разделении потоков:
В примере выше параллельный шлюз используется для ветвления потоков управления или создания параллельных веток выполнения процесса: после выполнения Процесса 1 запустится выполнение и Процесса 2, и Процесса 3.
Пример использования параллельного шлюза при слиянии потоков:
В примере выше параллельный шлюз используется для слияния потоков управления или синхронизации параллельных веток выполнения процесса. Выполнение Процесса 3 запустится только тогда, когда выполнится и Процесс 1, и Процесс 2.
Эксклюзивный шлюз
Эксклюзивный шлюз (XOR, «Исключающее ИЛИ») используется для ветвления потока управления на несколько альтернативных потоков, когда выполнение процесса зависит от выполнения некоторого условия.
Условия на диаграмме задаются при помощи условных потоков управления, исходящих из шлюза. При использовании эксклюзивного шлюза можно продолжить выполнение процесса только по одному из возможных условных потоков управления. Среди потоков управления, исходящих из эксклюзивного шлюза, допускается использование потока управления по умолчанию: если ни одно из условий не выполняется, дальнейшее выполнение процесса продолжится по потоку управления по умолчанию.
после выполнения Процесса 1 (рисунок выше) дальнейшее выполнение процесса может продолжиться только по одному потоку, исходящему из шлюза:
— если Условие 1 верно, то выполнится только Процесс 3;
— если Условие 2 верно, то выполнится только Процесс 4;
— если ни Условие 1, ни Условия 2 не верны, то выполнится только Процесс 2.
Эксклюзивный шлюз может использоваться и для слияния потоков управления. В данном случае шлюз просто пропускает через себя все потоки управления без синхронизации.
На рисунке выше Процесс 3 будет выполнен дважды: после выполнения Процесса 1 и после выполнения Процесса 2.
Неэксклюзивный шлюз
Неэксклюзивный шлюз (OR, «ИЛИ») используется для ветвления потока управления на несколько потоков, когда выполнение процесса зависит от выполнения условий. При этом каждое из указанных условий является независимым, и дальнейшее выполнение процесса может продолжиться сразу по нескольким потокам управления, если условия будут выполнены.
Условия на диаграмме задаются при помощи условных потоков управления, исходящих из шлюза. Среди потоков управления, исходящих из неэксклюзивного шлюза, допускается использование потока управления по умолчанию: если ни одно из условий не выполняется, дальнейшее выполнение процесса продолжится по потоку управления по умолчанию.
Неэксклюзивный шлюз может использоваться для ветвления и для слияния потоков управления.
На рисунке выше Процесс 3 будет выполнен только тогда, когда выполнится и Процесс 1, и Процесс 2 (пример слияния, или синхронизации).
Еще шлюзы
В BPMN различают также еще два типа шлюзов:
Комплексный шлюз используется для ветвления потока управления на несколько потоков, когда выполнение процесса зависит от выполнения условий. По своему действию комплексный шлюз аналогичен неэксклюзивному шлюзу.
Эксклюзивный шлюз по событиям (XOR, «Исключающее ИЛИ») используется для ветвления потока управления на несколько альтернативных потоков, когда дальнейшее выполнение процесса зависит от возникновения некоторого события-обработчика, следующего после шлюза.
На рисунке выше после выполнения Процесса 1 дальнейшее выполнение процесса может продолжиться только по одной ветке, исходящей из шлюза:
— если первым возникло Событие 1, то выполнится только Процесс 2;
— если первым возникло Событие 2, то выполнится только Процесс 3.
Поток управления
Стандартный поток управления является неконтролируемым, т.е. на поток не воздействуют никакие условия, и поток не проходит через шлюзы.
Другие обозначения
Поток сообщений не отображает ход выполнения процесса, а показывает передачу сообщений или объектов из одного процесса в другой процесс или внешнюю ссылку.
В качестве объекта данных может использоваться объект любого из следующих справочников: Бумажный документ, Электронный документ, ТМЦ, Информация, Программные продукты, Термины, Прочее.
Немного о правилах нотации
Сколько блоков задач/действий можно умещать на одной диаграмме/модели? С точки зрения нотации – сколько влезет, при чем в прямом смысле – столько, сколько сможете разместить блоков внутри пула процесса. Но с точки зрения анализа, есть не прописанное нигде правило, но которым пользуются аналитики: блоков задач/действий в одном процессе должно быть столько, чтобы не «уходить» на второй этаж пула.
То есть все действия одного процесса должны умещаться в линию в пуле, если в рамках одной дорожки действий слишком много и они не помещаются в линию, значит что-то не так с декомпозицией, это «излишнее» дробление на действия, скорее всего должно быть произведено на следующем уровне декомпозиции, включено в подпроцесс, свернуто и раскрыто в отдельной диаграмме.
Краткое описание 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 НА ПРАКТИКЕ?
Здесь я хочу поделиться некоторыми советами о том, с чего начать и как производить разработку моделей бизнес-процессов. Мои советы основаны на знаниях особенностей бизнес-моделирования и личном практическом опыте.
Что еще хотелось бы посоветовать:
Еще статьи по данной теме:
Также в настоящее время я готовлю к публикации книгу и онлайн курс, в которой подробно опишу собственное видение процессного подхода к бизнесу, а также мой собственный практический опыт работы в сфере функционального и процессного моделирования. Все желающие могут подписаться на уведомление о выходе новой книги по и другие новости ссылке.