Теперь применим паттерн «групповая обработка» к исходной задаче –

Рис. 6. Групповая обработка товарных позиций

Один и тот же паттерн здесь применен дважды: для таможенного декларирования и для доставки.

Схема процесса таможенного декларирования –

Рис. 7. Процесс таможенного декларирования

Комментарии к схеме:

• Процесс запускается каждый час (например) и начинает с того, что выбирает из базы товарные позиции со статусом «К декларированию», установленным подпроцессом на рис. 6.
• Найденные товарные позиции группируются по заказам.
• В цикле по заказам проверяется, все ли товарные позиции прибыли на таможенный склад. Если да, подаем декларацию.
• Если какие-то позиции задерживаются, проверяем как долго мы уже их ждем. Если прошло больше 48 часов (например), подаем декларацию по прибывшим товарным позициям, не дожидаясь отставших.
• В противном случае завершаем работу экземпляра подпроцесса. Через час процесс запустится снова, и так до тех пор, пока либо прибудут все товарные позиции, либо истечет срок ожидания.
• Подав таможенную декларацию и получив ответ таможни, меняем статус товарной позиции, чтобы подпроцесс на рис. 6 пошел дальше.

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

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

Рис. 8. Диаграмма бизнес-способностей

Внимание: хотя на рис. 8 изображены значки из палитры BPMN, это НЕ диаграмма BPMN, а диаграмма в нотации бизнес-способностей (Business Capabilities Diagram).

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

Отвлечемся от исходной задачи и рассмотрим паттерн «групповая обработка» на более простом примере –

Рис. 4. Групповая обработка

Комментарии к схеме:

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

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

Рис. 5. Групповая обработка с циклом по объектам

К сожалению, моделер не может изобразить поток данных из задачи смены статуса внутри развернутого подпроцесса перевозки, поэтому стрелка к хранилищу данных идет от подпроцесса в целом.

(Продолжение)

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

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

Схема, предусматривающая такие возможности –

Рис. 3. Асинхронное оформление разрешительной документации

Комментарии к схеме:

• Работа над разрешительными документами запускается параллельно с обработкой товарных позициях в цикле по объектам – по экземпляру подпроцесса на каждый документ.
• Событие-условие «Работа над разрешительными документами завершена» срабатывает, когда по всем разрешительным документам, требуемым для данной товарной позиции, есть какой-то результат (положительный или отрицательный).

(Продолжение)

Первая версия модели процесса –

Рис. 1. Заказ на таможенное оформление

К сожалению, эта схема годится только для заказов с единственной товарной позицией.

Если у нас N товарных позиций и они могут обрабатываться независимо друг от друга, то нужен цикл по объектам –

Рис. 2. Заказ на таможенное оформление, цикл по товарным позициям

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

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

Объединить потоки работ в BPMN существенно сложнее, чем расщепить. Это делается с помощью паттерна под названием «групповая обработка».

(Продолжение)

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

С другой стороны, любая проблема – это одновременно возможность! В данном случае – возможность освоить продвинутые техники моделирования процессов в нотации BPMN 2.0.

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

Описание процесса

Наша компания оказывает логистические услуги. Мы ничего сами не производим, физической доставкой тоже занимается третья компания, а мы занимаемся только экспедицией (контролем прохождения товара) и таможенным оформлением.

Этапы процесса:

1. Клиент размещает у нас заказ, содержащий N товарных позиций.
2. Товары поступают на таможенный склад.
3. Параллельно с ожиданием поступления товаров, мы оформляем разрешительную документацию, которая потребуется для растаможивания.
4. Мы оформляем и подаем таможенную декларацию.
5. Таможня выпускает товары.
6. Мы отправляем товар клиенту.
7. Клиент оплачивает наши услуги, мы закрываем сделку.

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

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

В чем здесь сложность: бесконечно ждать нельзя – благополучное прибывшие/растаможенные товары надо двигать дальше по процессу, а проблемные «выделять в отдельное производство», как говорят юристы. То есть в нескольких точках поток работ распараллеливается – один поток идет дальше, второй встает на паузу (ждем поступления оставшегося товара), третий зацикливается (подаем декларацию повторно).

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

Итак, имеется два требования к процессу со стороны бизнеса, отчасти противоречащих друг другу:

• обрабатывать товары «пакетом»
• обрабатывать товары по отдельности, если отстающих ждать слишком долго

Как бы вы смоделировали такой процесс?

(Продолжение)

«Метод и стиль» — это система соглашений в дополнение к правилам спецификации BPMN, делающих процессную логику полностью понятной исключительно из печатного образа диаграммы BPMN. Эта книга научит вас создавать интуитивно понятные схемы, одинаково воспринимаемые бизнесом и ИТ.

Благодарить за выход книги на русском можно Анатолия Белайчука, выступившего в качестве научного редактора и спонсоров – компании ELMA и Glowbyte, выкупивших авторские права.

