Нотация это руководство по использованию

Введение

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

Главное назначение и практическое применение

Нотация BPMN (Business Process Modeling Notation) нужна для подробного описания логики выполнения бизнес-процесса, в том числе для отражения деталей процессов, таких как: события, исполнители каждого из действий, используемые и создаваемые документы и другие объекты, использующиеся в качестве входных данных для тех или иных действий или создающиеся в результате их выполнения.

BPMN позволяет описать бизнес-логику выполнения действий в виде наглядной диаграммы, а также запустить отрисованный бизнес-процесс на исполнение. Для этого используются специализированные системы BPMS (Business Process Management System), поддерживающие эту нотацию.

BPMS-системы могут автоматически перевести схему бизнес-процесса в исполняемый код и создать веб-приложение, которое будет обрабатывать данные, введённые пользователями и сторонними сервисами. Это соответствует концепции Low Code/No Code (создание программного обеспечения без разработки кода) и отлично подходит для автоматизации офисных процессов.

Технически такая возможность реализуется за счёт перевода BPMN-диаграмм в документы формата BPEL (Business Process Execution Language). BPEL-документы представляют собой инструкции исполнения бизнес-процессов для веб-сервисов.

Таким образом, BPMN используется в следующих случаях:

1. Когда нужно детально и наглядно показать последовательность и логику взаимосвязи действий, событий, исполнителей и объектов бизнес-процесса

2. Когда требуется запустить схему бизнес-процесса на исполнение в BPMS-системах

Краткая история появления нотации

BPMN считается довольно молодой нотацией: её 1-я версия вышла в 2009 году под эгидой профессионального консорциума OMG. Сегодня эта нотация является стандартом де-факто в ИТ-сфере и используется для описания бизнес-процессов. Текущая версия BPMN 2.0 вышла в 2011 году и используется до сих пор. В 2014 году в дополнение к BPMN группа OMG выпустила нотацию описания бизнес-правил и принятия решений (Decision Model and Notation, DMN).

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

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

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

Уровни моделирования

В зависимости от целей построения BPMN-диаграмм, различают 3 уровня моделирования:

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

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

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

Алфавит нотации

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

Поток управления — это последовательность шагов бизнес-процесса, в которой он исполняется.

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

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

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

События

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

Триггер определяет тип и смысл события. Например, триггер в виде конверта означает, что пришли какие-то данные, причём совсем не обязательно в виде сообщения электронной почты. Триггер в виде часов связан со временем. Если событие имеет триггер, значит, поток управления двинется дальше только тогда, когда сработает триггер этого события. Например, получены данные, наступил определённый временной интервал и так далее.

Подробнее весь набор событий, их визуализация и смысл приведены в Приложении А.

Поток управления

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

Эфемерной сущностью BPMN, которая показывает смысл концепции потока, называют токен. Подобно потоку воды токен «бежит» от стартового события диаграммы к финишному, разделяясь на несколько экземпляров с помощью логических операторов. Последовательность и вариативность выполнения действий называется бизнес-логикой и показывается с помощью логических операторов или развилок, шлюзов. Например, на диаграмме ниже представлено 2 логических оператора: исключающее ИЛИ (XOR) и включающее ИЛИ (OR).

Процесс утреннего пробуждения

Как можно видеть на диаграмме, после стартового события выполняется первое действие («Проверить время звонка»). Следующий за ним логический оператор исключающего ИЛИ, подобно шлюзу, пропускает дальше поток управления только по одной ветке: «да» или «нет». Причём ветка «нет» здесь помечена как поток по умолчанию, который выполнится, если все остальные условия не будут верны.

После выполнения действия оператор включающего ИЛИ (OR) пропускает поток на действие «Выпить кофе» или на действие «Узнать новости» или по обоим веткам. Исключения здесь нет, ручеёк потока управления распараллеливается на две ветки, чтобы потом объединиться снова в одну и один раз выполнить действие «приготовиться к делам». После выполнения этого действия процесс заканчивается конечным событием.

