CamundaCon 2024 New York

Всем привет! На связи рубрика техно-дайджест 😎

Не так давно прошла ежегодная конференция CamundaConf 2024 в Нью-Йорке. Конференция проходила в традиционном формате в течении двух дней. Главными темами мероприятия стали следующие направления:

Внедрение
Техно гиганты, такие как Walmart, Atlassian, US Bank, Infosys, собрались не просто поразмышлять о современных тенденциях в автоматизации бизнес процессов, а поделиться успешными кейсами в цифровой трансформации.

Искусственный интеллект
Особое внимание уделили хайповой теме искусственного интеллекта. Создатели Camunda приоткрыли завесу тайн и поведали дальнейшие планы по развитию ИИ в платформе.
Интересный доклад был не только от вендора, но от компании Infosys по действительно оправданному внедрению ИИ, они продемонстрировали ИИ, как следующий пользовательский интерфейс в связке с Camunda.

Миграция
Не обошлось и без животрепещущей темы миграция на современную версию Camunda 8. И да, это были не смузи доклады об успешной успехе под чашечку кофе, а настоящий хардкор от Alliander.

Low-code
Также стороной не прошла тема Low-code решений, компания BNY Mellon представила собственную платформу на базе Camunda для минимизации программирования в условиях постоянно меняющихся требований бизнеса.

Итоги
CamundaCon 2024 продемонстрировала, что бизнес-процессы - это не просто визуализация ваших процессов, а реальный инструмент автоматизации, который идёт в ногу со временем. Для тех, кто пропустил все материалы можно найти на официальном сайте Camunda.

А также прочитать сводку в live-блоге:
День 1.
День 2.

#технодайджест@bpm_developers

State Machine вместо BPMN? Ну, такое…

Машины состояний (они же конечные автоматы) хорошо известны разработчикам. Поэтому, когда их просят автоматизировать какой-то процесс, частенько мысль о машине состояний первой приходит в голову, а вовсе не BPMN. А почему бы нет? – Зачем изучать новую нотацию, если можно использовать то, что проходили в универе?

Окей, для простых воркфлоу из нескольких шагов это вполне разумный выбор. Однако, при добавлении новых состояний и переходов модель может стать весьма сложной, что может затруднить читаемость и поддержку. Это еще мягко сказано. Модель на основе машины состояний с ростом сложности становится просто нечитаемой. И это главная проблема.

BPMN гораздо более толерантна к росту сложности, особенно если следовать лучшим практикам проектирования процессов, а не самодеятельничать. Конечно. BPMN не всемогущ, у этого подхода есть свои ограничения. А пока просто помним, что знакомое не всегда лучшее и выбираем BPMN, а не State Machine, когда дело пахнет сложностью.

Приглашаем обсудить это в комментариях 🙂

Почему именно BPMN?

В мире есть множество нотаций для моделирования бизнес-процессов, кроме BPMN: IDEF0, EPC, UML, Flowchart, SIPOC, UPN, VAD и другие. Почему именно BPMN стал стандартом де-факто?

Элементарно! Потому что BPMN – это единственная нотация, которая может исполняться движком. То есть, как нарисовано, так и работает. Появление BPMN стали таким же прорывом в автоматизации процессов, как появление WYSIWYG-редакторов для работы с текстом.

Почему так не получились с другими нотациями? Потому что, когда их разрабатывали, такой задачи не ставилось, хотели просто графически представить процесс, чтобы людям было легче понять друг друга. А, как мы знаем, если что-то не было заложено в дизайне системы, изменения потом могут стоить очень дорого.

До сих пор в кабинетах высокого начальства можно увидеть красивые диаграммы в разных нотациях, которые так и не стали автоматизированными процессами. Что ж, общее понимание процесса тоже важно. Но лучше, когда он еще и исполняется – а BPMN это может!

История BPM #1

Мало кто решится поспорить, что BPM зародился в начале XX века, когда американский инженер Фредерик Тейлор вывел принципы повышения производительности труда. Он ввел анализ бизнес-процессов предприятия, говорил о важности оптимизации, об отборе, обучении и развитие исполнителей - привет HR'ам, а еще про распределение труда и ответственности.

А когда к его исследованиям добавились идеи Шухарта и Деминга - все помнят про цикл PDCA? - то управление бизнес-процессами вышло на новый виток: это контроль на основе измерений, ограничения в вариативности процессов, акцент на постоянное улучшение.

#историяbpm

Реализации BPMN: To-Be и As-Is

