Извините, но причем тут 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, развиваясь по модели закрытых изолированных контуров. Исход в таком случае очевиден. Мы получим все те же "траблы", просто на новом витке спирали эволюционного развития.
Извините, но причем тут 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, развиваясь по модели закрытых изолированных контуров. Исход в таком случае очевиден. Мы получим все те же "траблы", просто на новом витке спирали эволюционного развития.