Рассмотренный пример иллюстрирует так называемую оркестровку, то есть последовательность выполнения действий в рамках одного управляющего центра. Управляющий центр (или пул) может быть процессом, системой, крупным элементом оргструктуры или внешнего контрагента.

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

Диаграмма BPMN может содержать один или несколько пулов, каждый из которых может содержать одну или несколько дорожек.

Процесс утоления голода

В следующем примере процесс «утоления голода» состоит из двух дорожек («Ребёнок» и «Мама»), общение между которыми выполняется через поток управления.

Стартовым событием является простое событие «Возникло чувство голода» на дорожке Ребёнок, а конечным — простое событие «Чувство голода удовлетворено» на этой же самой дорожке.

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

Кафе показано отдельным свёрнутым пулом, общение с которым происходит через поток сообщений в рамках свёрнутой задачи «Собраться в кафе». Предполагается, что детали выполнения задачи «Собраться в кафе» отражены на отдельной диаграмме.

Типы событий

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

В частности, одних только событий насчитывается 13 типов в зависимости от связанного триггера, например, сообщение, таймер и прочее. Некоторые из этих событий могут быть стартовыми, промежуточными и финишными, в зависимости от их расположения в потоке управления.

Также некоторые события могут быть прерывающими и не прерывающими.

Прерывающие события (обработчики) приостанавливают поток управления, ожидая прихода указанного в событии триггера. Непрерывающие события продолжают движение потока управления дальше, без остановки. Все стартовые события и некоторые промежуточные являются событиями-обработчиками. Триггер внутри таких событий не закрашен. Например, конверт в событии с типом «сообщение‎» будет белого цвета.

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

События могут располагаться в потоке управления между действиями процесса или на границе действия — в этом случае они считаются граничными.

Граничные события являются промежуточными, они находятся на границе действия, обозначая те факты, которые случились при его выполнении. Они могут прерывать процесс (граничные прерывающие события) или активировать дополнительный поток управления, который выполняется одновременно с выполнением подпроцесса (граничные не прерывающие события). Граничные прерывающие события обозначается кругом с двойной сплошной окантовкой. У граничных непрерывающих событий окантовка тоже двойная, но в виде штриховой линии.

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

Типы действий

Подобно событиям, действия в BPMN также могут быть разных типов:

• Выполняемые вручную без использования какого-либо ПО, например, съесть пиццу.

• Выполняемые пользователем с помощью ПО, к примеру, заказать пиццу.

• Выполняемые скриптом или сервисом, например, изменить статус заказа пиццы.

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

Более подробно про типы действий, их смысл и графические обозначения рассказано в Приложении Б.

Логические операторы

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

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

В отличие от исключающего или, простое ИЛИ (OR) допускает возможность активации как нескольких веток, так и одной из них. В математическом смысле этот оператор реализует дизъюнкцию или логическое сложение переменных, что показано в таблице истинности на слайде.

Наконец, логическое И (AND) означает активацию всех входящих или исходящих в этот оператор потоков управления, реализуя логическое умножение переменных, т. е. операцию конъюнкции.

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

Например, исключающее ИЛИ по событиям, событийное И, а также сложный оператор, который объединяет несколько из упомянутых и моделирует сложную бизнес-логику. Его не рекомендуется использовать на диаграммах, т.к. не очевидно, что именно он показывает.

Следующий рисунок показывает использование эксклюзивного шлюза по событиям, который запускает движение потока только по той ветке, где событие произойдёт раньше. Например, получено согласие от клиента ИЛИ прошло 5 дней (без новостей от клиента).

Все остальные шлюзы, которые есть в BPMN, приведены в Приложении В.

Артефакты

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

Вы можете найти полный перечень артефактов в Приложении Г.

Правила построения диаграмм

Рассмотрим пример бизнес-процесса обработки заявки:

Стартовым событием в нашем процессе является поступление заявки от клиента. Обратите внимание, что клиент на диаграмме показан в виде свернутого пула: мы не видим никаких действий в пуле клиента, потому что для рассматриваемого процесса он представляет собой чёрный ящик, от которого приходят и уходят потоки сообщений, без подробностей обработки.

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

После действия «Направить клиенту коммерческое предложение (КП)» на диаграмме используется логический оператор ИЛИ (событийный XOR), после которого возможен один из двух вариантов:

1. Если прошло 5 дней, что показано событием с триггером таймер, и ответа от клиента нет, заявке присваивается статус «Отказ» в CRM-системе и наступает финишное событие «Заявка закрыта».

2. Если же ответ от клиента получен и 5 дней ещё не прошло, процесс движется дальше в зависимости от данных в этом ответе.

Таким образом либо заявке присваивается статус «Отказ» или выполняется свернутая задача «Сформировать проект договора», детали которой показаны на отдельной диаграмме.

В результате этой задачи создаётся документ «Проект договора» и наступает финишное событие «Заявка успешно обработана».

Поток по умолчанию

Если в диаграмме используются операторы обычного XOR, проверяющего условия по данным, и OR (неисключающего ИЛИ) рекомендуется помечать поток по умолчанию, который активируется, если другие условия не сработали. Поток по умолчанию допустимо не подписывать, если подписаны остальные потоки и диаграмма остаётся понятной. В примере ниже «‎Нецелевой» — поток по умолчанию.

Альтернативный способ показать условия

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

Задачи и события

Говоря про вариативность BPMN, следует отметить небольшое различие между событиями-сообщениями и задачами-сообщениями. По сути это одно и тоже, но к задачам-сообщениям можно прикреплять обработчики событий (например, таймер) и модификаторы (например, цикл по объектам), а к самим событиям — нет.

Ниже показан пример диаграммы с задачами по отправке и получению сообщения:

Пример этой же диаграммы с событиями получения и отправки сообщений:

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

Рекомендации по использованию BPMN

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

Принимая во внимание три уровня моделирования BPMN и избыточный алфавит этой нотации, можно сделать вывод, что при проектировании диаграмм «‎для людей» (без запуска на выполнение в BPMS-системах) следует намеренно ограничить количество используемых элементов:

• Использовать только пользовательские и ручные задачи — без сценариев, сервисов и бизнес-правил, отправки и получения сообщений.

• Использовать только свернутые подпроцессы, раскрывая их детали на отдельной диаграмме.

• Использовать только XOR и AND, без событийных шлюзов и OR, так как разница между исключающим и не исключающим ИЛИ понятна не всем пользователям.

• Использовать события с типом простое, таймер, сообщение и останов.

Для упрощения восприятия диаграммы стоит придерживаться правил наименования:

• Внешних контрагентов показывать как закрытые, они же — свёрнутые пулы (пулы, в которых нет действий).

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

• Называть дорожки также, как роль, должность или структурное подразделение.

• Называть действия (задачи) в стиле Глагол-Существительное, например, «‎Проверить счёт», «Подтвердить заявку», «Оформить договор».

• Называть события как свершившийся факт в прошедшем времени, к примеру, «Поступила заявка», «Прошло 3 дня».

• Подписывать исходящие из XOR стрелки, например, «Да» и «Нет», а также отмечать поток по умолчанию.

Также рекомендуется:

• Показывать успешное и неуспешное завершение процесса разными финишными событиями.

• Не выводить поток управления за пределы подпроцесса.

• Взаимодействие между разными пулами показывать через поток сообщений (пунктирной стрелкой), который не может присоединяться к шлюзам, в отличие от потока управления.

Наконец, при разработке любой диаграммы нужно помнить о главном правиле аналитика: независимо от нотации, ваша схема должна быть МАКСИМАЛЬНО простой и понятной читателю БЕЗ знания тонкостей процессного моделирования!

