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

Рис. 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 октября.

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

Чтобы из первых рук информацию узнать, как подготовиться к экзамену и как его сдавать, приходите на конференцию «Системная практика управления бизнес-процессами» 26 января. Мероприятие онлайновое (Zoom) и бесплатное (требуется регистрация). В программе конференции доклад президента ABPMP Russia Анатолия Белайчука «Маленькие секреты сертификации специалистов по процессному управлению» — он расскажет как подготовиться к квалификационному экзамену и как его сдавать, проведет для всех желающих экспресс-тестирование и разберет несколько распространенных ошибок. Начало доклада в 15:30, не пропустите!

Основательно подготовиться к сдаче экзаменов можно на наших тренингах по методологии BPM и нотации BPMN. Очередной курс пройдет 12-15 февраля.

• Зарегистрироваться на тренинг >>

Большинство конкурентов не углубляется дальше первого уровня – «квадратиков, ромбиков и стрелочек». Всего же уровней освоения BPMN мы выделяем четыре:

1. Задачи, развилки, пулы и дорожки. Хотя это и начальный уровень, здесь есть свои подводные камни: например, является ли стартовое событие обязательным? Или: можно ли моделировать дорожкой информационную систему? А клиента или партнера?
2. Подпроцессы и циклы по объектам. Не поднявшись на эту ступень, невозможно качественно моделировать сквозные «от самого начала и до самого конца» бизнес-процессы. Мы этому учим уже на начальном курсе BPMN051 – Краткий курс BPMN 2.0
3. Межпроцессное взаимодействие и события. Эту технику необходимо освоить, чтобы выйти за рамки вспомогательных процессов – таких как командировки, согласование договоров или планирование бюджета – и заняться основными процессами. Основные процессы более значимы для компании, т.к. они деньги для компании зарабатывают, в то время как вспомогательные только тратят. Специфика основных процессов в том, что их участниками являются не только внутренние, но и внешние заинтересованные стороны – клиенты, поставщики, партнеры. Мы не можем ими командовать так, как собственными сотрудниками, а должны уметь реагировать на их действия, зачастую спонтанные. Это технику мы осваиваем на продвинутом курсе BPMN052 – Базовый BPMN 2.0.
4. Процессная архитектура. Как наглядно показать не единичный бизнес-процесс, а систему процессов, объединенных в иерархию и, кроме того, взаимодействующих друг с другом по горизонтали. Этому мы учим на курсе BPMN102 – Практика BPMN 2.0.

Ну и где еще вас этому научат? Причем не только в теории, но и на примерах из вашей собственной практики?

Под руководством Анатолия Белайчука – эксперта не только сертифицированного по международным стандартам ABPMP CBPP и OMG OCEB-2, но и соавтора российской системы оценки квалификации по профстандарту «Специалист по процессному управлению».

Регистрируйтесь – очередной цикл тренингов стартует 17 октября.