Комментарии 6
Какие альтернативы Camunda можете предложить?
Непонятно, почему такое противопоставление BPM и лоукода.
Давайте посмотрим на магические квадраты Гартнер по BPM и найдем там хоть одну не лоукод систему. Едва ли это получится. Потому что сейчас лоукод и BPM это практически синонимы. Все известные вендоры BPM давно называют себя лоукод-платформами. Pega, Appian, OutSystems, далее везде. А сегодня, следуя моде, все стали AI-платформами.
Стоит ли обращать такое внимание на маркетинговые ярлыки?
Да, это известный факт, что есть два уровня BPMN-моделей, аналитические и исполняемые. Естественно, аналитическую модель нельзя запихнуть в движок.
Но бизнес-логику все равно надо как-то делать. Это справедливо для всех платформ.
Смысл использования графической нотации, BPMN или другой в том, чтобы сделать процесс видимым. Observability это очень полезно.
Моделирование в BPMN это избыточный этап. Да и ТЗ писать только время тратить.
То есть, вы предлагаете отказаться от моделей процессов вообще и реализовывать их сразу в коде, да? Для простых процессов в 3-5 шагов пожалуй да. Ну пропуск заказать. отпуск согласовать.
Но когда этих шагов несколько сотен (а такое бывает), то пожалуй трудновато будет держать в голове всю логику, если это просто в коде.
Для внесения корректировок в BPM-системе необходимо не только обновить BPMN-схему, но и настроить саму систему, включая программирование логики процессов и интеграции.
Существует миф, что «нарисовал картинку – схему процесса в BPMN и получил готовое приложение». Совсем нет, потому что, BPMN – это не про бизнес-процессы, а только про их пусть и важную, но только часть - про workflow (WF). Поэтому их и называть нужно не BPMS, а WFE (WF-engine) \ WFES (WF execution system).
Впрочем, некоторые так и называют свои системы, например, Runa WFE.
Чтобы исполняемый BPMN стал про бизнес-процессы, в него нужно добавить, как минимум docflow (dataflow modeling).
Когда появится нотация, которая позволит без программиста создавать по схеме процесса приложение, то ее и следует будет назвать «настоящей BPMN». Простейшие случаи, типа Hello Calculator не рассматриваем.
Пока, что исполняемая нотация BPMN недостаточно для того чтобы формализовать в код бизнес-процесс, она может только workflow, а все останове необходимое, прежде всего модель данных и docflow (номенклатура документов, их свойства, включая набор состояний документов и т.п.), программисты дописывают вручную или используются встроенные конструкторы, которые к BPMN отношения не имеют.
BPM-системы — это не про автоматизацию
Точный тезис. BPM-системы - они только про моделирование, но про полноценное, включая docflow и др. Изначально (начало 2000-х) BPM-системами (BPMS) назывались системы в которых вообще не было исполняемых движков Execution Environment: ARIS, BPWin и т.п. Это были системы моделирования бизнес-процессов (не только workflow) и произошел их ребрендинг из CASE систем в «BPM-системы». Только потом Гартнер «отжал» у них (ARIS и т.п.) бренд «BPMS» в пользу исполняемых систем, тем самым всех запутав. Изначально «управление» (management) в контексте BPMS \ BPMT (tool) не было синонимом «исполнение» (наличие WFE).
BPM-системы постепенно переходят к low-code платформам.
low-code – это инструменты, которые позволяют минимизировать программный код визуальными средствами. Это либо визуальные конструкторы, либо редакторы диаграммам, где посредством графического пользовательского интерфейса (GUI) создаются блоки, которые потом генерируются в код.
jQuery и подобные библиотеки, также сокращающие код – это не low-code, а любая BPMN WFE – это всегда low-code, т.к. уже замена части кода картинкой говорит о «low».
В простых случаях, как Hello Calculator речь идет о no-code.
Dataexpress и VBA – в части создания пользовательского интерфейса – это тоже low code.
LCNC (low-code & no-code) можно поделить на три группы: BPMN-LCNC, noBPMN-LCNC и конструкторы не на процессных диаграммах:
LCNC - это «сборная солянка» любых систем «быстрой разработки», где применяется хоть какой-то визуальный конструктор, причем не обязательно графический (графический моделер). Во многих случаях этот конструктор и есть BPMN (low-code BPMN), т.е. можно разделить на две основные группы: BPMN-LCNC (Camunda etc) и noBPMN-LCNC (Pega etc).
Сегодня почти каждая система имеет какой-либо конструктор - если не для разработки, то хотя бы для конфигурирования, например, СЭД Директум 5 - для конфигурирования маршрутов задач. Обычно подобное также относят к LCNC.
Есть еще странное деление «на две большие группы: процессные движки (BPMN) и полноценные системы (BPMS)». Странность в использовании термина BPMS: получается, что бренд BPMS в очередной раз хотят "отжать", но уже у систем Camunda \ jBPM в пользу других.
Визуальное программирование - как реализация концепта «программирования без программирования» - в идеальном случае, это no-code.
Совсем простые (детские) примеры: Scratch и Lego Mindstorms EV3. Scratch – язык программирования - представляет собой визуальную среду, в которой ПО пишется с помощью блоков, см. wiki.
Долгое время BPM-системы строились вокруг идеи, что процесс сначала моделируется, затем передается разработчикам и только потом внедряется. На практике оказалось, что этот путь слишком длинный и неэффективный. Бизнесу нужны инструменты, позволяющие сразу тестировать и запускать процессы в работу.
Категорически не могу согласиться с автором. Тут перевернуто "с ног на голову". С точки зрения бизнеса BPM - это концепция управления, которая увязывает стратегию и цели организации с ожиданиями и потребностями клиентов через построение сквозных бизнес-процессов. То есть на верхнем уровне моделируется не передача документа от одного подразделения к другому, а путь формирования ценности для конечного клиента. И уже потом, на следующих уровнях уточняется как именно каждое из подразделений вносит свой вклад.
А еще потом, совсем-совсем потом, на самом низком уровне отбираются элементы маршрутов, на предмет их автоматизации. И при автоматизации исполнения процессов как раз появляются технические этапы прототипирования и отладки. Инструментов для этого огромное количество, в том числе инструментов на базе спецификаций BPMN и DMN, выполненных в low-code или по no-code формате. Но это совершенно никак не отменяет опоры на промышленную спецификацию.
Почему BPM-системы — это не про автоматизацию: мифы и реальность процессного управления