В целом алгоритм разработки BPMN-диаграммы можно представить как набор следующих 7 шагов:

1. Определить границы процесса, т. е. стартовое и конечное события, участников и полезный результат.

2. Описать «счастливый» путь (happy path), который ведёт к созданию полезного результата (продукта).

3. Добавить условия и альтернативные потоки.

4. Добавить неуспешные завершения.

5. Добавить артефакты (объекты и хранилища данных).

6. Раскрыть на новых связанных диаграммах свёрнутые подпроцессы.

7. Добавить промежуточные событийные потоки к внешним пулам.

Пример построения диаграммы по текстовому описанию

Рассмотрим пример процессов работы с клиентской заявкой, представленной двумя пулами: «Обработка заявки» и «Заключение договора».

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

Процесс начинается с момента, когда клиент оставил заявку на сайте (то есть поступление заявки является триггером процесса, его стартовым событием). На основании заявки, в которой указаны подробности заказа, менеджер формирует коммерческое предложение (КП). Далее менеджер озвучивает КП по телефону или направляет на email, или же делает и то, и другое — в зависимости от пожеланий клиента и указанных в заявке контактных данных.

Узнав подробности коммерческого предложения, клиент принимает решение о продолжении сотрудничества или отказе от него. Если клиент не согласился на условия КП, на этом процесс работы с ним заканчивается, а заявке присваивается статус «Отказ».

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

При наличии возражений к проекту договора клиент вносит в него изменения и снова направляет менеджеру. Менеджер формирует новый проект договора и снова отправляет клиенту на согласование, то есть идёт возврат к ранее выполняемой задаче.

Инструменты для разработки бизнес-процессов в нотации BPMN

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

• ШТОРМ — веб-редактор от команды Дениса Котова, пожалуй, главного евангелиста BPMN в России, с автопроверкой диаграмм и возможностями командной работы в одном пространстве;

• Online BPMN — простой и удобный веб-редактор, поддерживает интеграцию с BPMS-системой;

• Cavemo — веб-редактор, аналогичный предыдущему, имеет офлайн-версию

• простые веб-«рисовалки‎» Lucidchart, Draw.io, Visual Paradigm

Также алфавит нотации BPMN поддерживается и в MS Visio, ARIS Express и других редакторах диаграмм общего назначения.

Заключение

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

Однако, избыточный алфавит нотации, особенно слишком большой набор событий и шлюзов, затрудняют разработку и чтение диаграмм. Это приводит к тому, что у разных аналитиков могут получиться разные диаграммы описания одного и того же процесса. Такая вариативность не всегда хороша, поскольку повышает семантическую нагрузку на читателя. Поэтому при использовании BPMN в качестве корпоративного стандарта визуального описания бизнес-процессов (без запуска на исполнение в BPMS) следует определить, какие элементы вы с коллегами будете использовать, и что именно каждый из них означает, чтобы исключить риски возможных семантических расхождений и снизить смысловую нагрузку на читателей диаграммы.

• Кандидат технических наук (Системный анализ, управление и обработка информации, 2013)

• Сертифицированный бизнес-аналитик (IIBA CBAP, 2020)

• Сертифицированный специалист Business Studio и СЭД Directum

Профессиональные интересы: системный анализ, бизнес-анализ, разработка и поддержка СМК, ССП (KPI), анализ и формализация бизнес-процессов (UML, IDEF, BPMN), Data Science, технологии Big Data, разработка технической документации (ТЗ по ГОСТам серии 19, 34, руководства пользователя и администратора, описание программных продуктов), управление продуктами и проектами.

В этой статье мы поговорим про основы бизнес-анализа и рассмотрим наиболее популярные на сегодня нотации моделирования UML, BPMN и EPC, а также покажем, почему структурные методы IDEF0, IDEF1 и DFD до сих пор актуальны. Читайте в этом материале, где и как использовать различные нотации бизнес-моделирования и что рекомендует руководство BABOK.

