В данной статье-тренажёре мы подготовили 25 заданий на составление BPMN-модели процесса кредитования в ДБО. К каждому заданию мы подготовили рекомендации по его выполнению, а также под спойлерами спрятали наше решение и его объяснение. Возможно, наше понимание и исполнение может отличаться от того, к которому придёте вы — мы будем рады подискутировать в комментариях.
В конце статьи мы приложили файл цельной диаграммы всех процессов и полный текст в формате .pdf для скачивания, чтобы можно было потренироваться, поискать собственное решение и подробнее ознакомиться с нашим в любое удобное время.
Дисклеймер: задания и их решения — это сугубо пример, расхождения с реальными системами имеют место быть.
Введение. Предметная область: дистанционное банковское обслуживание
Дистанционное банковское обслуживание (ДБО) — это совокупность процессов и систем, позволяющих клиенту получать банковские услуги без визита в отделение: через мобильное приложение или веб-банк.
В рамках данной серии заданий мы будем моделировать сквозной бизнес-процесс оформления и сопровождения кредита физическому лицу через ДБО, начиная с подачи заявки и заканчивая обслуживанием кредита и обработкой проблемных ситуаций.
Итоговая цель серии BPMN-заданий: Построить полную BPMN-модель процесса кредитования в ДБО, включающую:
клиентский путь;
автоматизированные проверки;
ручные операции сотрудников банка;
альтернативные и исключительные сценарии;
тайминги, возвраты и завершение процесса.
Задание 1. Подача кредитной заявки клиентом
Описание задания: Клиент в мобильном банке заполняет и отправляет кредитную заявку.
Рекомендация для выполнения задания:
Используй пул "Банк" и дорожку "Клиент".
Используй стартовое событие (None Start Event).
Используй пользовательскую задачу "Заполнить заявку".
Используй объект данных "Кредитная заявка" (выход задачи).
Соедини элементы обычным последовательным потоком.
Решение
Подумай:
Объясни выбор пустого стартового события.
Объясни, почему данные оформлены как объект данных.
Объясни границы ответственности клиента.
Объяснение
Для построения данного графического решения первым шагом мы на диаграмму добавляем пул "Банк" — это наша организация, далее, для разграничения ролей, мы добавляем дорожку "Клиент", так как именно клиент и начинает процесс по оформлению кредита.
Далее на нашу диаграмму мы добавляем начальное событие. Так как процесс оформления кредита инициирует Клиент, то начальное событие будет пустым.
Следующим шагом добавляем на диаграмму задачу "Заполнить заявку", с типом "User task" — так как заявку по кредиту заполняет клиент.
На выходе заполнения заявки клиентом, в системе формируется кредитная заявка, поэтому на диаграмму добавляем объект данных "Кредитная заявка".
В BPMN есть несколько видов связей:
Последовательный поток — показывает направление и порядок выполнения шагов процесса
Ассоциация — используется для связывания разных элементов диаграммы, чтобы показать отношения между ними
Последовательный поток обозначается сплошной линией со стрелкой, а ассоциация — пунктирной линией со стрелкой.
Компоненты стартового события и пользовательской задачи соединяем последовательным потоком (сплошная линия со стрелкой).
А пользовательскую задачу и объект данных соединяем связью ассоциации (пунктирная линия со стрелкой)
Задание 2. Регистрация заявки системой
Описание задания: Система регистрирует полученную заявку.
Рекомендация для выполнения задания:
Добавь дорожку "Система ДБО".
Используй сервисную задачу "Зарегистрировать заявку".
Добавь хранилище данных "Реестр заявок".
Используй ассоциацию данных между задачей и хранилищем.
Решение
Подумай:
Объясни разницу между объектом данных и хранилищем.
Объясни, почему используется сервисная задача.
Описание
После заполнения заявки клиентом, система регистрирует данную заявку в реестре заявок.
В пул "Банк" добавляем дорожку "Система ДБО". На добавленную дорожку добавляем задачу "Зарегистрировать заявку" с типом "Service task". Задача "Зарегистрировать заявку" оформлена как сервисная, поскольку выполняется автоматически без участия пользователя и представляет собой системную операцию, которая может быть реализована в виде backend-сервиса. Использование Service task позволяет явно показать автоматизированный характер шага и отличить его от пользовательских и ручных операций.
Зарегистрированная заявка сохраняется системой в хранилище. Поэтому, на дорожку "Система ДБО" добавляем хранилище данных "Реестр заявок", в котором как раз и будут храниться зарегистрированные системой заявки.
На данном этапе стоит различать разницу между объектом данных и хранилищем данных. Объект данных — это некая сущность, в нашем примере — заявка, заполненная клиентом, а хранилище данных — это место, где хранятся зарегистрированные системой заявки.
Поэтому, сервисную задачу "Зарегистрировать заявку" и хранилище данных "Реестр заявок" соединяем связью ассоциации.
И не забываем про связь пользовательской задачи "Заполнить заявку" и сервисной задачи "Зарегистрировать заявку", соединяем их обычным последовательным потоком, так как задачи выполняются последовательно.
Задание 3. Автоматическая проверка платёжеспособности
Описание задания: Система проверяет платёжеспособность клиента.
Рекомендация для выполнения задания:
Используй сервисную задачу.
Добавь объект данных "Результат скоринг��".
Сохрани линейный поток.
Решение
Подумай:
Объясни, почему это автоматическая проверка.
Объясни назначение результата проверки.
Объяснение
Следующим шагом идёт скоринг. Проверка платёжеспособности оформлена как сервисная задача, так как выполняется автоматически на стороне банковских систем без участия пользователя или сотрудника банка. В реальных банковских процессах скоринг реализуется в виде алгоритмов и интеграций с внутренними и внешними источниками данных, поэтому моделирование этой операции как user task или manual task было бы некорректным. Добавляем сервисную задачу "Проверить платёжеспособность".
В результате проверки, в системе формируется результат, влияющий на одобрение или на отказ по выдаче кредита клиенту. Добавляем на диаграмму объект данных "Результат скоринга"
Соединяем сервисную задачу "Проверить платёжеспособность" с объектом данных "Результат скоринга" связью ассоциации.
И соединяем сервисные задачи "Зарегистрировать заявку" и "Проверить платёжеспособность" последовательным потоком.
На данном этапе вся ответственность за выполнение шага лежит на системе ДБО. Клиент и сотрудники банка не участвуют в процессе, что подчёркивает автоматизированный характер скоринга и позволяет в дальнейшем чётко разделять ручные и автоматические операции.
Задание 4. Первичное решение по скорингу
Описание задания: Система принимает решение: одобрено / отказано.
Рекомендация для выполнения задания:
Используй исключающий шлюз (XOR).
Используй условные потоки с условиями.
Решение
Подумай:
Объясни выбор XOR.
Объясни разницу между условным потоком и потоком по умолчанию.
Объяснение
В результате процесса скоринга может быть 3 ситуации:
Одобрение заявки по кредиту (условный поток)
Отказ по выдаче кредите (условный поток)
Отсутствие статистических данных по клиенту (поток по умолчанию)
Поток по умолчанию на данном этапе сознательно не моделируется, так как дальнейший сценарий будет добавлен в одном из следующих заданий (Задание 6).
Важно различать условные потоки и поток по умолчанию. Условный поток — это поток, который выполняется согласно условию (одобрено или отказано по выдаче кредита), а поток по умолчанию выполняется, когда ни один из условных потоков не выполняется (отсутствие статистических данных).
Для моделирования принятия решения используется исключающий шлюз (XOR), так как по результатам скоринга заявка может перейти только по одному из возможных сценариев. Одновременное выполнение нескольких веток невозможно, а выбор осуществляется на основании условий, вычисленных системой.
Далее добавляем 2 задачи по отправке сообщений клиенту (обозначаются прямоугольником с иконкой закрашенного сообщения в углу). Назовем их "Отправить сообщение об одобрении" и "Отправить сообщение об отказе".
Соединяем шлюз с двумя задачами по отправке сообщений потоками "Одобрено" и "Отказано".
Для этих двух потоков прописываем условия в condition
"Если платёжеспособность высокая"
"Если платёжеспособность низкая"
На данном этапе процесс не завершается, так как дальнейшие сценарии обработки заявки будут смоделированы в следующих заданиях.
Задание 5. Уведомление клиента о результате
Описание задания: Клиент получает уведомление о решении.
Рекомендация для выполнения задания:
Используй промежуточное событие сообщения (Message Intermediate Event).
Решение
Подумай:
Объясни, почему это событие, а не задача.
Объясни роль сообщений в BPMN.
Объяснение
На диаграмму, на дорожку "Клиент" добавляем промежуточное событие получения сообщения "Message Intermediate Catch Event", так как клиент ожидает сообщение о результате по выдаче кредита. Назовём его "Сообщение о результате по выдаче кредита".
Соединяем задачи по отправке сообщений и событие получения сообщения последовательными потоками
Итак, почему именно событие получения сообщения, а не задача. Клиент ожидает ответа от системы, то есть в этот момент он ничего не выполняет, а ждёт ответ, именно поэтому мы добавили на диаграмму событие. Тип у события проставляем сообщение, так как система по результату присылает уведомление клиенту.
Задание 6. Неоднозначный скоринг
Описание задания: Если скоринг неоднозначен, требуется ручная проверка.
Рекомендация для выполнения задания:
Расширь XOR-шлюз третьей веткой.
Добавь дорожку "Кредитный специалист".
Используй пользовательскую задачу.
Решение
Подумай:
Объясни добавление альтернативной ветки.
Объясни ввод новой роли.
Объяснение
Вернемся к условию по умолчанию из пункта 4 — "Отсутствие статистических данных по клиенту". Для реализации данного условия — добавим в пул "Банк" новую дорожку "Кредитный специалист".
Кредитный специалист реализует ручную п��оверку, если результат автоматического скоринга неоднозначный. Поэтому, далее на новую дорожку добавляем пользовательскую задачу "Проверить вручную".
И соединяем шлюз, разветвляющий условия скоринга, с пользовательской задачей "Проверить вручную" последовательным потоком с типом "Default Flow" — это будет поток по умолчанию. Поток по умолчанию выполняется в случае, если ни одно из явно заданных условий исходящих потоков не выполнилось. В нашем случае, когда результат автоматической проверки скоринга является неоднозначным.
Задание 7. Решение кредитного специалиста
Описание задания: Специалист: одобряет, отклоняет или запрашивает документы.
Рекомендация для выполнения задания:
Используй исключающий шлюз (XOR).
Три исходящих условных потока.
Решение
Подумай:
Объясни, почему решения взаимоисключающие.
Объяснение
Итогом ручной проверки кредитного специалиста могут быть следующие варианты:
Одобрение заявки по кредиту (условный поток)
Отказ в выдаче кредита (условный поток)
Запрос необходимых документов (поток по умолчанию)
В результате выполнения условных потоков клиенту отправляется сообщение о результате ручного рассмотрения заявки кредитным специалистом.
Добавляем на диаграмму две задачи по отправке сообщения клиенту на дорожку "Кредитный специалист", назовем их единообразно "Отправить сообщение об одобрении" и "Отправить сообщение об отказе".
Также, на данную дорожку добавляем исключающий шлюз XOR для разветвления процесса. Соединяем пользовательскую задачу "Проверить вручную" и шлюз последовательным потоком.
Условными потоками "Одобрено" и "Отказано" соединяем две задачи по отправке сообщения клиенту. Далее последовательными потоками соединяем данные задачи и событие по получению сообщения в дорожке "Клиент".
Поток по умолчанию рассмотрим в следующем пункте.
Посмотрите на текущую схему. Есть идеи что можно улучшить?
Задание 8. Запрос документов у клиента
Описание задания: Клиенту отправляется запрос документов.
Рекомендация для выполнения задания:
Используй промежуточное событие отправки сообщения.
Добавь объект данных "Запрос документов".
Решение
Подумай:
Объясни коммуникационный характер шага.
Предложи улучшения по сравнению с заданием 7.
Объяснение
Перед тем, как приступить к следующему шагу, необходимо оптимизировать вид диаграммы.
Всё дело в том, что если посмотреть на результат диаграммы, который получился в предыдущем задании, то следует обратить внимание на то, что у нас на разных дорожках происходит дублирование задач по отправке результатов проверки (одобрено или отказано). Решение верно, но задачи идентичны — это признак "плохого" построения, нужна оптимизация, так как в программировании существует такое правило: то, что повторяется, выносим в отдельное место.
Вынесем данные задачи в подпроцесс "Уведомление клиента". Данный подпроцесс необходимо сделать отдельным (независимым), ведь сам процесс уведомления клиента может встретиться далее по процессу, и чтобы нам не отрисовывать идентичный процесс, нам нужно сделать данный процесс универсальным, чтобы мы в любой момент выполнения программы могли к нему обратиться с целью уведомления клиента о каком-либо событии.
Добавляем на диаграмму независимый подпроцесс "Уведомление клиента", тип подпроцесса — "Call activity". Графически отображается жирной рамкой компонента подпроцесса.
Далее, размещаем подпроцесс на дорожке "Система ДБО", так как сообщение клиенту отправляет система приложения. Убираем с диаграммы все задачи после шлюзов, которые отвечают за отправку сообщений о результате проверки.
Соединяем данный подпроцесс с двумя последними шлюзами условным потоком. Событие по ожиданию сообщения клиентом также соединяем с данным подпроцессом последовательным потоком.
Как мы можем заметить, диаграмма приняла более аккуратный и не перегруженный вид, вместо четырех задач — у нас один подпроцесс, и множество потоков тоже преобразовалось.
Теперь немного поработаем с нашим подпроцессом, нужно внутри него реализовать процесс отправки сообщения.
Так как у нас независимый подпроцесс ("Call activity"), то процесс, который выполняется внутри подпроцесса отрисовывается в отдельном файле, а при выполнении просто вызывается, используя идентификатор процесса.
Создаем новую BPMN диаграмму, назовем её "Client Notification". На данной диаграмме нам необходимо отобразить только процесс отправки сообщения. Это реализуется с помощью события отправки сообщения. Добавляем данное событие на диаграмму. Но, чтобы запустить и закончить подпроцесс, нам также потребуются Начальное и Конечное события (пустые). Процесс для подпроцесса отрисован.
Далее, чтобы наша основная диаграмма понимала к какому файлу обращаться и запускать его для выполнения подпроцесса, необходим идентификатор внутреннего процесса, который только что был отрисован. Его можно скопировать с новой диаграммы "Client Notification", с которой только что работали. Справа в боковом меню в разделе "General" есть поле "ID", копируем данный идентификатор, возвращаемся на основную диаграмму, кликаем на подпроцесс "Уведомление клиента", в правом боковом меню переходим в раздел "Called element" (Вызываемый элемент), и вставляем в "Process ID" скопированный ранее идентификатор.
Теперь новый подпроцесс "уведомление клиента" знает какой именно процесс он выполняет, благодаря данной связке по идентификатору. Если в дальнейшем, в каком-то новом месте процесса нам нужно будет обратиться к процессу уведомления клиента, то мы так же просто добавим подпроцесс и свяжем его с данным "Process ID" с этим же процессом.
Оптимизация прошла успешно. Идем далее, преходим к нашему заданию.
На данном шаге, возвращаемся к условию по умолчанию — "Запрос необходимых документов".
Кредитный специалист при отсутствии документов о клиенте запрашивает их, отправляя соответствующее сообщение.
Теперь, когда наша диаграмма оптимизирована, всё проще. Запрос необходимых документов — это тоже уведомление клиента о результате рассмотрения заявки по кредиту. Именно поэтому связь между пользовательской задачей "Проверить вручную" кредитного специалиста и подпроцесса "Уведомление клиента" уже включает данную ситуацию. Для этого нам нужно будет отправлять в подпроцесс параметр "Тип сообщения" и в зависимости от полученного типа программа отправит то или иное сообщение из трех возможных вариантов:
Заявка одобрена
Отказ
Запрос документов
Коммуникационные шаги в BPMN целесообразно выносить в отдельные процессы, так как они, как правило, ��е зависят от конкретного сценария принятия решения и могут быть переиспользованы при возникновении различных событий в жизненном цикле заявки.
Задание 9. Загрузка документов клиентом
Описание задания: После получения сообщения о результате рассмотрения заявки клиент может оказаться в одном из трёх сценариев:
заявка одобрена;
в выдаче кредита отказано;
требуется загрузить дополнительные документы.
В зависимости от типа полученного сообщения:
— при одобрении или отказе процесс для клиента завершается;
— при запросе документов клиент загружает необходимые документы в систему.
Рекомендация для выполнения задания:
Используй промежуточное событие получения сообщения
После события используй исключающий шлюз (XOR) для обработки альтернативных сценариев
Для сценариев "Одобрено" и "Отказано" используй конечные события.
Для сценария "Запрос документов":
Используй пользовательскую задачу "Загрузить документы"
Используй объект данных "Документы" (вход/выход).
Решение
Подумай
Объясни повторное вовлечение клиента.
Объяснение
Как только клиент получил сообщение о запросе документов, то следующим шагом будет пользовательская задача клиента по загрузке документов в систему.
Сперва необходимо понять — клиент получает сообщение о результате проверки с помощью одного события ожидания сообщения. Сообщение может прийти об одобрении заявки, об отказе или о необходимости загрузки документов в систему. Один из этих трёх вариантов на диаграмме придёт в одно событие.
Поэтому на диаграмму первым шагом добавляем шлюз XOR на дорожку "Клиент", из него пойдет разветвление потоков. Рассмотрим поток, при котором клиент должен загрузить документы.
Данный шлюз соединяем с событием "Сообщение о результате проверки" последовательным потоком.
Далее добавляем на нашу диаграмму на дорожку "Клиент" пользовательскую задачу "Загрузить документы". Также добавим объект данных "Документы", так как при выполнении данной задачи загружаются определенные документы в систему. И соединяем объект данных "Документы" связью ассоциации с пользовательской задачей.
Далее по условию: если приходит сообщение об одобрении или отказе, то для клиента процесс завершается. На текущем этапе это, скажем так, небольшая заглушка, делаем её для того, чтобы не пропускать потоки шлюза. Добавляем на нашу диаграмму конечное событие (пустое), которое означает завершение процесса. И соединяем данное событие со шлюзом условным потоком. В дальнейших заданиях вернёмся к данным потокам и усовершенствуем их.
Задание 10. Проверка документов системой
Описание задания: Система проверяет документы.
Рекомендация для выполнения задания:
Используй сервисную задачу.
После неё — XOR-шлюз (корректны / нет).
Реализуй возврат по потоку.
Решение
Подумай:
Объясни цикл через поток, а не маркер.
Объяснение
Следующим шагом, после того как клиент загрузил документы, система должна их проверить — это сервисная задача.
Сервисную задачу по проверке загруженных документов выполняет система ДБО. Добавим сервисную задачу "Проверить документы" на дорожку "Система ДБО" и соединим с пользовательской задачей по загрузке клиентом документов последовательным потоком. Также на вход проверки у нас подаются документы, соединим объект данных "Документы" с добавленной сервисной задачей связью ассоциации, причем стрелочка направлена от объекта к задаче.
При проверке документов системой процесс может пойти двумя условиями:
Документы корректны — система подтверждает, что документы соответствуют требованиям
Документы некорректны — система должна повторно запросить документы у клиента
Положительный путь на данном этапе пока что пропустим – реализуем в конце для него заглушку, как в предыдущем пункте.
Рассмотрим условие, когда документы некорректны.
При некорректном пути, система должна повторно запросить документы у клиента. Повторный процесс на BPMN диаграмме мы можем реализовать:
С помощью цикла через поток
С помощью маркера
Мы будем реализовывать с помощью цикла через поток. Под нашу ситуацию реализация с помощью маркера не подходит, так как маркер повторного цикла ставится на одну задачу, которая повторяется, пока не выполнится условие. Использование цикла через поток позволяет явно отразить бизнес-логику повторного взаимодействия клиента и системы, а также сохранить прозрачность процесса. Это упрощает понимание модели и делает её более гибкой для дальнейшего расширения, например, добавления тайм-аутов или ограничений на количество попыток.
В нашем случае, если процесс проверки загруженных документов не пройден, то клиент снова должен загрузить документы, то есть в цикле участвуют две задачи (пользовательская и сервисная).
Итак, реализуем цикл повторного запроса документов, соединяем шлюз XOR последовательным потоком с пользовательской задачей клиента "Загрузить документы". Данный поток подпишем "Документы некорректны".
Возвращаемся к положительному пути, реализуем заглушку. Соединяем наш шлюз с конечным событием условным потоком.
Задание 11. Тайм-аут ожидания документов
Описание задания: Если документы не загружены за 5 дней — заявка закрывается.
Рекомендация для выполнения задания:
Используй граничное прерывающее таймер-событие.
Веди поток к конечному событию отказа.
Решение
Подумай:
Объясни выбор прерывающего таймера.
Объяснение
Когда клиенту приходит сообщение о запросе на загрузку документов в систему, то на это действие отводится 5 дней. Также, если клиент загрузил документы, но система выявила, что документов не хватает, и процесс возвращается в пользовательскую задачу по загрузке документов, то на это также отводится 5 дней.
Если по истечении 5 дней документы не были загружены, то процесс завершается. Для построения диаграммы на данном шаге нам потребуется прерывающее граничное событие с типом таймер, так как у нас ограничение по времени, после истечения которого процесс прерывается и завершается. Непрерывающий таймер в данном случае не подходит, так как он позволил бы процессу продолжать выполнение пользовательской задачи даже после истечения установленного срока, что противоречит бизнес-логике процесса.
Добавляем на диаграмму промежуточное событие "Таймер" и размещаем его на рамке пользовательской задачи "Загрузить документы", так как именно на эту пользовательскую задачу отводится 5 дней. Тип данного прерывающего события — "Timer boundary event".
Размещение таймера на рамке пользовательской задачи позволяет автоматически применять ограничение времени ко всем итерациям выполнения задачи, включая повторные попытки загрузки документов. Это делает модель устойчивой к изменениям сценария и избавляет от необходимости дублировать таймеры в каждом цикле.
Далее, соединяем прерывающее событие с конечным событием последовательным потоком.
Задание 12. Консолидация решений
Описание задания: Все одобрения сходятся в один поток.
Рекомендация для выполнения задания:
Используй XOR для объединения.
Решение
Подумай:
Объясни отличие объединения от выбора.
Объяснение
На данном этапе нам нужно вернуться к нашим двум заглушкам из 9 и 10 задания по успешным условным потокам и обработать их. Успешные потоки у нас собираются воедино.
Выбор и объединение потоков в BPMN выполняют разные логические функции, даже если для этого используется один и тот же тип шлюза.
При выборе (разветвлении) шлюз определяет, по какому из альтернативных сценариев пойдёт процесс, исходя из условий. В этот момент принимается решение, и активируется только один из возможных потоков.
При объединении (схождении) шлюз не принимает новых решений, а лишь собирает ранее разветвлённые альтернативные потоки в одну точку продолжения процесса. В данном случае используется XOR, так как в объединяемую точку может прийти только один из потоков — либо после автоматического одобрения, либо после одобрения по результатам загрузки документов.
Добавляем на нашу диаграмму шлюз XOR, разместим его на дорожке "Система ДБО", так как далее процесс пойдёт по данной дорожке.
Переделываем связи, которые идут в конечное событие от двух шлюзов:
Шлюз, который стоит после сервисной задачи по проверке загруженных документов клиентом в систему — убираем его поток с конечным событием и соединяем потоком с новым шлюзом
Шлюз, который расположен после события получения сообщения на дорожке "Клиент" должен разветвлять поток на 3 (одобрено, отказано, запрос документов). Поэтому от него просто ведём новый поток к новому шлюзу
Таким образом, мы с помощью нового шлюза XOR соединили воедино положительные потоки предыдущих этапов.
Задание 13. Формирование договора
Описание задания: Система формирует договор.
Рекомендация для выполнения задания:
Используй сервисную задачу.
Добавь объект данных "Кредитный договор".
Решение
Подумай:
Объясни артефакт договора.
Объяснение
На данном этапе, после соединения положительных потоков, следующим шагом система формирует договор.
Формирование договора — это сервисная задача. Добавляем сервисную задачу "Сформировать договор" на дорожку "Система ДБО". Соединим её последовательным потоком с последним (соединяющим) шлюзом.
Добавим на диаграмму объект данных "Договор" и соединим связью ассоциации с сервисной задачей по формированию договора.
Артефакт "Договор" в данном процессе оформлен как объект данных, так как он является результатом выполнения сервисной задачи по формированию договора. Объект данных позволяет зафиксировать факт создания документа и отразить его как информационный результат шага процесса, не влияя при этом на управление потоком выполнения.
Использование объекта данных, а не хранилища, подчёркивает, что на данном этапе договор только формируется и передаётся дальше по процессу, а не сохраняется как устойчивое состояние системы. В дальнейшем этот объект может быть использован как вход для следующих шагов процесса, например, для подписания договора клиентом.
Задание 14. Подписание договора
Описание задания: Клиент подписывает или отказывается.
Рекомендация для выполнения задания:
Используй пользовательскую задачу.
После — XOR-шлюз.
Решение
Подумай:
Объясни юридическую точку процесса.
Объяснение
После формирования договора, клиент может:
Подписать договор
Отказаться от подписания договора
На дорожку "Клиент" добавляем пользовательскую задачу "Подписать договор". Соединяем её с сервисной задачей по формированию договора последовательным потоком.
Учитывая, что клиент может отказаться от подписания договора, то после пользовательской задачи добавляем шлюз XOR для разветвления процесса. Соединяем последовательным потоком пользовательскую задачу клиента по подписанию договора с данным шлюзом.
Подписание договора является юридической точкой процесса, так как именно в этот момент между банком и клиентом возникают взаимные юридические обязательства. До подписания договор существует только как проект документа и не имеет правовой силы.
Фиксаци�� данного шага в виде отдельной пользовательской задачи позволяет явно обозначить момент, после которого процесс переходит из стадии рассмотрения заявки в стадию исполнения обязательств. В случае отказа клиента от подписания договора дальнейшее выполнение процесса теряет смысл и должно быть завершено.
Выделение подписания договора как отдельного шага также важно для последующего моделирования ответственности, аудита и правовых рисков, так как именно с этого момента возможны финансовые операции и обслуживание кредита.
Задание 15. Отказ от подписания
Описание задания: Процесс завершается отказом.
Рекомендация для выполнения задания:
Используй конечное событие отмены (Cancel End Event).
Решение
Подумай:
Объясни выбор типа конечного события.
Объяснение
На данном этапе клиент отказывается от подписания договора, в этом случае процесс завершается (отменой со стороны клиента).
В данном сценарии используется конечное событие типа Cancel, так как процесс завершается по инициативе клиента. Отказ от подписания договора является осознанным действием участника процесса, а не результатом системной ошибки или технического сбоя.
Cancel End Event позволяет явно зафиксировать, что процесс был прекращён по бизнес-причине, связанной с решением клиента, и не требует дальнейшей обработки или компенсационных действий со стороны системы.
Для начала оптимизируем потоки, которые идут в событие завершения процесса, так как у нас два потока идут в одно событие. Добавим на диаграмму шлюз XOR которые соединит эти два потока.
Далее, добавим ещё один шлюз XOR, который будет соединять поток, от предыдущего только что созданного шлюза и поток, который идёт от шлюза, в случае когда клиент отказывается от подписания договора.
Конечным шагом мы соединяем потоком конечный шлюз и событие окончания процесса.
Задание 16. Выдача кредита
Описание задания: Средства зачисляются клиенту.
Рекомендация для выполнения задания:
Используй сервисную задачу.
Решение
Подумай:
Объясни автоматический характер операции.
Объяснение
После того как клиент подписывает договор, на его счет автоматически зачисляются денежные средства.
Зачисление денежных средств моделируется как сервисная задача, так как данная операция выполняется автоматически банковскими системами после наступления юридически значимого события — подписания договора клиентом.
На данном этапе не требуется принятие решений или ручные действия со стороны сотрудников банка или клиента. Процесс зачисления средств инициируется системой и выполняется в соответствии с заранее заданными бизнес-правилами и настройками, что делает использование пользовательской или ручной задачи некорректным.
Добавляем на диаграмму сервисную задачу "Зачислить средства клиенту" на дорожку "Система ДБО".
Соединяем данную задачу со шлюзом, который разветвляет потоки после подписания или отказа от подписания договора клиентом, условным потоком.
Также, можно добавить объект данных "Зачисленные средства" и связать потоком ассоциации с сервисной задачей "Зачислить средства клиенту", так как при выполнении данной задачи, клиенту на счет происходит зачисление денежных средств.
Задание 17. Запуск обслуживания кредита
Описание задания: Начинается обслуживание кредита.
Рекомендация для выполнения задания:
Используй встроенный подпроцесс с маркером.
Решение
Подумай:
Объясни смысл подпроцесса.
Объяснение
После того, как клиенту зачислены средства, наступает подпроцесс "Обслуживание кредита", это встроенный подпроцесс.
Подпроцесс "Обслуживание кредита" используется для логического отделения этапа выдачи кредита от этапа его дальнейшего сопровождения. До зачисления средств процесс направлен на принятие решения и оформление обязательств, тогда как после зачисления начинается новый этап жизненного цикла кредита — его обслуживание.
Выделение обслуживания кредита в отдельный подпроцесс позволяет явно зафиксировать смену фазы процесса и упростить основную диаграмму, так как дальнейшие действия могут быть длительными, повторяющимися и значительно более сложными. Подпроцесс служит контейнером для этих операций и делает модель более читаемой и управляемой.
Встроенный подпроцесс на диаграмме обозначается в скрытом, либо раскрытом виде. На первый раз отрисуем подпроцесс в раскрытом виде.
В данном случае используется встроенный подпроцесс, а не Call Activity, так как обслуживание кредита является логическим продолжением текущего процесса и не предполагает повторного использования в других процессах на данном этапе моделирования. Добавляем на диаграмму подпроцесс с типом "Expanded sub process" — раскрытый подпроцесс, на дорожку "Система ДБО". Назовем его "Обслуживание кредита". Стартовое событие в подпроцессе добавляется автоматически, оставим пока его.
Далее соединяем сервисную задачу "Зачислить средства клиенту" со встроенным подпроцессом последовательным потоком.
Задание 18. Плановый платёж
Описание задания: Клиент вносит платёж по графику.
Рекомендация для выполнения задания:
Используй таймер-стартовое событие подпроцесса.
Используй пользовательскую задачу.
Решение
Подумай:
Объясни периодичность.
Объяснение
Кредит клиентом выплачивается с определенной периодичностью, как правило, каждый месяц. То есть каждый месяц клиент вносит ежемесячный платёж.
Возвращаемся к нашему подпроцессу "Обслуживание кредита". В подпроцессе обязательно должно быть начальное событие — оно добавилось автоматически при создании встроенного подпроцесса.
Далее, так как у нас подпроцесс имеет периодичность — каждый месяц, то нужно добавить событие таймера внутри подпроцесса с типом "Timer Intermediate Catch Event". Данное событие позволяет настраивать различные временные интервалы (например, ежемесячные, ежеквартальные и тд), что делает его более гибким для обработки платежей по графику. Важно понимать, что периодичность не реализуется через цикл по условию, так как повторение шага определяется не логическим условием, а наступлением конкретного момента времени.
Соединяем данное событие с начальным событием подпроцесса последовательным потоком. Добавляем пользовательскую задачу "Внести платёж" в подпроцесс, так как платёж вносит клиент банка. И соединяем данную задачу с событием таймера последовательным потоком.
Важно! Следует заметить, что логически, стартовым событием подпроцесса можно было бы сразу поставить событие таймера, но, по правилам построения BPMN, Camunda Modeler не пропустит такое построение. Именно поэтому, мы подпроцесс начали с пустого стартового события.
Задание 19. Серия плановых платежей по кредиту
Описание задания:
В рамках обслуживания кредита клиент вносит ежемесячный платёж в соответствии с графиком. Платёж повторяется до полного погашения кредита.
Рекомендация для выполнения задания:
В подпроцессе "Обслуживание кредита":
используй промежуточное событие таймера (Timer Intermediate Catch Event) для ожидания даты платежа;
добавь пользовательскую задачу "Внести платёж";
после задачи используй исключающий шлюз (XOR) с проверкой условия:
"Кредит погашен полностью?"
Нет — возврат к событию таймера;
Да — выход из подпроцесса обслуживания.
Решение
Подумай:
Объясни, почему повторяемость платежей моделируется через таймер, а не через multi-instance.
Объясни отличие повторения по времени от повторения по набору элементов.
Объясни, почему каждый платёж является отдельным шагом процесса.
Объяснение
Серия плановых платежей по кредиту — это многократное последовательное внесение платежей клиентом с определенной периодичностью (раз в месяц). Обратим внимание на то, что платежи выполняются последовательно, параллельно платежи вноситься не могут. То есть, после того, как внесен первый ежемесячный платёж по кредиту, только после этого становится доступен к погашению второй платёж и тд. Именно поэтому каждый платёж является отдельным шагом процесса.
Также кредитные соглашения часто предполагают последовательность платежей, так как каждый платеж может влиять на условия кредита, например, размер остатка долга. Параллельные платежи могут нарушить эти условия и усложнить учёт.
За цепочку платежей у нас будет выступать наше промежуточное событие-таймер в данном подпроцессе.
После пользовательской задачи добавим шлюз XOR, который будет разветвлять наш поток. Соединяем данный шлюз с пользовательской задачей по внесению платежа.
Далее, отобразим положительную ветку потока (кредит погашен) — добавим завершающее событие и соединим его условным потоком со шлюзом.
Для отрицательного потока (кредит не погашен) соединим шлюз с промежуточным событием таймера. То есть, если система при проверке погашения кредита понимает, что он ещё не погашен, то поток переходит на событие таймера, и когда наступает дата ежемесячного платежа, то выполняется вновь пользовательская задача "Внести платёж".
В целом, система при выполнении задачи по внесению платежей, будет проверять, погашен ли кредит. Далее поток пойдёт по одному из условий:
Если кредит погашен — переход к конечному событию
Если не погашен, переход к промежуточному событию таймера
Почему мы моделируем повторяемость платежей через таймер, а не, к примеру, через задачу мультиинстанса? Мы помним о том, что у нас есть определенное кол-во платежей, допустим кредит взят на 1 год — это 12 платежей, если мы данное кол-во укажем в мультиинстансе, то при наступлении задачи платежа она будет выполняться 12 раз подряд, поток не пойдет на цикл. А в нашем случае, мы в событии таймера сможем задать четкий временной интервал между платежами, например, раз в месяц, и при выполнении первого платежа(кредит не погашен), поток вернется к таймеру, дождется наступления определенной даты и вновь запустит задачу по внесению платежа.
Таким образом, мы используем подход повторения по времени, а не по набору элементов. Так как подход повторения по времени основан на определенном расписании или времени.
Задание 20. Просрочка очередного платежа
Описание задания: Если клиент не внёс очередной платёж в установленный срок, наступает сценарий просрочки.
Рекомендация для выполнения задания:
Используй граничное прерывающее таймер-событие на задаче "Внести платёж".
При срабатывании таймера:
добавь промежуточное событие отправки сообщения "Уведомление о просрочке";
направь поток к обработке просрочки.
Решение
Подумай:
Объясни, почему таймер является граничным.
Объясни, почему событие является прерывающим.
Объясни отличие просрочки от штатного сценария.
Объяснение
В процессе, когда вносятся последовательные платежи, клиент может в любой момент просрочить платёж. В этот момент система должна отправить клиенту уведомление о просрочке платежей — напоминание о том, что необходимо внести платёж. То есть основной процесс внесения платежей прерывается, и наступает "внештатная ситуация".
С точки зрения процесса, как это выглядит:
Выполняются последовательные задачи по внесению платежей в установленный срок;
При наступлении очередного срока, платёж не поступил;
Последовательный цикл выполнения задач по внесению платежей прерывается;
Клиенту отправляется уведомление о необходимости внесения платежа;
Клиент может внести платеж, либо игнорировать внесение платежа (длительная просрочка).
Отобразим это на нашей диаграмме. Добавляем на рамку пользовательской задачи "Внести платёж" прерывающее таймер-событие, которое будет прерывать наш процесс. Далее добавляем промежуточное событие по отправке сообщения "Уведомление о просрочке". Соединяем последовательным потоком данные события.
На дорожке "Клиент" добавляем ожидающее промежуточное событие получения сообщения "Сообщение о просрочке", которое срабатывает при отправке соответствующего сообщения системой. Конечное событие также добавляем на нашу диаграмму и соединяем с данным подпроцессом — это путь, когда кредит выплачен.
Далее, добавляем ещё один шлюз XOR, который будет разветвлять поток клиента:
Клиент вносит платёж
Клиент игнорирует внесение платежа (рассмотрим в следующем задании)
Для пути, когда клиент вносит платеж после получения сообщения, ведем поток от шлюза в соединяющий шлюз XOR, который мы также добавили на поток между подпроцессом и системной задачей "Зачислить средства клиенту".
Таким образом, мы реализовали выполнение оповещения клиента о просрочке внесения платежа.
Задание 21. Эскалация длительной просрочки
Описание задания: Если просрочка сохраняется длительное время, процесс передаётся специалисту по работе с задолженностью.
Рекомендация для в��полнения задания:
Используй событие эскалации (Escalation Event).
Добавь дорожку "Специалист по задолженности".
Передай управление процессом в эту дорожку.
Решение
Подумай:
Объясни, почему используется эскалация, а не ошибка.
Объясни бизнес-смысл передачи процесса человеку.
Объясни отличие эскалации от отмены процесса.
Объяснение
Когда клиент продолжительное время игнорирует необходимость внесения платежа, такая ситуация требует вмешательства. В этом случае дело передается сотруднику по задолженности, который должен предпринять соответствующие меры для влияния на клиента, не исполнившего свои обязательства.
Добавим новую дорожку в наш пул и назовем её "Сотрудник по задолженности".
Далее, возвращаемся к событию получения клиентом сообщения о просрочке. После того, как пользователю отправлено сообщение, используется промежуточное событие таймера, которое срабатывает при превышении установленного срока просрочки. Как только просрочка дойдет до N-ого порога, наступает событие эскалации. Данное событие используется, например, если определенная задача не выполнена в установленный срок — это как-раз наш случай.
Соответственно, когда наступает событие эскалации, то поток переходит к сотруднику по задолженности.
Отобразим на нашей диаграмме добавляем промежуточное событие таймера "Timer intermediate catch event", назовем его "Просрочка превышает N дней" на дорожку "Система ДБО". Соединим данное событие с событием получения клиентом сообщения о просрочке последовательным потоком. Далее, после события таймера добавляем событие эскалации и соединяем их последовательным потоком.
От события эскалации поток пойдет на дорожку "Сотрудник по задолженности" — детализация будет в следующем задании, а пока, для заглушки, добавим на данную дорожку пользовательскую задачу "Обработать задолженность". Соединим задачу с событием эскалации последовательным потоком.
Задание 22. Параллельные действия при просрочке
Описание задания: При работе с просрочкой одновременно выполняются несколько действий:
уведомление клиента;
переговоры о способе погашения;
расчёт штрафов.
Рекомендация для выполнения задания:
Используй параллельный шлюз (AND) для запуска действий одновременно.
Каждое действие оформи отдельной задачей.
Решение
Подумай:
Объясни, почему действия выполняются параллельно.
Объясни, почему нельзя использовать XOR.
Объясни влияние параллельности на длительность процесса.
Объяснение
При наступлении события эскалации поток переходит на дорожку сотрудника по задолженности, который в свою очередь предпринимает ряд действий:
Уведомляет клиента о просрочке
Переговаривает с клиентом о способе погашения задолженности
Рассчитывает штраф за просрочку
Важно учитывать, что на диаграмме мы это отобразим параллельными задачами, так как все они выполняются параллельно, к примеру, сотрудник может рассчитать штраф во время переговоров с клиентом о способе погашения и т.д. Параллельность в данном случае не держит процесс поэтапно, а выполняется скупом, что гораздо сокращает время обработки.
На дорожку "Сотрудник по задолженности" добавим параллельный шлюз вместо пользовательской задачи — заглушки "Обработать задолженность", далее добавим три пользовательские задачи:
"Уведомить клиента"
"Переговорить о способе погашения"
"Рассчитать штраф"
Соединим 3 пользовательские задачи с параллельным шлюзом. И не забываем после параллельных задач добавить ещё один параллельный шлюз (закрывающий).
Задание 23. Сложное урегулирование задолженности
Описание задания: По результатам работы с просрочкой возможны разные комбинации условий:
клиент готов к реструктуризации;
долг частично погашен;
превышен срок критической просрочки.
Решение зависит не от одного условия, а от их комбинации.
Рекомендация для выполнения задания:
Используй Сложный шлюз — Complex Gateway.
Опиши условия переходов как комбинации:
реструктуризация;
взыскание;
продолжение переговоров.
Решение
Подумай:
Объясни, почему XOR недостаточен.
Объясни, почему OR не отражает бизнес-логику.
Объясни назначение Complex Gateway.
Объяснение
После выполнения параллельных задач по обработке просрочки возможны различные комбинации потоков:
Реструктуризация долга
Взыскание долга
Дальнейшие переговоры с клиентом
Система должна принять решение, которое зависит не от одного условия, а от комбинации нескольких признаков. Для этого нам потребуется сложный шлюз "Complex Gateway".
В сервисной задаче "Оценить статус задолженности и готовность клиента" формируются три булевых признака:
A = Клиент готов к реструктуризации? (Да/Нет)
B = Долг частично погашен? (Да/Нет)
C = Превышен срок критической просрочки? (Да/Нет)
Дальнейший сценарий определяется их сочетанием.
Если брать шлюз XOR, то он нам в данном случае не подходит. XOR позволяет выбрать только один поток на основании одного логического условия.
В нашем случае решение может приводить:
либо к одному действию,
либо к двум действиям одновременно.
Следовательно, XOR не способен корректно отразить комбинированный сценарий.
Inclusive Gateway (OR) запускает несколько потоков, если их условия истинны, но он не предназначен для явного управления логикой сложных комбинаций, когда необходимо точно контролировать, какие наборы действий активируются в зависимости от конкретных сочетаний признаков. Соответственно OR тоже не подходит.
В нашем случае бизнес-логика требует явного описания комбинаций условий, поэтому используется Complex Gateway.
От Complex Gateway исходят следующие потоки:
Поток 1 (к задаче "Взыскать долг") : C = Да AND (A = Нет OR B = Нет)
Поток 2 (к задаче "Реструктуризировать долг") : A=Да AND B=Да AND C=Нет
Поток 3 (к задаче "Провести дополнительные переговоры") : A = Нет AND C = Нет
Поток 4 (к задачам "Реструктуризировать долг" и "Провести дополнительные переговоры") : A=Да AND B=Нет AND C=Нет
В комбинированном случае (Поток 4) Complex Gateway порождает два токена выполнения:
один запускает задачу "Реструктуризировать долг",
второй — задачу "Провести дополнительные переговоры".
Таким образом, одна и та же логическая комбинация указана на двух исходящих потоках, что является корректным при использовании Complex Gateway и отражает параллельный запуск двух действий в рамках одного решения.
После выполнения соответствующих задач используется Complex Gateway (join), который:
продолжает процесс после завершения одной задачи, если был выбран одиночный сценарий;
ожидает завершения обеих задач в случае комбинированного сценария.
Далее выполняется сервисная задача "Зафиксировать решение и обновить статус задолженности", которая фиксирует результат выбранной стратегии урегулирования.
Задание 24. Успешное завершение кредита
Описание задания: Если в рамках обслуживания кредита сумма задолженности полностью погашена, процесс завершается успешно.
Рекомендация для выполнения задания:
Используй условие на шлюзе в подпроцессе "Обслуживание кредита":
"Кредит погашен полностью?"
При положительном результате направь поток к конечному событию.
Используй None End Event (стандартное завершение процесса).
Решение
Подумай:
Объясни бизнес-смысл завершения процесса.
Объясни, чем успешное завершение отличается от отмены.
Объясни ценность явного финала процесса.
Объяснение
После того, как кредит полностью погашен, обязательства сторон выполнены — процесс завершается.
После сервисной задачи "Зафиксировать решение и обновить статус задолженности" поток расходится на два пути, так как по итогу может быть два условия:
Кредит погашен полностью
Кредит полностью не погашен
В подпроцессе "Обслуживание кредита" на дорожке "Система ДБО" у нас уже имеется шлюз с данной проверкой, поэтому в нашем случае, будет достаточно соединить сервисную задачу "Зафиксировать решение и обновить статус задолженности" с подпроцессом "Обслуживание кредита" последовательным потоком.
Задание 25. Аварийное завершение процесса
Описание задания: В процессе обслуживания кредита произошла критическая ошибка системы (например, сбой расчётов или повреждение данных).
Рекомендация для выполнения задания:
Используй Конечное событие ошибки — Error End Event.
Приведи к нему поток из исключительного сценария.
Решение
Подумай:
Объясни отличие ошибки от отмены (Cancel).
Объясни, почему процесс не может быть продолжен.
Объясни, зачем фиксировать аварийное завершение явно.
Объяснение
Переходим в подпроцесс "Обслуживание кредита".
После каждого внесённого клиентом платежа система автоматически пересчитывает график ежемесячных платежей. Для этого добавляется сервисная задача "Обновить график платежей", которая располагается после пользовательской задачи "Внести платёж".
После выполнения данной задачи необходимо проверить корректность обновления графика. Для этого добавляется исключающий шлюз (XOR) "График обновлён?", который разделяет поток:
Да — процесс продолжается к проверке "Кредит погашен?"
Нет (ошибка) — выбрасывается Error End Event "Ошибка расчётов"
Сервисная задача выполняется автоматически, однако в процессе расчёта может произойти критический системный сбой (например, ошибка расчётов или повреждение данных). В таком случае дальнейшее выполнение подпроцесса становится невозможным.
Поэтому при отрицательном исходе проверки используется завершающее событие ошибки (Error End Event) внутри подпроцесса.
Так как ошибка возникает внутри подпроцесса, на его рамке добавляется Boundary Error Event, который перехватывает выброшенную ошибку.
От Boundary Error Event проводится последовательный поток к финальному Error End Event родительского процесса - это обозначает аварийное завершение всего процесса обслуживания кредита.
Почему используется критическая ошибка, а не, к примеру, отмена? Отмена — это преднамеренное действие, результат которого можно обозначить, а критическая ошибка — это непредвиденный сбой системы, результат которого – принудительное завершение процесса.
Ссылка на скачивание цельной диаграммы и полного текста тренажёра в формате .pdf: Тренажёр BPMN
Расскажите, зашёл ли подобный формат тренажёра? Было бы интересно увидеть реализацию на Java или, возможно, описание какого-либо другого процесса? Обязательно пишите в комментариях! Мы в команде обожаем учиться и делиться полезными обучалками с другими!
