Процессное представление. Моделирование бизнес-процессов на транспорте с использованием нотации BPMN 2.0

Лабораторная работа №4

Цель работы - изучение особенностей разработки моделей цепочки бизнес-процессов, управляемых событиями, посредством диаграмм BPMN (Business Process Modeling Notation)

Краткие теоретические сведения

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

BPMN (Business Process Modeling Notation) – графический язык моделирования бизнес-процессов, разработанный организацией Business Process Management Initiative (BPMI). Последняя версия нотации BPMN 2.0 вышла в 2010 году.

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

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

- внутренних потоков сообщений (вследствие взаимодействия различных частей процесса)

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

Графическая нотация BPMN может быть применена аналитиками для:

- составления моделей и документирования бизнес-процессов в текущем состоянии, исходя из представлений о ней сейчас;

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

- выявления скрытых процессов;

- выявления всех частей процесса;

- описания взаимодействия участников процесса и смежных процессов.

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

Рассмотрим 5 основных категорий элементов языка моделирования BPMN (названия категорий, элементов нотации и типов элементов соответствует документации BPMN 2.0):

1. Элементы потока (процессы, события, шлюзы или логические операторы);

2. Данные (объекты данных и базы данных);

3. Соединяющие элементы (потоки управления, потоки сообщений и ассоциации);

4. Зоны ответственности (пулы и дорожки);

5. Артефакты (сноски).

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

Задачей в нотации BPMN называется элементарное действие (или операция), которое не имеет декомпозиции в рамках рассматриваемого процесса.

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

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

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

Рисунок 1 – Условные обозначения задачи и подпроцесс

Задачи подразделяются на следующие типы:

1). Абстрактная задача с неопределённым типом.

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

3). Сервисная задача представляет собой Задачу, предназначенную для оказания услуги, которая может являться как веб-сервисом (Web service), так и автоматизированным приложением.

4). Отправка сообщений: задача посылки сообщения внешнему участнику, находящемуся за пределами рассматриваемого процесса. Задача считается выполненной в случае, если сообщение было отправлено хотя бы один раз.

5). Получение сообщений: задача приёма сообщений от внешнего участника, находящегося за пределами рассматриваемого процесса. Задача считается выполненной в случае, если сообщение было получено хотя бы один раз.

6). Ручное выполнение: представляет собой Задачу, выполнение которой подразумевает действия человека и исключает использование каких-либо автоматизированных механизмов исполнения или приложений. Примером такого типа Задач может служить установка телефонного аппарата на территории заказчика специалистом по обcлуживанию телефонов.

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

8). Задача-сценарий: задача, выполняющая определённый сценарий (скрипт) некоторой автоматической операции. Задача-сценарий обозначает выполнение в процессе некоторого автоматизированного действия. То есть оно выполняется без конкретного исполнителя средствами самой BPMS-системы. Например, это может быть подсчет каких-либо данных - подсчет сумм, введенных пользователем. Такая работа прекрасно выполняется компьютером без участия человека. BPMS-система не только делает это быстрее, но еще и никогда не ошибается в расчетах. Задача считается выполненной в случае, если был выполнен запущенный для неё сценарий.

По умолчанию все задачи имеют абстрактный тип. Тип задачи указывается в прямоугольнике в верхнем левом углу (рисунок 2).

Рисунок 2 – Условные обозначения типов задач

Подпроцессы разделяются на следующие типы (рисунок 3):

1) Подпроцесс с неопределённым типом.

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

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

4) Ad-Hoc процесс: группа взаимодействующих процессов, последовательность и количество выполнений которых определяются их исполнителями.

По умолчанию процесс имеет неопределённый тип.

Рисунок 3 – Условные обозначения типов подпроцессов

Событие – некоторая важная ситуация, которая происходит в бизнес-процессе. Оно оказывает влияние на последовательность действий Процесса или время их выполнения. Типы событий представлены на рисунке 4:

Рисунок 4 – Условные обозначения типов событий

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

Различают следующие типы событий:

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

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

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

4. Ошибка: событие, при котором в системе появляется исключительная ситуация, требующая реакции и обработки.

5. Отмена: событие, отражающее прерывание (остановку или завершение) транзакционного процесса и подпроцесса.

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

7. Условие (правило): событие, которое используется для обработки исключений (порождает процесс обработки), когда бизнес-правило становится верным. Правило определяет данные порождённого процесса.

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

9. Остановка: обозначение окончания процесса во всей диаграмме.

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

Рисунок 5 – Условные обозначения типов шлюзов

Выделяют следующие типы шлюзов (Рисунок 5):

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

Исключающие Шлюзы включаются в состав бизнес-процесса для разделения Потока операций на несколько альтернативных маршрутов. Для процесса с исключающим типом Шлюза может быть выбран лишь один из предложенных маршрутов (поэтому определяется как Шлюз «ИЛИ»).

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

