до EPC

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

Business Studio — это простота и удобство

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

Используемые нотации моделирования

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

1. Нотация IDEF0

Наиболее популярная нотация моделирования бизнес-процессов, основанная на методологии структурного анализа SADT.

Методология IDEF0 - это методология моделирования, позволяющая создать функциональную модель, отображающую структуру и функции системы. А также — потоки информации и материальных объектов, связывающие эти функции. На рисунке ниже представлена графическая диаграмма в нотации IDEF0 - пример реализован в системе Business Studio.

Бизнес-процессы в нотации IDEF0 представляются в форме прямоугольника, а стрелки отражают связь с другими процессами и внешней средой.

Особенностями нотации являются:

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

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

С методологией SADT можно подробно ознакомиться в монографии Дэвида А. Марка и Клемента МакГоуэна «Методология структурного анализа и проектирования SADT».

2. Нотация Процесс (Basic Flowchart B Visio)

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

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

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

3. Нотация Процедура (Cross-Functional Flowchart B Visio)

Эта нотация используется для представления алгоритма выполнения процесса (нотация класса workflow). Дополнительно к графическим элементам, применяемым в нотации Процесс, используются дорожки (Swim Lanes), обозначающие организационные единицы - исполнителей действий процесса.

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

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

4. Нотация BPMN 2.0

Используется для представления алгоритма выполнения процесса (нотация класса workflow).

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

Она доступна для понимания и удобна как бизнес-аналитикам, так и разработчикам, которые занимаются автоматизацией исполнения процессов. Для экспорта схемы процесса в BPMS-систему в Business Studio используется стандарт XPDL.

В Business Studio представлено 2 типа диаграмм BPMN 2.0 - диаграммы процессов и диаграммы взаимодействия процессов.

Используются следующие графические элементы:

• процессы;
• события;
• шлюзы;

3 типа стрелок:

• поток управления;
• поток сообщений;
• ассоциации;

• документы;
• информация;
• сообщения;базы данных.

Важно, что в Business Studio все элементы диаграмм BPMN являются объектами репозитория.

В Business Studio в нотации BPMN можно строить иерархическое дерево процессов, то есть поддерживается декомпозиция.

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

5. Нотация EPC (Event-Driven Process Chain)

Используется для представления алгоритма выполнения процесса (нотация класса workflow).

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

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

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

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

А какие нотации используете в своей деятельности Вы?

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-диаграммах

Причина (триггер) события	Стартовое событие (Start event)			Промежуточное событие (Intermediate event)				Конечное событие (End event)	Примечания
	высокого уровня (Top-Level)	прерывающее подпроцесс (Sub-Process Interrupting)	непрерывающее подпроцесс (Sub-Process Non-Interrupting)	инициатор обработки (Catching)	прерывающее, возникающее на границе действия (Boundary Interrupting)	непрерывающее, возникающее на границе действия (Boundary Non-Interrupting)	результат обработки (Throwing)
Неопределенное (None)									Нетипизированное событие. Используется, чаще всего, для отображения начала или окончания процесса.
Сообщение (Message)
Таймер (Timer)									Моделирует события, происходящие по расписанию (в определенные моменты или периоды времени). Также позволяют моделировать таймауты (перерывы в ходе выполнения процесса).
Ошибка (Error)									Отражает факт возникновения и/или обработки ошибки в процессе. Ошибки могут иметь различные типы.
Прерывание, эскалация (Escalation)									Отражает факт возникновения и/или обработки некоторой ситуации, требующей немедленной реакции. Более общая ситуация, чем ошибка, т.к. может привести к положительному завершению процесса.
Отмена (Cancel)
Компенсация (Compensation)									Инициирует вспомогательные действия, компенсирующие неудачное завершение (прерывание) процесса.
Условие (Conditional)									Показывает получение и отправку сообщений в ходе выполнения процесса.
Связь (Link)									Отражает факт неудачного завершения (прерывания) процесса.
Сигнал (Signal)									Отражает факт рассылки или приема сигналов несколькими процессами. Один сигнал может обрабатываться несколькими получателями. Таким образом, события-сигналы позволяют реализовать широковещательную рассылку сообщений.
Завершение (Terminate)									Отражает факт немедленного завершения всего процесса.
Множественное (Multiple)									Отражает факт возникновения одного события из некоторого множества.
Параллельно-множественное (Parallel Multiple)									Отражает факт возникновения всех событий из некоторого множества.

На рис. 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). Содержательное описание процедуры приведено в разделе .

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

• для разработки стратегии, описания, анализа, документирования;
• информационной поддержки бизнес-процессов;
• поддержки потока работ (Workflow management).

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

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

