Разница между BPM движками и BPMS системами

Люди часто путают BPM движки и BPMS системы, из-за чего делают неправильные выводы и выбирают неподходящие инструменты. Чтобы сэкономить своё время на подборе системы для автоматизации BPMN-диаграмм прочитайте эту статью. Она большая, приготовьтесь.

Что общего между BPM движками и BPMS системами и почему их путают

Все хотят быстрее делать проекты, автоматизировать бизнес-процессы и тратить на это меньше денег. Маркетологи тратят кучу денег на то, чтобы результат применения движка или системы BPMS звучал так: “Закидываем бизнес-процесс в BPMN в окошко, потом эта схема сама начинает выполнятся”.

Чтобы понять что на самом деле является идеальным конечным результатом вспомним определение бизнес-процесса:

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

В контексте “управления бизнес-процессами” процессы — это сквозные набор работ, из серии “от-заявки-до-оплаты”, пересекающие всю организацию, чтобы доставить ценность потребителю.

Мне нравится такое определение, оно смещает внимание в ту область, где автоматизация процессов работает лучше всего.

Не процесс	Процесс
Выгрузка ежеквартального отчета Формирование КС-3 Интеграция со СМЭВ Выкладка товара на полке Отправка сообщения в очередь	Обработка заказа в интернет-магазине Согласование и оформление командировки Обработка заявки на банковскую гарантию

Теперь давайте посмотрим на определение с точки зрения софта:

1. “Набор” — значит нужно средство для формирования наборов действий. BPMN как раз подойдет.
2. “Действий людей” — значит нужен пользовательский интерфейс, где сотрудники могут жать кнопки.
3. “Или машин” — значит нужны API и возможность объяснить машине, что мы от нее хотим. Например написать на языке высокого уровня, типа C# или Java.
4. “Целей” — нужно как-то понимать что цель процесса достигнута или знать почему она не может быть достигнута. Обычно это выражается с помощью сущностей и их статусов, например “Заявка на кредит” и статус “Отклонена скорингом”. Поэтому нужны средства для моделирования и хранения сущностей.
5. “Определенных событий” — нужны API непосредственно к процессам, чтобы можно было ими пользоваться с внешнего мира.
6. “Всю организацию” — нужно понимать, кто и какие задачи по процессу сейчас делает — т.е. возможность смоделировать оргструктуру или распределить сотрудников по группам.

Кроме того, есть чисто эксплуатационные требования к решению:

1. Мониторинг и анализ работоспособности.
2. Резервное копирование и восстановление.
3. Средства обеспечения безопасности, шифрования и аудита.
4. Масштабирование и отказоустойчивость.
5. Инструменты для совместной работы и развития решения.
6. Распространенность на рынке и скорость подготовки специалистов

Что обычно автоматизируют в BPMS 

Если автоматизировать налоговый учёт, то BPM(S) всегда проиграет системам типа 1С или SAP. Сфера бизнес-процессов, которые вы хотите автоматизировать, также влияет на требования к системе. Gartner предлагают 3 вида систем:

• Systems of Record — в основном учетные системы , у всех бизнесов +- одинаковые взгляды и задачи. 1с, WMS системы, CMS системы и так далее.
• Systems of Differentiation — это места, где реализуются уникальные преимущества бизнеса и бизнес-процессов. Могут быть BPMS, PLM или кастомная разработка. Именно этот вид систем и задач подходит под BPMS.
• Systems of Innovation — это системы для быстрого запила прототипов, Low Code а-ля Outsystems. В основном там проверяют гипотезы, а потом всё переделывают в системах ниже.

Критерии сравнения BPM движков и BPMS систем

В итоге, чтобы понять разницу между движками и BPMS-системами, пробежимся по таким требованиям:

1. Формирование процессов.
2. Пользовательские интерфейсы и авторизация.
3. Написание высокоуровневого кода на языках общего назначения.
4. Средства для моделирования и хранения сущностей.
5. Наличие API к решению.
6. Моделирование оргструктуры и правил выбора сотрудников для задач.
7. Обеспечение мониторинга и анализа работоспособности.
8. Обеспечение безопасности, шифрования, аудита.
9. Варианты масштабирования и обеспечения отказоустойчивости.
10. Инструменты разработки и совместной работы.

Движков много, BPMS систем еще больше, говорить за всех я не могу. Поэтому буду рассказывать на примере движка Camunda и ELMA BPMS. Знаете о других? Пишите скорее в комментариях

1. Формирование процессов

Под этим требованием я понимаю возможность создать\читать\менять\удалить диаграммы в самой лучшей нотации для описания бизнес-процессов — в BPMN2.
Это одна из фишек что движков, что BPMS, которую все стараются делать на максимальном уровне.

Движки	BPMS
Camunda Modeler	ELMA BPMS

Как правило, всегда есть какая-то среда для рисования диаграмм. В случае с Camunda — это Camunda Modeler, приложение, которое на выход выдает корректный XML. В случае с ELMA — это приложение ELMA Дизайнер, они используется целиком для разработки процессов в ELMA, не только диаграмм

