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

Введение

В этой статье мы рассмотрим, что представляет собой нотация бизнес-моделирования 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/

нотация

Синонимы:

Нотация

Найдите нотацию в Wiktionary, бесплатном словаре.

In лингвистика и семиотика, нотация — это система графики или символов, символов и сокращенные выражения, используемые (например) в художественных и научных дисциплинах для представления технических фактов и количественных характеристик в соответствии с соглашением. Следовательно, нотация — это набор связанных символов, каждый из которых имеет произвольное значение, созданный для облегчения структурированной коммуникации в пределах поля предметных знаний или . of study.

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

Содержание

• 1 Письменное общение
  • 1.1 Биология и медицина
  • 1.2 Химия
  • 1.3 Вычислительная техника
  • 1.4 Классификация библиотеки
  • 1.5 Логика
  • 1.6 Менеджмент
  • 1.7 Математика
  • 1.8 Физика
  • 1.9 Условные обозначения
  • 1.10 Спорт и игры
• 2 Графические обозначения
  • 2.1 Музыка
  • 2.2 Танец и движение
  • 2.3 Наука
  • 2.4 Другие системы
• 3 См. Также
• 4 Ссылки
• 5 Дополнительная литература

Письменное общение

• Фонографические системы письма, по определению, используют символы для представления компонентов слухового языка, то есть речи, которая, в свою очередь, относится к вещам или идеям. Двумя основными видами фонографической системы обозначений являются алфавит и слоговая система. Некоторые письменные языки более последовательны в соотношении письменных символов (или графем ) со звуком (или фонем ), и поэтому считается, что они имеют лучшую фонематическую орфографию.
• Идеографическое письмо по определению относится к вещам или идеям независимо от их произношения на любом языке. Некоторые идеографические системы также являются пиктограммами, которые передают смысл через их графическое сходство с физическим объектом.

Биология и медицина

• Обозначение нуклеиновых кислот
• Графическое обозначение системной биологии (SBGN)
• Последовательность Обозначения паттернов-описаний мотивов
• Цитогенетические обозначения
• Язык энергетических систем

Химия

• Химические формулы — это способ выражения информации об атомах, составляющих конкретное химическое соединение, например H. 2O или C. 6H. 12O. 6

Вычисление

• BNF (нормальная форма Бэкуса или форма Бэкуса – Наура ) и EBNF (расширенная форма Бэкуса-Наура) — два основных метода обозначения для контекстной бесплатные грамматики.
• Дракон-диаграммы — это графическое представление алгоритмов и процедурных знаний.
• Венгерская нотация — это соглашение об именах идентификаторов в компьютерном программировании, которое представляет введите или предполагаемое использование переменной с определенным шаблоном в имени.
• Математические языки разметки — это компьютерные нотации для представления математических формул.
• Различные нотации были разработаны для определения регулярных выражений.
• язык программирования APL предоставил богатый набор очень кратких новых нотаций

Библиотечная классификация

• Нотация В энциклопедии организации знаний ISKO, ред. Биргер Хьёрланд и Клаудио Ноли.

Логика

Для выражения логических идей используются различные символы; см. Список логических символов

Управление

• Символы исследования времени и движения, такие как therbligs

Математика

• Математическая нотация используется для представления различных видов математических идей.
  • Все типы обозначения вероятности
  • декартовой системы координат, для представления положения и других пространственных понятий в аналитической геометрии
  • Обозначение для дифференцирования, общие представления производная в исчислении
  • нотация Big O, используемая, например, в анализе для представления менее значимых элементов выражения, чтобы указать, что они будут игнорироваться
  • Z-нотация, формальная нотация для определения объектов с использованием теории множеств Цермело – Френкеля и логики предикатов первого порядка
  • Порядковая нотация
  • Нотация-построитель множеств, формальная нотация для определения устанавливает в теории множеств
• Системы для представления очень больших чисел
  • Обозначение стрелок Конвея
  • Обозначение стрелки вверх Кнута
  • Обозначение Штейнхауса – Мозера
  • Символ Шлефли в геометрии
• Системы счисления, обозначение для написания чисел, включая
  • арабские цифры
  • Римские цифры
  • Научное обозначение для выражения la rge и малые числа
  • Знаковое обозначение, использующее знаки или символы для представления чисел
  • Позиционное обозначение, также известное как обозначение разряда, в котором каждая позиция связана со следующей посредством множителя которая называется основанием этой системы счисления
    • Двоичная нотация, позиционная нотация по основанию два
    • Восьмеричная нотация, позиционная нотация по основанию восемь, используемая в некоторых компьютерах
    • Десятичная нотация, позиционное обозначение с основанием десять
    • шестнадцатеричное, позиционное обозначение с основанием шестнадцати, обычно используемое в компьютерах
    • шестидесятеричное обозначение, древняя система счисления с основанием шестидесяти
• См. Также Таблица математических символов — для общих токенов и их определений…

Физика

• Нотация Бра-кет, или нотация Дирака, является альтернативным представлением вероятностных распределений в квантовая механика.
• Обозначение тензорного индекса используется при формулировании физики (в частности, механики сплошных сред, электромагнетизма, релятивистская квантовая механика, теория поля и общая теория относительности) на языке тензоров.

Типографские соглашения

• Инфиксная нотация, общие арифметические и логические обозначения формул, такие как «a + b — c».
• Польская нотация или «префиксная нотация», при которой оператор помещается перед операндами (аргументами), например «+ ab».
• Обратная польская нотация или «постфиксная нотация», которая помещает оператор после операндов, например «ab +».

