Диаграмма используется для построения модели бизнес процессов

АННА Вичугова

Как начать моделировать бизнес-процессы в BPMN

Алфавит нотации и примеры бизнес-процессов

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

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

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

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

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

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

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

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

Воркшоп «BPMN для людей:

основы самой популярной нотации

для описания бизнес-процессов»

Воркшоп для ИТ-специалистов, которые хотят научиться описывать логику выполнения бизнес-процессов с помощью формальной нотации — BPMN. Читателями таких диаграмм будут люди, а не сервисы.

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

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 уровня моделирования:

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

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

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

Событие — это некий свершившийся факт, что-то, что возникает по ходу процесса или происходит в результате выполнения тех или иных действий. Например, «от клиента поступила заявка», «прошла неделя с момента подачи заявления» и т. д. Процесс в 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 шагов:

Определить границы процесса, т. е. стартовое и конечное события, участников и полезный результат
Описать «счастливый» путь (happy path), который ведёт к созданию полезного результата (продукта)
Добавить условия и альтернативные потоки
Добавить неуспешные завершения
Добавить артефакты (объекты и хранилища данных)
Раскрыть на новых связанных диаграммах свёрнутые подпроцессы
Добавить промежуточные событийные потоки к внешним пулам

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

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

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

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

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

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

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

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

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

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

ШТОРМ — веб-редактор от команды Дениса Котова, пожалуй, главного евангелиста BPMN в России, с автопроверкой диаграмм и возможностями командной работы в одном пространстве;
Online BPMN — простой и удобный веб-редактор, поддерживает интеграцию с BPMS-системой;
Cavemo — веб-редактор, аналогичный предыдущему, имеет офлайн-версию
простые веб-«рисовалки‎» Lucidchart, Draw.io, Visual Paradigm

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

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

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

Воркшоп «BPMN для людей:

основы самой популярной нотации

для описания бизнес-процессов»

Анна Вичугова

Кандидат технических наук (Системный анализ, управление и обработка информации, 2013)
Сертифицированный бизнес-аналитик (CBAP 2020, международная сертификация IIBA)
Сертифицированный специалист Business Studio (2010, 2012, 2013, 2018)
Сертифицированный специалист и администратор СЭД Directum (2011)

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

Источник

Автор: Александр Марголин, CTO

Материалы статьи подготовлены в рамках внутренней программы менторства и обучения специалистов команды Evergreen.

Что такое UML-диаграммы?

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

Для чего используется UML?

Одна из задач UML — служить средством коммуникации внутри команды и при общении с заказчиком. Давайте рассмотрим возможные варианты использования диаграмм.

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

Нотация UML для описания логики проекта

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

фигуры;
линии;
значки;
надписи.

UML-нотация является де-факто отраслевым стандартом в области разработки программного обеспечения, ИТ-инфраструктуры и бизнес-систем.

Часто используемые программы для создания диаграмм

Diagrams.net — удобный сервис для создания блок-схем, UML-диаграмм, моделей бизнес-процессов онлайн. Совместим с большинством популярных инструментов, включая Google Docs, Git, Dropbox, OneDrive и другие.

Источник: diagrams.net

Dbdiagram.io — приложение для построения диаграмм связей для баз данных. Хороший инструмент для разработчиков и аналитиков.

Google Drawings — бесплатный инструмент для создания блок-схем и диаграмм в составе Google Drive (менее удобный по сравнению с diagrams.net);
xmind.net — программа для построения интеллектуальных карт (mind map), логических схем, сложных структур, проведения брейнсторма и не только.

Виды UML-диаграмм

В языке UML есть 12 типов диаграмм:

4 типа диаграмм представляют статическую структуру приложения;
5 типов представляют поведенческие аспекты системы;
3 представляют физические аспекты функционирования системы (диаграммы реализации).

Некоторые из видов диаграмм специфичны для определенной системы и приложения. Самыми доступными из них являются:

Диаграмма прецедентов (Use-case diagram);
Диаграмма классов (Class diagram);
Диаграмма активностей (Activity diagram);
Диаграмма последовательности (Sequence diagram);
Диаграмма развёртывания (Deployment diagram);
Диаграмма сотрудничества (Collaboration diagram);
Диаграмма объектов (Object diagram);
Диаграмма состояний (Statechart diagram).