3. Операторы, включающие объединение условий, осуществляют ветвление по набору условий (для каждого перехода возможно своё условие), условия независимы. Неисключающие Шлюзы используются для разделения потока операций на несколько альтернативных и параллельных маршрутов. Для данного экземпляра процесса может быть выбран лишь один из предложенных маршрутов – или параллельный (т.е. оба маршрута выполняются параллельно) или альтернативный (т.е. процесс пойдёт только по одному, соответствующему условиям, маршруту).

4. Операторы, содержащие комплексные условия, содержат сложное условие (композицию простых) или объединение простых операторов.

5. Параллельные операторы: используются для создания параллельных маршрутов и их синхронизации (объединения). С помощью Параллельного Шлюза параллельные маршруты создаются без необходимости проверки каких-либо условий. При разветвлении все исходящие потоки (маршруты) активизируются одновременно. Закрывающий Шлюз используется для синхронизации, т.е. он ожидает завершения выполнения всех входящих ветвей (маршрутов) и только затем активирует выходной поток.

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

База данных – хранилище информации, используемое приложением.

Рисунок 6 – Условные обозначения объекта данных и базы данных

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

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

Ассоциация – это элемент BPMN, связывающий объекты и базы данных или комментарии с задачами процессами.

Рисунок 7 – Условные обозначения потока управления, потока сообщений и ассоциации

Пул – некоторая область, в пространстве которой разворачивается процесс. Содержимое пула – диаграмма рассматриваемого процесса. Пул может содержать одну или несколько дорожек.

Рисунок 8 – Условные обозначения пула и дорожек

Дорожка – часть пула, процесс которой соответствует некоторой группе участников бизнес процесса.

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

Рисунок 9 – Условное обозначение артефакта

Пример бизнес-процесса «Обеспечение заказа покупателя» в нотации BPMN 2.0 представлен на рисунке 10.

Рисунок 10 – Пример бизнес-процесса «Обеспечение заказа покупателя» в нотации BPMN 2.0

BPMN 2.0 содержит описание три основных диаграмм: диаграмма процессов (Process Diagram), диаграмма Хореографии (Choreography Diagram) и диаграмма взаимодействия (Collaborationa Diagram). С помощью вышеперечисленных основных диаграмм может быть создано множество вариантов диаграмм бизнес-процессов.

Рисунок 11 – Типы диаграмм BPMN 2.0

Порядок выполнения работы.

1. Ознакомиться с заданием и теоретической частью данных методических указаний.

2. Проанализировать исходные данные.

3. По выбранному варианту построить проект бизнес-процесса в нотации BPMN 2.0, включающий:

3.1 диаграмму процессов (частный и публичный процесс)

3.2 диаграмму хореографии

3.3 диаграмму взаимодействия.

4. Продемонстрировать созданные модели преподавателю.

5. Оформить отчет.

Примечания:

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

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

- помните, что действия можно писать только внутри блоков процессов;

- не бойтесь использовать артефакты;

- избегайте зацикливания – операторы ветвления в этой нотации очень коварны;

- обратите внимание на начало и окончания процессов.

Среда выполнения лабораторной работы:

- MS Visio;

- Draw.io;

- Bizagi Process Modeller;

- Другие он-лайн серсвисы, поддерживающие нотацию BPMN 2.0.

Сохраняйте исходники!

Исходные данные задания

Вариант №1.

Процесс «Покупки железнодорожного билета» состоит из следующей последовательности действий:

1. Пассажир сообщает оператору ж/д кассы о направлении поезда, дате отправки и классе обслуживания.

2. Оператор по выбранным критериям делает запрос в ИС.

3. На основе полученных данных, оператор сообщает возможные варианты покупки билетов. В случае отсутствия мест оператор предлагает выбрать пассажиру другие параметры поиска.

4. Пассажир выбирает место в вагоне поезда и отдает оператору паспорт.

5. Оператор оформляет билет и сообщает сумму покупки.

6. Пассажир оплачивает билет. В случае отсутствия необходимой суммы оператор предлагает выбрать пассажиру другие параметры поиска.

7. Оператор выдает покупателю билет, чек и сдачу.

8. Процесс завершен, железнодорожный билет куплен.

Вариант №2.

Процесс «Покупки железнодорожного билета» состоит из следующей последовательности действий:

1. Пассажир выбирает поезд и дату отправления.

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

3. Оператор ж/д кассы оформляет проездной билет.

4. Пассажир оплачивает билет.

5. Оператор выдает покупателю билет, чек и сдачу.

6. Пассажир проверяет билет. В случае наличия ошибок, пассажир сообщает о них оператору, и он повторно оформляет билет.

7. Процесс завершен, железнодорожный билет куплен.

Вариант №3.

Процесс «Перевозка груза» состоит из следующей последовательности действий:

1. Заказчик отправляет заявку диспетчеру на перевозку груза.

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

3. Диспетчер оформляет накладную на перевозимый груз.

4. Сотрудник подразделения погрузки/разгрузки загружает перевозимый товар в вагон.

5. Поезд перенаправляется в пункт назначения.

6. Сотрудник подразделения погрузки/разгрузки выгружает перевозимый товар из вагона.

