QReal:BP

Используемая методология

QReal:BP поддерживает методологию BPM, предполагающую комплексное управление бизнес-процессами предприятия, включая разработку и моделирование бизнес-процессов. Далее эти аспекты управления бизнес-процессами рассмотрены более подробно с точки зрения использования QReal:BP для внедрения BPM в деятельность предприятия.

Разработка бизнес-процесса

Создание модели бизнес-процесса в QReal:BP состоит из двух стадий: разработка процесса и собственно моделирование.

Разработка процесса может быть разбита на следующие этапы:

  1. Определение целей и задач, которые должны быть решены в результате выполнения данного процесса.
  2. Определение участников, ответственных за выполнение процесса.
  3. Функциональная декомпозиция процесса: разделение задач процесса на подзадачи вплоть до элементарных (неделимых) действий, выделение подпроцессов.
  4. Организационная декомпозиция процесса: определение функций, за которые ответственен каждый участник, разработка потоков сообщений между участниками.
  5. Определение событий, влияющих на выполнение процесса.
  6. Разработка потоков управления, определяющих порядок и логику выполнения действий процесса.

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

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

Ниже представлены элементы BPMN, используемые в QReal:BP для моделирования бизнес-процессов, в соответствии с обозначенными в предыдущем разделе этапами разработки процесса.

Для моделирования участников и их подразделений используются роли (Swimlanes):

  • Пул (Pool) представляет собой участника процесса. Может содержать внутри себя одну или несколько дорожек. Взаимодействие участников процесса осуществляется с помощью потоков сообщений.
  • Дорожка (Lane) представляет собой роль или подразделение внутри участника процесса. Содержит в себе элементы потока управления.

Пул с двумя дорожками

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

Задание и подпроцесс

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

  • Начальное событие (Start Event) описывает способ инициации процесса. Начальное событие может принадлежать к одному из следующих типов:
    • None (Простое) - нетипизированное событие. Означает, что процесс был кем-либо инициирован.
    • Message (Сообщение) - процесс начинается по получении сообщения.
    • Timer (Таймер) - процесс начинается по наступлению какого-то времени или даты.
    • Conditional (Условие) - процесс начинается при наступлении какого-либо условия.
    • Multiple (Составное) - означает, что процесс может быть начат по наступлении любого события из нескольких.
  • Промежуточное событие (Intermediate Event) - описывает какое-либо происшествие, которое может случиться во время выполнения процесса. Возможные типы промежуточных событий:
    • None (Простое) - нетипизированное событие. Не несёт какой-либо дополнительной информации о событии.
    • Receive Message (Получение сообщения) - моделирует получение сообщения.
    • Send Message (Отправка сообщения) - моделирует отправку сообщения одним участником процесса другому.
    • Timer (Таймер) - моделирует истечение какого-либо срока либо наступление конкретной даты или времени.
    • Conditional (Условие) - событие происходит при выполнении некоторого условия.
    • Multiple (Составное) - наступление одного события из нескольких.
  • Завершающее событие (End Event) - описывает способ завершения процесса. Типы завершающих событий:
    • None (Простое) - завершение данного потока управления без каких-либо дополнительных действий.
    • Message (Отправка сообщения) - процесс завершается отправкой сообщения.
    • Terminate (Завершение) - немедленное завершение всех активных ветвей управления.
    • Signal (Сигнал) - генерация сигнала, который может быть перехвачен в другой части процесса.

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

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

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

  • Исключающее "или", управляемое данными (Exclusive (Data Based)) - поток управления направляется вдоль одной из исходящих ветвей в зависимости от выполнения какого-либо условия.
  • Исключающее "или", управляемое событиями (Exclusive (Event Based)) - поток управления направляется вдоль той из исходящих ветвей, на которой первой произошло событие.
  • Включающее "или" (Inclusive) - активизирует одну или более исходящих ветвей.
  • Параллельная (Parallel) - разделяет поток управления на несколько параллельных ветвей. Может использоваться для синхронизации параллельных потоков управления.

Пример разработки и моделирования процесса в QReal:BP>

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

Шаг 1

Функционально процесс можно разбить следующим образом:

  1. Процесс начинается с создания клиентом заявки. После этого она передаётся сотруднику организации, ответственному за её обработку.
  2. Сотрудник рассматривает заявку и принимает либо отклоняет её. В случае принятия заявки она передаётся исполнителю. В любом случае клиент получает сообщение о результатах рассмотрения заявки.
  3. Исполнитель реализует заявку клиента, после чего клиент получает сообщение об исполнении заявки.

Таким образом, процесс можно разделить на подзадачи:

  • Создание заявки - осуществляется клиентом
  • Рассмотрение заявки - осуществляется сотрудником организации, ответственным за обработку заявок
  • Исполнение заявки (при этом данное действие является сложным, его можно оформить в виде подпроцесса)

Шаг 2

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

Шаг 3

Дальнейшая доработка процесса (определение недостающих потоков управления и завершающих событий) очевидна:

Шаг 4