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

2. Определить какой тип модели бизнес процесса вам необходимо построить и выбрать список методологий, которые могут быть использованы при моделировании (используйте путеводитель, описанный ниже);

3. Сравнить методологии и нотации моделирования для вашего типа модели и выбрать подходящую для вас методологию:

• Методологии моделирования бизнес процессов верхнего уровня и потоков данных;
• Методологии моделирования потоков работ;
• Методологии моделирования структуры информации.

4. Построить модель.

Путеводитель по нотациям и методологиям

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

Классические методологии

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

8.8. Методология BPMN

Модель и нотация бизнес-процессов (BPMN, Business Process Model and Notation) – методология моделирования, анализа и реорганизации бизнес-процессов. Разработана Business Process Management Initiative (BPMI), с 2005 г. поддерживается и развивается Object Management Group (OMG) . В отличие от других методологий бизнес-моделирования, имеющих статус «фирменного» () или «национального» () стандарта, BPMN получила «международный» статус – Международная организация по стандартизации опубликовала стандарт «ISO/IEC 19510:2013. Information technology - Object Management Group. Business Process Model and Notation».

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

По заявлению разработчиков стандарта BPMN, он вобрал в себя лучшие идеи, что имеются в следующих нотациях и методологиях моделирования:

o EDOC (Enterprise Distributed Object Computing, корпоративная распределенная обработка объектов) – Business Processes (бизнес-процессы);

EbXML (Electronic Business eXtensible Markup Language, расширяемый язык разметки для электронного бизнеса) BPSS (Business Process Specification Schema, схемы спецификации бизнес-процессов);

ADF (Activity-Decision Flow, поток «деятельность-результат») Diagram;

LOVEM (Line of Visibility Engineering Methodology, визуальная методология проектирования);

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

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

Элементы (символы) графической нотации BPMN по назначению объединены в категории:

Объекты потока (Flow Objects);

Данные (Data);

Зоны ответственности (Swimlanes);

Соединяющие элементы (Connecting Objects);

Артефакты (Artifacts).

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

Таблица 8.3. Условные обозначения на BPMN-диаграммах

№ п/п	Символ	Наименование	Примечания
1. СИМВОЛЫ ОБЪЕКТОВ ПОТОКА
1.1		Событие (Event)	Факт (ситуация, набор условий или обстоятельств), который активирует или оказывает влияние на дальнейшее развитие одного или более процессов. Событие инициируют действия или являются их результатами. В отличие от функции, выполнение которой занимает определенный промежуток времени, событие относится к конкретной точке во времени.
1.2		Действие, деятельность (Activity)	Действие или набор действий, выполняемых исполнителем в ходе процесса. Помимо наименования действия вверху и внизу символа могут указываться имена участников.
1.3		Шлюз, логический оператор (Gateway)	Используется для обозначения слияния и/или ветвления потока событий и действий.
1.4		Обмен сообщениями (Conversation)	Описание действия, характеризующего обмен информацией между участниками (пулами) взаимодействия.
2. СИМВОЛЫ ДАННЫХ
2.1		Объект данных (Data Objects)	Товарно-материальные ценности (ТМЦ) или информация, используемые или получаемые в результате действий.
2.2		Хранилища данных (Data Stores)	База данных или ее фрагмент, содержащий информацию для выполнения действий.
2.3		Сообщение (Message)	Отражает факт передачи информации между участниками процесса.
3. СИМВОЛЫ ЗОНЫ ОТВЕТСТВЕННОСТИ
3.1		Пул, участник (Pool, Participant)	Структурное подразделение, которому поручено выполнение действия (фирма, организация, отдел, служба).
3.2		Дорожка (Lane)	Должность исполнителя или роль субъекта, которому поручено выполнение действия. Составная часть организационной единицы.
4. СИМВОЛЫ СОЕДИНЯЮЩИХ ЭЛЕМЕНТОВ (ЛИНИЙ)
4.1		Поток операций, поток управления (Sequence Flow)	Задает последовательность (до-после) возникновения событий и выполнения действий.
4.2		Поток сообщений (Message Flow)	Отражает информационный обмен между участниками процесса. Обычно соединяет действия и/или пулы двух участников процесса.
4.3		Ассоциация (Association)	Отражает связь между данными (артефактами) и объектами потока.
4.4		Ссылка на обмен сообщениями (Conversation Link)	Указывает на обмен сообщениями между участниками взаимодействия.
5. СИМВОЛЫ АРТЕФАКТОВ (СПЕЦИАЛЬНЫЕ СИМВОЛЫ)
5.1		Группа (Group)	Используется для группировки графических элементов, принадлежащих одной и той же категории.
5.2		Комментарий, текстовая аннотация (Text Annotation)	Примечание (дополнительная информация), связанная с отображенным элементом.

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

