Comments 29
Процесс покупки абонемента через бот в Telegram.
По тексту тоже все гладко.
Оформление тоже не даёт глазам разбежаться
Гладко? Серьёзно?
Ужасно по оформлению. Даже при разворачивании в полном размере текст едва читается.
Каждый блок можно (и нужно) увеличить раза в 2. Шрифт в них можно (и нужно) увеличить раза в 4.
И ещё расставить нормально переносы и центрирование. Что за ужас:
| Зарегистрирова | т
| ь пользовател |я
Конечно такое никто читать не будет.
Наверное надо было написать "относительно гладко" и "оформление более-менее ничего", тогда вы были бы не столь категоричны :)
В целом, я соглашусь, что переносы довольно кривоватые, глаз будет цепляться, но все же в реальности нам такое прощают и не ставят двойки :)
Насчёт размеров блоков и шрифта могу только посетовать на сжатие картинки, сомневаюсь, что автор (не я) исходных схем специально что-то уменьшал.
У вас последовательный поток обрывается, дальше смотреть не стал.
Поток чего? Это же event-driven процесс. Не "цикл обработки событий" же в стиле дракон-схем рисовать...
Токен у вас остановиться и дальше не пойдет. Это ошибка.
Я не супер-специалист в BPMN (да и не заявляла этого нигде), но не понимаю, о какой ошибке вы говорите...
После "Показать меню" токен никуда не пойдет, так как последовательный поток обрывается. Чтобы было понятней рекомендую глянуть видео
Не понимаю всё же, что за поток?
В BPMN должна быть описана обработка всех возможных ошибок?
А мне в статье всё нравится - напомнили о документации и вариант как можно оформить. Мне также нравится подход Параджанова к созданию блок схем, тут такой же подход - стараться не пересекать линии.
Бесплатные программы знаете, где это удобно делать?
По личному опыту, правило нумерации блоков существенно сокращает время на согласование блок схемы, позволяя быстро идентифицировать место схемы, о котором сейчас идёт речь.
Использование сложных нотаций часто тоже отпугивает бизнес-пользователей. Поэтому, чем нотация проще (меньше количество видов блоков и стрелок, использованных в схеме), тем лучше (проще понять неосведомленому в нотациях пользователю).
так может лучше сразу Event Storming, чем заставлять заказчиков и бизнес-пользователей разбираться в этом нашем богомерзком BPMN?
https://systems.education/disadvantages-of-classical-approach
Ошибок нотации у вас на этих схемах навалом. Может рановато учить как проще, а сначала нужно разобраться самой в нотации? из действия две сплошные стрелки выходить не могут, только через шлюз. И разберитесь - вы единый процесс в пуле рисуете или кучу бизнес-процессов, связанных по событиям. Если второе - то ваши пунктирные линии между дорожками должны быть осмысленны, а не просто "нарисуем тут, вроде связано".
С общей мыслью статьи я соглашусь - минимум неизвестных значков, только базовая нотация, понятная всем. Но и она должна быть без ошибок.
Моя схема в статье всего одна :) указанных вами ошибок на ней не нашла. Возможно к этому как раз привело следование тем правилам, которыми я пользуюсь, т.к. суперспециалистом по BPMN себя не считаю, и в реальности часто вообще пользуюсь самой простой блок-схемой, т.к. на моей практике ещё не встречались программисты, которым критично использование BPMN, а пользователю всегда чем проще тем лучше.
Ну и про кучу бизнес-процессов - об этом как раз девятый пункт - разберись, что описываешь)
"указанных вами ошибок на ней не нашла "
В схемах, которые вы приводите в статье, неверно используется поток сообщений (Message Flow) - это отправка сообщения о событии в другой бизнес-процесс (Pool).
На схемах, приведенных вами, он используется как поток управления (Sequence Flow) между задачами в разных дорожках (Lane).
О! Спасибо! Первый комментарий, из которого я поняла, что за ошибка. Но в целом как я уже кому-то отвечала, BPMN сюда просочился случайно и я уже сто раз пожалела, что начала с его помощью рисовать схему, т.к. к сути поста мои ошибки нотации не так уж много отношения имеют, зато все меня в них потыкали.
Ошибок нотации у вас на этих схемах навалом. Может рановато учить как проще, а сначала нужно разобраться самой в нотации?
тут как c UML 20 лет назад — если специалисты сами спорят про направление стрелок и их пустоту-заполненность, может что-то попроще выбрать, а не ожидать, что это поймут случайные люди из бизнеса?
Bpmn не только для визуализации используются. Еще и , как ни странно, для автоматизации. То есть этакий low-code подход когда на действия навешиваются скрипты и всё это дело запускаются. Это применяется и, как ни странно, в довольно серьезных банковских системах, и не только. И в этом смысле BPMN штука интересная. А вот для визуализации бизнес-процессов заказчикам как правило используют подобие с максимально простой нотацией.
Я как-то собеседовала бизнес-аналитиков, и мы всем давали тестовые схемы нарисовать. Так вот, самые опытные люди рисовали самые простые и незамудрённые схемы.
"2. Процесс должен двигаться последовательно — сверху вниз справа налево неважно горизонтальная или вертикальная схема.
..."
Вероятно у вас в тексте опечатка, не "справа налево", а слева направо.
Основная ошибка, допущенная при составлении данной схемы - использование потока сообщений внутри пула, что запрещено. Этого бы не произошло, если бы использовался специализированный инструментарий, типа CAMUNDA Modeler, который следит за соблюдением нотации. Инструмент просто не дал бы вам возможности ошибиться. А инструменты для рисования чего угодно общего назначения (типа draw.io) не следят за соблюдением нотации, в результате чего и появляются подобные схемы.
И кстати, это не пул, а три состыкованные дорожки, не объединённые одним пулом. В названии пула обычно пишется название процесса, а здесь его нет.
Почему ваши схемы бизнес-процессов не читают?