Что такое бизнес-моделирование: взгляд BABOK на многообразие нотаций

Прежде всего отметим, что цель этой статьи – не научить читателя рисовать диаграммы в той или иной нотации моделирования, а показать возможности этих инструментов для практикующего бизнес-аналитика. Начнем с определения: нотация бизнес-моделирования – это система графических элементов, символов и условных обозначений, для описания процессов или систем, позволяющая описать ключевые понятия предметной области и их взаимоотношения. Используемые при этом символы, условные и графические обозначения составляют алфавит нотации, с которым можно работать по специальным правилам применения его элементов [1]. Существует множество нотаций, используемых при описании бизнес-процессов и проектировании информационных систем, например, один только стандарт UML (Unified Modeling Language) включает 12 видов диаграмм для объектного моделирования при разработке программного обеспечения [2].

Семейство стандартов IDEF (ICAM или Integrated DEFinition) насчитывает целых 14 методологий, каждая из которых предназначена для моделирования процессов или систем с определенной точки зрения. Например, IDEF0 наглядно показывает структуру процессов и систем за счет функциональной декомпозиции, IDEF1x используется при проектировании реляционных баз данных, позволяя создавать ERD-диаграммы (Entity Relationship Diagram), с помощью IDEF3 можно документировать логику выполнения процесса и пр. [3]. Наконец, среди наиболее часто используемых на практике нотаций стоит упомянуть DFD (Data Flow Diagram, диаграммы потоков данных), EPC (Event-driven Process Chain, событийная цепочка процессов) и BPMN (Business Process Management Notation, нотация моделирования бизнес-процессов).

Некоторые из перечисленных нотаций частично дублируют назначение друг друга и даже похожи визуально. К примеру, у BPMN очень много общего с EPC и UML-диаграммой деятельности (Activity Diagram), а также процессным методом IDEF3 [4]. В свою очередь, объектный метод IDEF3 пересекается с UML-диаграммой состояний (State Diagram) [5], а IDEF4 вообще включает целый набор методов, аналогичных UML, позволяя проектировать систему «сверху вниз» через моделирование классов, объектов и взаимоотношений между ними [6].

Чтобы не запутаться в многообразии различных нотаций моделирования, бизнес-аналитику стоит помнить, что все эти диаграммы – всего лишь инструмент для описания процесса или системы с определенного ракурса. В частности, профессиональное руководство BABOK (Business Analysis Body of Knowledge) по бизнес-анализу [7], о котором мы рассказывали здесь, поясняет, что для комплексного описания системы следует использовать несколько нотаций моделирования, т.к. ни одна точка зрения не может автономно определить всю архитектуру сложного объекта. Более того, BABOK подчеркивает, что попытки вложить слишком много информации в одну точку зрения и представить все аспекты сложной системы, таких как набор требований к программному обеспечению, архитектура предприятия, корпоративные бизнес-процессы и пр., только усложнят видение и не позволят получить модели приемлемого качества.

Таким образом, на практике бизнес-аналитик работает с несколькими нотациями, чтоб описать бизнес-процессы предприятия или специфицировать требования к программному продукту. Разумеется, в реальности при этом используются не все вышеуказанные нотации бизнес-моделирования. Далее мы рассмотрим, какие диаграммы и для чего чаще всего применяются в практическом бизнес-анализе.

Структура и динамика: как описать системы и бизнес-процессы

Все многообразие нотаций бизнес-моделирования можно разделить на 2 категории:

• Структурные, которые показывают компонентный состав исследуемого объекта и взаимосвязи между его элементами. Например, UML-диаграммы классов, компонентов, кооперации, композитной структуры, развертывания, пакетов, объектов и профилей. Из нотаций стандарта IDEF к структурным относятся IDEF0, IDEF1x, IDEF4, IDEF5 и IDEF.
• Динамические, которые показывают движение потоков данных или логику выполнения процессов. Например, DFD, EPC, BPMN, а также UML-диаграммы деятельности, состояний, вариантов использования и последовательностей.