Ниже приводится описание специфики отображения символов и их семантическая интерпретация.

1. События.

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

Все события классифицируются по следующим признакам:

По времени наступления:

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

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

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

По возможности прерывания выполнения действия (подпроцесса):

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

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

По типу результата действия:

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

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

По причине возникновения (триггеру) – см. табл. 8.4:

Таблица 8.4. Условные обозначения событий на BPMN-диаграммах

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

Рис. 8.9. Пример использование различных типов событий по времени возникновения и результату действия

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

Рис. 8.10. Пример использование различных типов событий по возможности прерывания выполнения действия

2. Действие.

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

Различают три основных вида действий и их разновидности :

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

o - сервисная (Service). Задача предназначена для оказания услуги, которая может являться как веб-сервисом, так и автоматизированным приложением;

o - отправка сообщения (Send). Задача считается выполненной, если сообщение послано хотя бы один раз;

o - получение сообщения (Receive). Задача считается выполненной, если сообщение получено хотя бы один раз;

o - пользовательская (User). Характерная задача, выполняемая исполнителем при содействии других людей или программного обеспечения;

o - ручное исполнение (Manual). Характерная задача, выполняемая исполнителем без каких-либо средств автоматизации;

o - бизнес-правило (Business-Rule). Задача, технология выполнения которой зависит от текущих обстоятельств и выбирается на основе заданного бизнес-правила;

o - сценарий (Script). Задача, порядок выполнения операций которой описан на языке, распознаваемом исполнителем. Обычно используется для задач, выполняемых автоматическими средствами;

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

o - событийный подпроцесс (Event Sub-Process). Запускается каждый раз, когда происходит одно из стартовых событий. На диаграмме событийный подпроцесс не связан с другими действиями потоками операций. Контур подпроцесса отображается точками;

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

Вызов (Call). Позволяет включать в состав диаграммы повторно используемые задачи и подпроцессы. На диаграмме выделяется жирным контуром.

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

Цикл (Loop). Действие выполняется в цикле с пред- (while) или пост- (repeat-until) условием;

- ||| или ≡ - многоэкземплярность (Multi-Instance). Параллельное или последовательное выполнение нескольких экземпляров однотипных действий. При последовательном выполнении действие можно рассматривать как цикл с параметром (for);

Компенсация (Compensation). Действие выполняется взамен стандартного при невозможности его удачного завершения;

- ~ - настраиваемый подпроцесс (Ad-Hoc). Указывается только для подпроцессов. Конкретный состав и последовательность входящих в него действий определяется исполнителем в процессе его выполнения.

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

3. Шлюз.

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

- , – эксклюзивный (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). Аналогичен предыдущему, но возможна активация сразу нескольких маршрутов в случае срабатывания событий, с которыми они связаны. Возможно асинхронное выполнение маршрутов (связанных потоков операций и действий). Т.е. после активации и начала выполнения одного из маршрутов, другие маршруты тоже могут быть активированы и выполнены, пока не наступил момент завершения процесса (подпроцесса). Не имеет входящих потоков.

На рис. 8.11 показан пример диаграммы с двумя различными типами шлюзов (эксклюзивным и основанным на событиях).

Рис. 8.11. Пример использование различных типов шлюзов

4. Объект данных.

С помощью дополнительных маркеров на диаграмме может быть показана специфика использования и содержания данных:

- – входные данные (Data Inputs). Исходные ТМЦ или информация для выполнения действий. Отображается у верхнего края символа;

- – выходные данные (Data Outputs). Результат действия. Отображается у верхнего края символа;

- ||| – набор данных (Data Collection). Коллекция или массив однотипных данных. Отображается у нижнего края символа.

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

5. Потоки операций.

В дополнение к стандартному изображению потока операций, на диаграмме могут быть указаны специфические потоки:

- – условный поток операций (Conditional Sequence Flow). Используется при ветвлении потоков. Обычно отображается исходящим из действия, чтобы не отображать на диаграмме шлюз. Условия активации потока задается рядом в виде логического выражения;

- – поток операций по умолчанию (Default Sequence Flow). Используется при ветвлении потоков. Может исходить из действия или шлюза. Не связан ни с каким логическим выражением. Поток по умолчанию активируется, если активация других потоков в соответствии с их логическими выражениями или событиями невозможна.

