Рисунок 6. Основные шлюзы.
Если шлюз стоит перед задачей, то он управляет входом в эту задачу, если после, то расшифровывает логику выхода из этой задачи.
Например, нам нужно на графике отобразить такую ситуацию: Если «все требования выполнены» (товар оплачен, менеджер подтвердил отгрузку), то «совершить отгрузку» (нижняя часть графики). ИЛИ «Оплата товара не произведена» и «необходимо сообщить об этом менеджеру» (Рис. 7. Пример исключающего ИЛИ на выходе)
Рисунок. 7. Пример исключающего ИЛИ на выходе.
Этот же шлюз может быть расположен перед задачей, тогда он будет читаться по-другому (справедливости ради, в этой ситуации его можно заменить OR (ИЛИ), но это задаёт тонкости прочтения, пока их опустим). Например, у нас вот такая ситуация: Мы проводим проверку зарезервированных товаров под заказы. Среди них мы обнаруживаем те, у которых срок резервирования просрочен более, чем на 3 дня. Их мы должны снять с резерва. Кроме того есть заказы, по которым срок резерва вышел сегодня или вчера. В отношении этих заказов нужно связаться с клиентом. В результате этого, часть заказов нужно будет снять с резерва, а часть оставить. В графике это будет выглядеть так (см Рис. 8. Пример исключающего ИЛИ на входе).
Рисунок 8. Пример исключающего ИЛИ на входе.
Обратите внимание, что на выходе применён “Исключающий ИЛИ” с маркером (“Х” в ромбе), а на входе в задачу «Снятие товара с резерва» просто пустой ромб. Хотя и то, и другое обозначение относятся к одному и тому же Шлюзу, применение разных обозначений более наглядно – графика подсказывает вам, что “Х” в ромбе – это исходящий Шлюз, а пустой ромб – входящий. Входящее расположение XOR указывает на то, что «снятие товара с резерва» выполняется тогда, когда срок резерва просрочен на 3 и более дней. Кроме того, если резерв по каким-либо причинам не актуален, то мы тоже снимаем товар с резерва.
Обратите внимание на ещё один момент. Положительный сценарий развития БП отмечен зелёными стрелками, а негативный – красными. Хотя этот момент особо не оговаривается в нотации, всё же стоит добавить немного цвета графике. Она так лучше читается. Кроме того, когда это становится привычным, окрас стрелок может подсказывать.
Нам осталось разобраться с примерами шлюза “И”. Если этот шлюз у нас стоит после задачи (исходящий), то значит далее будет происходить 2 параллельных процесса. Например, менеджер нашёл нового клиента. Нам нужно проверить его юридическую надёжность и прояснить модель его бизнеса. На основании этого, мы сможем выбрать подходящий тип дилерского договора. Собственно, в этом примере мы увидим сразу и исходящий, и входящий вариант этого шлюза (Рис. 9. Пример “И” на входе и выходе). Обратите внимание, что на входе этот шлюз указывает, что пока у нас не завершатся все процессы, входящие в этот шлюз, дальнейшее прохождение БП не допускается. Мы не можем выбрать условия дилерского соглашения, пока не понимаем, чем занимается наш потенциальный партнёр и пока не проверили, находится его организация под судом или нет.
Рисунок 9. Пример “И” на входе и выходе.
Теперь давайте разберёмся со стрелками и дорожками.
В полной версии BPMN существует порядка 6 видов стрелок. Мы будем пользоваться только двумя основными. Один вид – это стрелки, показывающие основной поток БП (поток управления), а второй вариант – это стрелки, показывающие движение сообщений или документов (Поток сообщений).
Прежде чем приводить примеры стрелок, нужно разобраться с ещё одним понятием – это дорожки и пулы. Эти элемент очень важен, и он играет не последнюю роль в столь высокой популярности BPMN.
Начнём с пула.
Этот элемент графики может быть в свёрнутом и развёрнутом состоянии. Если развёрнутый пул можно считать обычной рамкой на листе и своеобразным заголовком, то вот свёрнутый играет большую роль в правильном прочтении графики. Свернутый пул позволяет нам увидеть взаимосвязь между процессами, обмен информацией между ними.
Дорожка – показывает исполнителя процесса. Причём в качестве исполнителя может выступать как конкретный человек (сотрудник, должность), так и подразделение или отдел, а в некоторых случаях и организация.
Например, мы описываем процесс обработки заказа клиента с рассрочкой. Нам требуется принять заявку и определить итоговую сумму заказа. Поставить товары на резерв, согласовать с руководителем отдела, и если всё ок, согласовать условия с клиентом. Если его всё устраивает, то проработать сделку с юристом.
Юрист у нас как раз и будет представлен в форме свёрнутого Пула. Он “живёт” в БП “Подготовка юридически значимых документов”. Сам процесс выполняется в рамках отдела продаж (это дорожка, разбитая на ещё 2 дорожки). Одна принадлежит исполнителю (менеджер по продажам), а другая руководителю отдела – он у нас оценивает клиента и разрешает сделку.
Рисунок 10. Примеры Пула, Потока сообщений, Ассоциаций и Дорожек.
Дорожками удобно демонстрировать акценты функционала. В нашем примере (Рис. 10) мы показываем, что менеджер согласует рассрочку с руководителем отдела, а тот, в свою очередь, проверяет благонадежность клиента (в данном случае мы убираем предвзятость) и определяет варианты сделки.
Чтобы показать принадлежность менеджера и руководителя к одному отделу, мы их Дорожки объединили в общую дорожку “Отдел продаж”. Такой вариант более нагляден, позволяет обеспечить однозначность прочтения графики.
На мой взгляд, наглядность, чёткость прочтения, отсутствие двойственности – это обязательные условия хорошего БП. Это правило относится и к графике, и к тексту.
Обратите внимание, что у нас присутствует Исключающее ИЛИ. Этот шлюз иллюстрирует возможные особенности благонадежности клиента. Если бы мы следовали классическому варианту визуализации БП, то нужно было бы эту информацию отразить как свёрнутый БП. Мы бы его назвали “Установление условий сделки”. Это связано с тем, что в классическом варианте на графике, на одном условном листе должно быть не более 6 объектов. В некоторых случаях это оправданно, особенно если мы проектируем исполняемый БП (это тот, который применяется непосредственно для создания программных продуктов), но когда мы проектируем бизнес-процесс, чтобы описать порядок работы организации, то именно это правило может помешать. Дефицитная графика, а следовательно, и описание, может внести сумятицу и помешать корректному восприятию логики работы. На практике нередко приходится сталкиваться с такой ситуацией.
Нотация EPC
EPC (event-drivenprocesschain) - событийная цепочка процессов. Вся суть этой нотации, её отличительные особенности отражены в названии. Эта нотация содержит такую фигуру как событие. Именно с неё начинается диаграмма и заканчивается тоже ею. Именно вокруг “События” и возникает множество споров относительно этой нотации.
Конец ознакомительного фрагмента.
Текст предоставлен ООО «Литрес».
Прочитайте эту книгу целиком, купив полную легальную версию (https://www.litres.ru/chitat-onlayn/?art=70528003&lfrom=174836202&ffile=1) на Литрес.
Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.
