BPMN Slider

Меня попросили поразбираться и рассказать, что интересного произошло за последнее время с графическими редакторами бизнес-процессов. Нельзя сказать, что тема рисования процессных диаграмм переживает всплеск интереса, но и с повестки дня совсем не уходит. В предвкушении новых открытий я погрузился в короткое исследование самых разных графических редакторов от bpmn.io до Yaoqiang и действительно обнаружил некоторые изменения в программах для моделирования поведения

Не стану утомлять вас банальными наблюдениями о том, что в Microsoft Visio процессные диаграммы уже особо не рисуют, предпочитая js-редакторы. Изменилось и еще кое-что. Многие разработчики решений для моделирования процессов реализовали не только BPMN process diagram, но и предусмотренные в версии 2.0 этой нотации Conversation, Collaboration и Choreography диаграммы. И если Collaboration модель используется уже довольно давно, то вот так, например, выглядит Choreography Diagram у Camunda (еще можно посмотреть на странице chor-js https://github.com/bptlab/chor-js на github или в онлайн-примере https://bpt-lab.org/chor-js-demo/ ). Много реже приходится увидеть BPMN conversation diagram (в общем, листайте слайдер).

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

Такие программы, вероятно, делались для печати картинок на плоттере. В крайнем случае, если у вас нет подобного девайса, то перед печатью на принтере программа непременно поинтересуется в какой последовательности разложить листы А4 по этой картинке – вертикальной или горизонтальной. Конечно, зажав кнопку Ctrl и колёсико мыши можно увеличить масштаб и даже покрутить диаграмму влево-вправо полосами прокрутки, но согласитесь, так уже давно никто не работает. Ни на large screen ни, тем более, на small screen. Современный пользователь смахивает экраны влево и вправо, вверх и вниз. Основным элементом, с которым он работает на мобильном устройстве является карточка, а на большом экране группа карточек и, быть может, навигационная панель. Вот как могла бы выглядеть BPMN choreography diagram, визуализированная таким вот образом

Card

Каждой активности – ровно один экран (карточка). Смахнув(swype, от англ. swipe) влево и мы переходим к карточке следующей активности(задачи) или к развилке(gateway), вправо – возвращаемся назад. На развилках выпадают сразу несколько карточек связанных с ней активностей (т.е. для каждой стрелочки), ну или что-то в этом роде. Исключения, вложенные процессы и прочие атрибуты задачи отображаются иконками в нижней части карточки. Нажимаем и проваливаемся в альтернативный сценарий (см. ниже)

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

use-case

и именно поэтому важно в первую очередь выделить в процессе типичный ход событий (happy path)  – последовательность выполняемых друг за другом задач, приводящую процесс к успешному завершению. Об этом двадцать лет назад писал Alistair Cockburn в своей легендарной книжке Writing effective use cases, рассказывает Ivar Jacobson в Use-case 2.0. С этой идеей мы непременно сталкиваемся в практиках Service Blueprint или же User Story Mapping. Придумано много способов, чтоб не дать архитектору процесса своевременно увидеть в графе этот маршрут. Это и дорожки с пулами, которые давно следовало бы сделать метками активностей (нет, ну если очень хочется, то можно сделать и отдельные представления и включить в них только задачи определенной группы сотрудников). Следующий момент – параллельные активности… В общем, отговорок много. Но не лучше ли просто взять набор активностей, следующих одна за другой и объявить их основным сценарием, а ветвления убрать в расширения и обработчики исключений?

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

В общем, есть куда еще развиваться инструментам описания бизнес-процессов. И даже если карточки описаний задач, связанные в упорядоченные колоды, не найдут своего применения для моделирования процессов, инструкции по работе для людей стоит оформлять именно так. И в этом тоже нет ничего нового. Guided navigation process, Wizard, Calling script – другие названия данного представления процесса. Думаю, что нет смысла дальше развивать идею данного сообщения. Всё и так понятно. Скорее следовало бы дополнить его примером описания процесса, запрототипированного в Lunacy или Figma. Будет время, постараюсь сделать.

Ну, а до графических редакторов других типов диаграмм мы доберемся как-нибудь в следующий раз. И речь, безусловно, в первую очередь, пойдет об инструментах рисования корпоративной архитектуры. Там тоже есть и запутанные узоры стрелочек и слои, и тоже нет внятных инструментов навигации по большим картинкам. В общем, всё как мы любим :-0

Добавить комментарий

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