На практике все перечисленные нотации моделирования используются довольно часто, однако тут стоит отметить некоторые особенности применения в зависимости от контекста:

• в задачах системного анализа и синтеза, таких как разработка совершенно нового технического продукта (ракета, автомобиль и пр.), преимущественно используются комплексные методологии семейства IDEF, позволяющие проектировать систему «сверху вниз» за счет функциональной декомпозиции – разбиения сложного объекта на более простые элементы с их последующим описанием;
• при разработке требований к программному обеспечению и документировании готового решения чаще всего применяется стандарт UML, позволяющий описать проектируемый продукт в объектно-ориентированных терминах. Для описания структуры базы данных используется ERD-нотация IDEF1x (Extended). А DFD-диаграмма наглядно продемонстрирует движение потоков данных между различными хранилищами (СУБД, файлы, бумажные и другие материальные носители) и процессами по их преобразованию. Подробнее о том, как разработать DFD-диаграмму, читайте здесь.
• для описания бизнес-процессов предприятия с целью их анализа и последующей оптимизации используются нотации IDEF0, BPMN, EPC. При этом указанные методы отлично дополняют друг друга, детализируясь от структуры метапроцессов, таких как «продвижение и продажи», «осуществление основного вида деятельности» и пр., представленных в IDEF0, к пошаговым алгоритмам, показывающим логику исполнения процессов в виде EPC- или BPMN-диаграмм. Например, именно такой подход реализован в популярной отечественной системе бизнес-моделирования Business Studio [8]. Подробнее о достоинствах и недостатках IDEF0, а также примерах практического использования этой нотации, которая сегодня несправедливо считается устаревшей и неактуальной, читайте в нашей новой статье.

В заключение отметим, что все рассмотренные и другие нотации бизнес-моделирования, в первую очередь, предназначены для аналитика и могут показаться сложными для руководителя или специалиста другой предметной области. В частности, руководство BABOK отмечает, что UML и BPMN-диаграммы в большинстве случаев кажутся стейкхолдерам слишком «техническими», что затрудняет восприятие информации. Поэтому при выборе нотации как инструмента моделирования следует помнить не только о цели (что хотим описать), но и о целевой аудитории (кому будем показывать). К примеру, схемы EPC, ярко и понятно описывающие алгоритм выполнения отдельных процессов, достаточно легко воспринимаются бизнес-пользователями. Что общего между EPC и BPMN нотациями, я рассказываю в этом материале.

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

Освоить все рассмотренные нотации моделирования и их применение на практике вы сможете на курсах Школы прикладного бизнес-анализа в нашем лицензированном учебном центре обучения и повышения квалификации системных и бизнес-аналитиков в Москве:

• Методы описания бизнес-процессов (IDEF, BPMN, EPC, UML)
• Основы бизнес-анализа: вход в профессию для начинающих
• UML для бизнес-аналитика

Источники

1. https://ru.wikipedia.org/wiki/Нотация
2. https://ru.wikipedia.org/wiki/UML
3. https://ru.wikipedia.org/wiki/IDEF
4. https://ru.wikipedia.org/wiki/BPMN
5. https://ru.wikipedia.org/wiki/IDEF3
6. https://en.wikipedia.org/wiki/IDEF4
7. https://www.iiba.org/standards-and-resources/babok/
8. https://www.businessstudio.ru/products/business_studio/notations/

Нотация

Синонимы:

Полезное

18.09.2020

Самые популярные нотации описания и моделирования бизнес-процессов

В прошлой статье мы уже разбирали основные типы описания бизнес-процессов. Теперь пришла пора поговорить о видах нотаций в их описании. 

Для начала необходимо разобраться, что же такое нотация.

Она определяет КАК мы обозначаем на схеме процессы, операции, события и т. п., и по каким правилам мы их объединяем в общую схему. То есть нотация — это набор знаков и правил для визуально понятного описания бизнес-процессов.