Диаграмма прецедентов — Use-case diagram

Диаграмма прецедентов использует 2 основных элемента:

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

2) Use case (прецедент) — описание отдельного аспекта поведения системы с точки зрения пользователя. Прецедент не показывает, «как» достигается некоторый результат, а только «что» именно выполняется.

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

Источник: slide-share.ru

Второй пример немного сложнее. Видим, что одно и то же лицо может выступать в нескольких ролях. Например, product manager у нас работает над стратегией и больше ничем не занимается, архитектор работает над стратегией и занимается внедрением, build master занимается тремя вещами одновременно, и так далее. По такой схеме мы можем проследить, какая из ролей связана с какими прецедентами.

Источник: slide-share.ru

Диаграмма классов — Class diagram

Класс (class) — категория вещей, которые имеют общие атрибуты и операции. Сама диаграмма классов являет собой набор статических, декларативных элементов модели. Она дает нам наиболее полное и развернутое представление о связях в программном коде, функциональности и информации об отдельных классах. Приложения генерируются зачастую именно с диаграммы классов. Рассмотрим на простом примере ниже:

Источник: slide-share.ru

Для класса «студент» есть таблица, содержащая атрибуты: имя, адрес, телефон, e-mail, номер зачетки, средняя успеваемость. И также показаны связи данной сущности с другими: прохождением курса, какой курс слушает, кто профессор. В этом примере также добавляются функции, которые могут быть применены к сущности «студент».

Диаграмма активностей — Activity diagram

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

Диаграмма активностей для сайта магазина максимально доступно объясняет, какие есть интеграции в системе. Актер (в нашем случае — покупатель), зашедший на сайт, делает заказ. Далее у нас происходит разветвление: проверяем, является ли пользователь оптовиком (Да/Нет). Если он не зарегистрирован в системе и не оптовик, заказ отправляется в retailCRM. Если пользователь зарегистрирован, его заказ попадает в Navision. При этом между retailCRM и Navision происходит синхронизация остатка и статусов.

Эту базовую диаграмму мы можем дополнить, расширить, она может выступить частью документации и дает общее представление о работе системы.

Диаграмма последовательности — Sequence Diagram

Используется для уточнения диаграмм прецедентов — описывает поведенческие аспекты системы. Диаграмма последовательности отражает взаимодействие объектов в динамике, во времени. При этом информация принимает вид сообщений, а взаимодействие объектов подразумевает обмен этими сообщениями в рамках сценария.

Источник: slide-share.ru

Диаграмма развертывания — Deployment Diagram

Диаграмма развертывания отображает графическое представление инфраструктуры, на которую будет развернуто приложение: топологию системы и распределение компонентов по ее узлам, а также соединения — маршруты передачи данных между узлами. Диаграмма помогает более рационально организовать компоненты, от чего зависит в числе прочего и производительность системы, а также решить вспомогательные задачи, например, связанные с безопасностью.

Источник: slide-share.ru

Заключение

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

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

Остались вопросы, хотите обсудить с нами ваш проект или заказать разработку? Пишите!

06.02.2021

Используемые в статье картинки взяты из открытых источников и используются как иллюстрации.

Источник

Лекция

Язык моделирования
— это графическая система обозначений
для описания программного проекта.
Кроме того, языки содержит ряд правил,
в соответствии с которыми создаются те
или иные диаграммы.

Одним из наиболее
распространенных языков моделирования
является UML.
В нем предусмотрены все аспекты создания
программного обеспечения: анализ,
проектирование, разработка. UML
принят в качестве международного
стандарта моделирования программных
систем. Стандарт UML
поддерживается многими крупнейшими
производителями программного обеспечения
(Microsoft
Visual
Modeler
for
Basic,
Rational
Rose,
Delphi
и др.). В настоящее время действует
стандарт UML
2.0.

Стандарт моделирования
UML
предназначен для реализации
объектно–ориентированного подхода в
проектировании программных средств и
моделирования
бизнес-процессов предприятий и
организаций.

Стандарт
моделирования UML
включает в себя следующий набор диаграмм:

