книги / Построение моделей бизнес-процессов

межуточное событие Условие наступает, когда счет получит статус «оплачен». После этого заказ доставляется, и процесс собственно продаж завершается успешно. При превышении тайм-аута ожидания заказ не доставляется. Также заказ не выполняется, если он не одобрен. Процесс обработки счетов запускается ежедневно. Сначала получают счета, затем в цикле очередной счет идентифицируют, и если он оплачен, то в записи счета делают пометку «оплачен». Если текущий счет не оплачен, то переходят к идентификации следующего счета. Оба процесса выполняются независимо, но при этом используют общую базу данных.

Рис. 98. Диаграмма процесса продаж

Рассмотрим диаграмму известной детской игры, показанной на рис. 99. В игре участвуют два игрока. Каждый из них в сессии выбирает один предмет из трех. Соотношение между предметами: камень «сильнее» ножниц, ножницы «сильнее» бумаги, бумага «сильнее» камня. При выбореодинаковых предметов никто не побеждает. Результат выбора определяется в задаче «Бизнес-правило», которая запускает механизм правил и получает от него данные о выигрыше

111

одного из игроков либо об отсутствии победителя. Если 2-й игрок не входитв игру в течение3 мин, то сессия не состоится.

Еще один пример с использованием бизнес-правил представлен на рис. 100. Заявитель, подавший заявление на страховой полис, проверяется на предмет риска для страховой компании.

Рис. 99. Диаграмма игры «Камень, ножницы, бумага»

Рис. 100. Обработка заявления на страховой полис

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

112

•Возврат значения «зеленый» означает отсутствие риска, и

вэтом случае заявителю будет выдан полис.

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

•Значение «красный» соответствует высокому уровню риска, и это влечет отказ в получении полиса.

На следующей диаграмме представлена модель процесса определения потребности клиента (рис. 101).

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

Вэтом случае возможны три варианта ответа клиента:

1)предлагает скорректировать заявку, тогда произойдет возврат к определению возможности ее выполнения;

2)согласует, что означает «заявка одобрена», и ее отправляют для подготовки коммерческого предложения (КП); процесс успешно завершается;

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

условию, хотя лучше поставить эксклюзивный шлюз.

113

114

Рис. 101. Процесс «Определение потребности клиента»

114

Обсудим фрагмент начальной части диаграммы, на котором показан раскрытый подпроцесс с циклом, о чем свидетельствует маркер у нижней границы подпроцесса (рис. 102). Подпроцесс Discussion Cycle включает действия по проведению дискуссии. Старт процесса происходит в пятницу. Просматривается начальный список вопросов (проблем), подлежащих обсуждению. Если он не готов, дискуссии не будет. Иначе выполняется подпроцесс Discussion Cycle, реализующий проведение дискуссии.

Рис. 102. Подпроцесс с циклом

Сначала объявляется список проблем для дискуссии. Затем поток операций разделяется на три параллельных потока (оператор И не показан): верхний поток запускает модерирование дискуссии по e-mail, которое может продолжаться 7 дней; средний поток запускает часы, и через 6 дней будет выдано предупреждение о крайнем сроке обсуждения по e-mail; в нижней ветви проверяется по календарю время проведения конференц-связи, и если оно совпадает с неделей дискуссии, то с 9 утра четверга модерируется дискуссия и по конференц-связи. После синхронизации трех потоков оценивается ход дискуссии: если не все проблемы успешно обсуждены, скорректированный список возвращается

115

для его объявления; если вопросы исчерпаны, подпроцесс завершается. Итоговый список передается на голосование.

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

Рис. 103. Процессы наёма персонала

Первый процесс в развернутом виде показан на рис. 104. Он начинается с возникновения потребности в новом сотруднике. Заинтересованный руководитель подает заявку на поиск кандидатов.

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

Диаграмма процесса оформления приема сотрудника на работу приведена на рис. 105. Менеджер по персоналу готовит и подписывает приказ о приеме на работу, затем оформляет трудовой договор. Действияофис-менеджераибухгалтераочевидны: записивтрудовую книжкуиличнуюкарточкусотрудникаиоткрытиелицевогосчета.

116

ГЛАВА 6. СРЕДСТВА МОДЕЛИРОВАНИЯ В НОТАЦИИ BPMN

За последние 10 лет благодаря международному признанию и популярности нотации BPMN появились десятки поддерживающих ее программ. Это и ранее существующие системы BPMS, дополнившие поддержку BPMN (например, ARIS), и новые платформы BPM (например, Bizagi, Omnitracker), а также локально устанавливаемые и онлайн-моделеры.

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

6.1. Camunda Modeler

Платформа Camunda предлагает несколько инструментов для разработки диаграмм и их реализации:

Облачный моделер (Cloud Modeler);

«Камунда моделер» (Camunda Modeler).

Cloud Modeler и Camunda Modeler различаются в основном своей средой. Cloud Modeler является частью Cloud Console и предлагает бесшовную интеграцию с Camunda Cloud для моделирования BPMN. Camunda Modeler — это настольное приложение, которое можно бесплатно установить и использовать локально. Представим кратко данный инструмент.

Camunda Modeler охватывает все элементы BPMN 2.0 для моделирования процессов и их взаимодействия (сотрудничества).

В начальном окне моделера предлагается создать диаграмму

BPMN или DMN, или CMMN. DMN (Decision Model and Notation) –

нотация и модель принятия решений, CMMN (Case Management Model and Notation) – нотация и модель управления кейсами (делами). Все три нотации являются детищами консорциума OMG. Это основные нотации, которых достаточно для реализации логики бизнес-процессов.

Видокнадля построениядиаграмм BPMN показан на рис. 107.

119