С аргументом «нам так удобнее» спорить сложно, т.к. удобно-неудобно – критерий абсолютно субъективный. Ваше мнение против моего – ничего доказать невозможно в принципе.

Но давайте вспомним, а зачем собственно люди придумывали стандарт? Причем надо понимать, что это потребовало серьезных интеллектуальных и организационных усилий – как свидетельствует Брюс Сильвер, «выпуск спецификации BPMN 2.0 полностью исчерпал ресурсы команды разработчиков».

Я бы выделил три ключевые проблемы:

1. Отсутствие стандарта приводит к искажениям смысла: трактовка диаграммы процесса оказывается неоднозначной – автор (например, аналитик) имел в виду одно, а читатели (бизнес-пользователь, программист) увидели другое.
2. Отсутствие стандарта приводит к зависимости от производителя программного обеспечения. Программные продукты несовместимы друг с другом – перенести модель из одного в другой можно только «экспортом-импортом через принтер». (Справедливости ради, еще до появления стандарта BPMN WfMC разработал формат XPDL, который частично решал эту проблему.)
3. Отсутствие стандарта затрудняет накопление компетенций – это все равно как вместо общенационального языка, универсальных учебников, толковых словарей и великолепной классической русской литературы у нас в стране была бы только куча диалектов с ограниченным числом носителей у каждого.

Соответственно, когда компания отказывается от следования международному стандарту, подменяя его локальными нормативно-методическими документами, она получает все эти проблемы:

1. Чтобы понять, что изображено на диаграмме, недостаточно знать BPMN – необходимо предварительно проштудировать локальное соглашение о моделировании.

Для начала кто-то должен будет его написать. Тут надо понимать, что даже крупной компании сложно выделить ресурсы для такой разработки с качеством, сравнимым с качеством международного стандарта. Поэтому скорее всего, документ получится неполным, противоречивым, неконкретным, но при этом объемным и многословным.

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

Имеющуюся обширную литературу по BPMN использовать не получится, ведь она будет противоречить внутреннему стандарту. Отправить сотрудников на внешний тренинг – аналогично.

3. Компания не сможет просто взять с рынка труда сертифицированного аналитика, знающего BPMN – его придется переучивать.

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

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

Это дорого, это зависимость от разработчика программного продукта. Разрабатывать собственный еще дороже, для большинства – запретительно дорого. ПО с открытым кодом не спасает, т.к. как только мы начинаем вносить в него свои правки, поддерживать его в дальнейшем будет не сообщество разработчиков, а мы сами, за свой счет.

5. Обмен моделями с внешними консультантами, бизнес-партнерами, поставщиками окажется затруднен.

Они не смогут импортировать наши модели, потому что они содержат элементы или конструкции, не предусмотренные стандартом. Мы не сможем импортировать их модели, потому что наше соглашение запрещает элементы, предусмотренные стандартом.

Таким образом, собственный «локальный стандарт BPMN» – это потери. А с потерями что полагается делать? Правильно – устранять.

Но дело не только в потерях.

Пример 1.

Вы затеяли у себя дома ремонт – не просто переклеить обои, а перепланировка с переносом стен, заменой электрики и т.п. Архитектор сделал проект – экспликация помещений, развертки стен, силовая проводка, слаботочная проводка, водопровод-канализация, …

Но в архитектурном бюро принята собственная система обозначений для схемы электропроводки с оригинальными значками для розеток, светильников и выключателей. Проект принят, приходят строители. Профессионал-электрик смотрит на чертеж – ЧТО ЭТО?!

Оно вам надо?

Пример 2.

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

Решитесь выйти с ним в море?

6. Знание стандартов и следование стандартом – признаки профессионала.

Непрофессионализм – это всегда риски, зачастую непросчитываемые.

Хотя я считаю Брюса своим учителем, с некоторыми рекомендациями его Метода я не могу согласиться.

В частности, Брюс рекомендует везде, где можно, экономить на развилках:

• использовать неявное распараллеливание -

• делать схождение альтернативных потоков на задаче -

• делать схождение параллельных потоков на завершающем событии -

Против этих рекомендаций у меня есть как конкретные, так и общие возражения:

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

Общее же возражение заключается в том, что стремление сэкономить на развилках является контрпродуктивным.

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

- человек считывает не задумываясь, «на автомате». Если убрать развилки – придется вглядываться и задумываться.

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

Я бы изобразил этот процесс так:

Схема стала больше? Да. Количество элементов увеличилось? Да. Но вся она собрана из стандартных блоков, либо следующих один за другим, либо вложенных один в другой.

Какая схема лучше? Вероятно, это дело вкуса. Как пишет Брюс, «вы можете соглашаться с моим Методом или нет – главное, чтобы вы выработали свой метод и последовательно его придерживались». С этим нельзя не согласиться!