Уровень поддержки BPMN везде разный, нужно смотреть конкретную систему. Если она поддерживает встроенные подпроцессы обработчики по сигналам непрерывающие, то скорее всего с BPMN всё хорошо 🙂 (Это экзотические символы, реализация работы которых говорит о том, что авторы серьезно относятся к стандарту)

Как выбирать: Если у вас уже много аналитиков и диаграмм в BPMN — выбирайте такое решение, которое поддерживает BPMN по-людски.

2. Пользовательские интерфейсы и авторизация

Под этим требованием я понимаю возможность управлять пользовательскими интерфейсами. Управлять — значит создавать, редактировать, просматривать, удалять.

Современные пользовательские интерфейсы — это отдельные браузерные приложения с использованием JS, HTML, CSS. Они могут исполняться прямо в браузере как SPA (фреймфорки а-ля Vue.js, React) или генерироваться на сервере и отправляться в браузер.

 

Как выбирать: Формы будут видеть внутренние сотрудники и нужно 5 полей вывести? Смотрите в BPMS. Делаете что-то очень красивое, где UI имеет важное значение для процессов? Делайте формы отдельно и прикручивайте их к движку.

3. Высокоуровневый код

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

 

Как выбирать:  У вас 15 любых библиотек для Java и четкое понимание структуры кода в вашем приложении? Ну тогда конечно движок. Вы только начинаете и вообще с кодом у вас так себе — смотрите в BPMS.

4.Моделирование и хранение данных

Под этим требованием я понимаю возможность описать предметную область и обеспечить хранение этих данных. Например сущность “Банковская гарантия” и её атрибуты “Заказчик” и “Поставщик”.

 

Как выбирать: Четко понимаете, что вам нужна графовая база данных и работа процессов с ней будет интенсивная? Тогда вам нужен движок. Понятия не имеете о том, чем класс отличается от атрибута? Тогда BPMS.

5. Наличие API

Под этим требованием я понимаю возможность интегрировать решение в текущую инфраструктуру. Что у движков, что у BPMS-систем с этим всё хорошо, т.к. это вообще одна из ключевых фич систем такого рода. Производители BPMS-систем в интеграции обычно заходят дальше и предоставляю автогенерируемые API для созданных моделей данных, что немного ускоряет разработку. Такого же эффекта можно добиться и с движком, например для Camunda можно использовать spring-data-rest.

Как выбирать: сердцем.

6. Моделирование оргструктуры и правил выбора сотрудников для задач

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

 

7. Обеспечение мониторинга и анализа работоспособности

Под этим требованием я понимаю возможность понимать, что происходит с приложением и что происходит с конкретными процессами. 

Эти требования одинаково хорошо проработаны что в движках, что в BPMS. Единственное, что в движках у вас больше возможности кастомизации. Например, прикрутить Prometheus к приложению с Camunda займет у вас 10 минут, а в ELMA надо этим придется поработать.

8. Обеспечение безопасности, шифрования, аудита

Под таким требованием я понимаю возможность проследить кто и какие кнопки жал в системе, как менялось её состояние, возможность зашифровать часть данных в базе и так далее.

Под таким требованием я понимаю возможность настройки системы так, чтобы выход одного из серверов не приводил к отказу в обслуживании. Также нужно уметь добавить ресурсов на сервер\ добавить новый сервер и сделать это быстро и хорошо.

Как выбирать: Будет больше 3-5 млн. инстансов процессов в день, хотите автоскейлинг через кубернетес? Скорее всего вам стоит использовать движок. Если меньше, то можно и BPMS посмотреть.

9. Инструменты для совместной работы и развития решения

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

10. Поиск разработчиков и аналитиков в BPMS

Под этим требованием я понимаю способность быстро добавить людей в проект и время, которое им потребуется, чтобы начать приносить пользу.

11. Зависимость от вендора\разработчика

В итоге BPMS vs Движки

Движки

Подойдут тем, у кого много готовых диаграмм в BPMN, кто планирует делать сложный интерактивный UI с привлечением дизайнеров; имеет идеи по использованию готовых библиотек из мира программирования; возможно планирует использовать noSQL базу данных; знает какие требования по безопасности и шифрованию предъявлены и понимает как их удовлетворить; собирается использовать kubernetes, потому что ожидается большое количество траффика; в штате есть профессиональные программисты, которые готовы заняться проектом.

BPMS

Подойдут тем, кто начинает новый проект, кто не предъявляет существенных требований к UI; кто не планирует множество интеграции и у кого нет любимых библиотек на Java; Кому всё равно, как хранятся данные в базе данных; у кого нет жестких требований по безопасности и достаточно чтобы “она была”; У кого будет небольшой траффик (тысячи процессов в день); Кто планирует разрабатывать и внедрять систему в основном без привлечения разработчиков, силами аналитиков.

---

Расскажите в комментариях о ваших соображениях по теме и о других BPMS системах. Вам слово.