Смелое решение. Тогда пожалуйста подскажите как онбордите и учите системных аналитиков, для ваших масштабов это же не 5 человек и не 50, там речь идет на сотни? У вас договор с каким-то учебным заведением или со своим корпоративным университетом и там отдельный учебный курс разработан по этой новой нотации? Есть ли увязка с ГОСТ-ами по совершенствованию бизнес-процессов, экзамены, сертификация и все такое?
Добрый день. Подскажите пожалуйста, а какой BPM-движок по итогу выбрали для работы с бизнес-процессами в нотации BPMN 2.0? Или, может быть, вы отказались от следования этой нотации и перешли на что-то архитектурно совсем иное?
2) Вы пишите про санкционные ограничения Camunda 8, но ничего не пишите про санкционные ограничения Flowable. Справедливости ради, Швейцария прям сильно ревностно следит за исполнением санкционных ограничений ЕС, по который компаниям запрещено поставлять в РФ ПО для автоматизации процессов в промышленности. Поэтому любой покупатель лицензии Flowable автоматически попадает на проверку по этим санкционным ограничениям. Про open-source варианты ПО в директиве ЕС никаких оговорок нет, там только сказано про вендоров. Поэтому часть юристов считает, что если open-source версия развивается не сообществом, а тем же вендором, то автоматически на нее распространяются санкционные ограничения.
И какой-то уж очень сложный путь у вас получился. Можно было просто на GitFlic скачать бесплатную open-source версию продукта OpenBPM и запустить ее поверх ваших старых баз Camunda 7 CE, все бы подхватилось и заработало автоматом. Без всяких адаптеров через Kafka. Может еще не поздно попробовать :-)
Добрый. Выше в комментариях вы написали, что не могли оценить OpenBPM, так как по нему было "мало информации". Вот, собственно, этот пробел я и попытался заполнить. С призывом еще раз пообщаться на уровне инженерных команд и взять наш форк за основу.
Пожалуйста: чем сегодняшний день и завершение анализа результатов исследования с командами. По крайней мере, такое складывается впечатление. Может чисто субъективное. В ближайшие пару дней скину статью с тем, как мы видим покрытие функциональной карты потребностей. Сравнимся.
А вообще конечно нас вот это сильно зацепило: "Внешний форк — это иллюзия экономии. На самом деле он создает новую зависимость, риски и технический долг."
Обидно, что столь сильное утверждение приведено с нулевой аргументацией. Особенно для тех, кто такой форк уже подготовил и активно развивает.
Да, конечно. Даже в статье у вас остались артефакты, которые говорят о том, что статья писалась заранее, еще в прошлом году: "Camunda 7: зрелость, но EOL на горизонте". При том, что EOL был в октябре. А общения с архитекторами и программистами команд мы начинали в январе-феврале 2025 :-)
Жму руку. Мы так и поняли, что политическое решение "о своем форке" было принято банком заранее, и потом под него уже просто подводились аргументы. Поэтому мы чуть позже сделаем развернутый ответ статьей на Хабре.
Привет. Здорово, что такой крупный банк с сильной архитектурной командой пришел к тем же самым выводам что и мы в компании Хоулмонт! Однако, отмечу пару странных моментов:
OpenBPM имеет бесплатную open-source версию Community, опубликованную в открытых исходных кодах на GitFlic, которая на голову выше Camunda7 по безопасности и уже вобрала в себя все перспективные доработки от Operaton. То есть дальше форкать имеет смысл уже это ядро, как более стабильное и современное. Это сэкономит под тысячу человеко-часов.
ТБанк огромная организация, мы много раз предлагали совместные тесты как по движку, так и по инструментам для процессно-ориентированных команд. Странно, что ни разу не пересеклись с автором этой статьи :-)
В любом случае желаю удачи и искренне надеюсь на продолжение наших контактов на уровне инженерных команд.
Игорь Клопотов, Хоулмонт (Самара), команда продукта OpenBPM
Вы правы, спасибо. Если не следить за темой по статьям наших аналитиков на Хабре (а их вышло уже более 40 штук по работе BPM-движков) то может быть трудно сориентироваться. Обязательно учтем этот момент на будущее.
Извините, но причем тут BPMN? Эта спецификация вообще никак не отменяет разработку, более того, она добавляет в разработку новые достаточно сложные паттерны (external task, message, event listeners и т.п.) для реализации которых нужно писать порядочно кода. Просто архитектурно итоговое решение получается гораздо чище и изящнее (да и BPM-движки можно менять по ходу, не ломая логику прикладного проекта).
Доброго времени суток. Вы абсолютно правы, там пока опубликован текст по состоянию на конец 2024 года, и у нас просто рук на все не хватает. Ближе к релизу мы обязательно обновим, вернее существенно пересмотрим лицензионную политику. Как раз сегодня этот вопрос обсуждали в продуктовом чате по OpenBPM.
Добрый день, приятно встретить знатока! Ну почему же без указания, в статье явно сказано о том, что мы взяли основу со строительной темы. Изменения есть, и по числу карточек, и по ограничениям на участника, и по стоимости достижения целей. Мы повысили динамику.
Долгое время BPM-системы строились вокруг идеи, что процесс сначала моделируется, затем передается разработчикам и только потом внедряется. На практике оказалось, что этот путь слишком длинный и неэффективный. Бизнесу нужны инструменты, позволяющие сразу тестировать и запускать процессы в работу.
Категорически не могу согласиться с автором. Тут перевернуто "с ног на голову". С точки зрения бизнеса BPM - это концепция управления, которая увязывает стратегию и цели организации с ожиданиями и потребностями клиентов через построение сквозных бизнес-процессов. То есть на верхнем уровне моделируется не передача документа от одного подразделения к другому, а путь формирования ценности для конечного клиента. И уже потом, на следующих уровнях уточняется как именно каждое из подразделений вносит свой вклад.
А еще потом, совсем-совсем потом, на самом низком уровне отбираются элементы маршрутов, на предмет их автоматизации. И при автоматизации исполнения процессов как раз появляются технические этапы прототипирования и отладки. Инструментов для этого огромное количество, в том числе инструментов на базе спецификаций BPMN и DMN, выполненных в low-code или по no-code формате. Но это совершенно никак не отменяет опоры на промышленную спецификацию.
Вы бы хоть статью в блоге bpmn.io дочитали, там в конце все очень подробно расписано и не пришлось бы "расследование" проводить. И да, мы с немецкими коллегами в хороших отношениях поскольку взаимно развиваем продукты. Процитирую:
About the Author
Viktor Fadeev is a Jmix product marketing manager and works at Haulmont, where we’re focused on developing tools and platforms that enhance developers’ productivity by automating coding routines and bringing ready-to-use application components into a single development environment — IntelliJ IDEA.
Приветствую! Форков разной степени готовности в мире гуляет достаточно много, они то появляются, то исчезают. Это сложный вопрос, на самом деле. Если говорить про РФ, то об официальном выпуске форка Camunda 7, который будет в Роспатенте и потом в Реестре МинЦифры, буквально на днях (5 февраля на MTS Link, 6 февраля на CNews) объявила компания Хоулмонт.
Описываемый Вами подход интересный, но он не лишен разбираемых в статье проблем. Разработчик по-прежнему будет ограничен возможностями дизайнера прикладных сущностей (Data models), и "биндингом", реализованным в конкретной сборке BPMS. Мы же говорим о том, что это принципиальное ограничение и снять его можно только полным и безоговорочным "раскрытием" BPMS контура, чтобы разработчик получил возможность использовать всю полноту программного стека (который постоянно совершенствуется), не теряя при этом преимуществ готового workflow, предоставляемого со стороны процессных движков.
Спасибо за Ваше мнение. Как раз проблема в том, что новые Low Code платформы в точности повторяют путь BPMS, развиваясь по модели закрытых изолированных контуров. Исход в таком случае очевиден. Мы получим все те же "траблы", просто на новом витке спирали эволюционного развития.
Смелое решение. Тогда пожалуйста подскажите как онбордите и учите системных аналитиков, для ваших масштабов это же не 5 человек и не 50, там речь идет на сотни? У вас договор с каким-то учебным заведением или со своим корпоративным университетом и там отдельный учебный курс разработан по этой новой нотации? Есть ли увязка с ГОСТ-ами по совершенствованию бизнес-процессов, экзамены, сертификация и все такое?
Добрый день. Подскажите пожалуйста, а какой BPM-движок по итогу выбрали для работы с бизнес-процессами в нотации BPMN 2.0? Или, может быть, вы отказались от следования этой нотации и перешли на что-то архитектурно совсем иное?
Добрый день. Большое спасибо за статью, хорошо написано с точки зрения планирования и управления командой. Но пара моментов "резанула глаз".
1) У Camunda 7 CE нет поддержки до 2030 года, как вы пишите. И патчи от платной версии не подходят. Вот здесь подробнее мы эту тему разбирали: https://openbpm.ru/blog/camunda-7-support-end-date
2) Вы пишите про санкционные ограничения Camunda 8, но ничего не пишите про санкционные ограничения Flowable. Справедливости ради, Швейцария прям сильно ревностно следит за исполнением санкционных ограничений ЕС, по который компаниям запрещено поставлять в РФ ПО для автоматизации процессов в промышленности. Поэтому любой покупатель лицензии Flowable автоматически попадает на проверку по этим санкционным ограничениям. Про open-source варианты ПО в директиве ЕС никаких оговорок нет, там только сказано про вендоров. Поэтому часть юристов считает, что если open-source версия развивается не сообществом, а тем же вендором, то автоматически на нее распространяются санкционные ограничения.
И какой-то уж очень сложный путь у вас получился. Можно было просто на GitFlic скачать бесплатную open-source версию продукта OpenBPM и запустить ее поверх ваших старых баз Camunda 7 CE, все бы подхватилось и заработало автоматом. Без всяких адаптеров через Kafka. Может еще не поздно попробовать :-)
Добрый. Выше в комментариях вы написали, что не могли оценить OpenBPM, так как по нему было "мало информации". Вот, собственно, этот пробел я и попытался заполнить. С призывом еще раз пообщаться на уровне инженерных команд и взять наш форк за основу.
Ноу проблем. Для удобства перенес ссылку прямо в начало статьи.
Добрый день. Так прямо в конце статьи ссылка на GitFlic с исходниками :-)
Доброго дня. Подготовил развернутый ответ в виде статьи о нашем взгляде на развитие форка.
Пожалуйста: чем сегодняшний день и завершение анализа результатов исследования с командами. По крайней мере, такое складывается впечатление. Может чисто субъективное. В ближайшие пару дней скину статью с тем, как мы видим покрытие функциональной карты потребностей. Сравнимся.
А вообще конечно нас вот это сильно зацепило: "Внешний форк — это иллюзия экономии. На самом деле он создает новую зависимость, риски и технический долг."
Обидно, что столь сильное утверждение приведено с нулевой аргументацией. Особенно для тех, кто такой форк уже подготовил и активно развивает.
Да, конечно. Даже в статье у вас остались артефакты, которые говорят о том, что статья писалась заранее, еще в прошлом году: "Camunda 7: зрелость, но EOL на горизонте". При том, что EOL был в октябре. А общения с архитекторами и программистами команд мы начинали в январе-феврале 2025 :-)
Жму руку. Мы так и поняли, что политическое решение "о своем форке" было принято банком заранее, и потом под него уже просто подводились аргументы. Поэтому мы чуть позже сделаем развернутый ответ статьей на Хабре.
Привет. Здорово, что такой крупный банк с сильной архитектурной командой пришел к тем же самым выводам что и мы в компании Хоулмонт! Однако, отмечу пару странных моментов:
OpenBPM имеет бесплатную open-source версию Community, опубликованную в открытых исходных кодах на GitFlic, которая на голову выше Camunda7 по безопасности и уже вобрала в себя все перспективные доработки от Operaton. То есть дальше форкать имеет смысл уже это ядро, как более стабильное и современное. Это сэкономит под тысячу человеко-часов.
ТБанк огромная организация, мы много раз предлагали совместные тесты как по движку, так и по инструментам для процессно-ориентированных команд. Странно, что ни разу не пересеклись с автором этой статьи :-)
В любом случае желаю удачи и искренне надеюсь на продолжение наших контактов на уровне инженерных команд.
Игорь Клопотов, Хоулмонт (Самара), команда продукта OpenBPM
Вы правы, спасибо. Если не следить за темой по статьям наших аналитиков на Хабре (а их вышло уже более 40 штук по работе BPM-движков) то может быть трудно сориентироваться. Обязательно учтем этот момент на будущее.
Извините, но причем тут BPMN? Эта спецификация вообще никак не отменяет разработку, более того, она добавляет в разработку новые достаточно сложные паттерны (external task, message, event listeners и т.п.) для реализации которых нужно писать порядочно кода. Просто архитектурно итоговое решение получается гораздо чище и изящнее (да и BPM-движки можно менять по ходу, не ломая логику прикладного проекта).
Доброго времени суток. Вы абсолютно правы, там пока опубликован текст по состоянию на конец 2024 года, и у нас просто рук на все не хватает. Ближе к релизу мы обязательно обновим, вернее существенно пересмотрим лицензионную политику. Как раз сегодня этот вопрос обсуждали в продуктовом чате по OpenBPM.
Добрый день, приятно встретить знатока! Ну почему же без указания, в статье явно сказано о том, что мы взяли основу со строительной темы. Изменения есть, и по числу карточек, и по ограничениям на участника, и по стоимости достижения целей. Мы повысили динамику.
Категорически не могу согласиться с автором. Тут перевернуто "с ног на голову". С точки зрения бизнеса BPM - это концепция управления, которая увязывает стратегию и цели организации с ожиданиями и потребностями клиентов через построение сквозных бизнес-процессов. То есть на верхнем уровне моделируется не передача документа от одного подразделения к другому, а путь формирования ценности для конечного клиента. И уже потом, на следующих уровнях уточняется как именно каждое из подразделений вносит свой вклад.
А еще потом, совсем-совсем потом, на самом низком уровне отбираются элементы маршрутов, на предмет их автоматизации. И при автоматизации исполнения процессов как раз появляются технические этапы прототипирования и отладки. Инструментов для этого огромное количество, в том числе инструментов на базе спецификаций BPMN и DMN, выполненных в low-code или по no-code формате. Но это совершенно никак не отменяет опоры на промышленную спецификацию.
Спасибо, искренне улыбнуло :-)
Вы бы хоть статью в блоге bpmn.io дочитали, там в конце все очень подробно расписано и не пришлось бы "расследование" проводить. И да, мы с немецкими коллегами в хороших отношениях поскольку взаимно развиваем продукты. Процитирую:
About the Author
Viktor Fadeev is a Jmix product marketing manager and works at Haulmont, where we’re focused on developing tools and platforms that enhance developers’ productivity by automating coding routines and bringing ready-to-use application components into a single development environment — IntelliJ IDEA.
Приветствую! Форков разной степени готовности в мире гуляет достаточно много, они то появляются, то исчезают. Это сложный вопрос, на самом деле. Если говорить про РФ, то об официальном выпуске форка Camunda 7, который будет в Роспатенте и потом в Реестре МинЦифры, буквально на днях (5 февраля на MTS Link, 6 февраля на CNews) объявила компания Хоулмонт.
Описываемый Вами подход интересный, но он не лишен разбираемых в статье проблем. Разработчик по-прежнему будет ограничен возможностями дизайнера прикладных сущностей (Data models), и "биндингом", реализованным в конкретной сборке BPMS. Мы же говорим о том, что это принципиальное ограничение и снять его можно только полным и безоговорочным "раскрытием" BPMS контура, чтобы разработчик получил возможность использовать всю полноту программного стека (который постоянно совершенствуется), не теряя при этом преимуществ готового workflow, предоставляемого со стороны процессных движков.
Спасибо за Ваше мнение. Как раз проблема в том, что новые Low Code платформы в точности повторяют путь BPMS, развиваясь по модели закрытых изолированных контуров. Исход в таком случае очевиден. Мы получим все те же "траблы", просто на новом витке спирали эволюционного развития.