Диаграммы
вариантов использования –
для
моделирования
бизнес-процессов
предприятий и организаций, а
также требований к будущей информационной
системе;
Диаграммы классов
– для моделирования статической
структуры применяемых в системе классов
и связей между ними;
Диаграммы
взаимодействия – для моделирования
процессов обмена сообщениями между
объектами системы. Существует два вида
таких диаграмм: диаграммы последовательности
и кооперативные диаграммы;
Диаграммы состояний
– для моделирования поведения объектов
при переходе от одного состояния к
другому;
Диаграммы
деятельностей – для моделирования
поведения системы в рамках различных
вариантов использования;
Диаграммы размещения
– для моделирования физической
архитектуры системы и другие.

Далее рассмотрим
сущность и применение основных диаграмм
языка UML
при моделировании систем на основе
объектно-ориентированного подхода.

Диаграммы вариантов использования

Диаграммы вариантов
использования иногда в литературе
называют диаграммами прецедентов. Мы
будем использовать первый термин.

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

Варианты
использования являются необходимым
средством на стадии анализа предприятий
и на стадии формирования требований к
будущей ИС. Каждый
вариант использования
— это модель одного бизнес-процесса,
реализуемого на предприятии.
В проектировании ИС вариант
использования
является одним потенциальным требованием
к системе, и пока оно
не выявлено, невозможно запланировать
его реализацию.

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

Действующие
лица делятся на три основных типа:

пользователи
системы,
другие системы,
взаимодействующие с данной,
время.

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

Рис. 1. Пример
диаграммы вариантов использования

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

перевести деньги,
сделать вклад,
снять деньги со
счета,
просмотреть
баланс,
изменить PIN-код
сделать платеж.

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

В
нашем примере клиент
банка инициирует большое количество
различных вариантов
использования: «Снять деньги со счета»,
«Перевести деньги», «Сделать
вклад», «Просмотреть баланс» и «Изменить
PIN-код». От варианта использования
«Сделать платеж» стрелка указывает на
«Кредитную систему». Действующими
лицами могут быть внешние
системы, и потому в данном случае
«Кредитная система» показана
именно как действующее лицо — она внешняя
для банковской
системы. Направленная от варианта
использования к действующему
лицу стрелка показывает, что вариант
использования предоставляет
некоторую информацию, используемую
действующим лицом. В данном случае
вариант использования «Сделать платеж»
предоставляет «Кредитной системе»
информацию об оплате
по кредитной карточке.

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

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

Конкретная
цель диаграмм вариантов использования
— это документирование:

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

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

не
моделируйте связи между действующими
лицами. По определению действующие
лица находятся вне сферы действия
системы. Это означает, что связи между
ними также не относятся к ее компетенции;
не
соединяйте стрелкой два варианта
использования непосредственно.
Диаграммы данного типа описывают
только, какие варианты
использования доступны системе, а не
порядок их выполнения.
Для отображения порядка выполнения
вариантов использования применяют
диаграммы деятельностей;

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

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

Варианты
использования обозначают действия
системы.
Для того чтобы фактически разработать
систему,
потребуются более конкретные детали.
Эти детали
описываются в документе, называемом
«поток
событий»
(flow
of
events).
Целью потока событий является
документирование
процесса обработки данных, реализуемого
в рамках варианта
использования. Этот документ подробно
описывает, что будут
делать пользователи системы и что — сама
система.

Для
моделирования бизнес-процессов
организаций и предприятий также
средствами UML также можно применять
диаграммы деятельности.
Ранее при проектировании информационных
систем эти диаграммы мы использовали
для моделирования динамических аспектов
создаваемых ИС.

В контексте языка
UML деятельность (activity) представляет
собой некоторую совокупность отдельных
вычислений, выполняемых автоматом. При
этом отдельные элементарные вычисления
могут приводить к некоторому результату
или действию (action). На диаграмме
деятельности отображается логика или
последовательность перехода от одной
деятельности к другой, при этом внимание
фиксируется на результате деятельности.

Соседние файлы в папке Лекции ОДП

Источник

#статьи

7 дек 2022
0

Рассказываем главное, что нужно знать об описании бизнес-процессов с помощью нотации BPMN.

Иллюстрация: Оля Ежак для SKillbox Media

