Внутренняя автоматизация – почему мы отказались от low-code системы в пользу Camunda
Привет! Меня зовут Мирослав, я инженер-разработчик проекта по реализации 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
Это приложение, которое устанавливается на компьютер аналитика или разработчика. Здесь можно редактировать 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 среде. И естественно с этими перспективами мы столкнулись лицом к лицу. Но это уже совсем другая история : D.
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
Пласт коннекторов, позволяющий 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.
Буду рад узнать про ваш опыт использования BPMS, особенно, если вы используете подход, отличный от нашего. Приходите в комментарии, будет интересно пообщаться.
