Шестерни современного банка вращаются в соответствии с финансовыми бизнес-процессами.
Они сложнее обычных – это правило работает для всего, к чему вы добавляете термин «финансовые».
С одной стороны, все осложняется регуляторами, бесчисленными согласованиями и вовлеченными сторонами.
С другой стороны, есть корявые монолитные BPMS (системы управления бизнес-процессами).
В этом посте мы расскажем, как мы успешно отказались от одной такой системы и перешли на гибкий и функциональный open source. 
Программисты отображают бизнес-процессы, используя разные обозначения.
Сейчас стандартом является BPMN (Модель и нотация бизнес-процессов) — это XML-файлы с прикрепленными к ним изображениями.
Для работы с этой нотацией создаются продукты BPMS — монолитные проприетарные системы, которые стараются вместить в себя максимум инструментов для BPM-разработки: от редактора пользовательского интерфейса до системы контроля версий.
Расширять их могут только разработчики, давно работающие с этими системами.
Корпоративные BPMS предоставляют REST API, то есть к системам можно получить доступ и получить данные в ответ. Но модификация и глубокая настройка самой BPMS практически невозможна.
Работать с такой BPMS можно только через ограниченный производителем набор инструментов — собственная система контроля версий, компилятор, деплоер — обычно для каждой крупной BPMS разрабатывается целый набор.
Эти инструменты развиваются медленно, и от релиза к релизу могут сохраняться одни и те же проблемы, поскольку в работе задействовано не так много людей, как в случае с открытым исходным кодом.
В целом возможности корпоративных BMPS и потребности их пользователей совпадают очень редко.
В рекламе таких систем говорят о сквозном документообороте, говорят, что бизнес сам может менять BPM-процессы на лету.
Но на самом деле с этим не могут справиться даже аналитики — справятся только разработчики.
Бизнес-процесс состоит из пользовательских и сервисных задач, последовательность выполнения которых приводит к конечной остановке.
В BPMS посредством таких схем можно отслеживать время выполнения бизнес-процессов, а также различные бизнес-показатели — например, KPI. Нам часто приходится вносить в бизнес-процессы изменения разного масштаба.
Раньше у нас был процесс BPM для менеджеров по работе с клиентами, которые сидят в дополнительных офисах.
В 2015 году мы закрыли часть офисов и перевели менеджеров на выездную работу.
Это потребовало серьезных изменений в процессах BPM; необходимо было ввести другие роли и действия.
Или, например, изменился регламент Службы экономической безопасности, и вместо двух координаторов теперь трое.
Первоначально мы внесли изменения через BPMS IBM Lombardi. Собрав типичные недостатки систем своего класса, он отличался еще и отсутствием организованной документации.
Казалось, что после покупки Lombardi Software софтверный гигант посмотрел на аморфное облако сопутствующих статей и решил ничего не трогать.
И даже прочитав всю документацию, многие вещи сделать не удалось.
Например, вызовите запрос REST с аутентификацией HTTPS, используя сертификат пользователя.
К счастью, поиск альтернативы увенчался успехом.
Камунда решает проблемы
Поработав с IBM BPM, мы пришли к выводу, что разные группы пользователей должны иметь возможность изменять бизнес-процессы.Обычные сотрудники бизнес-подразделений могут внести небольшой вклад в Интернете.
Системные аналитики меняют последовательность задач в бизнес-процессах.
Новые интеграции, изменения пользовательского интерфейса и программного кода остаются на стороне разработчиков.
И чтобы поддерживать эту гибкость, вся BPMS должна быть развернута на микросервисах.
Мы можем реализовать этот подход, используя BPMS Camunda с открытым исходным кодом.
Это ответвление проекта Activity, который команда разработчиков решила сделать более востребованным.
Они привели документацию в порядок и начали разрабатывать Камунду отдельно, зарабатывая на продаже поддержки.
BPMS Camunda позволяет редактировать бизнес-процессы с помощью обычной Java и поддерживает разделение на микросервисы.
Переход BPMS на микросервисы дает ряд преимуществ:
- Избавление от монолита.
Мы можем разделить бизнес-процессы на сегменты, соединив их вместе с помощью Rabbit MQ или Kafka через очереди.
Бизнес-процессы можно изменять изолированно друг от друга, изменения можно развертывать, не дожидаясь полноценного релиза.
- Избавление от сервера бизнес-процессов.
- Масштабирование.
Если один из серверов начнет глючить под нагрузкой, то его можно клонировать.
Во время пиковых нагрузок вы можете легко повысить производительность, запустив несколько экземпляров бизнес-процессов в разных сервисах.
- Версионирование.
Если, например, вам нужно обновить версию Java, вы можете поднять несколько микросервисов с разными версиями Java и параллельно запускать новую версию.
Каждый микросервис может иметь не только разные версии ПО, но и разные языки.
Здесь все гораздо сложнее, чем для частных лиц и даже чем для малого/среднего бизнеса.
Используется не продуктовая, а лимитная схема кредитования, лимиты ограничены во времени, заемщики обычно являются частью более крупных организаций типа холдингов, а холдинги являются частью чего-то другого.
Лимиты определяются отдельно для каждой из этих структур, причем каждая структура имеет свои координирующие органы, состав которых постоянно меняется.
Получаем бизнес-процесс из сотен этапов.
Мы смогли изменить это с помощью Камунды и решили остаться с этим.
Даже если разработчики решат закрыть проект сейчас, текущих возможностей системы хватит еще на три года.
Наша первая версия Camunda была на Websphere и по сути мало чем отличалась от IBM Lombardi. Мы решили написать приложения, к которым сервис обращался в Spring Boot. Они развернулись на Tomcat и не работали самостоятельно.
Потом выяснилось, что Camunda может работать на Tomcat, и была разработана версия для Spring Boot. Там уже стала доступна полноценная микросервисная архитектура.
Все приложения, с которыми работал бизнес-процесс, были реализованы на микросервисной архитектуре на базе Spring Cloud. Потом оказалось, что быстро менять функционал можно не только в сервисах, обслуживающих бизнес-процесс.
Сам механизм BPM можно подключить к любому приложению Springboot в качестве библиотеки.
Камунда как микросервис
Возник вопрос: сколько микросервисов поднять? Можно было создать для каждого процесса один сервер и разместить там все микросервисы, либо для каждой задачи создать свой микросервис и отдельный бизнес-процесс в нем.
Второе было бы удобнее, но пришлось бы организовывать взаимодействие процессов, разбросанных по отдельным микросервисам.
Мы попробовали несколько вариантов и остановились на решении, где за определенную тему отвечают несколько микросервисов и там группируется несколько процессов.
Связь происходит либо через REST, либо через Rabbit MQ. Сейчас мы запустили пилотную версию Kafka.
Перспективы BPMS
Бизнес-процессы не только отражают рабочий процесс бизнеса, но и реагируют на события, происходящие в других системах.Эти события мы аккумулируем в отдельном подразделении Big Data. По результатам анализа этих событий создаются новые бизнес-процессы или изменяются существующие – это происходит постфактум, с периодичностью, например, один раз в день.
В идеале бизнес-процессы должны перейти в онлайн-режим — например, когда спрос на определенные услуги увеличивается, им следует автоматически приоритезировать и перераспределять ресурсы.
Этого можно добиться за счет автоматизации, интероперабельности, как у Kafka и Camunda, но это вопрос как минимум нескольких лет. Возможно, самым большим двигателем онлайн-перемен является полностью онлайновый английский Monzo Bank. И мы над этим тоже работаем.
Теги: #bpms #Промсвязьбанк #бизнес-процессы #открытый исходный код #ИТ-инфраструктура #Управление проектами #Управление продуктами
-
10 Способов Заинтересовать Посетителей!
19 Oct, 24 -
7 Фундаментальных Принципов Itil
19 Oct, 24 -
Ресурсы В Помощь Дизайнерам. Часть 2
19 Oct, 24 -
Тестирование: Ручное Или Автоматизированное?
19 Oct, 24 -
Сервисы Онлайн-Восстановления Паролей
19 Oct, 24
