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

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

- метод функционального моделирования SADT (IDEF0);

- метод моделирования процессов IDEF3;

- моделирование потоков данных DFD;

- метод ARIS;

- метод Ericsson-Penker;

- метод моделирования, используемый в технологии Rational Unified Process

1 Метод SADT (Structured Analysis and Design Technique) считается классическим методом процессного подхода к управлению. Основной принцип процессного подхода заключается в структурировании деятельности организации в соответствии с ее бизнес-процессами, а не организационно-штатной структурой.

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

 

Рисунок 2 - Структура SADT-модели (декомпозиция диаграмм)

 

2 Метод моделирования IDEF3 предназначен для моделирования последовательности выполнения действий и взаимозависимости между ними в рамках процессов.

Как и в методе IDEF0, основной единицей модели IDEF3 является диаграмма. Другой важный компонент модели – действие, или в терминах IDEF3 «единица работы» (Unit of Work). Диаграммы IDEF3 отображают действие в виде прямоугольника. Действия именуются с использованием глаголов или отглагольных существительных, каждому из действий присваивается уникальный идентификационный номер. В диаграммах IDEF3 номер действия обычно предваряется номером его родителя (рисунок 3).

 

Рисунок 3 – Пример IDEF3

 

3 Диаграммы потоков данных (Data Flow Diagrams– DFD) представляют собой иерархию функциональных процессов, связанных потоками данных. Цель такого представления – продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами.

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

Основными компонентами диаграмм потоков данных являются:

• внешние сущности;

• системы и подсистемы;

• процессы;

• накопители данных;

• потоки данных.

 

Рисунок 4 – Пример диаграммы потоков данных DFD

 

4 Система ARIS (Architecture of Integrated Information System), разработанный германской фирмой IDS Scheer, представляет собой комплекс средств анализа и моделирования деятельности предприятия. Одна и та же модель может разрабатываться с использованием нескольких методов.

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

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

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

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

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

Модели в ARIS представляют собой диаграммы, элементами которых являются разнообразные объекты – «функция», «событие», «структурное подразделение», «документ» и т.п. Между объектами устанавливаются разнообразные связи.

Основная бизнес-модель ARIS – eEPC (extended Eventdriven Process Chain – расширенная модель цепочки процессов, управляемых событиями). В таблице 2 приводятся основные объекты, используемые в данной нотации.

Таблица 2 - Объекты модели eEPC

 

Рисунок 5 -  Модель eEPC

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

5 Метод Ericsson-Penker представляет интерес прежде всего в связи с попыткой применения языка объектного моделирования UML (изначально предназначенного для моделирования архитектуры систем ПО) для моделирования бизнес-процессов. Это стало возможным благодаря наличию в UML механизмов расширения.

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

 

Рисунок 5 - Метамодель категорий бизнес-модели

 

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

• стереотипы;

• тегированные (именованные) значения;

• ограничения.

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

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

 

 

Ограничение – это семантическое ограничение, имеющее вид текстового выражения на естественном или формальном языке (OCL – Object Constraint Language), которое невозможно выразить с помощью графической нотации UML.

Авторы метода Ericsson-Penker создали свой профиль UML для моделирования бизнес-процессов под названием Ericsson-Penker Business Extensions, введя набор стереотипов, описывающих процессы, ресурсы, правила и цели деятельности организации.

Метод использует четыре основные категории бизнес-модели:

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

• Процессы – виды деятельности, изменяющие состояние ресурсов в соответствии с бизнес-правилами.

• Цели – назначение бизнес-процессов. Цели могут быть разбиты на подцели и соотнесены с отдельными процессами. Цели достигаются в процессах и выражают требуемое состояние ресурсов. Цели могут быть выражены в виде одного или более правил.

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

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

Основной диаграммой UML, используемой в данном методе, является диаграмма деятельности. Основным элементом диаграммы является деятельность (activity).

6 Метод моделирования, используемый в технологии Rational Unified Process

Язык UML используется также в методе моделирования бизнес-процессов, являющемся частью технологии Rational Unified Process компании IBM Rational Software. Этот метод, направленный прежде всего на создание основы для формирования требований к ПО, предусматривает построение двух базовых моделей:

• модели бизнес-процессов (Business Use Case Model);

• модели бизнес-анализа (Business Analysis Model).

Модель бизнес-процессов – модель, описывающая бизнес-процессы организации в терминах ролей и их потребностей. Она представляет собой расширение модели вариантов использования (use case) UML за счет введения набора стереотипов – Business Actor (стереотип действующего лица) и Business Use Case (стереотип варианта использования).

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

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

• Кто извлекает пользу из существования организации?

• Кто помогает организации осуществлять свою деятельность?

• Кому организация передает информацию и от кого получает?

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

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

Описание Business Use Case представляет собой спецификацию (текстовый документ), которая, подобно обычному варианту использования, состоит из следующих пунктов:

• наименование;

• краткое описание;

• цели и результаты (с точки зрения действующего лица);

• описание сценариев (основного и альтернативных);

• специальные требования (ограничения по времени выполнения или другим ресурсам);

• расширения (исключительные ситуации);

• связи с другими Business Use Case;

• диаграммы деятельности (для наглядного описания сценариев – при необходимости).

Описание Business Use Case может сопровождаться целью процесса, которая так же, как и в методе ErikssonPenker, моделируется с помощью класса со стереотипом «goal», а дерево целей изображается в виде диаграммы классов.

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

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

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