Когда спецификация BPMN только разрабатывалась, в воздухе витала идея, что появится множество продуктов, которые ее реализуют, и что они будут совместимы. Как совместимы сетевые устройства – включил и работает.

Но бизнес-процесс — это абстракция гораздо более высокого уровня, чем сетевые протоколы. Поэтому не получается с помощью квадратиков и ромбиков описать все тонкости взаимодействия людей и систем. Реальный мир устроен сложнее.

В результате мы имеем множество продуктов, поддерживающих BPMN, но каждый немножко по-своему. Причем отклонения возможны как в минус, так и в плюс: с одной стороны, какие-то элементы BPMN могут не поддерживаться; с другой – разработчики добавляют свои расширения.

Так что об интероперабельности систем моделирования процессов можно забыть. Если взять модель процесса из одной системы и загрузить ее в другую, то не факт, что все будет гладко.

И как с этим жить? Стандартизуйте средства моделирования процессов на уровне организации и будет вам счастье!

🚀 Открыт прием заявок на конкурс «BPM проект года’2025»! 

Это ваш шанс: 
✅ Представить свой проект на суд экспертов. 
✅ Поделиться опытом с профессиональным сообществом. 
✅ Получить признание и поддержку от коллег и руководства. 
🌟 Финалисты и победители конкурса — лидеры процессного управления, за которыми будущее! 
📅 Подача заявок открывается с 1 декабря 2024 года! 
Все подробности — на сайте: bpmaward.ru 
Действуйте уже сегодня!

Open source правит миром

В том, что ИТ-индустрию накрыла волна open source и переформатировала подходы к построению архитектуры и разработке программных продуктов у нас нет никаких сомнений. Однако, порой одна картинка стоит тысячи слов – и вот как раз одна из таких.

На этом графике по мы можем сравнить совокупную рыночную капитализацию компаний двух категорий. Одни по традиции разрабатывают продукты с закрытым исходным кодом, вторые – строят решения на основе open source. Площадь под кривой показывает совокупную рыночную капитализацию компаний в каждой из категорий за период с 1970 года по 2020+

Капитализация поставщиков закрытого ПО составляет 20 трлн долларов за 50 лет, но темпы роста замедляются. 📉
Капитализация поставщиков решений на основе открытого ПО меньше (10–500 млрд долларов с 2010 года), но темпы роста ускоряются. 📈

Глядя на этот график, можно прогнозировать, что пройдет едва ли десять лет до того, как открытое ПО начнет доминировать в мире.

Марк Андриссен (Marc Andreessen), соучредитель и генеральный партнер венчурной фирмы Andreessen-Horowitz, которая инвестировала в Facebook, Groupon, Skype, Twitter и других нынешних ИТ-гигантов, в далеком сегодня 2011 году, когда у инвесторов еще не прошла боль после краха пузыря дот-комов, говорил, что “Software eats the world” – то есть, все отрасли, все сферы человеческой деятельности компьютеризируются и начинают зависеть от софта. Поэтому инвестировать в программное обеспечение будет выгодно.

Несомненно, он был прав. Сегодня ничто не может работать без софта – от уличного ларька до космической станции, так что те, кто последовал его совету, не прогадали.

Однако в наши дни набирает силу новая волна – вместо проприетарных продуктов заказчики начинают выбирать продукты с открытым кодом, причем этот процесс идет значительно быстрее первичной компьютеризации. Организация COSS Community много лет декларирует, что “Open source eats software FASTER, then software eats the world!”, то есть:

«ПО с открытым исходным кодом пожирает программное обеспечение быстрее, чем программное обеспечение пожирает мир»

Похоже, этот прогноз начинает сбываться.

Источники:
https://a16z.com/why-software-is-eating-the-world/
https://www.coss.community/cossc/open-source-is-eating-software-faster-than-software-is-eating-the-world-3b01

Люди BPM - Денис Котов

В русскоязычном BPM сообществе вряд ли найдется человек, который приложил больше усилий для популяризации методологии. Денис занимается бизнес-процессами более 12 лет. Ранее разрабатывал системы для активации и выдачи финансовых продуктов в таких банках как ПСБ, Ак Барс, МСП, Локо, Зенит, Тинькофф.

Денис создал множество обучающих материалов, например перевел ABPMP CBOK и глоссарий BPMN на русский язык. На Youtube канале выложено множество вебинаров, а подписаться на рассылку это must-have для каждого, кто хочет заниматься бизнес-процессами.