Рассказывает просто о сложных вещах из мира бизнеса и управления. До редактуры — пять лет в банке и три — в оценке имущества. Разбирается в Excel, финансах и корпоративной жизни.

Бизнес-аналитик с опытом работы более четырёх лет, магистр в области информационной бизнес-аналитики. Сейчас участвует в проектах, связанных с нефтедобычей, геологоразведкой, логистикой. Принимала участие во внедрении «1С:ERP» как основной бизнес-аналитик. Проверяющий куратор курсов Skillbox «Профессия Бизнес-аналитик», «Профессия Операционный менеджер».

Перед тем как улучшать процессы любого бизнеса, важно описать, как они работают сейчас, — смоделировать их. Нотация BPMN (Business Process Model and Notation) — один из способов такого моделирования.

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

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

В статье для Skillbox Media расскажем:

что такое бизнес-процессы и для чего ими управлять;
какие есть способы описания бизнес-процессов;
что такое нотация BPMN и в чём её главные преимущества;
из каких элементов состоит BPMN;
как построить модель бизнес-процесса с помощью BPMN пошагово;
как применяют нотацию BPMN в бизнес-аналитике;
как узнать больше об управлении бизнес-процессами.

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

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

Чтобы всё работало, процессами нужно управлять. От гибкости и управляемости бизнес-процессов зависит, насколько успешным будет бизнес. Есть разные подходы к управлению — все они включают три основных элемента:

анализ бизнес-процессов;
выявление проблем;
оптимизация бизнес-процессов.

Инфографика: Майя Мальгина для Skillbox Media

В Skillbox Media есть статья, где подробно рассказано об управлении бизнес-процессами.

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

Три самых распространённых способа описания бизнес-процессов:

Текстовый — подготовка письменных инструкций, регламентов, стандартов и других нормативных документов.
Табличный — описание процессов в формате таблиц.
Схематичный — графическое изображение процессов.

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

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

Нотации описывают:

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

Есть несколько вариантов нотаций — их выбирают в зависимости от типов бизнес-процессов и потребностей бизнеса. Вот некоторые примеры нотаций:

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

В следующих разделах подробно говорим о нотации BPMN.

BPMN — аббревиатура от Business Process Model and Notation. Это система условных обозначений и их описания для моделирования бизнес-процессов.

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

Первая версия BPMN создана в 2004 году рабочей группой IBM. В 2010 году — дополнена и выпущена под названием BPMN 2.0. В неё добавили новые типы событий и диаграмм, устранили ошибки первой версии.

Вот главные преимущества нотации BPMN перед другими нотациями:

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

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

Ниже на иллюстрации приведён пример процесса — поиска и приёма на работу нового сотрудника.

Фрагмент описания бизнес-процесса в нотации BPMN
Скриншот: личный архив Анны Солодовниковой

Разберём основные элементы нотации. Их будет достаточно для большинства схем.

Процесс (задача, подпроцесс). Задача — действие или операция, у которых нет дальнейшей декомпозиции в рамках процесса. Подпроцесс — декомпозированный процесс, в который включено несколько задач. На диаграмме он обозначается блоком со знаком +.

Изображение: Skillbox Media

Примеры задач в иллюстрации выше — «Заявка на подбор нового сотрудника», «Проведение собеседования». Часто задачи формулируют через глагол: «Провести собеседование», «Подобрать сотрудника».

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

Изображение: Skillbox Media

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

В нашем примере стартовые события — «Потребность в расширении штата» и «Текущий сотрудник написал заявление на увольнение».

Шлюзы. Показывают слияния потоков управления в рамках процесса. Среди них выделяют:

Параллельный шлюз — означает, что два процесса исполняются одновременно. Читается как «И».
В нашем примере параллельный шлюз — «Проведение собеседования» и «Проведение собеседования, заполнение листа оценки кандидата».

Изображение: Skillbox Media

Эксклюзивный шлюз — используют, чтобы обозначить ветвление потока управления на несколько альтернативных потоков, когда процесс зависит от выполнения условия. Читается как «ИЛИ».
В этом случае процесс идёт чётко по одному из потоков.

Изображение: Skillbox Media

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

Изображение: Skillbox Media