На рис. 8.12 показан пример диаграммы со специфическими потоками управления (условным и по умолчанию).

Рис. 8.12. Пример использование специфических потоков управления

Все многообразие процессов и способов взаимодействия между их участниками в BPMN поделено на типы (sub-model). Каждому из типов соответствует своя семантика и набор отображаемых элементов.

Таблица 8.5. Разновидности диаграмм (типы процессов) BPMN

Наименование диаграммы (процесса)			Назначение		Примерный вид
Диаграмма процесса (Process Diagram)	Частный (внутренний) бизнес-процесс (Private (internal) Business Process)	неисполняемый (Non-executable)	Процесс, выполняемый одним участником без указания на диаграмме других участников взаимодействия. Степень детализации (абстракции) участник процесса может быть произвольным (организация, отдел, сотрудник). Допускается использование на диаграмме пула, а внутри него дорожек, но потоки операций и сообщений не должны выходить за рамки пула.	Используется для высокоуровневого моделирования процесса. Отображен на диаграмме в общем виде, т.е. с такой степенью детализации, что его выполнение в реальных условиях по схеме, отображенной на диаграмме, как правило, невозможно из-за отсутствия описания возможных нюансов его исполнения. В частности, на диаграмме обычно отсутствуют шлюзы и условные выражения.
		исполняемый (Executable)		Используется для детализированного (обстоятельного) моделирования с описания всех возможных нюансов выполнения процесса.
	Публичный (открытый) процесс (Public Process)		Используется для отображения взаимодействия между частным процессом и другим процессом или участниками, отображенным в виде свернутых пулов.
Диаграмма хореографии (Choreography Diagram)			Используется для отображения частного процесса в виде действий, подразумевающих обмен сообщениями. Вверху и внизу символа действия указываются участники обмена сообщениями, с которыми непосредственно связаны отсылаемые/получаемые сообщения. Инициатор конкретного взаимодействия и его сообщение на диаграмме отображаются без заливки, принимающая сторона (обработчик запроса) и его сообщение (ответ) - с заливкой.
Диаграмма взаимодействия (Collaboration Diagram)	процессов (Process)		Используется для отображения состава и последовательности выполнения двух и более процессов в виде пулов с указанием взаимодействия между их составляющими через потоки сообщений.
	посредством обмена сообщениями (A view of Conversations)		Используется для отображения взаимодействия между участниками процесса через наборы потоков сообщений. Набор потоков сообщений представляется в виде символа обмена сообщениями, связанного ссылками с участниками информационного взаимодействия.

На следующих рисунках показаны примеры диаграмм разного типа из стандарта BPMN 2.0, построенные для одного и того же процесса.

Рис. 8.13. Диаграмма внутреннего процесса

Рис. 8.14. Диаграмма открытого процесса

Рис. 8.15. Диаграмма взаимодействия процессов

Рис. 8.16. Диаграмма хореографии

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

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

2. На диаграмме не должны присутствовать элементы без единой связи.

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

4. Каждый шлюз слияния должен обладать минимум двумя входящими связями, шлюз ветвления - минимум двумя исходящими.

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

Рис. 8.17. Примеры ветвления на альтернативные потоки по логическим выражениям

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

Рис. 8.18. Примеры ветвления на альтернативные потоки в зависимости от произошедших событий

7. Шлюз, разветвляющий ветки, и шлюз, объединяющий эти ветки, должны совпадать. Допускается также ситуация, когда шлюз ветвления «И», шлюз объединения – «ИЛИ».

Примеры допустимых и недопустимых ситуаций приведены на следующем рисунке.

а) допустимые ситуации

б) недопустимые ситуации

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

8. Количество пересечений линий следует минимизировать. При этом считается, что пересекающиеся линии не имеют логической связи друг с другом. Другими словами, потоки в местах пересечений не меняют своего направления.

8.10. Примеры построения BPMN-диаграмм для расчета допускаемых скоростей

В качестве иллюстрации использования BPMN-диаграмм выбрана процедура расчета допускаемых скоростей. На диаграмме ей соответствует функция «Расчет допускаемых скоростей» (см. рис. 6.21), а на – процесс «Рассчитать допускаемые скорости» (см. рис. 6.24). Содержательное описание процедуры приведено в разделе .