Спорт и игры

• Бейсбольный счет, чтобы представить игру в бейсбол.
• Обозначение жонглирования, чтобы представить шаблоны жонглирования.
• Каталог Aresti, для представления фигур высшего пилотажа
• Шахматная запись, для представления ходов в игре в шахматы
  • Алгебраическая запись
    • Портативная запись игры
  • Описательная запись
  • Форсайт– Edwards Notation

Графические обозначения

Музыка

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

Танец и движение

• Движение Бенеша Обозначение разрешает графическое представление движений человеческого тела.
• Анализ движений Лабана или Лабанотация позволяет графическое представление движений человеческого тела
• Обозначение движения Эшколя-Вахмана позволяет графическое представление телодвижений других видов, помимо людей, и вообще любых движений (например, высший пилотаж самолета)
• Пилотажные символы Aresti обеспечивают способ представления маневров полета при высшем пилотажах

Наука

• Фейнман диаграммы позволяют графически представить пертурбативный вклад в амплитуду перехода или корреляционную функцию квантово-механической или статистической теории поля
• Структурные формулы представляют собой графические представления молекул
• Диаграммы Венна s как логические отношения между конечным набором наборов.
• Дракон-диаграммы — графическое представление алгоритмов и процедурных знаний.

Другие системы

• Нотация Уайта для классификации паровозов по расположению колес

См. Также

• Злоупотребление нотацией
• Когнитивные аспекты нотации
• Формальная нотация
• Вторичная нотация

Ссылки

Дополнительная литература

Викицитатник содержит цитаты, относящиеся к: Обозначение

• Нёт, Винфрид (1995). Справочник по семиотике. Издательство Индианского университета. ISBN 9780253209597 .
• Хартмут Гюнтер, Отто Людвиг (1996). Письмо и его использование, Том 2. Вальтер де Грюйтер. п. 1559. ISBN 9783110147445.

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

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

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

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

К списку востребованных нотаций моделирования можно отнести IDEF0, EPC, BPMN, DFD, UML. Остановимся подробнее на каждом из них.

IDEF0 (Integration Definition For Function Modeling) как методология была разработана еще в 1981году, последние изменения были внесены в 1993году. Несмотря на то, что методология давно не актуализировалась, она на сегодняшний день имеет достаточно широкое распространение. IDEF0 – это нотация графического моделирования, которая используется для функционального моделирования. На диаграммах IDEF0 рассматриваются логические отношения между функциями, а не последовательность действий во времени и пространстве.

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

EPC (event-driven process chain, событийная цепочка процессов) – графический стандарт моделирования бизнес-процессов, нотация класса WorkFlow.  EPC-метод был разработан Августом-Вильгельмом Шеером в начале 1990-х годов при создании ARIS. Отличительной особенностью является обязательное чередование событий и функций. На диаграммах EPC можно увидеть последовательность решений, функции, события, документы и статусы и другие элементы бизнес-процесса. Корректно описанная модель может быть преобразована в текстовый или табличный регламент.

Нотация BPMN (Business Process Management Notation, нотация моделирования бизнес-процессов) — нотация класса WorkFlow, один из наиболее распространенных методов описания бизнес-процессов на сегодня. В нотации BPMN используется базовый набор интуитивно понятных элементов, которые позволяют определять сложные семантические конструкции. Диаграммы BPMN ориентированы на широкий круг пользователей: и на технических специалистов, и на бизнес-пользователей, и на аналитиков. Также этот язык «понимают» программные продукты, и он позволяет создавать исполняемые алгоритмы с использованием специального программного обеспечения.

UML (Unified Modeling Language, унифицированный язык моделирования) — язык графического описания для объектного моделирования в области разработки программного обеспечения. Применяется для моделирования бизнес-процессов, системного проектирования и отображения организационных структур. Этот язык получил широкое распространение в программной инженерии. Одна из особенностей UML заключается в том, что этот язык позволяет системным архитекторам представлять свое видение системы в виде набора стандартных диаграмм. Диаграммы UML подходят для коммуникации в команде разработчиков и взаимодействия с клиентами.

Источник: www.yandex.ru/images/search

DFD (data flow diagram, диаграммы потоков данных) – это методология графического структурного анализа, которая описывает внешние по отношению к информационной системе источники и адресаты данных, логические функции, потоки данных и хранилища данных. Это один из основных инструментов структурного анализа и проектирования информационных систем, существовавших до широкого распространения UML. Несмотря на популярность UML данный язык по-прежнему используется в бизнес-анализе. Для создания DFD-диаграмм используются две нотации — Йордана (Yourdon) и Гейна-Сарсон (Gane-Sarson). Язык DFD удобен для проектирования контекстных диаграмм, но в отличие от нотации IDEF0 здесь описывается взаимодействие разрабатываемых ИТ-систем с внешней средой.

Теперь ответим на второй вопрос: «в чем заключается отличие языков моделирования бизнес-процессов от языков проектирования систем?» Основное отличие заключается в назначении. Языки моделирования бизнес-процессов рассматривают последовательность действий с точки зрения бизнеса. То есть учитывают все объекты, задействованные при функционировании компании. Например, сотрудников, документы, товарно-материальные ценности, информационные системы и т.д. Языки проектирования информационных систем рассматривают действия с точки зрения воплощения бизнес-процессов в информационных системах и автоматизации. В языках проектирования систем не будет всех элементов бизнеса, которые позволят описать связь структурных подразделений, взаимодействие с поставщиками, клиентами и т.д.

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

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