Объект данных. Показывает, какие объекты сопровождают выполнение процесса. Например, бумажный документ, электронный документ, информацию и так далее.

В нашем примере объекты данных — «Заявка на подбор», «Лист оценки кандидата», «Предложение о работе».

Изображение: Skillbox Media

Потоки. Это стрелки, которые показывают движение по процессам и порядок их выполнения. Есть несколько видов потоков:

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

Изображение: Skillbox Media

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

Изображение: Skillbox Media

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

Изображение: Skillbox Media

Пулы (дорожки). Показывают участников бизнес-процессов. Например, должности, подразделения, роли, внешние субъекты. Дорожка не может соответствовать системе или другим объектам — только людям.

Например, в нашей иллюстрации дорожки соответствуют кандидату, HR-менеджеру, руководителю отдела.

Изображение: Skillbox Media

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

Существует много инструментов для разработки процессов в BPMN. Мы рекомендуем бесплатный онлайн-сервис Diagrams.net. В нём можно создавать схемы, модели, диаграммы и обмениваться ими в браузере.

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

Вот пошаговый план того, как построить бизнес-процессы в нотации BPMN:

1. Изучите процесс: для чего он нужен и какие задачи решает.

2. Определите, является он основным, вспомогательным или процессом управления.

Основной процесс — приносящий прибыль или влияющий на прибыль компании. Например, производство или продажи. Таким процессам нужно уделять особое внимание.

Вспомогательный процесс — процесс, который не генерирует доход, но обеспечивает качественное выполнение основных процессов. Например, бухгалтерский учёт.

Процесс управления — процесс, влияющий на существование и развитие компании. Например, управление командами компании.

3. Запросите у ответственных за процесс инструкции, регламенты и другие нормативные документы, которые описывают процесс или работу участвующих в нём отделов. По этим документам можно составить первичное представление о процессе.

4. Выявите всех участников процесса: должности, роли, отделы, в некоторых случаях — Ф. И. О. ответственных сотрудников. Но в схемах процесса лучше избегать построения дорожек, завязанных на Ф. И. О., — иначе нужно будет постоянно следить за актуальностью данных.

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

6. Отметьте все внутренние события бизнес-процесса. Дополнительные детали можно при необходимости уточнить у владельцев процесса.

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

Задачи бизнес-аналитика, для которых требуется BPMN, делят на два этапа:

Построение схем «как есть» (as is) — описание текущей последовательности работ бизнес-процесса.
Построение схем «как будет» (to be) — описание целевого процесса с фиксацией требуемых изменений: этапов модернизации, автоматизации.

Разберём на примере. Допустим, в компании N было 70 сотрудников, которые работали в одном офисе. Всю необходимую документацию они распечатывали, подписывали от руки и самостоятельно относили получателю — например, бухгалтеру, отделу кадров или секретарю.

Потом компания выросла в 2,5 раза, появились удалённые сотрудники. Руководство приняло решение внедрить систему электронного документооборота (СЭД). Перед внедрением такой системы бизнес-аналитику потребуется выполнить три основные задачи:

Разобраться и описать, как сейчас сотрудники знакомятся с документами и подписывают их. При этом учесть два типа сотрудников — работающих в офисе и удалённо.
Выявить возможные узкие места и особенности процесса в данной компании. Эти особенности должны быть учтены при разработке или покупке готовой СЭД.
Проанализировать, как бизнес-процесс «ложится» на новую систему: в каких местах необходима доработка ПО, в каких — организационные изменения внутри компании.

Что даёт описание текущего процесса и моделирование целевого процесса документооборота? Снизится риск упустить ключевые функции СЭД и получить на выходе систему, которая не будет решать задачи компании.

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

Бизнес-процессы — все операции, которые помогают решать задачи бизнеса и получать доход. Чтобы всё работало по плану, процессами нужно управлять: описывать их, анализировать и оптимизировать.
Эффективнее всего описывать бизнес-процессы графически — в виде интуитивно понятных схем. Для этого используют различные нотации — системы условных обозначений. Они нужны для того, чтобы любой человек понимал, что изображено на схеме.
Одна из универсальных и самых наглядных нотаций — нотация BPMN (Business Process Model and Notation). Она в графическом виде отражает последовательность работ бизнес-процессов и логику их выполнения.

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