Меня часто спрашивают - что почитать о бизнес-процессах?
Одним из лучших сайтов на просторах рунета является www.klubok.net . Я сам "вырос" на форуме и статьях этого сайта. Многие статьи не потеряли актуальности и сейчас. Начать учиться рекомендую именно с него.

А вот если говорить о книгах - то уверенно могу сказать лучшая книга о бизнес-процессах - это книга, написанная Репиным и Елиферовым: "Бизнес-процессы компании. Построение, анализ, регламентация".

Описание бизнес-процессов: стремление к простоте.

В статье рассмотрены вопросы выбора нотации для описания процессов с целью последующей регламентации. Сравниваются между собой часто используемые нотации Work Flow, такие как: «Простая блок-схема» в MS Visio, «Процедура» Business Studio, нотация ARIS eEPC и другие.

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

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

Введение

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

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

1. «Простая блок-схема» (с отображением движения документов, с использованием блока «Решение»);
2. «Простая блока-схема» (без отображения движения документов, без использования блоков «Решение»);
3. «Процедура» системы Business Studio (один из возможных вариантов представления);
4. ARIS eEPC.

В качестве тестового примера был выбран простой и интуитивно понятный процесс. Результаты описания этого процесса представлены на рис. 1-4.

На схеме рис. 1. Последовательность выполнения операций процесса во времени показана при помощи жирных стрелок, а движение документов - при помощи тонких пунктирных стрелок. Блоки «Решение» использованы классическим образом. Они отображают информацию (вопросы), от которых «зависит» последующий ход процесса. Такой подход к использованию «ромбиков» является весьма распространенным. Но фактически, вся логика принятия решений и формирования тех или иных выходов (документов) должна заключаться внутри операций процесса. Если задуматься, то ценность (смысл) рисования этих «ромбиков» не является очевидным. Что это за объекты: операции процесса, события? Вроде бы ни то, и не другое. Это скорее операторы принятия решения по какому-либо условию. Но ведь мы разрабатываем схему процесса для людей, а не пишем компьютерную программу на специальном языке. В компьютерной программе «ромбик» был бы полноценной операцией сравнения условий и т.п. Но на схеме процесса нужно показывать реальные объекты - процессы, выполняемые людьми, документы, информационные системы и т.п. Задумайтесь, корректно ли показывать «ромбики» отдельно от операции процесса на схеме? Вместо этого можно:

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

Сформулируем «плюсы» и «минусы» рассмотренного выше (рис. 1.) способа использования «ромбиков».

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

«Плюсы» и «минусы» графического представления процесса в форме, представленной на рис. 2., показаны ниже.

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

На рис. 3. представлена схема процесса, сформированная в нотации «Процедура» среды моделирования Business Studio. Схема имеет несколько особенностей. Во-первых, блоки «Решение» использованы не стандартным образом - не как графический элемент для отображения вопроса и ветвления, а как полноценная операция процесса, связанная с принятием решений. В Business Studio «ромбик» обладает почти всеми атрибутами полноценного процесса, но не может быть декомпозирован (возможно, разработчики системы со временем сделают такую возможность). Использование «ромбика» (вместо четырехугольника) делает схему нагляднее. При этом в атрибуты «ромбика» можно внести любую текстовую информацию: описание, начало, завершение, требование к срокам и т.п.

Второй особенностью схемы процесса, представленной на рис. 3., является применение стрелок. Для отображения последовательности операций можно использовать стрелку с одним наконечником - стрелку «предшествования». Для отображения движения документов можно использовать стрелку с двумя наконечниками. Но именно в Business Studio можно пользоваться только одним типом стрелок - стрелками «предшествования». При этом к именованным стрелкам можно привязывать необходимое количество документов, которые определены в справочнике объектов деятельности. Такой подход дает возможность:

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

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

«Плюсы» и «минусы» графического представления процесса в форме, представленной на рис. 3., показаны ниже.

В случае применения Business Studio, нотация «Процедура» может быть использована несколько по-разному. Автор статьи склоняется к подходу, представленному на рис. 3.

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

Заметим, что схема процесса в нотации ARIS eEPC занимает существенно больше места, чем схемы, представленные на рис. 1-3. Трудоемкость формирования такой схемы так же существенно выше.

В целом, если Вы не собираетесь покупать SAP R/3, то выбор и использование нотации ARIS eEPC не является, с точки зрения автора статьи, оптимальным решением. Стоит обратить внимание на более наглядные и интуитивно понятные исполнителям нотации описания процессов. Впрочем, кому-то нотация ARIS eEPC может показаться более наглядной и понятной. До определенной степени, это вопрос вкуса.

