Комментарии 16
В статье приведен ошибочный подход с ошибками в нотации. Разбор ошибок и неточностей займет больше самой статьи. Базовые - задачи должны быть в терминах предметной области, а не технических терминов вроде "сохранение", БД и элементы данных не могут выступать в качестве задач. Путаница в нотации между сообщениями (вид событий) и событиями. Учитесь пользоваться аннотацией для пояснения задач процесса вместо некорректных представлений связей между элементами данных и БД. Процесс с событиями таймеров ожидания между параллельными шлюзами - вообще иллюстрация как делать не надо никогда.
Базовые - задачи должны быть в терминах предметной области, а не технических терминов вроде "сохранение", БД и элементы данных не могут выступать в качестве задач.
В нотации не запрещено использование технических терминов. Элементы не могут, но задача/действие над данными могут.
Путаница в нотации между сообщениями (вид событий) и событиями.
Событие - элемент управления потоком, который указывает на состояние, влияющее на выполнение процесса. События могут запускать действия в процессе или быть их результатом. Сообщение в свою очередь является одним из типов такого события.
пояснения задач процесса вместо некорректных представлений связей между элементами данных и БД
Ко всем создаваемым диаграммам в обязательном порядке идет аннотация с описанием каждого бизнес-процесса, отраженного на схеме. Связи элементов важная составляющая диаграмм и понимания схемы пользователями.
Процесс с событиями таймеров ожидания между параллельными шлюзами - вообще иллюстрация как делать не надо никогда
Спасибо за замечание, не обратил внимание
Событие - элемент управления потоком, который указывает на состояние, влияющее на выполнение процесса
Событие - это то, что произошло. Всё. В нотации все элементы указывают на состояние, все влияют на выполнение БП (зачем рисовать что-то, что не влияет?) и полно элементов управления - все, которые не элементы данных. Это "определение" вы, вероятно, подрезали у каких-то консалтеров "не умеешь сам - учи других": очень сложно и пусто. Сообщение же - это вид событий. Еще бывают события старта/конца, таймера, ошибок, отмены, сигнала, условия и, конечно, ссылки на другой процесс (если кого-то забыл, простите меня, события).
Ко всем создаваемым диаграммам в обязательном порядке идет аннотация с описанием
Про аннотации я писал к задачам, не ко всей диаграмме. Диаграмма-то как раз может быть в идеале самоописана.
Про технические термины - нотация не запрещает писать любой текст, даже матом. Но если вы говорите про подход, при котором вы составляете схему бизнес-процесса, то нужно оставаться на одном уровне абстракции - слое бизнес-процессов, а не скакать со слоя на слой.
Например. Задачу - в глагольной форме в терминах бизнеса, пояснения - в аннотацию. Запись в БД и элементы данных - это артефакты задач: стрелки только на них, а ИЗ них запретите себе что-то рисовать - только запутаетесь. Приводить на схеме БП "записать", "прочитать", "сохранить" и т.п - перегружают схему. Это само собой - у каждой задачи обязательно есть свои входы и выходы, логи и метрики - сохраняется всё. Слой данных, в котором их жизненный цикл, синхронные, асинхронные операции, процессы управления данными и т.д. - это другой архитектурный слой, не надо всё тащить в бизнес-процессы - получится каша - описывайте отдельно. Если уж так хочется (ну, например, основное требование - какое-то единство БД и надо его подсветить), то лучше поместите в аннотации эти функции задач, но не надо при этом из аннотаций создавать "войну и мир", как и создавать схемы больше, чем на 7-10 элементов - надо бить на подпроцессы. Вот это я коротко описал подход в парадигме многоуровневой архитектуры. Любопытно как может выглядеть другой. Жду новую статью ;)
Событие - это то, что произошло. Всё
"Событие используется для нескольких целей. Во-первых, чтобы указать моменты времени, когда выполняется работа. Например, начать выполнение очередной операции через 1 час, после завершения предыдущей. Во-вторых, чтобы ограничить длительность операций. Например, прервать исполнение операции через 30 минут после начала. В-третьих, они описывают реакцию на изменение состояния внешних, по отношению к процессу объектов." - Моделирование бизнес-процессов в нотации BPMN2.0, И.Г. Федоров
Сообщение же - это вид событий
в статье приведена классификация по типу события
Еще бывают события старта/конца, таймера, ошибок, отмены, сигнала, условия и, конечно, ссылки на другой процесс
"Для описания бизнес-процессов из опыта в большинстве случаев достаточно элементов нотации, описанных здесь" - туториал не имеет своей целью охватить все элементы и аспекты нотации BPMN, для этого есть специализированные издания.
Для чего используется - это не определение.
Ну и как вы считаете, Федоров привел все цели событий? "В-третьих" - очень неуклюжая цель. Есть throw и catch ивенты - те, которые catch еще можно натянуть на цель "В-третьих". Но это придирка. Ждать от отечественного экономиста какой-то корректной классификации - все равно, что ждать от соседа, что он споет Шаляпина без фальши.
в статье приведена классификация по типу события
так вот она неправильная. То, что у вас с ромбиком - это не событие ошибки, а событийный шлюз (Event based gateway).
туториал не имеет своей целью охватить все элементы и аспекты
никто и не ожидает, что вы сможете охватить все аспекты - в bpmn есть полно экзотики, даже пример применения которой придумать очень сложно. Но упомянуть о существовании, как минимум, ссылочных и условных событий стоило бы.
Со шлюзами - в нотации "или" бывает с пустым ромбиком и с косым крестом. Вы описываете пустой, а на диаграмме (обреченный пациент с подозрением ЗНО) с косым крестом. Что мешало помесить упоминание ранее? Жадность?
Пациент обречен потому, что он никогда не дождется завершения обслуживания - не пройдет параллельный шлюз с двумя входами, но с единственным токеном в процессе.
Про аннотации я писал к задачам, не ко всей диаграмме. Диаграмма-то как раз может быть в идеале самоописана.
Это возможно и в каих-то случая нужно. Но диаграмма не идет в отрыве от описания бизнес-процессов, а иначе она представляет собой только логику выполнения БП, а не комплекс диаграмма-описание.
Вот это я коротко описал подход в парадигме многоуровневой архитектуры. Любопытно как может выглядеть другой. Жду новую статью ;)
Спасибо за участие в обсуждение и развернутые комментарии) Все конструктивные и объективные замечания, постараюсь учесть в работе при проектировании и описании БП, а также при написании в будущем статьи, возможно более развернутой или еще более компактной ;)
Спасибо за ваш отзыв и за то, что уделили время на его написание. Понимаю и допускаю, что могут быть различные подходы для отражения элементов на схеме. В своей статье я стремился сделать BPMN более доступным для широкой аудитории и возможно, допустил некоторые упрощения. Я обязательно еще раз просмотрю указанные вами моменты и постараюсь улучшить материал. Возможно, в будущем для другой статьи добавлю более детальные пояснения и примеры. Спасибо за ваш вклад в улучшение контента и дело Хабра. Комментарии как положительные, так и отрицательные помогают всем нам становиться лучше.
В общем-то и правда очень неплохой начальный гайд по нотации, спасибо! Но думаю что было бы неплохо добавить прау ссылок на конкретные кейсы и моделирование процессов там, для пущей наглядности.
не рекламы ради, но пользы для.
мне кажется хороший и понятный гайд, а также готовое соглашение о моделирование внутри компании сделал Денис Котов и ребята из сервиса stormbpmn.
Собственно и вам рекомендую ознакомиться, у них и примеры есть как надо и как не надо.
Именно из-за такой сложности BPMN нельзя использовать при общении с бизнесом. Хотя, казалось бы, первая буква названия говорит об обратном. :)
Рекомендую eEPC. Проверено опытном путём: согласовал кучу схем с "бабушками из бухгалтерии". :) Получить уверенность, что вы оба всё правильно поняли - очень важный пункт.
Привет и спасибо за комментарий) Я бы не назвал BPMN сложной, она хорошо подходит для описания именно бизнес-процессов.
EPC да, относительно легко читается, из-за небольшого кол-ва элементов и цветовой типизации, но мне кажется она больше подходит для описания относительно простых БП или процессов нижнего уровня, а также шагов, но выбор нотации в конечно счете зависит от конкретного случая и того, что именно будет описываться с её помощью.
"Хорошо подходит" вам, но не "бабушкам" - мой упор именно на это.
eEPC можно описать схемы любой сложности. Проверено.
Но это когда я был БА+СА. Сейчас, когда я в большей степени СА, в своей работе использую:
когда без схемы не обойтись: Sequence diagram или Swim lane;
очень редко - некоторые специфичные: Component diagram, простую ER-диаграмму, может ещё что, не вспомню.
но в основном - обхожусь без схем. Ну вот не нужны они в большинстве случаев, кроме как для повышения ЧСВ аналитика. :)
Либо у меня так происходит, что в первой версии фичи схема ЕЩЁ не нужна, а в какой-нибудь следующей - УЖЕ поздно (тратить пол дня на рисование в стол не хочется).
Когда последний раз использовал eEPC - уже и не вспомню. :)
BPMN 2.0 универсальный подход при построении диаграмм