Внутренняя автоматизация – почему мы отказались от low-code системы в пользу Camunda

[Kate]

Привет! Меня зовут Мирослав, я инженер-разработчик проекта по реализации BPM-решений для внутренней автоматизации КРОК.

Наш проект не гоняет миллионы строк каждую ночь через фильтры и правила, это не сложная система, которая отвечает за кадровую информацию, бюджетирование или сведение план-факта. Наш проект автоматизирует КРОК на самом понятном пользователю языке – их у нас сейчас более 2 000 сотрудников. Если есть рутинная задача, которую можно представить в BPMN, мы ее реализуем.

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

Теперь пользователь просто прописывает путь к папке, выбирает тип доступа (чтение/редактирование), оставляет при желании какой-нибудь увлекательный комментарий – и все, дальше все делает BPMN.

Таких антирутинных процессов у нас сейчас 27. Самые популярные – заказ командировок, пропуска для гостя, обучения и авансового отчета. В этом посте я расскажу историю о том, как мы решили обновить свою BPM-систему и что из этого вышло – поделюсь опытом, не обойду ошибки, и расскажу, как в итоге выстроили систему, которая полностью устраивает нас и наших заказчиков.

Каким мы хотели видеть BPMS​

Потребность в новой BPM-системе стала очевидной еще в 2018 году. Текущая K2 4.7 не шла в ногу со временем, а K2 5.0 не устроила нашу команду. В конце 2018 года менеджер нашего проекта в компании пары аналитиков начали изучать рынок BPM-решений в поисках альтернативы.

Тогда как раз набирала обороты глобальная трансформация КРОК (что это значит, в одном абзаце не объяснить, поэтому просто оставлю это здесь как факт). Бизнес повсеместно стремился к изменениям, и это, конечно же, влияло на нас. То, как было по-старому, работать перестало – нужны были гибкая разработка, регулярные демо, работа бок о бок с заказчиком на понятном ему языке.

Нашей идеальной системе предстояло усилить взаимодействие команды с заказчиками и ускорить процесс разработки. Для этого отлично подходили iBPMS, в которых, при нашем сценарии использования, ведущая роль разработки отводилась аналитику и автогенерируемому интерфейсу. Именно аналитик должен был проектировать BPM-схему, собирать модель данных и создавать страницы в UI-дизайнере. Разработчики, в свою очередь, должны были насытить BPM-схему логикой при помощи скриптов, а также развернуть окружение и наладить workflow внедрения новых бизнес-процессов.

Спустя пару месяцев наш выбор пал на Bonita, а в феврале 2019 года мне поручили ее внедрение на нашем проекте.

Опыт использования Bonita​

На изучение и внедрение новой системы, а также разработку бизнес-процесса под неё ушло около пяти месяцев. Это был очень интересный опыт адаптации цельного и мощного инструмента к нашим потребностям. В течение этого времени наша команда несколько раз меняла восприятие продукта и парадигму работы с ним.

Архитектура Bonita BPM
Как вы уже поняли из заголовка – Bonita нас все-таки не устроила. Далее я подробно опишу архитектуру решения, чтобы наглядно показать, почему в итоге наша команда от него отказалась.

Bonita Studio​