Зачем они нужны, ведь мы всегда можем нарисовать схему бизнес-процесса на листе бумаги или на доске маркером? Ответ — необходимость в автоматизации, т. е. в переводе нарисованного маркером на доске в какое-то ПО.

Мы рассмотрим 3 самых популярных на данный момент вида нотаций:

IDEF — Integration DEFinition.

Начнём с того, что IDEF — это не одна нотация, а целая группа. Они различаются по номерам (IDEF0, IDEF1, IDEF2 и т. д.) и используются для описания разных элементов бизнес-системы. 

Разбирать каждую из них не смысла, поэтому мы рассмотрим всю группу в целом.

Первое что важно знать о IDEF — это то, что это самая старая нотация из всех. Она уже десятилетиями не обновляется, а значит морально и функционально устарела. Тем не менее IDEF всё ещё пользуются, и раз она попала в топ-3, то как минимум знать о ней стоит.

(картинка примера IDEF)

Разберём плюсы и минусы нотации IDEF.

Плюсы:

1. Блок-схема, с использованием нотации IDEF, всегда «заточена» под лист А4. Удобно распечатывать.
2. Программ, поддерживающих IDEF, много.

Минусы:

1. Использовать модели, построенные в IDEF, сложно.
2. Построенную модель трудно анализировать.
3. Ограничения по количеству отображаемых в схеме процессов (всего 7).
4. Правила описания и чтения бизнес-процессов неудобны и сложны.
5. Программы, поддерживающие IDEF, устарели вместе с ней.

Вывод: если Вы встали перед выбором нотации для описания бизнес-процессов, то IDEF пропускаем мимо.

eEPC — extended Event-driven Process Chain.

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

За основу при разработке данной системы была взята IDEF3, однако eEPC намного нагляднее и обладает большим функционалом.

(картинка пример eEPC) 

Плюсы нотации eEPC:

1. Логика построения легка и понятна.
2. Многие ПО позволяют моделировать в eEPC.
3. Удобно изучать и анализировать.
4. Можно увидеть события, которые управляют развитием процессов.
5. Большое количество возможностей для моделирования любого процесса.

Минусы нотации eEPC:

1. Невозможно определить как происходит взаимодействие между участниками процесса.
2. События нельзя отличить по типу.
3. Дороговизна.
4. Ориентация на сложные и комплексные программные решения.

Вывод: eEPC стоит рассматривать для описания и моделирования бизнес-процессов.

BPMN 2.0 — Business Process Model and Notation.

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

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

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

Плюсы BPMN:

1. Регулярное обновление, развитие и доработка нотации.
2. Гибкость и удобство настройки.
3. Многофункциональность и простота в использовании.
4. Наличие «дорожек».
5. Возможность деления событий на типы: начало, промежуточное и окончание.
6. Возможность создавать свои собственные значки и адаптировать нотацию под свои потребности.
7. ПО с BPMN — самое активно развивающиеся. Многие программы бесплатные.
8. Подходит как для малых и средних, так и крупных компаний 
9. Возможность привязки к 1С.

Минусы:

1. В нотации много понятий и терминов. Их нужно знать и грамотно применять.
2. Высокий уровень вхождения. Из-за широкого круга возможностей нужно довольно много времени на их детальное изучение (по сравнению с другими нотациями).
3. Требуется знание бизнес-анализа. BPMN модели — не просто картинки, которые может рисовать любой ребёнок на листе А4. В этой нотации очень важная грамотная структура и последовательность.

Общий вывод: 

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

Если после прочтения статьи, у Вас возникли вопросы и Вы хотите получить на них ответы, то оставьте заявку на сайте:

Наш телефон: +7 (495) 981-63-05
Наша почта: expert@salecraft.ru

Тематическая статья:
Разрыв между продающим и производственными департаментами. Как оптимизация бизнес-процессов экономит время и деньги. Наглядный пример.