Комментарии 51
Проблема BPMN в том, что более-менее сложные процессы не помещаются ни на бумагу ни на монитор, для их редактирования нужны специальные редакторы и специально обученные люди. Несмотря на то что BPMN считается наглядным, действительно большой и сложный процесс на картинке понять сложно. Дробление на подпроцессы частично снимает проблему, но переключение между документами так же снижает читаемость. Кроме того, актуальность процессов в документах неизбежно уменьшается со временем, данные устаревают. И диграммы плохо поддаются сравнению на предмет изменений
Почему-то считается что диаграммы это хорошо и понятно, а текст - нет. Думаю большинство программистов с этим не согласны всю свою жизнь - хорошо написанный код или текст куда понятнее любой диаграммы. Текст можно версионировать, хранить в гите со всеми сопуствующими возможностями. Можно читать и редактировать в любом текстовом редакторе. Кроме того, код легко превратить в диаграмму автоматически. А наоборот - нет.
В связи с вышеизложенным, вопрос к знатокам - есть ли какой-то язык/стандарт/фреймворк, где бизнес-процессы можно описать текстом (кодом или псевдокодом)? Не прибегая к графике? Беглый поиск ничего похожего не нашёл.
Разве нельзя какой-нибудь PlantUML использовать? Пишем текст, версионируем, а смотрим в виде диаграмм. Конечно, возможности визуального редактирования весьма ограничены...
Впрочем, версионировать можно, кмк, даже "вручную нарисованные" диаграммы в DrawIO, благо формат - текст.
В качестве извращения - когда мне потребовалось вставлять в Word небольшие диаграммы в виде текстового описания (для быстрого редактирования), я стал делать вставки именно DrawIO как редактируемых объектов. Благо в DrawIO можно даже код Mermaid вставлять. (docx, конечно, такой уже не версионируется толком, но все равно легче чуть текст поправить, чем полноценно диаграмму перерисовывать ).
Думаю большинство программистов с этим не согласны
Так диаграммы не для программистов в первую очередь. Это инструмент коммуникации между бизнес-пользователями и программистами (обычно с посредничеством аналитиков, которые всё это и рисуют). Либо вообще без программистов, если это какой-нибудь LoCode/NoCode.
Есть ли какой-то язык/стандарт/фреймворк, где бизнес-процессы можно описать текстом (кодом или псевдокодом)?
Если надо просто чтобы текстовый (для git и т.п.) - BPEL, XPDL, да и в целом BPMN в XML в основном и хранят (не погружался детально, какой оно там спецификации соответствует P.S. Загуглил, XML схему публикует сама OMG, хоть в тексте стандарта XML-представление BPMN не определено, по факту все сериализуют по этой схеме)
Если надо ещё и чтобы читабельный - формат activity diagram в PlantUML.
Но PlantUML это просто рисовалка. Окей, для документирования сгодится. Однако мы же говорим об автоматизации процессов. Тогда нужен исполняемый BPMN, который загружается в движок. Вот у нас в Jmix так и есть -- BPMN моделер прямо в IDE, вместе с кодом. По мне, так удобно -- плюхнул сервис-таску -- сразу написал бин или делегат, из графической модели по одному клику переход в код.
И не согласен, что текст это прям панацея. Вот, например, модель данных где хотя бы сотня сущностей. Наверное, ER-диаграмма будет удобнее для понимания, чем текст.
Та же история с процессами: они делают наглядной логику выполнения для сложных систем. Просто надо разок напрячься и вникнуть в нотацию, потом становится просто.
И я бы не сказал, что в BPMN все интуитивно понятно. Для примитивных случаев - да. Как посложнее, то надо учить матчасть.
Та же история с процессами: они делают наглядной логику выполнения для сложных систем. Просто надо разок напрячься и вникнуть в нотацию, потом становится просто.
Нотация-то проблем не доставляет. Но реальные бизнес-процессы, особенно в среднем и крупном бизнесе, состоят из сотен шагов, такого размеры диаграммы нечитаемы. Они не помещаются ни на комп ни на бумагу.
И не согласен, что текст это прям панацея. Вот, например, модель данных где хотя бы сотня сущностей. Наверное, ER-диаграмма будет удобнее для понимания, чем текст.
В JSON отлично читается.
Никто же не запрещает декомпозировать на более мелкие элементы.
Это как если бы написать один метод строк на 700 -- будет непонятно, что он вообще делает.
Когда речь идет о сложных паттернах -- компенсации, событийный подпроцессы многим непонятно. Я раза с пятого въехал, как это работает. И то иногда сомневаюсь.
Кстати, типичный случай, что люди используют параллельный шлюз, там где на событийных подпроцессах было бы нагляднее и проще.
Это инструмент коммуникации между бизнес-пользователями и программистами
Я тоже так раньше думал. Но поработав во внедрении BPM-систем обнаружил, что редкий бизнес-пользователь в состоянии понять BPMN. И дело не в нотации а скорее в сложности самих процессов. Обычно бизнес-пользователь словами рассказывает аналитику, а тот уже продумывает все что осталось за кадром, рисует BPMN и отдает программистам. Или сам моделирует в системе с учетом ее возможностей. А когда что-то работает не так, бизнес все равно словами будет это транслировать команде, а не двигать стрелочки и квадратики.
редкий бизнес-пользователь в состоянии понять BPMN
Вот он обычно и становится куратором проекта от заказчика де-факто :) Но даже если диаграммы остаются только между аналитиком и программистом, аналитик-то тоже код читать, а тем паче писать не умеет.
аналитик-то тоже код читать, а тем паче писать не умеет.
Аналитика можно научить коду, если он будет описывать только бизнес-процесс, без всяких технических обвязок. По крайней мере это реальнее чем добиться от бизнес-юзера умения понимать BPMN
Ну и будет между Вами и аналитиком свой велосипед, возможно, даже удобный обоим, но ни разу не стандартный. Сменится аналитик - нового учить? А BPMN - стандарт, его и любой аналитик знает, и готовые движки (Camunda и все-все-все), которые его могут кушать, есть, и для каких-то иных целей (смежные проекты, документация и пр.) можно взять без длинных объяснений, как это всё у вас устроено.
Это стандарт представления, нотации, не более. Невозможно экспортнуть схему процесса из Camunda и импортнуть, например в Pega или какую-то еще BPMS, и чтоб оно заработало.
> но ни разу не стандартный. Сменится аналитик - нового учить? А BPMN - стандарт
Поэтому я и интересуюсь, есть ли какие-то известные языки текстового описания процессов.
Невозможно экспортнуть схему процесса из Camunda и импортнуть, например в Pega или какую-то еще BPMS, и чтоб оно заработало.
XML-схема более или менее стандартная, я выше писал, - почему нет? В обратную сторону вон гайд первой ссылкой нагуглился, мол есть нюансы, но задача решаемая.
Поэтому я и интересуюсь, есть ли какие-то известные языки текстового описания процессов.
Если XML не устраивает - увы :(
есть ли какие-то известные языки текстового описания процессов
Любой человеческий язык позволит тебе текстом описать процесс... Просто будет это на ещё большем количестве страниц, чем диаграмма.
Да и насчёт понятности текста - не согласен. Если мы говорим о больших процессах, в которых много ветвлений и возвратов к предыдущим шагам - текст не позволит быстро понять что как и куда работает.
Запусти программиста с минимальными вводными в код, который он не писал и он будет несколько часов разбираться что и как работает (если будут комменты к каждой вызываемой функции - будет быстрее, но мы все знаем, что это редкость).
Любой человеческий язык позволит тебе текстом описать процесс...
Я так и делаю, когда пишу инструкции и регламенты для сотрудников. Или use-кейсы. Но я ищу такой язык, чтобы эти тексты можно было превратить в исполняемую BPMS. Business procesеs as a code, если угодно.
Просто будет это на ещё большем количестве страниц, чем диаграмма.
Тут скорее не соглашусь - плюс-минус одинаково. Только BPMN растет вправо, а текст можно легко отформатировать как угодно.
Процесс - это граф. Граф, описанный в текстовом формате, нечитабельный для людей. Поэтому предположу, что чисто текстового нет ничего, только yaml/json/xml описания графов
Если надо просто чтобы текстовый (для git и т.п.) - BPEL, XPDL, да и в целом BPMN в XML в основном и хранят (не погружался детально, какой оно там спецификации соответствует
BPMN сохраненный в XML - это нечитаемая каша, с ним невозможно работать как с текстом.
Git'у всё равно на читабельность. А следующий абзац моего комментария как раз и начинается со слов " Если надо ещё и чтобы читабельный..." :)
Ну не знаю, у нас нет проблем. Плагин в Идее -- и пожалуйста, вот они процессы в графическом виде. При желании можно ручками XML подправить, иногда это даже удобнее. И нормально версионируются вместе с прочим кодом.
Да, если иметь отдельно рисовалку, то версионность это личное дело каждого. Едва ли можно поддержать порядок.
На моем текущем проекте пишем бизнес-процессы на DSL (Kotlin), правда, только для тестов. Мне нравится.
Для прода процессы пишут аналитики в своем отдельном приложении.
Предложение писать процессы на том же DSL и для прода у менеджмента восторга не вызвало. Это ж надо программистов нанимать, а они дорогие. А то, что аналитик, не будучи разработчиком, все равно делает работу разработчика, но хуже - это никого не волнует.
В тексте вы не увидите, что у вас в процессе тупик или недоделанная развилка. Нужно прочитать целиком, понять, представить, только тогда станет понятно (не всегда). Низкое качество диаграммы можно определить одним взглядом.
Это должно отлавливаться тестами.
Неудобно на этапе прототипа процесса пытаться писать покрывающие тесты. Проверять полноту тестов тоже не просто и не быстро.
Может у вас другой опыт, но удобен способ обмена информацией между людьми, а не только между роботами.
Неудобно на этапе прототипа процесса пытаться писать покрывающие тесты.
Смотря как процесс тестирования организован. В моем мире с пони и бабочками процесс как маршрут тестируется отдельно, задачи - отдельно.
Проверять полноту тестов тоже не просто и не быстро.
Я даже не знаю, что ответить. А что быстро?
Может у вас другой опыт...
Мой опыт таков, что если тест можно написать - я пишу. Дешевле выйдет.
...но удобен способ обмена информацией между людьми, а не только между роботами
Вы так говорите, будто тест человек не сможет прочитать. Конечно, такие тесты бывают, но тут дело не в тесте, а в том, кто его написал. ИМХО, критерии качества кода теста не должны быть ниже, чем у продкода.
В связи с вышеизложенным, вопрос к знатокам - есть ли какой-то язык/стандарт/фреймворк, где бизнес-процессы можно описать текстом (кодом или псевдокодом)? Не прибегая к графике?
RDF. Подробнее подход см. Semantic BPM
Через языки / технологии формализации знаний (формальная семантика, например, Linked Data) можно не только бизнес-процессы описывать, но все что угодно, включая родословные.
Поконкретнее см. эскиз процессной MetaModel
Процессы можно и табличками описывать с двухсторонней синхронизацией (EPC ARIS двадцать лет назад это умел, а BPMN и сейчас это не может), но максимальная "выразительность" (точность - однозначность, мощность - гибкость) будет у "знаниевых" технологий типа Linked Data (семантическая машина рассуждений - semantic reasoner, язык запросов SPARQL и т.п.).
А наоборот - нет.
Диаграмму в код тоже легко превратить, если диаграмма составлялась в правильном (семантическом) редакторе.
Заодно вопрос: есть ли формализация BPMN в OWL (или подобном)? Типы объектов, таксономия, возможные связи между объектами и т.п.?
Кстати, коль зашла речь о рисовании процессов, то можете попробовать эту штуку
https://stormbpmn.com
Мы разрабатываем эту штуку ровно потому, что процессы сложные и на бумагу не помещаются (как выше писали) и нужен нормальный редактор с дрилдаунами, подсветкой изменений, навигацией и т.д.
А еще в задачах моделирования процессов диаграммы недостаточно, нужен контекст вокруг - исполнители, системы, связь с другими процессами, владельцы, контекст и т.д. Стандарт про это ничего не говорит, выкручиваемся как можем :)
Касательно предназначения BPMN - там прям в начале написано текста написано, что BPMN предназначен быть мостиком между бизнесом и ИТ, в голову к ним за этим лезть не надо.
Возможно стоит рассмотреть инструмент Obsidian, на него идёт множество плагинов
ИИ не моделирует корректно, за ним надо править ручками
Надо какое-нибудь 109-е правило интернета уже: любой язык для «не-программистов» будет в итоге использоваться исключительно программистами, с болью и страданиями.
Проблема этой и других переводных статей в том, что их заказывают ИИ-стартапы для продвижения своих продуктов, а господа переводчики бездумно переводят и публикуют.
Flowable едва ли можно отнести к стартапам. Это open source проект под крылом солидного швейцарского интегратора. Приписывать им желание просто похайповать -- ну, как-то не сочетается. Они живут вполне себе в энтерпрайз-сегменте.
Конкретно про автора - человек более, чем в теме и понимает , что говорит. Это не "фаундер" ИИ-стартапа.
И как переводчик скажу: мне лично эта тема интересна. И не просто лайки пособирать. В своем продукте тоже ломаем голову, как прикрутить ИИ, потому что очевидно, что эта штука может быть полезна.
И есть понимание, что момент, когда можно было просто заявить, что у нас тоже используется ИИ, чтобы хайпануть, уже упущен. Сейчас клиенты спрашивают про конкретные кейсы, интеграции ИИ для галочки уже не прокатывает.
Так что господин переводчик немного думал, что делает.
Коль зашла речь о BPMN, то напомню, что его создали для задач управления бизнес-процессами (BPM - Business Process Managment) - управления взаимодействием работников "по горизонтали", передачей информации и следующего хода от работника одного подразделения работнику другого, минуя иерархическую подчиненность (через начальников)
Использование BPMN для автоматизации бизнес-процессов - того, чтоб друг друга поняли бизнес-пользователь и разработчик - одно из его применений. Но оно не единственное.
Не совсем так. BPMN изначала создавался, чтобы можно было модели загружать в движок и исполнять процессы. Не только для коммуникаций и лучшего взаимопонимания.
Если посмотреть на лидера BPM-движков, на Camunda, так они вообще говорят сейчас преимущественно об оркестрации микросервисов. Причем с уклоном в полностью автоматические процессы, где людей вовсе нет.
Не совсем так. Возможность загружать модели бизнес-процессов в нотации BPMN в BPMS или BPM-движки действительно была одной из целью создания BPMN. И для этого в моделировании бизнес-процессов в BPMN, помимо согласовательного и аналитического уровня предусмотрен исполняемый уровень модели бизнес-процесса. Это было и есть одной из целей создания BPMN - одной, но не единственной и не первой.
Ну, залезть в голову к авторам я не могу, что они там себе думали.
Описательных нотаций было полно на тот момент.
Возомнить себя настолько крутыми, что собраться придумать лучше?
Ну, может быть.
Хотя мне понятнее цель скрестить графическую нотацию и BPEL, чтобы получить исполняемые модели.
Вышло не совсем как задумывали, интероперабельности не получилось.
но и на том спасибо.
BPMN похоже на инфоциганство, как без этого жили раньше и создавали мегокорпорации и заводы. Это инструменты "эффективных" менеджеров, которые про бизнес слышали от таких же инфоцыган
Раньше и без интернета жили и ничего, обходились.
BPMN давно зрелая технология. Не панацея, но в своей области работает.
Это инструмент разработчика, одними картинками все не заканчивается, еще код писать надо.
Примеры найти несложно, стоит только захотеть
BPMN это нотация, инструмент BPM - business process management (управление бизнес процессами)
BPM это инструмент Тейлоризма - одной из теорий управления, научной организации труда, показавшей преимущества и экономическую эфективность разделения труда для повышения его производительности. Тейлоризм - одна из первых где применили научные методы конструирования процессов и управления.
До BPMN инструментами BPM стали Flowchart, IDEF, EPC
Его цель — создать единый способ моделирования бизнес-процессов, понятный всем заинтересованным сторонам: от бизнес-пользователей, менеджеров и аналитиков до разработчиков и систем, исполняющих эти процессы.
Это не совсем так (цитаты):
Джим Синур, ведущий аналитик Gartner в области BPM, расшифровал BPMN как «Business People May Not understand», то есть «люди бизнеса могут и не понимать» эту нотацию. По мнению многих специалистов BPMN-модели на практике быстро становятся очень громоздкими и сложными для восприятия и анализа.
1. Сложность: BPMN является сложным языком, который требует от разработчиков знаний в области управления процессами и моделирования.
Тем не менее, преобладающие доказательства говорят о том, что большинство бизнес-профессионалов не получают достаточно преимуществ, чтобы оправдать их желание изучать его.
Кратенько о BPMN:
Почему следует отказаться от BPMN
Почему BPMN может не подойти для ваших нужд ...
продолжать можно дальше ...
В целом BPMN не решил как
задачу получить понятную бизнесу нотацию: в BPMN 2.0 более 100 элементов (только типы событий включают около 20 вариантов) и она "не понятна бизнесу" (как бы в это не хотелось верить), так и
задачу автоматизации по принципу "программирование без программирования", т.к. все равно понадобится "много кода" (программисты), исключение (no code) составят только простенькие задачи типа Hello Calculator.
Другая серьезная проблема BPMN - это моделирование только WorkFlow. Для моделирования бизнес-процессов "половину модели" составляет моделирование данных / документов (в привязке к workflow), а Data Objects не решает такую задачу в нужном объеме.
Насколько я вижу, OMG охладела к развитию нотации BPMN (как ранее к UML переключившись с нее на BPMN).
Да хватит уже ссылаться на мою статью десятилетней давности))
BPM для людей и для систем, причем выдергивая из нее цитаты, которые удобны
Ну да, чтобы нотацию понимать, ее надо учить.
Почему это плохо?
И кто такой этот "бизнес"? Это слишком абстрактно.
Конечно, исполнитель или даже начальник департамента не обязаны знать нотацию.
Но процессный офис -- другое дело. И это не ИТ.
Зайдите на конфу ABPMP, бизнес вполне шарит в BPMN.
Так же непонятно, зачем BPMN куда-то "развивать".
Это стандарт, который работает.
BPMN 3.0 никто не ждет. Это не новый айфон.
надо ли развивать TCP/IP и каждый год выпускать новую версию?
Для моделирования данных есть другие инструменты, нет такой задачи тащить данные внутрь процесса. Это вообще противопоказано.
И нет такой задачи, чтобы обойтись без программистов.
No-code подходит только для узких нишеых применений, которые можно хорошо покрыть абстракциями. Для энтерпрайз-приложений это не подходит, там нужны инструменты профессиональной разработки.
Но BPM-движок вполне вписывается в корпоративный ландшафт и свою задачу по управлению процессами решает.
Да хватит уже ссылаться на мою статью десятилетней давности))BPM для людей и для систем, причем выдергивая из нее цитаты, которые удобны
Вы про альтернативный перевод сокращения "BPMN" от Джима Синура? Так его сразу кроме вас в нескольких десятках статей только в ру-сегменте процитировали.
надо ли развивать TCP/IP и каждый год выпускать новую версию?
Пара примеров: ipv6 или попробуйте на компе с winXP походить по инету (многое уже не откроется). Стек TCP/IP постоянно развивается, спросите ИИ хотя бы за период с 2020.
Сколько лет прошло между IPv4 и IPv6?
Известно же: работает — не трожь!
М-р Синур говорит вполне очевидную вещь: интуитивно нотация BPMN непонятна.
Но сказал он это 10 лет назад.
С тех пор по крайней мере среди аналитиков знание BPMN стало почти обязательным. На любом собеседовании спросят.
Если надо, аналитик чисто бизнесу объяснит, у него работа такая.
Не вижу тут проблемы.
BPMN умер, все сделает ИИ