• диаграммы активности UML;
• диаграмма потоков активностей и принятия решений ADF (activity decision flow);
• диаграмма событийных цепочек процесса ЕРС (event-driven process chain);
• нотация функционального моделирования IDEF (Icam DEFinition for functional modeling);
• другие модели (UMLEDOC Business Processes, RosettaNet, LOVeM).

В 2010 г. была опубликована версия BPMN 2.0, созданная при сотрудничестве многих исследовательских групп, в том числе консорциума OMG, Института Хассо Платтнера (Hasso Plattner Institut, Потсдам, Германия), университета Гумбольдта (Берлин, Германия), университетской инициативы Signavio.

В 2013 г. версия BPMN 2.0.1 была принята как международный стандарт IS0/1 ЕС 19510:2013 Информационные технологии. Модель и нотация процесса менеджмента объекта в групповом бизнесе.

Основные понятия и группы объектов в BPMN приведены в табл. 4.6.

Таблица 4.6

Основные понятия и группы объектов в BPMN

объектов	Описание
Действия	При помощи объектов Действия описываются задачи (бизнес-правила, сценарии, задачи-сервисы, задачи отправки сообщений и др.). Задачи затем детализируются, в том числе за счет маркеров действий (сценариев действий) и определения потоков (порядка и условий выполнения действий)
	События в BPMN, как и в некоторых других нотациях, относятся к категориям начальных, промежуточных и завершающих. К событиям относятся: отправка и получение сообщений, таймеры, ошибки, сигналы, остановы и другие виды событий. По сути, событие является индикатором происшествия, требующего дальнейшего участия пользователя, что возможно организовать, НЕ прерывая процесса (в отличие от предыдущих версий нотации)
Логические операторы	Логические операторы определяют порядок наступления событий процесса при ветвлении, слиянии или синхронизации
	Стандартные объекты данных (сообщения, хранилища, коллекции объектов), которые могут использоваться различными действиями
Хореография	Понятие, впервые появившееся именно во второй версии нотации BPMN. Его основная идея в отражении задач взаимодействия (обмена сообщения) между участниками (двумя и более)
Диалоги и взаимодействия	Определение характера информационных взаимодействий: один-к- одному либо один-ко-многим. Отличие от хореографии - в выделении нескольких пулов действий (swimlanes ) и детальном описании каждого из них (пример таких пулов приведен на рис. 4.17)
	Благодаря группе объектов Роли определяются: распределение обязанностей участников процесса; информационные потоки между ними; порядок обмена сообщениями

Нотация еЕРС (Extended Event-driven Process Chain, расширенная событийная цепочка процессов) предполагает описание алгоритма действий, выполняемых отдельными организационными единицами, что позволяет сформировать общий сценарий процесса как последовательность отдельных шагов.

Рис. 4.17.

Основными объектами диаграммы еЕРС являются элементы, приведенные в табл. 4.7.

Таблица 4.7

Объекты и нотация диаграмм еЕРС

Тип объекта	Описание	Графическое обозначение
	Состояние внешней и внутренней среды, являющееся также обязательным условием начала и окончания выполнения функции. Конечные события могут также быть начальными событиями для другого процесса
Логическое	Правила выполнения функции (если наступает только одно из событий или обязательно оба события) и правила наступления событий при выполнении функций (по сути, правила слияния и разделения ветвей процесса)
	Описание элемента работы, который представляет собой один этап процесса
Интерфейс процесса	Внешний (по отношению к текущей диаграмме) процесс или функция. Используется для указания взаимосвязи процессов (как для логической последовательности «следу- ющий/предыдущий процесс», так и для обозначения направления передачи объекта)
Объекты организационной схемы	Обозначение организационных единиц (должностей, подразделений, ролей) - исполнителей, владельцев или участников функций. Бизнес-роли в данном случае рассматриваются как требующие полномочий для управления функциями

еЕРС нс случайна названа «расширенной» диаграммой - на практике в модели такого вида могут также включаться другие объекты, например:

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

Между всеми объектами в обязательном порядке определяются связи, например, «создает» (документ), «распределяет» (задание между сотрудниками), «использует» (информационную систему 1C), «выполняет» (функцию выполняет менеджер), «принимает решение», «обеспечивает», «является владельцем» и многие другие.

Пример

Текстовое описание

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

Графическое описание

Рис. 4.18.

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

Архитектура интегрированных программных систем ARIS - инструментальная система моделирования бизнеса, разработанная компанией IDS Scheer AG и ныне принадлежащая Software AG.

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

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

Рис. 4.19.

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

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

Для каждого из представлений программный продукт ARIS предусматривает различные виды диаграмм:

• организационная диаграмма;
• диаграмма данных ERM;
• диаграммы BPMN 2.0;
• процессный ландшафт (цепочка добавленной стоимости VACD);
• системный ландшафт (диаграмма компонентов);
• иерархическая диаграмма активностей (whiteboard );
• диаграмма бизнес-процессов ЕРС;
• диаграмма ИТ-инфраструктуры (сети);
• диаграмма общего вида.

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

