Нотации моделирования системы Business Studio. Методология BPMN - Учебная и научная деятельность Анисимова Владимира Викторовича Основное отличие моделей vad и epc
Модель AS-IS или модель «как есть» представляет собой модель бизнес-процессов на момент обследования предприятия и строится с целью понять, как функционирует данное предприятие с позиций системного анализа. Эта модель строится с целью выявления ошибок и узких мест, а также формулировки предложений по улучшению ситуации.
Во второй главе настоящего практикума при изучении методологий и технологий проектирования мы уже строили модель этого бизнес-процесса. Поэтому в этой части пособия мы только уточним эту модель, используя полученную в процессе сбора информацию.
Контекстная модель:
Название: Реализация готовой продукции со склада.
Цель: Увеличение продаж.
Точка зрения: Начальник отдела продаж.
Входные данные: копия накладной, копия договора, заказ.
Выходные данные: требование, счет, выписка из журнала, отчет, отказ от выполнения заказа.
Управление: номенклатура крепежных изделий, текущая цена крепежных изделий, устав предприятия, положение об отделе продаж.
Механизмы: сотрудник отдела продаж.
Контекстная модель представлена на рисунке 18.
Рис.18. Контекстная диаграмма
Перейдем к построению диаграммы декомпозиции. Обработав анкеты, мы можем идентифицировать основные функции: проверка готовности заказа, организация оплаты, организация выдачи, подготовка отчетов. Диаграмма декомпозиции представлена на рисунке 19.
Рис.19. Диаграмма декомпозиции
Проанализируем интервью и рассмотрим реальную технологию работ сотрудника отдела продаж. На основании этих данных можно декомпозировать основные функции. Основная функция «Проверка готовности заказа» может быть декомпозирована на следующие действия: выборка договоров на текущую дату, прием заказов на текущую дату, сверка с журналом готовой продукции. Декомпозиция представлена на рисунке 20.
Основную функцию «Организация оплаты» можно декомпозировать на следующие действия: подсчет суммы оплаты, выставление счета, оплата счета. Основную функцию «Организация выдачи» декомпозируем так: выписка требования, сообщение на склад о подготовке товара, подготовка выписки для отдела договоров, изменение в журнале продаж. Основную функцию «Подготовка отчетов» декомпозируем на такие действия: анализ данных, выборка данных, печать отчетов. Соответствующие диаграммы представлены на рисунке 21, 22, 23.
Рис.20. Диаграмма декомпозиции A1
Рис.21. Диаграмма декомпозиции A2
Рис.22. Диаграмма декомпозиции A3
Рис.23. Диаграмма декомпозиции A4
Поскольку перед проектировщиками поставлена цель автоматизации документооборота, то, прежде чем декомпозировать процессы, имеет смысл рассмотреть модель документооборота. При этом, можно пойти двумя путями: рассмотреть отдельную модель документооборота и декомпозировать отдельные бизнес-процессы с помощью построения DFD-диаграмм.
⇐ Предыдущая567891011121314Следующая ⇒
Похожая информация:
Поиск на сайте:
Нотация ARIS Value-added Chain Diagram (ARIS VAD)
На рис. 2.30 представлена одна из важнейших нотаций ARIS - нотация ARIS VAD. Диаграмма цепочки процесса, добавляющего ценность, используется при описании бизнес-процессов организации на верхнем уровне. Как правило, консультанты, использующие ARIS, рекомендуют выделять шесть-восемь бизнес-процессов верхнего уровня и описывать их в нотации ARIS VAD. Затем выполняется декомпозиция полученных процессов верхнего уровня в нотации ARIS VAD или ARIS еЕРС.
Модели AS-IS и ТО-ВЕ
Рассмотрим объекты нотации ARIS VAD, представленные на рис. 2.30.
Основным объектом нотации ARIS VAD является Value-added chain - процесс или некоторая группа функций организации, которая служит для получения добавленной ценности. Объекты соединяются между собой пунктирной стрелкой, которая имеет тип is predecessor of («является предшественником»). Этот тип связи показывает, что один процесс - предшественник другого. Очевидно, однако, что на практике все основные процессы цикличны. Кроме того, они имеют обратные связи. Поэтому термин is predecessor of, на наш взгляд, является неудачным.
Между процессами, приведенными на рис. 2.30, могут быть отображены потоки материальных ресурсов и информации, для описания которых можно воспользоваться объектами типа Cluster и Technical term, соответственно. Для описания инфраструктуры, необходимой для выполнения процесса, в данном примере выбраны типы объектов Product/Service и Information service. Выбор типов объектов для отображения реальных потоков является в достаточной степени условным. Очень важно в начале работ по моделированию процессов определиться, какие именно типы объектов будут использованы и какие объекты реального мира они будут отображать. Так, в случае примера, приведенного на рис. 2.30, можно было бы показать все потоки (информационные и материальные) при помощи объектов типа Technical term.
На рис. 2.30 показаны также объекты Organizational unit, отображающие подразделения, выполняющие соответствующие процессы.
Объекты соединяются между собой при помощи связей определенного типа (см. рис. 2.30). Например, информационный поток, отображаемый объектом Cluster, является входящим для первого процесса и связан с ним при помощи стрелки типа is input for («является входом для»). Другой пример - тип связи executes («исполняет») между объектами Value-added chain и Organizational unit. Тип связи is used by показывает, что Product/Service используется процессом и т.д. Таким образом, в методологии ARIS важнейшим требованием является корректный выбор и дальнейшее использование связей и объектов определенного типа.
На рис. 2.31 представлен пример модели верхнего уровня, выполненный в нотации ARIS VAD. Вы уже знакомы с этим процессов. Выше, на рис. 2.16, этот же процесс представлен в нотации IDEF0.
88____________________________ ВВ. Репин, В.Г. Елиферов
Глава 2 Выбор методологии описания бизнес-процессов________________________________ 89
Принципы построения диаграммы процесса верхнего уровня в нотации ARIS VAD существенно отличаются от нотации IDEF0. Так. в нотации ARIS VAD стрелки могут входить в любую сторону объекта Value-added chain. (Напомним, что в нотации IDEF0 каждая сторона объекта Activity (функция) имеет глубоки и смысл). На рис. 2.32 представлена ситуация, возможная в нотации ARIS VAD. когда на диаграмме процесса приводится множество обратных связей, которые понятны только аналитику, создавшему модель.
Указанный недостаток нотации ARIS VAD можно исключить, заранее оговорив возможность специального использования обратных связей, как, например, на рис. 2.33. Отметим, что у специалистов по ARIS такой подход может вызвать критику, так как противоречит нотации. Но мы придерживаемся той точки зрения, что это вполне допустимо, так как модели верхнего уровня в нотации ARIS VAD реально могут быть использованы лишь в качестве простейшего способа графического изображения цепочки процесса.
Заканчивая обзор нотации ARIS VAD, еще раз акцентируем внимание на том, что указанная нотация в большей степени носит иллюстративный характер и не предназначена для создания комплексных моделей процессов верхнего уровня организации.
90 В.В. Репин, В.Г. Елиферов. Процессный подход к управлению
2.7.2. Нотация ARIS еЕРС - расширение нотации IDEF3
Нотация ARIS еЕРС (extended Event Driven Process Chain) - расширенная цепочка процесса, управляемого событиями.
Нотация разработана специалистами компании IDS Scheer AG, Германия, в частности, профессором Шеером. В табл. 2.2 приводятся основные объекты, используемые в рамках нотации.
Таблица 2,2 Основные объекты, используемые при построении диаграмм еЕРС
Помимо основных объектов, указанных в табл. 2.2, при построении диаграммы еЕРС могут быть использованы многие другие объекты. На практике применение большого числа объектов различных типов нецелесообразно, так как это значительно увеличивает размер модели и затрудняет ее прочтение.
91
Для понимания смысла нотации ARJS сЕРС рассмотрим основные используемые типы объектов и связей (рис. 2.34-2.38). На рис. 2.34 представлена простейшая модель ARIS еЕРС, описывающая фрагмент бизнес-процесса предприятия.
Из рис. 2.34 видно, что связи между объектами имеют определенный смысл и отражают последовательность выполнения функций в рамках процесса. Стрелка, соединяющая Событие 1 и Функцию 1, «активирует» (activates) или инициирует выполнение Функции 1. Функция 1 «создает» (creates) Событие 2, за которым следует символ логического оператора «И», «запускающий» выполнение Функций 2 и 3.
Внимательный анализ нотации ARIS еЕРС показывает, что она практически не отличается от нотации IDEF3. Важнейшим отличием ARIS еЕРС является наличие объекта «событие» (event). Этот объект служит для отображения в модели возможных результатов выполнения функций, в зависимости от которых выполняется та или иная последующая ветвь процесса. Нотация ARIS еЕРС называется, очевидно, расширенной именно вследствие наличия в ней объекта «событие» (в IDEF3 такого объекта нет). На рис. 2.35 приводятся примеры применения символов логики и событий при построении моделей в нотации ARIS еЕРС.
При построении моделей в ARIS еЕРС необходимо соблюдать следующие правила:
1. Каждая функция должна быть инициирована событием и завершаться
событием;
2. В каждую функцию не может входить более одной стрелки, «запускаю
щей» ее выполнение, и выходить не более одной стрелки, описывающей
завершение выполнения функции.
Кроме этих правил, существуют и другие важные требования к формированию моделей в ARIS. Их можно изучить с помощью методического материала «Методы ARIS». который устанавливается на компьютер одновременно с демо-версией продукта, а также в .
На рис. 2.36 показано применение различных объектов нотации ARIS еЕРС при создании модели бизнес-процесса.
92____________________________ ВВ. Репин, В.Г. Елиферов. Процессный подход к управлению
Из рис. 2.35 и 2.36 видно, что бизнес-процесс в нотации ARIS еЕРС представляет собой последовательность процедур, расположенных в порядке их выполнения. Следует отметить, что реальная длительность выполнения процедур в ARIS еЕРС визуально отражена быть не может. Это приводит к тому, что при создании моделей возможны ситуации, когда на одного исполнителя будет возложено вы-
Глава 2 Выбор методологии описания бизнес-процессов___________________________________ 93
полнение двух задач одновременно. Используемые при построении модели СИМ-ЮЛЫ логики позволяют отразить ветачение и слияние бизнес-процесса. Для получения информации о реальной длительности процессов и визуального отображения загруженности персонала в процессе можно использовать другие инструменты описания, например диаграммы Гантта в системе MS Project.
Рассмотрим примеры применения нотации ARIS еЕРС для описания бизнес-процессов. На рис. 2.37. представлен бизнес-процесс обработки заказа клиента. Этот же процесс изображен в нотации IDEF3 на рис. 2.23.
Процесс начинается с события «Поступил заказ клиента». Это событие инициирует функцию «Выполнить учет заказа в системе», которую выполняет менеджер Отдела сбыта. Для выполнения работы он использует «Систему учета заказов». Результат выполнения функции отображается событием «Учет заказа выполнен». После этого менеджер Отдела сбыта выполняет функцию «Выполнить анализ на соответствие номенклатуре». Результатом выполнения функции являются два альтернативных события «Заказ соответствует номенклатуре» и «Заказ не соответствует номенклатуре». Процесс ветвится. Для отображения ветвления процесса используется символ логического оператора - исключающее «ИЛИ».
Функция «Уведомить клиента о невозможности выполнения заказа» может выполняться в двух случаях: 1) заказ не соответствует номенклатуре и 2) производство невозможно. Для отображения на схеме процесса этих вариантов используется символ логического оператора «ИЛИ» и т.д.
Как видно из рис. 2.37, схема процесса в ARIS еЕРС отличается от схемы в IDEF3 наличием объектов: событий, документов, прикладных систем и должностей. Схема в ARIS eEPS визуально предстаатяется более информативной и воспринимается лучше, однако размер этой схемы существенно превышает размер схемы в IDEF3.
Рассмотренный выше процесс может быть представлен также в нотации ARIS PCD (Process Chain Diagram) - разновидности ARIS еЕРС. На рис. 2.38 показан бизнес-процесс обработки заявки клиента в нотации ARIS PCD. При описании этого процесса использованы все объекты, которые составляют процесс, показанный на рис. 2.37, но расположены они в виде столбцов таблицы. В первом столбце представлены события и некоторые символы логики, во втором - функции, в третьем - входящие и исходящие документы, в четвертом - виды прикладного программного обеспечения, в пятом - должности сотрудников, задействованных в процессе. Такое представление процесса является более «стандартным». Оно лучше подходит для целей документирования процессов. Однако представление в нотации ARIS PCD обладает существенным недостатком - его можно эффективно применять для простых (не более пяти-восьми функций), желательно линейных, процессов. Сложные процессы с разветвленной логикой отображать при помощи нотаций ARIS PCD неудобно, что наглядно видно на рис. 2.38.
94_________________________________ ВВ. Репин. В.Г. Елиферов. Процессный подход к управлению
Рис. 2.37. Пример модели процесса
Глава 2 Выбор методологии описания бизнес-процессов_______________________________ 95
в нотации AR1S eEPC.
96____________________________ В.В, Репин, В.Г. Елиферов. Проц ессный подход к управлению
Рис. 2.38. Пример обработки
Глава 2 Выбор методологии описания бизнес-процессов 9 7
заявки и нотации AR1S PCD.
98 В.В. Репин, В Г. Елиферов Процессный подход к управлению
Нотация AR1S Organizational Chart
Нотация ARIS Organizational Chan яа!яется одной ИЗ основных нотаций ARIS и предназначена для построения схем организационной структуры предприятия. Как правило, эта модель строится в начале проекта по моделированию бизнес-процессов. В модели отражаются существующие подразделения предприятия в виде иерархической структуры, как показано на рис.
Модель строится из объектов Organizational unit, Position, Internal person и др.
Заложенные в нотацию типы связей позволяют отразить различные виды отношений между объектами организационной структуры. В представленном на рис. 2.39 примере Предприятие управляется Директором, при этом используется тип связи is Organization Manager for. Иерархия подразделений строится при помощи связей типа is composed of. Кроме того, могут быть указаны должности - Position и фамилии реальных сотрудников, их занимающие - Internal person, тип связи occupies.
Кроме моделей иерархии подразделений, могут быть построены модели иерархии подчиненности в проектных командах, группах и т.д. Все отраженные в моделях объекты можно использовать в дальнейшем при формировании моделей бизнес-процессов. При построении сложных иерархических структур может быть применена декомпозиция, например, структуру подразделения возможно представить более детально.
Глава 2 Выбор методологии описания бизнес-процессов_________________________________ 99
Предыдущая78910111213141516171819202122Следующая
Модель AS-IS
– это модель «как есть», т.е. модель уже существующего процесса/функции. Обследование процессов является обязательной частью любого проекта создания или развития системы. Построение функциональной модели AS-IS позволяет четко зафиксировать, какие процессы осуществляются на предприятии, какие информационные объекты используются при выполнении функций различного уровня детализации.
На основе модели AS-IS
достигается консенсус между различными этапами процесса по тому, «кто что сделал» и что каждый этап добавляет в процесс. Функциональная модель AS-IS является отправной точкой для анализа потребностей предприятия
, выявления проблем и “узких” мест и разработки проекта совершенствования деловых процессов. Модель AS-IS позволяет выяснить, «что и как мы делаем сейчас» перед тем, как определить то, «что и как будет делаться завтра». Анализ функциональной модели AS-IS позволяет понять, где находится проблемная ситуация, в чем будут состоять преимущества новых процессов и каким изменениям подвергнется существующая структура организации процесса. Исследование необходимости реструктуризации
(выявление и ликвидация недостатков) в существующих процессах достигается за счет применения декомпозиции (анализа), производящаяся даже там, где функциональность на первый взгляд является очевидной.
Функциональная модель AS-IS
Так, например, признаками неэффективности существующих процессов могут быть:
- бесполезные, неуправляемые и дублирующиеся функции;
- неэффективный документооборот (нужный документ не оказывается в нужном месте в нужное время);
- отсутствие обратных связей по управлению (на проведение функции не оказывает влияния ее результат), входу (объекты или информация используются нерационально) и т. д.
При создании модели AS-IS неопытным аналитиком может возникать достаточно распространенная ошибка — это создание идеализированной модели, особенно в том случае, когда модель создается под влиянием знаний (точки зрения) руководителя. Обычно руководитель знаком с тем, как предполагается выполнение функции по руководствам и должностным инструкциям и часто не знает, как на самом деле подчиненные выполняют требуемые функции. Поэтому могут создаваться модели, называемые SHOULD BE (как должно бы быть), и несущие ложную информацию и которую невозможно в дальнейшем использовать для анализа.
BPMN (Business Process Management Notation) – это язык моделирования бизнес-процессов, который является промежуточным звеном между формализацией/визуализацией и воплощением бизнес-процесса.
Говоря проще, такая нотация представляет собой описание графических элементов, используемых для построения схемы протекания бизнес-процесса.
Как минимум, такая схема нужна, чтобы выстроить в соответствии с ней бизнес процесс и понятно регламентировать его для всех участников.
Как максимум, позволяет впоследствии провести автоматизацию бизнес-процессов в соответствии с имеющейся схемой.
История возникновения BPMN
Первая версия нотации BPMN вышла в мае 2004 года (BPMN 1.0). Следующая версия появилась в январе 2011 года (BPMN 2.0). Наконец, в январе 2013 года компания OMG выпустила ту версию, которая в основном используется и сегодня – BPMN 2.0.2.Основные графические элементы BPMN
BPMN-процесс – это любой бизнес-процесс, отражённый с помощью нотации. Процессы состоят из элементов, каждый из которых обозначается на схеме специальным значком.Элементы нотации BPMN – это элементы графической схемы, но также и элементы самого бизнес-процесса.
Нотация опирается на следующие базовые графические элементы:
- Пул и Дорожки
- Действия
- Шлюзы или Развилки
- События
- Потоки
- Артефакты
BPMN элементы “Пул” и “Дорожка”
Весь бизнес-процесс состоит из пулов: совокупности операций + лиц, которые эти операции выполняют.
Например, пулом окажется весь набор действий по погрузке товара и отправке его клиенту.
При этом выделяют так называемые “дорожки”, из которых состоит любой пул. Для нашего примера одной из дорожек станет оформление документов, касающихся погрузки и отправки товара, второй дорожкой – физическая погрузка нужной партии на автомобиль и поездка автомобиля к клиенту. Обе эти дорожки дополняют одна другую, проходят параллельно, но в целом служат выполнению одного и того же этапа бизнес-процесса.
BPMN элемент “Действие”
Под “действием” понимается единица работы, выполняемой в ходе исполнения бизнес-процесса. Действия могут быть как элементарными (задача/task), так и составными (подпроцесс/sub-process).
Есть несколько типов элементарных действий, которые отличаются условиями выполнения:
- Многократное выполнение действия в рамках одного процесса. Например, одно и то же действие может выполняться параллельно для каждого товара в заказе клиента.
- Циклическое действие выполняется многократно, пока заданное условие верно.
Абстрактная задача | Используется для обозначения простого действия или операции, не имеющей дальнейшей декомпозиции в рамках текущего бизнес-процесса. | |
Подпроцесс | Используется для отображения декомпозированного процесса, включенного в состав рассматриваемого процесса. Подпроцесс описан более подробно на своей диаграмме. | |
Процесс-ссылка | Используется для обозначения ссылки на один из наиболее часто повторяющихся процессов. |
Пользовательская задача | Используется для отображения задачи, которую выполняет человек. | |
Задача на выполнение сценария | Используется для отображения шага процесса, по достижении которого автоматически выполняется скрипт. | |
Задача на вызов сервиса | Используется для иллюстрации шага процесса, на котором вызывается веб-служба или скрипт С#. | |
Встроенный кейс | Используется для представления нестандартной задачи, курируемой ответственным лицом или группой лиц. Кейсы используются, когда нужно быстро организовать в рамках процесса неструктурированную или слабоструктурированную активность. |
BPMN элементы “Развилка” или “Шлюз”
Под шлюзами понимаются элементы, определяющие ветвление и слияние потоков работ.BPMN описывает 7 типов развилок. В качестве основных выделяют 2 типа:
Шлюз исключающего «или» | Используется для создания альтернативных потоков процесса или сходящихся потоков управления. | |
Параллельный шлюз | Используется для создания параллельных путей без оценки какого бы то ни было условия или для сходящихся потоков и синхронизации параллельных веток выполнения процесса. |
Пример использования шлюза исключающего «или» для создания альтернативных потоков процесса:
- Этап 7. Звонок клиенту с целью оценить качество обслуживания.
- 1. Если клиент доволен, фиксация положительной оценки, закрытие бизнес-процесса.
- 2. Если клиент недоволен, выяснение причины.
Фактически, шлюзы являются одними из самых ответственных и сложных этапов бизнес-процессов. От того, насколько грамотно будут прописаны все условия и следствия по принципу “Если… то”, во многом зависит эффективность работы всей системы.
BPMN элемент “Событие”
“Событие” является одним из главных элементов BPMN и служит для описания того, что должно случиться (в отличие от задачи, когда что-то должно быть сделано). Событием может быть, например, подписание договора, или разговор с клиентом.
Графические элементы событий в BPMN классифицируют двумя способами:
- В зависимости от положения события на схеме процесса:
Начальное событие (инициирующее бизнес-процесс) | |
Промежуточное событие | |
Конечное событие (заканчивающее бизнес-процесс). |
- По типу события классификация следующая:
Простое событие | Представляет не типизированное событие. | |
Событие-сообщение | Показывает отправку или получение сообщения. | |
Событие-таймер | Используется для моделирования регулярных событий. Также таймер может использоваться для моделирования моментов времени, временных промежутков и превышения лимита времени. |
BPMN элементы “Потоки”
Поток – это последовательность действий, которая обозначается стрелкой. Элемент “поток” показывает какое действие после какого необходимо совершить.Поток управления | На стандартный поток управления не воздействуют условия и он не проходит через шлюзы, т.е. является неконтролируемым. | |
Условный поток управления | Используется для того, чтобы показать, что дальнейшее выполнение процесса будет происходить по определённому потоку только в том случае, если выполнятся заданное условие. Ромбик у основания стрелки добавляется, если условный поток управления является исходящим от процесса. Ромбик не добавляется, если условный поток управления является исходящим от шлюза. | |
Поток управления по умолчанию | Используется тогда, когда необходимо показать, что дальнейшее выполнение процесса будет происходить по определённому потоку только если не выполняется ни одно из заданных условий. | |
Поток сообщений | Используется для отображения межпроцессного взаимодействия – отображает передачу сообщений или объектов из одного процесса в другой процесс или внешнюю ссылку. | |
Ассоциация | Применяется для визуализации связи между элементами потока и объектами, не являющимися элементами потока (артефактами). |
BPMN элементы “Артефакт”
Под артефактами в BPMN понимают объекты, которые не влияют на исполнение бизнес-процесса напрямую. Это могут быть документы, данные, информация.Основные виды артефактов:
Группа объектов | Используется для группировки графических элементов, принадлежащих одной и той же категории и позволяет повысить простоту восприятия диаграммы. | |
Текстовая аннотация | Применяется для уточнений к диаграмме – комментариев и пояснений, которые увеличат читабельность диаграммы. | |
Объект данных | Используется для отображения информации о данных, которые обрабатывается в ходе процесса. |
Преимущества BPMN
BPMN-описание бизнес процесса имеет несколько преимуществ.Первое – простота трансляции диаграмм в исполняемые модели с помощью языка формального описания бизнес-процессов.
Описание элементов BPMN является понятным для большинства участников бизнес-процессов и часто не требует никаких дополнительных разъяснений. С помощью простого графического выражения можно составить конкретные регламенты, которые будут исполняться сотрудниками.
Наряду с тем, что описание нотации BPMN 2.0 позволяет добиться понимания сотрудниками того, как происходят бизнес-процессы, данную нотацию поддерживают большинство современных инструментов бизнес-моделирования, что позволяет импорт готовых схем бизнес-процессов в BPM-системы.
Елена Гайдукова, маркетолог-аналитик, бренд-менеджер решений на базе , специалист по партнёрским отношениям.
Процессным подходом к организации бизнеса мир занимается уже давно и достаточно эффективно, и стандарт Business Process Model and Notation (BPMN, нотация) является процедурой продуманной с правильным описанием бизнес-процессов. Компании постоянно совершенствуют разные специализации данного стандарта и тем самым добиваются весьма существенного повышения всех качественных показателей своей работы. Нотация BPMN понятна не только для экспертов той предметной области, в которой она создавалась, её логическими выкладками может оперировать любой работник.
Моделирование и стандартизация
Одновременно с простотой эта стандартизация является наиболее полной моделью описываемого бизнес-процесса, составленной в машиночитаемой форме. BPMN (если рассматривать её в версии нотации BPMN 2.0) выстраивает модели самых сложных процессов в бизнесе очень мощно и выразительно, причём в наиболее понятной системе. Самое важное то, что вместе с этим стандартом определяются графические модели и преобразуются в прекрасно структурированную и легко читаемую машиной форму, которая основана на XML. Язык BPMN-нотации абсолютно исполняем, то есть он позволяет моделировать процессы, в дальнейшем выполняемые посредством BPMS (автоматизированные системы управления бизнес-процессами). Такая стандартизация чрезвычайно полезна именно тем, что разработчики моделей могут пользоваться одними программными продуктами, а исполнители - другими, если ими поддерживается данный стандарт.
Для построения определённой модели может использоваться не одна версия (нотация BPMN 2.0 (PDF) и другие), иногда модель составляется из фрагментов разных нотаций, но способ их систематизации и прочтения один и тот же. Всё большее количество предпринимателей внедряют в своих компаниях опирающееся на данный стандарт выполнение бизнес-процессов. Растёт с каждым днём востребованность специалистов, которые владеют этим языком моделирования. Всё большее количество людей занято изучением графических элементов нотации BPMN и правил построения моделей. Для этого существуют специальные курсы, где желающие познакомятся с назначением этого языка, с видами диаграмм, увидят возможности автоматического выполнения построенных моделей. Самое интересное - практический опыт в нотации BPMN 2.0 (на русском языке тоже есть), моделирование и проведение анализа, разработка бизнес-процесса.
Специалисты
Кто способен заниматься описанием бизнес-процессов? BPMN-нотация моделирования легко выполняется всеми, кто связан с автоматизацией, разработкой бизнес-процессов. руководители проектов, системные аналитики, архитекторы и разработчики компьютерных систем, методологи, работники служб качества. Обычно эти люди умеют читать техническую документацию по-английски, участвовали в каких-либо проектах по анализу, по описанию BPMN-нотации, оптимизировали или автоматизировали бизнес-проекты или разрабатывали, сопровождали программное обеспечение. Эта методология имеет международный статус, а не фирменный, как многие другие стандарты, и даже не национальный. Именно поэтому с 2005 года анализируют и реорганизуют бизнес с помощью моделирования процессов в нотации BPMN.
Эта методика обеспечила доступной информацией практически всех пользователей - от самых крупных аналитиков, которые создают схемы, и разработчиков, внедряющих технологии выполнения бизнес-процессов по этим схемам, до руководителей компаний, то есть обычных пользователей, которые заняты управлением и отслеживанием выполнения построенной модели. Таким образом, нотации моделирования бизнес-процессов (BPMN) устраняют расхождение между созданием модели и её реализацией. Здесь собраны лучшие идеи, имеющиеся в других методологиях. Например, для лучшей гибкости и читабельности в нотации BPMN 2.0 ведётся в традициях блок-схем.
Символы (элементы) BPMN
Поддерживает и развивает BPMN организация OMG. Это не мем интернетных завсегдатаев, обозначающий "о майн гот", а весьма знаменитая фирма Object Management Group, в которой участвуют более восьмисот компаний, разрабатывающих стандарты, подобные BPMN-нотации. Всеми полезными изменениями в новых версиях мы обязаны разработчикам OMG. Именно эта организация выбрала ключевым направлением продвижение нотации UML BPMN, с помощью которой моделируются объектно-ориентированные системы. А потому при разработке диаграмм помимо концепций и понятий (поток управления, действие, объект данных и тому подобное) в BPMN много понятий, характерных для подхода объектно-ориентированного: сообщение, обмен и поток сообщений.
Символы графической нотации разобраны по назначению и объединяются в категории. Objects - объекты потока, Data - данные, Swimlanes - зоны ответственности, Connecting Objects - соединяющие объекты, Artifacts - артефакты. Поток управления, объект данных и символы объектов потока дополнительно разделяются на подгруппы по семантическому признаку, чтобы отобразить специфику происходящих событий, особенности ветвления потоков, выполнение действий и так далее. Указывают специфику за счёт дополнительных графических изображений - маркеры, иконки, помещённые внутри главного символа. Также символы событий бывают с разным видом контура и фоновым цветом.
События по времени
В ходе выполнения бизнес-процесса всегда происходят самые разные и многочисленные события, которые оказывают своё влияние, несмотря на то что чаще всего являются элементами необязательными и не отображены в диаграмме бизнес-процесса. Это получение и ответ на сообщение, смена статуса в документах и многое другое, что перечислять нет смысла - множество событий происходит буквально на каждом шагу. Чтобы их классифицировать, определяются признаки каждого. Первая группа - по времени наступления. Это стартовое событие, которое покажет начало диаграммы. Отсюда поток управления может быть только исходящим, а поток сообщений - идти в обе стороны. Стартовое событие на диаграмме бизнес-процесса обычно одно, но можно его не отображать вообще. Иногда их даже несколько, если отображение происходит с дорожками, пулами и развёрнутыми подпроцессами. Контур события изображается тонкой одинарной линией.
Конечное событие - результат выполнения бизнес-процесса. Сюда поток управления только входит, а поток сообщений всё так же движется и на вход, и на выход. Входящий поток изображается стрелкой. Диаграмма отображает только одно конечное событие или несколько - они обведены контуром в виде жирной одинарной линии. Промежуточное событие - это любое из остальных, которые возникают во время выполнения бизнес-процесса. Сюда входит один поток и выходит тоже один. Только Boundary (граничное событие) возникает и обрабатывается сразу - либо в самом начале, либо в конце действия. Отображается оно на контуре (границе) действия, и содержит только один поток - либо входящий, либо выходящий. А обозначается такое событие тонкой двойной линией.
События: прерывание подпроцесса и тип результата
Поскольку события во время моделирования бизнес-процесса происходят самые разные, следующим блоком были классифицированы те, которые способны прервать выполнение действия. Первыми отмечены непрерывающие события - это промежуточное или стартовое, которое возникает по ходу выполнения, однако инициирует исходящий поток, связанный с ним, только когда действие завершается. Контур такого события изображён штриховой линией. Далее - прерывающее событие, которое возникает до стандартного действия или после него. В исключительных ситуациях это событие требует остановки или прекращения действия, если отсутствует необходимая информация или показывается ошибка в ходе обработки, если появляется необходимость дополнительных действий и тому подобное. Здесь контур отображён сплошной линией.
Третий вид событий классифицирован согласно типу результата. Прежде всего здесь нужно говорить об инициаторе обработки. Это промежуточное или стартовое событие, которое возникает как результат выполнения действий и является итогом выполнения процесса - стандартного или нет. Событие-инициатор изображено незакрашенной иконкой. Необходимо внести в этот раздел ещё одно событие, тоже говорящее о результативности, только здесь им является результат обработки. Это промежуточное или конечное событие, возникающее в ходе выполнения действий и являющееся одним из итоговых результатов выполнения процесса - стандартного или нет, отображено оно закрашенной иконкой.
Действия
Изображаемый в виде диаграммы процесс выглядит упорядоченным набором действий, которые выполняются для получения определённого результата. На вертикальной диаграмме нотации BPMN сверху вниз задаётся последовательность, показывающая выполнение процесса по времени. Также можно проследить её по направлению стрелок соединяющих элементов слева направо. У отображаемых действий есть три главных вида и много разновидностей, каждое из которых имеет собственную иконку или значок.
Task - задача. Элементарное действие, то есть неделимое. Разновидность или специфика задачи отображается маркером или иконкой в верхнем углу слева на символе действия. Задача может быть Service (сервисная), для оказания услуги, являющейся автоматизированным приложением или веб-сервисом. Send - отправка сообщения. Если хотя бы единожды сообщение отправлено, задача может считаться выполненной. Receive - получение сообщения (тот же принцип: если единожды получено сообщение, задача выполнена). Задача User - пользователя, считается характерной, выполняется исполнителем при помощи программного обеспечения и содействии других сотрудников. Задача, требующая ручного исполнения, - Manual, которая исполняется без помощи автоматизации. Business-Rule - бизнес-правило, по технологии выполнение этой задачи зависит от обстоятельств, выбрать способ помогает заданность бизнес-правила. Script - сценарий, где выполнение операций строго по порядку, описанному на распознаваемом исполнителем языке. Обычно этот вид задач выполняется автоматическими средствами.
Подпроцессы
Sub-Process - подпроцесс. Он включает в себя шлюзы в нотации BPMN, потоки операций, события и много других действий. Таким образом, подпроцесс является составным действием, части которого непосредственно отображаются внутри символа на диаграмме или же выносятся на отдельную декомпозиционную диаграмму. В последнем случае на главной диаграмме в центре подпроцесса (нижний край действия) должен отображаться знак +. Есть стандартные подпроцессы, но их недостаточно, поэтому и появились две его специфические разновидности. Это Event Sub-Process - событийный подпроцесс, который запускается всегда при появлении стартового события. Диаграмма показывает его никак не связанным с остальными действиями и потоками операций. Контур такого подпроцесса изображён точками.
Вторая разновидность - Transaction (транзакция), это состоящее из разных операций действие с удачным завершением, то есть получением положительного результата. Получить конкретный результат можно только при условии удачного завершения абсолютно всех составляющих. Если же возникают проблемы по ходу выполнения подпроцесса, результаты всех предыдущих операций будут отменены (отмена события). Такими помехами могут стать невозможность выполнения той или иной операции или некорректное выполнение её. Чтобы не отменять предыдущие события, можно попробовать неудавшуюся операцию компенсировать (компенсация события). Контур такого подпроцесса отображён двойной сплошной линией. Для включения в диаграмму всех задач или подпроцессов, используемых повторно, существует Call - вызов, который на диаграмме обозначен жирным контуром.
Шлюзы
Шлюзы в нотации BPMN предназначены для того, чтобы указывать специфику потока операций и их пропуска по параллельным или альтернативным ветвям. Шлюз может обходиться без исходящих или входящих потоков, но всегда имеет как минимум два собственных либо входящих потока, либо исходящих. Маркер внутри его символа задаёт тип шлюза. Это может быть Exclusive, XOR - эксклюзивный с исключающим "или", предназначенный для разделения потока на альтернативные маршруты. По ходу выполнения процесса активирован может быть только один из предлагаемых маршрутов. Условия пропуска содержатся рядом с обозначающей линией. Inclusive, OR - неэксклюзивный с логическим "или" шлюз, предназначенный для разделения потока на маршруты, где активируется каждый, если соблюдено условие истинности логического выражения, связанного с ним. В этом процессе можно выполнять несколько маршрутов, но если хоть в одном отсутствует истинность, то выбор невозможен.
Аналог неэксклюзивного шлюза - Complex (комплексный). Отличие в том, что определяющее активизацию того или иного потока операций выражение только одно. Parallel, AND - параллельный с логическим "и" шлюз нужен для ветвления или слияния параллельно выполняемых операций. Exclusive Event-Based - шлюз эксклюзивный, но основанный на событиях, разделяющих поток операций на альтернативные маршруты. Exclusive Event-Based Gateway to start a Process - тоже эксклюзивный шлюз, события, на которых он основан, запускают весь процесс. Это начальный символ процесса или подпроцесса, входящих потоков не имеет. Таким же образом работает и Parallel Event-Based Gateway to start a Process - шлюз параллельный, также основанный на запускающих процесс событиях. Однако при его помощи можно активировать несколько процессов одновременно, если события, связанные с ними, сработают. Входящих потоков, естественно, не имеет. На картинках ясно видна нотация BPMN в примерах построения диаграмм с двумя видами шлюзов.
Данные и потоки
Объект данных содержится и используется в диаграммах специфически, что демонстрирует применение дополнительных маркеров. Data Inputs - входные данные, то есть исходная информация для того, чтобы начать выполнение действий. Изображается на верхнем крае символа. Data Collection - набор данных, то есть целый массив или коллекция данных одного типа. Отображено снизу символа. Объект данных и действия объединены связью с помощью ассоциации.
Стандартное изображение потока операций может быть дополнено в диаграмме указанием специфических потоков. Conditional Sequence Flow - обозначение условного потока операций при ветвлении его. Отображён исходящим из действия (если нет желания использовать в диаграмме шлюз). Default Sequence Flow - поток операций, совершающийся по умолчанию, чаще всего исходит из шлюза или действия, с логическими выражениями не связан.
Примеры и выводы
Стартовое событие, как можно заключить из названия, указывает на точку начала того или иного процесса. Это отправная начальная точка, что значит отсутствие любого вида входящего потока. Стартовое событие в примерах нотации BPMN обозначается кругом, в котором центр свободен. Таким событием может стать письмо или звонок от клиента, например, направленный в интернет-магазин или на сайт компании, которая моделирует данный бизнес-процесс. Далее поток операций идёт по линиям и обозначает выполнение процесса вплоть до красного кружка, который обозначает завершение, конечное событие. Их, кстати, может быть и несколько, и легко проследить, где именно поток операций пришёл к концу, завершив процесс. Никакой исходящий поток из красного кружка невозможен.
Если диаграмма составляется не в цвете, то конечное событие выделяется жирной линией в форме круга. Например, на практике это событие может быть выдачей заказанного товара, который прошёл весь путь от оформления через обработку до выдачи. По ходу всей этой работы диаграмма показывает действия, которые производились на пути от стартового до конечного события. Действие обозначается прямоугольником с закруглёнными краями. Шлюзы - ромбами. Этот язык понятен пользователям, стоит лишь слегка ознакомиться с системой отображений, которая присутствует здесь в иллюстрациях.
«В какой нотации нам лучше строить свои бизнес-процессы? » — довольно частый и один из самых странных вопросов, которые мне приходилось слышать. Дело в том, что выбор нотации для бизнес-моделирования целиком и полностью зависит от целей и задач предприятия, которое решило перейти к процессному управлению.
Ещё раз об IDEF0
Именно нотация IDEF0 до сих пор остаётся горячо любимой среди консультантов и бизнес-аналитиков. Большинство семинаров и тренингов по процессному управлению сегодня проводятся на базе данной нотации, хотя лично я своё мнение по этому поводу уже высказал в статье « ».
IDEF0 хорошо подходит для построения процессов верхнего уровня, то есть для отображения логического взаимодействия между работами. При этом диаграмму можно декомпозировать, то есть каждый отдельный элемент можно представить в виде новой схемы взаимодействий, детализирующих выбранный блок. Благодаря отображению на диаграмме не только входов и выходов, но и «управления» и «механизма», существуют возможность проследить за движением и преобразованием ресурсов в ваших процессах.
К сожалению многие бизнес-консультанты не осознают, что при всех достоинствах IDEF0 её неразумно использовать для построения процессов нижнего уровня, детализирующих подробное выполнение работ персоналом (WorkFlow). Во-первых, нотация IDEF0 не способна отобразить временную последовательность выполнения работ, а во-вторых, не содержит блоков условного перехода, поэтому все процессы будут описывать работы лишь линейно, и недостаточно детализировано.
Вывод: нотация IDEF0 подходит для построения процессов верхнего уровня, с целью отображения взаимодействий между подразделениями и движения ресурсов.
BPMN – новый взгляд на процессы
BPMN – относительно новая нотация, первая версия которой появилась в 2005 году. Нотация ориентирована на детальное описание потоков работ, и наилучшим образом подходит для моделирования процессов на нижнем уровне. Нотация BPMN обладает одной ключевой особенностью — все диаграммы, построенные с соблюдением спецификации BPMN могут быть «выполнены» системой в режиме реального времени.
При выполнении процесса, создаётся его «экземпляр» и руководитель или владелец процесса может в реальном масштабе времени контролировать выполнение задач.
Возможность «выполнения» процессов сервером требует достаточно высокой квалификации специалиста по моделированию процессов и достаточной детализации процесса. Например, если бизнес-аналитик не предусмотрел соответствующего перехода или возможности возврата к предыдущей функции, то на определенном этапе процесс может «застопорится» и не выполнится, что приведёт к необходимости внесения изменений в процесс и повторного его запуска.
При всех её достоинствах нотация BPMN достаточно сложна для использования в целях регламентации, например, для описания всех функций персонала с целью анализа и генерации должностных инструкций, положений о подразделении и регламентов процессов.
Вывод: нотация BPMN наилучшим образом подходит для моделирования лишь ключевых процессов предприятия, для дальнейшего контроля их исполнения в реальном масштабе времени.
FlowChart – назад к основам
На самом деле нотации с таким названием не существует, имеется множество вариаций на тему обычной блок-схемы, например, Basic FlowChart, Сross Functional Flowchart и т.д.. Все эти нотации позволяют описывать потоки работ и распределять ответственность за выполняемые функции внутри процесса. Множество программных продуктов используют разновидности этих нотаций для описания процессов нижнего уровня в дополнение к описанию процессов верхнего уровня при помощи IDEF0.
Специалисты по бизнес-моделированию могут сами определять степень детализации подобных диаграмм, жестких требований к описанию схем процессов не существует, так как данные диаграммы не предназначены для исполнения системой в масштабе реального времени.
Очень часто данные нотации применяются в специализированных системах бизнес-моделирования для построения единой цельной процессной модели предприятия с привязкой к организационной структуре. Разработчики ПО также часто вводят дополнительные блоки для обозначения ресурсов, документов и т.д.
Вывод: простота моделирования процессов в нотациях FlowChart делает их идеальными кандидатами на использование в системах бизнес-моделирования с целью дальнейшей автоматической генерации регламентирующей документации: должностных инструкций, положений, регламентов.
eEPC – мы пойдём своим путём
Авторами нотации eEPC является известная немецкая фирма IDS Scheer AG. Как и нотации на базе FlowChart, eEPC предназначена для описания процессов нижнего уровня, вот только в основе неё лежат не функции персонала, а события, которые в свою очередь уже инициируют выполнение какого-либо действия со стороны персонала. Из-за данной особенности стандартные процессы получаются почти в два раза больше по сравнению с их аналогами, описанными в нотации FlowChart.
Функциональность нотации eEPC является избыточной для среднестатистического пользователя, использовать все доступные блоки не имеет смысла, поэтому, как правило, при разработке процессной модели в нотации eEPC пользователи предварительно составляют специальный документ (соглашение о моделировании), в котором заранее оговаривают, какие блоки будут использоваться в процессной модели предприятия.
Вывод: нотация eEPC может применяться для построения процессов нижнего уровня, если по каким-либо причинам более простая в использовании нотация FlowChart не удовлетворяет требований предприятия к глубине описания модели.
Разумеется, данная заметка не презентует на полноту изложения и не раскрывает особенности использования каждой нотации в отдельности, зато надеюсь, что после прочтения данной статьи, вопросов в стиле «Что нам выбрать BPMN или IDEF0? » станет меньше.
3.2. Нотации создания бизнес процессов
Модель - это отображение, какого либо процесса, создаваемое для решения задач. Для создания моделей используются специализированные языки, такие как графика, схемы, таблицы или текстовые описание и называются «нотацией» описания бизнес процесса.
Под методологией (нотацией) создания модели (описания) бизнес-процесса понимается совокупность способов, при помощи которых объекты реального мира и связи между ними представляются в виде модели. Для каждого объекта и связей характерны ряд параметров (атрибутов) отражающих определенные характеристики реального объекта (номер объекта, название, описание, длительность выполнения (для функций), стоимость и др.).
Модель бизнес-процесса - прикладное представление (в заданной нотации) исполняемых предприятием работ.
В практике деятельности предприятий применяются модели разной направленности:
модель бизнес-процессов верхнего уровня - агрегированная, наиболее общая модель бизнес-процесса предприятия;
модель бизнес-процесса алгоритмическая, отражающая состав и логику выполнения предприятием работ при его реализации;
модель бизнес-процесса потоковая, отражающая материальные, финансовые и информационные потоки объектов;
модель бизнес-процесса функциональная, отражающая функциональный состав бизнес-процесса, закрепление функций процесса за исполнителями.
В современных условиях модели стали рассматриваться как новый вид регламентационных документов. В тех случаях, когда модель разрабатывается с помощью специальной программы, ее применяют как электронный регламент. А в части применения подобных моделей стала развиваться специальная методология - бизнес-инжиниринг.
Формы описания бизнес-процесса:
текстовая;
табличная;
алгоритмическая.
Для детализации процесса текстовое описание дополняется описанием в виде таблицы или алгоритмической схемы.
Применение табличной формы (рис.3.2) делает описание процесса четким и упрощает его восприятие. Каждый параметр процесса отражается в отведенном столбце таблицы, а не «размывается» в тексте.
Описание бизнес-процесса |
Ответственный исполнитель |
Входная информация |
Срок исполнения |
Исходящая документация результат |
Потребитель результата бизнес-процесса |
Рис. 3.2. Пример табличного представления бизнес-процесса
Использование алгоритмических схем (рис. 3.3; 3.4) целесообразно в случаях, когда последовательность выполнения бизнес-процесса (подпроцессов, процедур) допускает вариантность исполнения (последовательное выполнение сочетается с параллельным, ветвление процесса и т. д.). Алгоритмические схемы призваны отобразить логическую связь процессов, к тому же они более наглядные и «читаемые».
Использовать исключительно одну форму - текстовую, табличную или алгоритмическую - нецелесообразно. Текстовая форма не столь наглядная и не структурированная, в табличной трудно отразить логическую и временную взаимосвязь процессов и поэтому трудно обойтись без алгоритмической схемы.
Если применять только алгоритмическую схему, на ней необходимо будет указать все существенные параметры процесса - исполнителей, входы, выходы, поставщиков, клиентов и т. д. В результате схема получится громоздкой и «трудночитаемой», что снизит ее практическую ценность.
Для составления алгоритмических схем используют специальные графические элементы (рис. 3.5), совокупность которых определяет нотацию моделирования. Наиболее популярными для описания бизнес-процессов являются: алгоритмическая блок-схема, Basic Flowchart, Cross-Functional Flowchart, Event-driven Process Chain,
IDEFO, 1DEF3, Data Flow Diagrams, Work Flow Diagram. Выбор нотации моделирования зависит от его целей и от программного продукта, применяемого для этого. Обычно используют 3^1 и более нотаций.
Наиболее распространенные нотации детализации (способы описания бизнес-процессов) - это представление процессов как алгоритмов в виде блок-схем и описание процесса в виде потока объектов. Под потоком объектов понимается информация, документы, другие ресурсы.
Популярное
- Виды организационно-правовых форм
- Обоснование доходов торговой организации на перспективу Экономическое обоснование доходов
- Основные правила делового этикета
- Веб-комиксы как способ заработка
- Сэд "корпоративный документооборот" Всё включено или внедрение в короткие сроки
- Как рассчитывается маржа: отличия между наценкой и маржей
- Чем отличаются земли ИЖС, СНТ, ДНП: в чем разница и что выбрать Что означает участок снт днп
- Новая почта - отследить посылку
- Нюансы отказа от посылки наложенным платежом, если прислали не тот товар
- Изменение графика смен без согласия