Всем привет!

Меня зовут Сергей Максимов и я руковожу разработкой в Центре Управления Процессами (ЦУП) Московской Биржи. В статье я хочу рассказать о нашем опыте автоматизации бизнес-процессов (БП), когда система должна быть не только удобной бизнес-пользователям снаружи, но и надежной внутри.

Бизнес Биржи, с одной стороны, похож на обычный банковский финтех, но имеет ряд важных особенностей. Чтобы лучше представить специфику нашей работы, я приведу метафору. Представьте, что каждое утро с вашего корпоративного космодрома в космос отправляется ракета. В течение дня космический корабль автономно выполняет работу на орбите, а вечером возвращается на базу. В полёте связь с кораблем очень ограничена и успех его полёта на 99% определяется качественной подготовкой. Всё должно отработать точно и в срок. Досрочный спуск корабля с орбиты технически возможен, но влечет за собой огромные репутационные потери с отчетом регулятору и новостями в федеральных СМИ.

Немного истории

Когда в 2018 году система ЦУП только проектировалась, остро встал вопрос выбора общего языка для обмена информацией. В виду наличия большой экспертизы у наших бизнес-пользователей нам была важна возможность регулярного контроля с их стороны и внесения дополнений в ходе разработки. Были рассмотрены несколько нотаций UML, ArchiMate, IFDEF, но все они страдали достаточно узкой специализацией. Свой выбор мы остановили на BPMN 2.0, тем более на рынке к тому моменту уже был ряд приложений, позволяющих работать с этой нотацией напрямую. Сначала нотацией овладели аналитики и разработчики, постепенно и пользователи подключились к работе по согласованию и модификации схем процессов. На данный момент BPMN-схемы стали неотъемлемой частью повседневной аналитической работы.

Архитектура движка BPMS

Когда с языком описания бизнес-процессов определились, перешли к поиску промышленных BPMS-систем. Подавляющая часть BPMS тяготела к монолитному развертыванию и имела свои специфические механизмы версионирования, раскатки и моделирования. Этот подход был хорошо документирован и обеспечен инструментом от вендоров, но налицо были ограничения по надежности и масштабируемости. Нам хотелось максимально использовать свою экспертизу в Java-разработке, как в части процесса, так и в части инструментов. От корпоративной архитектуры поступило требование к внедрению микросервисного подхода и на основе популярной BPMS-библиотеки Camunda 7 мы начали разработку собственного распределённого движка.

Средой функционирования BPMS-движка было выбрано частное облако Kubernetes. Частный (on-premise) вид облака продиктован требованиями по безопасности и непрерывности работы инфраструктуры. Решение на базе проекта Kubernetes с открытым исходным кодом минимизировало зависимость от конкретного вендора. База данных Postgres развернута отдельно от облака в виде гео-распределенного кластера.

В центре нашего распределенного BPMS-движка находится брокер сообщений. Изначально брокером был выбран Apache ActiveMQ Artemis, главным образом из-за наличия экспертизы в смежных подразделениях. Брокер обеспечивает маршрутизацию команд и событий между сервисами.

Для построения персональной ленты задач для каждого пользователя нами был разработан сервис «Менеджер задач». В отличие от встроенных средств управления задачами от Camunda, наш сервис умеет бесшовно соединять в единый список задачи из разных сервисов и управлять доступом пользователей на базе корпоративного AD-домена. Это достигается за счет использования шаблонов CQRS (command-query responsibility segregation) и Event Sourcing.

OLTP-схемы данных Camunda технически имеют возможность хранить исторические данных о ходе завершившихся процессов, но практически использовать эти данные для аудита очень трудно. Запросы выполняются долго и отнимают ресурс на исполнение у активных бизнес-процессов, тем самым существенно снижая их быстродействие. В результате исследования внутри команды мы пришли к гибридной модели: данные завершенных процессов хранятся в исторических таблицах 90 дней, а затем убираются служебным скриптом. За указанное время данные о всех процессах успевают скопироваться в витрину на основе Elasticsearch 7, чтобы быть доступными для быстрого поиска. Таким образом размеры оперативной базы данных бизнес-процессов остаются достаточно небольшими и удобными для обслуживания.

Практические сценарии использования

Для иллюстрации работы нашей платформы расскажу о решении некоторых практических бизнес-задач.

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

В рамках решения данной задачи мы добавили дополнительного подписчика к имеющемуся потоку событий бизнес-процессов. Отдельный сервис на базе Logstash осуществляет фильтрацию и преобразование выбранных событий для публикации их в дашборде. Такой подход позволяет максимально переиспользовать имеющиеся информационные потоки с минимальными доработками уже использующихся в промышленной среде бизнес-процессов.

Рабочая смена маклеров операционного департамента сопряжена с выполнением большого количества ежедневных регламентных операций. Контроль качества и сроков выполнения раньше осуществлялся вручную через отдельную страницу в Confluence. Когда список операций стал превышать 100 элементов, заказчиком было принято решение по созданию автоматического средства контроля. Командой ЦУП был разработан сервис «Чек‑лист», который в назначенное время запускает проверки выполнения операций. Результат всех проверок за день выводится таблицей на экран, где все записи имеют цветовую индикацию в зависимости от своего статуса. Каждая автоматическая проверка представляет из себя небольшой бизнес-процесс на нашем BPMS-движке, результатом которого будет актуальный статус операции. В результате внедрения сервиса «Чек‑лист» удалось автоматизировать более 200 ежедневных операций и добиться сокращения рабочей смены почти в 3 раза (с 16 до 6 человек).

Одним из важных направлений развития платформы является упрощение взаимодействия пользователей с ИТ-системами. Нашей командой был разработан комплекс бизнес-процессов, осуществляющих синхронные действия в нескольких торговых системах. Ранее некоторые регламентные процессы требовали голосовой синхронизации и согласованных действий внутри нескольких изолированных АРМов (автоматизированных рабочих мест). Это могло приводить к ошибкам ручного ввода и несогласованности действий по времени. Разработанная нами автоматизация позволяет в режиме одного окна выбрать все необходимые действия и указать точное время выполнения этих действий, далее система организует всё взаимодействие автоматически. Таким образом было существенно снижено влияние человеческого фактора на регламентные процессы, а время их выполнения сократилось с 40 минут до 3, то есть более чем в 10 раз.

Планы дальнейшего развития

Команда ЦУП Московской Биржи продолжает развивать платформу распределенного движка BPMS параллельно с решением актуальных бизнес-задач. На данный момент архитектура системы показала хорошие показатели по отказоустойчивости и производительности. Однако пространство для улучшений всё ещё есть:

1. Надо улучшать возможности мониторинга и трассировки проблем в ходе выполнения бизнес‑процессов. Исследуется вопрос применения стандарта Open Telemetry.

2. При заинтересованности со стороны бизнеса обеспечить интеграцию с BI и Process/Task Mining системами с целью быстрого анализа и оптимизации сложных бизнес‑процессов.

3. Исследовать вопрос преимуществ замены связующего брокера с Artemis ActiveMQ на Apache Kafka.

На этом у меня всё. Надеюсь, было интересно ?