Я бы провел здесь параллель со структурным программированием, идея которого – разбить программный код на стандартные блоки: последовательность, выбор, цикл. В свое время структурное программирование произвело революцию в разработке программного обеспечения. Сегодня про него мало кто вспоминает, но не потому, что оно стало неактуальным – ровно наоборот, оно настолько прочно вошло в практику программирования, что его перестали замечать.

В моделировании процессов, по моему мнению, также следует придерживаться структурного подхода, что, в частности, означает – не экономить на развилках.

Чтобы освоить структурное моделирование в нотации BPMN и в теории, и на практике, приходите на мой тренинг – очередной курс пройдет 7, 8 и 10 октября.

Начнем с более простой части вашего вопроса. С VAD BPMN конкурировать не может: VAD умеет моделировать процессную иерархию, BPMN – нет. В нем банально нет значка для изображения группы процессов.

BPMN и EPC сравнивать можно, эти две нотации предназначены для одного и того же – для моделирования единичного бизнес-процесса.

Преимущества BPMN:

• Открытый стандарт (OMG/ISO) – вы никому ничего не должны за использование этой нотации. EPC – нотация проприетарная, и даже если сейчас с производителя софта, использующего EPC, лицензионные платежи не потребуют, потенциально такую возможность исключать нельзя.
• BPMN 2.0 стандартизовал не только внешний вид элементов, но и XML-представление модели. Это позволяет начать рисовать в одном программном продукте, продолжить в другом, а запускать в третьем. Или консультант может пользоваться одним инструментом, а заказчик другим.
• Возможность создавать непосредственно исполняемые (процессным движком) модели процессов.
• Интуитивная понятность. Она обеспечивается тем, что базовый набор элементов BPMN позаимствован из блок-схем. Назначение овалов и шестиугольников EPC без пояснения не угадаешь.
• Возможность моделировать не только поток работ в одном процессе, но и межпроцессное взаимодействие. Это важно, потому что то, что на бытовом уровне называют бизнес-процессом, в действительности часто состоит из нескольких потоков работ с разными ритмами, стартовыми событиями и контекстом.
• Однозначность трактовки. Неважно что хотел изобразить автор диаграммы – ее трактовка определяется механизмом токенов.
• Эффективный механизм коммуникаций между бизнесом и ИТ. При грамотном использовании BPMN достаточно прост и понятен, чтобы быть «своим» для бизнеса, и в то же время достаточно точен, чтобы без искажений донести бизнес-логику до ИТ.

Недостатки BPMN:

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

Амбивалентное отличие BPMN:

• BPMN методологически нейтрален – технически, это просто набор значков и самых базовых правил. Как и для чего вы будете его использовать – методология – может быть разной. Это можно считать и преимуществом, и недостатком.

Преимущества EPC:

• Успех EPC в значительной степени обусловлен тесным партнерством немецких компаний SAP и IDS Scheer. Хотите внедрить SAP – моделируйте в EPC. Сейчас это уже не так жестко, но в 90-е было безальтернативным.

Резюмируя, преимущества BPMN не выглядят подавляющими. Кроме того, многое из сказанного выше является мнением приверженца BPMN и может быть оспорено приверженцами ARIS и EPC. Но даже не очень значительные преимущества одной нотации со временем приводят к ее доминированию.

BPMN – нотация более молодая, ее разработчики учли опыт EPC, как положительный, так и отрицательный. BPMN не сразу стал доминирующей нотацией – понадобилось примерно 6 лет и выход версии 2.0, чтобы о его поддержке заявили ведущие производители ПО, включая Oracle, IBM, SAP и IDS Scheer (на тот момент в составе Sofware AG).

Дальше – больше: больше книг, больше учебных курсов, больше специалистов. EPC фактически остался в тех организациях, которые начали моделировать свои процессы до того, как BPMN стал мейнстримом, и накопили большую базу моделей. Некоторые из таких организаций, например Лукойл, нашли в себе силы начать миграцию из ARIS в BPMN, другие нет.

• Продолжение дискуссии >>

Дополнено:

Решающих факторов, определивших преимущество BPMN перед ARIS, пожалуй два:

1. Возможность непосредственного исполнения. В EPC тоже моделируют процессы «для автоматизации», но это другое (ц).
2. и главное. С чего бы условный IBM или Oracle стали лить воду на мельницу конкурента, продвигая методологию ARIS и нотацию EPC? SAP – да, у них с профессором полное взаимопонимание и любовь. Экосистема SAP (партнеры, клиенты) – да, без вариантов. А конкуренты SAP выберут что-то нейтральное, т.е. BPMN.

Ресурс развернут по адресу bpmnbox.org на вики-движке DokuWiki, контент можно свободно использовать в том числе с коммерческими целями при условии указания источника.

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