7. Заказчик забирает груз.

8. Процесс завершен, груз перевезен.

Вариант №4.

Процесс «Перевозка груза» состоит из следующей последовательности действий:

1. Заказчик отправляет заявку диспетчеру на перевозку груза.

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

3. Сотрудник отдела логистики на основании заяви, учитывая габариты, массу груза и условия перевозки распределяет груз по вагонам и поездам.

4. Диспетчер оформляет накладную на перевозимый груз.

5. В пункте отправления сотрудник подразделения погрузки/разгрузки загружает перевозимый товар в вагон.

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

7. Бухгалтер выписывает документы (акт выполненных работ, счет фактура, счет на оплату) и передает их заказчику.

8. Заказчик оплачивает перевозку и забирает груз.

9. Процесс завершен, груз перевезен.

Вариант №5.

Процесс «Изменение графика движения поездов» состоит из следующей последовательности действий:

1. Начальник центра управления перевозками выдает задание на изменение графика движения поездов.

2. Проектировщик разрабатывает график движения поездов.

3. Сотрудник нормоконтроля проверяет соответствие графика установленным правилам и критериям. В случае нарушений, график направляется на доработку.

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

5. Начальник центра управления перевозками создает приказ о дате ввода нового графика.

6. Процесс завершен, график движения поездов изменен.

Вариант №6.

Процесс «Изменение графика пригородных электричек» состоит из следующей последовательности действий:

1. Начальник центра управления перевозками выдает задание на изменение графика движения пригородных электричек.

2. Сотрудник отдела статистики передает информацию о пассажиропотоке проектировщику.

3. Проектировщик разрабатывает график движения поездов.

4. Сотрудник нормоконтроля проверяет соответствие графика установленным правилам и критериям. В случае нарушений, график направляется на доработку.

5. Начальник отдела статистики согласовывает новый график. В случае отклонения, график направляется на доработку.

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

7. Начальник центра управления перевозками создает приказ о дате ввода нового графика.

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

Вариант №7.

Процесс «Осмотр технического состояния вагона» состоит из следующей последовательности действий:

1. Помощник дежурного по парку составляет расписание осмотра технического состояния вагонов.

2. Дежурный по парку извещает осмотрщиков-ремонтников вагонов о подходе поезда, указывая время его прибытия и номер пути приема.

3. Осмотрщики-ремонтники вагонов выходят к пути приема и проводят осмотр вагона. В случае нарушений вагон отправляется на ремонт и затем проходит повторный осмотр технического состояния.

4. Дежурный по парку оформляет документы по техническому состоянию вагона.

5. Начальник службы технического осмотра утверждает документ.

6. Процесс завершен, выполнен осмотр технического состояния вагона.

Вариант №8.

Процесс «Осмотр технического состояния вагона» состоит из следующей последовательности действий:

1. Дежурный по парку извещает осмотрщиков-ремонтников вагонов о подходе поезда, указывая время его прибытия и номер пути приема.

2. Осмотрщики-ремонтники вагонов выходят к пути приема и проводят осмотр движущегося вагона. В случае нарушений вагон отправляется на ремонт и затем проходит повторный осмотр технического состояния.

3. Осмотрщики-ремонтники вагонов проводят осмотр неподвижного вагона. В случае нарушений вагон отправляется на ремонт и затем проходит повторный осмотр технического состояния.

4. Осмотрщики-ремонтники составляют акт технического состояния вагона.

5. Начальник бригады утверждает акт технического состояния вагона. В случае наличия ошибок, документ направляется на повторное составление.

6. Начальник службы технического осмотра утверждает акт.

7. Процесс завершен, выполнен осмотр технического состояния вагона.

Вариант №9.

Процесс «Отправки посылки железнодорожным транспортом» состоит из следующей последовательности действий:

1. Пользователь передает посылку и паспорт оператору сервисного центра.

2. Оператор упаковывает посылку и оформляет перевозочный бланк.

3. Пользователь оплачивает услугу перевозки груза. В случае недостатка средств, пользователь подает заявку на новый тип упаковки.

4. Оператор передает посылку грузчику.

5. Грузчик погружает посылку в вагон.

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

7. Оператор сервисного центра принимает посылку.

8. Получатель посылки отдает паспорт оператору сервисного центра.

9. Оператора оформляет факт выдачи посылки на перевозочном бланке и отдает посылку получателю.

10. Процесс завершен, посылка отправлена.

Вариант №10.

Процесс «Поездка в поезде» состоит из следующей последовательности действий:

1. Пассажир покупает билет на поезд

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

3. Пассажир осуществляет посадку в вагон поезда.

4. Поезд перенаправляется в пункт назначения.

5. Пассажир покидает вагон поезда.

6. Процесс завершен, поездка в поезде осуществлена.

Требования к отчёту по работе.

Отчёт о работе должен содержать следующее:

1) Название работы;

2) Вариант;

3) Текст задания;

4) Сриншоты разработанных моделей;

5) Выводы по проделанной работе.

Контрольные вопросы: