Комментарии 26
Практически любая нотация выглядит понятно и привлекательно на простых процессах. Ваш пример регистрации пассажира — по сути диаграмма последовательности (которая бы ещё выиграла в читаемости без лишней строгости BPMN).
Можете показать сложный пример использования BPMN, где участвует 4 или больше сторон непоследовательно?
Применял во взаимодействии с заказчиками BPMN, он существенно выигрывал в том числе на таких сценариях по нескольким причинам. Во-первых - лучше визуализируется ветвление процессов на основные и ошибочные пути, и можно показать все типовые ошибки. На диаграмме последовательности так сделать сложнее в силу линейности. Во-вторых - бизнесу схемы понятнее, и как только понимают иконки шлюзов (включающий, исключающий,....) - такая диаграмма очень легко становится понятной и нетехническому бизнес-заказчику, и технической команде. Для крупных сложных процессов - вне зависимости от типа схемы надо отделять блоки и подпроцессы, иначе схема будет размером с лист A1. В упомянутом кейсе с 4-6 сторонами, обычно оказывается, что есть 2-3 стороны основного процесса, а остальные живут в подпроцессах с четкими входами и выходами.
подскажите как создать такие разрывы в diagrams?!
Это делают программы сами. Если у вас такое автоматически не делается, то сами вы это не сделаете. Скорее всего. Но если честно, меня отсутствие таких защипов не смущает. Да, линии иногда пересекаются. Но. Огромное количество пересекаемых линий тоже мне кажется говорит о спагетти-процессе, который не есть наверное оптимальный. Или не совсем оптимальный уровень абстракции. Если кто-то захочет ну прям все процессы например одного отдела на одном листе отобразить, то да, там таких перекрёстков будет уйма. Но от этого само описание не станет понятнее и удобнее. Надо разделять. Иногда стоит использовать Lines & Pools и интерфейсы к ним.
При выбранной линии в её свойствах можно выбрать, что с ней будет происходить в месте пересечений с другими линиями: круглая арка, прямоугольная арка, разрыв
В "применении на практике" первый совет выглядит как "вредные" советы - сознательно добавили чтобы понять кто дочитал, кто нет? :)
Надо было не только заголовки, но и весь текст бахнуть капсом!
Что на счет применения BPMN в разработке ПО? Есть ли подходы кроме указания исполняемых частей внутри BPMN? К примеру как сделать чат бота на BPMN , где он спрашивает вопросы и в зависимости от ответов продвигается по диаграмме состяний чтобы определить новые вопросы?
Очередной виток развития технологий сейчас выводит в тренды "low-code" решения для разработки ПО, в основе которых, как правило, BPMN. Много их. Кроме упомянутого в статье, вот например Camunda.
Программисты пишут отдельные функциональные блоки типа "отправить вопрос", "обработать ответ" специфичные для чат-платформы, а все диалоговое дерево бота строится уже аналитиками средствами BPMN редактора.
В идеале это конечно мечта любого топ-менеджера по разработке ПО. Умные разработчики не нужны, системные аналитики не нужны, проектировать не надо, тестировать не надо. Взял одного бизнес-аналитика, составил с ним BPMN диаграмму на понятном бизнесу языке, и вот вам программное обеспечение для любого бизнес процесса. Красота.
На практике это работает только в определенных сферах бизнеса, с высокой степенью регламентированности процессов.
Львиная доля бизнес-процессов в современных банковских системах описаны в BPMN и управляются Camunda.
Обожаю эту ноитацию. Но. По всей Европе только в единичный случаях и то играючи занимаются этим. И то - в основном энтузиасты. После которых, если они уходят из фирмы, то и вся эта документация накрывает тазиком. От слова совсем и полностью.
Раздел Customers на сайте camunda.com этому заявлению противоречит.
Ага, если кто то из фирмы купит лицензию, то фирма уже в списке customers, не важно делает она этом что-либо или нет, умеет-ли он это делать или нет, и если делает, то что этим рисуется - удовлетворяет ли это стандартам bpmn 2.0 или это просто для галочки. Во-первых почти рикто не умеет находить правильный уровень детализация. Почти везде - в первый момент перебор и какой,то заумный или уже-процесс или будущий процесс описывается так, что уже через недельку другую от постоянного видоизменения процесса авторы такой документации не в состоянии все изменения вносить. Забивают потом на это. В других же плюют на правильное описание лишь-бы 'квадратики' и стрелочки как- нибудь были-бы нарисованы, не важно - работает так или нет - потому что редко, кто в этом вообще разбирается. Но смотрится неплохо, особенно для 'доказывания', какой 'сложный' и ресурсо-ёмкий' у них процесс итд. Конечно, есть фирмы, в которых требования на большом уровне могут быть. Но я таких не встречал. Нет, переправил себя. Раньше встречал больше, но тогда не было bpmn. Тогда писалось всё под EPK (по русски - Событийная цепочка процессов). Вот тогда были требования которую. А сейчас всё агиль, сейчас не надо ни архитектуры ни описания процессов. Нет, они вроде бы они ой как и нужны. Но кто будет этим заниматься, если один из канонов агиль гласит - рабочая система стоит выше, чем описание или документация этой системы. И всё- шах мат тем, кто думает, что только благодаря именно этим описаниям и документация можно вообще выжить...
Я сильно сомневаюсь, что например европейские отделения Райфайзена работают с bpmn меньше или менее серьёзно, чем российские.
P.S. Я сам не сторонник пихания гибких методологий всегда и везде, но замечу, что Сберу agile не помешал полностью переписать свои системы.
Не помешал. Но, например, это приводит к тому, что приложение Сбербанка под Андроид использует полтора десятка портов и десяток разных серверов из разных подсетей. Когда задал вопрос человеку, вроде бы связанному с разработкой в Сбере, получил ответ, что приложением занимаются несколько команд разработки и инфраструктура у каждой в значительной мере обособлена (хотя действия по унификации проводятся, но координировать всё совсем не просто; поэтому виджеты идут к одним серверам, сервисы - к другим, данные о картах - к третьим, и так далее).
За все фирмы не могу говорить, но своего рода всё, что связано с bpmn или вообще описанием процессов делится на такие ситуации (извиняюсь, это не может быть точным, тк. делал навскидку):
Ничего не слышали и ничего в этом направлении не делается.
Слышали, но ничего не делается.
Делается, но это так - отдельные случаи - и больше как - посмотрите, как это классно! С реальным состоянием процессов это не имеет ничего общего.
В этом направлении что-то делается, но это один процес из 1000. И реально поддерживается только индивидуальным энтузиазмом отдельных людей.
Некоторые процессы описываются и вроде бы постоянно актуализируются. Но это затрагивает или только жизненно важные процессы или те, которые в последних миграционный проектах были затронуты, или как в предыдущем пункте, но с эволюцией инициативы отдельных людей до своего рода небольшой культуры отдельного отдела - например технического.
Очень большое количество процессов описано и время от времени их актуализируют.
Все процессы описаны и постоянно находятся в актуальном статусе.
У каждого из этих пунктов есть след. подпункты:
Описание отдельного процесса произошло один раз и никогда больше не видоизменялось. По этому описанию никто не живёт, но даже его иногда вытаскивает, когда какому-нибудь аудитору надо создать иллюзию - что процессы описаны, чтобы получить или подтвердить лицензию на например ISO 9000, 9001 или похожие.
Процесс описан, но с реальностью не имеет ничего общего. В рамках каких-нибудь проектов его актуализируют, но со временем он устаревает.
Процес описан, и вроде бы и поддерживается, но служит только документации.
Процесс описан и актуальный, и интегрирован во всевозможные оболочки, где действительно по нему протекают все 'тело-движения'.
Не надо забывать и этот факт - описание может иметь место, но оно является или вообще простым нагромождение квадратиков и стрелочек без какой либо грамматики. Или частично неработающей. Ну или сделанной по всем правилам нотации.
И последний факт - тоже немаловажно- это насколько деталированно прописаны все процессы. Потому что поставить в цепочке например задачу 'продукт выслать', при этом не указать, что это под-процесс и тем боллее его не описать - то так себе полное покрытие документацией цепочки какого-нибудь процесса.
Итд. Всё эти комбинации в разных форматах имеют место быть. И я не помню случая, где имели место полное и грамматически правильное описание ВСЕХ процессов, по которым работаютлюди или системы. Да какое там - полное? Не в тречал неразумно даже половинного покрытия. Без какой либо подтверждений стат. базы- так ощущение.
А я работал и в немецких банках, на химических и сталелитейных заводах, в тяжёлой индустрии и в телекоммуникационных фирмах. Итд. Поэтому не могу разделить ваше предположение в отношении использования описания процессов. Хотя, как и сказал в первом своём комментарии- я и ярый сторонник bpmn, могу себя назвать даже евангелистом, потому что учу этому и своих студентов. Потому что убеждать и доказывать использования bpmn в фирмах я перестал - неблагодарное это дело. Чувствую, что борюсь с ветрянными мельницами. И только надеждой на будущее поколение по этому вопросу мотивирую себя.
Сорри за многобукв.
Date – Данные
Наверное Data
А потом студенты себе перепечатывают. "Date" это нотация Тиндера, а "набор" всё-таки бассейн, плавательная дорожка как бы намекает.
практически вся информация, которую можно найти в Интернете
Странно, что очень редко сравнивают BPMN и блок-схемы. А первый если и не вырос из второго, но очень близок по сути.
Странно, что очень редко сравнивают BPMN и блок-схемы. А первый если и не вырос из второго, но очень близок по сути.
первый раз слышу, что кто-то говорит, что это не сравнивают. Оно и по времени разнесено на десятилетия, и конечно-же bpmn выходит из блок-схем. Обе модели имеют много общего, но bpmn владеет оптимальными вещами, которые были очень сложны для реализации. Поэтому блок-схемы в принципе изжили себя. И продолжают существовать, если надо небольшие задачи описать, например для алгоритмов они просты для использования, чем bpmn.
Статья писалась для "новичков", но трудно читается даже бывалыми:
1) activity - понятия транзакции и вызывающего действия не понятны как по смыслу, так и по ценности для описания процесса
2) pool - очень запутанно, лучше напишите через понятия разграничения отвестовенности
3) gateway - включите популярный шлюз "по событию", исключите шлюз "ИЛИ" его не любят использовать из-за неопределенности
Краткое описание нотации BPMN