Описание процесса для целей последующей автоматизации

Интересно посмотреть на рассматриваемую схему процесса в случае, если она описана в нотации BPMN 2.0. Это нотация предназначена для описания «исполняемых» процессов, т.е. процессов которые поддерживает система BPM.

Своим мнением об использовании BPMN 2.0. делится А.А. Белайчук - Генеральный директор компании «Бизнес-консоль»:

Практика жизни

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

При формировании схемы рис. 6, бизнес-аналитики очевидно, «боролись» за наглядность и максимальную понятность для рядового пользователя. Они стремились свести к минимуму, или вообще отказаться от текстового комментария к схемам процессов. Исполнителям просто печаталась схема формата А3, при чтении которой все сразу становилось понятно: что делать, как, какие документы использовать и т.п.

Рассматриваемая схема не является, конечно, образцом простоты и наглядности. Но она была сформирована, чтобы донести максимум полезной информации для исполнителей процесса.

Выводы

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

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

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

В.В. Репин , к.т.н., доцент, Исполнительный директор ООО «BPM Консалтинг Групп », зав. кафедрой Управления бизнес-процессами НОУ ВПО «ИЭФ «Синергия», основатель портала www.FineXpert.ru

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

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

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

Рисунок 1.2. Нотация IDEF0

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

Рисунок 1.3. Нотация IDEF3

При отслеживании потоков документации при использовании методологии IDEF возникает необходимость совместного использования нотации DFD.

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

Рисунок 1.4. Диаграмма языка UML

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

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

Рисунок 1.5. Диаграмма ARIS

Методология поддерживает четыре типа моделей, отражающих различные аспекты системы:

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

Каждая нотация предоставляет большое количество возможностей для описания бизнес-процессов. Однако моделирование событий в ARIS позволяет создавать более подробные и корректные описания процессов, но необходимо обратить внимание на сложность и трудоемкость описания по сравнению с другими рассмотренными нотациями (Таблица 1.1 ). Эффективность использования нотаций может варьироваться в зависимости от решаемых задач. Например, отсутствие четких соглашений по моделированию управляющих воздействий в рамках ARIS может привести к созданию моделей, не отвечающих на поставленные вопросы, в то время как нотация IDEF0 позволяет решить эту задачу. С другой стороны, процедура, выполняемая одним сотрудником, может быть более адекватно описана при помощи языка ARIS, чем при помощи IDEF0 или IDEF3.

Таблица 1. 1. Сравнительная таблица нотаций описание бизнес-процессов

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

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

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

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

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

Разрабатываемая ИС удовлетворяет следующие требования:

• · справочный характер ИС - разрабатываемая система в диалоговом режиме предоставляет пользователям необходимую в процессе реализации проектов информацию (советы, извлеченные уроки, шаблоны документов и др.);
• · экспертный характер ИС - при заполнении системы начальными данными, в том числе определение показателей оценок методик и рангов проектов, применены опыт, мнения и советы ведущих экспертов Компании;
• · аналитический характер ИС - для реализации системы были проанализированы методики управления проектами и выбраны наиболее критичные (в рамках данного исследования) данные для включения в систему;
• · база знаний в ИС - при создании в системе нового проекта определение методики его ведения происходит посредствам семантических правил в режиме «вопрос-ответ», расчет и определение которых выполняется в соответствие с рангами методик по показателям (Приложение Б.);
• · база документов в ИС - в системе хранится ряд документов в библиотеках узла: проектные процедуры, шаблоны календарных планов, уставов и т.п.;
• · база данных в ИС - подход реализации узлов на порталах SharePoint можно представить как реляционную базу данных, в которой её таблицами являются списки SharePoint.

Системой управления реализуемых бизнес-процессов является платформа разработки ИС - MS SharePoint 2013.

Разработка информационной системы, описание бизнес-процессов и настройка системы на платформе SharePoint 2013 приведена в Главе 2.

Процессным подходом к организации бизнеса мир занимается уже давно и достаточно эффективно, и стандарт 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 обозначается кругом, в котором центр свободен. Таким событием может стать письмо или звонок от клиента, например, направленный в интернет-магазин или на сайт компании, которая моделирует данный бизнес-процесс. Далее поток операций идёт по линиям и обозначает выполнение процесса вплоть до красного кружка, который обозначает завершение, конечное событие. Их, кстати, может быть и несколько, и легко проследить, где именно поток операций пришёл к концу, завершив процесс. Никакой исходящий поток из красного кружка невозможен.

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