Разработка исполнимых бизнес-процессов - появление новой парадигмы программирования
Решения с непарными разделениями - слияниями
Несмотря на то, что предпочтительными решениями являются схемы с парными разделениями и слияниями, существуют ситуации, для которых решениями являются схемы с непарными разделениями-слияниями. В качестве примера такой ситуации рассмотрим бизнес-процесс организации конференции. Он состоит из следующих действий:
- Заключить договор аренды помещения
- Подготовить помещение к конференции
- Подготовить пригласительные материалы
- Впечатать в материалы конференции адрес
- Разослать материалы конференции
Действия, относящиеся к помещению и к печатным материалами, должны выполняться параллельно, однако впечатывание адреса в материалы конференции не должно выполняться до заключения договора аренды помещения, в котором будет проводиться конференция.
Схема бизнес-процесса, реализующая бизнес-процесс организации конференции представлена на Рис. 4.9. Видно, что одно разделение на схеме соответствует сразу двум слияниям и наоборот. При этом данная схема "не позволит" впечатать адрес в материалы до заключения договора аренды и "разрешит" готовить помещение даже если еще не готовы пригласительные материалы. При помощи использования парных разделений-слияний решить эту задачу нельзя.
Использование элемента "окончание бизнес-процесса"
Использовать элементы "окончание бизнес-процесса" предпочтительнее, чем элементы "завершение потока управления", так как в этом случае бизнес-аналитику легче анализировать схему выполняющегося экземпляра бизнес-процесса с нанесенными на нее точками управления. В случае прихода точки управления в элемент "окончание бизнес-процесса" экземпляр бизнес-процесса сразу завершается, в случае же использования элементов "завершение потока управления" бизнес-аналитику приходится затрачивать больше усилий для того, чтобы следить за тем, чтобы все точки управления пришли в элементы "окончание бизнес-процесса".
На основе элемента "окончание бизнес-процесса" можно строить процессные решения для некоторых ситуаций. Рассмотрим случай согласования документов: Три отдела должны согласовать документ. Каждый отдел может утвердить, или отклонить документ. Если любой отдел отклоняет документ, то документ получает статус "не согласован" и согласование сразу же должно прекращаться. Рассмотрения документов другими отделами уже не требуется.
Согласование всеми отделами должно происходить параллельно, порядок одобрения в данном бизнес-процессе не важен. На Рис. 4.10 представлена схема, использование которой внутри подпроцесса решает поставленную задачу.
Согласно данной схеме любая точка управления, пришедшая в узел-Окончание "Отказано" в связи с отказом какого-то из отделов, остановит выполнение всего подпроцесса и, в частности, удалит точки управления из узлов, в которых производится согласование документа с двумя другими отделами. В случае положительного решения любого отдела точка управления попадает в элемент-Слияние, в котором "ждет" положительных решений от других отделов.
Пример "компромиссного" решения по разделениям-слияниям и использованию элемента "завершение потока управления"
Разработка исполнимых бизнес-процессов - искусство, подобное искусству традиционного программирования. Здесь нет готовых рецептов для всех возможных ситуаций. Во многих случаях решением оказываются компромиссные схемы сочетающие как использование предлагаемых в настоящей лекции рекомендаций, так и наличие некоторых исключений.
В качестве примера рассмотрим упрощенный бизнес-процесс розничного кредитования банка. Описание бизнес-процесса: Операционист вводит в стартовую форму данные заявки на кредит и запускает экземпляр бизнес-процесса. Далее задание "Верифицировать данные" выполняет Специалист-Верификатор. Он выбирает один из двух вариантов - Данные верифицированы / Данные не верифицированы.
В случае, если данные не верифицированы, Операционист знакомится с информацией об отказе в оформлении данного кредита, SMS-шлюз (автоматический исполнитель) выполняет задание "Уведомить заемщика об отказе", после этого бизнес-процесс завершается.
В случае, если данные верифицированы, далее задание "Определить риски" выполняет Сотрудник скорингового центра. В форме задания он выбирает один из двух вариантов - Риски приемлемы / Риски не приемлемы. В случае, если риски не приемлемы, Операционист знакомится с информацией об отказе в оформлении данного кредита, SMS-шлюз выполняет задание "Уведомить об отказе", после этого бизнес-процесс завершается.
В случае, если риски приемлемы, далее задание "Произвести проверку СБ" выполняет сотрудник службы безопасности. В форме задания он вводит результат проверки - один из четырех вариантов: "Отлично", "Хорошо", "Удовлетворительно", "Не удовлетворительно". В случае неудовлетворительного результата далее Операционист знакомится с информацией об отказе в оформлении данного кредита, SMS-шлюз выполняет задание "Уведомить об отказе".
Если результат не равен "Не удовлетворительно", то далее задание "Принять решение по кредиту" выполняет кредитный менеджер. Если он принял положительное решений, то
Оператор колл-центра информирует клиента о положительном решении по кредиту, одновременно Операционист выполняет задание "Оформить кредит", далее Бухгалтер выполняет задание "Зачислить средства". После этого бизнес-процесс завершается.
Если кредитный менеджер принял отрицательное решение, то операционист и сотрудник службы безопасности знакомятся с информацией об отказе в оформлении кредита, SMS-шлюз выполняет задание "Уведомить об отказе", после этого бизнес-процесс завершается.
Замечание. В данном бизнес-процессе не должно быть дублирования задач операционисту по ознакомлению с информацией об отказе и SMS-шлюзу "Уведомить заемщика об отказе". Каждая из этих задач должна соответствовать только одному узлу-действию
На Рис. 4.11 приведено "компромиссное" решение данной задачи. Оно содержит как парные разделения и слияния, так и непарное разделение, а также как узел окончания бизнес-процесса, так и два узла завершения потоков управления. Так получается потому, что в случае отказа кредитного менеджера появляется еще один исполнитель, которого надо проинформировать об отказе.
Использование алгоритмов в схеме бизнес-процесса
В силу того, что схемы бизнес-процессов очень похожи на блок-схемы алгоритмов, алгоритм решения некоторой задачи можно включить прямо в схему бизнес-процесса. Данный подход может быть применён при разработке как промышленных, так и учебных бизнес-процессов.
В качестве примера рассмотрим реализацию задачи об игре в камешки. Игра состоит в следующем: есть кучка в 100 камней. Игроки ходят по очереди. За один ход игрок должен взять из кучки не менее одного, но не более 9 камней. Тот, кто возьмет последний камень, является выигравшим. Надо разработать бизнес-процесс, реализующий игру в камешки. Также требуется придумать гарантированно выигрышную стратегию поведения игрока. В бизнес-процессе на форме задания каждому игроку должен находиться соответствующий стратегии совет от экземпляра бизнес-процесса, - какое количество камней игроку на данном ходе стоит взять из кучки. Если при данном количестве камней в кучке не существует "выигрышного" хода, то на форме должно содержаться сообщение "не могу дать совет". На Рис. 4.12 представлен пример бизнес-процесса, решающего данную задачу.
Контрольные вопросы
- За счет чего при внедрении исполнимых бизнес-процессов затраты на автоматизацию могут быть ниже, чем при традиционном подходе к автоматизации предприятия
- Почему скорость изменения ИТ-решения на основе исполнимых бизнес-процессов может быть выше, чем при традиционном подходе?
- Что надо постараться сделать для того, чтобы второстепенные действия не блокировали нормальное выполнение бизнес-процесса?