[IMG alt="Это приложение, которое устанавливается на компьютер аналитика или разработчика. Здесь можно редактировать BPMN-схемы, создавать модели данных, писать скрипты на Groovy, загружать справочники пользователей, рисовать формы – в общем, полный стартерпак для создания бизнес-процессов.
"]https://habrastorage.org/getpro/hab...a4766d0e127fee5f83e47d18cf78087d.PNG[/IMG]Это приложение, которое устанавливается на компьютер аналитика или разработчика. Здесь можно редактировать BPMN-схемы, создавать модели данных, писать скрипты на Groovy, загружать справочники пользователей, рисовать формы – в общем, полный стартерпак для создания бизнес-процессов.
С чем столкнулись

• Моделлер рисования схем сам по себе показался не очень удобным, так как достаточно криво отрисовывал XML. Редактирование схем и приведение их к единому стилю иногда доставляло боль.

Вот так выглядит BPMN-схема для процесса "Выдача прав доступа" в Bonita

• Ограничение лицензии не позволяло нам открыть два окна Bonita Studio, а значит, два проекта одновременно, чтобы скопировать схемы или скрипты.
• Отдельным разочарованием стал UI Designer – конструктор форм, на который мы изначально делали большую ставку. Мы надеялись, что это поможет сократить срок разработки UI и делегировать этот процесс аналитику.
  На деле UI-дизайнер оказался слишком негибким для того, чтобы отрисовывать на нем сложные формы. Аналитик мог "набросать" примерную схему страницы, но дальше на ее оживление разработчик тратил слишком много времени. И чем сложнее была страница, тем больше времени требовалось. А все дело было в том, что под капотом конструктора были примитивные и не расширяемые инструменты, а формируемые им страницы реализовывались на AngularJS.
  Дальше мы старались писать фронтенд по старинке, при помощи Angular 2+, и налаживать взаимодействие с Bonita через REST API.

Bonita Portal​

Это пространство, в котором пользователи управляют задачами, а администраторы – процессом. Разворачивается вместе с сервером, и хорошо работает из коробки.
С чем столкнулись

• Такое пространство – удобное решение, если нет необходимости его дорабатывать. У Bonita есть возможность кастомизировать портал при помощи архивов стилей, накатываемых прямо в Web. Мы легко перекрасили оформление и даже поменяли язык всего портала на русский. Но когда дело дошло до каких-то детальных изменений, не предусмотренных BonitaSoft, мы столкнулись с проблемой – для подобных доработок Bonita Portal не был приспособлен.
• В Bonita Portal можно редактировать скрипты и параметры бизнес-процессов в runtime. Это достаточно мощное решение, с которым можно здесь и сейчас устранить проблемы пользователей, но в перспективе эта опция создает огромные проблемы и хаос в Production среде. И естественно с этими перспективами мы столкнулись лицом к лицу. Но это уже совсем другая история .

Bonita Runtime​

К этой части вопросов почти не было. Движок требует настройки, документация не идеальна, но сам по себе он работает хорошо и REST API у него описан достаточно подробно.

Version Control​

Это опция Bonita Studio, которая обеспечивает взаимодействие с Git-репозиториями. Не очень красивая, и на самом деле, совершенно необязательная, так как можно воспользоваться каким угодно иным инструментом для работы с Git. Но работает исправно

Bonita Storage​

Еще один инструмент Bonita, который реализует low-code. Предполагается, что аналитик создает модель данных в Bonita Studio, подключает её к схеме и UI, что позволяет ему проделать значительный пласт работы без участия разработчика.
С чем столкнулись

• На деле обязанность по построению модели данных легла на плечи разработчиков, так как именно они писали скрипты для наполнения бизнес-процесса логикой и именно они знали, какие сущности им в этом будут необходимы. Здесь снова не совпали наши "ожидание - реальность", и мы еще сильнее отдалились от "идеальной" системы, в которой большую часть приложения создавали аналитики, оставаясь в тесной связке с бизнесом.
• После создания модель данных содержалась в xml-файле, который необходимо было заархивировать и развернуть в Bonita Portal.

XML-схема, которую генерит Bonita на основе business data model. Далее в соответствии с этой схемой будут созданы таблицы в БД
И вот здесь нам снова аукнулись нюансы – открывать одновременно два проекта нельзя. В итоге, xml затирала модели данных других бизнес-процессов. Решение оказалось костыльным - мы хранили в репозитории "главный" xml-файл модели данных, который вручную изменяли при появлении новых сущностей.

• После деплоя архива с xml-схемой в BonitaPortal на ее основе создавались таблицы в заранее указанной базе данных. Выглядели они не совсем так, как нам хотелось. При этом в самой Bonita были ограничения по именованию объектов BDM. Все таблицы лежали в одной БД, хранить их иначе было невозможно. Для того, чтобы исключить пересечения именований, мы добавили префиксы, но в названиях таблиц (сущностей в модели данных) нельзя было использовать точки или нижние подчеркивания. В результате это были просто буквы, с которых начинались все названия сущностей.
  Еще были сложности с изменением модели данных. Добавление нового столбца или изменение Nullable могло обернуться вынужденным сносом всех данных из таблицы – этого в проде мы допустить не могли.

Information systems​

[IMG alt="Пласт коннекторов, позволяющий Bonita взаимодействовать с внешними системами.
Этот механизм облегчает жизнь разработчику – можно подключиться к БД, SOAP, REST, отправлять письма. "]https://habrastorage.org/getpro/hab...face6acd31b942d7f6934d2ce87c00.PNG[/IMG]Пласт коннекторов, позволяющий Bonita взаимодействовать с внешними системами. Этот механизм облегчает жизнь разработчику – можно подключиться к БД, SOAP, REST, отправлять письма.
С чем столкнулись

• Основная проблема этого механизма - в его предопределенности. Здесь ситуация очень сильно похожа на Bonita Portal. В рамках задач, обозначенных BonitaSoft, коннекторы справлялись хорошо, но расширить их настройки или спектр применения было попросту невозможно. Да, мы могли создать самописные коннекторы, но тогда какой же это low-code? В итоге некоторые взаимодействия с внешними системами происходили через проставку из самописного сервиса.

Выводы​

Bonita отлично подошла нам для создания простых бизнес-процессов: в некоторых случаях нам пригодился UI-дизайнер и даже генерация несложной модели данных. Но при создании нетривиальных, многомерных BPM-приложений такой подход начинал пробуксовывать, порождать костыли, а само приложение становилось неподъемным в плане поддержки и развития.

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

Более того, через несколько месяцев (в декабре) у нас заканчивалась лицензия BonitaSoft, что ставило нас в ситуацию с выбором – либо мы уходим на новый круг работы с системой, которая не оправдала наших ожиданий, либо отказываемся от нее здесь и сейчас и бросаем все силы на перевод существующих процессов. Конечно, мы решили рискнуть.

Поиск новой BPMS​

В этот раз в выборе BPM системы участвовала большая часть проектной команды – все те, кто был причастен к разработке процессов на Bonita. Пропустив через этот опыт решения из прошлого исследования, выбрали четырех финалистов – Bizagi, ELMA, Bpm’Online и Camunda.

Bizagi не устроила нас по цене, ELMA показалась слишком похожей на Bonita. Bpm’Online мы смогли изучить подробнее, благодаря опыту наших коллег – она уже используется в КРОК в качестве внутренней CRM-системы. В нашем случае она казалась не самым удачным вариантом – могли быть трудности с поддержкой нетривиальных схем. У Camunda не было богатого набора инструментов iBPMS как у Bonita (но именно к ним у нас и было больше всего вопросов). Но зато у нее была Community-версия – что стало дополнительным аргументом "за". Нам хотелось быстро и безболезненно протестировать решение, и быстро отмести его, если вдруг что-то опять пойдет не так. В общем-то, по этой причине мы выбрали ее качестве объекта для исследования и внедрения в тестовой среде.

Новая BPMS​

Camunda - BPM Engine​

Рассказывать о том, что такое Camunda можно долго, но на самом деле об этом уже написано достаточно статей. Вот, например, отличный материал от Tinkoff, позволяющий быстро и легко погрузиться в особенности этого BPM движка.

Добавлю лишь немного лайфхаков.

• Ссылка на git-репозиторий с огромным количеством тестовых проектов Camunda на любой вкус, которые помогут быстрому старту и поиску решений проблем, возникших при самостоятельном знакомстве.
• Ссылка на telegram-канал русскоязычного сообщества Camunda, куда можно обратиться за помощью, когда документация и Google не смогли подсказать решение. Эти ребята ни раз меня выручали в период знакомства с движком, за что им огромное спасибо

Наша основная проблема​

Начав исследовать Camunda я столкнулся с очевидной проблемой. Camunda написана на Java, разворачивается в среде Java и расширяется при помощи Java-подобных языков. А вся наша команда пишет на .NET (надеюсь, у вас тоже проигралась заставка из Ералаша).

Вероятных решений было два:

• Научиться писать на Java или Kotlin, но не растерять при этом навыков .NET, так как на поддержке у команды остается еще более двадцати бизнес-процессов
• Интегрировать Camunda в нашу экосистему таким образом, чтобы рассинхрон стека как можно слабее повлиял на получаемый результат

Мы решили попробовать пойти по второму сценарию – и вот что из этого получилось.

Новая концепция взаимодействия с BPM​

Вместо того, чтобы помещать BPM движок в центр нашего бизнес-процесса, мы используем его как вспомогательный фреймворк. Руководящая роль в этом случае отводится .NET-приложению – дальше я рассмотрю каждый элемент схемы подробнее.

Spring Boot​

Java-часть нашей BPMS выглядит так:

Здесь мы используем Spring Boot, в который как зависимость импортируем Camunda.

У Camunda есть свой REST API и, конечно, BPMN-составляющая, а также своя БД, используемая для хранения процессных данных. BPM-движок через схему обращается к коду, написанному на Kotlin, который, в свою очередь, обращается к нашему .NET приложению для получения бизнес-данных.

.NET​

Основная часть бизнес-процесса представляет из себя .NET приложение:

Бизнес-данные хранятся в БД, с помощью EF Core мы потребляем их в слой сервисов, где рассчитываем бизнес-логику и откуда обращаемся к Camunda REST API. Также у приложения есть формы на Angular для взаимодействия с пользователями и REST API для доступа к бизнес данным из Camunda и внешних систем.

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

Как теперь все устроено​

За 8 месяцев мы исследовали и внедрили движок Camunda, а также мигрировали на него все бизнес-процессы, тем самым полностью отказавшись от Bonita BPM. Теперь у нас есть 3 отдельных Spring Boot приложения Camunda, под каждый бизнес-контур (Sales, HR и Production), самописный CROC BPM Portal, агрегирующий информацию о состоянии экземпляров процессов, и 4 бизнес-процесса, работающих в production-среде – вот таких:

---

– Выдача прав доступа

С него начался этот пост. Это инструмент, позволяющий автоматизировано получать права и доступ на файлы и папки КРОК.

– Обходной лист

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

– Согласование тендера

Мы упростили коммуникацию по согласованию участия в тендере и исключили из этого процесса электронную почту или мессенджеры. Теперь наши менеджеры используют автоматизированное приложение с продуманным WorkFlow.

– Пульс проекта

С помощью этого процесса мы раз в полтора месяца собираем обратную связь по работе проектной команды, аккумулируем статистику и переводим её в плоские отчёты. Это позволяет отслеживать динамику настроения проектной команды и обращать внимание менеджера на болевые точки и узкие места.

---

Считаю, что будет справедливо показать, как изменился процесс автоматизации с переходом от Bonita к Camunda – ниже опишу несколько ключевых моментов.

Bonita Portal => CROC BPM Portal​

Интерфейс, который отвечает за отображение скоупа задач и экземпляров процессов – CROC BPM Portal – теперь тоже самописный. Благодаря этому мы можем оперативно отвечать на требования пользователей и гибко его развивать.

Task-модуль CROC BPM Portal на тесте

Bonita Runtime => Spring Boot и Camunda​

Также, вместо standalone-подхода мы используем импорт библиотеки Camunda в Java-приложение. И таких приложений у нас несколько, в целях увеличения отказоустойчивости, каждое под свой бизнес-контур.

Bonita Storage => EF Core​

Еще мы полностью контролируем бизнес-данные, для обновления БД используем миграции, а таблицы хранятся в удобном для нас виде:

Information systems => Самописные сервисы​

Вместо преднастроенных контроллеров взаимодействия с внешними системами мы используем самописные синхронизации и сервисы. Конечно, это не так удобно, как добавить модуль на BPM-схему, но взамен мы получаем гибкость и стабильность работы.

Почему BPM – это круто?​

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

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

Аналитик согласовывает с заказчиком схему бизнес-процесса, передает её разработчику, и тот дальше вносит в нее технические изменения. Схема при этом всегда остаётся "живой" и может меняться в одном ритме с кодом. Такое поведение системы делает работу проектной команды целостнее и слаженнее, а связи с заказчиками – прочнее. Это именно то, чего мы добивались, начиная описанную мной историю.

Что дальше?​

Наша BPM продолжает развиваться, и многое еще предстоит усовершенствовать. В ближайших планах написать собственную админку с возможностью просмотра истории экземпляров процесса, а также сервис, уведомляющий проектную команду об инцидентах Camunda.

Источник статьи: https://habr.com/ru/company/croc/blog/563182/