Расширения ARIS

Таблица 4.8

Дополнительные инструменты	Предоставляемые возможности
Процессная аналитика	Визуализация проблем производительности
	Получение отчетов/оповещений о достижении критических отметок показателей процессов
	Мониторинг данных, процессов и их ключевых индикаторов (например, функционально-стоимостной анализ затрат)
Управление	Управление бизнес-операциями, рисками и требованиями, контроль исключений
Управление политиками и соответствием требованиям регуляторов	Формирование карт политик в бизнес-контексте с разграничением зон ответственности
	Сочетание политик управления требованиями, рисками и процессами
	Ведение журнала аудита с возможностью формирования сложных отчетов (в том числе по контрольным панелям)
Управление взаимодействием: создание рабо- чей платформы коллаборации	Организация общих обсуждений процессов/приложений/данных
	Представление моделей процессов в формате web-страниц
	Публикация моделей процессов в интранет-сети компании
	Возможность для специалистов компании предложить свои улучшения в процессах
Симуляция	Возможность «прогона» (симуляции) моделей BPMN 2.0 и ЕРС для выявления различий моделей As-Is и То-Ве
	Получение статистики и сводной информации по результатам симуляции моделей в режиме реального времени
	Возможность проведения сценарного анализа «Что, если» для определения степени зависимости результата и показателей процессов от определенных факторов и групп факторов
Моделирование бизнес-правил	Возможность определения логики бизнес-правил и связывания сформированных с их помощью структурированных моделей с электронными таблицами (например, для анализа стоимости процесса)
Управление оптимизацией	Интеграция информации о структуре и значениях ключевых показателей эффективности процессов, моделях бизнес-процессов, информации о центрах затрат для поддержки принятия стратегических решений

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

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

Можно отметить 3 самые популярные нотации: семейство IDEF, eEPC и BPMN 2.0. Я не буду рассказывать об истории возникновения, развития и правилах использования нотаций – все это можно прочитать в Википедии. Вместо этого представляю свой взгляд на их использование сугубо с практической точки зрения.

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

Семейство IDEF

Ну всё-таки небольшое вступление будет. IDEF – это не одна нотация, а целое семейство. Различаются они по порядковым номерам – IDEF0, IDEF1, IDEF2 и т.д. Каждая нотация имеет свои особенности и используется для описания разных элементов бизнес-системы. Рассматривать будем семейство в целом.
Итак, IDEF. Первое что надо знать, IDEF является самой «старой» нотацией. Второе, она уже очень давно (десятилетия!) не развивается. Отсюда первый камень в огород. Семейство IDEF безнадежно, морально, функционально устарело.
Дальше. Использовать модели бизнес процессов, выполненных в IDEF, крайне сложно. Как для изучения, так и для анализа. Ниже представлен пример схемы бизнес процесса. Судите сами.

Нотация имеет ограничения по количеству отображаемых на схеме процессов – не больше 7. Отсюда возникает необходимость подстраивать описания под эти правила. Кроме того, существуют правила, которые сильно усложняют жизнь как «писателям» бизнес процессов, так и «читателям».
В совокупности это влечет за собой огромное количество тяжелых для восприятия, крайне запутанных схем. Но есть и плюс – вне зависимости от того, в какой программе вы составляете модель процесса в нотации IDEF, блок-схема будет ориентирована на лист формата А4 в альбомной ориентации. Т.е. распечатывать такие схемы удобно. На этом плюсы закончились)
О программном обеспечении. Да, существует огромное количество ПО, поддерживающего моделирование в этой нотации. В том числе и бесплатное. Но в большинстве своем оно тоже устарело и не позволяет решать актуальные на сегодняшний день задачи. В конце концов, нарисовать модель бизнес процесса можно в любом графическом редакторе. Начиная от элементарного Paint и заканчивая профессиональными инструментами, например, Microsoft Visio. Даже от руки на листе бумаги можно создать схему.
К слову, именно из потребности в автоматизации, т.е. в переводе моделей бизнес процессов в программу, и родились современные нотации. В том числе IDEF. Именно этим обусловлена строгость соблюдения правил моделирования. Машина может понять строгий графический язык, но не в состоянии понять текстовое описание.

Резюме – если вы встали перед выбором нотации для описания и моделирования бизнес процессов, ни в коем случае не останавливайтесь на IDEF.

Нотация eEPC

А вот это уже интересно. Само название нотации Событийная цепочка процессов (event driven process chain, «e» вначале означает extended, расширенное) говорит о том, что моделирование в данной нотации сосредоточено вокруг событий. А именно события и определяют развитие процесса.
В основе этой нотации лежит… Одна из нотаций семейства IDEF. А конкретно IDEF3. Впрочем, eEPC намного функциональнее и нагляднее.

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

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

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

