Comments 12
Спасибо за статью.
Хорошо ее прочесть в дополнение к универскому курсу по моделированию бизнес-процессов. Именно такие вопросы "а как правильно делать-то?" возникают сразу, как только начинаешь работать с BPMN.
Преподавателю, наверное, пошлю ссылку.
Коллеги, BPMN нцжен в первую очередь для оценки трудокмкосьи дораьотки. И отображения и фиксации полноты процесса. Все остальное от меры испорченности
Добрый день! По моему опыту, основная цель использования BPMN зависит от уровня зрелости организации. Если она небольшая и незрелая, то аналитик или тимлид использует BPMN, чтобы определить участников и перечень процессов, а также их основные этапы и целесообразность запуска работ по их автоматизации.
Если организация зрелая, ведётся реестр процессов, внедрена BPMS, и процессы уже автоматизированы, тогда BPMN используется для сбора функциональных и нефункциональных требований и оценки трудоёмкости доработки.
Привет, спасибо что упомянули наш инструмент Stormbpmn , внизу ссылка правда не та)
Глубина проработки материала отличная, бпмн из коробки немного дурацкий, но зато с кучей возможностей, которые иногда могут быть полезны.
Чтобы немного облегчить жизнь для фанатов BPMN написали соглашение о моделировании, можно использовать в работе https://stormbpmn.com/bpm/process-modelling-agreement
Стандарт недоработанный, избыточный, неоднозначный, и где-то противоречивый, из-за чего им сложно эффективно пользоваться, особенно в реальных больших проектах.
1 Исполнимость
1.1 Трамплин BPMN был основан на его изначальной исполнимости: WF\BPMN-engine.
1.2 Исполнимость (в варианте low code) – это была (и остается) «идея фикс» (одержимость) BPM начала 90-х. Казалось, что изначальная связка BPM-ERP (ARIS-SAP) вот-вот реализует концепт «модель -> система / исполняемый код».
1.3 Сейчас OGM (не путать с OG – ArchiMate) фактически бросила развитие BPMN, как и ранее UML (кошка бросила котят …) переключившись с UML как раз на «перспективный BPMN». Полагаю, что в основном из-за разочарования в текущей технологии BPMN-engine.
Полагаю, что если в BPMN повысить исполнимость workflow в несколько раз и добавить «исполняемый docflow» и т.п., то это будет уже иная технология. Текущего уровня формализма в BPMN недостаточно (BPDM, DMN не особо помогли), чтобы делать не то что «no code», а даже совместимый «low code».
И ... «BPMN 3.0, которого не будет»
2 Не исполнимость
2.1 Неисполняемый BPMN ничем не лучше того же EPC. Более того, «котовские отмены дорожек» - приближают его к EPC даже визуально, а зоопарк значков делает BPMN непонятным бизнесу по сравнению даже с EPC.
Одних только стартовых событий в BPMN - 23 значка (складывает три столбца 7+9+7).
2.2 Если говорить о математизации \ семантизации workflow, то и тут BPMN «не очень», впрочем, как и его ответвление в этом направлении YAWL.
Зачем нужны Data Objects vs {Data Inputs \ Data Outputs) - если стрелка к объекту однозначно определяет входные они или выходные? При этом Data Objects обычно одновременно и входной и выходной (см. EPC). Association (Data Objects) «привязанная» к Sequence Flow, Направленная ассоциация vs «Data Association» и др.
2.3 Концепт «единая простыня» - когда есть одна «большая безразмерная схема», не помещающаяся в А4, – это не про документацию. Можно декомпозировать и т.п., но это не очень помогает в реальных проектах.
Добрый день. Про неисполнимость процессов - согласен.
Про исполнимость специально писать не стал. Слишком много печального опыта накопилось. Особенно, когда организация решает задачу одного заказчика и подбирает технологический стек для быстрого решения только этой задачи.
Маркетологи компании, стремясь расширить рынок, утверждают, что система поддерживает low‑code и BPMN для решения любых задач. Заказчик, не особо разбираясь в BPMN, покупает систему и начинает переносить свои процессы. Но они не работают - и тогда подключаются аналитики, а затем и разработчики.
Разработчики понимают, что требования заказчика можно реализовать в 100 раз быстрее и дешевле, но нужно "снести" всё, что сделал заказчик и использовать другой стек. А это делать нельзя, т.к. сроки уже прошли и заказчик перенёс все свои процессы в BPMS и ждёт, когда они заработают.
Такие проекты, где объединяются непонимание BPMN, недоработки стандарта, ограничения технологического стека и его неприменимость к текущим задачам, настоящий кошмар для всех участников. На них выгорают и сотрудники заказчиков, и аналитики, и руководители проектов и разработчики.
Поэтому я бы рекомендовал тем, кто хочет использовать BPMN для автоматизации, очень хорошо разобраться в стандарте, уточнить используемый стек. Кроме того понимать, что первая часть стандарта описывает нотацию для рисования схем, а вторая часть модель для автоматизации процессов. Выяснить, какую часть разработчик реализовал в BPMS-системе и насколько процентов. Это очень важно понять до внедрения. Очень печально, если система поддерживает 80% BPMN в части проектирования схем, 40% в части автоматизации и стек, который не получится доработать.
Даже интересно что же ждёт нас в Части 2 этого обзора? Краевые события?
Вот за что неистово плюсанул автору, так это за "соглашение о моделировании". Всё так. Лично наблюдал 3 сильно разных версии BPMN в достаточно крупных компаниях
плюсанул автору, так это за "соглашение о моделировании".
Подобное тут складываю.
интересно что же ждёт нас в Части 2 этого обзора?
Обзоры: BPMN MetaModel (хотя бы наподобие archimate) \ BPMN Engine \ BPMN Simulator \ генератор схемы по текстовому описанию (llm) или табличному (наподобие smart design) \ BPMN as Code (dot\mermaid\Plant"BPMN")? Угадал хоть что-то?
Также хотелось бы ссылки на библиотеки значков BPMN для visio (может есть сторонние), Drawio, yEd и т.п. Может есть BPMN в связке с репозитарием (процессный репозитарий free \ open source), как вариант c excel-repo на штатной связке visio-excel.
Добрый день! Во второй части будут советы и примеры проектирования процессов для аналитиков и тимлидов. Краевых событий не будет.
Мой опыт расходится с академическими методиками моделирования, которые описаны в большинстве статей и курсов. Из-за этого я как аналитик часто сомневаюсь в своих компетенциях, особенно при использовании BPMN. Постепенно сложилось впечатление, что академические методики хороши лишь в идеальных, несуществующих организациях. В реальной жизни их применение часто приводит к конфликтам, выгоранию специалистов или разочарованию в нотации.
Как и про капитализм - можно тонны причин привести, почему и та и другая вещи - не есть perfect, вопрос только в том, а какая альтернатива лучше?
Добрый день! В стандарте по бизнес анализу "Guide to the Business Analysis Body of Knowledge" (BABOK) для моделирования и анализа процессов приведены 5 альтернатив: Flowchart, UML, BPMN, IDEF, SIPOC.
Я не призываю отказаться от BPMN. Напротив, я активно использую этот инструмент в работе. UML как альтернатива также является международным стандартом, но мне легко читать диаграммы активности, use case и классов, спроектированные специалистами по всему миру независимо от их уровня. А с BPMN возникают сложности, если автор при моделировании не учитывает неоднозначные моменты и не поясняет логику выбора элементов нотации.
В статье предлагаю обратить внимание на недостатки BPMN, которые важно учесть до начала моделирования, чтобы сделать его эффективным.
BPMN для аналитиков и тимлидов (часть 1)