Сейчас Денис сосредоточился на собственном продукте Stormbpmn. Это инструмент для моделирования бизнес-процессов, который помогает бизнес-аналитикам и их коллегам работать над сложными процессами.

#людиbpm

#пятничное субботнее

🔥 Почему разработчики избегают BPM движков?

Для многих Java-разработчиков идея использования BPM движков кажется сложной и чуждой. Но почему?

БЫЛ ОДИН СЛУЧАЙ

Представьте: обычная команда Java-разработчиков. Проект по автоматизации закупочных бизнес-процессов компании. Весь код написан на привычном стеке: Spring Boot, Hibernate, REST API. Фронтендеры сами копошатся с формочками. Каждый процесс прописан детально — от начала до конца, используя if-else конструкции, сервисы и базы данных.

И тут приходит бизнес с новым требованием:
— Мы придумали новое управление по “закошмариванию” поставщиков и теперь все закупки свыше 1 000 000 руб. через них. Вот тут мы с аналитиками в BPMN 2.0 все накидали. Владельцем процесса становится Сан Саныч. Он будет вот эти метрики мониторить вместе со всеми процессами. Изменения небольшие, но затрагивают 80% закупок. Через 2 недели начинаем работать в соответствии с новой схемой.

Команда хватается за голову. Неужели придется внедрять-таки проклятущий BPM движок? Это же то самое сложное, неприятно лоу-кодное, да еще и врубаться в эту дрянь! У команды возникает ощущение, что их лишают свободы:
• Придется учить новый инструмент.
• Пропадет контроль над кодом.
• Все процессы превратятся в непонятные «черные ящики».
Звучит знакомо? Думаю да, для всех кому приходилось адвокатить BPM в командах профессиональной разработки.

ПОЧЕМУ CAMUNDA — НЕ ВРАГ, А ДРУГ РАЗРАБОТЧИКА?

1️⃣ Java-friendly платформа

Camunda создана с учетом потребностей Java-разработчиков. Она не навязывает вам чуждый стек, а органично интегрируется в ваш привычный мир, а с помощью плагинов еще и в вашу привычную IDE:
• Вы продолжаете писать код на Java. Camunda поддерживает написание кастомной бизнес-логики в Service Tasks с использованием Java Delegate или паттерна External Tasks. Паттерн External Tasks позволяет описать логику в любом стороннем сервисе и необязательно на Java.
• Благодаря поддержке Spring Boot и JPA в ваших сервисах вы работаете с данными так же, как вы привыкли.
Для тех, кто боится потерять контроль над кодом, Camunda — это не «черный ящик», а понятный и хорошо документированный инструмент.

2️⃣ Миф о лоу-кодности

Использование BPM движка пугает из-за того, что его часто ассоциируют с визуальным редактированием процессов. Кажется, что это неудобно и медленно. Но в Camunda вы можете комбинировать визуальное представление BPMN схемы с чистой BPMN 2.0 XML разметкой и Java-кодом:
• Визуальная схема процесса становится общей точкой взаимодействия с бизнесом, а вся кастомная логика остается в коде.
• Визуальная модель помогает быстрее “въехать” в задачу и упростить коммуникации с аналитиками.
• XML представление модели процесса легко версионируется с помощью стандартных инструментов разработчика.
На самом деле это упрощает, а не усложняет жизнь разработчика.

3️⃣ Контроль и прозрачность

Разработчики часто боятся BPM движков, потому что думают, что теряют контроль над процессами. Но с Camunda вы контролируете всё:
• Встроенные инструменты мониторинга позволяют видеть выполнение процессов в реальном времени и отрабатывать инциденты.
• Исходный код открыт. Вы можете «залезть» в любую часть движка, чтобы понять, как всё работает.
Тоже самое касается и альтернативных популярных open-source BPM движков: Flowable и Activiti.

Это поможет убедить команду использовать BPM? - Мммм, не сразу

Скорее всего команда из нашей истории попытается сделать все по старинке, угорит от рефакторинга и регресса, и только потом вспомнит про этот пост и хотя бы попробует на тестовом проекте. Начало использование BPM движков — это серьёзный шаг к изменению принятых в конторе шаблонов проектирования. Несмотря на то, что подход уже доказал свою жизнеспособность естественным ростом сообщества BPM технологий во всем мире, первые шаги обычно даются очень тяжело. Именно поэтому мы ведем этот канал, чтобы увлеченных становилось больше, а страданий enterprise разработчиков меньше.

❓Вам показалась знакомой ситуация из данного поста? Расскажите свою историю в комментах и получите наш мерч первыми - как только мы его сделаем 🙂