Резюме – нотация eEPC является не самым плохим решением для описания и моделирования бизнес процессов.

Нотация BPMN 2.0

Скажу сразу, на мой взгляд, это лучшая нотация для описания и моделирования любых бизнес процессов.
BPMN (Business Process Model and Notation) – Нотация управления бизнес процессами. Вот так скромно и без прикрас назвал свое детище Институт управления бизнес процессами (BPI). Да, созданием и развитием BPMN занимается целый институт. Одно это говорит о том, что нотация является результатом серьезной, научно обоснованной работы. Более того, работа эта происходит постоянно, а в настоящее время нет ничего важнее постоянного развития инструментов управления. Впрочем, перейдем к сути.
BPMN – самая удобная, гибкая, наглядная, функциональная и вместе с тем простая нотация.
Существенным отличием является наличие понятия “дорожка”. Дорожка – это область в модели процесса, которая отображает все, что выполняет конкретный человек в данном процессе. Естественно, если процесс затрагивает разных людей, то посредством дорожек отображается их взаимодействие. И это крайне важно.

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

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

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

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

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

Резюме – нотацию BPMN выбирает большинство профессионалов в управлении бизнес процессами. Она наиболее современная и активно развивающаяся. Я рекомендую работать именно с ней.

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

• Выбирайте ту нотацию, с которой у вас уже принято работать.
• Если не принято, выбирайте BPMN.
• Выбирайте ПО и соответственно ту нотацию, с которой оно работает.
• Не знаете с чего начать? Начинайте с BPMN.

8. Выберите преимущества формального подхода к формиро­ ванию бизнес-модели предприятия:

9. Недостатками гуманитарного подхода к формированию бизнес-модели предприятия являются:

Тема 2. Процессная бизнес-модель предприятия

2.1. Эволюция организации бизнеса

2.2. Процессный поход к управлению, сущность понятия «бизнес-процесс»

2.3. Классификация бизнес-процессов предприятия

2.4. Управление бизнес-процессами предприятия

Ключевые факторы успеха (кфу)

2.5. Оценка эффективности управления бизнес-процессами

Тема 3. Основы моделирования бізнес-процессов

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

3.2. Нотации создания бизнес процессов

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

Бизнес-процессов

Методология sadt

Методология idef3

2. Выберите предметные области моделирования:

Тема 4. Методология управления качеством бизнес-процессов

4.1. Системы концепции совершенствования бизнес-процессов

Система «канбан»

Система «5s»

Система «три»

Система «кружкикачества»

Цикл pdca

Цикла Шухарта-Деминга

Система «шесть сигм»

В концепции Six Sigma

Система «кайдзен»

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

Гистограмма

Контрольные карты

Стра тификация

Диаграмма исикавы

Диаграмма парето

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

17. Что представляет собой концепция «Шесть сигм»?

18. Выберите последовательность действий при использова­ нии колеса Деминга:

20. Сколько циклов содержит цикл Шухарта-Деминга?

Тема 5. Ресурсная бизнес-модель предприятия

5.1. Ресурсный подход в управлении предприятием

5.2. Сущность, виды и структура ресурсов предприятия

5.3. Зависимость результативности деятельности предприятия от ресурсов

5.4. Формирование ресурсной бизнес-модели предприятия

5.5. Оптимизация распределения сырьевых ресурсов на предприятии

Тема 6. Информационная бизнес-модель предприятия

6.1. Основные понятия и элементы информационной бизнес-модели

6.2. Информационная среда экономической деятельности предприятий

6.3. Информационные системы: развитие, виды, характеристика

6.4. Облачные вычисления - бизнес платформа XXI века

6.5. Формирование информационной бизнес-модели предприятия

11. Что представляет собой информационная индустрия?

Тема 7. Матричная бизнес-модель предприятия

7.1. Основные понятия и виды матричных моделей в экономике

7.2. Матричные инструменты в системе управления предприятием

Матрица приоритетов

7.3. Экономические матричные модели в оценке эффективности деятельности предприятия

7.4. Формирование матричной бизнес-модели предприятия во внешней среде

1. Что понимают под матричной мо­делью?

2. Что представляет собой матричная диаграмма?

14. На рисунке представлена матрица показателей. Расставьте показатели по степени важности для начала действий по совер­ шенствованию.

Тема 8. Компетентностная («3d») бизнес-модель предприятия

8.1. Сущность и основные элементы компетентностной («3d») бизнес-модели предприятия

Компетенциями

8.2. Методический подход к формированию компетентностной («3d») бизнес-модели

Приложение д

Предприятия

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 и более нота­ций.

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