Другие материалы Skillbox Media для менеджеров

Научитесь: Профессия Бизнес-аналитик
Узнать больше

Источник

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

!!! Полезный материал! Статьи “Как внедрить бизнес-процессы за 2 дня”. Скачать >

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

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

Моделирование бизнес-процессов — это подробное описание деятельности компании.

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

Цели

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

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

Условно, моделирование всех бизнес-процессов можно подразделить на 3 основных этапа:

Первый начался в 20 году прошлого века с выходом в свет “Принципов научного управления” американского инженера Ф. Тейлора. Внедряется SADT – методология структурного анализа, объединяющая процесс моделирования с управлением конфигурацией проекта. Появляются наглядные блок-схемы и сети Петри. В 80-х гг. предпринимаются первые попытки автоматизации. Однако используемые методики несовершенны, так как допускают варианты интерпретации.

В 1990 М. Хаммер и Д. Чампи выпускают “Реинжиниринг корпорации: манифест революции в бизнесе”, которая до сих пор изучается во всех ведущих бизнес-школах мира. Рождается новый подход к моделированию. С этого момента строится две модели: одна описывает существующие процессы, вторая — оптимальные (как должно быть). Продолжаются работы по автоматизации. Основная задача — моделирование нестандартных бизнес-процессов, для чего требуется привлекать программистов и вкладывать средства. Если хотите подробнее узнать о реинжиниринге – читайте эту статью.

2000 гг. ознаменовались появлением работы Г. Смита и П. Фингара “Управление бизнес-процессами: третья волна”. Новый подход предполагает разработку инструментов, которые дадут возможность менеджерам предприятий не только вносить корректировки в схемы бизнес-процессов, но и самим их создавать.

Работа по усовершенствованию способов моделирования бизнес-процессов продолжается. Специалисты отмечают тенденцию к упорядочиванию и стандартизации.

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

Работа по моделированию бизнес-процессов включает в себя 5 этапов:

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

!!! Полезный материал! Статьи “Как внедрить бизнес-процессы за 2 дня”. Скачать >

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

Виды

Поскольку анализ схем, состоящих из большого числа элементов, затруднен, принято строить несколько моделей по видам:

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

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

Основных принципов пять:

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

Информационной достаточности. Моделирование реальных бизнес-процессов компании должно базироваться на реальных данных. Эффективность работы зависит от точности и полноты исходной информации.

Множественности. Для достижения требуемых показателей, необходимо разработать несколько моделей, чтобы описать бизнес-процессы в разных плоскостях (с разных сторон). Только всесторонний охват может привести к желаемому результату с минимальным количеством ошибок.

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

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

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

!!! Полезный материал! Статьи “Как внедрить бизнес-процессы за 2 дня”. Скачать >

Методы моделирования

Методов построения моделей довольно много, среди них:

IDEF — построенная на основе методологии SADT модель состоит из графических схем, облегчающих анализ системы.

DFD — используется при проектировании информационных систем. Показывает взаимосвязи между элементами, процесс передачи данных. Удобна для выявления причин изменени.

Flow Chart Diagram — метод моделирования бизнес-процессов посредством символов. Отличается гибкостью.

Сети Петри – показывают динамику изменения процессов.

Инструменты

AllFusion Process Modeler. Позволяет строить модели и производить анализ с использованием стандартных инструментов IDEF0, DFD и пр.
ELMA BPM. Позволяет отслеживать выполнение процессов в реальном времени. Для построения моделей используется нотация BPMN 2.0.
Draw io. Сервис позволяет строить огромное количество диаграмм и имеет большой набор элементов. Возможно связывать модели через гиперссылки. Кроме того, можно к элементам присоединять файлы из облачных хранилищ данных.

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

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

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

Значение моделирования бизнес-процессов для предприятий

Если работа проведена правильно, на выходе компания получит:

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

Как видим, правильное и осознанное моделирование бизнес-процессов только упрощает работу руководства и персонала компании.

!!! Полезный материал! Статьи “Как внедрить бизнес-процессы за 2 дня”. Скачать >

Автор: Марина Ступакова, эксперт компании iTeam

Источник